| 
View
 

SQWK Mlat - Planeplotter Updates Reference Notes

Page history last edited by Danny Gooch 3 years, 6 months ago

This section contains notes from Planeplotter updates that relate specifically to the SQWK Mlat feature and functionality

 


 

 

SQWK Mlat Version Updates and Notes

 

Additions and changes – Planeplotter version 6.5.2.6

 

Message counter

 

The View..Aircraft display and the "a" window now include a message counter for each aircraft.  This simply counts up the number of messages from each aircraft since first reception in the current session.  If the aircraft times out, the counter will reset.  It may be particularly useful to help to decide if an XXnnnn ping (Mode-A) is real (many pings) or erroneous (few pings), since there is otherwise no error checking on those pings on which to base confidence.

 

To accompany that new features, there is a new noun in the conditional expression vocabulary "message count"/"msg", which can be used in a condex to display only those aircraft with more (or less) than a certain number of messages.

 

Sector Master User - Mode-A  (SMUA)

 

This release includes support for selected users to be nominated as SMUAs, which will monitor a range of Mode-A squawks in their area to initiate an Mlat of there is no associated position.  Since XXnnnn targets are only passed through the sharing system when they have an Mlat position, this service will ensure that active squawks will, where possible, be located and therefore shared.

 

 

Additions and changes – Planeplotter version 6.5.2.3

 

XXnnnn squawks

 

Currently, if enabled, PlanePlotter will create dummy hex codes in the form XXnnnn for any squawk codes that do not correspond to a known Mode-A squawk from a Mode-S/ADS-B aircraft that is currently being received.  In this release, XXnnnn entries will also not be created if the received code matches the code corresponding to the altitude of any Mode-S aircraft currently being received.

 

Additionally, for those XXnnnn entries for which the code has a corresponding altitude if considered to be Mode-C, that altitude is now shown in the routes column of the View...Aircraft window.  The reason for the apparently illogical choice of column, is that some users currently populate the registration and route columns of XXnnnn aircraft by hand, and the altitude column itself, may be populated by PP itself, if it detects a ping-rate correlation match between a Mode-A and a Mode-C ping.  The equivalent altitude is listed merely for information purposes and does not necessarily indicate the likely altitude unless, of course, the XXnnnn entry was created in response to pings that were, in fact, Mode-C.  Many users disable the detection of Mode-A pings that have an identical Mode-C counterpart, in which case, this new feature has no effect.

 

'C' window displaying altitude

 

In the current version, pressing "C" displays a pop up window showing a graph of the altitudes of all aircraft being received either by Mode-S/ADS-B or by Mode-C.  Since any Mode-C ping could, in fact, be a Mode-A ping, this release suppresses the display of any pings that correspond to the known Mode-A squawk of any current aircraft.  In this way, the graph should be less cluttered with lines that do not actually relate to altitudes.

 

Additionally, in this release, moving the cursor over the "C" pop up window, displays the altitude at the cursor point.  This should make it easier to tell the altitude of recent traces that are furthest from the labelled axis on the graph.

 

 

Additions and changes – Planeplotter version 6.5.2.2

 

New in version 6.5.2.1 (not generally released)

 

XXnnnn codes and SQB database lookup

 

In this release, Mode-A codes of the form XXnnnn are no longer added or checked in the SQB database.  As the codes are dynamic there is no point in adding them to the database and for Mode-A enabled systems, it was previously adding an unnecessarily large processing load.

 

Script triggering of Mlats

 

Significant problems were occurring for popular Ground Stations when some users used a script to trigger Mlats, which had inadvertently included errors in the script that made an absurd number of Mlats in a short time.  To combat that possibility, external scripts can no longer trigger Mlats at an unresonable rapid rate.  Script-triggered Mlat requests made too quickly will be ignored.

 

New in version 6.5.2.2 (this release)

 

Script triggering of Mlats (continued)

 

Following on from the previous item, this release now reports, at each share cycle, the number of script-triggered Mlats that each system has performed.  This will allow us to help any users who accidentally run a buggy script, as rapidly as possible.

 

Additions and changes – Planeplotter version 6.5.1.9

 

Squawk matrix

 

This release fixes the vulnerability of the "q" window to reducing its size to the point where there is a division by zero.

