About DFM raw frame handling (only every other frame actually received?)

[bazjo]

Sorry in advance: This is a lazy one by me, I haven't looked fully in the code yet, but I know Hansi is always at hand and I have quite a strong suspicion that diggin deeper would find what already is my working hypothesis at the moment.

I am currently trying to make a performance evaluation on different DFM receivers. For this, I am comparing the raw frames.

In the serial output, when a sonde is decoded, i.e. the following is logged

inverse is 0<\b>CFG(0):6000000 DAT(0):0000026802040 DAT(0):00000000A0281 DFM-06 ID: 0 DAT[0]: Packet counter: 104 DAT[1]: UTC-msec: 41000RSSI update: drawRSSI: 6 0 14 (13)[3]<\n>
inverse is 0<\b>CFG(0):000BA90 DAT(0):0000000000004 DAT(0):000036400E7C5  DAT[4]: GPS-height: 0.00, vv: 0.00 DAT[5]: (?)Timeout check: 90640 - 28850 vs -1; 90640 - 29709 vs -1; 90640 - 0 vs 20000<\n>

Clearly, every other frame is missing from the log (In this case, the one with DAT[2] and DAT[3])

Is the decoder only catching every other Frame for DFM Sondes? Is this a general Problem for continuous transmission decoding with the sx1278?

Is the main loop running with a period of 1 s? If so, as the frame duration for DFM sondes is 224 ms, with every other frame received there should be 3 Frames printed every 20 s or so. However, this never seems to be the case. Why is this?

Thank you so much for your help!

[dl9rdz]

Are you using the "DFM" or "DFM[6/9] (old)" setting?

What you observe is a known problem of the (old) decoders. It should not happen with the newer DFM decoder.

[dl9rdz]

Regarding the last part of the question: I tried to keep the main loop at about a period of 1s, but that is not enforced. The real period is defined by the decoder. For RS41, it decodes a single frame and returns.

For DFM old, it decodes two frames and returns. That was just done empirically to observe about 1s intervals, without taking a closer look on details of the DFM protocol (otherwise I would have detected earlier that every second frame was missing in the old decoder).

The new decoder decodes 4 frames per invocation.

[bazjo]

OK, I found the issue, I upated prior to opening the issue via OTA, and didn't pay attention to changing the type/mode identifier in the QRG list...

Does this mean the new decoder is still missing frames?

[LukePrior]

It seems like this is an issue as I'm only seeing a frame every 2 seconds on SondeHub

[dl9rdz]

So if you select type "DFM" this should not be an issue, and you should see something like this with consecutive frames on the serial console which I judge is complete (test sonde indoors without gps, so lat lon is 0):

MAIN: Running loop in state 0 [currentDisp:0, lastDisp:0]. free heap: 118512, unused stack: 4980
[RSSI=116 FEI=305 AFC=9277] CFG(0):1B6A6FB DAT(0):0000000000004 DAT(0):0000000000005  1b:i=0,top=10 DAT[4]: GPS-height: 0.00, vv: 0.00 DAT[5]: (?)
[RSSI=116 FEI=0 AFC=9277] CFG(0):2C9E890 DAT(0):4851544A56526 DAT(0):5F5B49535D467  2c:i=4,top=10 ID:2C[0] CNT:1,0,st=44,lastfrid=172 DAT[6]: (?) DAT[7]: (?)
[RSSI=116 FEI=366 AFC=9277] CFG(0):AC01040 DAT(0):0000000000008 DAT(0):000000000000F  ac:i=8,top=10 ID:AC[0] CNT:3,2,st=172,lastfrid=172 ID OK DAT[8]: Date: 0000-00-00 00:00z DAT[15]: (?)
[RSSI=116 FEI=-122 AFC=9277] CFG(0):0C82088 DAT(0):0000023D00000 DAT(0):0000000000001  0c:i=3,top=10 DAT[0]: Packet counter: 61 DAT[1]: UTC-msec: 0
Sonde:receive(): Event 00: action ff, res 00 => ff00

MAIN: Running loop in state 0 [currentDisp:0, lastDisp:0]. free heap: 118512, unused stack: 4980
[RSSI=115 FEI=366 AFC=9277] CFG(0):1B6A6F2 DAT(0):0000000000002 DAT(0):0000000000003  1b:i=0,top=10 DAT[2]: GPS-lat: 0.00, hor-V: 0.00 DAT[3]: GPS-lon: 0.00, dir: 0.00
[RSSI=117 FEI=-122 AFC=9277] CFG(0):2C9E869 DAT(0):0000000000004 DAT(0):0000000000005  2c:i=4,top=10 DAT[4]: GPS-height: 0.00, vv: 0.00 DAT[5]: (?)
[RSSI=116 FEI=366 AFC=9277] CFG(0):3C66D72 DAT(0):808C808080806 DAT(0):8080808080807  3c:i=9,top=10 DAT[6]: (?) DAT[7]: (?)
[RSSI=116 FEI=-61 AFC=9277] CFG(0):0C82061 DAT(0):0000023E00000 DAT(0):0000000000001  0c:i=3,top=10 ID:C[1] CNT:0,1,st=12,lastfrid=172 DAT[0]: Packet counter: 62 DAT[1]: UTC-msec: 0
Sonde:receive(): Event 00: action ff, res 00 => ff00

If you select a type with label "...(old)", every second frame is likely to be missing.

[LukePrior]

If you select a type with label "...(old)", every second frame is likely to be missing.

Is there any reason the old decoder is still included?

[dl9rdz]

I guess it would be best to remove it soon.

The old decoder lets the hardware do most of the work (header detection etc.). The advantage of the hardware approach is that the automated AFC and AGC of the chip can be used and might enhance reception quality in case there is a frequency error. I left the old decoder in to allow people to check whether the old decoder is better in detecting weak signals. I added the new decoder last November, and so far nobody complained that the new decoder is sometimes worse, so probably removing the old one is the right thing to do now.

The main problem with the old decoder is that for unknown reasons the hardware is not ready for receiving the next frame soon enough after finishing one frame. Also, the hardware can detect only a single sync signals, so you have to manually choose which polarity you want to detect (dfm6 or dfm9 style)...

[bazjo]

After the OTA Update to the latest devel, I just found a textbox with 6/9 prefilled, I had to look up the value 'D' in the code...

As for the performance comparison: I might be able to pull this off and include it in my masters thesis which i am currently working on, and which will include a comparison (sensitivity/selectivity) between various decoding solutions

Originally, I was planning on primarily using the Si4464 for this, but I stumbled on pretty much the same problem there, and so the Si4464 is now the candidate who might be included or not (depending on time), and the RDZSonde is planned to be included for sure (at least thats my plan at the moment)...

[bazjo]

Ok, the first Test shows the old decoder is about 6 dB more sensitive than the new one. I will follow up with proper results in the discussions. I think there is no longer the need to keep this open.