Host for LimeSDR

Hello everyone, I was asking if limesdr is able to run in a standalone mode. The answer seems no. I am quite interested in which host can be/have been used.

Please feel free to add the host that you are using in this post. If possible, please also list your development tool.

Some answer from my previous post: tablet, raspberry pi, Odroid-c2.

Thanks.

If you’re like me, you probably just want to turn it on with the settings automatically uploaded to the device?

I use a laptop. My guess is that you want something that can stand alone and also be somewhat autonomous. But I can only guess since you haven’t told us what your constraints are.

Laptops have a built-in battery backup and are quite cheap

  • How much processing power do you need?
  • Does it need to be wx proof?
  • Does it need its own power source or will the location provide power?
  • Will it run 24/7?
  • Will you need remote access?
  • Will remote access be via wifi or ethernet or EME (Earth-To-Moon-To-Earth)?
  • What about size/space?

Etc.

1 Like

Sorry I should have put more information in the initial post.

I am working on a university research project and we are planning to build a network with several LimeSDR boards (e.g., more than ten). The purpose is to carry out experiments and collect real data. Each node may run several minutes, one hour at the maximum, 24/7 is not required, so I presume the data collected won’t be too much.

My plan is using some host to control the LimeSDR and store the data. I will then transfer all the raw data to the laptop for further processing. I want to use some cheap host (cheaper than a laptop).

My concern is how to store the data for further processing. Do you have any advice on this?

Odroid XU4 or UDOO X86 sounds like perhaps the best candidates in terms of price/performance and size. Provided they have sufficient processing power for your given application.

I don’t have an XU4, but I’m tempted to order one to try it out with LimeSDR. Still waiting for my Kickstarter UDOO.

Hi all.
I have a similar need: will run 24/7 unattended, headless and recording radio astronomy data.

Even if I’ve used R-PI-3 until now for other SDRs, I would not be able to use LimeSDR at a sampling rate > 2.4M using the USB 2 port of the R-PI. I already hit that same threshold with simple RTL-SDR dongles…
R-PI’s USB and ethernet go through the same USB host chip so perfs in some scenarios are not ideal.

So I’m interested in the host selection looking at both USB 3 presence, fast ethernet port, proper CPU perf, RAM availability and compatible OSs (my pref is for Debian ).

FYI: there’s a post by @g8sqh mentioning some specific issue on the odroid xu3 and xu4. They could be of some importance to some users depending on the planned usage:

Lot’s more info in that same thread:

  • there’s @martywittrock mentioning he’s using an MSI Cube PC.

  • about the usable sampling rate @Kc7noa writes he “can run 3Ms/s with no decimation on an Odroid-X2 AND Odroid-C2 …”

  • @g8sqh also mentions the ethernet speed available depending on the board, 100 Mbps vs 1 Gbps

finally, just yesterday I was looking at UP boards http://up-shop.org/4-up-boards
they seem to have nice specs but still have to read everything.
Does anyone here have an UP board in use with LimeSDR ?

I’m also considering power needs, selecting the lowest possible in my case and not an easy topic when you also want a fast cpu…

mario

1 Like

Hummm …

I can do 4,500,000 sample rate @60mhz lpf on my Odroid-x2 … Shurly a UX3 can do better …

mario

No question that an ARM board will have better CPU/mW than Intel x86. I abandoned my XU3 as a standalone system (with HDMI display) since there’s a long-term unfixed bug on the X server, and gqrx hit that bug immediately. For this the XU4 should be the same

Running headless I had no problem with CPU upto 15 Msamples/s, but on the XU3 the ethernet is off USB2, so only 100 Mbps. Not sure when that would become a bottleneck for X windows exporting drawing commands. On the XU4 (which is the one you can still buy) the ethernet is 1G, and on one of the USB3 - the other goes to a socket - where you attach the LimeSDR.

