Simplest way for 75MS/s 14bit recordings to SSD? - Page 1
Forum section: electronics / beginners

author: 240RS
author_rank: Regular Contributor
timestamp: June 01, 2023, 01:35:59 pm
content: I want to sample baseband RF at 75MHz and record 14bit samples (real values only) on SSD/HD for later analysis. Ideally for a minute or so.I was hopeful I could do this with a red Pitaya directly to its SD card, but that seems limited to 10MB/s. I assume I would need 150MB/s (2 bytes per sample).I had overlooked this issue. I was simply thinking ADC’s are fast enough these days, USB3.0 is fast enough. But I can literally not find a single solution.Is there something obvious for the recording part?Later on. I would like to be able to play it back. I just purchased an eBay Anritsu MG3700a vector signal generator that can play back 512MS with max 160MHz bandwidth. But maybe there is a logical DAC solution also.Thanks

author: radiolistener
author_rank: Super Contributor
timestamp: June 01, 2023, 03:19:31 pm
content: I tried to get 30 MS/s 14 bits (aligned to 16 bits) through gigabit ethernet on i5 760 running at 3200 MHz. But it works unstable, I have packet drops. I think there is needs some ethernet card with hardware acceleration, because my onboard Realtek 8112L gigabit chip is unable to handle continuous realtime streams above 700 MBit/s on Windows 7 without high CPU load even when receiver app is not running. I just start OS and don't run anything, then push 700-900 MBit/s stream through ethernet cable and my PC starts to lagging despite the fact that it has pretty fast 95 Watt desktop CPU with massive heatsink.USB2 interface just unable to handle more than 480 Mbit (include protocol overhead). I'm not sure if USB3 interface allows to process more fast stream than 1 Gbit in realtime, but anyway 75 MS/s at 14 bits is not so easy for desktop PC, because even fast server HDD is unable to write data continuously at that speed, of course SDD probably can do it, but there is still bottleneck with CPU and motherboard bus speed.I think there is a sense to implement direct interface between FPGA and SSD to write data directly to SSD with no need to process it on PC.

author: langwadt
author_rank: Super Contributor
timestamp: June 01, 2023, 03:41:12 pm
content: https://opalkelly.com/products/xem7310mt/and a board with your ADC (DAC) ?

author: 240RS
author_rank: Regular Contributor
timestamp: June 01, 2023, 05:36:34 pm
content: Quote from: radiolistener on June 01, 2023, 03:19:31 pmWhat ADC board did you use?

author: 240RS
author_rank: Regular Contributor
timestamp: June 01, 2023, 05:37:46 pm
content: Quote from: langwadt on June 01, 2023, 03:41:12 pmSounds good indeed, but steep learning curve?

author: KE5FX
author_rank: Super Contributor
timestamp: June 01, 2023, 06:14:13 pm
content: Quote from: 240RS on June 01, 2023, 05:37:46 pmOpal Kelly's FrontPanel architecture is very easy to learn and use. It's proprietary, though, so you have to be prepared to either stick with it in the long run or migrate eventually when your needs change. (For one thing, your supply chain will be joined at the hip to theirs.)Also see the ZTex and Trenz boards for a more open, DIY-friendly alternative. I've used both ZTex and Opal Kelly's products and usually find ZTex a better fit for my needs and interests, but Opal Kelly's products are also superb.

author: 240RS
author_rank: Regular Contributor
timestamp: June 01, 2023, 07:08:58 pm
content: Ah, great. What ADC to connect? That will be parallel data lines I guess?

author: langwadt
author_rank: Super Contributor
timestamp: June 01, 2023, 07:48:05 pm
content: Quote from: 240RS on June 01, 2023, 07:08:58 pmif you have to ask I doubt it is for you ...how much are you wiling to spend?maybe something like this?https://spectrum-instrumentation.com/products/families/44xx_m4i_pci.phphttps://www.alazartech.com/en/product/ats9628/642/

author: 240RS
author_rank: Regular Contributor
timestamp: June 01, 2023, 08:13:59 pm
content: Quote from: langwadt on June 01, 2023, 07:48:05 pmI got that indeed :-). No offense.Starting point was: 14bit 125MS/s ADC’s are 20-40usd these days. USB3.0 is fast enough. I had just overlooked there isn’t a couple hundred dollar complete solution that would just “dump” 75MS/s on my computer. Had really hoped I would not have to program fpga’s and hookup SYZYGY boards.

author: radiolistener
author_rank: Super Contributor
timestamp: June 01, 2023, 09:51:31 pm
content: Quote from: 240RS on June 01, 2023, 05:36:34 pmI'm using self made board with AD6645-105 ADC. It works good, but has too high power consumption (about 1W from 5V) and pretty hot even with heatsink on it. More modern ADC allows to reduce power consumption.Quote from: 240RS on June 01, 2023, 07:08:58 pm75 MHz x 14 bit will produce at least 1.05 Gbps serial stream, I think it will be hard to deal with it, especially when you prototype it. Even 100 MHz parallel bus has issue if you use a little different wire length.

author: ve7xen
author_rank: Super Contributor
timestamp: June 01, 2023, 10:23:38 pm
content: USRP B200 over USB 3 claims 61.55MS/s realtime streaming with 16-bit IQ. Not quite your target but should be very easy to set up, though not as cheap.Naively, 1Gbps interface of Red Pitaya is not quite fast enough, nor is its SD card interface, so there is not really an 'easy' solution available. If stored as integer, I guess the raw data might be relatively easily compressible, so if you run it through lossless compression and then dump it over the network it can probably keep up, assuming the network interface and CPU can keep up reasonably well with a pretty fat flow, though it's not obvious to me whether or not it would hit the mark. Check the gr-compress module, dump it to a UDP sink and store it on a box with faster disk.

