Our Callsign showing in Firelight

[sarwat1952]

I have been using Stratux for a long time now and find it very useful. Thank you for your great effort.

I am actually facing two issues:

The callsign of my airplane is (DMNKZ), but Stratux is always reporting it in ForeFlight as (DLZYM). I have no idea how to correct this, especially since the correct callsign is properly registered in Stratux.
While flying, Stratux sometimes shows my own airplane as nearby traffic. My transponder's Mode S is correctly registered in Stratux, so I'm not sure if this issue is related to my FUNKE transponder with ADS-B out. If so, what can I do to resolve this?
Thank you in advance for your help.

[VirusPilot]

How does Stratux display it on its own traffic web page? I searched through a couple of feeder databases but all of them have your plane DMNKZ properly displayed as a C42 so it appears to be a ForeFlight issue. Furthermore DLZYM would be used by a "Luftschiff" which is strange as well.

[hardtmedia]

Since it is being brought up, I have this issue, too and basically since forever.
I change the Ownship ID often, that is always when I fly another aircraft. I switch Types often.
From the top of my head, there are two icao IDs which resolve to the wrong registration.

I always assumed that you (as in @b3nn0) are using a database from somewhere which maybe is just outdated.

However, I found this:

stratux/main/traffic.go

Line 1573 in 5e63e5e

func icao2reg(icao_addr uint32) (string, bool) {

It seems that icao hex addresses are actually decoded into the registration.
The referenced method shows implementations for US, CAN, AU.

@b3nn0 is this the correct place to look for a solution?

Address Range for Germany would be 3C0000 to 3FFFFF.

I found this here script: https://github.com/wiedehopf/tar1090/blob/master/html/registrations.js
Which decodes the addresses in more detail. This is used in the ADSB Exchange frontend, as it seems.
They show D-M Ultralights, but the script is missing a D-M stride.

I downloaded the script and will try to figure out what is missing to decode german registered Ultralights correctly.

Maybe the limited decoding in traffic.go can then be replaced by the more complete version from ADSB-Exchange.

[b3nn0]

re. registration: Stratux can either guess the registration for a few countries (not for Germany), or use the Flight ID that's transmitted by your transponder. It has no other source/database/..
For OGN it has a database, but that's not used for ADS-B.
I would guess that it is foreflight that's doing something wrong, or your flight ID is misconfigured.
You can check the traffic page (potentially toggle the "Show Tail Number" switch) what Stratux knows. This is what it sends to the EFB. If the EFB shows something different, it's their fault.
@hardtmedia : Careful: dangerous superficial knowledge:
Afaik not all countries assign their ICAO Address in a way that allows computation of a registration/tail number. AFAIK Germany does not, so I think it's impossible to do this reverse calculation for German aircraft.

re. ownship shown as traffic:
Stratux should - in most cases - not show it if it's correctly configured. However, there is some logic that tries to detect if you are really currently flying this aircraft.
This is done, so people who switch aircraft a lot, can simply enter all ICAO adresses that they regularly fly. Stratux will then try to figure out which address(es) you are actually flying with right now, and still show the other ones. Maybe this logic fails for you for some reason?
If stratux decides to display an excluded aircraft, a log message (or well.. many messages) will be produced in your log file. You might want to check that after such occurence. Stratux will display the reason there why it thought that you were not actually in that aircraft.

[hardtmedia]

Spoiler: Didn't work

The linked script provides some specific mappings for Germany and I was able to reverse engineer a starting address for D-M registration. That seemed to work for VLY, however, the required start address for NKZ came up different with a very different offset. So yes, decoding won't work. At least I learned something :)

Flight ID that's transmitted by your transponder.
I know for a fact that the Flight ID in one of the planes, where this occurs, is correct. The other one.. I would not be surprised if not.
That would rule out a misconfig at least in this case.

I will try to gather data next time I fly that plane, which may be some time.