Fast-sweep (similar to hackRF update)

#1

I was wondering if LimeSDR (or more specifically the firmware) can do fast frequency sweep like the update to hackrf. Basically the update doesn’t require continual frequency updates from the computer, so can scan large bandwidths very quickly. Being able to see FFT for the whole 3.8GHz would be so useful.

Example here: http://www.rtl-sdr.com/scanning-spectrum-8ghz-per-second-new-hackrf-update/

1 Like
Re-tune Time
#2

I can’t see any reason this cannot be done, but it will definitely require modifying the FX3 firmware, and maybe also the FPGA (that might give even faster tuning compared to only modifying the FX3 firmware).

The LimeSDR is more similar to the BladeRF architecture wise, but similar tricks have been done for that (see https://www.nuand.com/blog/large-bandwidth/ ). According to the datasheet (available at https://github.com/myriadrf/LMS7002M-docs ) the PLL settling time is max 150 us, so i doubt it will be possible to tune it faster than that.

#3

150us would give a maximum possible bandwidth/second of something like 400GHz/s, discounting the time to actually sample and transfer the 61MHz chunk. More than enough.

I might take the time to have a read of the source. I don’t expect it to make much sense straight away, but it’ll make for interesting reading at any rate.

#4

I don’t claim to know the bottle neck for re tuning though, factors like the speed of the SPI bus, and maybe some other oscillators may be slower. It is also important to keep in mind, as you write, that the radio has to stay for a while on a frequency in order to actually capture data.

If anybody from lime knows the minimum feasible re tuning speed it would be great if they can leave a comment here. Both for similar frequencies (e.g. to cover all of 2400 to 2480 for Bluetooth) and between bands far away e.g. 145 mhz / 430 mhz.
This may also be relevant for people implementing frequency hopping spread spectrum (if all packets doesn’t fit inside the SDR passband).

#5

I’m new to SDR but this reminds me of overclocking and I’d be worried about heat production. Am I wrong to be concerned with more heat when doing this?

What did hackrf do?

#6

I haven’t looked at what is done with HackRF, but the suggestion seems to be to have the FX3 microcontroller or FPGA on the LimeSDR board directly control the tuning (sweeping) of the LMS7002M transceiver, as this could be a lot faster than having software on your PC issuing commands over USB to do this.

Sounds like a fun project for someone and I wouldn’t have imagined this to result in overheating.

#7

My understanding is better and this approach makes sense as you remove the latency induced by USB comms.

#8

Yep, that’s exactly it Andrew. I haven’t looked at the exact functionality but I’m assuming that the firmware can accept a range to sweep. But I do need to take a look to be sure.

#9

According to that Nuand post, they spent a year implementing the feature. They also implemented a full ADS-B decoder in the FPGA. Might be some good info in that project.

1 Like
#10

I would note that the FPGA-based decoder is not open source, as it is licensed only for use with Nuand hardware. Even studying the RTL in order to inform the design of another implementation is likely not advisable.

#11

I can’t argue with what you’re saying but I can say that any examples, even if they don’t apply directly to another project, are useful. But I think you’re saying they are minimally useful. Fair enough.

The code’s not a Rosetta Stone but still can be useful in some ways.

Is anyone at Lime/Myriad interested in implementing this kind of sweep in the firmware/gateware?

It’s really not clear to me what kind of contributions Lime/Myriad are going to spend time/money on. Are we LimeSDR owners now on our own? Or will there be significant contributions from all you all? I’m looking for clarity only not commitments or roadmaps, etc.

#12

No, what I am saying is that studying third party non-open source IP and using that to inform your own design may lead to copyright infringement. I’m not a lawyer, so could be wrong, but there is a reason that projects sometimes go to great pains to do a “cleanroom re-write” of code with copyright/licensing issues.

We — all of us on the forums and working with LimeSDR etc. as users and developers — are Myriad-RF :slight_smile:

Lime will continue to maintain the platform and associated firmware, gateware and SDR driver etc. While also seeking to enable support for new applications where possible. However, there are not unlimited hours in the day and so it’s a question of prioritisation and doing what we can in the time available.

It’s certainly a very interesting application, but I’m not sure what would be involved in creating a custom firmware and/or gateware to support fast sweep. Maybe @Zack could advise.

#13

Well I suppose for the sweep code that makes sense. As for the ADS-B stuff it’s all there in github and could provide some insights into FPGA programming and RF, etc. Maybe not directly applicable to the sweep idea/implementation.

This is good to know and wasn’t clear. Glad you cleared this up.

More clarity and much appreciated. I figure it’ll make things clear for others too.

My naive two cents on the fast sweep is that it could be useful in many situations and would make the LimeSDR a more versatile tool. But as you rightly point out time and priorities are key.

#14

Yes, under a non-open source licence. Personally, if I had the opportunity to look at the source code for something that is proprietary and in an area where I might conceivably want to do development work some day, I’d steer well clear of it. But, that’s just me and this is not legal advice etc. etc. :slight_smile:

#15

Quite important thing that I missed! My god man you’re far too patient. :slight_smile:

No, no, good advice and I agree. I don’t often read licenses. Way back when I got my DE0-Nano I recall reading about different methods used to protect the FPGA IP on-chip. But I also recall that it was all circumvented too. Do you know if that’s still true? Or have they found more ways to prevent it?

My point is that if the ADS-B code is protected under a license, yet available for free, what’s to stop someone from creating their own one-trick pony device for ads-b and selling the device?

#16

Nothing is stopping anyone from copy/pasting the code indeed. The only problem is if they get caught and it can be proven that they didn’t respect the license.

On the fast-sweep front, no one is interested in implementing it? I guess it could be useful to lots of people, but it might indeed be quite a complex task (says he who doesn’t know anything about FPGAs).

Looking at the Nuand API, it seems they schedule retunes in the future to avoid latency issues ( https://www.nuand.com/libbladeRF-doc/v1.7.2/group___f_n___t_u_n_i_n_g.html#ga268b47eb4aed73a8da7a4a65c35cc082 ). I would have imagined a way to tell the FPGA to sweep a specific bandwidth a certain number of time, or for a specific amount of time, or until canceled. It could be nice also to get the FFT straight for spectrum analyzer apps.

#17

I too am very interested in this functionality. I haven’t bought any SDR yet as things keep moving so quickly with new devices and such. My main use will be the spectrum analyzer and waterfall mode. The HackRF and AirSpy do basically what I want but the first has only 8 bits and the second only goes to 2.2 Ghz. Now that LimeSDR is releasing the “LMS8001 Companion” that supports up to 10 GHz. One should in theory be able to have a 100KHz to 10 GHz fast spectrum analyzer for somewhere around $450, all that is missing is the software/firmware. I will continue to wait and see if anyone progress occurs before buying a device as there are already other new devices like the XTRX coming out. I don’t know if it would be possible or make sense, but perhaps we could offer a bounty for the creation of this firmware/fpga functionalit? I’ve never done it before but there appear to be sites like the following https://bountify.co/

#18

what is the status of fast sweep for limesdr-mini?

#19

It has never been implemented, for LimeSDR or LimeSDR mini.

1 Like