author: langwadt
author_rank: Super Contributor
timestamp: June 01, 2023, 10:39:30 pm
content: Quote from: radiolistener on June 01, 2023, 09:51:31 pmtwo pairs of LVDS will do, e.g.https://www.analog.com/en/products/ad9645.html

author: larsdenmark
author_rank: Regular Contributor
timestamp: June 02, 2023, 06:20:04 am
content: Perhaps a single board computer with 16 GB of RAM can be used. E.g. the Orange P5 5:http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5.htmlIf you can make its GPIO pins work fast enough then you can simply store the data in RAM before moving the data to a SD card or an SSD harddrive.The Orange Pi 5 has interfaces to network, USB, CD cards and SSDs so there should be plenty of possibilities of getting data out of this thing. Note that it doesn't have Wifi or Bluetooth built in.

author: radiolistener
author_rank: Super Contributor
timestamp: June 02, 2023, 07:23:23 am
content: Quote from: larsdenmark on June 02, 2023, 06:20:04 amI think orange pi will be unable to handle even 10-20 MS/s, especially through GPIO, GMII or USB interface. Such a stream needs for at least modern i5/i7 CPU. If you want for a mobile solution, you can try modern notebook for gamers with i7 CPU, but I'm not sure if mobile i7 CPU will be able to handle 75 MS/s because this is more than 1 Gbps realtime continuous stream...

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 02, 2023, 02:28:46 pm
content: On non-x86 Linux SBCs:If you can get a suitable USB 3 DAQ, thenOdroid M1 (8 GiB)should work, I believe. It is a 2.0 GHz quad-core Cortex-A55 with Neon, FPU, and crypto extensions. There is also an NPU, and Mali G52-2EE graphics (including video acceleration and HDMI to a display). (I've been considering getting one myself. I really like Odroid SBCs, and RockChip is one of the rare SoC manufacturers who push support for their SoCs to upstream open source Linux kernels, instead of binding one to vendor kernels only (but HardKernel does provide customized images and kernels too).)It is based on (specs) Rockchip RK3568, and has a PCIe 3.0 M.2 M-key slot for storage; benchmark (on top of a filesystem in Linux) indicates sequential writes in 512k chunks reaches 1200 MiB/s (so almost an order of magnitude more than you need for 75 Msps @ 16bit = 150 MiB/s). It also has a 5V SATA (standard SATA connector, but the power connector does not provide 12V), which you can use with SATA SSDs. SATA is slower than the PCIe, but still has sufficient bandwidth (somewhere between 100 MiB/s and 500 MiB/s, depending on the SATA SSD drive) for your use case.Instead of USB 3, you could also use MIPI CSI (two differential data input lanes plus clock input to the SoC); see theRK3568B2 Datasheet. You probably would need a straightforward custom Linux kernel driver to communicate with the MIPI ADC/DAQ, as the standard platform drivers are image-oriented. Perhaps via Lattice iCE40 FPGA, like using one of theOlimex iCE40 FPGA boards?Quote from: radiolistener on June 02, 2023, 07:23:23 amNo, Rockchip RK3588S is even more powerful than RK3568. These puppies have absolutely no problem throwing a gigabyte per second around, continously.From what end did you pull the belief thatan Intel processorwould be needed for this? That's ridiculous, really.

author: radiolistener
author_rank: Super Contributor
timestamp: June 02, 2023, 02:51:51 pm
content: Quote from: Nominal Animal on June 02, 2023, 02:28:46 pmI didn't tried that RK3588S, but a much powerful desktop i3 has performance issues even with 20 MS/s. I also tried intel Atom and 2 core ARM Cortex A15, they are just sucks and have problems even with 1 MS/s.Maybe it can transfer 1-2 Gbps with no issue in some usecases through some internal bus, but if you're planning a real usage through GMII or USB interface, it will starts packet drops at much slower data flow. Just notice that this transfer speed cannot be handled even with gigabit ethernet because it's max transfer speed is smaller than minimum required.And note that there is requiredcontinuous transfer in realtime, not a signle burst transfer. It doesn't allow waiting or delays. Any delay leads to a transfer fail because it leads to a packet drop. So the real requirement is much higher than 1-2 Gbps in order to cover all other data transfer required for OS functions.Such a transfer speed requires about 4-8 GB dedicated RAM just for the receive buffer with hardware DMA write.I didn't tested odroid-m1 or raspberry pi 4/5, but I'm sure they cannot handle even continuous gigabit data flow from Ethernet GMII interface. Just because much more powerful desktop PC cannot do it well without server ethernet adapter with hardware acceleration.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 02, 2023, 08:00:10 pm
content: Quote from: radiolistener on June 02, 2023, 02:51:51 pmI think you have way too much faith in Intel.Quote from: radiolistener on June 02, 2023, 02:51:51 pmSigh. The USB 3 numbers are from real benchmarks.Yes, Raspberry Pi's USB implementation is utter shite, because it can drop packets silently.Also, Windows is not useful for this kind of stuff; you don't run a GUI on a high-performance measurement instrument. The amount of resources Windows needs is not related to how much resources the same task in e.g. Linux needs, really.UDP/IP payload bandwidth at optimal conditions using gigabit is about 120 MBytes/second, and Odroids can sustain about 90% of that, or 110 MBytes/second, as one can easily benchmark (including using simple C programs). With a direct link, increasing MTU will give slightly better performance.Radxa Rock5B, for example, has a 2.5Gbit Ethernet (RTL8125B), with practical bandwidth around 2.35 Gbit/s according toiperf benchmarking, so using UDP/IP over a dedicated link (no collisions), you should be able to get 2 Gbit/s or 250 Mbytes/s transfer rate in practice – which is two thirds more than you actually need.Quote from: radiolistener on June 02, 2023, 02:51:51 pmIknow. One of my hobbies is interfacing to various sensory things using Teensy 4, a $24 dev board for NXP i.MX RT1062. Unlike many other microcontrollers, this one has native USB 2.0high speedinterface (two, actually), and even a trivial USB Serial example can reach 200+ Mbit/s (or 25 Mbytes/s)payloadin one direction. I test this with a Xorshift64 PRNG, generating the data (it runs at 600 MHz) on both the Teensy and my host computer, so I even verify the data is correct. I measure the interval between received chunks (using wall clock, or POSIX CLOCK_REALTIME in Linux), and update min, max, avg, and stddev (median for limited runs). Then, I run it for a few hours to verify this can besustained.To get closer to the theoretical maximum, I need to use bulk transfers, but as that rate is more than my sensor and small display things need, I haven't bothered even testing the maximum.I've also done server-side development for years, so I know what bandwidth, PPS, latency, and other related termsactuallymean.What I don't know, is the electronics side. I'm a hobbyist newbie when it comes to electronics, especially things like how to implement proper LVDS (or MIPI CSI) interfaces at 1.2 Gbit/s bandwidth.You need large buffers, preferably mostly continuous ones, filled/drained via DMA or a dedicated CPU, to reach 2+ Gbits/s throughput.The memory bandwidth is about 6 Gbytes/sec ("48 Gbit/s") on Odroid-M1 (report), more on Rock5B and Orange Pi 5.Storage tends to be quite optimized in Linux, so no problem there. The main problem is obtaining the ADC data. You will not achieve anywhere near the necessary bandwidth using GPIO pins; you'll need a native interface with DMA and sufficient bandwidth to do so.In the aforementioned SBCs –– unlike e.g. Raspberry Pi's –– the storage buses (SATA and PCIe) are separate from the USB 3. They are peripherals integrated to the SoC, with DMA access to the SoC memory. While I haven't verified it, USB3 should easily exceed the needed bandwidth, if you had an USB 3 ADC or DAQ. Both RK3588 and RK3568 MIPI CSI can do 2.5 Gbits/sec per lane, and the boards expose either two or four lanes, so MIPI CSI bandwidth would not be an issue if you can just get the ADC to talk MIPI CSI (assuming a DIY frontend-ADC-FPGA-MIPI solution).I wish I had an Odroid-M1, Rock5B, or Orange Pi 5, because then I could actually easily verify this, simply by connecting USB3 to a JMS567-SATA bridge and to a fast SATA drive, and check the sustained transfer rates to/from a Samsung PCIe M.2 (or other similar SSD with sufficiently high bandwidth on PCIe 3.0).I'm very sure the result is well over 150 Mbytes/second, probably twice that (unless limited by the SATA drive), based on my experience with other SBCs.It is very much equivalent to using USB 3 bulk transfers to an userspace process, and that process storing it to the PCIe M.2 (or vice versa).Quote from: radiolistener on June 02, 2023, 02:51:51 pmYou're utterly, utterly wrong. Desktop PCs, especially those running Windows, aren't a good benchmark.Look at theRock5B iperf benchmark here. This is just a short run, over 27 seconds, with at least 280 megabytes transferred each second (except the initial second). I prefer at least 15-20 minute runs, myself, but there is no reason to think this cannot be sustained.Even oldOdroid XU4can sustain 225 Mbytes/sec over USB3 using JMS578 USB-to-SATA bridge and Samsung SSD 850 PRO 256GB. That is 1.8 Gbits/s, well over the 1.5 Gbits/s you need. (I have the Odroid HC1 model, with the JMS578 bridge on board; on most SATA SSDs I have, the SSD itself is the bottleneck.)

author: larsdenmark
author_rank: Regular Contributor
timestamp: June 02, 2023, 09:00:09 pm
content: I don't see a need for continuous transfer. The OP states that he want to store data that are collected for a minute. Which means you can simply store the data in RAM and decide where to move the data afterwards.The Orange Pi 5 plus has 2.5 GB ethernet interfaces so you can transfer the data quickly to somewhere else. I haven't tested this, but I would assume that it comes with these interfaces because it is able to move data that fast.

author: radiolistener
author_rank: Super Contributor
timestamp: June 02, 2023, 09:19:50 pm
content: Quote from: Nominal Animal on June 02, 2023, 08:00:10 pmAs I remember, my desktop PC reports about 900 Mbps transfer speed in benchmark. But I can't get stable continuous realtime transfer without packet drops even at 600 Mbps.Another example is my gigabit router DIR-655, it has gigabit ports, and peak transfer speed really going to about 1 Gpbs. But when I push realtime continuous stream into it, it just starts to drop packets at about 200-300 Mbps, when I increase transfer speed up to 700-900 Mbps it just leads to denial of service. But it has real gigabit ports and can transfer at gigabit speed... but this is not the case when stream is continuous and don't allows delays and waits...When I tried to push 700-900 Mbps continuous UDP stream directly into gigabit ethernet port of my desktop PC running on Win 7, and there is no running program and no listener on UDP port, it leads to about 30-40% CPU load for 2 core i5 CPU which running at 3200 MHz (overclocked). That 30-40% CPU load is just to receive packets with OS driver at fully loaded gigabit link. This is why I don't believe that such a toy singleboard PC can handle it with no problem

author: ve7xen
author_rank: Super Contributor
timestamp: June 02, 2023, 09:38:29 pm
content: Generally it is pps that matters more than bps for realtime throughput. If you are sending ~1500b payloads, then any non-broken implementation should easily support 900mbps without drops. If you are trying to do it with 64b (minimum) size packets, (24x the overhead), it becomes a lot more difficult as the ISRs must be serviced more frequently to avoid drops in most designs, and obviously it is a lot more parsing and so on overhead in the OS.I could believe that a reasonably modern machine might struggle with 1Gbps @ 64b packets, but there is no way that any remotely modern machine, even a cheap SBC, should struggle with 1Gbps @ 1500b packets. Notwithstanding whatever the processing / storage of that data requires, of course.Realtek is known for quite poor drivers as well as hardware that requires relatively a lot of CPU involvement. Good NICs are not expensive, though, and the MACs in embedded CPUs tend to be fine as well.

author: radiolistener
author_rank: Super Contributor
timestamp: June 02, 2023, 09:55:22 pm
content: Just found screenshot with my tests at about 935 Mbps. The receiver program just receive UDP packets, and check it's first 4 bytes with packet id to detect packet loss and calculate transfer speed per second. There is no other tasks and no background processes.As I remember I was used UDP packet size 2048 bytes.As you can see so easy task requires at least 46% CPU load for i5 @ 3200 MHz.I just wonder how you can get better result on a much slower toy-machine?

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 02, 2023, 10:27:59 pm
content: Quote from: radiolistener on June 02, 2023, 09:19:50 pmYou believe exactly what you want. However, even the older Linux SBCs I have, can stuff a gigabit ethernet full of data with no problems.I even included links to real-world benchmarks (usingiperfand other tools) on said hardware, but apparently your belief in the superiority of Windows is unshakeable even when shown contrary real-world results.There is a reason why Windows is only used on the desktop, and why none of the worlds top 500 high-performance computers run Windows (they all run Linux, and have for years now), and even Microsoft has switched to using Linux outside their desktop business.To me,Windowsis the desktop-only toy.

author: radiolistener
author_rank: Super Contributor
timestamp: June 02, 2023, 10:31:24 pm
content: Quote from: ve7xen on June 02, 2023, 09:38:29 pmwell, may be this is because realtek MAC chip, but I never seen a project for raspbery pi level machine that allows to get realtime stream from high speed ADC at rate more than 1-2 MS/s. And this is not because this is no needed. That ability is very interesting.And high speed SDR receivers with USB3 interface that allows to receive at 20 MS/s and more write notice that such a speed requires modern top level PC, at least i5 or i7. And you can read feedback from users that it has performance issues on a slow machines at rate 10 MS/s and above.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 02, 2023, 10:36:49 pm
content: Quote from: radiolistener on June 02, 2023, 10:31:24 pmRaspberry Pis have unreliable-hardware USB implementation. They are not a valid choice for something like this.As to the rest, you should note that that is your unfounded belief that others who actually use these SBCs disagree with, never having tested one, instead of positing it as a fact you have verified yourself. Windows machines do not compare to SBCs, it's that simple.

author: radiolistener
author_rank: Super Contributor
timestamp: June 02, 2023, 10:39:14 pm
content: Quote from: Nominal Animal on June 02, 2023, 10:27:59 pmI tested iperf. The problem with iperf is that it doesn't use continuous realtime stream at constant hardware controlled speed for measurements. It has a lot of random delays in transfer. In such relaxed mode you can transfer data at pretty high rate, but with no guarantee for a constant transfer speed. The actual speed is varying from low to high and iperf just measure average speed.This is why iperf can show you nice digits, but these digits don't show you a real ability to transfer realtime stream at constant high speed close to the maximum limit of the gigabit link.When you're trying to transfer realtime continuous stream at constant speed which is needed to transfer data from high speed ADC, it leads to a problems with packet drops on PC side. This is because such a mode requires guaranteed OS response within pretty low time interval. And higher speed means that this interval should be lower.If CPU doing some non critical stuff and didn't processed packet within hardly defined time interval, it just drops the packet and it leads to malfunction, because there is no way to re transmit the packet.Can you please show me example of high speed ADC data transfer implementation for a raspberry pi at rate about 10-20 MS/s and above that? I never hear that... The only implementation that I know which allows 20-40 MS/s transfer through USB3 requires top level desktop machine with i5/i7 CPU...It will be great to have something like raspberry pi which allows to handle so fast realtime streams, but unfortunately I don't know such solution. You're just use desktop PC to handle stream at gigabit speed, or use raspberry pi and accept it's limit for a speed transfer to about 1-2 MS/s or even smaller.By the way, I tried linux (Arch+plasma) and windows (Win7) comparison for SDR processing with SDRAngel and SDR++, I can say that I was expected that linux will be better for that. But in reality I found that linux implementation is a little bit slower and buggy. In addition I found that windows implementation works more smooth and stable. That was a surprise for me.Of course it's doesn't means that windows IP stack is better, but if we take all things together (IP stack, OpenGL, task scheduler and other things) the windows OS still win in that fight.Quote from: Nominal Animal on June 02, 2023, 10:36:49 pmMy belief is based on the fact that there is no even a single implementation for SBC to get realtime high speed ADC stream into SBC and process it in realtime without packet drops. Desktop PC has such implementation up to 40 MS/s and more.I tested some different machines with aim to try implement such transfer, but unfortunately slow machines (like SBC) have big performance limitations which prevents to use realtime streams more than 1-2 MS/s. Maybe modern SBC have better performance and can do more, but 14-bit 75 MS/s realtime stream is too much even for a modern top performance desktop PC.As I understand, your belief that SBC can handle 14-bit 75 MS/s realtime stream is based on iperf results. Well, but why no one can do it if it's possible?I'm really interesting, maybe I don't know something and it's really possible, then can you show me some example? For example maybe there is some project that receive realtime ADC data at 40-75 MS/s and can process it in realtime. At the moment, with results that I was seen on different machines, I just don't have idea on how it can be possible on so slow SBC.

author: Marsupilami
author_rank: Frequent Contributor
timestamp: June 03, 2023, 12:45:07 am
content: https://www.ebay.com/itm/166033310781?

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 03, 2023, 04:53:24 am
content: It seems to me thatEZ-USB FX3 interfaced to a parallel ADCwould yield an USB 3 solution – except that EZ-USB FX3 [fixed:] EVM (CYUSB3KIT-001) is no longer manufactured, and the EZ-USB FX3 Explorer kit (CYUSB3KIT-003) is not available anywhere, possibly no longer manufactured.It has a dedicated GPIF-II, that can run at 100 MHz, and supports 8-, 16-, 24-, or 32-bit parallel inputs. [end fix]While the requiredCYUSB3013-BZXCchip itself is still manufactured, it's a 121-ball BGA with 0.8mm pitch; way outside my electronics skill range.Oh, andOrange Pi 5 Pluslooks extremely interesting, what with both PCIe 3.0 M.2, 2×2.5GbE, HDMI In + 2×Out, and so on.Quote from: radiolistener on June 02, 2023, 10:39:14 pmNo, because Raspberry Pis are not suitable for this.Like I said, the problem is getting the ADC data via some kind of a parallel bus and DMA to RAM.BeagleBone Black (based on TI AM335x "Sitara" processors from around 2011), according to TI,can do 14bit parallel input clocked at 50 Msps. Unfortunately, it is so old it doesn't have USB3 nor PCIe M.2 for fast enough storage, so just like 'Pis, BBB isn't suitable here.Quote from: radiolistener on June 02, 2023, 10:39:14 pmMost scientific measurement appliances and even oscilloscopes run Linux on ARM cores; so do many NASes and miniservers(which usually use USB3-to-SATA interfaces like JMS578) that can definitely do several hundred megabytes per second locally, limited by the SATA SSD's sustained I/O bandwidth.Just because you don't know them doesn't mean they don't exist.Analog Devices even provides Linux kernel drivers for controlling their high-speed ADCs like AD9467 (16-bit 200MSPS ADC,driver source) andmany othersrunning on Zync SoC FPGAs (entire AD tree) like ZedBoard, easily adapted to ones own use. (The iio in the path refers toIndustrial I/Osubsystem in Linux.) Of course, the price for these particular ones ispainful.

author: KE5FX
author_rank: Super Contributor
timestamp: June 03, 2023, 05:09:45 am
content: Quote from: Nominal Animal on June 03, 2023, 04:53:24 amWait,what?That would be more or less apocalyptic.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 03, 2023, 06:01:29 am
content: Quote from: KE5FX on June 03, 2023, 05:09:45 amEVM! The EVM, CYUSB3KIT-001, is no longer manufactured! Sorry.And CYUSB3KIT-003 is zero-stock everywhere, including Infineon.[*]The CYUSB3KIT-001 was even more an EVM, whereas -003 is the Explorer Kit. CYUSB3KIT-003 is/was/would be only around twice the cost of a single CYUSB3013-BZXC in singles for us hobbyists. You could even use it as a100 MHz logic analyzer with Sigrok(using the same USB3 bandwidth as 16bit 100MS/s ADC). The GPIF II parallel-to-serial bridge would be configured usingGPIF II designer. According toAN86947, it shouldn't have any problems with a 100 Msps 16-bit GPIF II externally-clocked parallel-to-USB data stream.I only have the EZ-USB FX2LP one myself, which is similar, but limited to USB 2.0 High Speed (480 Mbit/s).[*]Except Farnell/Element14 Singapore (and from there to Australia)has some in CYUSB3KIT-003 in stock, of course.

author: radiolistener
author_rank: Super Contributor
timestamp: June 03, 2023, 07:01:40 am
content: Quote from: Nominal Animal on June 03, 2023, 04:53:24 amStop. But I already said that such transfer is possible with direct write into RAM with DMA, if your external device has an access to internal memory bus. I was talking that SBC (such as raspberry pi/orange pi/odroid-m1) cannot do it with gigabit Ethernet or USB3 port. While modern powerful desktop PC can do it. But you're said that SBC also can do it and even can do it better than powerful expensive PC. Isn't it?Quote from: Nominal Animal on June 03, 2023, 04:53:24 amOscilloscope uses FPGA for ADC data processing and don't use gigabit ethernet, USB3 or SPI to transfer data between FPGA and CPU, they use high speed transfer through internal high speed bus with using DMA to reduce CPU load. And oscilloscope CPU doesn't deal with high speed stream from ADC, it is processed on FPGA. So, the oscilloscope CPU get already processed data flow with reduced speed.Yes, you can do fast hardware transfer directly to memory or SSD by using their hardware bus directly, which don't involve CPU. But we're talking about attempt to use SBC through it's standard ports like gigabit ethernet, USB3 or SPI on it's GPIO connector.

author: radiolistener
author_rank: Super Contributor
timestamp: June 03, 2023, 07:22:16 am
content: Quote from: Nominal Animal on June 03, 2023, 06:01:29 amYes, it's problematic to buy high speed USB3 controller, they are expensive or just don't available.Quote from: Nominal Animal on June 03, 2023, 06:01:29 amI also have FX2LP, but it's based on 8051 based MCU with paginated memory and kludges, and it don't have JTAG/SWD for in-circuit debugging, so it's headache to debug some code on it. I tried to use it but after STM32, it looks like bullying, so I just threw it awayIf you're want to use 480 Mbps of USB2, it's more easy to use FT232H.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 03, 2023, 07:52:47 am
content: Quote from: radiolistener on June 03, 2023, 07:22:16 amThe C (sdcc-compiled) sources to the fx2lafw firmware Sigrok uses for itare here. It too has (and uses) the GPIF for (slave) parallel input using 8- or 16-bit inputs, so the 8051 code really only sets up the USB endpoints and GPIF, and then just spins in a busy loop polling for events.It isn't nice like Cortex-M or even AVR, for sure, but usingsdccto compile the C sources to 8051 seems okay to me. The 8051 core does not touch the data flowing, so it shouldn't have to be too keenly optimized to work well.The EZ-USB FX3 isn't that much different. Instead of 8051, you have an ARM9 running some kind of RTOS kernel, and lots more speed and bandwidth.I really only like them for the parallel-to-USB interfaces, plus uses as a logic analyzer.

author: Marsupilami
author_rank: Frequent Contributor
timestamp: June 03, 2023, 08:10:29 am
content: Quote from: Marsupilami on June 03, 2023, 12:45:07 amIn bird culture this might be considered a d*ck move, but while you guys were bickering here I wanted to recommend another ebay find and I ended up buying it just for the lolz.https://www.ebay.com/itm/1253074947748bit only but if I understand it correctly it can do 3Gsps on one channel.And it's$99lol. Manufacturer lists it for almost 9 grand.Moral of the story, go ebay hunting.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 03, 2023, 09:48:51 am
content: Quote from: radiolistener on June 03, 2023, 07:01:40 amYet, even my old Odroid HC1 can do it. Other than RPi, the SBC's I've mentioned above obviously can.Quote from: radiolistener on June 03, 2023, 07:01:40 amWhen that SBC is not running wasteful stuff like GUI and unneeded crap like various service daemons, and has a suitable SoC with the requisite hardware peripherals, sure.For example, OV5647 is a MIPI CSI camera module, that can produce 1920×1080×30×10 = 622,080,000 bits per second, or just under 78 Mbytes/sec. Yet, these SBCs can record and display the camera output at that resolution (1080p30) just fine, and you can even do other stuff at the same time.How is that possible? These SBCs have many periperals that can transfer data to anywhere in memory without the intervention of the actual processor cores. They use pretty smart DMA controllers with priorities et cetera, so that the only real impact is on the memory bandwidth – but on the better SBCs, a couple of gigabits per second of DMA transfers doesn't yet starve anything. (The processor cores also have caches, of course.)It is better to have bursty transfers at higher than necessary clocks, rather than require well-timed byte/word transfers, so that the DMA controllers and caches use the available bandwidth to its fullest, without competing with each other too much.This is how even slooow boards likeMikroTik RBM33G(800 MHz32-bit MIPS processorwith just 256 MB of RAM) can stuff a gigabit ethernet pipe full of data, as long as there are no resends or collisions, and the data is already in memory buffers, because essentially the board itself is "an accelerated Ethernet card".The beforementioned EZ-USB FX2LA, which has a puny 48 MHz 8051 core, is well known to reach quite close to the theoretical maximum transfer rates, when using the GPIF feature. GPIF, too, is a hardware peripheral, which waits for a specific clock edge, then latches 8/16/24/32 bits, and buffers the data, letting the USB buffer side know how much data it has. Whenever there is enough data and the USB buffer side is ready to do so –– all this without the 8051 processor core doing anything! ––, the USB buffer side initiates and transfers the data using USB bulk or isochronous transfers. When ACKed by the host, the USB buffer side discards the data (letting future GPIF transfers overwrite it), and round it goes. The actual 8051 core just waits for event flags (at certain memory addresses, updated by the GPIF peripheral and the USB buffer manager) and updates the configuration when necessary, it does not participate in moving the data around.In SBCs with MIPI CSI and OV5647 support at maximum frame rates (the driver isbuilt-in to the vanilla Linux kernel, by the way), when you display or compress the camera video, it is not done by the processor core computing the details. Most of these have a video compressor subsystem, which is simply told whenever a new frame has been received, and it does (most) of the work by itself; there is typically a bit of housekeeping work for each frame, buffer maintenance and so on. When displayed on screen, the OpenGL or OpenGL ES display accelerator can directly display the camera frames on screen, with scaling, as long as it supports the color format. In some cases, like Raspberry Pi's (which does support OV5647), the display accelerator or media processor manages the camera frame transfers almost autonomously, with one of the core processors just doing some bookkeeping work (keeping track of memory) once per frame.Quote from: radiolistener on June 03, 2023, 07:01:40 amYet, the underlying transport, typically 2, 4, 8, or 16 LVDS lanes (sometimes at double data rate, at both edges of the clock),isthe same.The only difference is that in SoCs, when an appropriate bus (USB, MIPI, PCIe, etc. is used, the transceivers are connected to a DMA engine.In FPGAs, I believe you can interconnect the signals in a much more complex way, includingbothstoring the data to a RAM buffer, and processing it using some optimized ALU or triggering detector.Quote from: radiolistener on June 03, 2023, 07:01:40 amOr rather, theCPU never touches most of the data at all, just like the EZ-USB FX2 and its 48 MHz 8051 core.Quote from: radiolistener on June 03, 2023, 07:01:40 amBut you see, USB3, MIPI CSI, PCIe, and all those buses I've suggested could be used,do fast hardware transfers directly from memory, without involving the CPU! That's the entire idea.If we tried to use plain GPIO, for example dedicating one core for just waiting for the specific clock edge, and then latching the data pin states, I do not believe we could achieve the necessary bandwidth.This is also why number crunching and things like intensive JavaScript on web pages (I like to use the browser-basedEasyEDA editorfor my board designs) feels so much slower on an SBC than on a desktop or laptop: the core processors has to manipulate all that data and interpret the Javascript, and none of those hardware peripherals can help much. (Well, the media processors, capable of encoding and decoding h.264 at 1080p60 or better and only spendinga watt or two, are definitely useful for video playing. And OpenGL ES graphics do work well when the system is designed to exploit them – just look at your cellphone. Both Android and iPhone/iOS heavily rely on OpenGL ES for the display graphics!)

author: sparkydog
author_rank: Regular Contributor
timestamp: June 05, 2023, 09:29:14 pm
content: Quote from: radiolistener on June 02, 2023, 10:39:14 pmThis, right here, is why your skepticism is unwarranted and probably¹ wrong. Comparing a desktop environment to a real-time computing environment is apples and oranges. Network behavior on a multi-client network is similarly not comparable with behavior on a dedicated, point-to-point link. There's no such thing as aWindozemachine that isn't doing all manner of non-critical stuff all the time. A properly configured SBC only does non-critical stuff when itisn'tdoing critical stuff... if it does at all. Note that "non-critical stuff" might includerunning a task scheduler.(¹ I won't say "definitely" because I haven't done any tests myself. However, I'm inclined to believe the other posters.)Quote from: radiolistener on June 02, 2023, 10:39:14 pm...which isexactlywhy you use a real-time kernel and not Windoze when you need this sort of performance. The entire reason such kernels exist is to guarantee low-latency response.Basically, you're complaining that your 300 HP minivan (which is bloated with luxury creature comforts and other bits and baubles that don't help it go fast) isn't very impressive on the racetrack and concluding on that basis that the 200 HP racing bike (that's been ruthlessly stripped of anything that doesn't contribute to racetrack performance)mustbe worse than your minivan.