Remember the XU3/4 CPU is 4 2.0G ‘big’ cores and 4 1.4G ‘little’ cores. As long as your processing can use multiple cores, then the XU3/4 is a powerful machine for its DC power requirements.

With the XU3/4 you also need to factor in the cost of the eMMC ‘disk’ module - they are much faster than microSD, and you’ll one to get best performance from the Odroid. If you’re doing any serious system-level work I strongly recommend also getting the serial console to USB cable - that way you get access to the u-boot loader and console messages before the screen is booted up.

I may have time next week to see how fast a sample rate the XU3 can handle headless - for you my question is how much processing do you do on the XU3/4, and what is the data rate you need to record, and is that to be recorded on the XU3/4? Modern hard disks over USB3 will sustain (linear) write speed of say 150 Mbytes/s, so you might be able to record 30 Msamples/s quadrature directly on an XU3 - which has 2 USB3 channels brought to 2 sockets. Only problem is you can’t then get the data back over ethernet! On the XU4 you can’t do that trick - you would have to process the data to a lower rate before recording it either to local USB disk (shared with the LimeSDR data) or to remote storage (limited to 1Gbit by the ethernet)

Good luck with the astronomy

–David

1 Like

I quite like the idea of an XU4 + LimeSDR with SoapyRemote and the actual application running on a remote PC. Did this before with an Intel NUC running the server — worked well, but brutal on the LAN :smiley:

Does anyone also have experience on using tablet as the host?
I understand the cost may be higher, but will it be easier to use?
Any comment is welcome.

Do many tablets have USB 3.0? My guess is they would be the least easy to use when compared with a desktop or laptop.

Maybe a stupid question, I presume the USB interface affects how fast the LimeSDR can write the data to the host. So if I don’t have a high requirement on this, USB 2.0 will do. Right?

I think you can use usb 2 with LimeSDR running not at the top sampling rates.

Some additional thoughts: if a tablet has USB-C connector it should support USB 3.1 speed.
I’ve also used my Android phone with a specific app to read rtl-sdr iq stream but a specific driver has been developed and released in order to manage rtl-sdr dongles on android via usb otg cables.

I believe theoretically this could be done as well for LimeSDR but some consideration should be done also on the processing power of the tablet. I mean… should usb-c otg at full speed allow streaming from LimeSDR at max sample rate… the data should still be processed by a cpu capable of sustaining that load… some sort of compromise should be met.

About power on usb otg cables:i believe it’s bidirectional and LimeSDR could receive power from the tablet. Not sure if that could be enough or how much the tablet battery could last.

My 2 cents…
Mario

@g8sqh
I plan to do experiments at different wavelengths.
For example Sun and Jupiter-Io at 15-30 MHz and hydrogen line around 1.4 GHz.
I don’t need to save the raw IQ stream. I would process that on the selected board cpu to get just fft values and store the resulting fft bins at regular time intervals doing scans over a certain bandwidth.
This lowers my needs in terms of local storage speed. Yet I would prefer having a good cpu to run fftw routines possibly in multi threading on some cores.
I’ve already modified and successfully used rtl-power-fftw in its multithreaded version on the r-pi.
I see there is now soapy_power available and I would like to use it in the same way with limesdr.

When I use large integration times speed is not so important. But when I need to see details with lower integration times the cpu speed becomes the bottleneck.

It’s my understanding that currently the fpga on limesdr is not involved in the fft production. Adding that function to the fpga firmware could represent a huge step for my usage scenario but also for those interested in using limesdr as a spectrum analyzer…

A quick look for benchmarks suggests a XU4 is perhaps twice as fast as the Pi 3 http://www.cnx-software.com/2016/04/02/low-cost-development-boards-linux-benchmarks-raspberry-pi-vs-banana-pi-vs-orange-pi-vs-odroid/

I’m sure you’ve already met libfftw - but you need to make sure you have a version compiled to use the NEON instructions for best floating point speed. Also remember to run fftw-wisdom - it takes many hours CPU, but further optimizes FFT speed.

