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

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!



Page history last edited by Danny Gooch 1 year, 12 months ago Saved with comment

Using Beamfinder and Beamfinder Plus

For Beamfinder, you will need Plane Plotter with a suitable receiver.  Currently the SBS-1e (with firmware upgrade), SBS-3, PlaneGadget Radar, AVR, Mode-S Beast, miniADSB, microADSB, and SSRx receivers allow use of the Beamfinder facility.

For Beamfinder Plus, you need a receiver also capable of capturing the mode A/C transponder pings.  Currently only The Mode-S  Beast and Kinetic SBS-3 allow this, although the RTL receiver dongle and the dump1090 software allow this, and the RTL1090 software can be used as well.


For Beamfinder Plus S all receivers except the AirNav Radar Box are suitable.


There is a video tutorial from Bev on setting up Beamfinder plus S here, and there is a tutorial in the Plane Plotter Help, see: Help, Help Topics, Contents, Tutorials, Beamfinding &c.  Please do look at these extra resources as well as the following information.


Changes to Beamfinder in v6.5.7.7


Significant changes to Beamfinder were introduced in v6.5.7.7 of Planeplotter (released April 2022).


The following is the release note from Bev:


Most of the changes refer to the Beamfinder method and specifically to the tools provided to create the calibration file required for the Beamfinder function.  Beamfinder is a method of locating aircraft that are not transmitting position.  It is not as accurate as Multilateration (Mlat) but it does not require other Ground Stations in your area.  If you are far away from other GS, Beamfinder is the next best thing as it relies only on your signal reception and nobody else.


I should mention that Beamfinder requires the maximum performance from the receiver, in order to pick up pings that are close together.  I have found that the SBS-3, Beast and PlaneFinder receivers all give excellent results with the Beamfinder method.  In my experience, which you may not share, dongle-based receivers do not perform well in this application.


Existing users of the Beamfinder method need to be alerted to the fact that, unlike earlier versions, when creating the "radar.txt" precursor file, this release does not save the first draft of the calculated radar site position.  It only saves the data to file when you have decided exactly where the radar head is located and have performed Ctrl-click on the chosen spot.  It you don't do that, you will be disappointed that nothing has been saved to file.


New help file and a new video tutorial


The Help file entry for Beamfinder has been substantially rewritten to refect the new methodology but, as a picture is worth a thousand words, I have also made a (rather long) video (www.coaa.co.uk/Beamfinder.mp4) showing the complete process all the way from creating the reference file ("radar.txt") from scratch, to putting it to use within PlanePlotter



Using Beamfinder


Having run a log of the radar identifier pings, you can then use the Tools, Radar site analysis, Analyse radar site ping log to get an estimate of the location of a radar site.  The analysis does not give you the answer on a plate - but it does provide one source of information about the possible whereabouts of the sites in question.  You need to draw on other information as well.

The analysis result is more likely to be a good approximation to the actual position if your receiver coverage and that of the site in question, overlap to a large extent.  If your coverage only covers a small arc of the radar site's beam, then the uncertainties in the analysis become very large and the results will be less useful.
In any case, depending on the distribution of ADS-B aircraft in that overlap area during your log recording, the results may be more or less representative of the actual position.  You should not be surprised that the results vary from run to run - especially if the calibrating aircraft are relatively few and especially if they are not well distributed over the whole of the mutual coverage area.


There is an animation showing the set-up steps required for Beamfinder here - kindly provided by John Locker.  As this is a large 3.5 MB animation, you will need to select the Download tab to view it on your PC after clicking the link.  Thanks, John.


Why may numbers of beams differ widely?

Q: Is there a reason why some radar sites produce a good number of beams whereas others only throw very rare beams, even when a track is closer to the 'low' site than the others that shoot more frequent beams?


A: It is difficult to answer that in a completely generic way.  There are so many ways that a radar site can be configured and used.  

