Hi everyone,
I am now using the OFDM Transmitter and Receiver block, I believe I filled everything correctly but I am getting an error such as “header_payload_demux :info: Detected a packet larger than max frame size” anytime I execute the flow graph, any ideas? Any comments are appreciated
All I am trying to accomplish is send a .txt file that contains HELLO WORLD and have that be transmitted and receive on my LimeSDR.
Parameters for Both Transmit and Receive:
Flow Graph:
They have a working example on the gnuradio website -
The most glaring difference is they are using a 100 KSPS sample rate and you are using a 16 MSPS - try cutting that down a bit - perhaps that is your problem - it is erroring because it cannot do that high of bandwidth.
Thank you for the reply! I have tried using this example, it works as long as I dont add in the LimeSDR TX and RX. I tried lowering down the Sampling rate and the issue is still occurring
I modified their version with the transmit and receive for my BladeRF(my limeMini died). It gets the same errors that you get and does not work, but there is no wonder the received data looks nothing like the send data. I suspect that you will see the same thing. I guess that the data needs some anti-aliasing filters for the send and receive.
Thank you for the file modifications, just ran it. Correct, the data being transmitted does not look the same to me either when receiving it (I am not experienced, take it with a grain of salt). And correction, I only get that original error “header_payload_demux :info: Detected a packet larger than max frame size” when using the OFDM Receiver actually With the LimeSuite Rx.
Would the anti - aliasing fix the issues for the data not looking like each other or that mysterious “header_payload_demux :info: Detected a packet larger than max frame size” error?
Yes, I expect the fixing anti - aliasing issues would make it work, but because there is no anti - aliasing the carriers are mixing together and creating a sorts of unwanted frequencies. I know how to fix the problem with the liquidsdr routines, but I not sure how to do it using the gnuradio routines - they are poorly documented.
Look at you go thats reinsuring, what kind of anti - aliasing filter was it low pass? Did it also fix that original issue with the header payload exceeding the max frames?
I run the exact same program with the exact same input and I have received three different sets of results. I am not sure I am going to be able to work thru all of the gnuradio bugs. One bright spot, I finally got it to transmit and receive NBFM correctly.
I finally got it to work. This morning, I saw a comment on line to be careful not to clip the OFDM data - that was it. Scaling down the input to the transmitter by a factor of 20 fixed the problem.
Just a note: I though that that noise was coming from anti - aliasing - when it was actually caused by the clipping of the input.
THANK YOU SO MUCH.
Was that really the issue? Wouldn’t had never guessed, Thank you so much will be testing this today and will report back!
@RightHalfPlane Once again thank you for trying to fix it, however I am still getting that “header_payload_demux:info:detected a packet larger than max frame size” and no data is being placed within the file sink. I used your example just exchanging the Sink and Source with LimeSDR Sink and Source
You likely need to adjust the gains. Does the Transmitter input look like the Receiver output ? They should show patterns with about the same frequency. If Receiver output has higher frequencies, you are still clipping. If Receiver output is smooth, but has a small amplitude you need to increase the gain.
It should start working, when you get the “Receiver output” showing smooth curves with about a plus and minus one volt signal.
@RightHalfPlane Thank you for the fix, however I am getting bizarre outputs as shown in the pictures. I will also include debug messages left in the console.
As you can see the Receiver output is in a PWM like wave form and the Scope Plot output is essentially flat.
LimeSDR TX Settings:
Gain = 0dB
RF = 2.4GHz
Sample Rate = 1.5M
PA Path = BAND 1
LimeSDR RX Settings:
Gain = 0dB
RF = 2.4GHz
Sample Rate = 1.5M
LNA PATH = H
Pictures:
Console Messages:
Generating: ‘/home/chris/Downloads/ofdm_loopback_example.py’
Executing: /usr/bin/python3 -u /home/chris/Downloads/ofdm_loopback_example.py
Warning: failed to XInitThreads()
LimeSuite Source (RX) info
##################
Connecting to device
##################
LimeSuite version: 20.10.0+dfsg-5
gr-limesdr version: 2.2.7
##################
Device list:
Nr.:0 device:LimeSDR-USB, media=USB 3.0, module=FX3, addr=1d50:6108, serial=0009070602431B19
##################
INFO: device_handler::open_device(): no serial number. Using first device in the list.
Use “LimeUtil --find” in terminal to find prefered device serial.
Reference clock 30.72 MHz
Using device: LimeSDR-USB(0009070602431B19) GW: 2.23 FW: 4
##################INFO: device_handler::enable_channels(): SISO CH0 set for device number 0.
SISO CH0 set for device number 0.
INFO: device_handler::set_samp_rate(): set sampling rate: 1.5 MS/s.
INFO: device_handler::set_rf_freq(): RF frequency set [RX]: 2400 MHz.
INFO: device_handler::set_analog_filter(): RX LPF configured
INFO: device_handler::set_gain(): set gain [RX] CH0: 0 dB.
INFO: device_handler::set_antenna(): CH0 antenna set [RX]: LNAH.
INFO: device_handler::calibrate(): Rx calibration: MCU error 5 (Loopback signal weak: not connected/insufficient gain?)LimeSuite Sink (TX) info
##################
Connecting to device
INFO: device_handler::open_device(): no serial number. Using first device in the list.
Use “LimeUtil --find” in terminal to find prefered device serial.
Previously connected device number 0 from the list is used.
##################INFO: device_handler::enable_channels(): SISO CH0 set for device number 0.
SISO CH0 set for device number 0.
INFO: device_handler::set_samp_rate(): set sampling rate: 1.5 MS/s.
INFO: device_handler::set_rf_freq(): RF frequency set [TX]: 2400 MHz.
INFO: device_handler::set_analog_filter(): Filter calibrated. Filter order-4th, filter bandwidth set to 5 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active
TX LPF configured
INFO: device_handler::set_gain(): set gain [TX] CH0: 6 dB.
INFO: device_handler::set_antenna(): CH0 antenna set [TX]: BAND1.
INFO: device_handler::calibrate(): Tx Calibration: MCU error 5 (Loopback signal weak: not connected/insufficient gain?)
INFO: sink_impl::init_stream(): sink channel 0 (device nr. 0) stream setup done.
INFO: source_impl::init_stream(): source channel 0 (device nr. 0) stream setup done.
header_payload_demux :info: Detected a packet larger than max frame size (65 symbols)
header_payload_demux :info: Detected a packet larger than max frame size (71 symbols)
header_payload_demux :info: Detected a packet larger than max frame size (121 symbols)
header_payload_demux :info: Detected a packet larger than max frame size (125 symbols)
header_payload_demux :info: Detected a packet larger than max frame size (123 symbols)
header_payload_demux :info: Detected a packet larger than max frame size (103 symbols)##################
INFO: device_handler::close_device(): Disconnected from device number 0.
##################Done
You have added things to grc and changed some names, but if the “Receiver Output” is the same as in my original grc - it says that your transmitter is clipping the signal. So, you need to open osmocom Sink and adjust the Rf Gain, IF Gain and BB Gain until it stops clipping the “Receiver Output”.
Sorry about that, I ended up using your fix example with no changes to it, if you take a look again at my reply. I tried adjusting the gain in terms of the LimeSDR Tx as it wont allow me to go below 0dB. I also tried changing your multiplying const as well even tried multiplying by 0.01, still nothing.
The multiplying const should stay at 0.05. You need to work with Rf Gain, IF Gain and BB Gain. Set them all to 20 to begin with and try pushing them up and down and watch the “Receiver Output” - it should look like the “Transmitter input”.
Bingo, at Gain = 55dB It works, I am receiving it on the receiver end thank you!
@RightHalfPlane Thank you so much, I finally received my data perfectly. The only question I have to ask now is that, is it possible to not use the repeat mode? For example if I were to send a TCP packet instead would that work?
