Jump to content

dannyboy

Members
  • Content Count

    34
  • Joined

  • Last visited

About dannyboy

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Sydney, Australia
  • Github
    https://github.com/crabmusket
  1. That ULN2003 package looks convenient - am I right to think it'd be possible to power the entire LED strip through it rather than through the MOSFETs? That seems weird... what about heat dissipation? I guess my power requirements aren't very high (600mA at 12V makes 7W for the whole LED strip). Thanks everyone for spending time on me - I'm slowly finding my way through practical electronics! I come from code-land where everything is just high or low .
  2. Thanks, everyone! @@RobG and @@veryalive, I'd show my connections if I had more than a crappy phone camera which really does not photograph breadboards well. Believe me, I've tried. But I've been over the schematic many times since I discovered the failure, and I'm as certain as I can be that the connections are the right way around. The sources are connected to ground, and the drains to 12V via the LED strip. @@spirilis Thanks for pointing that out! I'd been reading that as needing 2-4V in any condition... silly me. I'm giving it 12V from a wall wart, and according to the Adafruit tutorial I can expect to see 600mA drawn if I have all the LEDs on. I wasn't up to the stage of verifying that yet. I forgot to mention that I tested the MOSFETS after running them a bit, and they didn't seem to have heated up - but you and @@oPossum are right, I was definitely driving them at way too low a voltage. It worked somewhat, but probably wasn't ideal. Given I don't need a ton of current, the Arduino's 5V should be fine according to figures 5 and 6, but not 3.5V. So, it looks like RobG's booster would be an ideal solution, but I'm enthusiastic to make this work myself, and I eventually want to fit the circuit on a smaller footprint than the LaunchPad itself (I want this LED strip as a lighting fixture!). My naive first solution would be to include some sort of intermediate power supply at 5-6V, and connect non-power MOSFETs to the MSP to drive the gate voltages of the bigger MOSFETs. However, voltage dividing 12V to get 6V sounds like a bit of a waste. Must do more research. And think about MOSFET safety! A bit of research indicated I shouldn't need a heatsink for the MOSFETs, but better safe than sorry.
  3. I've been playing around with an analogue LED strip - basically following this tutorial, but using a LaunchPad instead of an Arduino. I'm using STP16NF06 power MOSFETs rated for 16A/60V, which should be fine (the strip should draw no more than .8A at 12V for each colour). However, I've managed to induce failures into two of four of them - they allow drain-source current when the gate is held low, so two of my light channels never turn off. I'm not sure how I've managed to cause that failure, since I'm playing well below their rating. I hadn't been doing anything too extreme with the microcontroller, either - I'd only gotten to the stage of giving each channel a 1s on time (followed by 2s off while the other two channels turned on), which appeared to be working fine. I noticed the breakdown after I tested with the micro, so it must have happened in between that test and when I next tried to just select the channels manually (by connecting jumper wires to ground/3.3V). This page indicates that gate over voltage could cause 'hard on', which sounds like what I'm experiencing. (Gosh, that was a bit dirty in retrospect.) But I verified that the LaunchPad is giving 3.5V, and I had the grounds connected during operation. I did disconnect the LP from the circuit after that - could it have been something like disconnecting the ground in the wrong order? But I was pretty careful to always get rid of the 12V supply before touching the rest of the circuit. Anyway. I figure there was some accident that applied over voltage to the gates; I haven't destroyed either of the other two transistors since, so it seems like my normal operations aren't harming them. I just want to know what I should be doing to avoid those kinds of mistakes in the future!
  4. I've been playing around with Atom for a while - it's a Haskell DSL that generates C code that should run in deterministic time/space. I've been writing a library of MSP430-related definitions for it. Simple example. I've also been tempted to see if it's possible to get Nimrod compiled to C and working on a micro. It's a nice language and quite close to C.
  5. Thanks heaps everyone, using those tri-state buffers is a great idea. And I can get them as DIPs...
  6. I'd like to find an IC that will multiplex two 8-bit (i.e. 8-wire) signals, selecting one as output (on 8 wires). Does such an item exist? I'm not sure whether I'm searching for the right thing, but all I've been able to find is this TI 'LAN switch' which appears to do what I'm after, but doesn't seem to be breadboard-able. I could of course recreate the logic myself, using ICs with multiple 1-bit 2-to-1 multiplexers, but the wiring would be much less fun.
  7. I have wanted someone to make one of these for ages! Fantastic job. I imagined it having a bit less deviation (i.e., each tick being maybe a tenth to a fifth of a second off) but this is just great.
  8. Hmm, so IAR is having the same difficulty. I'll have a go reinstalling the drivers.
  9. This is a fresh install of Windows 7 64 bit, actually. I've installed the MSP drivers, and when I plug in the LaunchPad with a 2231 in the socket, I can find a 'MSP-FET430UIF' in the Devices and Printers menu. Energia only lists COM1 when the board is unplugged, but lists COM1 and COM3 when it is plugged in. I select COM3, upload one of the example sketches, and get: Binary sketch size: 547 bytes (of a 2,048 byte maximum) tilib: MSP430_OpenDevice: Could not find device (or device not supported) (error = 4) tilib: device initialization failed This is with 0101E0009. Where should I go from here? I think my first step will be to install IAR (which I have used previously with success) to see if it's Energia or if I've really messed up the setup somehow.
  10. Yes, leveraging existing tools should be a priority. that makes a lot of sense. Unfortunately I have found few other languages for specifying circuits, other than netlists or some package-specific formats like LTSpice's text-based file format. VHDL is important, but has different design goals. I will definitely have a look for more! CircuitLab seems to be the closest to what I want to do in terms of environment, sharing and so on, though they have an entirely visual editor and slightly less convenience (need to log in to create).
  11. The idea with 'via' is you can connect any number of routes to it. A route can just be a single component name X (which is shorthand for X.in>out), or you can specify the full route. So to add the transistor in the middle: V.plus -> V.minus via (R then Q.base>emitter then C) || L I guess having a '+' with regular precedence and using parentheses wouldn't be too bad. It makes it more understandable - replace 'then' with '+' if you're in a hurry :-P. That's the plan! Well, not C++ - the idea is to provide an in-browser editor and environment for other tools, again, something like JSFiddle.
  12. I guess it's easiest to show you by example: V.plus -> V.minus via (R then C) || L then Q.base > emitter The indentation is just for formatting, the language itself is insensitive to it. I'm also experimenting with briefer syntax options using more maths operators: V.plus -> V.minus via R & C || L then Q.base>emitter Notice that there are three operators with different precedences - the & (series) is applied first, then the || (parallel), then the 'then' (series again). Not sure if that would be too confusing. Using '+' instead of '&' might be a good idea here, but the point of using '&' was to make a higher-precedence, concise version of 'then'. '+' is lower precedence than || in maths, usually, so that might be a bit jarring. I also wanted to use '+' and '-' as port names - for example, V1.+ and V1.-, though that just looks a bit odd. That's also a big goal for me. I guess that's where I need feedback the most, since what I decide to be intuitive syntax might not seem that way for everyone! I've been inspired a lot by Bret Victor's essay on learnable programming, and by CoffeeScript.
  13. Sorry, I didn't really get into detail about the language syntax in my post. I can clear that up - the 'via' keyword used for the resistor isn't vague at all when you know how it works. Via will create a route through a component in an automatic direction 'in' to 'out'. So I could equivalently write V1.plus -> R1.in V1.minus -> R1.out But using 'via' makes it clearer that the two ports are connected across the resistor, and it's more concise (Maybe 'across' would be a better keyword, but I thought 'via' gave a sense of the current flow... though of course, you could connect it backwards and it would be electron flow... or you could connect components in a way that makes no sense at all in terms of current.) Different components have different pin names available, and you can specify routes for multi-pin components. For example, connecting two voltage supplied across a transistor: V1.plus -> V1.minus via Q1.base>emitter V2.plus -> V2.minus via Q1.collector>emitter V1.minus -> V2.minus # Connect grounds As for having to specify the model for R1, I agree it's too verbose, but that's why I added the 'modelinference' option. Maybe model inference should be on by default, and you can unset if you want to name things oddly? I will look into VHDL! But I really wanted to move away from defining nets and into refining paths/routes.
  14. This is something I've been thinking about for a while. Circuit exchange, IMO, seems a bit broken. At least, this is my perspective coming through EE education (still in uni) and seeing people sharing Eagle files, hand-drawn schematics, etc. Sharing Eagle files is probably a good idea when you get to more complex circuits, and want to start specifying layout and more details, but for simple circuits, especially those you encounter in classes, images are just not a great way to go. I could talk about that a bit more, or I could tell you what I'm up to. I've started to specify a plaintext language for circuits. The goal is to allow you to write a circuit definition really naturally as a text file. This includes component definitions and connections, but not the actual layout of circuits. Here's an example simple circuit in netlang: V1 model = dc_source, potential = 10mV R1 model = resistor, value = 1kOhm V1.plus -> V1.minus via R1 I hope it's pretty clear what's going on - I tried to design the language for both conciseness and readability. Defining components is a matter of listing properties (like what model they should use, and any values associated with them). Defining the connections in the circuit uses the graphviz-like -> symbol, but I added the ability to use `via` clauses to make the logic of the circuit more clear. This is what makes the language a step above netlists, IMO: you can define loops individually, giving your circuit description much more meaning than just defining a list of nodes that connect the components. And for the code ninjas, I'll eventually want to provide options to allow you to make trivial circuits even more trivial. Here's a rewrite of the above circuit using model inference (the interpreter guesses that something named V1 is a DC supply) and inline models (no need to specify a component for the 1k resistor): set modelinference, inlinemodels V1.plus -> V1.minus via 1kOhm V1 10V I'm posting this up here to gauge some initial reactions. I've started to define the language grammar in ANTLR, but before I finish it off and port it to Jison, I'd like to see what actual people working with electronics think of it. I think defining new text-based languages is an excellent idea, but obviously not everyone's going to feel the same way! And, more important than the language itself is what it gets used for. I really want to make it much easier to share circuit designs, not just write them. I'd like to provide a service like JSFiddle or pastebin for circuit designs - write out your circuit in netlang, share it with a short URL, and so on. Update circuit designs and re-share them, add comments and tags, etc. What tools would you use on top of that? Exports to popular file formats? I don't think I have the skills to write a full-on browser-based circuit simulator, but I'd like to be able to export netlang circuits to falstad's Java circuit sim applet. Or, the site could take your circuit design, convert it into a bunch of components and connections, and allow you to drag them around manually to lay out the circuit. I'd really love to do some backend work to analyse the layouts people come up with for their circuit, and try to design some algorithms to learn how to lay out circuits by learning from data on the site. Really, I'm just rambling here, so I'll shut up. Over to you guys!
  15. Just wondering whether anybody has used eispice before. It's a Python library that implements circuit simulation. I've been looking around for SPICE programs recently for an electrical engineering assignment which I'd really like to apply some computer science to - namely, using a genetic algorithm to evolve resistor values that give good biasing. Using one with a Python frontend would be perfect, since the algorithm can be implemented in Python. I guess I just want to get a feel for whether eispice has a reputation - and of course, whether there are any other alternatives I should be aware of!
×
×
  • Create New...