For Beamfinder, Plane Plotter can only look at the IID that is added to some DF11 replies in response to a specific interrogation message format from the site.  How that is used, seems to be different from site to site.  David Taylor has produced some impressive diagrams showing that in his area, the IID is included only for traffic beyond a very specific radius from the site.  In that situation, it is very easy to infer the site location from the centre or the arc.  In Portugal, the IIDs displayed from the Mode-S radars in Morocco seem to be confined to aircraft outside of the Casablanca FIR.  In complete contrast, here in South Australia, the IIDs are confined to aircraft that are inside, not outside, a specific radius from the Mode-S radar at Adelaide.  So you see, it can be very different from place to place.  Part of the fun is learning the characteristics of the different radars and learning how to interpret them and how to get the most information from the site.

For Beamfinder Plus, Plane Plotter can only look at the time interval between successive Mode-A interrogations for each aircraft with known squawk.  For those sites with a fixed pulse interval, this is shooting fish in a barrel.  For sites where both Mode-A and Mode-S interrogations are made, the number of candidate pulses will depend on the interrogation pattern and how often Mode-A is interrogated compared with Mode-S and Mode-C.  For those sites using a jitter pattern, it is slightly more problematic.  There are multiple candidate pulse intervals and this dilutes both the chance of calibrating the real-time beam azimuth and the production of beams.

Are you using the latest version of PP?  Precisely because of the dilution of data in the case of jitter, it adds a feature whereby you can add a group identifier to the entries in radar.txt so that PP will treat all of the group members as one, when calibrating the azimuth.  This substantially increases the number and accuracy of beams where a site is using pulse interval jitter.  Of course, you need to be very sure that the various pulse intervals do indeed refer to the same site.

The short answer to your question is that there are many ways a radar site can operate and some are more amenable to BF or BF+ than others.