author: 240RS
author_rank: Regular Contributor
timestamp: June 15, 2023, 01:00:19 pm
content: Could this RX888 mk2 “sdr” be an option?https://dc4ku.com/.cm4all/uproc.php/0/SDR%20-%20TEST-BERICHTE/RX888_english.pdf?cdp=a&_=1806ad658e7It seems to have been built to just stream baseband over usb3. Costs $180.

author: 240RS
author_rank: Regular Contributor
timestamp: June 15, 2023, 02:01:11 pm
content: Found the schematics and the idea is very simple:- 16 bit 105MSPS ADC (via simple filtering connected to input SMA- output lines of ADC connected to this boardhttps://www.infineon.com/cms/en/product/evaluation-boards/cyusb3kit-003/Sounds, very, very simple this way.

author: radiolistener
author_rank: Super Contributor
timestamp: June 15, 2023, 11:36:59 pm
content: Quote from: 240RS on June 15, 2023, 02:01:11 pmYes, but it requires very powerful desktop PC with a top CPU like i7 in order to use such bandwidth.This is the main con of that Chinese RX888 receiver, it requires a lot of CPU power. It doesn't have onboard FPGA to do digital frequency down conversion in hardware before transfer stream to PC (to reduce required transfer speed and CPU load).

author: 240RS
author_rank: Regular Contributor
timestamp: June 16, 2023, 01:46:47 pm
content: Quote from: Nominal Animal on June 03, 2023, 04:53:24 amOrdered the FX3 003 kit as part of RX888 mk2 (china, 180$ eBay). It has a 130MSPS 16bit ADC and a clock circuit. Is quite some value for money then. The 001 kits can be had on ebay (150$).Received a Leo Bodnar clock generator today since the RX888 clock has horrible specs (40ps jitter).Have a 4 year old i7 desktop. Was top of the bill then (according to the company building it for me then :-)).Next step will then be understanding how to configure GPIF2 for the FX3 to do its work. The ADC puts 16 bits at the input of the FX3 and has a clock out (“data ready”) hooked up to the FX3 as well. Anybody a keyword for me to google to find a suitable GPIF2 example? I just hope the FX3 can just push data over USB, but maybe there needs to be some pull from the PC. Never programmed with USB. What would be the “hello world” sample of an external data source and a PC as sink?Then on the PC side I want to write some simple C code to handle USB (found ezusb.c) and just store the data to disk (or memory if not fast enough). Hints are appreciated as well. I understand that RX888 users complain about PC load, but isn’t that because they are using SDR tools that do a lot of work?If any of the SBC’s mentioned could handle USB3 and are a preferred method over Windows on an i7, please let me know as well. Maybe Linux is better suited for single tasks than Windows. Having said that, an SBC with SSH on a laptop is so much more convenient.All info you all have provided os so useful. It takes some time to grow into this, but this is encouraging.

