|
It is, in the sense that the current loop sensor drives the current to a value determined by the measured value and, say, an audio amplifier drives the voltage to a value determined by the sound pressure level. In fact, you can drive a 20mA indicator LED at a brightness proportional to the signal intensity by putting it in series with a current loop sensor and you can drive an incandescent bulb at an intensity proportional to the sound intensity if you connect it in parallel with an audio amp's speaker connection. The LED would easily burn up without a resistor on the audio amplifier output.
|
#
?
May 22, 2020 18:59
|
|
|
|
| # ? Apr 25, 2024 09:02 |
|
|
Gotcha, I think I understand it a little better now. Thanks for bearing with me and my not quite right understanding and way of explaining my thoughts! It's really helpful.
|
|
#
?
May 22, 2020 19:10
|
|
|
Sure, "voltage device" and "current device" may not be perfectly appropriate terms, but if you want to power an incandescent lamp you regulate a voltage and if you want to power an LED you regulate a current. If you want to drive a bunch of incandescent lamps at the same intensity you connect them in parallel so they see the same voltage. If you want to drive a bunch of LEDs at the same intensity you connect them in series to drive them at the same current. If you connect a voltage regulated power supply across an LED it may be too dim and it may blow up, but it's unlikely to be just right. If you connect a current regulated supply across an incandescent lamp, it may have trouble starting since the inrush current at the specified voltage is what it depends on to get up to temperature quickly. So, like, I get that they have different V-I characteristics and the incandescent bulb has the added dimension of temperature but it's at least not unreasonable to say something like led is to current as incandescent is to voltage, to a first order.
|
|
#
?
May 22, 2020 19:44
|
|
|
Yep, I studied Comp Sci and had an electronics class taught by the Physics department as part of my coursework. Then I had a first job where I wrote firmware for microcontrollers. It was a small company where nobody was an EE, of the three of us, owner was a CivE, I was CS, and the other guy was a highly experienced technician. So I have enough knowledge to be dangerous and use jargon close but not quite right  Amazing how far the model of circuits as pipes and valves can get you really, combined with the CMOS cookbook and someone who's seen how circuits fail over decades of work.
|
|
#
?
May 22, 2020 20:13
|
|
|
mobby_6kl posted:I've been trying to get ADC working on an ESP32 using the I2S with the internal ADC as shown in this example: https://github.com/espressif/esp-idf/tree/master/examples/peripherals/i2s_adc_dac I'm not familiar with this system so I can only give some general advice: Sampling at those rates you'd probably be better off setting up a circular DMA, and triggering your read/processing at the DMA half complete and complete interrupts (essentially making a double buffered DMA). Increasing the buffer size might help, since it reduces the interrupt rate. I assume you're dumping the data using a serial link; this serial link might be using all your resources, preventing the sampling from running well? Maybe dump it to a DAC and see what it looks like then? PCBs can be any 2D shape you want as long as it can be machined using a ~1mm end mill (you could go smaller but price might increase since the smaller end mills are fragile and slow).
|
|
#
?
May 22, 2020 21:57
|
|
|
mobby_6kl posted:I've been trying to get ADC working on an ESP32 using the I2S with the internal ADC as shown in this example: https://github.com/espressif/esp-idf/tree/master/examples/peripherals/i2s_adc_dac Ok so this I actually do know a bit about. First of all, you've discovered the semaphores and mutexes for what you're trying to accomplish here are two different ways of skinning that cat. Just use whichever metaphor makes the code more clear in its intent to you. Basically the difference is that the mutex itself should be enforcing the mutual exclusion whereas the semaphore is a signal flag and you've written your code to respect the meaning. So like if you were writing a library where the person using it wouldn't be expected to know all the rules of the system, you'd probably want a mutex. Side note, signal flag is literally where the name semaphore comes from. You know the little flags sailors wave around to communicate to another boat looking at them through a telescope? That's a semaphore. In regards to your signal there's quite a few aspects. First of all, a square wave is actually the infinite sum of its fundamental frequency and then all the odd octaves in diminishing weights. So if you're looking at a 10kHz square wave you're actually looking at 10kHz + (1/3 * 30kHz) + (1/5 * 50kHz) + ... The wikipedia article has a good animation: https://en.wikipedia.org/wiki/Square_wave Secondly I suspect the 125kHz is actually the sample rate of the ADC (technically 125 kSamples/sec). The analog bandwidth also needs to be high enough. Now you have to worry about input and output impedance and how fast the signal can actually change regardless of how fast you can measure it. Signals are a big ol' can of worms. Rule of thumb I'd suggest is get 10x faster ADC than you think you need. You can also try using an op-amp to buffer the signal. Also, it's fairly likely the the mutlimeter and/or the ESP32 spec sheets are stretching the truth with regard to their ratings.
|
|
#
?
May 22, 2020 22:30
|
|
|
Quick question: Are there any gotchas when wiring pins on microcontrollers? On the Rasperry Pi Compute, there are many things you have to connect. ~80 ground pins that must all be connected, ~15 power pins that must all be connected at 3 voltages, and each have a bypass cap. On the STM32 chip reference I'm looking at, it's got none of that: 4 ground pins all connected to the same ground, 4 power pins connected to the same power source with a fuse and voltage divider, and they're all on the same voltage. Is this normal? Simplest explanation is the Pi's just much more complicated . No gotchas in the datasheet so far. Mainly surprised vice the Pi, and even ADCs etc generally require a multiple resistors/caps for default usage. Related: If you're using a chip that accepts a flexible voltage range < 5V, but want to power it with 5V, would you use a (eg 3.3v) voltage regulator, or is a voltage divider with two resistors good enough? Intuition says the divider's fine, due to the flexible input V, and regulators or refs are more apt when the input VCC is picky. Dominoes fucked around with this message at 23:20 on May 22, 2020 |
|
#
?
May 22, 2020 23:03
|
|
|
Dominoes posted:Quick question: Are there any gotchas when wiring pins on microcontrollers? On the Rasperry Pi Compute, there are many things you have to connect. ~80 ground pins that must all be connected, ~15 power pins that must all be connected at 3 voltages, and each have a bypass cap. On the STM32 chip reference I'm looking at, it's got none of that: 4 ground pins all connected to the same ground, 4 power pins connected to the same power source with a fuse and voltage divider, and they're all on the same voltage. Is this normal? Simplest explanation is the Pi's just much more complicated . No gotchas in the datasheet so far. Mainly surprised vice the Pi, and even ADCs etc generally require a multiple resistors/caps for default usage. The STM32F0-3 series is that simple, you need 3.3V for VDD, 3.3V or something similar on VDDA (usually connected to the exact same supply), and a ~100nF capacitor to ground on the RESET_L line. Hook up VCC, RESET, SWDIO, SWCLK, and ground to the ST-Link and you've got a programming and debug interface. The STM32F4 series and up get more complicated (the F4s require some additional capacitors, for example). Do not power chips using voltage dividers. That's what voltage regulators are for, there are hundreds if not thousands of voltage regulators that can be used to convert 5V to 3.3V at whatever power level you need. The reason you don't power digital chips with voltage regulators is that the actual current they consume is highly variable, and they require a low impedance power supply. The voltage divider will be far less efficient than a linear regulator in almost all cases.
|
|
#
?
May 22, 2020 23:23
|
|
|
Dominoes posted:Quick question: Are there any gotchas when wiring pins on microcontrollers? On the Rasperry Pi Compute, there are many things you have to connect. ~80 ground pins that must all be connected, ~15 power pins that must all be connected at 3 voltages, and each have a bypass cap. On the STM32 chip reference I'm looking at, it's got none of that: 4 ground pins all connected to the same ground, 4 power pins connected to the same power source with a fuse and voltage divider, and they're all on the same voltage. Is this normal? Simplest explanation is the Pi's just much more complicated . No gotchas in the datasheet so far. Mainly surprised vice the Pi, and even ADCs etc generally require a multiple resistors/caps for default usage. quote:Related: If you're using a chip that accepts a flexible voltage range < 5V, but want to power it with 5V, would you use a (eg 3.3v) voltage regulator, or is a voltage divider with two resistors good enough?
|
|
#
?
May 22, 2020 23:27
|
|
|
Dominoes posted:Quick question: Are there any gotchas when wiring pins on microcontrollers? On the Rasperry Pi Compute, there are many things you have to connect. ~80 ground pins that must all be connected, ~15 power pins that must all be connected at 3 voltages, and each have a bypass cap. On the STM32 chip reference I'm looking at, it's got none of that: 4 ground pins all connected to the same ground, 4 power pins connected to the same power source with a fuse and voltage divider, and they're all on the same voltage. Is this normal? Simplest explanation is the Pi's just much more complicated . No gotchas in the datasheet so far. Mainly surprised vice the Pi, and even ADCs etc generally require a multiple resistors/caps for default usage. Nah you're good, the Pi is way more complicated, faster, and probably has more varied (and faster) buses. If you look at even more limited MCUs like the AVR8 or PIC16, a lot of them will have a single power and ground. Also you pay companies like ST and Microchip the big bucks because their datasheets are very good so whatever their reference circuit tells you is fine. If there are variables at play they should be noted in the sheet. On the power supply question, depends what you're doing with it. If the chip is really low power or you're just testing something out real quick a simple voltage divider could work. But a voltage divider will always waste power and a typical through hole resistor can only handle 1/4W which is real easy to exceed. So like 5-3.3 = 1.7V which means the first resist will limit you to ~150mA, probably more like 100mA to be on the safe side. If you have an op-amp on hand you can use the voltage divider to make a reference voltage and have the op-amp hold that voltage (which is essentially what a linear regulator is). But probably just get some voltage regulators and keep them on hand.
|
|
#
?
May 22, 2020 23:29
|
|
|
Never ever power microcontrollers or anything remotely complicated with a voltage divider. Your calculated voltage will immediately and always be wrong, because you don't have control over how much current it's drawing.
|
|
#
?
May 22, 2020 23:36
|
|
|
Thank y'all very much for the detailed explanations. Added a voltage regulator with bypass caps, and bypass caps on the NRST and VCC inputs. This is a breath of fresh air; and I can dodge the soldering problems that have been plaguing me, since this can be SMT-assembled by the board maker. The datasheet really is quite good.
|
|
#
?
May 23, 2020 00:06
|
|
|
All microcontrollers/SoCs/SoM's basically want the same things: - Power supplies connected, decoupled, and sequences properly - Grounds connected - Stable clocks The little STM32 is simpler because lots of those requirements end up being degenerate compared to the Pi: - There's no separate core/IO/memory voltages and no other chips to supply, so only one VCC and no ordering - It's physically little so one bypass cap for the one VCC is near the entire IC - You're using an internal oscillator so there's no crystal circuit Where are you getting stuff assembled by the way? Even at China costs, there's still a bunch of labor to massage pick-and-place files, load reels, etc... and I'm surprised it's practical
|
|
#
?
May 23, 2020 00:36
|
|
|
Thank you for info. I've been ordering from JLC. I'm going to investigate using a stencil and cheapish reflow oven, but for now, I like not having to include my terrible soldering in the troubleshooting process. Related: I think I've figured out why I couldn't get the solder to flow around the pads like in the vids: That only works if they stay on/near the feet. Once solder gets high in the pins, it has to be removed with wick and redone. The paste+hot air approach dodges this by pre-placing the solder at the base. Another related microcontrollers-are-awesome thing - apparently this includes multiple ADCs and op amps, which I both include separately in my designs. I wonder if some BOM reduction's in order. And the whole drat controller costs about the same as a 4-channel ADC, or 1/3 the price of the nicer op amps. Dominoes fucked around with this message at 00:50 on May 23, 2020 |
|
#
?
May 23, 2020 00:43
|
|
|
Dominoes posted:Thank y'all very much for the detailed explanations. Added a voltage regulator with bypass caps, and bypass caps on the NRST and VCC inputs. This is a breath of fresh air; and I can dodge the soldering problems that have been plaguing me, since this can be SMT-assembled by the board maker. ST in particular I find to have great documentation. The user manuals can be a little overwhelming but every little detail should be there somewhere. Pro tip: most of these companies have great application notes too if you look up the part you're using and click over to the documentation. These are essentially "This is all the really cool poo poo you can make with this part!" in enough detail to teach you things in the process.
|
|
#
?
May 23, 2020 00:44
|
|
|
Tangent: Any recommendations on small reflow ovens? Would something like this $~250 Chinese oven be OK for small-scale use on tiny boards? Probably a step up over the toaster oven projects. I notice some of the reviews recommend useful modifications, like grounding the case. Dominoes fucked around with this message at 00:57 on May 23, 2020 |
|
#
?
May 23, 2020 00:55
|
|
|
I've always used hotplates instead of ovens (work has some spare temperature controlled wet lab ones lying around). That thing looks nice but also suspiciously cheap (but I can't think of a reason why an IR oven like that would inherently be expensive).
|
|
#
?
May 23, 2020 00:58
|
|
|
You could probably pair a stencil with a hot air gun too, for small stuff
|
|
#
?
May 23, 2020 03:43
|
|
|
Beware the specs of the internal ADC (or DAC or opamp or mux or any analog bits) compared to an external IC. Not that they aren't appropriate for your application but check the specifications to make sure. They are often limited somewhat compared to standalone parts due to design complexity, size, cost, etc taqueso fucked around with this message at 04:05 on May 23, 2020 |
|
#
?
May 23, 2020 04:02
|
|
|
The STM32 ADCs are pretty good in my experience, they might start to fail if you're pushing the speed or need every single bit of resolution but very capable. The data sheet lists the approximate input impedance of the ADC for a given resolution and sample time (sample time can be turned up a lot, which makes a big difference). At full speed you definitely need a very low impedance driver, like most other high speed ADCs (the F3 ADCs can get down to 18 ohm effective input impedance running at full speed). If configured correctly for low speed mode with max sample time (e.g. scanning some pots or measuring supply voltages through dividers) it works fine up to ~100k source impedance as long as you have a capacitor to ground at the ADC input (I use 10nF or greater for those cases). Though using a lower source impedance is probably better to get full accuracy. Also something that isn't very obvious: the ADCs are factory calibrated (also the internal temperature sensor). If you enable the VRefInt channel you can calculate the actual VDDA voltage using the calibration value. Then you can use that + the temperature sensor calibration readings (2 point) to get a reasonably accurate die temperature. Knowing the exact VDDA voltage is also useful if you care about the actual voltage at the ADC input for other channels. I've never used the internal opamps, they seem to be pretty mediocre.
|
|
#
?
May 23, 2020 09:43
|
|
|
Maybe this whole thing would work properly with an STM32, but I've seen it work well enough for others so it has to be possible with the ESP too. longview posted:I'm not familiar with this system so I can only give some general advice: Yeah I've been dumping it over serial now.... I don't think that's the issue but I'll test it. Forseti posted:Ok so this I actually do know a bit about. First of all, you've discovered the semaphores and mutexes for what you're trying to accomplish here are two different ways of skinning that cat. Just use whichever metaphor makes the code more clear in its intent to you. Basically the difference is that the mutex itself should be enforcing the mutual exclusion whereas the semaphore is a signal flag and you've written your code to respect the meaning. So like if you were writing a library where the person using it wouldn't be expected to know all the rules of the system, you'd probably want a mutex. Side note, signal flag is literally where the name semaphore comes from. You know the little flags sailors wave around to communicate to another boat looking at them through a telescope? That's a semaphore. '. The FreeRTOS mutexes and semaphores seem to be identical except for priority inheritance, but in any case it doesn't make any difference here, even if I use neither.I don't know much about signals so that's certainly not making the project any easier  I don't know if it's actually hidden somewhere in the data sheet, but someone from Espressif did say the analog bandwidth is 6KHz: here https://esp32.com/viewtopic.php?f=2&t=1075&start=10 Still, I found this guy got it to measure a 4KHz signal pretty well with a similar approach so I've no idea WTF could be the problem  https://github.com/espressif/arduino-esp32/issues/3315 Well anyway, I found and I2S MEMS microphone in my box of crap and... after a morning of loving with it, it doesn't work right either. Just outputs garbage and occasionally this pattern: 3, 0, 2083, 6, 0,0, 8144, 16379, 4312, 16397. I even found a working example code and using it verbatim doesn't fix it.  Maybe something's wrong with the board. But I should probably just get a hobby that doesn't make me want to kill myself.
|
|
#
?
May 23, 2020 18:29
|
|
|
I have learned a lot this past year because I've been working on building an NTSC analog video decoder off and on for a while. It can get very complicated to understand for sure, I'm certainly no expert! On the analog bit the specification that I find easiest to visualize is the 'slew rate' which is the fastest rate the signal can change at. It will be in units like Volt/second. Any faster than this and the signal gets attenuated and appears to have less amplitude than it really does (because the circuit couldn't reach the real level before it changed again). The other thing is that real world signals are made up of a bunch of sine waves added together. 3 Blue 1 Brown has a great visual explanation for this: https://www.youtube.com/watch?v=r6sGWTCMz2k When you get to converting it to digital, sampling theory gets added into the mix. Technology Connections made a great video on this: https://www.youtube.com/watch?v=pWjdWCePgvA Both of these concepts are still hard to grasp though IMO. Practically, the easiest thing to do is use parts with capabilities much greater than what you think you need.
|
|
#
?
May 23, 2020 19:52
|
|
|
mobby_6kl posted:Well anyway, I found and I2S MEMS microphone in my box of crap and... after a morning of loving with it, it doesn't work right either. Just outputs garbage and occasionally this pattern: 3, 0, 2083, 6, 0,0, 8144, 16379, 4312, 16397. I even found a working example code and using it verbatim doesn't fix it. I'm currently (trying) to build an i2s phased array on a breadboard. The bit clock is a pain (1MHZ up to 4 MHZ) and gets horrible munched between the generator and the MEMS microphones and the USB adapter. Make sure your clock and WS/FRAME/LR line is as clean as possible. I still can't get it to work. Breadboards might not be that great for >1MHz signals, specially since the clocks come from another device over 15cm
|
|
#
?
May 23, 2020 21:06
|
|
|
Got another pair of questions re STM32 board design: Ordered this ST-Link/SWM board to flash things. # 1: What's your fav technique for being able to flash the board, but not cluttering it up? Through-holes you can put non-solder headers through temporarily? #2: How do you wire SWIM? From the description of that ST-Link module, it has 6 pins: VCC and GND, which are standard. SWDIO, SWCLK, and RST, which are well documented in the STM32's datasheet, , ref diagrams, IDE etc. AFAIK, you just match the pins. I'm confused about the SWIM pin, in that I can't find it anywhere on the STM datasheet, or in the body of the STM32 Discovery datasheet, other than the ref diagram, which labels 3 pins connecting to the SWIM net, 2 to SWIM_IN, and two more to SWIM_RST/RST_IN. These don't seem to go anywhere. It seems it could be an arbitrary GPIO configured in a certain way? I'm also a bit confused in that elsewhere, SWT is described as needing only 2 pins, but we have 4 here. Dominoes fucked around with this message at 21:48 on May 23, 2020 |
|
#
?
May 23, 2020 21:46
|
|
|
SWIO is the STM32 programming/debugging protocol. SWIM is the STM8 protocol. Yeah, I typically just provide some standard header footprints if I can get away with it. SOICbite is a good miniaturisation system for later.
|
|
#
?
May 23, 2020 21:50
|
|
|
Awesome. So I provide a header for SWDIO, SWCLK, and RST? Great! I noticed on the Discovery ref, the breakout header includes a T_SWO pin too, that the ST_LINK board doesn't have. It shows which pin to connect it to, and is reffed a few times, without a description.Pin header describes it as reserved. Is this skippable too? That SOICbite thing looks perfect. Might go straight to it.
|
|
#
?
May 23, 2020 21:57
|
|
|
karoshi posted:I'm currently (trying) to build an i2s phased array on a breadboard. The bit clock is a pain (1MHZ up to 4 MHZ) and gets horrible munched between the generator and the MEMS microphones and the USB adapter. Make sure your clock and WS/FRAME/LR line is as clean as possible. I still can't get it to work. Breadboards might not be that great for >1MHz signals, specially since the clocks come from another device over 15cm Yeah 1MHz is about the limit for a breadboard according to rule of thumb. Dave from EEVBlog talks about it (in typically long winded fashion) in this video: https://www.youtube.com/watch?v=6GIscUsnlM0 The gist is that a breadboard has a really high stray capacitance compared to, say, a PCB which in turn limits your circuits ability to change fast enough to keep up with faster signals. This is compounded by the fact that it's probably also covered in little antennas from the hookup wires which pick up lots of noise. Working with signals is very difficult without a good oscilloscope (meaning at least the Rigol/Siglent level) and they're unfortunately not exactly inexpensive. Sometimes you might find someone getting rid of an older analog oscilloscope for pennies on the dollar on craigslist or something. These are actually really great I think for understanding what's going on in the circuit because you sort of get to see a raw picture of what's going on and are a great thing to play with for your own education. Unfortunately they're not NEARLY as useful as a modern digital storage oscilloscope (especially for digital signals) because you can't pause the picture and zoom in. This is one of the reasons for test signals like the good ol' SMPTE color bars which produces a repeating signal that you can see more easily on an analog scope. I managed to get myself an Agilent 54622d for ~$150 and I really love it but I had to save a search on eBay and keep an eye out for like 6 months to get it. However, it's also about 20 years old and I had to replace a battery inside that allows it to actually save its settings/calibration and there's a good chance I'll need to replace things like capacitors before too long. It's also massive compared to a modern scope like the Rigol and it has a loud fan, but I used an older HP scope at my first job and love the interface. Another useful tool for understanding what may be going on is playing around in MATLAB (or if you're a cheap bastard like me, GNU Octave) and making simulations. However this is probably only useful if you're already comfortable in these programs or willing to learn. Still, I'm glad to have taken the time to learn because I use Octave all the time now for various things.
|
|
#
?
May 23, 2020 22:02
|
|
|
Dominoes posted:Awesome. So I provide a header for SWDIO, SWCLK, and RST? Great! I noticed on the Discovery ref, the breakout header includes a T_SWO pin too, that the ST_LINK board doesn't have. It shows which pin to connect it to, and is reffed a few times, without a description.Pin header describes it as reserved. Is this skippable too? SWO is for tracing code paths. I'm not really sure, I've never needed it. Skip it. I wouldn't rely solely on the SOICbite first and immediately. Toss the footprint on there if you like, but also put some 0.1" headers, otherwise you'll be making life difficult for yourself for no reason.
|
|
#
?
May 23, 2020 22:07
|
|
|
Awesome. Ordered a clip, the ST-LINK USB board, and will start with the dual approach. Should be able to test the pin connections on the Discovery board once it arrives using the SWT header.
|
|
#
?
May 23, 2020 22:10
|
|
|
yeah unless you're severely cramped for space on the board there's no reason to not just put some 0.1" test points in a block or line somewhere.
|
|
#
?
May 23, 2020 22:17
|
|
|
You can also add the footprint for the headers and just sort of stick the pins in there part way and let it rest at an angle to make temporary contact. I've also heard of people making a custom footprint for the purpose by staggering the pads back and forth slightly to create enough friction to make contact by sticking the pins in there, which would probably work even better. I think in both cases it's more useful for programming boards when you're producing copies rather than having a prototype hooked up to your computer for a couple weeks though.
|
|
#
?
May 23, 2020 22:23
|
|
|
That sounds like a great idea too; going to add that vice the normal layout. Any recommendation on how much to stagger? Going to try with 0.2mm. I figure it'd be hard to get reliable contact with normal headers and no tricks.
Dominoes fucked around with this message at 23:16 on May 23, 2020 |
|
#
?
May 23, 2020 23:12
|
|
|
Dominoes posted:# 1: What's your fav technique for being able to flash the board, but not cluttering it up? Through-holes you can put non-solder headers through temporarily? I just leave the programming connector populated. For my personal boards I defined my own 8 pin 0.5mm pitch FFC connector. I then made some adapter boards that plug into the ST-Link. The connector is small and cheap, and can be put almost anywhere (but preferably on a board edge). They are a bit hard to solder though. Before I used the FFC I used a 6 pin 2 row standard header with one pin removed as a key, that way it was harder to plug it in backwards.
|
|
#
?
May 23, 2020 23:15
|
|
|
There's not a huge size diff for 3 pins - Top: SOICbite. Bottom: 2.54mm staggered.
|
|
#
?
May 23, 2020 23:21
|
|
|
Search "sparkfun staggered headers" or something, pretty sure they were the first ones to do that. You should also add power and ground to that header.
|
|
#
?
May 23, 2020 23:24
|
|
|
Was planning to power and ground from a dev board, or phone charger to reduce the footprint. Is that OK? Looks like the sparkfun headers use a bigger stagger. It also appears that this may be useful for normal use. It's been a minor struggle to get the headers to sit flat before soldering the first pin. Dominoes fucked around with this message at 23:32 on May 23, 2020 |
|
#
?
May 23, 2020 23:26
|
|
|
I usually just use scotch tape to hold parts in place or if it's something like a blue pill style board where there are two single rows that are parallel, stick it in a breadboard to align it and solder it that way.
|
|
#
?
May 23, 2020 23:58
|
|
|
I’m looking for a USB serial adapter to attach to the programming pins (UART?) of an ESP device. It wants 3.3V/GND/TX/RX per https://esphome.io/cookbook/h801.html — is this cable what I want? I’m pretty sure I want TTL serial, but I’m not sure about the FTDI references. Should I get a breakout like this instead? (Whatever I get I’ll get in both 3.3 and 5 variants I think, since it seems like there’s lots of stuff on both sides of that divide.)
|
|
#
?
May 24, 2020 00:30
|
|
|
I'm trying to use this generic USB audio interface https://www.jaycar.com.au/usb2-0-to-3-5mm-audio-converter/p/XC4953 so I can use this headset microphone https://www.amazon.com/Beyerdynamic-COP-Headset-Gear-Microphone/dp/B00DHBVUCQ?th=1 for video conferencing in MacOS and Windows. It says it has a microphone interface, but I believe this is inaccurate. In MacOS the input label reported by the device is just "LINE". Plugging in a line-level source works fine, but my microphone is barely audible and way too low for actual use. I purchased this pre-amplifier https://www.altronics.com.au/p/k6044-champion-pre-amp-kit/ kit hoping it would raise the microphone to line-level. Testing it with my phone's headphone output, it does *work*, so I don't think I have hosed up the construction; at full amplification it noticeably increases the volume coming in from my phone. Unfortunately, it doesn't do anything at all for the microphone, and in fact I can't hear anything at all with the microphone plugged in. According to the Amazon listing the microphone is a "High quality Condenser (back electret) microphone with gooseneck, 20 -20k Hz". I tried reading up on electret microphones but just came away more confused. This is part of the circuit description and diagram from Silicon Chip Magazine which originally published the design. Note that I'm only using the pre-champ side.  quote:Fig.1 shows the complete circuit Naively reading it, it sounds like I could increase the value of the 2.2MΩ resistor to increase the sensitivity of the input? Or is there some fundamental incompatibility using this type of microphone with this type of preamp? It's also very likely I'm in way over my head here and should just buy a better USB audio interface, but I wanted to try and use what I have on hand and maybe learn something in the process. EDIT: I somehow missed this at the end of the magazine article: quote:Microphone bias current Going to give that a shot. EDIT 2: That worked a treat! Going to make a nice box for it all now. Granite Octopus fucked around with this message at 02:33 on May 24, 2020 |
|
#
?
May 24, 2020 00:48
|
|
|
|
| # ? Apr 25, 2024 09:02 |
|
|
Subjunctive posted:I’m looking for a USB serial adapter to attach to the programming pins (UART?) of an ESP device. It wants 3.3V/GND/TX/RX per https://esphome.io/cookbook/h801.html — is this cable what I want? I’m pretty sure I want TTL serial, but I’m not sure about the FTDI references. Should I get a breakout like this instead? (Whatever I get I’ll get in both 3.3 and 5 variants I think, since it seems like there’s lots of stuff on both sides of that divide.) Either will work fine (as long as you set the jumper on the latter to 3.3v). I've got a couple of $3 ebay USB adapters I use that work fine. The breakout has lines for CTS and DTR which I haven't used in arduino stuff but are serial control lines: https://en.wikipedia.org/wiki/RS-232_RTS/CTS#Data_and_control_signals For just programming microcontrollers it shouldn't matter. The only real difference is the breakout will work with 5v devices as well, but you have to provide your own cable and jumper wires to hook it up to the microcontroller.
|
|
#
?
May 24, 2020 01:15
|
|
