Thanks for checking out pre-cog. I’m not sure what “algorithm” you’d
it, or if calling it an “algorithm” might be giving the implementation
more credit than it deserves, but here is the basic MO of the FHSS
All I/O is to/from the FHSS_hier implementations is done with
passing - currently of gr-extras variety. Someday, with Johnathan
help this may get converted to the new message passing API in
The TX blocks read the rx sample stream from the USRP, pull off
stream tags, and count samples to maintain an awareness of the USRP
It tracks this time, and when a target time elapses, the block issues
tuning command via XML_RPT, and a timed burst via tagged sample
a stream. After each time, we set the next time we want to transmit.
reality, the act of issuing the tune command and sending a burst
some time (1-5 ms) before the actual burst occurs. The frequencies
provided to the block as a parameter - comma delimited text.
On the receive side, the FHSS simply tunes the USRP to the first
frequency of the frequency list. It waits here until it receives a
packet - then it uses a similar process to (2) to start hopping in
This was a basic demo of how to use stream tags and message passing to
integrate control functions in a GRC flowgraph. There’s a lot of
improvements - its slow, it could be converted to C++, etc. Once you’ve
got the basics up and running, I do invite contributions to pre-cog or
I’ve attached files for an FHSS transceiver, but I’d start off with the
simplex examples in the repo.
I want to build frequency hopping transmitter receiver for PUs.
The primary users will be hopping in a given no of bands and secondary
users will opportunistically sense empty band and communicate with each
Now the problem is how do I synchronize receiver and transmitter while
You wrote fssh_engine.py. But I did not understood much through it as I
not so well familiar with pmt,blob and gr-extras.
So I was interested in knowing the algorithm so that I can write codes
the hopping synchronization.
I am more interested in using python scripts and Gnu Radio support to
design the synchronized hopping.
Suppose the transmitter has a list of hopping frequencies and so does
receiver.Now primary starts transmitting and receiver has to sense which
channel primary is transmitting and insure locking.
There is certain lag associated with USRP and this should be taken in to
account for synchronization.
Based on what you said in your last paragraph I think you’ve got a good
high level understanding of how thing are working. I have to step out
a few hours, but I should be able to answer in more detail later. If
you’re going to be working in the mean time, you might read up on some
I’m curious about how it tune the LO in USRP. Does it control the LO
Well, current pre-cog uses the v3.6 gr-extras out of tree message
passing to execute functions on the USRP python object. Basically the
control block would pass some sort of PMT to an output message port,
this would go to the input port of the PMT RPC block, which would then
execute a function on the usrp object in the python flowgraph.
That works, but no one is really endorsing that particular method. Think
of it as a one-off to set things working. What I think we really want is
a good API friendly framework supported way to set properties on blocks.
Given that I have learned a lot from the pre-cog development struggles,
GRAS now has a programmatic way for blocks to register properties and
access the properties of other blocks.
USRP control block to set properties on:
Now the code in fhss_engine, might look more like this (thanks Yogesh):