author: radiolistener
author_rank: Super Contributor
timestamp: June 19, 2023, 07:24:32 am
content: If you're planning to test it with SBC like RPI4, please let me know what a max speed you can reach on it.

author: 240RS
author_rank: Regular Contributor
timestamp: June 19, 2023, 08:43:18 am
content: Quote from: radiolistener on June 19, 2023, 07:24:32 amI will after I get it working on PC. RPi is the only SBC I know how to work with by the way. The other dropped names I have never seen except beaglebone.I was wrong about the RX888mk2 having a FX3 dev board. The original design had, this one is somewhat more advanced. It has the chip integrated to the pcb. From the radio enthusiasts using it, it is a fine setup for 16bit 64MSPS. The ADC can go to 130 and the FX3 to 100 at 32bits. So my 75 MBPS will be fine. Device will take some time to arrive. I have looked up my PC spec and it is an i7 9700 should be ok if I can get Windows not to do stuff I do not want. That will be a challenge.Next up will be to design a test method to verify I did not drop samples.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 19, 2023, 09:33:31 am
content: RPi 4 is definitely not suitable for this! Its internal bus architecture has bottlenecks that will limits its performance, and I'm not sure it can reach the desired rates even in optimal situations!I would definitely start with a Linux SBC likeOdroid M1with a PCIe 3.0 M.2 two-lane SSD, perhaps a Samsung 980 500 GB or 1 TB one. This ensures you can at least capture the data from USB 3 continuously at 150 MB/s for almost an hour or longer, using a simple capture application or library written in C or C++ (that just reads the bulk USB transfers, and saves them to a file, using large enough buffers); M1 has been benchmarked to easily maintain 1100+ MB/s to a good quality PCIe M.2 SSD. (Pi CM4 tops at 188 MB/s.)With the GbE interface, transferring the raw data to another machine over Ethernet should take less than twice the duration of the capture, too. Or, you can use an external SATA SSD (or USB 3-connected external SSD), and use that to transfer the data between machines.Odroid M1 processor is RockChip RK3568, with four 2 GHz Cortex-A55 cores, a separate Mali G52-2EE OpenGL ES graphics and media controller (does both video decryption and encryption in hardware), and a dedicatedNPU(rknpu2). The NPU is designed to do Caffe/TensorFlow/TensorFlow Lite/ONNX/Darknet/PyTorch neural network and OpenCV processing at a very high rate (0.8 TOPS). The NPU SDK is a 3 GB download, and since I don't have the board myself (yet), I cannot say whether it would be useful for processing the 14/16-bit data or not. I just don't know if the hardware ops it can do are useful for e.g. FFT, because for example the matrix multiplication example (the closest I found to FFT) uses 8-bit integer sources (analogous to samples and coefficients) with 32-bit integer results. 16×16-bit multiplication to 32-bit results and 32×32-bit multiplication accumulating to 64-bit integers would be pretty optimal for FFT'ing this data.Using two or three A55 cores for FFT processing (using your own code) should however allow you to analyse the data on the RK3568 itself (even during ongoing capture); I just cannot specify the exact rate (FFTs per second for any specific window size), and whether a half-overlap windowed FFT is possible to do in realtime for any specific sample window size. The instruction set architecture is 64-bit ARMv8.2-A, on which doing an FFT on real integer (or fixed point) data, each 32×32-bit multiply-add takes only a single cycle (but each data load and store takes additional cycles, limiting the bandwidth to something like one multiply-add per two to four cycles or so, sustained). It'd definitely need a real-data limited-integer-input FFT implementation to take maximum advantage of the hardware; there are some libraries optimized for Neon, but they tend to use floating-point data only.You could also make that into a GUI, for example displaying the FFT (complex amplitudes) using OpenGL ES, with proper antialiasing and hardware acceleration, at realtime (but sampled, i.e. windowed at regular intervals, skipping over intervening data), converting it into an appliance.Stored sequences would be easy/easier to display, since there would not be a specific realtime requirement; a controllable timeline and timestamp ought to suffice for examining the data. (Doing this right also involves using cpusets, nice, and ionice in Linux, to ensure the processing and I/O priorities are correct, and the data capture and storage is prioritized over the GUI.)You can do the GUI even without X, either on top of plain DRI OpenGL ES as a full-screen application (although text and fonts are a bit of a pain then), or using e.g. Qt on top of raw framebuffer.None of what I've described in this thread is an 'off-the shelf' or even 'combine existing open-source software' solution; I am assuming OP is willing to experiment and develop the necessary software (using mostly, but not exclusively, existing libraries) themselves.

author: 240RS
author_rank: Regular Contributor
timestamp: June 19, 2023, 12:26:54 pm
content: Very helpful to explain Odroid specs and hardware setup. Thanks! The Samsung 500GB SSD is easy to find and fits like this: