DFM XDATA Support?

[LukePrior]

Hello,

I was wondering if it would be possible to add XDATA decoding for DFM sondes as this functionality has recently been added to ra-firmware.

The specific commit adding support can be found here: https://github.com/einergehtnochrein/ra-firmware/commit/a308ed106ba6067f0a3966496b455f1709a754b3, https://github.com/einergehtnochrein/ra-firmware/commit/383a0079aaee24402b901bc1751689be6384ca65

Thanks

[rs1729]

I've never seen XDATA transmitted by a DFM, do you have an example?

[LukePrior]

I don't have any recordings but I do know the DFM is listed by Graw as being officially compatible with XDATA:

https://www.graw.de/fileadmin/cms_upload/en/Resources/PR-GRAW_Overview_V06.00_EN.pdf

https://sondehunt.de/language/en/archive/1189

I believe the DFM sondes launched weekly from this site include Ozone XDATA Instruments: www.sondehub.org/site/71917

[bazjo]

As far as I am aware, as the DFM Telemetry is fairly limited in the number of transmitted bytes for xdata, therefore the sonde is configured on an instrument basis to send the ASCII coded data as binary data. I believe no identification of an instrument is sent, therefore it seems not practical to get anything useful out of the transmission.

[rs1729]

I know that GRAW mentions XDATA, but who uses it? Don't remmeber if I've ever seen reports of a DFM-XDATA transmission or a picture of a DFM with a XDATA instrument attached. (Maybe I overlook it?) Maybe you could try it yourself attaching an instrument and test. But if it is nowhere really used... I don't know. If they use it at the station on Ellesmere Island, it would be interesting to see raw data or better a recording of the signal.

[rs1729]

From http://weather.uwyo.edu/cgi-bin/bufrraob.py?datetime=2022-03-11%2012:00:00&id=71917&type=TEXT:LIST (Eureka/Ellesmere Island 2022-03-11 12Z)

-----------------------------------------------------------------------------
   PRES   HGHT   TEMP   DWPT   RELH   MIXR   DRCT   SPED   THTA   THTE   THTV
    hPa      m      C      C      %   g/kg    deg    m/s      K      K      K 
-----------------------------------------------------------------------------
 1000.0     14  -29.2  -32.1     76   0.26     62    3.4  243.9  244.6  244.0
  986.1    108  -28.3  -31.6     73   0.28      9    3.3  245.8  246.6  245.9
[...]
  100.0  14962  -72.6  -94.1      3   0.00     92    2.8  387.2  387.2  387.2
   94.1  15321  -72.4  -94.6      2   0.00    107    3.3  394.5  394.5  394.5
[...]
    5.4  34160   -5.0  -49.5      2   7.84    287   70.2 1191.8 1317.0 1197.5
    5.2  34367   -5.6  -49.2      2   8.44    287   68.4 1202.2 1338.2 1208.3

On https://earth.nullschool.net/#2022/03/11/1200Z/wind/isobaric/10hPa/overlay=temp/orthographic=-60.00,90.00,1103 you can see the temperatures at 10hPa in the polar region.

[einergehtnochrein]

I came across the XDATA mode more or less accidentally. It was very easy to integrate, so I added it as part of a code cleanup...

Like you I have never watched a DFM sending XDATA, same fpr everybody else I asked. So this seems to be very rare indeed.

As far as I am aware, as the DFM Telemetry is fairly limited in the number of transmitted bytes for xdata

Compared to RS41 the DFM XDATA mode is really extremely limited: You can send only one XDATA packet per GPS cycle, i.e. every five frames (~1.1s). XDATA payload must be exactly 24 bytes long, so instruments must be "DFM-aware" or they can't be used. Consider that RS41 can send multiple XDATA packets of arbitrary length from one or more instruments in a single radio frame, with a total payload beyond 150 bytes.

Multiple instruments may be chained, since instrument type and number (in the chain) are transmitted. The limitation of one XDATA frame per GPS cycle remains, and so with two instruments each would have an update rate no faster than once per 2.2s.

Implementing XDATA isn't desperately needed... However, DFM can send GPS position in one of three ways, and implementing this cleanly basically gives you XDATA for free.

[rs1729]

@einergehtnochrein Thanks for the additional info. I added xdata support to test branch. @zanco provided real world data (thanks again), it's a DFM-17 and probably a ECC Ozonesonde (ID=0x01):

[ 22] 2022-03-29 12:49:24.0   lat: 50.54946  lon: 5.00713  alt: 25263.0  vH: 15.76  D: 185.2  vV:  6.79   T=-56.4C 
      XDATA: 01 01 0C 77 03 82 47 9B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ID=0x01 ECC  Icell:3.191uA  Tpump:8.98C  Ipump:71mA  Vbat:15.5V 
{ "type": "DFM", "frame": 1332593364, "id": "DFM-19029285", "datetime": "2022-03-29T12:49:24.000Z", "lat": 50.54946, "lon": 5.00713, "alt": 25263.00000, "vel_h": 15.76000, "heading": 185.15000, "
vel_v": 6.79000, "sats": 18, "batt": 4.28, "temp": -56.4, "aux": "01010C770382479B000000000000000000000000000000000000", "subtype": "0xD:DFM17P", "ref_datetime": "UTC", "ref_position": "MSL" }

[ 23] 2022-03-29 12:49:25.0   lat: 50.54932  lon: 5.00714  alt: 25267.8  vH: 14.44  D: 165.2  vV:  2.47   T=-56.5C 
      XDATA: 01 01 0C 1A 03 80 47 9B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ID=0x01 ECC  Icell:3.098uA  Tpump:8.96C  Ipump:71mA  Vbat:15.5V 
{ "type": "DFM", "frame": 1332593365, "id": "DFM-19029285", "datetime": "2022-03-29T12:49:25.000Z", "lat": 50.54932, "lon": 5.00714, "alt": 25267.80000, "vel_h": 14.44000, "heading": 165.21000, "
vel_v": 2.47000, "sats": 18, "batt": 4.28, "temp": -56.5, "aux": "01010C1A0380479B000000000000000000000000000000000000", "subtype": "0xD:DFM17P", "ref_datetime": "UTC", "ref_position": "MSL" }

[ 24] 2022-03-29 12:49:26.0   lat: 50.54920  lon: 5.00722  alt: 25271.0  vH: 16.34  D: 154.1  vV:  4.25   T=-56.5C 
      XDATA: 01 01 0C 0A 03 80 47 9B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ID=0x01 ECC  Icell:3.082uA  Tpump:8.96C  Ipump:71mA  Vbat:15.5V 
{ "type": "DFM", "frame": 1332593366, "id": "DFM-19029285", "datetime": "2022-03-29T12:49:26.000Z", "lat": 50.54920, "lon": 5.00722, "alt": 25271.00000, "vel_h": 16.34000, "heading": 154.13000, "
vel_v": 4.25000, "sats": 18, "batt": 4.28, "temp": -56.5, "aux": "01010C0A0380479B000000000000000000000000000000000000", "subtype": "0xD:DFM17P", "ref_datetime": "UTC", "ref_position": "MSL" }

Since there is no length byte for the AUX data, all the 26 bytes are in the output.