Database Writer Needs Some Work

Are you having problems with using or developing a plugin? Let me know here.
Post Reply
nzradar
Posts: 20
Joined: Wed Nov 07, 2012 4:42 am
Location: New Zealand

Database Writer Needs Some Work

Post by nzradar » Thu Mar 14, 2013 11:53 pm

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
Michael
New Zealand
Flightaware Flightfeeder System/VRS

agw
Posts: 2241
Joined: Fri Feb 17, 2012 3:20 am

Re: Database Writer Needs Some Work

Post by agw » Fri Mar 15, 2013 12:16 am

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.

nzradar
Posts: 20
Joined: Wed Nov 07, 2012 4:42 am
Location: New Zealand

Re: Database Writer Needs Some Work

Post by nzradar » Sat Mar 16, 2013 8:14 am

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?
Michael
New Zealand
Flightaware Flightfeeder System/VRS

agw
Posts: 2241
Joined: Fri Feb 17, 2012 3:20 am

Re: Database Writer Needs Some Work

Post by agw » Sat Mar 16, 2013 7:10 pm

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.

ianhind
Posts: 19
Joined: Mon Apr 30, 2012 10:40 pm

Re: Database Writer Needs Some Work

Post by ianhind » Thu Mar 21, 2013 9:23 pm

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".

Post Reply