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

[Patrick Sathyanathan]

Never mind. It looks like I should build "hackrf_usb.bin". That looks the correct size.
 
--Patrick
 
From: wpats at hotmail.com
To: dominicgs at gmail.com
Date: Wed, 13 Jul 2016 19:38:29 -0700
Subject: Re: [Hackrf-dev] How to do retunes in firmware ?
CC: hackrf-dev at greatscottgadgets.com




I have built a version of the firmware following the instructions in the hackrf/firmware/README file. The build produces the following files:
 
hackrf_usb.elf  -> 591408 bytes
hackrf_usb_m0.bin -> 396 bytes
hackrf_usb_m0.elf -> 93992 bytes
 
Compared to the downloaded firmware hackrf_one_usb_rom_to_ram.bin which is of size 20452 bytes the above .bin seems too small.
 
The wiki page says: "When writing a firmware image to SPI flash, be sure to select firmware that is compiled with the "rom_to_ram" option"
 
How do I build with the "rom_to_ram" option ?
 
Thanks,
 
--Patrick
 

 
From: dominicgs at gmail.com
Date: Wed, 13 Jul 2016 12:56:02 +0100
Subject: Re: [Hackrf-dev] How to do retunes in firmware ?
To: wpats at hotmail.com
CC: hackrf-dev at greatscottgadgets.com

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

 		 	   		  

_______________________________________________
HackRF-dev mailing list
HackRF-dev at greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20160713/af52fd53/attachment.html>