MRAR messages

[lucapaganotti]

Hi all,

I'm developing a C++ library in order to decode enhanced squitter and Mode-S messages taking pyModeS as reference so to be able to confront decoded messages.

I'm interested in determining the positions of aircrafts and to have some positions related meteo data.

I'm correctly getting and identifying aircrafts and their positions (DF17). I store aircrafts' data in a live map where the key is the transponder id (addr as per pyModeS) and the value is a suitable data structure to hold positions and other metadata. I'm able to correctly decode MRAR Mode-S messages, confronting them with pyModeS decoder I get the same results on both sides.

But the transponder id I get from MRAR messages is almost never contained in my identified aircrafts' map. I wish to be able to relate meteo data with the source position. When the transponder id is (rarely) found in the map and has at least one position, meteo data are always void and this seems to always happen for small aircrafts (cessna, etc... ), so it seems that I can get positons or, (exclusively) meteo data.

Has anyone some suggestion? Am I trying to do something not feasible?

Thanks for any answer, have a nice day.

[paulmadejong]

Are you only observing this for MRAR data, or does it also apply to other DF20/21 (Mode-S EHS) messages? It is possible that your received data might have a different parity setting, resulting in the aircraft ID already being decoded. In this case, the ID does not need to be decoded but can be found in the last 6 digits of the raw/binary message. To my knowledge, pyModeS does not adequately handle this situation, so I have taken it upon myself to verify it.

[junzis]

hi @lucapaganotti, as Paul pointed out, MRAR is indeed only in DF20/21, and most aircraft do not have MRAR capability. You can take a look at the following paper: https://www.mdpi.com/2504-3900/59/1/4 (Figure 2 & 3). Only a few aircraft types have MRAR capability (BDS 44 & 45).

More details on MRAR decoding can be found at: https://mode-s.org/decode/content/mode-s/8-meteo.html

I hope this helps.

[lucapaganotti]

Hi Paul, thanks for your answer,

I should check my code, I'm writing a c++ library in order to decode these messages, my project is stuck at the moment as I've not enough time to dedicate to it. Yes. Anyway as I can remember I'm concentrating on DF20 and DF21 messages, I've read the docs on https://mode-s.org/ https://mode-s.org/decode/content/mode-s/8-meteo.html that I used as the basis of my implementation, I cannot exclude an error of mine but I should have similar behaviour also for other messages that instead behave correctly.

Anyway, as I will get back to this project, I'll make more detailed checks.

Thanks again for you answer and have nice Christmas holidays.

Best regards.

-- lp

---

-- Dott. Ing. Luca Paganotti -- Via Baroffio 4 -- 21040 Vedano Olona (VA) -- 393 1346898

-- softech s.r.l. email: -- @. -- @. -- https://github.com/lucapaganotti -- sourceforge email: -- @.*** -- skype name: luca.paganotti [image: http://it.linkedin.com/in/lucapaganotti] http://it.linkedin.com/in/lucapaganotti

---

-- Mistakes are portals of discovery - JAAJ

---

On Mon, Dec 18, 2023 at 5:03 PM Paul de Jong @.***> wrote:

Are you only observing this for MRAR data, or does it also apply to other DF20/21 (Mode-S EHS) messages? It is possible that your received data might have a different parity setting, resulting in the aircraft ID already being decoded. In this case, the ID does not need to be decoded but can be found in the last 6 digits of the raw/binary message. To my knowledge, pyModeS does not adequately handle this situation, so I have taken it upon myself to verify it.

— Reply to this email directly, view it on GitHub https://github.com/junzis/pyModeS/issues/154#issuecomment-1860904205, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOYWHPGXIQJKFFKLWOXHVLYKBSLPAVCNFSM6AAAAAAZRJUMDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRQHEYDIMRQGU . You are receiving this because you authored the thread.Message ID: @.***>