|
Yeah that approach is fine, though blowing away the part can be annoying. Worth noting that it'll damage most LEDs though.
|
#
?
Apr 23, 2018 17:33
|
|
|
|
| # ? May 20, 2024 02:49 |
|
|
Splode posted:That's what I thought until my current workplace showed me how. My hands have a fair amount of twitch in em' and sometimes will decide they need to suddenly jerk whatever tool I'm using a couple mm while I'm trying to place something, so 0805 has been the smallest thing I've been able to reliably place even using the heat gun, so I guess I'm a bit biased 
|
|
#
?
Apr 23, 2018 17:37
|
|
|
Splode posted:Yeah that approach is fine, though blowing away the part can be annoying. Worth noting that it'll damage most LEDs though. I melted a bunch of LED's until I realized I had my heat gun up way too high, you only need it at around 180C max to get the solder to melt and at that heat the LED's don't even discolor or anything. You still gotta turn the speed way down so you don't blow them away though, yeah e: Note that this only applies to LED's specifically designed to be surface mounted and reflowed, it will absolutely melt any through-hole LED nearby the part you're working on even with lower temperatures Shame Boy fucked around with this message at 17:41 on Apr 23, 2018 |
|
#
?
Apr 23, 2018 17:39
|
|
|
Speaking of SMD stuff, I want to buy a whole crapload of SMD passives so I can start making smaller boards than the through-hole stuff I currently use. Is 0805 a reasonable all-around size for hand assembly or should I go up to 1206? I've repaired surface-mount things before but never assembled a board with predominantly SMD components before so I dunno.
|
|
#
?
Apr 23, 2018 18:51
|
|
|
Sagebrush posted:Speaking of SMD stuff, I want to buy a whole crapload of SMD passives so I can start making smaller boards than the through-hole stuff I currently use. Is 0805 a reasonable all-around size for hand assembly or should I go up to 1206? In general, I find 0805 to be a reasonable compromise between reworkability/hand assembly and footprint size. 0603 is even pretty doable in a pinch, if your board is getting too crowded. Then again, if you have the board space, larger caps will have higher reliability, and larger resistors will handle more power, so if you don't have a size constraint, treat yo self. Lastly, depending on what you mean by "a whole crapload," I've had manufacturers reach out to me in the past offering sample binders for free, just to get their parts into designs. That might be worth looking into.
|
|
#
?
Apr 23, 2018 19:42
|
|
|
Sagebrush posted:Speaking of SMD stuff, I want to buy a whole crapload of SMD passives so I can start making smaller boards than the through-hole stuff I currently use. Is 0805 a reasonable all-around size for hand assembly or should I go up to 1206? by "hand assembly" do you mean soldering with an iron or with paste+hot air? i personally wouldn't go smaller than 0805 with an iron, but with paste+air 0603 is pretty easy if you have good eyesight.
|
|
#
?
Apr 23, 2018 19:49
|
|
|
Sagebrush posted:Speaking of SMD stuff, I want to buy a whole crapload of SMD passives so I can start making smaller boards than the through-hole stuff I currently use. Is 0805 a reasonable all-around size for hand assembly or should I go up to 1206? I went through this a while back and settled on 0805 and haven't had any problems (0805 seems to be the internet consensus). If you don't have manufacturer hookups, definitely buy a little binder to store them; it may even be worthwhile to buy a presorted/prearranged binder set. I balked at the markup so bought the components and binder separately, but it was hell trying to read the microscopic markings to sort them. Might be a good idea to pick up some LEDs too.
|
|
#
?
Apr 23, 2018 19:57
|
|
|
Yeah 0805 is my preferred size. See if you can get a design kit.
|
|
#
?
Apr 23, 2018 22:11
|
|
|
Sagebrush posted:Speaking of SMD stuff, I want to buy a whole crapload of SMD passives so I can start making smaller boards than the through-hole stuff I currently use. Is 0805 a reasonable all-around size for hand assembly or should I go up to 1206? When I first got into SMD stuff I bought a big bag of every value of 1206 resistors thinking "gosh that's so small it's probably all I'll ever need!" and within like a week regretted it because compared to everything else on the board they're huge. Now I never use them if I can help it because 0805 is much better - tends to fit the scale of everything else better, doesn't take up as much space, still reasonable to solder etc. For random active components (single opamps, transistors, etc) my new favorite package is SOT-23 and it's 5, 6 and 8 pin variants - it's just large enough to solder reasonably consistently (using the heat gun and solder paste method, haven't tried with an actual iron) and to have its pads come out usable when etching my own boards, but still so tiny that it barely takes up any space at all. Shame Boy fucked around with this message at 22:19 on Apr 23, 2018 |
|
#
?
Apr 23, 2018 22:15
|
|
|
1206 and up can be more expensive too due to nobody in industry using them very often
|
|
#
?
Apr 23, 2018 22:19
|
|
|
I've standardised my kit on 0603. I can hand solder them without a magnifying glass, although that helps. I find I need to drink a beer if it's evening and on my own time, or skip the coffee on work soldering mornings. I don't do an entire board though, I'll just solderpaste and reflow it if that's the goal.
|
|
#
?
Apr 23, 2018 22:33
|
|
|
Holy crap digikey is pretty awesome for Canadians - $8 shipped fedex priority overnight with no additional customs hassle (and free shipping over $100). Same day shipping if you get your order in before 8CST. I think mouser charges $20.
|
|
#
?
Apr 24, 2018 04:38
|
|
|
Yeah, as a Canadian Digikey has really spoiled me as far as shipping times and cost.
|
|
#
?
Apr 24, 2018 09:26
|
|
|
I have a stupid, naive question regarding filters in a differential system. I'm working with an RS-485 link and came across this excellent article, where they discuss differential filter construction: http://www.analog.com/en/technical-articles/understanding-and-designing-differential-filters-for-communications-systems.html however I'm confused by what exactly the difference is between constructing a "single" differential filter vs. a single-ended filter on each line. Or, indeed both? edit: I'm asking because I've inherited a design in which there is a single-ended filter on each line and now I'm wondering why, and if I should be redesigning this thing for differential filtering instead.
|
|
#
?
Apr 24, 2018 13:36
|
|
|
C'mon my goon dudes, I need some help here.
|
|
#
?
Apr 26, 2018 13:13
|
|
|
Cyril Sneer posted:C'mon my goon dudes, I need some help here. Wish I could help, but you're basically asking about another designer's intent, and I'm not knowledgeable enough to know a reason that might have been explicitly chosen. Intuitively, it seems like the differential filter is just an optimized version of two single filters (referencing to each other instead of ground is more relevant and cleaner), so it may just be a case of "this is how I learned it and it's always worked fine." Or maybe ground is important to this circuit in a way that's not typical or obvious, despite the fact that it's differential. Maybe ESD protection means you'd have to reference to ground? I'm out of my depth, but I didn't want to leave you completely hanging. If someone else knows better, definitely take their advice over mine.
|
|
#
?
Apr 26, 2018 18:29
|
|
|
With differential signals you always want a balanced filter, balanced filter meaning equal input impedance to ground and between the differential lines. I can't fully explain why fully balanced filters with no ground connection are better in the case of the ADI article, but that article is dealing with filtering signals as part of a processing chain. Their primary focus other than selling you fancy parts is minimizing noise and distortion. Normally for signals inside a single PCB with a solid ground plane you don't need differential filtering unless you have very strict signal integrity requirements like a modern radio transceiver. Your RS-485 link is a bit different since it's an external signal, with different considerations, especially relating to common mode vs. differential filtering. You also need to consider the input voltage range; normally -7/+12V to ground on either line for RS-422/485. Also keep in mind that for EU EMC testing you'd often inject 10V peak-peak of common mode RF in the ~30-90 MHz range as part of testing with a hard requirement that this not cause any issues (this simulates a VHF band TV transmitter). Before I continue, you should look up common mode vs. differential if you're not comfortable with the concept, and you also must be aware of mode conversion in differential signalling. To explain it by example: Consider an unbalanced audio connection between a lovely laptop and a fancy grounded amplifier. The laptop is grounded to the wall through the DC return on the power cord, and it pulls AC current due to switching regulators and the variable load of a CPU. When you plug in the audio cord between the devices, the laptops ground return current has a parallel way back to the charger which due to IR drops in the cable shield will cause a potential difference between the laptop ground and the amplifier ground. The laptop generates a clean audio signal relative to the ground of the laptop, and since the amplifier grounds the shield it sees the signal the laptop made added with the voltage drop of the audio cable shield between the laptop and amplifier. This is basically mode conversion at low frequencies. If you use a differential receiver or transformer in the amplifier and connect that between the signal and ground of the laptop instead of grounding the audio ground in the amplifier, it will reject the ground potential difference (common mode) by only looking at the voltage difference. This applies all over for differential signals even at RF; by having an unbalanced input you convert a common mode voltage to a differential one. For a functioning RS-485 link almost all your noise is common mode, not differential mode (provided you don't cause mode conversion by say grounding out one side of the link somewhere or make an unbalanced filter). If you use a RC filter on the RS-485 lines to ground at each node this will affect the common mode and differential mode noise about the same. As long as the signaling rate is fairly low compared to the expected noise frequencies that works just fine (conducted susceptibility testing usually covers 100 kHz-30 MHz) . The ideal component to deal with common mode noise is the common mode choke, which can be used to reject common mode noise down to very low frequencies while allowing differential mode signals to pass at far higher frequencies (a typical signal choke might be 90-600 ohm common mode impedance at 100 MHz with less than a few Ohms differential mode impedance). If you can afford it and need speed a common filter topology for differential filters is a common mode choke with equal low value capacitors to ground for each line. To properly design a line filter for differential signals you also need to consider things like the common mode voltage range, and rejection vs. frequency for the specific line receiver IC you're using (most differential receivers are pretty good at lower frequency rejection so your filter can be crummier there). You also might need to consider the input impedance of the filter; sticking a huge cap to ground on a slow input will remove noise, but a powerful aggressor signal could drive enough current into it to destroy it. A final warning on filter design: for the love of god, don't put clamping diodes/any semiconductor before at least the first stage input filter. They can act as rectifiers for injected RF which can then pass through low pass filters. This is very important in the US where some people live near high power AM transmitters.
|
|
#
?
Apr 26, 2018 19:41
|
|
|
Awesome, thanks for the reply. Lots to wrap my head around though. The situation here is one in which we're bringing the RS-485 from a noisy environment into a clean one. The lines, contained in an external cable bundle as twisted pairs, connect to a shielded box wherein this filter module lives, and after the filter, continue to a board connector. The filters are high-order lowpass filters. For this application its important to "eliminate" any energy above ~20 MHz, so that's what the filters are ostensibly for. The signalling rate is quite low so its not a problem.
|
|
#
?
Apr 27, 2018 12:48
|
|
|
I'm laying out a board with a bunch of analog stuff and a few fairly rapidly switching digital signals kinda nearby. I've made the bottom layer entirely ground plane, and put a ground plane on the top layer too to surround as much of the analog stuff as I can. The analog side runs off a separate low-noise LDO and has lots of bypassing with different sizes and dielectrics of capacitor. I've also stitched together the two planes all over the place so I don't get any inadvertent loops on the top layer (and also I find it weirdly relaxing to do in kicad since you have to lay out each individual via manually, so it's like crocheting sorta???) Anything else I should consider? I've never really done a board with a lot of analog stuff on it before so I'm kinda massively over-designing this. Will all this via stitching come back to bite me in the rear end somehow? I don't think the added stray capacitance will be that much of a problem since the fastest signal is only around a couple MHz and I've put it off to one side along a short track. The only other thing I can think of is that it will make it a pain to solder due to the heat sinking, but I can handle that.
|
|
#
?
Apr 27, 2018 14:36
|
|
|
Via stitching is normal, all the boards I work on have it. Stuff you've done sounds right to me, remember to check your top ground plane is well connected everywhere and not forming an antenna anywhere.
|
|
#
?
Apr 27, 2018 15:04
|
|
|
Splode posted:Via stitching is normal, all the boards I work on have it. Great, thanks. Never really did it before and wasn't sure if it was one of those things that's great to use in some situations but has hidden drawbacks that prevents you from using it in others. I guess it weakens the mechanical strength of the board? That's all I can think of 
|
|
#
?
Apr 27, 2018 15:11
|
|
|
ate all the Oreos posted:Great, thanks. Never really did it before and wasn't sure if it was one of those things that's great to use in some situations but has hidden drawbacks that prevents you from using it in others. I guess it weakens the mechanical strength of the board? That's all I can think of I'm told by the old engineers that in the bad old days pcb manufacturers charged per via, so that was a major downside. Only other downside is the one you identified already: thermal issues when soldering grounds. This can be dealt with but I'm not sure exactly how myself yet, I'll ask the Expert at work on Monday.
|
|
#
?
Apr 27, 2018 23:43
|
|
|
The board I designed for the radiation detector for my thesis had 2 ground planes, and the weak signals sandwiched between those planes also had a ground fill surrounding them. It works very well in practice but soldering the through hole parts on it was crazy even with thermals on the holes because the entire board was a massive heat sink. The entire board warmed up before the pad got hot enough for soldering.
|
|
#
?
Apr 27, 2018 23:48
|
|
|
ate all the Oreos posted:Great, thanks. Never really did it before and wasn't sure if it was one of those things that's great to use in some situations but has hidden drawbacks that prevents you from using it in others. I guess it weakens the mechanical strength of the board? That's all I can think of I've never heard of via stitching causing mechanical issues with any board, even ones that have literally hundreds of drill hits and look like swiss cheese. A lot of RF boards have vias every 100 mils or more.
|
|
#
?
Apr 28, 2018 03:07
|
|
|
Cyril Sneer posted:Awesome, thanks for the reply. Lots to wrap my head around though. That sounds like a pretty good system design, dedicated filter modules for subsystems can work really well. You can simulate the performance pretty easily in tools like LTSpice if you're concerned/interested in the performance. Splode posted:Only other downside is the one you identified already: thermal issues when soldering grounds. This can be dealt with but I'm not sure exactly how myself yet, I'll ask the Expert at work on Monday. You need to add thermal relief, basically around a pad/hole you disconnect it from the plane in a circle and draw an X over the hole, or some other way to provide a higher thermal impedance to the plane around it. Any PCB editor worth using can do it automatically (and many are configured out of the box to do it). Some examples here: https://electronics.stackexchange.com/questions/266129/adding-multiple-thermal-relief-spokes-to-a-large-pad-in-mentor-pads The amount of relief is usually agreed upon with the PCA manufacturer. They're sometimes not possible to use since they obviously increase the electrical impedance to the plane as well. For multi-layer boards it's considered best practice for assembly to only connect through hole pins to ground (or other internal planes) on the solder side outer layer. Otherwise for a 16 layer board you might get the thermal relief to a ground plane on 4-8 internal layers that also have ground planes, making it much harder to solder. That's also sometimes not possible due to electrical requirements.
|
|
#
?
Apr 28, 2018 08:18
|
|
|
ate all the Oreos posted:I'm laying out a board with a bunch of analog stuff and a few fairly rapidly switching digital signals kinda nearby. I've made the bottom layer entirely ground plane, and put a ground plane on the top layer too to surround as much of the analog stuff as I can. The analog side runs off a separate low-noise LDO and has lots of bypassing with different sizes and dielectrics of capacitor. I've also stitched together the two planes all over the place so I don't get any inadvertent loops on the top layer (and also I find it weirdly relaxing to do in kicad since you have to lay out each individual via manually, so it's like crocheting sorta???) Consider where all your return current is going to flow in the ground plane and make sure none of the digital return paths cross the analog parts. The AC return current will flow underneath the outgoing trace if it can. Splitting the ground planes is pretty unnecessary if the layout is good. No current will want to flow between the sections anyway. Unless you told it different, Kicad defaults to putting thermal relief on all your pads, so that should be okay. Foxfire_ fucked around with this message at 10:18 on Apr 28, 2018 |
|
#
?
Apr 28, 2018 10:16
|
|
|
Foxfire_ posted:Consider where all your return current is going to flow in the ground plane and make sure none of the digital return paths cross the analog parts. The AC return current will flow underneath the outgoing trace if it can. Splitting the ground planes is pretty unnecessary if the layout is good. No current will want to flow between the sections anyway. Yeah all the digital or fast-switching bits are separated from the analog bits and current should find its way back to ground without crossing the analog part, so I should be good. I didn't actually know this was recommended but did it anyway because I figured "well if I can keep the, uh, bad electrons away from the good electrons, why not..." Foxfire_ posted:Unless you told it different, Kicad defaults to putting thermal relief on all your pads, so that should be okay. Almost everything has thermal reliefs, though a couple large transistors that I expect to need extra heat-sinking don't. I've soldered stuff like that before though so I think I'll be fine.
|
|
#
?
Apr 29, 2018 02:15
|
|
|
Yeah I know about thermal reliefs, but I've soldered a lot of boards where it was completely inadequate.
|
|
#
?
Apr 29, 2018 09:01
|
|
|
Splode posted:Yeah I know about thermal reliefs, but I've soldered a lot of boards where it was completely inadequate. This. I have boards that sink so much heat at my job now that we need to preheat them on a hot plate to do any rework. And even then, we sometimes need to use hot air and an iron.
|
|
#
?
Apr 29, 2018 16:26
|
|
|
Got a couple quick questions that I couldn't really get clear answers from via google, hoping someone here has an inkling or can at least point me in the right direction. For my project I'm trying to build an extremely pared down DJ controller. DJ controllers are typically MIDI boxes that send some analog/digital data to DJ software on an adjacent laptop/computer. What I'm focusing on is not to build a full controller but rather one with just a few components but with a serious emphasis on getting the latency and jitter as low as possible. As far as physical components that I'm trying to replicate, my controller is only going to house a few Sanwa-style momentary arcade buttons and 1 'jog-wheel'. The jogwheel is the complicated part but when I thought about it in more detail none of these components are analog - the buttons are obviously digital, but in reality so is the jogwheel since it is a combination capacitive button and incremental radial encoder (AB phases 00, 01, 11, 10). So really I don't *need* MIDI since I'll only ever be passing digital values on to the intended DJ software. Which leads to the first question - what's the best board and input format to use to get the lowest latency? I found a few interesting articles that seemed to point to Teensy as a good, low-latency board - but it seems like newer versions of Teensy have appeared since the article was written (and likely Arduino models as well) so I'm at a loss as to which board to even pick. Then as far as format I was curious about shying away from MIDI and trying for something like emulating a keyboard - I've verified that everything I'm trying to do with the DJ software can be done with keyboard presses, but when I googled about keyboard vs MIDI latency there weren't really any clear results, and in fact MIDI seemed to have the edge due to better drivers that can have sampling rate and sampling size customized (i.e. in their testing a MIDI driver set down to 32/64 samples was faster latency-wise than their board emulating a mouse, presumably due to polling rate on the computer end). Second question is a little more straightforward - how do jogwheels work exactly? I get that they are a metal disk affixed to the shaft of a radial incremental encoder - which generates 1 'pulse' (represented as 4 AB phases) when it is rotated a certain distance - the direction in which it cycles through the 4 phases also lets the device know if it was rotated clockwise or counterclockwise. I *also* get that the top surface of a jogwheel is some sort of capacitive button - when the DJ touches the top of the jogwheel that button is pressed - letting the DJ software know to halt the virtual vinyl - and when the DJ lets go of the jog wheel the button is released and the DJ software starts the record again. My question though is how do you get both of these working on 1 metal disc that can rotate freely in either direction? It seems like the free spinning operation of the encoder would interfere with wiring the capacitive button. Is there some sort of 'floating' connection that can be affixed to the shaft of the encoder that would measure the capacitance of the shaft+disk (assuming both are metal and joined together well enough to form a 'connection')? Am I mistaken that jogwheels are not actually capacitive buttons?
|
|
#
?
May 1, 2018 23:00
|
|
|
A floating connection would be fairly trivial; encoders already use brushes for the AB phases.
|
|
#
?
May 2, 2018 00:23
|
|
|
Super Rad posted:Got a couple quick questions that I couldn't really get clear answers from via google, hoping someone here has an inkling or can at least point me in the right direction. When you say "keyboard" I assume you mean typing keyboard and not musical keyboard, right? Emulating one of those is prooobably not the lowest-latency option since you're at the whims of the operating system's built-in keyboard drivers, which aren't exactly designed for music use or built down to lowest possible latencies. MIDI's probably gonna be your best bet, just because it's designed to do what you're trying to do already. If you're doing all this in software via USB, you could always make two different copies of your program and see which you like better. The teensy is a good choice because it's really overpowered as far as tiny little controller boards go. Newer versions should work with source code written for older versions, but some things might need to be changed (like pin numbers, etc.) I know the oldest version of the Teensy used a completely different chip and architecture from the modern version, so the changes required might be significant, but the latest version is also even faster and more powerful so it's worth it imo. What version of the Teensy did the guide you mentioned say it required? Super Rad posted:Second question is a little more straightforward - how do jogwheels work exactly? I get that they are a metal disk affixed to the shaft of a radial incremental encoder - which generates 1 'pulse' (represented as 4 AB phases) when it is rotated a certain distance - the direction in which it cycles through the 4 phases also lets the device know if it was rotated clockwise or counterclockwise. I *also* get that the top surface of a jogwheel is some sort of capacitive button - when the DJ touches the top of the jogwheel that button is pressed - letting the DJ software know to halt the virtual vinyl - and when the DJ lets go of the jog wheel the button is released and the DJ software starts the record again. My question though is how do you get both of these working on 1 metal disc that can rotate freely in either direction? It seems like the free spinning operation of the encoder would interfere with wiring the capacitive button. Is there some sort of 'floating' connection that can be affixed to the shaft of the encoder that would measure the capacitance of the shaft+disk (assuming both are metal and joined together well enough to form a 'connection')? Am I mistaken that jogwheels are not actually capacitive buttons? Capacitive touch switches that don't need to know precisely where you touched (like a touch screen would) are actually fairly simple electronically, so even something like a brush would work fine for it. I bet you could also do something without electrically connecting to the wheel at all since you're measuring capacitance, but I'm not sure how that would go together
|
|
#
?
May 2, 2018 03:35
|
|
|
How much latency do you believe is noticeable? USB MIDI latency vs keyboard is unlikely to actually be noticeable by humans What input can your DJ software actually take? Being a USB MIDI device is a not-insignificant amount of software. Being a USB HID device (mouse/keyboard) is easier, but still a lot of work to handle enumeration to the OS. Easiest way to attach via USB is with a FTDI chip emulating a serial port, but you would need to make your DJ software actually react to the serial port. Semi-comedy option since you mentioned that normal keyboards work as triggers: PS/2 keyboards are not horribly complex to implement, so that would work if your motherboard has a connector. Or run it through a PS/2 to USB converter (will introduce latency, but you probably actually don't care)
|
|
#
?
May 2, 2018 05:58
|
|
|
Foxfire_ posted:How much latency do you believe is noticeable? USB MIDI latency vs keyboard is unlikely to actually be noticeable by humans I never thought this mattered until I looked into music production a bit, but low latency is very important. Each different step you run your instrument or tool or w/e through adds its own little bit of delay, and they add up quick. Add enough effects or processing steps and pretty soon you've got enough time between you doing something and the result coming out of your speakers that it begins to screw you up mentally. People are a lot more sensitive to something with a repeating pattern being subtly off than they are to something like a keystroke rendering a character 50ms too late.
|
|
#
?
May 2, 2018 06:55
|
|
|
ate all the Oreos posted:When you say "keyboard" I assume you mean typing keyboard and not musical keyboard, right? Emulating one of those is prooobably not the lowest-latency option since you're at the whims of the operating system's built-in keyboard drivers, which aren't exactly designed for music use or built down to lowest possible latencies. MIDI's probably gonna be your best bet, just because it's designed to do what you're trying to do already. If you're doing all this in software via USB, you could always make two different copies of your program and see which you like better. It was an academic paper comparing the latency between an Arduino Uno, and Teensy 2.0 plugged into a Mac, the paper also compared using Puredata/Portaudio vs MSP, and then compared everything to running sound internally from a Pi (not applicable in my case, sadly). In any case I'm planning to do this through windows so I'd need an ASIO driver, I'm guessing I have to hack it with ASIO4ALL/Focusrite(?) unless there's a dedicated ASIO driver for any of the more powerful Arduino/Teensy boards, which I don't see. I'm thinking of using a teensy 3.5/3.6 since the rotary encoder I'm getting has 4096 positions, moving the platter quickly back and forth might require polling those pins at upwards of 20khz. Throw polling the capacitive touch switch and the momentary switches, and the decoding logic on top of all of that and it's quite possible the extra clockrate will be needed to make sure no state transitions are dropped. I'm leaning towards the Teensy 3.5 since it can tolerate 5V, and I'd be able to use the same Vcc for the encoder which operates at 5V minimum (not sure if that's optimistic to get a tolerable 5V to the teensy while also getting an acceptable 5V to the encoder). ate all the Oreos posted:Capacitive touch switches that don't need to know precisely where you touched (like a touch screen would) are actually fairly simple electronically, so even something like a brush would work fine for it. I bet you could also do something without electrically connecting to the wheel at all since you're measuring capacitance, but I'm not sure how that would go together Thanks for the correction - I've been reading up on it more and I'll have to experiment with a pair of brushes and see if I can have them contact on the shaft. Would be really nice to keep the brushes in the project box. Rather than checking for capacitance directly I'm just going to use the teensy to measure the RC delay. If you can find any examples of wireless measurement I'd love to see those, just to keep all the options in mind. Foxfire_ posted:How much latency do you believe is noticeable? USB MIDI latency vs keyboard is unlikely to actually be noticeable by humans I'm looking for <10ms total if possible, but really there's no such thing as too low here - the goal is to have it feel as close to an actual turntable as possible and apparently delay in percussion can be noticed up to 5-6ms if the bpm is high enough, so it's definitely perceptible. The DJ software accepts keyboard/mouse/MIDI input as well as DVS which is when you run an audio timecode signal in. I already have a DVS setup with a portable turntable that has a USB out - I run that USB through ASIO4ALL and it works pretty well though at the end of the day the sample rate is locked and I can only configure the buffer size down to 64 samples which limits how far down I can drive the latency by conventional means. My hope was that I could circumvent all of that somehow but now I'm just hoping that I'll be able to set a higher sample rate on the Teensy side and/or find a compatible ASIO driver that lets me reduce the buffer size to 16 or 32 samples. Super Rad fucked around with this message at 07:19 on May 2, 2018 |
|
#
?
May 2, 2018 07:07
|
|
|
Super Rad posted:It was an academic paper comparing the latency between an Arduino Uno, and Teensy 2.0 plugged into a Mac, the paper also compared using Puredata/Portaudio vs MSP, and then compared everything to running sound internally from a Pi (not applicable in my case, sadly). I admittedly haven't worked with ASIO in a looooong time so I'm not much help here, but presumably yeah the teensy would show up as a generic USB audio device of some kind that ASIO4ALL would take over. I'm not sure if anyone's written any raw ASIO application using the teensy, if you're feeling brave give it a try but that seems like it would be... difficult to say the least. I'm not sure if you've checked it out already but there seems to be a bunch of code related to doing audio stuff, already baked in to the Teensy core library here - check out MIDIUSB.h and usb_audio.h Super Rad posted:I'm thinking of using a teensy 3.5/3.6 since the rotary encoder I'm getting has 4096 positions, moving the platter quickly back and forth might require polling those pins at upwards of 20khz. Throw polling the capacitive touch switch and the momentary switches, and the decoding logic on top of all of that and it's quite possible the extra clockrate will be needed to make sure no state transitions are dropped. I'm leaning towards the Teensy 3.5 since it can tolerate 5V, and I'd be able to use the same Vcc for the encoder which operates at 5V minimum (not sure if that's optimistic to get a tolerable 5V to the teensy while also getting an acceptable 5V to the encoder). Well you probably don't want to poll at 20KHz, you want to set up interrupts. This lets the microcontroller do whatever it wants most of the time, but the second the hardware detects a change on one of the pins hooked up to the rotary encoder it pauses whatever it's doing and immediately jumps to a piece of code you specify (which can increment a "spinning" count or something like that in your code), then goes back to what it's doing. It's a little bit tricky to get this right - you want to make sure that the code it runs during the interrupt is as short as possible so a long interrupt doesn't screw up other things in your code that require tight timing. Usually what you do is what I mentioned, increment some simple variable that says "rotary encoder has turned x clicks in y direction" or something like that, then immediately exit the interrupt. Then somewhere else in your code, take that value and do the heavier work with it (send it to the computer, turn it into beeps and boops, whatever). The capacitive sensor however probably needs polling, I'm not sure how you'd do an interrupt for that, but the teensy should be more than able to handle that. Super Rad posted:Thanks for the correction - I've been reading up on it more and I'll have to experiment with a pair of brushes and see if I can have them contact on the shaft. Would be really nice to keep the brushes in the project box. Rather than checking for capacitance directly I'm just going to use the teensy to measure the RC delay. If you can find any examples of wireless measurement I'd love to see those, just to keep all the options in mind. I'll keep an eye out for it, I admit I've never done too much with capacitive sensing other than read about it and fiddle around with it on a breadboard so other posters might be better sources than me on this 
|
|
#
?
May 2, 2018 15:21
|
|
|
ate all the Oreos posted:I admittedly haven't worked with ASIO in a looooong time so I'm not much help here, but presumably yeah the teensy would show up as a generic USB audio device of some kind that ASIO4ALL would take over. I'm not sure if anyone's written any raw ASIO application using the teensy, if you're feeling brave give it a try but that seems like it would be... difficult to say the least. What I'm waiting to see is if the baud rate set on the board will matter beyond the 31k for midi (i.e. would ASIO4ALL recognize it if I set the teensy to 115k). If it doesn't then the latency would actually be higher than on the dvs which is 44.1khz audio. At least software is what I do so I might actually be able to get a good sense of how much work it would entail to get a real driver operational if I ever looked into it. I'm guessing it's a lot for someone who has never really had to delve into DLLs. ate all the Oreos posted:
Right, polling was the wrong term but yeah, it's possible that rapid motions could trigger said interrupt up to 20k times per second, so I'm thinking a 16mhz processor might be a little too tight on the timings. And yes the capacitive sensor does need real polling but fortunately the polling itself acts as the 'clock'/trigger to perpetuate itself, each time you simply poll again after writing the current code index to memory and comparing to the last one recorded, the timing there determines if the switch is open or closed. I think debouncing might be necessary on this and possibly the arcade buttons, yet another reason to go with a beefier processor.
|
|
#
?
May 2, 2018 16:43
|
|
|
I went and dug out my Teensy 3.2 to check some stuff out because I got it a while ago and just sorta threw it in a drawer because I didn't have anything that needed that kind of power. Turns out if you're using teensyduino it actually has a freakin' menu option to automatically configure it as different USB audio devices: I'll try to fiddle with some capacitive touch stuff later to see if there's anything special you gotta do. Super Rad posted:What I'm waiting to see is if the baud rate set on the board will matter beyond the 31k for midi (i.e. would ASIO4ALL recognize it if I set the teensy to 115k). If it doesn't then the latency would actually be higher than on the dvs which is 44.1khz audio. Where'd you get "16MHz" from? The teensy's clock is much higher than that, I think it defaults to 72MHz (like you can see in my screenshot) and can be pushed further than that if you don't mind possible heat or stability issues. Even so you'd probably be surprised, triggering an interrupt at 20KHz likely wouldn't even be noticeable on a 16MHz processor as long as it was a very simple interrupt routine. There's lots of stuff built in to the chip that's triggering interrupts much faster than that all the time (like timers), and modern hardware is very good at dealing with them as fast as possible. If we're talking about 8-bit AVR's for example, entering and exiting an ISR is about 4 cycles each, so let's say 12 to enter one, do a simple operation and exit. At 20KHz worst case, that routine would be eating 240KHz of processor cycles, leaving you with... 15.76MHz left over.
|
|
#
?
May 2, 2018 17:13
|
|
|
ate all the Oreos posted:I went and dug out my Teensy 3.2 to check some stuff out because I got it a while ago and just sorta threw it in a drawer because I didn't have anything that needed that kind of power. Turns out if you're using teensyduino it actually has a freakin' menu option to automatically configure it as different USB audio devices: Well, that will save a lot of effort! Though from what I'm seeing online that will only get me as far as having a WASAPI recognized MIDI device, if I want to skip the OS layer with ASIO, I would still need to use a generic driver like ASIO4ALL - still crossing my fingers that this will be snappy enough. ate all the Oreos posted:
16MHz is the Teensy 2.0 (which was one of the test subjects in that academic paper on audio latency). My concern with the rate of interrupts isn't exactly that it would eat up all of the processing capability, but rather that it eats up a big enough proportion of the total CPU time that a certain percentage of the time it is interrupting the middle of the actual MIDI update routine, thus possibly causing a 'missed' output as the relevant register would be overwritten before the data can be sent over MIDI. These should be rare, and not super consequential considering how physically small one positional shift is, but multiplying the clock rate by ~10 will do a lot to make a rare occurrence that much less likely. Also, the notion that the encoder could update as frequently as 20KHz is napkin math, based off my intuition that a quick 'chirp' could involved moving the platter 50% of a rotation in .1 seconds - I don't know the exact figures here so for all I know it's significantly lower - or a bit higher! As long as the baud rate of the USB connection is 31k or above I should really be safe, but again worst case scenario is that the extra computational power is going to waste, and at the very least it is likely to result in some very minor reduction in latency either way. E: I'm also wondering if a bela.io board is powerful enough to do all the I/O I need PLUS run PiDeck and a Touch-screen LCD. PiDeck is not the DJ software I wanted to use, but the notion of a 100% embedded solution that gets latency down into the micro/nanoseconds is, obviously, appealing. Unfortunately it looks like only a few people have tried sticking an LCD display onto it in the first place, and no one has tried running PiDeck on it, so yet agin I'd be in undiscovered country trying to get all of that operational. Super Rad fucked around with this message at 22:25 on May 2, 2018 |
|
#
?
May 2, 2018 22:15
|
|
|
|
| # ? May 20, 2024 02:49 |
|
|
This is a seriously ambitious project, good luck with it!
|
|
#
?
May 2, 2018 22:45
|
|