Difficulties decoding meshtastic

[miweber67]

First, thanks for the awesome work!

I've been trying to decode a local meshtastic network and having poor results (<5% of received frames have valid CRCs, even with SNR's exceeding +10dB). Headers always seem to have valid CRCs. I've tried an airspy mini and an rtlsdr on the front end with similar results. I've tried Fs between 1e6 and 6e6 and filtering/decimation to achieve os_factors from 4 to 24. The beginnings of the frames 'look' correct, e.g. the first four bytes are 0xff, which corresponds to a 'broadcast' destination address.

Local meshtastic nodes are using the 'long_moderate' preset, which corresponds to 125kHz with SF=11 and 4/8 coding. The preamble length is claimed to be 16, but manually counting the sweeps in gr_fosphor reveals somewhere between 16 and 18 upsweeps for the preamble. The network ID is '0x2B.' Payload lengths vary between 40 and 70 bytes, typically.

What is a good target number for the frame_sync's 'os_factor?' Is soft decoding expected to work better than not using it?

I'm not sure if I have a sub-optimal receiver configuration or if there is just some difficulty decoding the particular parameters meshtastic is using. Thanks for any thoughts you have. I can supply IQ recordings if that would help.

[tapparelj]

Hello @miweber67, there definitively is something off if you only receive a few correct frames at such a high SNR.

• For the _osfactor, an oversampling of 4 should be enough to have good performance without too much overhead.
• Yes, the soft-decision decoding should work better (or at least not worse) than hard-decision decoding. And for large received SNR, it will automatically switch to hard decision to avoid numerical issues.

Some questions:

• Can you share the flowgraph you use, so I can have a look if anything strange pops out?
• Which carrier frequency are you using?
• Also, can you connect a Tag Debug to the output of the Frame Sync and see what value has the CFO estimate (cfo_int and cfo_frac)?

[miweber67]

@tapparelj , thanks for the response! I can certainly do what you asked.

Please find attached the tag_debug log, console output from the session. 53 frames detected, 5 crc valid. CFO int mostly between -60 and 30. CFO frac varies.

Carrier frequency is 903.0625MHz. You'll see some frequency shifting blocks in the script, but these are only to support offset collection and channelization for inspecting different channels. The lora decode performance is the same without them. There's also a filter to get rid of adjacent channel interference. Removing the filter drops detections to 33 and valid CRCs to 4.

Also attached is the grc file, although I had to rename it .txt because github wouldn't accept it as .grc.

Thanks much for your help!

tag_debug.txt lora-rx-file.txt

EDIT: Here is the preamble and first part of a packet from meshtastic; I count 18 upchirps in the preamble? Is that right?

[mskvortsov]

Sorry for interfering, but I think it's not worth creating a separate issue since my observation might be related to this one.

I have two signals, both contain some meshtastic packets with the same channel settings corresponding to the LongFast preset: SF 11, BW 250KHz, preamble length 16, sync word 0x2b. Center frequency is 869.075 MHz, 1 Msps sampling rate.

sample2.griq.xz is decoded successfully with the sync word set to expected 0x2b (or [16, 88] in the full form). However, to decode sample1.griq.xz I need to set the sync word to [16, 2008].

Is it expected? Am I missing something?

[tapparelj]

Hello @miweber67, First to answer some questions:

• Regarding the filter: it is necessary to have a a input signal filtered at the LoRa bandwidth to remove noise outside the band of interest (depending which SDR you use, you can configure directly their filter to be smaller than their sampling rate, else adding a low-pass filter before the _framesink is also fine).
• From the spectrogram, I htink there are 16 upchirps (not 18) and then two modulated upchirps with values [16,88] (for 0x2b) and then the 2.25 downchirps.

I've checked connecting the transmitter to the receiver you configured and it seems to work as expected even at low SNR and with reference clock frequency offset. So I don't see anything strange. Would it be possible to have access to the sample you use that lead to a wrong decoding as well as the payload that is transmitted? (one or two frame would be enough) so that I can identify which part of the receiver seems to fail?

[miweber67]

@tapparelj , thanks for your efforts! Here are two slices of the capture file with one bad packet each. These slices have been filtered and decimated by 3 to 500kSps, so you should be able to feed them straight in to frame_sync with os_factor 4.

903062500-0.5MSs-extract-filt-decim-1.c64.gz 903062500-0.5MSs-extract-filt-decim-2.c64.gz