EHS Messages Garbled

[esnelling]

Thanks again for previous help! I am successfully outputting the EHS bds messages after editing the script you provided. A large number of the messages seem to get garbled. The hex address is always clean but the ModeS FlightID is garbled about 95% of the time. Sample below it took 20 msgs before a correct FlightID appeared. To be clear, if I search on a specific aircraft, it sees the hex code correctly but misses decoding the FlightID all other bds messages. Here is a sample of my CSV; Code attached.

11336281.8378913,A2E935,#TKR#Y4#,,,,,,,-14.406,638,,161,,-14752,10208
1611336281.838103,ADC1EF,B###N#PF,12816,,854.0,35.2,,1312,-8.0,12,70.312,231,2.624,-8192,192
1611336281.838188,AD4873,R###XS0H,54416,,894.4,-30.6,,,1.219,16,298.828,300,,1248,256
1611336281.83827,ABDD63,#PAC_#Z4,,,,,,,,1384,,,,,-10624
1611336281.8383174,AC7103,CU4UV#P#,12816,22336,,35.2,,170,,66,70.312,686,0.34,,1056
1611336281.8383658,A340FC,5#A#####,,61456,979.3,,174.375,,,,,,,,
1611336281.8384125,A41B52,J###F#S,,,,,,756,,,,483,1.512,,
1611336281.8384583,A41B52,EG#E#B_B,12832,7744,,35.2,100.547,46,-15.844,,70.488,,0.092,-16224,
1611336281.838506,AC59AA,COV#4#PW,12816,15712,861.6,35.2,,1318,,46,70.312,634,2.636,,736
1611336281.8385534,A9B7F6,B#V7##PN,12816,,1100.4,35.2,,1466,-8.0,28,70.312,2,2.932,-8192,448
1611336281.8386016,AC85EE,D##X#U0H,54304,,,-30.9,82.266,,,16,298.301,,,,256
1611336281.838649,ABDD63,ASH6072,,19584,1091.3,,,,,320,,,,,5120
1611336281.8386955,A4795A,#8#D####,,57776,,,,,,,,963,,,
1611336281.8389168,A70699,#_#F#E##,61440,,,-11.2,,,,,337.5,,,,
1611336281.8389654,AD4873,HP#B#D#8,61504,,,-11.1,,,,,337.852,,,,
1611336281.8392606,A9BF27,CB#7_F#Z,12816,2688,1100.8,35.2,,,,,70.312,533,,,
1611336281.8394158,A36212,2PI#D#X#,,,,,,,,1024,,129,,,0
1611336281.8394632,A4795A,DAL534__,,,1079.1,,1.582,430,,,,,0.86,,
16

pyModeScode.txt

[junzis]

Your decoding logic is quite wrong. You can't simply pass the same message to all the deocding functions...

A message can't possible include all the flight informatio, right? You must first indentify the message type before deocde the content.

If you are new to Mode S. I recomment you to carefully take a look at following book:
https://mode-s.org/decode/

Once you have understood the fundamentals, then take a look at the decoding logic for modeslive:
https://github.com/junzis/pyModeS/blob/master/pyModeS/streamer/decode.py

[esnelling]

Thanks again for the speedy reply. The truth hurts, but good to know :) Yes, makes perfect sense now; I was overly hopeful for getting this in action for a specific test that was planned today. Appreciate the guided direction; not my area of expertise but it's fun to learn something new that can be of use. Have a great weekend.

[esnelling]

Wow, that was fun to relearn all the bin/hex/decimal conversions and see what's really happening on 1090MHz. Thanks again for the excellent documentation on your project. I am looking only for 4,0 5,0 and 6,0 messages. Since we are just listening to replies I understand the checking logic, but there is something I still don't understand. I get different results when I use "if pms.bds.infer(msg) == 50:" than when I use the "if pms.bds.bds50.is50(msg) == True:" It seems like the 'is50' and 'is60' modules identify quite a few messages that are not really track and turn or heading and speed report messages. Whereas checking the bds type explicitly works better. It is worth noting that in my environment (midwest US), I am not expecting many if any 4,0 5,0 or 6,0 replies. Thanks.

[junzis]

You are welcome, @esnelling.

I guess you might have figured out this already. In general, you can run pms.bds.infer(msg) to find out the BDS code. If it returns a unique BDS code, you can then use different functions to decode the message.