| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

Networking Test Functions

Page history last edited by info@coaa.pt 4 months, 2 weeks ago

In Plane Plotter version 5.4.6 and later, use the Help Test Networking, Check sharing status menu function.  If you are not already using that version or higher, please upgrade as soon as possible from here => Download Plane Plotter.

 


 

What tests are available and what do they do?

 

The first three options in Help, Test networking open a web page in your default browser.

 

  • Check sharing status: opens the Network sharing test page, where you can see the error in your PC's clock, the number of aircraft uploaded and downloaded, and your status for raw data and multilateration.

     

  • Check raw data out: opens the Plane Plotter Network Test page, where you should see a non-zero value for the "PPnnnn raw buffer content = NNNN" box in the centre of the page.  Pressing F5 (Refresh) should change the number.  Please note that you should only expect a value here if you are wishing to be a Ground Station for Mlat.  Please close the test Web page after use.

     

  • Check raw data in: opens another the Plane Plotter Network Test page which tries to send an Mlat message to your PC.  A box should pop up from Plane Plotter, stating that a test message has been received.  If not, check your router and firewall settings.  Please close the test Web page after use.

     

  • The fourth one opens a Windows Command Box.  The IP Address is what you would need to enter into your router to forward Mlat packets to your PC.  If there is more than one connection displayed, look for the adapter associated with your Internet connection.

  • The fifth test is for the Ground Station validation.  See below for a discussion of results.

 

If the web pages are not opening, you probably have some security setting that prohibits a program from launching your browser or you have no browser or no Internet connection.

 

 

Test GS/MU functions

 

This function will open a Web page, with results such as these:

 

1 - Sharer tD
      is currently a Master User. 
      is currently a Ground Station 
      has "raw raw" enabled in Options I/O settings according to the information submitted in sharing. 
2 - Starting 1st simple poll test.....
      responded to 1st simple poll test
3 - Starting additional simple poll test.....
      also has "raw data" enabled in Options I/O settings according to the information obtained by direct polling. 
4 - Starting 2nd simple poll test.....
      responded to 2nd simple poll test (PP12345 raw buffer content = 21461 )
      raw data is available in PlanePlotter.
5 - Starting regular plane data transfer test....
      responded to a request for data with 1428 bytes.
6 - Starting raw data transfer test....
      responded to a request for 250 raw data reports with 249 reports.

 

If any of the tests fail, be sure to try and resolve them yourself before asking for help on the Groups.io group.  If you do need help, be sure NOT to post your PP number (PP12345 in the example above) in your post.

 

What to do if a test fails

 

Test 6  fails - likely port forwarding is not set up in your router.  See this Wiki page.

 

What to do if someone else's share code appears on the PlanePlotter Ground Station/Master User Test output page.

 

 See http://planeplotter.pbworks.com/w/page/17117305/MLAT%20trouble-shooting#WhydoIseesomeoneelsessharecodeaswellasmineonthePlanePlotterGroundStation/MasterUserTestoutputpage

 

Flatlining

 

If all the tests are passed, there is now a graph showing the progress of the raw data time tag.  You expect a graph with one or more rising green lines.  Flat green lines (flatlining or flatline) are an indication that you have an incorrect software version, possibly of the RTL1090 software.  Be aware that RTL1090 has now been superseded by the more accurate DUMP1090 program.  Be sure you are running version 2 of that program.  John Locker notes: [if you see flat green lines] you need to make sure you are using DUMP1090 and tick the raw data box in the configuration section, then try the GS/MU test again. 

This is what you do want to see:

 

 

 

The version number of Plane Plotter is shown in the heading (6.4.3.4 in the example above).  Bev notes: The yellow line along the bottom changes state every second.   The green trace wraps should occur, on average, 1.2 times for every second.  The pairs of numbers in the brackets show the number of wraps of the green trace : the number of changes of state of the yellow line.  They should be in the ratio of 1.2 to 1 plus or minus one.  If they are less than that figure by more than two units, or more than that figure by more than two, then there is something wrong.

 

The most common cause is that the data rate is so low (poor antenna, poor location, badly set receiver gain) that the timer actually wraps more than once between successive messages.  Such systems are not really any use unless it reflects a low traffic period that might improve at some other time of the day.

The more serious problem arises where the receiver setup or firmware is giving the wrong clock rate on the time tag.  It was this that we were seeking to monitor with the new feature.


Below is an example of flatlining, which you do not want to see:

 

 

