|
Silver Alicorn posted:Just a quick-ish audio question - I'm playing with sound on my STM32F0DISCOVERY, and so I don't end up wrecking anything I'm running the output through an LM324 op-amp. I'm running it at 5 volts (well, the onboard regulator is giving me 4.6 volts but I'll take it I guess). It's reasonably loud in headphones, really quiet on an 8 ohm PC speaker I have. Use an LM386 or another audio amp chip. Op amps are usually designed for relatively low currents, which means driving relatively high impedance loads. You want something that's designed to drive a speaker. Some op-amps have up to a few hundreds ohms output impedance which is a lot compared to an 8 ohm speaker; this impedance in series with the speaker acts like a voltage divider and dissipates most of your power. From the datasheet at Onsemi looks like the LM324 has about 25 ohms impedance on the high side which is still a lot compared to a speaker. High impedance headphone might be a few hundred ohms, which would explain why they sound ok with a 324. A higher voltage would certainly sound louder, if you have more gain, but you're still battling the opamp's output impedance.
|
#
?
Mar 4, 2013 07:17
|
|
|
|
| # ? May 9, 2024 02:15 |
|
|
Hey guys, I'm building a motor speed controller circuit to control a small DC motor (draws between 200 and 500mA from what I can tell) using a PWM signal, with a little LED in parallel to judge the approximate speed visually: What I have here right now works fine as far as I can tell, but I was wondering: should I be doing anything to protect the driving circuit (in this case, an Arduino)? Could the motor suddenly shutting off cause a big inductive voltage kickback or something and fry the Arduino? Is there anything else horribly wrong with my design that will ruin everything? Am I just being paranoid?
|
|
#
?
Mar 4, 2013 08:05
|
|
|
My experience with dodgy DVI cables suggests that errors can creep in and affect video quality, primarily with solid coloured pixels in dark areas of the screen. I'm not sure if it's an effect of how it's encoded but it only seems to happen when a large area surrounding the pixel is also dark. This should be fairly obvious if you test it for more than a few minutes before deciding it's ok, but just getting a static picture on screen does not guarantee a perfect image.
|
|
#
?
Mar 4, 2013 09:19
|
|
|
Parallel Paraplegic posted:Hey guys, I'm building a motor speed controller circuit to control a small DC motor (draws between 200 and 500mA from what I can tell) using a PWM signal, with a little LED in parallel to judge the approximate speed visually: It probably won't hurt the Arduino to keep things the way you have them because the MOSFET will provide some protection and 200-500 mA isn't a huge amount of current. That being said, it's generally good practice to stick a reverse biased diode around the motor to clamp any inductive kick.
|
|
#
?
Mar 4, 2013 15:44
|
|
|
SnoPuppy posted:It probably won't hurt the Arduino to keep things the way you have them because the MOSFET will provide some protection and 200-500 mA isn't a huge amount of current. Just to clarify, the 5v rail is also coming from the Arduino, which I believe is just directly wired to the USB port (I used the "Vin" pin). As for the diode, "around" meaning in parallel with (but reverse biased so nothing flows through it normally) I assume? Sorry, I haven't really done much as far as protecting things with diodes goes before 
|
|
#
?
Mar 4, 2013 18:11
|
|
|
longview posted:My experience with dodgy DVI cables suggests that errors can creep in and affect video quality, primarily with solid coloured pixels in dark areas of the screen. I'm not sure if it's an effect of how it's encoded but it only seems to happen when a large area surrounding the pixel is also dark. Yeah, this has been my experience as well, which is why I asked. I've seen a hand-repaired DVI cable cause ghosting and flickering before in certain areas of the screen. Even though it's digital, I imagine there's some sort of clock signals that might be susceptible to interference. We'll see when my new Aoyue 937+ soldering station gets here tomorrow!
|
|
#
?
Mar 4, 2013 19:50
|
|
|
Parallel Paraplegic posted:Just to clarify, the 5v rail is also coming from the Arduino, which I believe is just directly wired to the USB port (I used the "Vin" pin). Cathode connected to positive in parallel with the motor, yes. Edited: I'm a moron longview fucked around with this message at 22:46 on Mar 6, 2013 |
|
#
?
Mar 4, 2013 21:58
|
|
|
HATE TROLL TIM posted:Okay, I'll see how that works. I was under the impression HDMI is very susceptible to noise. If I *did* need shielding, would tin foil do the job? Well we were able to get a 50' run of triple-shielded HDMI working in order to record our big tesla coils, so it can be surprisingly robust. I think we also added a bunch of ferrite chokes as well.
|
|
#
?
Mar 4, 2013 22:42
|
|
|
Okay I have a verilog question. How is contention (meaning a wire or register being driven simultaneously to different states at the same time) actually dealt with in cad tools? Right now I'm developing verilog with Active HDL, and upon compilation and simulation, it does not give any errors about obvious contention bugs, but the bugs are obviously affecting the functional simulation results. As of now there's no implementation or synthesis tools in the software, so maybe that's why? Eventually we're going to have to implement the design in Cadence, but I was hoping that we'd be able to do most of the coding and debugging in Active HDL, since it's just much more familiar. But if it can't detect contention, then it's basically worthless.
|
|
#
?
Mar 4, 2013 22:47
|
|
|
Parallel Paraplegic posted:Just to clarify, the 5v rail is also coming from the Arduino, which I believe is just directly wired to the USB port (I used the "Vin" pin). Not that I'm an expert, as I've only been playing with the Arduino for about a month...but my understanding is that a typical Arduino board is only supposed to be run at maximum of 40mA per I/O pin, and 200mA maximum load on the board as a whole. Anything that's going to consume more current (especially a motor) is usually run from an external power supply through a controller of some sort. You *probably* won't burn your board up with a small motor, but it's something to think about. You could build a motor controller with about $7 worth of components or just grab a cheap Chinese motor shield off eBay or Amazon.
|
|
#
?
Mar 4, 2013 22:56
|
|
|
Aaaaaand, I completely forgot to address the reason I opened this thread today in the first place!  Does there exist such a thing as a purpose-built PCB drill press for the average hobbyist? I'm somewhat in the mental design stage of a DIY rig, but with all the other projects I have hanging out in the wind, the last thing I need is another unfinished one. I wouldn't be afraid to spend a little money to save me the time, and it'd certainly help some of the other projects along. 
|
|
#
?
Mar 4, 2013 23:00
|
|
|
ANIME AKBAR posted:Okay I have a verilog question. For actual implementation you should get a DRC error at one of the build stages. Which stage (synth/map/PAR) probably depends on the tools and design. While I'm quite familiar with FPGA/HDL development, I only work with VHDL and Modelsim. Hopefully I can still offer some advice. For simulation, I'm surprised that you're not getting an 'X' or 'undefined' propagated around. That's typically what happens if you get a signal that can't be resolved. Have you tried seeing what happens when you intentionally double drive a net? Do the tools just randomly decide to pick a '0' or '1'?
|
|
#
?
Mar 4, 2013 23:25
|
|
|
SnoPuppy posted:For actual implementation you should get a DRC error at one of the build stages. Which stage (synth/map/PAR) probably depends on the tools and design. quote:For simulation, I'm surprised that you're not getting an 'X' or 'undefined' propagated around. That's typically what happens if you get a signal that can't be resolved.
|
|
#
?
Mar 4, 2013 23:35
|
|
|
Acid Reflux posted:Not that I'm an expert, as I've only been playing with the Arduino for about a month...but my understanding is that a typical Arduino board is only supposed to be run at maximum of 40mA per I/O pin, and 200mA maximum load on the board as a whole. Anything that's going to consume more current (especially a motor) is usually run from an external power supply through a controller of some sort. The specific pin I'm using (Vin) is supposedly directly wired to the USB port's power, which can support up to 500mA according to the USB spec. Normal I/O pins (which are just being driven by the microcontroller) probably shouldn't have much load on them, yeah. No part of the Arduino seems to get particularly warm so I think I'm okay. I had originally built a separate power supply for it but it was a pain to carry around and plug in when I could just as easily suck it out of my laptop. longview posted:Anode connected to positive in parallel with the motor, yes. Wait, anode towards positive? Wouldn't connecting it like that mean the current would just flow through the diode instead of the motor when in normal operation?
|
|
#
?
Mar 4, 2013 23:42
|
|
|
Parallel Paraplegic posted:Wait, anode towards positive? Wouldn't connecting it like that mean the current would just flow through the diode instead of the motor when in normal operation?
Acid Reflux fucked around with this message at 00:38 on Mar 5, 2013 |
|
#
?
Mar 5, 2013 00:35
|
|
|
Acid Reflux posted:A 4001 would be more than enough to handle your 500mA motor. Good thing too, considering I have a whole bin full of 4001's Thanks!
|
|
#
?
Mar 5, 2013 00:47
|
|
|
Why oh why oh why, in the year of our lord 2013, do ICs still have faded dark grey print on them even when they're brand new???? Why don't they have bright, easy-to-read white markings signifying what they are? Does anybody know the answer to this question? It's like chip makers are ashamed of their product and sheepishly write the numbering on them in dark grey to hide it. Unless I have bright sunlight I often have to spend 5 minutes tilting a DIP back and forth before the light hits it just right, letting me see the faded brown or dark gold ink that lets me know if this is an ATMEGA328 or that quad-AND-gate chip I was looking for. I even tried using a silver sharpie to write on these but the smallest tip I could buy at the art store is still too thick to write much. Strangely, with some of these chips if I cover it in the silver ink it actually makes the writing stand out more.
|
|
#
?
Mar 5, 2013 06:03
|
|
|
The markings are typically laser etched, which doesn't always make for the best readability/contrast on whatever epoxy the package is made out of.
|
|
#
?
Mar 5, 2013 06:11
|
|
|
Acid Reflux posted:Aaaaaand, I completely forgot to address the reason I opened this thread today in the first place! You could look at workstations that Dremel has: http://www.dremel.com/en-us/attachments/Pages/ProductDetail.aspx?pid=220-01 Or try it free hand, which I think was done here: http://quinndunki.com/blondihacks/?attachment_id=1166 Parallel Paraplegic posted:Wait, anode towards positive? Wouldn't connecting it like that mean the current would just flow through the diode instead of the motor when in normal operation? Afrotechmods has a video talking about this: https://www.youtube.com/watch?v=LXGtE3X2k7Y Terminal Entropy fucked around with this message at 06:28 on Mar 5, 2013 |
|
#
?
Mar 5, 2013 06:23
|
|
|
ANIME AKBAR posted:The thing is my version of Active HDL doesn't have any implementation or synthesis tools (it can support them, but doesn't provide them). It can't even generate netlists. I was assuming that contention could be detected at the compilation stage, regardless of implementation. I agree with SnoPuppy that I'd expect to see red and X's given contention. Without knowing more I'd wonder if you really have the contention you think you do. Can you code up a clear cut example of contention and verify that it's consistent with what you're seeing? That said I've seen the simulator (Xilinx in my case) be fairly permissive of some things that it probably shouldn't in my oppinion. At least in the context of FPGA development. How do you like Aldec? They package with lattice and I've been wanting to design in some MachXO2 parts.
|
|
#
?
Mar 5, 2013 16:13
|
|
|
You should use a Schottky diode for this, regular diodes have a slow turn-on time after being reverse biased. The reason you haven't had problems so far is that the body of the FET itself is a small diode.
|
|
#
?
Mar 5, 2013 16:21
|
|
|
Terminal Entropy posted:You could look at workstations that Dremel has: http://www.dremel.com/en-us/attachments/Pages/ProductDetail.aspx?pid=220-01 I have one of these and it's very useful for drilling tiny holes that I'm not comfortable doing freehand (PCBs and acrylic mostly).
|
|
#
?
Mar 5, 2013 18:23
|
|
|
I'd recommend the Proxxon IB/E and the MB 140/S over the Dremel Workstation. It came a bit more expensive but I wasn't impressed at all about the Dremel's plastic clip, it felt shaky. Basically the same feeling as this guy: https://www.youtube.com/watch?v=1JyTf1tJXXo If you are more serious and want a true small drill press I can recommend the Proxxon TBM. It comes a bit more expensive than the IB/E + MB 140/S but it is "the pro way" to go about hand-drilling PCB holes in my opinion.
|
|
#
?
Mar 6, 2013 00:59
|
|
|
I used the Dremel drill press, plus Harbor Freight carbide bits to drill my holes in several personal boards. It works very well for average through-hole boards.
|
|
#
?
Mar 6, 2013 05:06
|
|
|
Thanks for all the suggestions! I like the Proxxon drill press, although I'm not sure I want to spend quite that much just yet...but it does look quite nice. Hmmmm. Decisions, decisions...
|
|
#
?
Mar 6, 2013 05:34
|
|
|
I seem to recall Jameco selling a cheap mini drill press just for PCB drilling a while back, but I can't be bothered to search for it.
|
|
#
?
Mar 6, 2013 05:48
|
|
|
Just pickup a standard benchtop drill press from a surplus store. The quality of the drill bits are way more important than the drill itself. Just make sure the press has a decent chuck that can take very small bits.
|
|
#
?
Mar 6, 2013 06:05
|
|
|
asdf32 posted:I agree with SnoPuppy that I'd expect to see red and X's given contention. Without knowing more I'd wonder if you really have the contention you think you do. Can you code up a clear cut example of contention and verify that it's consistent with what you're seeing? code: quote:That said I've seen the simulator (Xilinx in my case) be fairly permissive of some things that it probably shouldn't in my oppinion. At least in the context of FPGA development. quote:How do you like Aldec? They package with lattice and I've been wanting to design in some MachXO2 parts.
|
|
#
?
Mar 6, 2013 14:05
|
|
|
ANIME AKBAR posted:
Hmm well I guess one argument is that simulators actually do, and must, run through code step by step. And testbenches need to run non-synthesizeble code. So by that reasoning why should the simulator care? The decrement code comes second so decrement wins. But I'll try this in xilinx at work tomorrow if I remember. Synthesizers will throw this out on the grounds that the same variable can't be assigned in two different always blocks. Did you say you're going to synthesize this? You may want to synthesize as you go along to avoid getting to far with un-synthesizeable code. If you're new to verilog the difference can be confusing. Edit: And what I was picturing when I said create a conflict was using an assign statement to assign two different values to the same variable. I believe that really should give you an X. As should having two different modules assigning the same variable (which should be equivalent to two assigns). asdf32 fucked around with this message at 02:08 on Mar 7, 2013 |
|
#
?
Mar 7, 2013 01:58
|
|
|
Ok, so I'm working my way through Electronic Devices and Circuit theory, and I'm stuck on BJTs. I have a superficial understanding of how they work, but there's a couple of concepts that aren't explained very well and are completely tripping me up. I understand the basics though:
What's tripping me up is, it seems to me that once the major emitter-collector current is established, it's just cascading straight across of its own accord and the base current won't affect it. I've tried checking a lot of different sources and they just gloss over it, so obviously something is being assumed that I'm not picking up on. My best guess is that the depletion areas can only be filled in by charge carriers coming in from the base, but I don't see what makes those charge carriers different from the other charge carriers flowing through the transistor. Please tell me why I'm wrong. e: telling me what I'm saying makes no goddamn sense would also be a step in the right direction for me. e2: on second thought, how important is it for me to know how it works on this level if I plan on getting into serious EE? Should I just assume there's a wizard inside making sure the electrons go where they're supposed to? e3:Well I found a course outline from a UCSD prof that made a bit more sense - looking at a PNP transistor, the base current causes a diffusion of holes into the base, and then a more or less equal number of electrons hop from the collector into these holes. If you drop the base current too far, any holes that existed fill up, but now there's no more insertion of electrons from the base terminal, so no new holes come from the emitter and the E-B depletion zone grows again. Somehow I got the idea that the same electrons are flowing all the way from the collector to the emitter, but it's more like a handoff happens at the base. As far as I understand it, when you forward bias a p-n junction, it becomes easy for electrons to spontaneously jump into holes across the junction, even if they're not directly contributing to the current? So in a forward-bias diode, you get a concentration of holes at the cathode, and electrons in the anode? That would explain why so many holes cross into the base region of a PNP transistor. I hope I'm on the right track, it's starting to make sense. Silver Alicorn fucked around with this message at 08:01 on Mar 7, 2013 |
|
#
?
Mar 7, 2013 03:34
|
|
|
Acid Reflux posted:Thanks for all the suggestions! I like the Proxxon drill press, although I'm not sure I want to spend quite that much just yet...but it does look quite nice. Hmmmm. Decisions, decisions... I have a Dremel drill press and the plastic holder flexes causing oval holes.
|
|
#
?
Mar 7, 2013 09:38
|
|
|
ANIME AKBAR posted:Compiles with no errors or warnings. Simulation shows dummy decrementing on falling edges, always a valid state
|
|
#
?
Mar 7, 2013 12:43
|
|
|
asdf32 posted:Hmm well I guess one argument is that simulators actually do, and must, run through code step by step. And testbenches need to run non-synthesizeble code. So by that reasoning why should the simulator care? The decrement code comes second so decrement wins. quote:Synthesizers will throw this out on the grounds that the same variable can't be assigned in two different always blocks. Did you say you're going to synthesize this? You may want to synthesize as you go along to avoid getting to far with un-synthesizeable code. If you're new to verilog the difference can be confusing. makomk posted:This was mentioned in the OP of the Cavern of Cobol Verilog thread which I just happened to read recently. Apparently assignments in different always statements are processed in arbitrary order at simulation time: http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf No idea why it does things that way, but it does seem to be pretty easy to get a mismatch between simulation and synthesis in general. But just to be clear, I'm not talking about blocking assign statements (using the assign statement), I'm talking about non-blocking operations which are always edge triggered. ANIME AKBAR fucked around with this message at 14:49 on Mar 7, 2013 |
|
#
?
Mar 7, 2013 14:42
|
|
|
Even Webpack won't synthesize with multiple drivers:code:
|
|
#
?
Mar 7, 2013 16:45
|
|
|
ANIME AKBAR posted:It certainly would be nice to synthesize along the way, but so far we've been unable to get Cadence's verilog stuff working, and there doesn't seem to be anyone at our university who has done so. From what I've heard, people here resort to doing all the verilog debugging (including netlist and gate-level schematic export) in another program called NCsim, then right at the end they will just dump the netlist into Cadence and pray to silicon Jesus that it works in the mixed signal design. I'd... like to avoid that. But I don't suppose anyone here has experience with Cadence. What toolkit are you using from Cadence? FWIW, Quartus immediately called me dumb as well trying to synthesize your code. NCSim is their simulator from their Incisive suite which eats the INCA code generated from ncvhdl/ncvlog + elaboration from ncelab. I don't mind it too much nowadays (really expensive), though I'm in the middle of evaluating QuestaSim from Mentor right now as Cadence wants more money for SV support (apparently the Altera AXI BFM is all SystemVerilog).
|
|
#
?
Mar 7, 2013 19:06
|
|
|
ANIME AKBAR posted:This is the opposite of what I'd expect from an HDL development tool. If two blocks are triggered by the exact same event, then it shouldn't matter what order they're coded in. And of course there are some implementation related issues that a mere compiler can't be expected to deal with, but contention really shouldn't be one of them. Consider though that multiple non blocking assignments are allowed to the same variable and the last one takes precedence. For example: A <= 1; A <= 0; This is considered acceptable and will even synthesize. So what you wrote, from the simulators perspective, is equivalent - two non-blocking assignments in the same time step. What bothers me is that the order of the two posedge blocks is not guaranteed (I believe), therefore it's ambiguous even in the simulator and a warning should be provided. So in the absence of your actual synthesizer consider downloading lattice diamond (which talks to Aldec) and target one of their FPGA's. Lattice uses synplicity under the hood which is a well known synthesis tool. Heh and be careful when you say cadence - they have tons of producs with constantly changing names. Oh and yes your code does simulate in Xilinx's simulator as well but does not synthesize as expected (as jawn pointed out). asdf32 fucked around with this message at 22:35 on Mar 7, 2013 |
|
#
?
Mar 7, 2013 19:29
|
|
|
Silver Alicorn posted:Ok, so I'm working my way through Electronic Devices and Circuit theory, and I'm stuck on BJTs. I have a superficial understanding of how they work, but there's a couple of concepts that aren't explained very well and are completely tripping me up. I understand the basics though: Well first, it sounds like you're close to understanding it so I would keep persuing it. But the answer to e2 is probably not very. Sure there are areas of engineering where you need intimate knowlege of semiconductor manufacturing but in most areas you won't. At my company I doubt anyone but perhaps one person (our power engineer PHD) out of 8 hardware people could answer your question. There are some people that can talk some stuff about P-N junctions but if pressed it's usually the case that they can't demonstrate any useful understanding of it. I'd put myself into that category. A transistor can be best understood like a faucet. It's off, then it's on a little, then it's on more, then it's all the way on. The valve in the case of a mosfet is the gate to source voltage and the base to emitter current in a BJT. Very few people need to care about the particulars of that transition phase because most of the time you're trying to avoid it. When you're trying to harness it, as you might for certain linear circuits you often need feedback anyway because the part to part or temperature variations for things like Vbe, hfe, or gate turn on threshold are so wide. Once you have feedback you no longer care. As an aside this touches on a subject I could write volumes about - the inadequacy of engineering education. Like you, I went through a phase of being "taught" this stuff and I imagine at the time I had the equations on my exam cheat sheets and I dutifully filled them in for an occasional right answer. However in the process the complexity of all the junk masked basic purpose and different practical uses for transistors such that when I finally got a real job and set out to use a transistor in a real application I promptly blew up several. I remember that lesson well. Anyway, after doing board design for 8 years I'm positive I've never needed anything in your question. Again, thats not to discourage anyone from learning this stuff, having a good grasp of underlying principle is always useful. It's just there are limits to what you can spend time studying and this stuff wouldn't be that high on my list. Well before any of this stuff you should understand some of the more practical uses and applications for transistors.
|
|
#
?
Mar 8, 2013 01:08
|
|
|
asdf32 posted:As an aside this touches on a subject I could write volumes about - the inadequacy of engineering education. Like you, I went through a phase of being "taught" this stuff and I imagine at the time I had the equations on my exam cheat sheets and I dutifully filled them in for an occasional right answer. However in the process the complexity of all the junk masked basic purpose and different practical uses for transistors such that when I finally got a real job and set out to use a transistor in a real application I promptly blew up several. I remember that lesson well. Anyway, after doing board design for 8 years I'm positive I've never needed anything in your question. me posted:Talking about RF, is it just me or is a lot of RF/analog becoming a lost art? Seems like my parent's generation had quite a few self-taught HAM types who are comfortable with antenna design and a bunch of other things that I, with my formal education, am not comfortable with. It could just be practice (I don't do much antenna stuff, they have years and years of experience) or willingness to experiment (they are picking up analog radio stuff so they can play with the antenna, I'm doing digital 2.4 GHz so I follow the datasheet exactly), but I'm always sad when I see old electronics magazines and they gloss over details on stuff like antennas because 'duh' and I don't get it. 
|
|
#
?
Mar 8, 2013 01:44
|
|
|
My analog professors were practically religious in their fervor to convert people into analog engineers, and there's definitely a lot of money if you can handle it. It was always black magicks for me. I'm perfectly content pretending binary is as far down as the rabbit hole goes.
|
|
#
?
Mar 8, 2013 01:52
|
|
|
|
| # ? May 9, 2024 02:15 |
|
|
Silver Alicorn posted:What's tripping me up is, it seems to me that once the major emitter-collector current is established, it's just cascading straight across of its own accord and the base current won't affect it. I've tried checking a lot of different sources and they just gloss over it, so obviously something is being assumed that I'm not picking up on. My best guess is that the depletion areas can only be filled in by charge carriers coming in from the base, but I don't see what makes those charge carriers different from the other charge carriers flowing through the transistor. Please tell me why I'm wrong. I think it's because unless you're doing something to keep the base voltage high, then the collector-base junction (which is a reverse-biased diode) will block current. I don't really understand what makes the ratio of Ice to Ibe be what it is though.
|
|
#
?
Mar 8, 2013 02:02
|
|