Closed SDRSKY closed 2 years ago
The number is not "wrong". The number is the internal number used by the iridium network to identify the satellite. This number is not the same as the names in the "official" NORAD satellite list. It is possible to create a mapping by correlating the satellite position against TLE data, but there is no guarantee that this mapping is not changing at any point.
In fact I have written such code in the past -- I should probably find it and commit it.
Hello Sec, many thanks for the quick reaction. This is clear now. When you can find some code for solving the mapping problem it would be great. Otherwise I will make al list for mapping the used numbers and the "official" numbers.
I have found and fixed the old code to run on my machine again. Will have to polish it a bit, but hope to push something in the next week or so.
I just pushed the respective code in the iridium-toolkit repo.
You will need to install the python3 skyfield module and have TLE data in tracking/iridium-NEXT.txt
- which you can fetch/update that by running cd tracking && ./update-tracking
Pipe some parsd IRA into reassembler.py -m satmap
and it should output a mapping for those based on TLE data.
Please note that the TLE data and your received IRA frames need to be the same age. If they differ by more then a couple of days, accuracy of the mapping may be reduced.
If you want a mapping of all current satellites, you will need IRA frames from about 12-13 hours. To save some time, it should be enough to only pass about every 5th IRA into the reassembler like this:
cat output.parsed |grep ^IRA|awk 'NR % 5 == 0' |./reassembler.py -m satmap
Let us know if it works for you.
Hi Schneider, I am using GR-Iridium and Iridium-toolkit preinstalled on DragonOS. In the output of the IRA frames I see that the satellite number is not correct. In the frame format discription i read that there are only 7 bits used for the satellite number The Iridium Next satellites have numbers from 100 and above. So 8 bits are needed to display these numbers properly. Is this problem already solved in a newer version of the toolbox? Or is there a workaround for this problem?