-
Shower thoughts: headless oscope, is there an easy high BW computer link?
Posted by Whales on 13 Aug, 2022 13:28 -
(This is all non-serious shower thoughts, not an actual production project)
My best scope at home (HP 54600 series) is 100MHz analog bandwidth but only 20MSPS @ 8bits.
You can buy ~$5 ADCs that do 60MSPS @ 10bits (edit: woops 50MSPS, but close enough). I'm sure my first designs with it would have all sorts of problems, but it would be fun and I could throw some basic relay-switchable analog filters into the mix.
Triggering, signal averaging, etc: doesn't matter as long as I could continuously (without gaps!) stream all samples to something like a desktop computer or laptop. Then I can do everything in software on the powerful machine. In fact this would be a lot better than many USB scopes I have seen (which have abysmal sampling speeds if you can't tolerate gaps in your capture).
Getting the data from the ADC to a computer is hard?
This is where my shower thoughts start to fall apart. How do I easily get high bandwidth digital data into a desktop computer? 60MHz @ 8bits is 480Mbit/s minimum, in reality the link will need to be faster.
Ethernet raw via discrete chips: Doesn't look as simple as a few discrete chips buffering samples into a pair of SRAMs and then spamming hardwired frames at an ethernet transformer. There is scrambling and negotiation needed (1000baseT requires one end to elect to be the master clock source, amongst other things). In practice you could probably skip a lot of the standards and use something like an ethernet switch chip to patch over the holes (eg retransmissions, collisions, some bits of autonegotiation) but I think it would still end up rather complex.
Ethernet raw with an FPGA: Spiritual and cost failure. If you use an FPGA I feel like you're already making a design similar to commercial oscilloscopes. I don't have much experience with FPGAs, but I presume a 1000baseT implementation would require the resources of a chip that costs a magnitude more than the ADC I link above.
Ethernet 1000baseT via an ethernet interface chip: All of the gigabit NIC chips seem to be built around PCIE as an interface. I'll keep digging to see if it's something you could feasibly cheat and use something simple with.
Ethernet 100baseT via an ethernet+network stack interface chip: These have much simpler interfaces like SPI and parallel. Sadly the highest I've seen (WIZNET-W5500) is claiming somewhere between 33MHz and 80MHz max theoretical SPI clock, so the actual analog sampling on the scope frontend is going to be well below 10MSPS
USB interface chips: UART USB bridges obviously won't do. Again PCIE might be the only interface option at these bitrates?
SBC computer or random allwinner SoC: Peripheral clocks are often a fraction of the core clock, but this might still allow 100MHz or so of digital data (more than 10MSPS of 8bit analog captures) to be ingested. Then stream it out via ethernet, PCIe or USB. Actually this sounds quite disappointing, especially since you'd probably have to do more than just a Linux userspace implementation of it to avoid timing issues (skipping incoming data).
Am I missing something here? Why is there such an imbalance in cost and complexity between the ADC chip itself and the ways of getting its data into a computer? -
You could use discrete logic to drive a GMII interface to a phy. The phy takes care of all the negotiation and so on, you just provide an 8 bit wide bus plus some clocks and control signals at 125 MHz. You would need to include computation of the FCS, all the other headers could be precomputed. Even a small FPGA would make this a lot easier. Sending UDP packets from an FPGA is pretty easy.
If you want 2 channels you are going be running up against the theoretical limits of gigabit ethernet. After that you pretty much are left with USB3, PCIe, or 10G Ethernet. Technically you could bit bang XGMII if you can find it but really this is the realm of FPGAs with multi gigabit transceivers. -
There are sometimes other interfaces like thunderbolt or infiniband or firewire etc. etc. but they're less common and harder to deal with.
Thunderbolt native would be a mighty pain for low volume, but thunderbolt to PCIe chassis are pretty common in professional applications. So PCIe is possible (vendor example design will be critical). Example:
https://github.com/EEVengers/ThunderScope
https://www.crowdsupply.com/eevengers/thunderscopeMy best scope at home (HP 54600 series) is 100MHz analog bandwidth but only 20MSPS @ 8bits.
Hold your horses! The sampling rate is much lower than the bandwidth because its not a "realtime" sampling and a bunch of magic happens in the analog front end.
You can buy ~$5 ADCs that do 60MSPS @ 10bits. I'm sure my first designs with it would have all sorts of problems, but it would be fun and I could throw some basic relay-switchable analog filters into the mix.
If you want something to start playing with:
https://earthpeopletechnology.com/digital_storage_oscilloscope_dso_100m -
Yes, USB SS would be the easiest path here. Can be done with a FT60x + some FPGA. Or you could use a Cypress FX3, but not sure it could handle the ADC (to be checked), maybe so if it has a parallel interface fast enough.
That said, you'd also have to write the PC software carefully so that it can handle the constant data stream flawlessly, which is not necessarily as easy as it sounds.
And then, you'll have to determine whether it's really worth all the trouble for just 60 Msps - which is frankly not that high.
-
The USB logic analyzers (Saelae, Analog Discovery, etc) which all have analog sampling functionality now, all use USB3 SuperSpeed.
-
Thankyou everyone for these suggestions.
- I've not delved into FPGAs before so this might be an excuse to try some of the lower end units for fun and see what the few open source toolchains are like.
- I didn't realise you could get gigabit ethernet or USB3 chips that had simple parallel interfaces, that's dramatically different to what I was seeing. I'm reading into them
SATA compatible interface
[...]
Hmm actually it'd be sort of cute / bizarre to have a little FPGA emulate a fast microSD card
I was also thinking about SATA last night. Perhaps MIPI/CSI on a raspberry pi too, but its spec isn't public and I suspect it might be more of a kernel/software hell to deal with than USB or ethernet due to less working examples in the kernel.And then, you'll have to determine whether it's really worth all the trouble for just 60 Msps - which is frankly not that high.
The "all the trouble" bit is why I made this topic. I thought it so damn strange that I could build the analog frontend and ADC relatively cheaply, but then struggle with complexity and cost just to get the data into a computer electrically. It seems rather backwards.
Also 60MSPS is pretty impressive if you consider continuous capture, not repetitive bursts.Hold your horses! The sampling rate is much lower than the bandwidth because its not a "realtime" sampling and a bunch of magic happens in the analog front end.
I'm aware of the magic equivalent time sampling and exploiting reflected frequencies. Alas this doesn't help much for single shot captures, only for repetitive signals. I really wish the 20MSPS was written on the front of my scope just as the 100MHz is, I would have learned these things many years earlier than I did.