As for running on the FPGA - that would be wonderful, but I can see immense difficulties:

Altera have an FFT library, and it can be run on cyclone IV (our FGPA) https://www.altera.com/en_US/pdfs/literature/ug/ug_fft.pdf
Good so far, but then

1 I’m not on the dev team, so I have no idea how much of the FPGA is unused after it has taken data from the radio and sent to the USB
2 The Altera code is heavily licensed, and likely to be expensive - like thousands of $$. I think I found the relevant item on mouser item 989-IP-FFT - it is listed at £6,483.79 or about $8000 US - and you may need the standard version of Quartus ($2995)

So, unless there is any open-source IP for FFT on altera devices, there’s no way we can get FFT on them without a lot of investment, or a lot of code development. And there may not be enough FPGA spare anyway - the FFT in the user guide gives figures for cyclone V, and it would be a good fraction of our 40K element FPGA. I suspect you first need to see what an XU4 can give with the software tuned for that ARM chip…

Good luck

–David

Hello David and thank you for the precious info.
I will certainly have a look at those benchmarks.
Yes, I know libfftw but I never used fftw-wisdom : will search and read the docs.

Yes, I know… FFT on the FPGA could stay a dream for some time and for sure I would start with squeezing the most out of the host cpu.

regards,
mario

If you look at a some of the Opencores for Verilog FFT’s:

64 point fft/ifft - Overview :: Pipelined FFT/IFFT 64 points processor :: OpenCores

  • FFT unit for 10 bit data and coefficients, and 2 data buffers occupies 1513 CLB slices, 4 DSP48 blocks, and 2,5 kbit of RAM in Xilinx XC4SX25 FPGA, and 700 CLB slices 4 DSP48E blocks, and 2,5 kbit of RAM in Xilinx XC5SX25 FPGA, data buffers are implemented on the distributed RAM.

128 point fft/ifft - Overview :: Pipelined FFT/IFFT 128 points processor :: OpenCores

  • FFT unit for 10 bit data and coefficients, and 3 data buffers occupies 4147 CLB slices, 4 DSP48 blocks, and 5 kbit of RAM in Xilinx XC4SX35 FPGA, and 1254 CLB slices 4 DSP48E blocks, and 5 kbit of RAM in Xilinx XC5VLX30 FPGA.

256 point fft/ifft - Overview :: Pipelined FFT/IFFT 256 points processor :: OpenCores

  • FFT unit for 10 bit data and coefficients, and 2 data buffers occupies 1652 CLB slices, 4 DSP48 blocks, and 2,5 kbit of RAM in Xilinx XC4SX25 FPGA, and 670 CLB slices 4 DSP48E blocks, and 2,5 kbit of RAM in Xilinx XC5SX25 FPGA, data buffers are implemented on the distributed RAM.

OK the above listed resources are for a Xilinx FPGA, and not Altera FPGA used in the LimeSDR, but for simplicity sake if you consider each CLB (configurable logic block) as being a LAB (logic array block), you can see that a FFT does require a lot of resources, the question is how much free resources exist in the LimeSDR FPGA chips ?

LimeSDR-USB  - EP4CE40F23C8N (Cyclone IV E 2475 LABs 39600 LE 1161216 RAM(bits) 328 IOs)
LimeSDR-PCIe - EP4CGX30CF23C7N (Cyclone IV GX 1840 LABs 29440 LE 1105920 RAM(bits) 290 IOs)

I’m sure that some public FFT core could be adapted and squeezed inside the existing FPGA, but I suspect that the FFT size for 12-bit samples would not be very big at all. I would love to be proven wrong though.

Yit would be wonserfull if the fft and I/Q correctiin could be done on the fpga … that should decrease the USB bandwidth load…

@andrewback Hello Andrew, does my above comment make sense? Will LimeSDR work with USB 2 (with a lower data rate)? We are having some Zedboard with USB 2.0. I wonder if I can use them to host the LimeSDR. Thanks.