|
Chillbro Baggins posted:How much power is wasted in the resistor? I^2 * R Or V^2 / R (this V is power supply minus diode V_f) 
|
#
?
Aug 16, 2020 03:54
|
|
|
|
| # ? Jun 12, 2024 20:43 |
|
|
Chillbro Baggins posted:Can't get a photo (in the words of our favorite Canadian, "FOCUS, YOU FACK!" The proper way to figure out the correct resistor is to look up the specs for the LED, find its nominal forward current, and pick a resistor that will give you that value by Ohm's law. Don't forget to subtract the LED's voltage drop from the supply voltage. If you don't have the specs, you can hook it back up to the AAA battery pack with your multimeter in series, turn it on, and read the current flow as an acceptable substitute.
|
|
#
?
Aug 16, 2020 04:07
|
|
|
What techniques have y'all had success with for removing flux and stray solder after soldering? I've been using isopropyl wipes, but they leave paper fibers all over, visible with a magnifier. I've read of acetone, alcohol, deionized water soaking and sonic approaches, but they seem suited mainly for mass production. What do you use, at small scales?
|
|
#
?
Aug 16, 2020 17:40
|
|
|
Dominoes posted:What do you use, at small scales? Spray bottle with isopropyl. If that isn't working, then spray contact cleaner. I like the stuff from CRC; I think I get it at Autozone.
|
|
#
?
Aug 16, 2020 18:01
|
|
|
Microfiber cloths can be gotten pretty cheaply and don't leave lint behind.
|
|
#
?
Aug 16, 2020 18:10
|
|
|
babyeatingpsychopath posted:Spray bottle with isopropyl. If that isn't working, then spray contact cleaner. I like the stuff from CRC; I think I get it at Autozone. Maybe this goes without saying but It's important to blot or drain off the isopropyl after spraying it on otherwise you dissolve the flux into your alcohol puddle and the puddle dries leaving an even coating of ever-so-slightly conductive flux on the board. I just do that with a paper towel usually (but I'm definitely not the person to ask about making quality boards... I've learned about flux residue's conductivity the hard way.)
|
|
#
?
Aug 16, 2020 18:10
|
|
|
Awesome. Ordered spray isopropyl and microfiber cloths. How do you clean the cloths for re-use? Run under sink water?
|
|
#
?
Aug 16, 2020 18:41
|
|
|
You can wash microfiber in a clothes washing machine, do them seperately from non microfiber. (from car detailing knowledge) At work we use kimwipes e: for real cleaning it's an ultrasonic bath with saponifier then water rinse and air dry taqueso fucked around with this message at 19:19 on Aug 16, 2020 |
|
#
?
Aug 16, 2020 18:51
|
|
|
I use iso alcohol spray, and scrub pretty hard with an old toothbrush. Don't use it on your teeth again after though
|
|
#
?
Aug 16, 2020 19:15
|
|
|
Ideally just get a big tub full of iso to scrub it in. Or use it in an ultrasonic cleaner. Iso can dissolve a lot of flux before saturation, so you can re-use the same iso bath for a long time. After dissolving the flux you can then rinse the board in some fresh iso. Naptha is a better flux dissolver, but it seems to saturate much faster and it's generally more volatile. It's the primary component in professional grade flux cleaners like Vigon EFM. Certain cheap brake cleaner sprays are mostly just naptha, including what my local hardware store sells. I use the spray cans of that for spot cleaning or for cleaning solder joints in wires etc., since it's much faster than using iso. Be aware that naptha is not iso, and it will e.g. (slowly) dissolve polypropylene bottles that are fine for storing iso in. Also note that many brake cleaners contain tons of other solvents (acetone is pretty common), including potentially really bad ones, read the MSDS before using.
|
|
#
?
Aug 16, 2020 19:28
|
|
|
Stack Machine posted:I've been burned this way by a comparator, yes. It was caused by supply noise coupling into the input and looked like a few millivolts offset and I solved it by putting a little capacitance on the input pins. Could have just bought a slower comparator and spared myself the headache. Man this is the poo poo they don't tell you about unless it costs you millions in a redesign.
|
|
#
?
Aug 16, 2020 20:06
|
|
|
Dominoes posted:What techniques have y'all had success with for removing flux and stray solder after soldering? I've been using isopropyl wipes, but they leave paper fibers all over, visible with a magnifier. I've read of acetone, alcohol, deionized water soaking and sonic approaches, but they seem suited mainly for mass production. You shouldn't have stray solder metal and that isn't coming off unless you heat it enough to reflow For flux residue, a little bottle of IPA like these kind and a brush. Pushing down on the top pumps a little bit of IPA into a pool on the top for dipping the brush into. Also, using no-clean flux so that cleaning the residue is cosmetic/so it isn't sticky and not functional.
|
|
#
?
Aug 16, 2020 20:13
|
|
|
Awesome. Added to Digikey cart. I mainly end up with lots of flux from direct application or MG paste. Today had tiny beads of solder after paste+ hot air on a qft. Not sure if the paste was going bad or what. Or if I get messy and need to remove unmelted paste. Should I buy this ultrasonic cleaner? taqueso posted:You can wash microfiber in a clothes washing machine, do them seperately from non microfiber. (from car detailing knowledge) Dominoes fucked around with this message at 21:41 on Aug 16, 2020 |
|
#
?
Aug 16, 2020 20:36
|
|
|
mobby_6kl posted:Thanks! I'm generally curious to learn how it works of course but right now I'm just trying to make a prototype ASAP. There's a function provided in the library for partial refresh, but it's not well documented and crashes when I try it. SPI is such a bait and switch with the pin count. It's never just 4! edit2: Sneaking suspicion after an inspection of the working WaveShare board that I have the FPC pins backward... maybe. Edit again. The board FPC has pin labels. Oh my god. The footprint I'm using is backwards. A closer inspection of the traces confirms it. That's why it doesn't work. The KiCad labeling convention is not the same as the WaveShare one. edit: Unrelated. I'm quickly becoming a fan of QFN packages. (The square ones with pins underneath). Aside from the normal advs like heat management and easier wire routing, I think they're easier to solder, due to no risk of shorts high up on the pins, where solder doesn't flow as readily as on the board surface. Haven't tried them with wire solder yet. Dominoes fucked around with this message at 04:36 on Aug 18, 2020 |
|
#
?
Aug 17, 2020 23:27
|
|
|
Anyone know anywhere to get cable mount RCA jacks like these that doesn't involve shipping from China? As best I can tell they don't exist anymore and I've either gotta harvest them from other cables or stick a F-F adapter on the end of a plug.
Fantastic Foreskin fucked around with this message at 03:38 on Aug 18, 2020 |
|
#
?
Aug 18, 2020 03:21
|
|
|
Some Goon posted:Anyone know anywhere to get cable mount RCA plugs like these that doesn't involve shipping from China? As best I can tell they don't exist anymore and I've either gotta harvest them from other cables or stick a F-F adapter on the end of a jack. I buy mine from Amazon. https://www.amazon.com/Honbay-Solder-Adapter-Connector-Professional/dp/B01FJBA5YU
|
|
#
?
Aug 18, 2020 03:28
|
|
|
Stack Machine posted:I buy mine from Amazon. Ah gently caress, I got my plugs / jacks switched, thats what I get for thinking about plugs and jacks all day. I'm looking for female terminated ones. There's one listing in the 'frequently bought together' part of that page but they look super cheap even for a china special. E: turns out mouser has them and I'm bad at looking. Fantastic Foreskin fucked around with this message at 14:56 on Aug 18, 2020 |
|
#
?
Aug 18, 2020 03:40
|
|
|
Dominoes posted:Tangent: Did you connect that display via FPC to your own circuitry, or does it have a board with a normal SPI (or SPI + extra pins) interface (Labels on right imply latter)? I'm on the struggle bus with getting a similar one working. Ie no signs of life. Realized last iteration I was missing a connection, but have now checked everything on the schematic, and still no success.The WaveShare one with board and SPI+ works. Despite using a manufacturer ref design, I can't get the FPC+own circuit working. Maybe need to add test points to the next design or something. Or could be sloppy soldering on the FPC, but I can't identify any shorts with a magnifier. Sorry about your inverted pinout lol. poo poo happens 
|
|
#
?
Aug 19, 2020 08:59
|
|
|
babyeatingpsychopath posted:you need to buy a pair of arduinos and use the arduino IDE and go through their examples of how serial communication works. C++ code:
|
|
#
?
Aug 19, 2020 12:22
|
|
|
Dominoes posted:I'm grappling with the issue of how the slave listens. Eg: between calls to ArduinoMaster.read(), where does data sent by the Master live? I'm guessing it's a buffer that the SoftwareSerial lib wraps. When does the writing happen? Is there something async going on as well? What if the slave is waiting for interrupt, doing a computation or something while the request is sent, then resumes the loop? The example loop above executes quickly, but there might be computations, a delay etc that would make these questions seem more meaningful. The data lives in a buffer. There's no interrupt going on here. It's all synchronous. The write happens as soon as you call .write(). Your program is doing literally nothing until that write is completed. If you're using hardware serial, the UART has its buffers and the write is very, very fast. It's possible for you to throw a few writes in the buffer before the bits are actually sent out over the wire. When this happens, the program blocks until there's buffer space. Same way on a read. If you read(10) and 8 bytes come through, you're waiting until the next 2 bytes show up. If you're in some kind of deep sleep with the UART turned off, then data can get missed. However, there is an actual interrupt available on hardware rx if you need. https://www.arduino.cc/en/Tutorial/SerialEvent is a great place to look. This is the standard way of receiving long strings of data coming at unpredictable times. You've got some size buffer, and some kind of stop byte. When data comes in, you fill your local buffer. When you receive your stop byte, your interrupt sets a flag and you run off to do whatever it is you're going to do in the main loop, and clear the flag there.
|
|
#
?
Aug 19, 2020 15:09
|
|
|
Thank you! for going over those details. I know find myself this knowledge gap which may be the key to the puzzle. Here is a demonstration of my guess of timeline, which should highlight my problem: 1: Slave initiates the above loop, or a similar one, and continues for a period. 2: Master sends a message at its convenience. (It then eagerly listens for a response, pausing all operations until it receives one. It loads this response into a buffer, and continues. That's all we need to worry about for the master, the mystery lies solely with the slave) 3: As the master sends this signal, a series of high and low voltages across a line that occur quite quickly, the slave is at an arbitrary part of its loop. Perhaps at the end, just prior to going to a short delay, then the top. 4: The slave finishes the delay, hits the top of the loop, then calls read(), at which point it's prepared to store a signal into a buffer. At this point, the signal's already passed. Here lies the essence: How does the slave make sure it's ready at the exact time? Where does the information go before the slave executes code to listen and inert into a buffer? One way is the interrupt approach you describe: Slave is in WFI/WFE, and is woken by a UART/USB etc interrupt. But let's ignore that for now. Perhaps the slave loops must execute so quickly that it completes many iterations in the time between the master's initial transmit bit pulls low (etc) and resets. TF is up with dev boards using weird USB ports. Arduino on B, STM32Disc on mini Dominoes fucked around with this message at 21:31 on Aug 19, 2020 |
|
#
?
Aug 19, 2020 21:20
|
|
|
Depending on the loop delay and UART specifics the UART will have a hardware receive FIFO (buffer) of some size (sometimes just 1 byte, IIRC it's 8 bytes for STM32 UARTs). In that case the slave will probably immediately get the buffered data when it calls read. Otherwise in your case the slave would lose data due to the receive buffer overflowing. A receiver like that realistically has to use an interrupt to receive data, or just stay in the receive part all the time/call read faster than the time it takes to fill the UART receive FIFO. For larger MCUs this case can be handled more elegantly with DMA to memory; the receiver UART data is dumped into RAM as long as the DMA is active. Two issues with setting up a receive DMA are: when the DMA is complete the receiver has to recognize that, process the received data, and restart it before more data arrives. This is solved by using a circular DMA (or a double buffered DMA), for a circular DMA the CPU gets an interrupt when the DMA has filled up either the lower or upper half of the buffer. The receiver can then process that half that was just filled while the DMA writes to the other half. The DMA is never stopped so as long as the receiver can process data fast enough it won't lose any of it. The other issue is: how does the receiver know how big to make the buffer? If the transmitter sends a message that is just short of filling the buffer (or half-buffer) then that will just sit there until the next time it transmits and the DMA generates an interrupt. There's no way to know how old that data is when the interrupt triggers. This can be solved several ways, but when available a UART Idle Interrupt can be used to detect when the line is idle for some (short) time, when that interrupt triggers the code has to know what buffer index it was at last time one of the interrupts fired and process from there to where the DMA is currently at. I've done this a few times using this example code for STM32: https://stm32f4-discovery.net/2017/07/stm32-tutorial-efficiently-receive-uart-data-using-dma/ This DMA uses fewer resources than interrupting for every byte, especially if there's a lot of bursty traffic on the line. I usually implement my message framer in the interrupt handler and then just use flags or message queues (when I have an OS) to tell the main process that a packet has been received and can be processed.
|
|
#
?
Aug 19, 2020 21:38
|
|
|
Dominoes posted:Thank you! for going over those details. I know find myself this knowledge gap which may be the key to the puzzle. Here is a demonstration of my guess of timeline, which should highlight my problem: Read at least the high-level parts of the UART chapter of the STM32 reference manual to know what the peripheral is capable of doing. The UART hardware is physically separate from the processor core and runs independently and simultaneously. The processor talks to it via memory addresses that are actually registers in the UART. There are two 1-byte registers visible to the core, one for transmit and one for receive. As data is received, the UART shifts the received bits into an internal shift register. Once it has accumulated a full byte, it will copy into the CPU-visible RX register, setting an overflow flag if nothing has read that register since the last time it was written. You must make sure the previous byte was read out before a new one arrives. Options are: 1) Check it frequently enough in normal code. Serial is often slow. A byte at 57600 baud takes 140us to arrive. If you are running at a fast processor clock rate, you could have a main loop that runs every 125us and it won't ever overflow. 2) Have the UART trigger an interrupt every time it has collected a new byte. The ISR reads the byte from the UART register and puts it somewhere else to deal with later 3) Have the UART trigger a DMA event every time it has collected a new byte. The DMA hardware reads the byte from the UART register and puts it somewhere else to deal with later longview posted:This is solved by using a circular DMA (or a double buffered DMA), for a circular DMA the CPU gets an interrupt when the DMA has filled up either the lower or upper half of the buffer. The receiver can then process that half that was just filled while the DMA writes to the other half. The DMA is never stopped so as long as the receiver can process data fast enough it won't lose any of it. On a STM32, you don't need to do this. The DMA hardware exposes the number of items remaining to transfer, so you can have it constantly copying into a circle and then have your main loop process all newly received bytes. Foxfire_ fucked around with this message at 23:52 on Aug 19, 2020 |
|
#
?
Aug 19, 2020 23:48
|
|
|
Dudes, thank you. It sounds like a summary of the solution is the independent hardware receiver buffer, in combination with a fast poll rate, or perhaps interrupts. (I mentioned I'm working on a Rust STM32F3 interrupt lib, but haven't set it up for comms interrupts yet) Going to give this a shot later over UART, USB, and RS485 hardware permitting. (Can do STM dev to arduino with jumpers for UART, but need a mini to C cable for USB, and a board I'm about to order for 485) DMA is something I've heard about a number of times in manuals and examples, but haven't dove into yet. Can't find that section in the STM32F3 ref man. (It mentions UART many times, but mostly in terms of register ref). I suspect there's a standalone STM32 serial comms doc, or something. Dominoes fucked around with this message at 01:31 on Aug 20, 2020 |
|
#
?
Aug 20, 2020 01:25
|
|
|
UART and USART and EUSART are (usually) synonymous terms you'll see. You don't need the 485 board for initial testing / programming, as long as your controller and peripheral boards are sitting next to each other. Then drop in the boards at the end and it should still work.
|
|
#
?
Aug 20, 2020 01:33
|
|
|
STM32F3 reference manual chapter 29 You are probably looking at the datasheet for a specific chip. That will only have chip-specific information (pinouts, electrical characteristics, which peripherals exist and how they mapped into memory addreses, etc...). The reference manuals will talk about how the family works. USART = Universal Synchronous/Asynchronous Receiver Transmitter. The hardware can do synchronous things as well, for RS232/RS422 you are using it in asynchronous mode (no separate clock line).
|
|
#
?
Aug 20, 2020 01:59
|
|
|
Oh poo poo! Nailed it on the missing USART in ctrl+F and not checking TOC. Thank you. I noticed the USART/UART distinction when trying to find the right pins, but didn't dive deeper. Good info on ref man vice datasheet - I find the ref man more useful in general, and that's a clear description of when to look in one vice the other. Re 485: Guess I forgot our earlier chat about protocols vs transmission. edit: Setting up UART on dev boards may not be so simple. Through a psychological bias or spatial-temporal anomaly, all the jumper wires are the wrong type, despite being purchased in equal quantities. I suspect the female-female ones are located near the pens and singleton socks. Dominoes fucked around with this message at 03:12 on Aug 20, 2020 |
|
#
?
Aug 20, 2020 02:14
|
|
|
The STM32 data sheets and RMs are well indexed and have an actual PDF TOC. Not sure what viewers actually support the TOC but I know Adobe does and and Chrome/Edge don't seem to.
|
|
#
?
Aug 20, 2020 12:46
|
|
|
Confirming Edge doesn't.
|
|
#
?
Aug 20, 2020 15:57
|
|
|
Chrome does actually, it's this button:
|
|
#
?
Aug 20, 2020 16:21
|
|
|
Foxfire_ posted:On a STM32, you don't need to do this. The DMA hardware exposes the number of items remaining to transfer, so you can have it constantly copying into a circle and then have your main loop process all newly received bytes. Good to know! I might try that next time
|
|
#
?
Aug 20, 2020 16:45
|
|
|
Shame Boy posted:Chrome does actually, it's this button: This changes everything.
|
|
#
?
Aug 20, 2020 17:40
|
|
|
Rust bros: Check out probe-run. It's a tool for running embedded code in debug mode, eg with printing-to-console and panics. Released a few days ago. Cleaner workflow than openocd/itm etc. I was able to remove my script that ran the super-long open ocd run command, and no longer need 2 sep terminals. You run cargo install probe-run, set up .cargo/config to look like this, modified for your chip: TOML code:quote:RTT implements input and output to/from a debug probe using in-memory ring buffers and memory polling. This enables debug logging from the microcontroller with minimal delays and no blocking, making it usable even in real-time applications where e.g. semihosting delays cannot be tolerated. Dominoes fucked around with this message at 23:52 on Aug 20, 2020 |
|
#
?
Aug 20, 2020 23:37
|
|
|
Hey thread, got a weird question. Might be just an exercise in curiosity, or I might be interested in trying to make something. I just picked up a game I'm really enjoying called 'RUINER' which has a big cyberpunk aesthetic to it, and the protagonist has a mask/helmet that basically displays video. https://i.imgur.com/hsjFoEd.gifv I got to wondering if a practical [working] version of this could be made. I've been digging throughout the morning and I've seen a bunch of options, but I'm wondering if there's anything else out there I'm unaware of. Looks like you could try... RGB LED Matrix panels - Something like this from Adafruit, maybe? It's flexible, so you could probably conform it to the inside of a mask, in theory. You'd probably have to find one -just- the right size to make it work, and even then, the gaps between the pixels look like they'd be doing a low-res scrolling-sign version of the graphics. In a similar vein, this also looks interesting as a paper-thin color LED matrix option, looks a little tighter packed together. Flexible OLED displays - These still seem pretty nascent technology? Adafruit showed off a sample playing Blade Runner a few days ago, but they don't look like they're widely available anywhere. Ali Express has something similar for a hefty $435. Edit: I saw this transparent OLED display on Sparkfun and got excited because it looked promising, but then I learned it has fixed color areas and fixed display counters, so you can't reproduce other graphics on it. I know nothing is going to match the fictional mask, and any option to reproduce it would involve compromises. For instance, I can imagine a static display version of the mask that sits on a shelf with a projector hitting it, instead. I'm just curious if there's anything else I missed. Harvey Baldman fucked around with this message at 20:27 on Aug 21, 2020 |
|
#
?
Aug 21, 2020 20:22
|
|
|
Harvey Baldman posted:I know nothing is going to match the fictional mask, and any option to reproduce it would involve compromises. For instance, I can imagine a static display version of the mask that sits on a shelf with a projector hitting it, instead. I'm just curious if there's anything else I missed. I mean even in the video you posted it kinda looks like it's a projector shining on it, so I think that's going to be the best-looking effect tbh. If you wanted it to be portable you could get one of those tiny battery-powered mini-projectors that run android and just carry it around with you and shoot it at your face  e: If you wanna be extra fancy, rig up some sort of head tracking so the projector image can follow your head and map onto it correctly!
|
|
#
?
Aug 22, 2020 00:31
|
|
|
Shame Boy posted:I mean even in the video you posted it kinda looks like it's a projector shining on it, so I think that's going to be the best-looking effect tbh. If you wanted it to be portable you could get one of those tiny battery-powered mini-projectors that run android and just carry it around with you and shoot it at your face Or just put a pico projector on a selfie stick
|
|
#
?
Aug 22, 2020 00:49
|
|
|
The idea of a projector like that on a selfie stick is tempting, actually. I have absolutely no idea how you'd go about doing any sort of head tracking, but as long as the projector was in the same relative spot to the mask I wager it could work. The only other idea I've had lately is to maybe get some of those 144leds/m dense strips and try laying them up so they partially overlap, and then using something like this matrix mapping generator to help get the non-rectangular layout worked out, but I know that's a ton of work and the power and computational requirements for that would be stupid.
|
|
#
?
Aug 22, 2020 01:29
|
|
|
For maximum danger you could do this:
|
|
#
?
Aug 22, 2020 03:02
|
|
|
Projectors to the face remind me of these projects: https://www.youtube.com/watch?v=D-b23eyyUCo https://www.youtube.com/watch?v=WefSub8qesQ
|
|
#
?
Aug 22, 2020 03:16
|
|
|
|
| # ? Jun 12, 2024 20:43 |
|
|
Trabisnikof posted:For maximum danger you could do this: This thing intrigues me and now I'm trying to find a slip ring rated to a high enough RPM that a 1D LED array gives a reasonable resolution e: maybe - Big battery on the hat powering the motor - Rotor made out of a strip of PCB - Pair of coin cells close to the rotor axis to power LEDs, microcontroller, and encoder reading the shaft angle Foxfire_ fucked around with this message at 06:12 on Aug 22, 2020 |
|
#
?
Aug 22, 2020 06:00
|
|