I like this idea, but if implemented it would have to shade areas that produce less range as well as more.
…Tom
Yes, if it could show the difference whether positive or negative that would be good.
Another idea I had was to generate range rings based on signal strength rather than altitude - for example, draw a ring at the maximum range seen for signals of at least -3dB, and then every so many dB to a minimum level.
I don’t know if either are realistic to implement, but I thought they might be useful.
@idh - glad I could be of some help! 
Looks like jprochazka’s setup script has now included the changes from lignumaqua’s script.
Do you get all the extra “settings” menu on gmap.php now, just by copying that directory in?
Coud you share a screen grab of your gmap.php?
@jprochazka - did you “merge” these functions in your updated release yesterday? 
(I’ve not used the finalised image yet, for fear of breaking my own “hack” from yesterday… )
Yes, possible, but with a potential gotcha. This is all running in JavaScript in your browser, as such the code has no access to the filing system of the computer. (JavaScript security is pretty strict on this, you don’t want web pages to be able to access your files!). Instead we store temporary data in the local storage location in the browser. This means that any range data you accumulate is local to that browser and that browser alone. It can also be easily lost if you clear your data cache, for example, and won’t be available from any other browser, even if running on the same computer.
So, would that be acceptable? If not, then we might have to look at other options. For example, we can send and save data on a server, even on the Pi itself if we use something like PHP as used in the scripts. Alternatively the page can make data available for the user to save.
I’m traveling on business this week (sitting in DFW airport as I write this) but I’ll take a look at perhaps storing the data back on the Pi. That would be useful anyway.
Remember that my repository on Github includes a complete version of config.js with all additions. I suspect that’s what you pulled down. Nothing wrong with doing that but you will lose any customizations you had already configured and go back to all default settings. Fine for a completely new install! 
but you will lose any customizations you had already configured and go back to all default settings. Fine for a completely new install!
Yes it was a new install - nothing extra configured. But of course that leads me to wonder what I have missed out
Do you get all the extra “settings” menu on gmap.php now, just by copying that directory in?
Coud you share a screen grab of your gmap.php?
Like this?
I don’t get a lot of range, but it does seem to keep accurate track.
The first airplane’s track is shown with another five a/c following the STAR into KATL.
I don’t see it as a problem if it just uses local storage if that’s easy enough to implement - It doesn’t take too long to build up the picture and you have to manually reset it anyway. A more permanent solution would be good, but if that’s more complicated then I don’t think it’s a problem if it takes longer.
With the range plots being stored in browser cache, how does it generate the range plots for periods when the browser wasnt open?
Does this retrospecitvely draw them from the logs - or does it rely on the browser being open to draw those plots in realtime?
If the latter, I’d definately +1 for using local storage on the pi - or indeed building them from the logs the first / next time the browser is opened…
It depends on your OS and browser. If the browser periodically updates unseen tabs and allows them to keep running javascript then you will be fine. This seems to be the case with OS X and Safari. However, if it puts unseen tabs to sleep (as happens with an iPad for example) then the range will only accumulate when the page is open. Either way, using storage on the Pi wouldn’t help as the program creating that data is running on the browser.
Any non browser dependent solution would have to run in code on the Pi. Perhaps a Python script, and would be platform dependent. That’s outside the scope of what I’m doing here.
Morning @lignumaqua
I’m running Chrome, which AFAIR does snooze background tabs to save memory etc.
So, just to confirm, for the range plots to be “total since start” - rather than “total since browser window focussed” - we would need:
- client machine on constantly
- browser window open constantly
Not a complaint, more just defining requirements in this area.
Looking at those requirements, my first thought would be - “run the browser window on the host Pi”; it’s always on and the browser could be always open.
Without doing this through the host GUI (ie the Linux desktop on the host Pi), I’m thinking “command line browser, then remote into that” somehow.
Just a thought, I’ll see what I can find!
Out of interest, does Dump1090 store all it’s full logs somewhere?
With SD cards so cheap these days - even 32gb etc - storage isnt too much of a premium, and I’d imagine this could be archived off at “x% remaining etc” (Ideally to cloud storage - dropbox / google etc).
From there, it might be possible to update / poll from that file “since last update”, but do those JS limitations include reading from - as well as writing to - the FS?
Appreciate this isnt the direction you want to take your scripts - just thinking out loud!
The long-term storage problem is the main reason I haven’t done any sort of range thing in dump1090-mutability, getting it right is a bit tricky.
Probably the way to do it is have dump1090 maintain the data directly in memory and optionally write it out to a local DB periodically. Then serve the results as json like all the other data it provides. For a simple range plot there isn’t a huge amount of data to store.
Sounds ideal Obj!
Of course, one could just use VRS for this, but that requires a machine on permanently - when the host pi already is.
I’m sure many others would find such a solution on the Pi like this valuable…
Sorry, misusing this thread, but it feels like the right place …
planeObject.js defines these aircraft-classes:
PlaneObject.prototype.getMarkerIconType = function() {
var lookup = {
'A1' : 'light',
'A2' : 'medium',
'A3' : 'medium',
'A5' : 'heavy',
'A7' : 'rotorcraft'
};
if (this.category === null || !(this.category in lookup))
return 'generic'
else
return lookup[this.category];
}
But from time to time I also see class A4:
Is A4 missing from planeObject.js or is this a false code?
Klaus
A4 is “high vortex aircraft”
I ran the command in the screenshot in an attempt to get that readout. The command took but nothing happened. What did I do? Could I have messed something up. woops.
from faa.gov/aircraft/draft_docs … 0-165B.pdf
Table 1 Emitter Category (A Categories are 0-8)
Value Emitter Category Description
0 No Emitter Category Do not use this emitter category. If no emitter category fits your installation, seek guidance from the FAA as appropriate.
1 Light Airplane < 15,500 lbs Any airplane with a maximum takeoff weight less than 15,500 pounds. This includes very light aircraft (light sport aircraft) that do not meet the requirements of 14 CFR 103.1.
2 Small Airplane ≥ 15,500 to < 75,000 lbs Any airplane with a maximum takeoff weight greater than or equal to15,500 pounds but less than 75,000 pounds.
3 Large Airplane ≥ 75,000 to < 300,000 lbs Any airplane with a maximum takeoff weight greater than or equal to 75,000 pounds but less than 300,000 pounds that does
not qualify for the high vortex category.
4 Large Airplane with High Vortex Any airplane with a maximum takeoff weight greater than or equal to 75,000 pounds but less than 300,000 pounds that has been determined to generate a high wake vortex. Currently, the Boeing 757 is the only example.
5 Heavy Airplane ≥ 300,000 lbs Any airplane with a maximum takeoff weight equal to or above 300,000 pounds. 747, 777, 787, A380 etc
6 Highly Maneuverable > 5 G and > 400 TAS Any airplane, regardless of weight, which can maneuver in excess of 5 G’s and maintain true airspeed above 400 knots.
7 Rotorcraft Any rotorcraft regardless of weight.
8 Reserved This value is not used at this time
9 Glider / Sailplane Any glider or sailplane regardless of weight.
10 Lighter than Air Any lighter than air (airship or balloon) regardless of weight.
11 Parachute / Sky Diver
12 Ultralight Vehicle A vehicle that meets the requirements of 14 CFR 103.1. Light sport aircraft should not use the ultralight emitter category unless they meet 14 CFR 103.1.
13 Reserved
**14 **UAV Any unmanned aerial vehicle or system regardless of weight.
15 Space/trans-atmospheric vehicle
16 No ADS-B Emitter Category Information Do not use this emitter category. See Emit Cat 0 above
17 Surface vehicle— emergency vehicle
18 Surface vehicle—service vehicle
19 Point Obstacle (includes tethered balloons)
20 Cluster Obstacle
21 Line Obstacle
There are some B and C categories for ground vehicles.
from sunavionics.com/AV15%20v2.00 … Manual.pdf
The Emitter Category code definitions;
B0=NO INFO C0=NO INFO D0=NO INFO
B1=GLIDER C1=EMER SURFACE D1 to D7 RESERVED
B2=BLIMP C2=SURFACE VEHICLE
B3=SKYDIVE C3=POINT OBSTACLE
B4=ULTRALIGHT C4=CLUSTER OBSTACLE
B5=RESERVED C5=LINE OBSTACLE
B6=UAV C6,C7 RESERVED
B7=SPACE VEHICLE
Ah, thanks.
readjson.pl can’t work on you Pi, that is a Perl-script I wrote to pretty-print the content of /var/run/dump1090-mutability/aircraft.json and because you did a grep (=search) after the command there was no output. You did not mess anything up.
Great, you found the right documents! Thank you!
markers.js has only 3 different shapes (generic, beechcraft, rotorcraft), scaled to different sizes. Maybe I should give that code a little polish. I’ll check which of the types I can watch over time. It’s really time to get an own fork at GitHub up to be able to submit stuff to obj’s repo, but time is limited this week.
Microlight version:
Base model with gross weight of 450 kg (992 lb) and 75 litres (16 imp gal; 20 US gal) fuel capacity for the European microlight category
LSA version:
Model with gross weight of 549.7 kg (1,212 lb) and 98 litres (22 imp gal; 26 US gal) fuel capacity for the US light-sport aircraft category. Standard empty weight is 299.5 kg (660 lb), useful load 250.5 kg (552 lb), range 1,397 km (868 mi).