I flew with a friend who has SafeSky and uses it on his own plane normally.
I have pilotaware inc iGrid. This is setup with my planes hexcode.
When flying in my plane, but with his SafeSky running seperatly, we were getting a lot of ghost reports on my pilotaware.
However the hex code shown was 393F76, which is not the hex code for my friends plane.
Is there a way you can check on your servers why this hex was transmitted ?
Hello @marioair,
393F76 is not registered in SafeSky transponder list.
But you you can precise a date and time, I can see where it was coming from?
Fly safe,
Tristan
thanks, flight was on Friday 26th August between 1400 and 1530 utc
I was running PilotAware and was getting lots of alerts (I was NOT using safesky feed)
My co pilot was running SkySafe configured as shown and was also seeing ghosting
if you want to see a playback of the flight go to aircrew website
b2c97783
Hello, and thanks for the feedbacks. Your SafeSky setup is perfect.
I just checked for your flight, and I can see the traffic from hex code 40651B:
By design, SafeSky will show the most up-to-date and precise traffic location, regardeless of its source.
There is nothing in our logs that relates to 393F76. Could you please followup with PilotAware, and share with us their findings? Could it be that they do not de-duplicate traffic and were generating ghost alerts in PAW?
I suspect that on SafeSky, there was no alerts, since those 3 sources were you.
I just received this from PilotAware……
I just configured mine to emit an ICAO code of 40526F
But this is what was produced and sent to the OGN
SKY475048>OGNSKY,qAS,SafeSky:/192459h5223.53N/00127.45W’245/000/A=000239 !W42! id20475048 +000fpm gps17x6
I then changed to 444444, and it produced
SKY7F411F>OGNSKY,qAS,SafeSky:/193159h5223.53N/00127.45W’235/000/A=000239 !W31! id207F411F +000fpm gps5x3
I entered your code 40651B, and I got
SKY47CF4B>OGNSKY,qAS,SafeSky:/193338h5223.53N/00127.45W’235/000/A=000239 !W31! id2047CF4B +000fpm gps5x3
it seems safesky are scrambling the real ICAO code when sending to the OGN - that seems like a very silly thing to do for compatibility
Hello @marioair ,
Sorry for late reply, but we are on our way to the ultra-light world event in France.
Thanks for copying the reply, it’s pretty clear now. Indeed, to guarantee being anonymous when needed from SafeSky to OGN, we are creating a hash of the internal id. In this specific case, since the PAW id was encoded in safesky (would be the same for an ads-b or mode-s ICAO hex), we should simply respect and pass over the entered id. That way, PAW will receive it and will be able to deduplicate the traffic naturally.
Thanks a lot for raising this point to us, we are going to take an action and fix this.
Fly safe,
Tristan
Thanks. Is it legal to transmit false IDs?
I’m not sure what you mean by anonymous? Data transmitted on ADSB and mode S carries the proper hex code. It’s a core part of the standards. I think it’s a massive manipulation of the ecosystem if the codes of aircraft are collected from OGN and then scrambled by SS? Do OGN know you’re doing this?
If the intent is to protect the personal identity of the pilot then their ownership details with the aviation authority should be anonymous. Not the call sign.
Any update please?
Hello @marioair,
We are just back from the MULM 2022 in Blois. It’s been a fantastic event, and as an official partner, SafeSky has been used by AFIS agents to securely handle 800 registered aircrafts in and out over the week-end. Second year we are doing this.
That explains my late response…
Forget ly previous message. The issue is different. We are working hand in hand with the OGN team, and we are totally in sync when it comes to bi-directional data exchange. We are happily sharing SafeSky traffic to OGN so that other third party projects can also benefits from this. In return, we strongly advertise for OGN ground station installations so that we can support the project too. Beautiful partnership.
So in short, we are not ‘scrambling’ OGN ids in any ways. The problem was an encoding issue with aircrafts that has entered a custom id in SafeSky transponder. The patch has been applied today.
Thanks a lot for having reported the problem and supported us with this issue.
Please let me know in your next flight if this is working fine (no traffic alerts from your own PAW)
Fly Safe,
Tristan
Thanks for update. I’ll test it and report back issues.
However in the original screenshots I showed in this thread, we had not entered a custom ID but the correct hex code for the call sign.
So the explanation doesn’t seem to make sense. Can you let us know more info?
Looking today it doent appear its fixed:
I have been monitoring this today, and have seen the following
000050 : SKY000050>OGNSKY,qAS,SafeSky:/083915h4530.85N/00540.71E’136/003/A=000958 !W28! id20000050 +000fpm gps5x3
130AD4 : SKY130AD4>OGNSKY,qAS,SafeSky:/083914h4218.55N/00520.06W’013/106/A=003871 !W79! id20130AD4 +000fpm gps2x1
19BAB8 : SKY19BAB8>OGNSKY,qAS,SafeSky:/083917h5852.11N/00927.13E’239/083/A=001256 !W21! id2019BAB8 +000fpm gps5x3
2310D7 : SKY2310D7>OGNSKY,qAS,SafeSky:/083921h4703.59N/00646.00E’221/071/A=004055 !W97! id202310D7 +006fpm gps5x3
25900F : SKY25900F>OGNSKY,qAS,SafeSky:/083938h4913.55N/00308.41E’234/077/A=001883 !W27! id2025900F +000fpm gps5x3
2E1480 : SKY2E1480>OGNSKY,qAS,SafeSky:/083915h4217.10N/00520.05W’013/124/A=003900 !W70! id202E1480 +003fpm gps5x3
35311F : SKY35311F>OGNSKY,qAS,SafeSky:/083919h4209.56N/00823.93W’025/048/A=001282 !W88! id2035311F +003fpm gps5x3
38A77D : SKY38A77D>OGNSKY,qAS,SafeSky:/083951h4516.54N/00027.37W’434/000/A=000127 !W66! id2038A77D +000fpm gps5x4
38B810 : SKY38B810>OGNSKY,qAS,SafeSky:/083915h4440.82N/00109.51W’282/104/A=001679 !W49! id2038B810 -003fpm gps2x1
395D9C : SKY395D9C>OGNSKY,qAS,SafeSky:/083915h4440.31N/00554.55E’049/060/A=006138 !W83! id20395D9C +003fpm gps5x4
3DF39E : SKY3DF39E>OGNSKY,qAS,SafeSky:/083921h5251.43N/00812.54E’214/091/A=000702 !W28! id0C3DF39E +000fpm gps4x1
48FD60 : SKY48FD60>OGNSKY,qAS,SafeSky:/083915h5359.04N/01626.91E’290/099/A=004435 !W20! id2048FD60 +000fpm gps4x1
64F92B : SKY64F92B>OGNSKY,qAS,SafeSky:/083915h4127.59N/00237.20W’206/085/A=005393 !W28! id2064F92B +000fpm gps5x6
934DF9 : SKY934DF9>OGNSKY,qAS,SafeSky:/083915h4749.84N/01613.49E’280/003/A=000902 !W95! id20934DF9 +000fpm gps5x6
These are (in the most part) already allocated, as you can see here
http://www.aerotransport.org/html/ICAO_hex_decode.html
Also I enabled my device and entered code 400123 , but saw the following sent out
444111 : SKY444111>OGNSKY,qAS,SafeSky:/084818h5223.53N/00127.45W’316/000/A=000239 !W14! id20444111 +000fpm gps5x3
So there is still an issue.
Hello,
Thanks again a lot for supporting this issue.
The latest examples needs to be interpreted right. Let’s focus on one:
SKY48FD60>OGNSKY,qAS,SafeSky:/083915h5359.04N/01626.91E’290/099/A=004435 !W20! id2048FD60 +000fpm gps4x1
Means that station called “SKY48FD60” coming from the APRS TO-CALL transmission system is “OGNSKY”. This station is transmiting a position for id “48FD60”.
Because it’s coming from OGNSKY with a station starting with SKY, this ID is NOT intended to be a ICAO hex code as defined by ATDB - ICAO 24-bit addresses - Decode
We had some exchange with the team at OGN tonight, and they confirm that when an ICAO hex code is to be used as an official ID, the expected message format is:
ICA48FD60>OGNSKY,qAS,SafeSky:/083915h5359.04N/01626.91E’290/099/A=004435 !W20! id2048FD60 +000fpm gps4x1
Where the station name starts with “ICA”.
From OGN documentation: Aprs Interaction Examples - Open Glider Network Project
Therefore, as agreed with OGN team, we have just applied a patch to use ICA as a station prefix for ICAO codes.
When we now use ICAO hex “4497C3”, we are getting the correct messages (see screenshot).
We are also in touch with PilotAware team to ensure we are all aligned on the approach.
Fly Safe,
Tristan
In addition, we are going to hash the safesky internal IDs (the one not based on real ICAO as entered by the pilot) so that they will also translate into hex code > F096FF so that they will never match any existing allocated hex codes.
This should retro-fit with any systems, regardless of the “ICA” prefix interpretation.
Tristan
This message is the confirm that after some exchanges with the OGN team and the PilotAware team, the patch that was deployed last week is addressing the issue reported.
We are going to conduct additional flight tests in the next coming days to confirm with various configurations.
Fly Safe everyone,
Tristan
