there is many spurious emission when transmit

[ruanxw]

What type of issue is this?

permanent - occurring repeatedly

What issue are you facing?

hardware: portapack H2(MAX2837 SI5351C)
firmware: V2.0.1

lora iq file(52.3k_62.5k.c16)
bandwidth: 52.3khz
sample rate: 200k
url: https://drive.google.com/drive/folders/1mRJ-CC0OTODt6pOXMl4QfbpQ2Tush09h?usp=sharing

i replay this file by portapack H2 and chek the wave by r&s device pr200. there are many spurious emission. you can check the attached picture(testResult.png).

The sample rate is 200khz. And we can find that every 200khz there is a spurious emission.

i tried many kinds signal(FM、AM、bpsk、lora ....). it always persist.
Could you please help to check it? Thank you so much!

What are the steps to reproduce this?

1.Switch on portapackH2
2.enter replay app.
3.select the lora iq file lora_52.3k_62.5k.c16
4.start to replay.
5. check the signal waveform with receiver（R&S PR200)

it also persist when using gnuradio.

Can you provide any logs? (output, errors, etc.)

No response

[miek]

This is caused by using a sample rate that is too low, we recommend using a sample rate of at least 8 MHz for best results.
This is because the anti-aliasing filter on the hardware can only go down to 1.75 MHz wide so, unless you use a sample rate wider than that, it can't filter out the aliases and you will see those spurious emissions.

See here for more detail: https://hackrf.readthedocs.io/en/latest/sampling_rate.html

[ruanxw]

Thanks for your reply. As your suggestion, it is better than before.

Bad test result with sampRate: 200k

Better test result with sampRate: 16M
test grc in gnuradio:=====================

Test result:=================================

So you do find the root cause.
But i have one more question. Now these spurious emission still appear +/-1M. is there any way to decrease this value?

[miek]

I see a couple of issues with the flowgraph:

1. You should remove the Throttle block when you have a hardware block in the graph (like the osmocom sink/source, or an audio sink/source)
2. The low pass filter is quite tight and may require too much computation, try changing the transition width to match the cutoff freq.

[ruanxw]

Hi
as your suggestion, i disable the Throttle block and change the transition width to 2k(bandwith is 20K). But these spurious emission still appear +/-1M. Is it possible to decrease the spurious emission? (decrease the +/-1M to +/-100k or +/-20k)?

test result:

[Moji14]

Just checked your files...
Can you give in more detail what is (in terms of signal) the file lora3_52.3k.c16 ?
How did you created it?
Is it a record?
lora3_52.3k.txt Only says sample rate is 200KHz and center frequency is 220MHz... But can you provide if it's any time of modulation or just a tone.
Can you connect a frequency sink before the filter ans show us the original signal?
I'm trying to discard that is a problem inherent to the signal itself...

[ruanxw]

1. i don't know how this IQ file is created. I only know the sample rate is 200k and the bandwidth is 52.3k. Actually i have many IQ files AM,FM,DMR,2FSK.... And i only know samp rate and bandwidth of them. We just want to replay these IQ files to study these signal.

2. The original signal is as below. The red line is the max value. I don't know how to keep the max value showing. So i draw it by myself. the bandwidth is 52.3khz.
   

3. I share a FM iq file as below URL. The samp rate is 200k and bandwidth is 20k. When you replay it, You can use a receiver to demodulate it and you can listen it like listen to a FM station. Althought we can demodulate it successfully, there still persist many spurious emission +/-1M.
   FM

Due to i am out of office, so i cannot provied the test picture and just try to explain by my poor english. Thanks for you patient.

[miek]

At this point I'm not able to reproduce the problem, if I run a similar flowgraph the output looks OK here:

Once thing I would still recommend is to make the low-pass filter less tight. A transition bandwidth that low will require a lot of taps and a lot of computation, and may not be keeping up with real-time. Make sure that you're not seeing 'U' characters continuously printed to the GNURadio console, as that would indicate underflow and could cause all sorts of spurious output.

[ruanxw]

Great, your test looks better! Thank you so much! So which version of hackrf one do you use? R8 or R9?

[miek]

I tested on both r4 and r9

[Moji14]

@ruanxw Observing @miek simulation and results they look what's expected. And yours are probably as well.
I see that you are using a R&S PR200 portable monitor receiver, which is fine to use as a spectrum analyzer.
Correct me if I'm wrong. The readings on your PR200 indicate a peak power of 66.4 dBuV (which is around -40 dBm) and that's suggesting me that you are trying to validate your HackRF with an OTA (over the air) measurement (unless you're using 150 m of cable or it's broken), and that's a bit more complicated and prone to errors (unless you are doing that measurement inside an RF anechoic chamber with special antennas and so on a so forth).
If so, try to connect directly your Hackrf to the PR200 (which is capable of handling power inputs up to +20 dBm so no worries of burning it up).
You can also change the PR200 config to show the measurements in dBm so it will be easier to comprare results.

[ruanxw]

Ok， i will test next week. Thanks so much for your help!

[ruanxw]

Actually i test with portapack+hackrf one(use hackrf app). I guess you test with a single hackrf. So we get different test result. Anyway i will retest in next week. Thanks so much!