Re: burst mode for hackrf one

[Marcus Müller]

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