Page 1 of 1

Database Writer Needs Some Work

Posted: Thu Mar 14, 2013 11:53 pm
by nzradar
Having been using VRS and the DBW plugin for a couple of days I notice that the LastSeen column is only ever updated after the plane has disappeared. When using the DBW feature to write a report on the flights being tracked this presents a problem because the time is not recorded in order to know that the flight is currently active and also what state the flight is in such as Lat/Long, Squawk and Altitude etc.

A solution is required and I think it is this:

Write to the Flights table each time a new message is received from the flight updating the LastSeen column and all the others where the message is relevant. So if the message includes altitude update the LastAltitude column as well as the LastSeen column etc.

This would boost the usefulness of the DBW plugin immensely.

Thanks,

Mike
nzradar.com

Re: Database Writer Needs Some Work

Posted: Fri Mar 15, 2013 12:16 am
by agw
The plugin is copying the behaviour of BaseStation, which doesn't update the Flights table with the final values for the flight until 20-odd minutes after the flight is last seen. If it behaved differently then it might not work with other 3rd party tools that were written to work with BaseStation.

Re: Database Writer Needs Some Work

Posted: Sat Mar 16, 2013 8:14 am
by nzradar
I see your point but I'm not sure Basestation does it correct either so just mimicking other software is poor development when the logic is clearly flawed (happy to be convinced).

Another important but less annoying issue is the writing of the squawk to the Flights table. If the assigned squawk has a leading zero this is not saved, so for example if it's 0214 then it is saved as 214 and thus any reporting reflects this which looks daft because everyone knows a squawk has four digits. Is this a problem with SQLite?

Re: Database Writer Needs Some Work

Posted: Sat Mar 16, 2013 7:10 pm
by agw
The goal is to mimic the behaviour of BaseStation to give the plugin the best chance of working with other tools, I'm not going to change it. However the source for the plugin is here - http://www.virtualradarserver.co.uk/Dow ... SourceCode - if you want to do your own build of the plugin then be my guest.

If you really want it to update the database on every message received then you can get the effect by adding this line after line 392 in the TrackFlight method in Plugin.cs:

Code: Select all

Line 392: UpdateMessageCounters(message, flight);
Add this: _Database.UpdateFlight(flight);
Bear in mind that if you're getting 1,000 messages a second then that's 1,000 database writes a second. If you don't mind waiting ten seconds or so between updates you can take the heat off SQLite by deferring updates. Change the FlushFlights method in Plugin.cs instead of doing the above. Add this line after line 571:

Code: Select all

Line 568: foreach(var kvp in flushEntries) {
Line 569:     _FlightMap.Remove(kvp.Key);
Line 570:     _Database.UpdateFlight(kvp.Value.Flight);
Line 571: }
Add this: foreach(var flight in _FlightMap.Values.Select(r => r.Flight)) _Database.UpdateFlight(flight);
Regarding squawks, they are integers in the database. If 0214 is written to a squawk field then it's stored as the integer 214. When you read the squawks out you need to pad them with leading zeros.

Re: Database Writer Needs Some Work

Posted: Thu Mar 21, 2013 9:23 pm
by ianhind
I see your point but I'm not sure Basestation does it correct either so just mimicking other software is poor development when the logic is clearly flawed (happy to be convinced).
Go and argue your point at the Kinetic web site. And see what success you get!

As an "add-on" to Basestation output, VRS needs to conform to the perhaps incorrect format. And with the recent influx of DVB-T dongles, if the interfacing software also mimics the "flawed" Basestation output, then VRS won't work if it is changed to be "correct".