burst mode for hackrf one
Unfortunately it seem I put the cart before the horse by having submitted a bug request about something I expected to work but now find needs more thought. I hope this mailing list is the right place for discussion. HackRF One is a device designed for half duplex operations, this is why I believe it is safe to assume it will be able to do burst transmissions on a hardware level. Unfortunately the gr-soapy driver, which implements burst transmission which will work with UHD (at least I have been told so), don't work with the SoapyHackRF driver to do burst mode. So far I have not found a description or even mentioning of burst mode in the soapy driver model documents. Since I was told the gr-soapy driver will work with UHD I was looking for a SoapyUHD or the like, but there is none. I found Soapy BladeRF Sink Soapy Custom Sink Soapy HackRF Sink Soapy LimeSDR Sink Soapy PLUTO Sink however not Soapy UHD Sink. What am I misunderstaning here? Has anyone already considered burst mode or has experience with any of BladeRF, LimeSDR or PLUTO drivers? Thank you for consideration, Roland OpenPGP_signature Description: OpenPGP digital signature
Re: burst mode for hackrf one
Hi Roland, On 05.11.22 14:00, Roland Schwarz wrote: Unfortunately it seem I put the cart before the horse by having submitted a bug request about something I expected to work but now find needs more thought. Ha! "I, as a user, am in a reasonable expectation that something should work, now I figure it doesn't" might also indicate that some things might be in need of better documentation! I hope this mailing list is the right place for discussion. So far it's been a fantastic place :) HackRF One is a device designed for half duplex operations, this is why I believe it is safe to assume it will be able to do burst transmissions on a hardware level. There's a TX amp/RX amp/bypass switch (U12/U14), controlled by the logic, which could indeed be used for rapidly switching off TX. Unfortunately the gr-soapy driver, which implements burst transmission which will work with UHD (at least I have been told so), don't work with the SoapyHackRF driver to do burst mode. I guess what that means is that when the Soapy sink is in tagged bursts mode (you set a length tag), it will set the the SOAPY_SDR_END_BURST flag at the right point after a length tag, before sending the samples and flags off to the underlying device driver. UHD knows how to deal with that; there's a mechanism to transport that "OK, and after that last sample of this sample packet, you stop transmitting" info from PC to do device. So far I have not found a description or even mentioning of burst mode in the soapy driver model documents. Since I was told the gr-soapy driver will work with UHD I was looking for a SoapyUHD or the like, but there is none. Dunno where you look, but at the place where JBlum keeps his SoapySDR, he also keeps his SoapyUHD: https://github.com/pothosware/SoapyUHD I found Soapy BladeRF Sink Soapy Custom Sink Soapy HackRF Sink Soapy LimeSDR Sink Soapy PLUTO Sink however not Soapy UHD Sink. What am I misunderstaning here? These sinks are just "convenience sinks". SoapySDR is a plugin architecture: there's just actually one block, the Soapy sink, and it doesn't know which hardware you have, or how to talk to that – but you can install plugins for SoapySDR that actually know hardware, and then you can stream to that hardware. These inidividual sinks just "pre-fill" all the configuration so that this type of device is used, and that the device-specific settings are done. Has anyone already considered burst mode or has experience with any of BladeRF, LimeSDR or PLUTO drivers? No experience on my side with TX bursting. But, source code tells me the SoapySDR driver for HackRF does support handing down the "end of stream" information to the device: https://github.com/pothosware/SoapyHackRF/blob/4e40fa19fa3b64f335d48ce112859acbaecee6c4/HackRF_Streaming.cpp#L386 So, should work the same as when using a USRP instead of a HackRF. Best regards, Marcus
Re: burst mode for hackrf one
On 05/11/2022 10:39, Marcus Müller wrote: Hi Roland, On 05.11.22 14:00, Roland Schwarz wrote: Unfortunately it seem I put the cart before the horse by having submitted a bug request about something I expected to work but now find needs more thought. Ha! "I, as a user, am in a reasonable expectation that something should work, now I figure it doesn't" might also indicate that some things might be in need of better documentation! I hope this mailing list is the right place for discussion. So far it's been a fantastic place :) HackRF One is a device designed for half duplex operations, this is why I believe it is safe to assume it will be able to do burst transmissions on a hardware level. There's a TX amp/RX amp/bypass switch (U12/U14), controlled by the logic, which could indeed be used for rapidly switching off TX. Unfortunately the gr-soapy driver, which implements burst transmission which will work with UHD (at least I have been told so), don't work with the SoapyHackRF driver to do burst mode. I guess what that means is that when the Soapy sink is in tagged bursts mode (you set a length tag), it will set the the SOAPY_SDR_END_BURST flag at the right point after a length tag, before sending the samples and flags off to the underlying device driver. UHD knows how to deal with that; there's a mechanism to transport that "OK, and after that last sample of this sample packet, you stop transmitting" info from PC to do device. So far I have not found a description or even mentioning of burst mode in the soapy driver model documents. Since I was told the gr-soapy driver will work with UHD I was looking for a SoapyUHD or the like, but there is none. Dunno where you look, but at the place where JBlum keeps his SoapySDR, he also keeps his SoapyUHD: https://github.com/pothosware/SoapyUHD I found Soapy BladeRF Sink Soapy Custom Sink Soapy HackRF Sink Soapy LimeSDR Sink Soapy PLUTO Sink however not Soapy UHD Sink. What am I misunderstaning here? These sinks are just "convenience sinks". SoapySDR is a plugin architecture: there's just actually one block, the Soapy sink, and it doesn't know which hardware you have, or how to talk to that – but you can install plugins for SoapySDR that actually know hardware, and then you can stream to that hardware. These inidividual sinks just "pre-fill" all the configuration so that this type of device is used, and that the device-specific settings are done. Has anyone already considered burst mode or has experience with any of BladeRF, LimeSDR or PLUTO drivers? No experience on my side with TX bursting. But, source code tells me the SoapySDR driver for HackRF does support handing down the "end of stream" information to the device: https://github.com/pothosware/SoapyHackRF/blob/4e40fa19fa3b64f335d48ce112859acbaecee6c4/HackRF_Streaming.cpp#L386 So, should work the same as when using a USRP instead of a HackRF. Best regards, Marcus I will also point out that it's naive to assume that all SDR hardware supports the same set of features, or even that those features are implemented in the same way. Once you move beyond the basic "stream some samples in either direction" usage model, each SDR can be fairly different in terms of feature sets. USRPs have historically offered the richest feature set in order to support "bursts" and precisely-timed transmission, etc. Many of the other SDRs are catching up to this, and some will never have anything beyond the basic streaming model. Now *some* of this can kind of sort of be "faked" in the drivers. But things like hardware-precise burst timing? Nope. That requires hardware support, and unless the target hardware was "born" with that hardware support, no amount of "faking it" with software will help...
Re: burst mode for hackrf one
Am 05.11.22 um 16:01 schrieb Marcus D. Leech: I will also point out that it's naive to assume that all SDR hardware supports the same set of features, or even that those features are implemented in the same way. I fully understand, that it's naive to assume that all SDR hardware supports the same set of features, or that those features are implemented in the same way. I never complaint that the behavior is different from my expectations. (I inadvertently filed a bug, sorry for that.) Instead I am just looking for the correct point to start, without reinventing the wheel. Since documentation on the topic is sparse and understanding the data flow from looking at three different layers, which are not implemented in the same way as you say is hard, I thought I could try to get some insight from the knowledgeable's on this list. :-) Now *some* of this can kind of sort of be "faked" in the drivers. But things like hardware-precise burst timing? Nope. As a first step I am not looking for 'precise' burst timimg. When I create a burst PDU and convert it with PDU to Stream I am happy if that packet is sent out by the transmitter. Currently the send buffer waits until it is full before any data gets out of the tx. That requires hardware support, and unless the target hardware was "born" with that hardware support, no amount of "faking it" with software will help... Hmm, not sure I understand you here. HackRF One for sure is a cheap piece of hardware which likely has no sophisticated tx/rx timing control. But turning on the transmitter when a burst packet is available and turning it off when the burst is complete does not sound insurmountable to me. Please don't get me wrong: I am not looking for fast TX/RX half duplex control currently. I do understand that this will be possibly not doable with GnuRadio because there is no combined sink and source device concept available. Sending out bursts, however, should be possible. As already said: I am seeking advice for the best starting point, considering my "problem". Shall I tinker with the three levels of gr-soapy which makes use of the Photos HackRF soapy driver, which in turn uses libhackrf, or shall I better write my own specific gr driver which directly depends on libhackrf? Roland OpenPGP_signature Description: OpenPGP digital signature
Re: burst mode for hackrf one
Am 05.11.22 um 15:39 schrieb Marcus Müller: Dunno where you look, but at the place where JBlum keeps his SoapySDR, he also keeps his SoapyUHD: https://github.com/pothosware/SoapyUHD Thank you for the link. I was just looking in the gnuradio gr-soapy driver and discovered that it hands off processing to the photos driver for hackrf, which in turn uses libhackrf. These sinks are just "convenience sinks". SoapySDR is a plugin architecture: there's just actually one block, the Soapy sink, and it doesn't know which hardware you have, or how to talk to that – but you can install plugins for SoapySDR that actually know hardware, and then you can stream to that hardware. Hmm, can it be the case, that this convenience stub is just missing from the palette that is visible to GRC? I checked my ubuntu package repo, where I can clearly see that I have installed the soapysdr-module-uhd. No experience on my side with TX bursting. But, source code tells me the SoapySDR driver for HackRF does support handing down the "end of stream" information to the device: https://github.com/pothosware/SoapyHackRF/blob/4e40fa19fa3b64f335d48ce112859acbaecee6c4/HackRF_Streaming.cpp#L386 Indeed this is the very same place I "landed". Following the source, however, shows that this code is only touched when the device is opened, i.e. where the gr-soapy driver block_impl::start() calls the activateStream function. So, should work the same as when using a USRP instead of a HackRF. To me it seems the SOAPY_SDR_END_BURST flag does not get handled in the code path of the HackRF writeStream function at all. Considering what you told me regarding the fact that the gr-soapy is a generic driver, I should look for changing the HackRF photos/soapy driver, because the gr-driver is device agnostic. Hmm, couldn't it be the case that the HackRF soapy driver requires just a different call sequence to make bursts happen? E.g. calling activateStream for every burst that is to come? If this is the case this would be bad since then both drivers are "correct" but their interworking will yield different results depending on which plugin is used, which is also a bad thing since it invalidates the whole idea of abstraction. What do you think? Roland OpenPGP_signature Description: OpenPGP digital signature
Re: Running flowfraph dies with segfault with GR 3.10.4 (gr-fosphor)
Hi Ville, On 04/11/2022 17.35, Ville Eerola wrote: > Thread 1 "python3" received signal SIGSEGV, Segmentation fault. > 0x7fff458b5fe5 in ?? () from > /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 > (gdb) bt > #0 0x7fff458b5fe5 in () at > /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 > #1 0x7fff45961927 in () at > /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 > #2 0x7fff458c193f in gr::block::allocate_detail(int, int, > std::vector > const&, std::vector std::allocator > const&, std::vector std::allocator > const&) () at > /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 > #3 0x7fff458d628e in > gr::flat_flowgraph::allocate_block_detail(std::shared_ptr) > () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 > #4 0x7fff458d7845 in gr::flat_flowgraph::setup_connections() () at > /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 > #5 0x7fff4590d40b in gr::top_block_impl::start(int) () at > /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 > #6 0x7fff4590d7f6 in gr::top_block::start(int) () at > /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 So this segfault happens during block allocation and initialization. Check if you have multiple versions of libgnuradio-fosphor.so or fosphor_python*.so installed at the same time. ls -alt /usr/lib/x86_64-linux-gnu/libgnuradio-fosphor.so* /usr/lib/python3/dist-packages/gnuradio/fosphor/fosphor_python* If you have multiple versions then remove them all and reinstall gr-fosphor. >>> - In order to rectify this I have updated all the OOT modules from Osmocom, >>> which I had previously installed with: >>> $ cd / >>> $ rm -rf build; Ideally before removing the build directory you should have uninstalled previous version by running `make uninstall` Best Regards, Vasil
Re: burst mode for hackrf one
Hi Roland, On 05.11.22 14:00, Roland Schwarz wrote: Unfortunately it seem I put the cart before the horse by having submitted a bug request about something I expected to work but now find needs more thought. Ha! "I, as a user, am in a reasonable expectation that something should work, now I figure it doesn't" might also indicate that some things might be in need of better documentation! I hope this mailing list is the right place for discussion. So far it's been a fantastic place :) HackRF One is a device designed for half duplex operations, this is why I believe it is safe to assume it will be able to do burst transmissions on a hardware level. There's a TX amp/RX amp/bypass switch (U12/U14), controlled by the logic, which could indeed be used for rapidly switching off TX. Unfortunately the gr-soapy driver, which implements burst transmission which will work with UHD (at least I have been told so), don't work with the SoapyHackRF driver to do burst mode. I guess what that means is that when the Soapy sink is in tagged bursts mode (you set a length tag), it will set the the SOAPY_SDR_END_BURST flag at the right point after a length tag, before sending the samples and flags off to the underlying device driver. UHD knows how to deal with that; there's a mechanism to transport that "OK, and after that last sample of this sample packet, you stop transmitting" info from PC to do device. So far I have not found a description or even mentioning of burst mode in the soapy driver model documents. Since I was told the gr-soapy driver will work with UHD I was looking for a SoapyUHD or the like, but there is none. Dunno where you look, but at the place where JBlum keeps his SoapySDR, he also keeps his SoapyUHD: https://github.com/pothosware/SoapyUHD I found Soapy BladeRF Sink Soapy Custom Sink Soapy HackRF Sink Soapy LimeSDR Sink Soapy PLUTO Sink however not Soapy UHD Sink. What am I misunderstaning here? These sinks are just "convenience sinks". SoapySDR is a plugin architecture: there's just actually one block, the Soapy sink, and it doesn't know which hardware you have, or how to talk to that – but you can install plugins for SoapySDR that actually know hardware, and then you can stream to that hardware. These inidividual sinks just "pre-fill" all the configuration so that this type of device is used, and that the device-specific settings are done. Has anyone already considered burst mode or has experience with any of BladeRF, LimeSDR or PLUTO drivers? No experience on my side with TX bursting. But, source code tells me the SoapySDR driver for HackRF does support handing down the "end of stream" information to the device: https://github.com/pothosware/SoapyHackRF/blob/4e40fa19fa3b64f335d48ce112859acbaecee6c4/HackRF_Streaming.cpp#L386 So, should work the same as when using a USRP instead of a HackRF. Best regards, Marcus
Re: burst mode for hackrf one
Hi Roland, Hmm, can it be the case, that this convenience stub is just missing from the palette that is visible to GRC? I checked my ubuntu package repo, where I can clearly see that I have installed the soapysdr-module-uhd. I'm not even sure such a convenience stub exist. I haven't checked. It's pretty likely that it doesn't – GNU Radio can't check for all possible soapy plugins at GNU Radio installation time, that's the point of having plugins. But, source code tells me the SoapySDR driver for HackRF does support handing down the "end of stream" information to the device: https://github.com/pothosware/SoapyHackRF/blob/4e40fa19fa3b64f335d48ce112859acbaecee6c4/HackRF_Streaming.cpp#L386 Indeed this is the very same place I "landed". Following the source, however, shows that this code is only touched when the device is opened, i.e. where the gr-soapy driver block_impl::start() calls the activateStream function. ah, you're right, it seems. So, should work the same as when using a USRP instead of a HackRF. To me it seems the SOAPY_SDR_END_BURST flag does not get handled in the code path of the HackRF writeStream function at all. Yep, seems to be missing. Considering what you told me regarding the fact that the gr-soapy is a generic driver, I should look for changing the HackRF photos/soapy driver, because the gr-driver is device agnostic. Exactly! Hmm, couldn't it be the case that the HackRF soapy driver requires just a different call sequence to make bursts happen? E.g. calling activateStream for every burst that is to come? If this is the case this would be bad since then both drivers are "correct" but their interworking will yield different results depending on which plugin is used, which is also a bad thing since it invalidates the whole idea of abstraction. What do you think? I think: Ah. So, the HackRF wants to know how many samples are there on the end of a burst. But that wouldn't stop you from using the same flag handling in the writeStream, as far as I can tell. The thing is though that I don't know how much you'd need to re-initialize after. So, whether you'd want to refactor the activateStream method to extract the part that you would have to do the moment after you've finished a burst to get ready for the next batch of samples. Cheers, Marcus
Please ignore previous email (was: burst mode for hackrf one)
seems like I somehow managed to send this twice. On 05.11.22 20:23, Marcus Müller wrote: Hi Roland, On 05.11.22 14:00, Roland Schwarz wrote: Unfortunately it seem I put the cart before the horse by having submitted a bug request about something I expected to work but now find needs more thought. Ha! "I, as a user, am in a reasonable expectation that something should work, now I figure it doesn't" might also indicate that some things might be in need of better documentation! I hope this mailing list is the right place for discussion. So far it's been a fantastic place :) HackRF One is a device designed for half duplex operations, this is why I believe it is safe to assume it will be able to do burst transmissions on a hardware level. There's a TX amp/RX amp/bypass switch (U12/U14), controlled by the logic, which could indeed be used for rapidly switching off TX. Unfortunately the gr-soapy driver, which implements burst transmission which will work with UHD (at least I have been told so), don't work with the SoapyHackRF driver to do burst mode. I guess what that means is that when the Soapy sink is in tagged bursts mode (you set a length tag), it will set the the SOAPY_SDR_END_BURST flag at the right point after a length tag, before sending the samples and flags off to the underlying device driver. UHD knows how to deal with that; there's a mechanism to transport that "OK, and after that last sample of this sample packet, you stop transmitting" info from PC to do device. So far I have not found a description or even mentioning of burst mode in the soapy driver model documents. Since I was told the gr-soapy driver will work with UHD I was looking for a SoapyUHD or the like, but there is none. Dunno where you look, but at the place where JBlum keeps his SoapySDR, he also keeps his SoapyUHD: https://github.com/pothosware/SoapyUHD I found Soapy BladeRF Sink Soapy Custom Sink Soapy HackRF Sink Soapy LimeSDR Sink Soapy PLUTO Sink however not Soapy UHD Sink. What am I misunderstaning here? These sinks are just "convenience sinks". SoapySDR is a plugin architecture: there's just actually one block, the Soapy sink, and it doesn't know which hardware you have, or how to talk to that – but you can install plugins for SoapySDR that actually know hardware, and then you can stream to that hardware. These inidividual sinks just "pre-fill" all the configuration so that this type of device is used, and that the device-specific settings are done. Has anyone already considered burst mode or has experience with any of BladeRF, LimeSDR or PLUTO drivers? No experience on my side with TX bursting. But, source code tells me the SoapySDR driver for HackRF does support handing down the "end of stream" information to the device: https://github.com/pothosware/SoapyHackRF/blob/4e40fa19fa3b64f335d48ce112859acbaecee6c4/HackRF_Streaming.cpp#L386 So, should work the same as when using a USRP instead of a HackRF. Best regards, Marcus
Re: burst mode for hackrf one
On 05/11/2022 12:14, Roland Schwarz wrote: I never complaint that the behavior is different from my expectations. (I inadvertently filed a bug, sorry for that.) Instead I am just looking for the correct point to start, without reinventing the wheel. Since documentation on the topic is sparse and understanding the data flow from looking at three different layers, which are not implemented in the same way as you say is hard, I thought I could try to get some insight from the knowledgeable's on this list. :-) Now *some* of this can kind of sort of be "faked" in the drivers. But things like hardware-precise burst timing? Nope. As a first step I am not looking for 'precise' burst timimg. When I create a burst PDU and convert it with PDU to Stream I am happy if that packet is sent out by the transmitter. Currently the send buffer waits until it is full before any data gets out of the tx. So it seems that the question you're *actually* asking is somewhat disjoint from the question I *thought* you were asking-- my apologies. It *sounds* like you want to understand how to get "bursty" behavior from Gnu Radio's overall "streaming" doctrine--and THAT is only tangentially related to the underlying hardware. "I created a PDU, sent it through the modulators, but the resulting buffer is small enough that it's getting 'hung up' inside GR". Since I'm not a TX guy primarily, I'm not actually sure how this is dealt with, and others might have some insights--there have been a crap-tonne of people who have used GR for TX, and often in "bursty" mode--like sending CW on HF, for example. One technique that likely works OK is "zero stuffing". You send a constant stream of 0s in "idle" state, and when a PDU comes along it interrupts the otherwise-boring stream of 0s.
Re: burst mode for hackrf one
On Saturday, 5 November 2022 22:39:13 EET Marcus D. Leech wrote: >One technique that likely works OK is "zero stuffing". You send a > constant stream of 0s in "idle" state, and when a PDU comes >along it interrupts the otherwise-boring stream of 0s. That's not good if the TX path includes an RF switch, like the TX/RX port on the B200 family. IIRC without using tags on a semi-duplex device a constant stream will keep the TX path on as long as samples are flowing. There must be an end of burst flag that tells the device to empty the buffer and switch on the RX path. The LMS api has such a flag, but I'm not familiar with the HackRF. I suggest digging into libhackrf code to check if it does. Adrian
