Basic burst example to get tx activity at gpio-pin

Projects LimeSDR
#1

Hi,

i want to control a external switch array via LimeSDR-gpio dynamically. One of my first step was to change the value of FPGA Register 00C0 to FFFE to get tx activity on J12 header (Pin 0).
Iḿ using vectors n gnu-radio of some “ones” and “0” to get a periodical tx-burst and was also able to receive signals (two channel MIMO-mode). Unfortunately the J12 Pin 0 is always “high” now. as long as gnu radio is running. Is there a posibility to enable AND disable J12 pin 0 exactly with tx-representation? I have burst times of ~500 ns and periods of ~1-7 µs.

If there is no possibility to do that in gnuradio, i would appreciate a lot to get a basic tx-example (cpp or python) with periodically tx on and off, which is correctly represented by the JPIO-Pin.

Thank You in advance
Andreas

#2

Hi again,

i made some progress acording to the problem mentioned obove.
Found a paper, puplished in 2019 regarding partly what I need:

https://aip.scitation.org/doi/full/10.1063/1.5127746

The puplisher did puplish the gateware and also his API here:
https://sourceforge.net/projects/limr/

With this gateware I get a stable signal at the GPIO (J12) 0-Pin that represents all Tx-Samples (>0). Now I am able to control an external swich array with this signal despite using just pre implemented gnu radio blocks. I find this gateware extremely usfull. But it is based on lime firmware 2.18. Currently I am not familiar with FPGA-programming. But for someone in the field, it might be easy to find out how to change the current gateware using for example LimeSuite with the current firmware for register manipulation?

#3

Hi Andreas

Indeed, an update of the sourceforge page is overdue…(!!!)

I am running on firmware 2.22 since a while and a much more stable ‘RX-TX’ backend. I also have compiled 2.23 firmwares ready, though untested. So just drop me a mail.

It is now also possible to get GPIO control for pure TX applications, where the waveforms are played back from the onboard RAM. Frees USB resources when one needs to make sure that it runs without interrupt over hours.

Other than that, I thought that there was some gateware fork that allows to have GPIO high during TX. No idea about this one, though. If you do not need to explicitly time the GPIOs at the sample rate, this could save some USB bandwidth.

#4

Hi,

oh, best case scenario that especially you, the author of the papers and gateware, provide feedback on this question :-). So thanks, I will definitely get in touch by mail.

Regarding the gateware manipulation: I was only able to get a “high” at GPIO Pin during any activity, even with zero-values, with default gateware so far.