Re: burst mode for hackrf one

[Roland Schwarz]

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