Uncertainty & Accuracy parameters

[JoseAndresMR]

Hello everyone,

First of all, my name is José Andrés and I am member of a robotics research group focused on UAVs. We are recently introducing our research on ADS-B for UTM utilities and this project fits perfect with our first requirements. So thank you so much for such a great job of code and manual book.

I am implementing NACp, NACv and SIL myself as well as version 2 for NIC. Here comes the point that nic_sup_b (NICs) is defined as a bit (40) part of the incoming msg whatever TC it is. In contrast, regarding to the book, NICs should be defined by bit 76 of TC=31 "operation and status messages". It is also the same definition for NICa in version 2.

Maybe I did misunderstand something.

By the way, I know it is a ten-minutes-issue, but I would share accuracy & integrity parameters implementation if you find it useful.

Thanks in advance for your help

[junzis]

@JoseAndresMR, Thanks for the comment. You are right. The NIC function in pyModeS is not correct. It requires more work here. I am still working on the dev-2.0 branch of the pyModeS with more fuction, Such as ADS-B version, operational status decoding, etc. Hope all these will be included in the 2.0 release.

Yes, It would be great if you can share your code. Just make a pull request. I will have a look and merge it into the new branch.

[JoseAndresMR]

That's perfect. I will share it as soon as it is ready with new changes.

I think it would be more suitable if adsb.py became a class in order to get all these parameters (version number, NICs, NICa, NICb, NICc, NIC, SILs) inside once known. Let me know what you think and I will do a pull request with all staff so you can check it.

[junzis]

Hi @JoseAndresMR, I implemented the decoder fully functional (not OOP) from the start. All the decoding functions take a message and spell out something certain. The message type is checked and raise errors if not matching.

I understand this scarifies the flexibility of handling different message types and requires the user to build a flow logic on top of it. But I think it is very simple to read and use.

So I would still recommend keeping the NIC/NAC decoding the same way. Of course, we need to buffer multiple messages for each aircraft in order to get the versions right. There are also other cases, such buffering is required. That's when the new stream class is put in place in dev-2.0 branch.

https://github.com/junzis/pyModeS/blob/dev-2.0/pyModeS/streamer/stream.py

Here we can perform higher levels of logic, for example, the NIC/NAC identification.

I am going to change the dev branch as the main branch since internally we are are soon abandoning the 1.x version too.

[JoseAndresMR]

Hi @junzis . from the very first moment I got on it, I understood the hierarchy of the code and also think this is the best way. Pull request is already sent.

About next improvement on these parameters, this is my point of view: store physical threshold attributes (i.e. Rc for NIC) on a .csv file. Then, in the code, read it and create a data frame ready for every actualization of U&A parameters. In addition, I think that it would be more suitable if we directly feed the data frame with raw ADS-B inputs (like TC or NICs) and extract NIC and Rc. Code clarity would be improved and data would be better stored and accessible.

[junzis]

With some bug fixing, I update the streamer with the uncertainties parameters. It works nicely. Here is a screenshot of the live terminal:

Yes, I will incorporate the exact uncertainty values from a csv, then will just show these values. In this way, we can add the version 0 uncertainty too.

[JoseAndresMR]

That's nice! In a few days I will make a new pull request with both version 0 and csv staff implemented