(From Bev's message: http://groups.yahoo.com/group/planeplotter/message/64856)



One Man's experiences with Beamfinder


Kindly contributed by Don,  WD9DMP - see this post in the Plane Plotter Yahoo group.


After reading the various tutorials on the Beamfinder variants, I decided to have a go at making my own radar.txt file for use in my location.  A quick look at the "Radar identifier window" showed  I could see quite a few unique radar IDs, most grouped in the ii-1 to ii-10 range.    Producing the best radar.txt file turned out to be a hybrid operation, using several tools to get the best results. I ended up following this procedure:

  • Run the "Tools > Radar site analysis > Log radar identifier pings" utility. I ran this for just over 12 hours, covering the morning and afternoon busy-hours for O'Hare and Midway airports near Chicago.  Running this for a long period was needed to get a good position estimate for the radar locations.  The logging process creates an individual log file for each of the radar identifiers found in the Mode-S messages.  I wound up with 68 log files for 68 unique radar site identifiers.
  • For any file > 1 Megabyte in size, I ran the "Tools > Radar site analysis > Analyse radar site ping log" utility.  This produces an output file called "radarsitemeasurements.log" which contains the derived location estimate and rotation rate for the site.  Subsequent runs of the utility append additional sites to the file.  I found the location estimates to be way off, but the necessary information produced by the utility is the rotation rate.  The lat-lon gets replaced later.
  • I next ran the "Tools > Radar site analysis > Display ping log file" on the same log files that I analysed. I first turned off Plane Plotter processing to speed up the display.  This produces a display on the map with a position estimate indicated by cross-hairs on the screen.  There was a defined coverage "hole" around the location estimate cross-hairs, verifying the position estimate.  I found this estimate to be very reliable.  In my case, I found the estimate corresponded to the location of a major airport within a few miles.  I had loaded a .out vector display file of all major airports in the region, as well as a navaids .gpx overlay which made airport identification easy.  I looked up the lat-lon coordinates of each corresponding airport on-line, converted the surveyed location to decimal degrees with an Internet tool, and substituted those positions in the "radarsitemeasurements.log", keeping the rotation data from the "analyse" function.  I also added comments identifying the airport location.  

    Example display here: http://projectmf.homelinux.com/station_pics/ii01_12_hour.jpg


  • Finally, I copied the edited "radarsitemeasurements.log" file to my Plane Plotter installation, deleted the old radar.txt file, and renamed "radarsitemeasurements.log" to radar.txt.
  • I shut down and restarted Plane Plotter to reload the new radar.txt file.  I enabled "Options > Calculate Beamfinder fix",  "View > Chart display options > Beamfinder > Beamfinder beams" and "View > Chart display options > Beamfinder > Beamfinder labels".
  • I found that Plane Plotter will automatically attempt to get a fix on various position-less aircraft after being idle for a time.  I can also force a secondary fix on a selected aircraft on the chart by double-clicking the plane icon.  This verifies that the Beamfinder is working correctly and that the radar.txt file has valid positions and rotation rates.  I could also select a position-less aircraft in my aircraft list and Beamfinder will attempt to locate the aircraft.  It is quite cool to see the beams converge on the unknown location.  After a few seconds, a yellow circle appears around the position estimate and eventually a triangle appears on the display with the plane's data. Beamfinder continues to track the plane's location as long as it is selected.

Some of the beam lines are way off, but most converge on the location quickly.  The accuracy of the beams depends upon the number and distribution of other position-reporting aircraft that are receiving the radar site identifiers.  Accuracy has been outstanding!  This is using an R820T dongle with RTL1090.  The antenna is an 8-element collinear with an LNA and band pass filter connected.


Beamfinder FAQ


I get very inconsistent results all the time

It is quite possible that some pulse rates or IIDs cannot be solved at all, because they come from more than one site.  If you get persistently meaningless results, then give up on that pulse rate or IID.  There is no point in battling on if there is no solution.


I've spent a lot of time analysing data, but I get different results each time

It occurs to me that in all the time that you might spend in trying again and again to use the analysis tool to locate the sites, you could have gone through your list of the most active pulse rates or IIDs one at a time, made a radar.txt file with only that one value in it and tried inserting the coordinates of each of the known radar sites within 250 nm of your location, one at a time, until you find the location that makes the beams match the target.  With half a dozen rates or IIDs and half a dozen radar sites, it would only take 36 trials, each one only taking a minute or two, to solve them.

What does the Display Ping Log file show for identifiers?

Use the Display Ping Log file after capturing the identifier pings to see whether a particular II or SI file shows a clear "hole" centred on a radar site.  There's an example here showing the "hole" around Inverness, Scotland radar.


Beamfinder Plus works, but I can't locate sites for Beamfinder!

That is because they probably do not exist!  The II/SI codes are not 100% certain.  If you get very little data for a code, especially if it is II-1, 2, 4, 8, SI-16 or SI-48, then simply ignore it; it is not real.


Details: The site identification is overlaid on the error checking part of a particular Mode-S message.   As such (read this carefully) there is no error checking possible on this data.   This means that any noise spike or momentary fade can change a "0" to a "1" or a "1" to a "0" and there is no absolute way to tell that it has happened.  Now, to avoid an avalanche of erroneous identifications, PP keeps a track of the identifications  and only processes those that occur with a significant frequency.  Even so, there can be no certainty that any particular identification is real.  In particular, those identifications that correspond to a single bit error are most likely to occur and to occur often enough to be taken seriously (albeit falsely).
Your list of those codes that you never quite get enough data to analyse, beautifully exemplifies that situation.  One bit errors in that field give rise to II-1, II-2, II-4, II-8, SI-16, SI-48.  (In case any sharp-eyed reader wonders, the SI values are encoded as 16 plus the SI code so SI-16 = 32 and SI-48 = 64, both powers of two).  Your list of elusive codes contains four of the six particularly suspect codes.
Adapted from: http://groups.yahoo.com/group/planeplotter/message/65100


What does a Rose plot look like?

Here's an example rose plot from Edinburgh. 


This was taken from a few minutes of data gathering one Sunday morning in Edinburgh, with one file being used in the Tools, Radar site analysis, Display ping log file menu option.  You can see that lines have been drawn between near-identically timed radar echoes, which are likely therefore to be from the same group of pulses emitted by the radar, and hence the lines point to the source radar.  By moving the cursor you can make an approximate match between the rose and the lines, and hence estimate the radar head location.  Running for a longer period may also produce a characteristic "hole" plot around the radar as mentioned above.  In this example, the "hole" is centred on Inverness.



Beamfinder Plus FAQ


I see quite a list of PRFs when the "z" key is pressed, but some are quite similar?

The acceptance of a matching PRF (pulse repetition frequency) has a tolerance of 2 microseconds.  Similar values may be from different radars or they be members of the family of intervals created by the jitter pattern that some radars use to avoid synchronous confusion with other sites.
For example, here in Adelaide, one of the transmitters has a nominal PRF of 3323 us and the other transmitter has a nominal PRF of 3325 µs.  The transmitters are used on alternate days, I think.  Both of them have a 5-fold jitter pattern of +10, +20, -20, -10, 0 µs.  This leads to the following observed pulse intervals for the first transmission:
  6656, 6676, 6646, 6616, 6636 µs
and these for the second transmission:
  6660, 6680, 6650, 6620, 6640 µs


Do radars from the same manufacturer have the same PRF?

The manufacturer does not define the PRF.  The systems analysts who design the overall system will specify PRFs such that synchronous interference between overlapping sites is avoided or controlled.


Why are the entries in the "z" list apparently in a random order?

They are not random, they are sorted in descending order of frequency of occurrence, with the most common interval at the top of the list.  Sorted in this way, analysing them in the order given gives you the best results first and when the analysis starts to fail, you can usually ignore the rest.


Does the intensity of the line in the "u" window relate to the strength of the pings?

This window is displayed when you press "u", or use the View, Mode-A/C pulse rates window.  No, it has nothing to do with the strength of the pings.  The intensity of the green dots is a measure of how many pings with that interval occurred during the sampling time:

  • No pings  - no dot
  • One ping - faint dot
  • Many pings - more intense dot.


Why do I see multiple PRFs from the same site?

Radars can do all sorts of interesting things. They can introduce a systematic jitter in the interval between pulses and they can use various strategies for separately interrogating Mode-A and Mode-C responses from aircraft.

Imagine a radar that is alternately polling Mode-A and Mode-C. Suppose that it also has an interval jitter that contains a number of steps that is not a multiple of two. You can easily imagine that there are several apparent intervals, measured from A-ping to A-ping and from C-ping to C-ping, manifested by the same site.

In the case where the polls go C,C,A,C,C,A then it would not be surprising if the interval between pings from the same site was seen to be both "t" (C-ping to adjacent C-ping) and also "2t" (C-ping to non-adjacent C-ping) and also "3t" (A-ping to A ping).

The only thing that matters is what intervals PP sees coming out of the receiver and whether or not they turn out to be unique to a site and therefore capable of uniquely identifying that site.

(from a message from Bev in this thread on the Plane Plotter Yahoo group)


Should I include entries in Radar.txt for the multiple PRFs I see?

Multiple PRFs are only to be expected.  Given the number of message collisions, it is going to be fairly likely that one ping is not received, either at the aircraft, so the aircraft responds after 2t or at the ground even if the aircraft responds after t.  The observed pulse interval will then be twice the nominal value.  It is worth including these so that a "beam" results even when one ping is lost.


What does the Display Ping Log file show for pulse rates?

Use the Display Ping Log file after capturing the pulse rate pings to see whether there are lines pointing towards a radar site.  There's an example here showing the lines pointing at Dublin.  Not very clear!  You can now get similar plots from analysing II/SI files collected with the Tools, Radar site analysis, Log radar identifier pings function.


How are the different message types used in the Beamfinder functions?

Please see this page.

Comments (0)

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