Bev notes: The green graph should increase monotonically from left to right, wrapping if it hits the top line.  The horizontal axis is the number of messages decoded and the vertical axis is the raw data time tag on each message.  If you have a very high received message rate, the green line will increase only slowly from left to right.  If you have a very low message rate, the green line will increase more steeply and will wrap around from top to bottom more often.

 

Finally, be sure to check that the location of your antenna is correctly displayed on the map.

 

More details on the time tags graph

 

Bev notes on the Yahoo group:

 

The graph shows the value of raw data time tag against the consecutive report number.

It should be a single valued monotonic graph - always with a positive slope - that wraps at intervals.  In the case of the SBS3, it may show multiple values but this artefact will disappear with the next release of PP.  Graphs that are completely flat, possibly multivalued, have no raw data time tag.  Systems provided by some other networks have this feature and cannot be used for multilateration.

The graph may be smooth, if there are plenty of reports that average out to a steady rate, or it may be lumpy (but still monotonic) if there are reports coming in more in bursts.  If it is lumpy, it is not a fault; it merely reflects the nature of the traffic being received - sometimes more quickly, sometimes more slowly.  If the pings are as the result of interrogations by a single nearby radar site, and if the traffic is not uniformly distributed around the radar head, then the pings will come in groups as the beam sweeps past the aircraft so the curve will climb sometimes more slowly and sometimes more swiftly.

The yellow horizontal line should not be solid.  It shows the odd/even seconds (changes from on to off, or off to on, each second) so you can judge how much time in seconds has elapsed for the total graphic display (count the yellow lines and the gaps between them).  Less is better - it means there are more reports per second because the graph shows a fixed number of reports.

The less steep the line, the better (but not flat, of course, see above).  It means that the raw data time tag is not progressing much between successive reports - i.e. that the reports are coming in very fast - a good thing.  It has nothing to do with the resolution of the time stamp per se.  The time stamps are all scaled to the same resolution.

In very rare cases, some receivers have delinquent time stamps and it is possible to recognise that from the graph.  The number of wraps of the graph, should be about 1.2 times the number of seconds determined by counting the yellow dashes and the gaps between them.  It is not very accurate because the numbers are small but those few receivers with wrong time tag clocks are easily identified.

Systems with very low message rates - e.g. where the antenna is on a biscuit tin under the table in the basement - have graphs that wrap so much (hardly a report every second or so) that they may look like snow and not like smooth lines at all.  Such systems are probably not much use to the network unless the low message rate really does reflect a paucity of aircraft and not just a poor antenna/receiver system.

 

Tell me more

 

(From Bev's message in the Plane Plotter Yahoo group: http://groups.yahoo.com/group/planeplotter/message/31210)

 

The two raw data tests (inbound and outbound) both rely on the server being able to send UDP/IP packets to Plane Plotter.

In the case of the inbound raw data test, it sends a UDP/IP packet to Plane Plotter, which then displays a pop-up confirm arrival of the packet.  If the test fails to generate a pop-up, then almost certainly the router port-forwarding has not been done correctly.

In the case of the outbound raw data test, it sends a special UDP/IP packet to Plane Plotter, which elicits an outbound UDP/IP packet back to the server, which the server then display.

Note that if the inbound test fails (server-to-PP message not arriving), then the outbound test will necessarily fail since the interrogation will not reach PP to elicit the outbound packet.

Remember that, unlike the test described above, the provision of raw data for routine Mlats is elicited during the course of a routine share cycle, not via UDP/IP.  This means that a Ground Station can be validated and working, for the purpose of sending out raw data for Mlats, even though the inbound port forwarding is mis-configured.

In other words, you can be a working GS and still fail the built-in outbound network test because the inbound path is broken.

In that situation, you would, of course, want to fix the problem so that you can conduct your own Mlats but is does not affect your validity as a GS.

I suppose I should have put the two tests into the menu pull down the other way round so that the inbound one was the first to be tried.

Summary: 

If you fail the inbound test, do not even try the outbound test because the former must work before the second one has a hope.

If you fail the outbound test with no response, do the inbound test and check the router port forwarding.  Only if you see "raw buffer content = 0" should you conclude that some configuration setting for raw data is incorrect.

 

(Further clarification:  https://groups.yahoo.com/neo/groups/planeplotter/conversations/messages/112531)

 

Except in very exceptional circumstances agreed in advance, a Ground Station must be accessible by UDP 9742 packets.

The exceptions relate to systems integrated into a local "slow SMU" net where a WAN IP address is not available to the outstations.  All "normal" systems must have properly configured port forwarding for UDP9742 packets in order to operate as a Ground Station

 

Comments (0)

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