RS41 - Add notification of encrypted telemetry.

[darksidelemm]

Add a notification that the telemetry is encrypted to the usual stdout output, and to the JSON output.

[rs1729]

I don't know if I want so much notification text in the std output. That's why I did not do such output. Ok, maybe RS41-SGM is a good guess, and probably it is a good idea to output something even if --crc is not selected, but there are some issues. Though, it is good to do it locally, since the status can change, but then you have to initialize the local variable "encrypted" to 0! Otherwise you get random "encrypted" output even for normal frames with positions. And for json-output, the gpx-position does not have to be 0, it is initialized only at the beginning. After that only part of gpx (config/calib) is initialzed if the sonde-id changes. Thus if the decoder was decoding a regular rs41 before, json would give you the last coordinates it has calculated. This can happen if you change the frequency or if there is another radiosonde (later) on the same frequency. Maybe it is better to do a separate json-output for rs41-sgm, or the entire gpx-struct has to be reset, when a different sonde_ID is detected.

The other pck_XXXX-defines are 16bit, e.g. 0x76xx, 0x7E00, so it can be used by check_CRC(). And when 0x80 is detected at pos_PTU, the crc should be checked before doing printf "rs41-sgm..."

Let me give you a modified version this evening (UTC).

[rs1729]

I modified rs41mod.c such that the coordinates are reset if the crc-check fails. The rs92decoder can output position even if the crc is invalid, because the gps block is so large that errors are more likely. But for rs41 only crc-valid packets are put out, so the coordinates can be reset in any case (normal output or json/encrypted).

Also modified rs41dm_dft.c.

Sorry that this conflicts with your version, but yours wouldn't work right with mixed input. The gps reset is needed if the decoder listens to stdin and the source/frequency is changing, or if different (in time) rs41 use the same frequency (though it's only relevant if a rs41sgm is one of them).

I have included experimental/empirical rel. humidity (rough approximation). Error could be 5% in particular if RH is high and even more if temperature is low (or very low, below -70 deg celsius), but RH has some uncertainty anyway. And response time is not considered, that would need post-processing. Though they will be some updates probably. For json/rs41dm_dft.c it is turned off, maybe you want to test.

Did you test the __mod.c decoders with auto_rx? They need more stack memory, but they are more flexible (aux-data, conf-data). I would like to concentrate more on rs41mod.c (rs41dm_dft.c only bugfixes).

[darksidelemm]

OK those changes make sense. Not sure why you need the 16-bit pck_ defines, since the byte after the packet type ID is the length of the following packet in all cases anyway. After the ECC section in the frame it appears to just be repeats of , so packet extraction could be done without any hard-coded frame offsets. I guess in most cases the packet lengths are always going to be the same, but I'm wondering if there's some packet types we haven't seen yet. When I saw the RS41-SGM telemetry I was quite confused because the GPS CRCs were failing - I had to go dig more into the frame to find the 0x80 packet type.

I'm currently working on integrating the new 'mod' decoders into auto_rx now, starting with the RS41 and RS92 ones. Good work on the humidity addition! I'll compare it against what the local met bureau report (when they start launching again!!!).

I've noted you've changed the ID type for the DFM17 and PS15 sondes to use the hex ID - I need to make sure all stations are consistent with how that operates else we will end up with weird conflicts in the network. How sure are you about the ID-to-type mapping for these sondes? Is it still a guess?

[rs1729]

The hard coded pck(id,len) can help if the frame has many errors. If the fec is successful, it is not needed, but if there are too many errors, some packets could still be ok, though not with hundred percent certainty (the crc could be ok even if bits are wrong). If you have 5 pcks where you can set 5*2 bytes in a second pass, it could be enough to re be able to repair the whole frame. The only packets that I know that have variable length are AUX and ZERO. If you only rely on the 1-byte packet id, you would have to accept only fec-OK frames, otherwise it could go wrong easily. I do it only for AUX, ZERO, and https://github.com/rs1729/RS/blob/master/demod/mod/rs41mod.c#L1169

DFM: I'm certain about 0x6 -> DFM-06 and 0xA -> DFM-09. I'm not so sure about 0xC. Someone sent me frames with 0xC-ID and he thinks it is a DFM-09 w/ pressure sensor. If there is a pressure sensor, the should be more "channels", so it could be that the ID moves further back. The frames decoded like the one that where identified as DFM-17, also the sensor reference data moved, but I don't know if the DFM-17 always have pressure sensors (would be surprised) and what 0xD is. Vaisala doesn't make so many changes, with DFM it looks more like a dynamical process.