Re: burst mode for hackrf one

[Marcus D. Leech]

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...