[Hackrf-dev] How to do retunes in firmware ?

[Dominic Spill]

On 13 July 2016 at 02:47, Patrick Sathyanathan <wpats at hotmail.com> wrote:
>
> Thanks for the info. I have been looking at the firmware code in
.../hackrf/firmware/hackrf_usb and I see there is a "main" function in
hackrf_usb.c. I'm not sure I understand the control-flow. After doing some
initialization there seems to be a loop transferring buffers 0/1. Is this
loop where I should insert my periodic retuning code ?

Yes, if you want something to happen after N buffers, then you can count
them there and call the code at that point.  Alternatively you could set a
timer, but that wouldn't be synced to the number of buffers.

>
> Is there a document that outlines the design of the firmware ? Something
that outlines the major modules and that could point me to where I need to
make my modifications  ?

As far as I know there isn't any documentation on how the firmware is put
together.  You seem to be doing a good job of working it out from the code,
but if you have any questions, IRC or this mailing list are good places to
ask.

Thanks,
  Dominic

> ________________________________
> From: dominicgs at gmail.com
> Date: Sat, 9 Jul 2016 14:05:47 +0100
> Subject: Re: [Hackrf-dev] How to do retunes in firmware ?
> To: wpats at hotmail.com
> CC: hackrf-dev at greatscottgadgets.com
>
>
> On 8 July 2016 at 03:02, Patrick Sathyanathan <wpats at hotmail.com> wrote:
> >
> > I am trying to use the HackRF-One for fast scanning somewhat like
osmocom_spectrum_sense but using the hackRF library directly. I want to
reduce retune time as much as possible. A recent thread on this list
mentioned that firmware tuning is the fastest. How do I implement periodic
(at fixed intervals) retuning in firmware ? Can I also make my PC
application aware of the current frequency at any time with this ?
>
> The firmware doesn't currently support retuning, so the feature would
need to be added.  You would need to determine a way for the host
application to know what the frequency is, I would suggest either:
> 1) putting the currently tuned frequency at the start of the buffer to be
sent back to the host
> or
> 2) configuring a fixed number of buffers to return to the host between
retuning event
>
> The first means changing the buffer sizes and any complexities involved
with that, the second means synchonisation issues if a transfer is dropped
for any reason
>
> > Is there any sample code I can look at ?
>
> I believe that Mike Walters is currently working on a project with very
similar goals.  I don't know if his code is available yet, but I would
expect it to appear on GitHub when it is.
>
> Dominic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20160713/30dda08d/attachment.html>