This release also adds annotation of the squawk code to the right side and to the bottom of the matrix, to make it easier to identify the code of a particular tile

Additions and changes – Planeplotter version 6.5.1.8

 

View..Squawk matrix

 

This release of PlanePlotter introduces a new feature for aficionados of Mode-A/Mode-C aircraft. See the announcements section for details - October 29th 2020

 

Additions and changes – Planeplotter version 6.5.1.7

This release deals with some matters arising from the changes in 6.5.1.6.

 

Sharing Mode-A fixes

 

The new feature to allow sharing of Mlat fixes on Mode-A (non Mode-S) aircraft is now user-selectable.

In "Options..Sharing..Setup" there are tick boxes for Mode-A in both the upload and download sections.

   

Aircraft list

 

The option to display Mode-A/C pings in the aircraft list is now remembered between sessions.  In all previous releases it was reset to off when the program closed.

 

 

Additions and changes – Planeplotter version 6.5.1.6

 

Sharing Mode-A (Squawk) Mlat fixes

 

For some time now, Master Users have been able to perform Mlats on Mode-A (squawk) pings to determine the location of the aircraft.

The MU performing the Mlat was able to see the location of the aircraft but the data was not passed to the sharing system so could not be seen by others.

 

This version now uploads most Mode-A Mlat fixes to the sharing server and makes them available to other Master Users via the sharing network

 

 

Additions and changes – Planeplotter version 6.5.1.4

 

Triggering Mode-A Mlats from the "a" window

 

Hitherto, Mlats triggered from the "a" window required there to be some GS listed in the sharers list for a candidate aircraft before PP would allow an Mlat to start.  Because Mode-A Mlats are not shared across the network, this condition was never met for XXnnnn codes.  I have now removed that requirement so that Mlats on XXnnnn codes can now be triggered from the "a" window.

 

Triggering Mode-A Mlats from a script

 

In earlier releases, the OLE/COM function "MlatRequestByHex()" required there to be some GS in the sharers list otherwise no Mlat was initiated.  To deal with the XXnnnn codes, which are not shared, this requirement has been removed in this release.

 

AirSpy receiver Mlat status

 

Previously, the "Raw data" option in Options..I/O settings was unconditionally checked if the selected receiver was an AirSpy.  To avoid confusion where a user has multiple receivers, this is now conditional on the Raw data option being explicitly ticked in I/O settings, when an AirSpy receiver is in use.  Note that if you are currently using an AirSpy receiver and are a validated Ground Station, it would be prudent to check that Raw data is still checked after you have installed this release.  You may need to be tick it again.

 

 

Additions and changes – Planeplotter version 6.5.1.3

 

Mode-A Multilateration

 

This release includes a number of improvements to the recent Mode-A Mlat feature.

The code has been changed to avoid the situation, in any type of Mlat, to prevent ones own raw data from filling the raw data buffer before other users' data arrives.  Previously, highly productive users could actually reduce the success rate of Mlats by crowding out other users' data.

 

In the last release, the Mode-A raw data time tags for the SBS-3 and PlaneFinder receivers were inadvertently omitted from the data stream.  They are now included, which should increase the success rate considerably.

 

After the last release, it came to light that each receiver type time tagged the Mode-A packets in a different way.  The symptom of this was that Mode-A Mlats looked more like a bird's nest than the very crisp convergence of the hyperbolae for normal Mode-S Mlats.  I have now measured all combinations of receiver type and have harmonised the time tags for the Beast, SBS-3, PlaneFinder, and the RTL dongle interfaced by dump1090 running on the PC.  That should make the Mode-A Mlats look much tidier and be more accurate.  For obvious reasons, I therefore urge users that are Mode-A capable, of installing this version at the earliest opportunity.

 

Unfortunately, dump1090 running on an RPi connected to PlanePlotter presents several possible Mode-A time tag offsets depending on the version of dump1090 and the receiver type.  In this release I have made the default correction correct for dump1090-fa running on the RPi, so those installations will also now be harmonised.

 

For users with an RPi feeding PlanePlotter

 

For the other possible configurations of the RPi feeding PP, apart from dump1090-fa, there is, unfortunately no way that PP can 'see' into the RPi to determine what version of dump1090 or equivalent is running there, to enable it to use the appropriate offset correction automatically. Acccordingly, this release includes provision to log raw data in such a way that the server can analyse the time tags to determine the appropriate time tag offset to be applied, to bring the receiver into line with all the other harmonised receivers. Along with that, to complete the story, this release includes provision for the server then to pass the corrected offset to PlanePlotter so that the change takes effect and brings the system into line with all the others.

 

 

