I am confused on the best method to control active transmit of the LimeSDR board when in use by gnuradio. When accessed via either the gr-limesdr or osmocom drivers, a constant carrier is always present even if the data is a null source (zeros).
Use of limesdr_sink.stop() which calls LMS_StopStream(&streamId[stored.channel]) has no effect on the carrier. Gain can of course be dropped to zero but that seems to just be ignoring the central issue. Is LMS_EnableChannel() the better route or is that its own set of issues?
Is this just an artifact of the gnuradio general_work coding structure where data is constantly being passed to the device buffer? I’ve seen some discussion of using the UHD style stream controls for transmission tagging which I have used in the past on USRP devices for TDMA signals. Are these actually supported on the lime devices?
My current basic test case is VOX control on NBFM signals with the transmitter going silent to conserve battery power. I am probably just missing the obvious. Any advice is greatly appreciated. Thanks!
what is you LimeSDR hardware version? is it LimeSDR-USB or LimeSDR-Mini?
what is your operating system? what is your version of LimeSuite?
Is lime connected over USB 2.0 or USB 3.0? Get this info from LimeUtil --find.
I am not having any issues with USB communication. The device is working fine. My question is what software API mechanisms are in place in order to control the TX activity of the board from within a streaming gnuradio application. As soon as the board is activated via gr-osmosdr or gr-limesdr it will emit a carrier signal even if the incoming data is a null data source. Is there an already established way to control TX activity via tagging or other mechanism (GPIO?) that enables/disables TX based on software control? Thanks.
Unfortunately, multiplying by 0 or setting gain to 0 is not a very good way to go about this. It’s still transmitting something, even when only fed a stream of zeroes. I know the hardware has it built in, but I haven’t found a way to actually turn off the transmitter yet either.
I confirm. It is only necessary to initialize the module to transmit the carrier no longer turns off.
It is not right. Restarting the project does not result in the carrier signal being turned off.
I can put a video.
Interesting that multiplying by zero worked for you. Perhaps a firmware version difference? In my case both null (zero) and no data (use of the copy block with gui toggle) result in a constant carrier. In the case of the no data, it appears to be just repeating the last buffer received. I can upload some .grc or python files but the basic zero data case is just:
This also worked with LimeSDR with osmocom source and sink. I no longer have it for testing.
Both drop their carrier which was the initial problem I had as well
I will write my thoughts about GNU Radio stream control I have recently discovered (this is not necessary the truth).
GNU Radio has the following ways to stop stream:
stop() function which can be used while running flow graph and is working nicely with QT GUI (for example when you use “Selector” block stop() function is called to prevent unused block from streaming).
Destructor, for example ~sink_impl() which should be called when closing (not killing!) flow graph. However it is not working with QT GUI and only works with WX GUI. I have not found any information to fix this.
Now, to reset device to default state LMS_Reset() should be used. It works when you use it in a destructor, however you can only use it with WX GUI (again, destructor is just not called with QT GUI). When you put it in stop() function it works well with QT GUI and WX GUI however when you use blocks like “Selector” calling stop() function instantly resets device to it’s default state and it is not possible to recover current stream. The only way is to restart flow graph in order to set device correctly and initialize stream.
Thats why most of you see one carrier after closing flow graph (the device is configured but cannot be reset). What are your thoughts about this problem?
Thank you for your example! I think the key was the offset plus bandpass but am still not sure. Simply zeroing out the audio did not drop the carrier for me BUT now the copy “valve” is working perfectly and the carrier drops as expected. Will keep looking in to it to figure out exactly why it works in this case and not others. Thanks again.
Hadn’t noticed the difference in qt and wx before. My thoughts are that: It should be that indeed the carrier transmit should stop when closing a flow graph, only not when stop transmitting inside a flow graph.
The stop might be ok for voice but when using data there is lost time and data when setting and re-tuning every time you want to start and stop transmit within the flow graph.
That is why i used the tx_on switching to multiply the audio, sine ampiltude, Band Pass gain and LimeSuite sink gain with zero when not transmitting. Combined with Sine mixing instead of hardware RF Frequency tune the correct freq.
