search

greatscottgadgets / hackrf

low cost software radio platform
https://greatscottgadgets.com/hackrf/
GNU General Public License v2.0
6.52k stars 1.52k forks source link

Fast RX/TX switching #745

Closed FabianSchwartau closed 3 years ago

FabianSchwartau commented 4 years ago

Hi everyone, I am currently thinking about a project where I would need an SDR to switch between RX/TX relatively fast. I'd like to know if the HackRF can do this (by now). I read quite a bunch of similar questions, but most of them where from 2016/2017. They all suggest to use soapy for that. Yes, that works for me in gnuradio, but it is horribly slow. Like there is a constant tone of ~300ms before it even starts transmitting the data after switching to transmit. I looked at the libhackrf API but could not find anything about that topic. I will need to make precise switches down to ~1 ms. I know the switch times in advance, so USB should not be a bottle neck in that case. Did I missed something? Is that possible? Best regards

WangMinSSS commented 4 years ago

I have a same problem, how fast could the hackRF switch between RX/TX? I look the circuit diagram of hackRF, the switch chip is SKY13350-385LF, datasheet says switch rise/fall time is 45ns, is this the minimum switch speed of hackRF?

FabianSchwartau commented 4 years ago

Wow... no... That depends on how you switch it. To my best knowledge, you currently need to uninitialize the full library and initialize it again to switch between TX/RX, which takes at least a couple of 100ms in my tests. If someone would modify the software to support on-the-fly switching it would be much faster, but you will probably not get much below 1ms due to USB delays. An other option, which would also need to be implemented, is that you can tell the device in advance when to switch (at a certain timestamp), then you would get down to the CPLD/FPGA (?) clock cycle.

WangMinSSS commented 4 years ago

Wow... no... That depends on how you switch it. To my best knowledge, you currently need to uninitialize the full library and initialize it again to switch between TX/RX, which takes at least a couple of 100ms in my tests. If someone would modify the software to support on-the-fly switching it would be much faster, but you will probably not get much below 1ms due to USB delays. An other option, which would also need to be implemented, is that you can tell the device in advance when to switch (at a certain timestamp), then you would get down to the CPLD/FPGA (?) clock cycle.

Oh, thank you for your answer. Maybe I need to find other SDR device, what I need is 1us switch speed. Do you have some advise?

FabianSchwartau commented 4 years ago

As I said, that depends on many things. If you cannot predict when exactly you want to switch (in the future) this is not possible with USB, probably not even with PCI-E. Even if PCI-E could do that, the Task/Thread Scheduler of your OS is probably running somewhere in the range of 1ms, so you cannot guarantee that it will work as your application is simply not running at that moment. You would have to use some Real-Time OS. So, you have to do your processing on the SDR itself (in the FPGA/CPLD). Here you have quite a lot of options, including HackRF, BladeRF, USRP, Adaplm-Pluto, and many more. If you cannot or do not want to write your own FPGA/CPLD code, you have to know in advance when you want to switch. I have done that with the Ettus X310 (I think it can go down to 5ns resolution as the FPGA is running at 200 MHz), but it is a horrible pain to write that code. I had to work around a couple of ugly bugs in the firmware and although we payed Ettus a butload of money for the two devices, the support was basically not existent. I even provided minimal (non-)working examples, and they were not able to resolve the issue, even after a year (sorry for the rant). So, that are your only two options. Can you say more about your application? - I am just curious :)

WangMinSSS commented 4 years ago

As I said, that depends on many things. If you cannot predict when exactly you want to switch (in the future) this is not possible with USB, probably not even with PCI-E. Even if PCI-E could do that, the Task/Thread Scheduler of your OS is probably running somewhere in the range of 1ms, so you cannot guarantee that it will work as your application is simply not running at that moment. You would have to use some Real-Time OS. So, you have to do your processing on the SDR itself (in the FPGA/CPLD). Here you have quite a lot of options, including HackRF, BladeRF, USRP, Adaplm-Pluto, and many more. If you cannot or do not want to write your own FPGA/CPLD code, you have to know in advance when you want to switch. I have done that with the Ettus X310 (I think it can go down to 5ns resolution as the FPGA is running at 200 MHz), but it is a horrible pain to write that code. I had to work around a couple of ugly bugs in the firmware and although we payed Ettus a butload of money for the two devices, the support was basically not existent. I even provided minimal (non-)working examples, and they were not able to resolve the issue, even after a year (sorry for the rant). So, that are your only two options. Can you say more about your application? - I am just curious :)

yeah, I thought about using FPGA embed in SDR, but I don't know how. I used ADALM-PLUTO and NI USRP, but those SDR need to work in coordination with PC both. You meaning to rewrite the firmware of SDR? and could the SDR device work without PC?

haha, it's not an application yet, which is my course experiment. I am a graduate student now. In my plan, I want to use SDR receive a signal and then retransmit it very quickly. So I need the switch speed is quick.

FabianSchwartau commented 4 years ago

Yes, you would have to more or less do that completely on the FPGA. There is something called RFNoC (at least for the USRPs), which - as far as I understood - are building blocks (like in gnuradio maybe?) you can use and it will build an individual FPGA image without coding (too much?) vhdl/verilog code. But maybe I am completely wrong about that, have never worked with it, but that is what I understood from reading about it here and there. I am more of an analog RF guy, less software. I would use the SDR to loop the signal with a defined delay and use hardware to figure out when to switch. You can use some sort of power detection to detect the start/stop of a transmission and use that to toggle an RF switch. That is pretty common in amplifiers that you can connect for example to your Wifi device to amplify it. It also detects when your device starts to transmit and quickly switches on the transmit path. But you have to know the length of the signal in advance. Its hard to come up with a good solution, if you cannot say anything else about the application.

mossmann commented 3 years ago

Interesting conversation! Unfortunately we will never be able to achieve TX/RX switching on HackRF One anywhere near as fast as 1 us. I believe that would require a full-duplex transceiver, and you would probably have to write firmware/gateware for the device to achieve such speeds. We may be able to approach 1 ms if we were to implement timed operations (#86), but we do not have a solution at this time. If you make any progress in this area, please add to #86.