Additions and changes – Planeplotter version 6.5.1.2

 

General

Mode-C window size

This release should fix a problem with the size of the Mode-C window becoming corrupted.

 

Circles method for Mode-A pings

This release includes support for the "Circles" method to display the approximate location of a Mode-A squawk in situations where an Mlat is not successful.  A set of circles centred on each responding Ground Station, shows the Venn diagram indicating the area within which the aircraft is likely to be located.  You need to turn on the Circles method for this feature to show.

Options..Chart..Circle sharers..Enable/Circle fill.

 

Matching Mode-A and Mode-C squawks

This version performs a statistical analysis on the Mode-A and Mode-C pings that are received, in order to associate an altitude with a Mode-A XXnnnn aircraft.  Since these squawks have no checksum, the result is by no means guaranteed to be correct but the option may be useful in some circumstances.  View..Aircraft list display options..Mode-A/C..Attempt squawk/altitude correlation.

 

New option for dump1090-fa users

User who are running dump1090-fa on a Raspberry Pi to interface an RTL dongle or equivalent to PlanePlotter, should now be able to turn on Mode-A/C reception with the new option :

Options...Mode-S receiver..RTL dongle RPi dump1090..dump1090-fa mode ac

 

Mode-S/ADS-B Squawk code reception

For historical reasons, previous releases of PlanePlotter retrieved the current squawk code from DF5 and DF21 messages but not from DF17 messages.  This release adds the detection of the current squawk from DF17 messages.  In some areas, the DF17 sub-format is much more common than the other two formats, leading to a delay in displaying the squawk code.  That issue is resolved in this release.  Thanks to Dan Henry for spotting this long standing lacuna.

 

18/07/2020 14:49

 

Dump1090-fa sd-card install users

A new feature has been added allowing PP to request and enable mode-a/c data from Raspberry Pi users that installed using the FlightAware sd-card method.  This new method no longer requires logging in remotely to the Pi and editing configuration files every time the Pi software is updated.

 

This feature will only work if you have correctly identified your receiver in "Options.. I/O settings.." as "RTL>RPi+Dump1090".

 

To enable mode-a/c, select "Options.. Mode-S receiver.. RTL dongle RPi dump1090.. dump1090-fa modeac"  This will enable and place a check by the menu option if you look at it again.

 

Mode-a/c can now be enabled or disabled with this new option.  After making a change you must stop/start PP processing for the change to happen.  Also realize that there is an approximately 15 second smoothing factor in the "m" message rate display.  If you turn off mode-a/c and stop/start processing it will still display for a short time.

 

 

If you are running ppup1090 on a Raspberry Pi

Q. Will RPi ppup1090 installations set up to as Mode-A capable be of any use providing the raw data required for "normal" ground stations to Mlat?

 

A. ppup1090 has no way to know that anyone is interested in a particular XXnnnn code so it does not put the raw data into the buffer.  That means there is nothing to report if it was asked for it.

 

Q. So ppup will respond to ordinary Mlat requests but not squawk ones.

 

A. It's not so much that it wouldn't want to respond to squawk ones but that it does not record the raw data from such pings and does not act on the request for that data in the way that recent releases of PP do.

 

Regards

Bev

COAA

 

Q. Can you successfully perform Mode-A Mlats with a PC running PlanePlotter in download only mode receiving its local data from ppup1090?

 

A. If your RPi is the Ground Station; that is to say, it receives the raw data requests from the router and responds with raw data, then it will not be useful as a Ground Station for those who are trying to Mlat

Mode-A aircraft.  The RPi does not buffer raw data for Mode-A pings.

 

Having said that, notwithstanding the router configuration, it may be possible for your PP to perform Mlats on any targets that are available because some routers are smart enough to associate a returning UDP packet with a recent outgoing UDP packet to the same address and send the data to the PC not the RPi.  If that works for regular Mlats, it will also work for Mode-A Mlats although of course your receiver will not be contributing to those activities.

 

28/07/2020

 

Comments (0)

You don't have permission to comment on this page.