HackRF TX with GNURadio: Why does my spec an look like this?

I suspect you have discontinuities in your signal from the hackRF.

Check if you have buffer underflows or overflows - some SDRs have LEDs to indicate this, otherwise you might need to look at your signal in the time domain. It's similar to a sound card when the sample rate isn't quite right - you get a crackle now and then (more often if you're underflowing severely - e.g. in the case of more complex GNURadio flowgraphs or if you have mismatched rates somewhere).

- Gough

EDIT: Why is your source 32k and the sink running at 64k? Make them both equal would be a good start, but perhaps not necessarily enough as there will still be offset from the PC clock to the SDR's clock to worry about.

Sorry - I only just realised you had an earlier part to the question which I completely glossed over.

I'm not too experienced with GRC flowgraphs, but I suspect the blue-tabs indicate real values. So the signal source is generating a 32ks/s stream of sine real-values into the sink block. As the sink block has it's own frequency, I suspect this means the graph represents a 1kHz signal being generated and shifted up to 433.2MHz centre frequency. This would be a form of modulation - at a guess I would think it to be single sideband (in this case upper-sideband), which means you'll probably find a pure tone at 433.201MHz assuming everything is calibrated. That is, if my understanding is correct - I don't have a HackRF so ... I can't be sure.

- Gough

Gough Lui  wrote:

 

I suspect you have discontinuities in your signal from the hackRF.

otherwise you might need to look at your signal in the time domain.

That was my first thought. I have access to an 8 GHz oscilloscope with TDR. I looked at the signal on the scope and it is not stable there either. (Don't have screenshots. They didn't save to my USB drive.) So I looked at the cable with the TDR and it looked fine. Regardless, I switched to a higher quality cable and there was no change on the HackRF's output.

you get a crackle now and then (more often if you're underflowing severely - e.g. in the case of more complex GNURadio flowgraphs or if you have mismatched rates somewhere).

With a slightly more complex frequency modulated flowgraph, I'm getting audible crackles when transmitting a wav file. On that one, I am seeing "aU" feedback from GNUradio, which I think is buffer underflows. With this simpliified flowgraph, I'm not getting any "aU" feedback from GNURadio.

Why is your source 32k and the sink running at 64k?

Troubleshooting step after I took the spec an screenshot. But admittly, I don't fully understand how sample/data rates work in GNUradio yet.

If you are getting underflows, that's bad news. But even if you don't get the "U" showing up in console, this is not an indication that all is fine. Instead, you could be having overflows elsewhere unreported (e.g. in the driver for the HackRF or the HackRF's FPGA). I would double-check your connectivity as well - in case you get better results from certain USB controllers. I know the BladeRF I had before was very picky -  certain USB ports would always cause discontinuous output depending on the chipset.

If you want a global sample rate (i.e. the samp_rate variable), then set all your blocks sample rates to samp_rate so that you change it in one spot rather than all over the graph. But to have a source block at a different rate to the sink block is always going to cause issues. Also note that not all rates are going to be supported by certain sinks - usually the FPGAs have certain fixed rates they can accept input at (any other rate requires CPU-intensive resampling and is best avoided).

Some documentation for the HackRF claims that it supports rates from 2Msps to 20MSps - so to make it happy, perhaps set sample rate to 2M and see what happens?

- Gough

so to make it happy, perhaps set sample rate to 2M and see what happens?

I'll give that a shot next. I've changed the Hack RF sample rate a number of times, but not systematically. That's a good next step.

then set all your blocks sample rates to samp_rate

Yeah, that's how I've been using GNURadio. In this case, I just tacked on "*2" on to the variable to double the global sample rate. (I was hoping over sampling would fix the problem.)

I'm at Teardown in Portland right now. Lime Microsystems has a big show of their SDR solutions and there is at least one other talk on SDRs. So between your suggestions and those sessions, I'll be heading back to the lab armed with way more information than I had a day ago.

Thanks Gough.

Best of luck! I've just been too busy to play with SDRs, sadly. But the Lime Microsystems chips have been so important - the BladeRF that I had was using one as the front end and it's been pretty amazing for me (while it lasted).

Glad to see they've entered the market with their own LimeSDR and LimeSDR Mini - I should pick one up next time I get a chance.

- Gough