Official bladeRF forum

I'm working on my Masters Thesis on FHSS in GNURadio. I'm trying to send data packets using a custom spread spectrum frequency hopping schema. Part of the purpose is to build an easily-obscured transmission system so I don't want the radio constantly broadcasting when no data is being sent.

1. The OsmoSDR GRC sink continues to transmit at the center frequency even if no data is received. I need to implement a means to turn the radio off once the packet data has been transmitted, correct?
ref: http://stackoverflow.com/questions/2861 ... not-needed

2. The OsmoSDR sink operates on a single center frequency.

So if I understand both of these limitations correctly, I need to write a new sink block to control the bladerf that will select a frequency (according to criteria that I specify), transmit a particular number of packets/samples, then select another frequency and transmit, etc..... And once all data packets are sent, turn off the transmission. I've looked at jmalsbury's pre-cog code (https://github.com/jmalsbury/pre-cog) which is written in Python, and also doesn't work with GNURadio > 3.7 (I'm running 3.7.5 for now). Should I also consider re-purposing some Bluetooth code?

I've got about 30 days to produce something....

dear Noble ..

Regarding ur first query ..

1. The OsmoSDR GRC sink continues to transmit at the center frequency even if no data is received. I need to implement a means to turn the radio off once the packet data has been transmitted, correct?
ref: http://stackoverflow.com/questions/2861 ... not-needed

yes bladerf continously transmits on CF, i will go by the same answer as posted by Manos ,, to add , after multiplication with vector , the resultant (CF) is reduced to a considerable level .. have used the same method in a project to avoid Self Interfernce to a large extent .. i am not sure that whether it would be sufficient in ur case too ..
there might be one more approach that u can look into .. just go through the Multiple flow graphs in http://gnuradio.org/redmine/projects/gn ... plications ... and the corresponding python example gr-uhd/examples/python/usrp_nbfm_ptt.py .. hope it may prove helpful to you ..

Regarding ur second qstion

2. The OsmoSDR sink operates on a single center frequency

if i have understood ur qstion correctly , then as long you go by In band frequency hopping i-e within the instantaneous bandwidth of sdr , i beleive that wont be any issue , that part can be done by keeping the center freq constant and and carrying out the required signal processing before OsmoSdr block .. if u need to hop out of the band , then u need to use the probe signal vector etc to keep on updating the CF (inside the OsmoSDR sink block) in real time .. However ur hop rate would be then limited to the LOs settling time of SDR .. to my knowledge for bladerf it is in the order of milliseconds ..

All of the above can be accomplished using tag feature , but that is not yet available (as per my knowledge) with bladerf ... if u have to use bladerf for ur project then i beleive u have to go without tags ..
Anyways ,, do let me know if u need any further assistance ..

Regards !

P.S
there was some presentation on similar project given at grcon14 have a look http://static1.1.sqspcdn.com/static/f/6 ... cTmxVFQ%3D

Thanks, actually that does help quite a bit. I'm not a trained eletrical engineer or anything prior to jumping in feet-first to GNURadio, so all this radio stuff makes blood run out of my ears. By re-working the width and number of channels I had planned I can make the whole transmissions fit within the bladeRF x40's 28MHz bandwidth.

The peak at the center is caused by DC offset at the outputs of the DACs. One way to deal with it is to add a fixed values to your I/Q signals. The exact value depends on the board, but also on such settings as the center frequency and gains.
The best and easiest way to figure out how the offset influences the CF leakage is to connect spectrum analyzer to the output of the board and use osmocom_siggen to fiddle with offsets. Once you find the optimal values for I and Q, you can hardcode them in your flowgraph. It's not perfect, you still may see some leakage few dB above the noise floor and the level will probably depend on temperature of the chip, but is trivial to implement.
For perfect cancellation you probably would have to listen to your transmitted signal, and compute the corrections dynamically.

j.