Errors with RB/PP/FD7 and the FRL route lookup service

[tarbat]

Does anyone else use Planeplotter and Flight Display 7 (FD7) with their Radarbox?

There appears to be a problem with this combination.  Looking through my Wireshark logs, I see that using FD7 with Planeplotter creates lookup errors when using the FRL service for route lookups.

The call made to FRL looks like this:
<UserName>Tester</UserName><FlightNumber>LOG14QJ</FlightNumber><Latitude>57.8367</Latitude><Longitude>-3.823</Longitude><ModeScode>G-LGNC</ModeScode>

The reply back from FRL looks like this:
<Flight><FlightNumber>LOG14QJ</FlightNumber><Error>Please enter a valid Mode S code</Error></Flight>

Looks like somewhere between Radarbox, Planeplotter, FD7, and the FRL service the ModeS hex code is getting substitutes for the aircraft registration (G-LGNC in this example).

[DaveReid]

Does anyone else use Planeplotter and Flight Display 7 (FD7) with their Radarbox?

There appears to be a problem with this combination.  Looking through my Wireshark logs, I see that using FD7 with Planeplotter creates lookup errors when using the FRL service for route lookups.

The call made to FRL looks like this:
<UserName>Tester</UserName><FlightNumber>LOG14QJ</FlightNumber><Latitude>57.8367</Latitude><Longitude>-3.823</Longitude><ModeScode>G-LGNC</ModeScode>

The reply back from FRL looks like this:
<Flight><FlightNumber>LOG14QJ</FlightNumber><Error>Please enter a valid Mode S code</Error></Flight>

Looks like somewhere between Radarbox, Planeplotter, FD7, and the FRL service the ModeS hex code is getting substitutes for the aircraft registration (G-LGNC in this example).

Other than confirming that I'm seeing the same thing in the server log for a very small proportion of queries, I'm at a loss to explain this and it certainly doesn't seem to be a problem at the FRL end.

By the way, you might want to edit the lat/lon in your post  :-)

HTH
Dave
www.flightroutelookup.com/FlightRoute/

[tarbat]

Other than confirming that I'm seeing the same thing in the server log for a very small proportion of queries, I'm at a loss to explain this and it certainly doesn't seem to be a problem at the FRL end.

Dave, thanks for confirming from the server logs.

I've had no response on the Planeplotter forum.  And FD7 is no longer supported, so it won't get fixed there either.

Dave, is there any chance you could relax the validation to allow invalid ModeS hex codes - it can't really be needed to do a route lookup, can it?  Your FRL service is by far the best route lookup - I rely on it to add/correct routes in Radarbox.

[DaveReid]

Dave, is there any chance you could relax the validation to allow invalid ModeS hex codes - it can't really be needed to do a route lookup, can it?  Your FRL service is by far the best route lookup - I rely on it to add/correct routes in Radarbox.

The reason the Mode S code is required is so that the server can look up in the database whether it's a Mode S only or ADS-B aircraft.  If the latter, the aircraft's coordinates are then used to do a sanity check on the route in the database (and to work out which is the current leg if it's a multi-sector flight), and if it's a non-ADS-B aircraft then a much cruder check is done based on the user's location.

These are invaluable in detecting incorrect or out-of-date routes, so I don't plan on making any changes, I'm afraid.

[tarbat]

Okay, thanks for looking at this anyway Dave.

I've reverted to using FlyteCom as the primary lookup for routes in FD7.  It seems to find most routes, even those difficult to find Loganair ones.