internet adres as registration ?

[vonsmalhausen]

thanks for looking in to this.
just had another anormality, this time with the logo ;
aldo the flight ID is diplayed corectly : LOT332, the old LTU logo, LTO shows up
see screenshot
deleted the LTO file now so it can not happen again, but how is this possible ?

[neroon79]

I have it from time to time, so for me this is a known effect, that occurs under following circumstances:

- A corrupted flight id is received for a few ADS-B / mode s frames. The corruption is of the type "valid false"*.
- After these few frames the correct flight id is received.
- unfortunately the logo for a flight is assigned with the first plausible flight id received. Id changes have no effect after the Logo was assigned.

*valid false: The corruption has altered the message in a way that the error correction marks the messagfe as true / valid, although the content is false.

Next time try untick/tick process Hardware flights. For me it solved the problem.

Ingo

[Runway 31]

Yes, good description Ingo.  Also I believe the issue from the start of the thread should now be corrected.  Please let me know if you see it again

Alan

[neroon79]

Is it necessary to perform a db download to correct the original issue or will a "popultae run" fix it too?

As I knew, that the problem will trigger alerts I'll keep the related alert setting for a while.

Ingo

[Runway 31]

I am not aware that it had anything to do with the database Ingo, most probably server software related.

Alan

[vonsmalhausen]

thanks for the info Ingo, will try the tick/untick trick next time i see it.
to Alan ; did not wanted to start another tread about this, as probably i would ended up with the same people responding on this, that basicly ( in my eyes ) relates to a DB/software problem.
sory if it causes inconvienience in the forum structure, if nessecary i'll move the last part in to a new topic if advised.

[neroon79]

Hi Alan,

I'm sending Alerts through own Mail account and got a alert mail after the small planet A320 was received. So I think that there might be another problem. I will post if it occurs again.

Ingo

[Runway 31]

no problem vonsmalhausen, as far as I am aware the first issue was server software related and this should now be corrected but time will tell.  We will only know it isn't corrected if it occurs again.

The second issue happens from time to time when a corrupt signal is received early in the reception of the aircraft and this stays the duration of your current reception as detailed by Ingo.

Alan

[neroon79]

Hi Alan, I received this one:

http://pla (49D287) Flight Number: CSA1DZ

Total flight information:
Flight ID: CSA1DZ
Registration: http://pla
Aircraft: B738
Routing: LFPG-LKPR
Latitude: N50 02.3
Longitude: E008 41.3
Altitude: 37000
Speed: 454
Heading: 075

-
Alert Generated by AirNav RadarBox - 5.00.072
http://www.airnavsystems.com
-
Note: Replies to this e-mail will not be read.

Ingo

[neroon79]

Hi Alan,

I performed a db dowload update* on one PC of my two PCs. The other is still using the populate updated db.

*method: replace with server db

Both PCs have just generated the following alerts for hex 49D287:

Total flight information:
Flight ID: CSA508
Registration: http://pla
Aircraft: B738
Routing: LKPR-EKCH
Altitude: 36025
Speed: 430
Heading: 344

-
Alert Generated by AirNav RadarBox - 5.00.072
http://www.airnavsystems.com
-
Note: Replies to this e-mail will not be read.


Total flight information:
Flight ID: CSA508
Registration: http://pla
Aircraft: B738
Routing: LKPR-EKCH
Latitude: N51 54.9
Longitude: E013 46.2
Altitude: 36025
Speed: 430
V/S: 256
Heading: 344

-
Alert Generated by AirNav RadarBox 3D - 5.00.072
http://www.airnavsystems.com
-
Note: Replies to this e-mail will not be read.

Seems that we have a not easily solvable problem.

Ingo

[Runway 31]

I am confused Ingo,

Are you getting these through the alerts or through your Navdata following a database update.

I shows as 49D287,OK-TVV,38027/4030,Boeing 737-86N,Travel Service Airlines,TVS,B738 on the server so no idea where it is coning from

It looks like you are getting them from an alert and not the database.  I searched the database for http://pla/ and nothing found.  Were the alerts local or network alerts?  I will advise Airnav in any case.

Alan

[neroon79]

Detailed version:

PC1: No Database update
PC2: Replace with server DB update

Alert setting: HTTP* in section Registration

Alerts sent through own mail account at google mail.

Network flights not activated on both PCs.

So far affected HEX Adresses:
49D287
489C08
501DA9

Both PCs sent me an alert for hex 49D287 at almost same time.

The http* Alert is in the Alert Log-List and the alert is displayed in the small alert message window.

For hex 49D287 the effect started month after V5.00.072 Software release. So in my opinion there must be something wrong with the db.

I hope it's clearer now.

Ingo

[Runway 31]

So the http/ affect for 48D287 started around over a year ago around June 2014 and you only see it in alerts and not on the grid.

I will set up an alert for http* in the registration field and see if I can replicate this on either local or network flights.

Airnav have been advised again regarding this issue,  Also what makes you think its the database at fault and not the Airnav software?

Thanks

Alan

[Runway 31]

I have the alert for http* active on the registration field for all flights including network flights at this time and no alert received.  OK-TVV 49D287 is currently on CSA509 on my network flights EKCH-LKPR, just landing LKPR.  Unfortunately CSA don't come over this way to allow me to pick it up on local flights.  The other two do not appear active this time.

Alan

[neroon79]

Negative Alan,

the effect started in april 2015 for hex 501DA9 and for hex's 49D287 and 489C08 a couple of days ago.

Forgot to tell: reg seen in list, on map, in alerts and in Log reports.

PC with populate cycles: 49D287, 489C08 is false in the db, 501DA9 is correct in the db.
PC with server db dowloaded a couple of hours ago: 49D287 is false in the db, 489C08 and 501DA9 are correct in the db.

Ingo