c34dft input arguments parsing problem

[flux242]

./c34dft --json /dev/stdin
--json konnte nicht geoeffnet werden

Additional question: the dft_detect returns C34C50 for both sonde types. As far as I don't know what sonde type it is I have to start both sondes decoders at the same time:

    DFM9) decoder="tee >($DECODERS_PATH/dfm09mod --ptu --ecc --json /dev/stdin > /dev/stderr) | "$DECODERS_PATH"/dfm09mod --ptu --ecc --json -i /dev/stdin > /dev/stderr";bw=10 ;;
  C34C50) decoder="tee >($DECODERS_PATH/c34dft -d1 --ptu --json /dev/stdin > /dev/stderr) | "$DECODERS_PATH"/c50dft -d1 --ptu --json /dev/stdin > /dev/stderr";bw=19.2 ;;

the same for the DFM sonde because I don't know which one it is DFM9 or DFM6

Q1: can the dfm decoder automatically invert the input signal and then adjust returned id type accordingly?
Q2: would it be possible to distinguish between C34 and C50 by returning C34 and C50 separately from the dft_detect?

or am I missing something?

[rs1729]

Well, the C34 decoder has no JSON output, only C50. I added JSON output to C50 to see if it would be used in auto_rx, but I think it is still pending. It was not clear that the C34 would continue to be in service.
The detection of C34 and C50 is very similar, and AFSK is pita. The C50 AFSK modulation does not have the idle states between 8N1 stop and start bit. (And the NMEA data format is a bit different.) dft_detect does not go so deep, since the C50 is not very common, the effort is kept to a minimum.
Q2: probably, but would take more computing effort, and dft_detect has to rule out many different types, so if it is not necessary, rather won't do it. M10/M20 is a similar problem. Same with the Meisei types, though there both in one decoder. It's often a trade off.

For DFM-06/09/17 it is different, there is only one decoder for all DFMs. The only thing that matters is polarity, and that's given by the sign of the dft_detect output. In the early versions of dft_detect/rs_detect the sign was relative to the old dfm06-decoder, then I changed it to be relative to the new decoder dfm09mod. Anyway, it depends on your receiver setup, which sign is which, because e.g. the soundcard could invert the polarity, or the sdr program thinks different about IQ sample order (early sdrsharp). The decoders are ment to be compatible with rtl_sdr and rtl_fm, i.e. the dfm09mod decoder should be used with + polarity for DFM-09 and -i or inverted polarity for DFM-06 (and early DFM-09 with DFM-06 hardware).
E.g. if dft_detect outputs DFM9: 0.9133, use dfm09mod as it is, however if the output is e.g. DFM9: -0.8634, use dfm09mod -i ... for that signal. If your sdr-setup has same polarity as rtl_sdr, the negative output probably indicates DFM-06 or Pilotsonde, or some DFM-17 variant, have seen both DFM-17 (was it the "D"-Version?), maybe DFM-17-Tests.
You could also try dfm09mod --auto -vv for auto-detect. Is this that you asked in Q1? I cannot say how reliable the --auto option is.
Option -vwill give you the serial number and packet number of the serial number which gives you some clues what model it is. "ID06" is DFM06, "ID09" is most likely DFM-09 (packet "0xA"), "ID-C" is probably either DFM-17 or DFM-09P (w/ pressure sensor), then there is also "ID-D", and the pilotsondes have lower packet numbers "7" or "8" (they don't have so many different packets).

Remark:
The DFM radiosondes have 9 different GPS packets and between 5, and 0xD (or more?) PTU/config packets depending on the type of DFM and sensors. The last of the config packets contains the serial number.
https://github.com/rs1729/RS/blob/master/dfm/dfm06.txt

[flux242]

ah, ok, thank you for the explanation. I have removed c34 decoder and take into account the sign of the second parameter returned by dfm_detect to invert polarity for DFM sondes.

[rs1729]

Added JSON output to C34 decoder.