Invalid RS41 subtypes sent to SondeHub

[eben80]

It seems that invalid subtypes are being sent to SondeHub for the RS41 sondes.

  {
    "software_name": "rdzTTGOsonde",
    "software_version": "devel20210919",
    "uploader_callsign": "EBSKI_RDZTTGO",
    "time_received": "2021-09-19T23:29:32.000Z",
    "manufacturer": "Vaisala",
    "serial": "R5020804",
    "datetime": "2021-09-19T23:29:49.000Z",
    "lat": 49.00356,
    "lon": 20.37939,
    "alt": 5162.59863,
    "frequency": 400.6,
    "vel_h": 9.71973,
    "vel_v": 5.75604,
    "heading": 123.55472,
    "rssi": -115,
    "frame": 2067,
    "type": "RS41",
    "sats": 8,
    "subtype": "ohtvaJSM2P",
    "uploader_antenna": "403MHz Ground Plane Monopole",
    "uploader_position": "49.0523,21.2821",
    "position": "49.00356,20.37939",
    "uploader_alt": 271
  },

In later frames it was decoded correctly but it seems the first sub-type used in SH

[LukePrior]

We use the longest subtype in the SondeHub tracker as that stops the value from jittering. This works when only correct values are uploaded but creates errors like this.

[dl9rdz]

There won't be any real test data available around here the next 3 days, but I added some additional debug output. If possible, capture the serial output and send it to me. Also, if you compile the code yourself, don't upgrade u8g2 to 2.31.1, as it will not compile.

[eben80]

Thanks I'll try to get some log captures for the midnight flights.

On Mon, 20 Sep 2021, 11:25 dl9rdz, @.***> wrote:

There won't be any real test data available around here the next 3 days, but I added some additional debug output. If possible, capture the serial output and send it to me. Also, if you compile the code yourself, don't upgrade u8g2 to 2.31.1, as it will not compile.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dl9rdz/rdz_ttgo_sonde/issues/181#issuecomment-922763430, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATNONGC7BJGSXJAFALDDDLUC34Z5ANCNFSM5ELOVMDQ .

[mycarda]

This is just a theory at the moment so happy to be proved wrong.

In the method for obtaining the subtype in RS42.cpp if( (sf->valid & (3<<21)) != (3<<21) ) return -1; Should it be 3<<33 or 3<<0x21 because the subtype value in the subrame data is at 0x218 for 10 bytes.

It might explain why sometimes we have the wrong value if we are checking for the wrong subrame block arrival. If the subtype name eventually starts showing the correct one, then I would guess that is the issue as eventually we receive the full subframe so it does not matter what we check.

[dl9rdz]

Yes, exactly. (almost. 3<<0x21 overflows as 3 is a 32bit int, but I just commited a working fix)

[mycarda]

If only I could get my battery voltage code to produce the right value. First it seems about 0.2v lower than reported by others, then suddenly it says 1641.2v. I need to work out the issue before I submit my code. More testing tomorrow.

[dl9rdz]

Ok, lets see. I will not have any RS41 in receiver range the next two days for testing, but wouldn't that simply be something like that (with batt added in sonde.h as float):

diff --git a/libraries/SondeLib/RS41.cpp b/libraries/SondeLib/RS41.cpp index 76ddc57..fb15969 100644 --- a/libraries/SondeLib/RS41.cpp +++ b/libraries/SondeLib/RS41.cpp @@ -432,6 +432,7 @@ int RS41::decode41(byte *data, int maxlen) Serial.print("; RS41 ID "); snprintf(buf, 10, "%.8s ", data+p+2); Serial.print(buf);

• sonde.si()->batt=0.1 data[p+10]; sonde.si()->type=STYPE_RS41; strncpy(sonde.si()->id, (const char )(data+p+2), 8); sonde.si()->id[8]=0;

[eben80]

I left my static ttgo unplugged this morning so I ran out of battery with the midday flight. 👎 I'll get the data from the midnight flight to see what subtypes were sent.

[eben80]

The sub-types from last night were consistent and correct.