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