JayKominek I've was so busy with work for the last 12 months that I got fed up and quit. So now I'm unemployed and have a bit of time on my hands.
We missed you. Welcome back! Very nice to have you back. Sorry about the circumstances, I hope you can afford to take a vacation (or at least staycation) and recharge. I'm sure you'll have no problem finding a good job, the situation 'round here is still okay (not fantastic as it was a year ago when I started my not-so-new-anymore job, but still decent enough for job seekers). I have plenty of connections, if you want to chat about possible options don't hesitate to reach out privately to me. And I mean more about an insider's view of "what's like to work at place X, would they suck your gut out or treat you well?" rather than "here's a position that looks interesting" which as I said I am sure you can do just fine on your own!
JayKominek Hmm, reading ADC data sheets is always rough, but that one seems particularly rough.
I noticed that 🤣
JayKominek And I believe for this kind of usage we'd never see more than 15 useful bits out of it. Which isn't the end of the world, that's about where I'm at with the ST part.
I think 15-16 bits is plenty, especially if we can bias the phototransistor properly to concentrate most of the resolution toward the end of the strike, which is what I would like to try to do, and matches well your design with separate key sensors for the release (if one wants to have only hammer sensors, they need to spread the resolution all over the stroke of the hammer). Back of the envelope: stroke after the escapement is 1mm to 2mm depending on regulation. Assuming to sense the last 3.2mm or perhaps 6.5mm with 32768 or 65536 levels is 1/10 of a micron resolution!!! Plenty.
JayKominek If they were less noisy, or it could produce them at >=30kS/s, that'd be interesting/useful.
Exactly. On the other hand, as we have discussed in some other thread here and on github, the velocity depends on both space and time resolution. Even if time resolution is not extreme, assuming that its accuracy is high enough, one could still get high enough resolution in velocity, perhaps resorting to some interpolation/extrapolation (e.g. time resolution insufficient to resolve the exact instant of the strike, but space resolution high enough to have great position locations before and after it, with some math one can infer the missing data and have accurate enough velocity estimate).
JayKominek I feel a little bit better about the TI part. I generally feel better about TI parts.
On paper, I came to the same conclusion, even if I am not discarding the MC option. I feel so for various reasons, including that the MC is only in a UQFN package (even though on its webpage they picture a DIP package too, go figure). Yet, with a schmartboard's EZ surface solder technology that could be not so bad, so I still wanted to give it a try.
But in any case, as I wrote on github, there are other options too, for example the Analog Device AD4116. I placed that on the backburner because it's multiplexed rather than simultaneous and its declared sampling rate are less than on the MC and TI. But as you said the ADC data sheets often hide the important detail of what you can actually do by quoting the best spec of each characteristic which you can achieve when all the others characteristics are sacrificed, and instead we want a best compromise with every spec, which is hard to understand from the data sheet.
JayKominek I'm thinking I might design a board that uses these external ADCs, and plugs into a Nucleo-144's morpho connector with the ADCs and other bits and bobs necessary to make the whole thing act as an ADC board in my system. Maybe throw on a raspberry pi 40 pin header as well, so I could try it out there? (Probably couldn't physically populate both sets of headers on the same PCB.)
I think that would be great for testing! In fact it's similar to what I wanted to do myself (see below).
JayKominek If you've got some microcontroller that has a pleasant in-circuit debugging experience and a software stack that makes you complain less, I'd be open to designing something that could connect to a dev board for it, instead.
My plan was to get a few samples of these ADCs, solder them on a schmartboard and build a air-wired version of the before-SPI section of their evaluation boards. Eventually I would have added your analog stage with a TIA, but to begin with less moving parts and less things for me to get wrong, I'd have started without. I'd have tested the ADC with all of the following boards until found one good enough for production, probably in this order:
RPi pico. Pro: extremely inexpensive, easy to use, 2 SPI channels, small footprint, not affected by part shortage. Cons: perhaps not enough compute power to read and process all the data from 16 ADCs (even though with some tricks one could halve that number, e.g. by not reading a key sensor until the hammer sensor has reached a strike)
Odroid XU4. Pro: I already have it, similar to a RPi 3 in performance and ease of use, not affected by part shortage. Cons: less documentation than RPi, less options to do stuff, only a single SPI channel per board (making it too expensive and too large for production -- the goal of its use is just to test the ADC).
A ST32H743 nucleo board (which I also already have). Pro: good computing power, I believe 6 SPI channels. Cons: severely affected by parts shortage, very tedious and hard to work with their development environment, hard to find code examples and extremely hard to integrate code examples in other projects.
Raspberry Pi 4. Pro: has six SPI controllers, it's a pleasure to work with, good computing power. Cons: still affected by parts shortage (but that should ease in a month or two, many places have accepted pre-orders -- now almost sold-out -- for boards to be shipped in the next couple of weeks), OS jitter could possibly be an issue, even though there are workarounds (depending on how severe the issue is it may become as hard to work with as a ST32 board, but it's definitely easier to get started)
This was my plan, but I'm not opposed to try another MCU if we think it's more promising.
Now, with you back onboard, if you want to design an appropriate PCB with either or both of these ADC (or any other), including the TIA, that would solve all the things I'm struggling most with. We can then evaluate these options which are most easily found (I've just lost a RPi 4 which was on sale on craigslist, sigh) and perhaps even others.
Actually, now that I think about it, if @stem_piano is willing to generate some data for us, I could concentrate on that part and see how it goes (while you design and build the hardware). I imaging something like:
- @stem_piano produces the highest-frequency data flow that he can from a single ADC (all channels) and saves it
- I massage that data to make it (say) 6 times as if it were coming from six separate ADCs.
- I use one board to read the massaged data and stream it out of (say) 6 SPI buses, trying to keep it synchronous in the way the data would come out of the ADC
- I use another board to read the 6 SPI buses and process the incoming flow, concentrating myself on the algorithm and real time processing
The ideal platform for this test would be using two separate RPi 4, but at the moment I have zero (I mean not even one, I don't have the RPi Zero 🤣)
[search search] -- I can probably buy a 400 and/or a very expensive kit if we deem this as the most viable path.
What do you guys think?
