I get most of this, and like (and understand) @mgunthers comment earlier…
I have a update_lignumaqua.sh file with the following in my home directory:
Code:
rm -rf dump1090/
git clone -n github.com/lignumaqua/dump1090 --depth 1
cd ./dump1090
git checkout HEAD:public_html formatter.js gmap.html planeObject.js script.js style.css maplabel.js
rm -rf ./.git
sudo cp ./. /usr/share/dump1090-mutability/html/
It copies and updates all required files. But you still need to manually add some lines to config.js.
That all makes sence…
My question for the moment is that these update commands - whether manually or using the .sh as above - all put / replace the files into a dump1090 folder under /home/pi .
I’m pretty sure mine didnt have that folder till I manually ran the git commands - nothing in the Image seems to reference that location / files, which leads me to believe that this isnt intended to work on a clean install of JP’s ADSB Reciever image?
If I could just find where these files where needing to go (NB I have multiple /dump1090/ structures as above) the rest looks pretty straight forward…
No, I have not yet used those scripts (although I’m sure I will at some point - they look very cool!) and I have no idea what folder structure they use for the html. This thread predates those scripts and assumes a standard install of dump1090-mutability using the default folders. Either way, the map files are the same. Just overwrite whichever are your live versions in the appropriate folder.
The default folder is /usr/share/dump1090-mutability/html/ (not under the pi home structure) but perhaps the scripts change this to something else? Although I don’t see why they would.
Actually, let me try MGunthers script - I must admit the one I used was from earlier in the thread and didnt have that line.
(Copied etc the files, but didnt have that last function).
Force refreshing (Chrome) attempts to reload, but then gets the “infinite spinner / bouncing loading bar” that’s been mentioned before, which I believe indicates it’s just needing the config.js editing…
Let me see if I can work that bit out, I now believe I’m actually looking at new lines in config.js on your repo?
which must have been where JP’s image stored it, as it wasnt one of the files copies / replaced by mgunthers script.
Manually hacked the new lines onto the end of the file:
// Grid size for heatmap. Range in miles from Site. Default 200.
HeatMapRange = 200;
// Set Altitudes and Colors for Range Rings
// RangeAltitude is an array of altitudes in feet
// Use 99999 for range at any altitude
// RangeColor is a corresponding array containing the color values of the rings
RangeAltitude = new Array(99999,30000,10000);
RangeColor = new Array('#008000','#000080','#800000');
// Allow use of MLAT data for the range poly
UseMlatDataForRange = true;
Yep, looking good. And /usr/share/dump1090-mutability/html/ is the location for dump1090-mutability html files, wether installed manually or with JP’s script.
Yes, looks good. You are missing a few lines at the end of config.js. I also strongly recommend leaving UseMlatDataForRange set to false. As you are in the UK you have plenty of ADS-B messages. These are the total additions at this moment.
// Grid size for heatmap. Range in miles from Site. Default 200.
HeatMapRange = 200;
// Set Altitudes and Colors for Range Rings
// RangeAltitude is an array of altitudes in feet
// Use 99999 for range at any altitude
// RangeColor is a corresponding array containing the color values of the rings
RangeAltitude = new Array(99999,30000,10000);
RangeColor = new Array('#008000','#000080','#800000');
// Allow use of MLAT data for the range poly
UseMlatDataForRange = false;
// Information that should appear in the label above each aircraft marker.
// Enter only one of the following options.
// Valid options are: icao, flight, squawk, category, altitude, speed, track, position, bearing, rssi
// Leave blank to disable the label.
LabelText = 'altitude';
Was working on this literally all day yesterday (according to my moto 360 watch - and much to mf GF’s negative comments - seems I moved about 300 steps away from my office desk yesterday lol).
0830 here now…
@lignumaqua - Thanks! I’ll def add those lines to config.js later, and chnage that setting.
@mgunther - thanks mate! Just a relative noob hacking around, this work last night was on the border between “breaking it completely” and “fixing it” lol. I have worked with PC’s for 20yrs plus, know a bit of programming, and work in online marketing - but Linux is certainly not an area I have much experience in. Still, learning! (Only fun when it works tho…
ONe thing I have noticed this morning, when checking on my CHromebook and Android phone (both running CHrome browser) is that this mapping feature seems very reliant on browser cache-refresh state (which I know has been covered earlier here)…
WHen I logged on this morning, both were showing no aircraft at all - I toggled a few things on and off in the settings, then the aircraft appeared and all seems to be ok now.
I apreciate i’ve rather hacked this together and the two scripts (image/mapping features) arent currently explcitly intended to work together, but just thought I’d mention that.
This may already be taken care of but now and then the RAAF here (mainly C130’s I think ) display an altitude of -1000 which messes up the 10,000 ft range display badly.
I thought that ignoring MLAT for range would have fixed this but today there is a suspicious long range 10,000ft track again, it could be just ducting but the track looked a bit long for that.
Maybe filtering out all altitudes below 0ft would help, if its not already implemented in the current version.
Have made those additions and changed mlat back to false in that line…
What are the benefits of doing this?
I believe that setting this to false ignores MLAT birds in the range map plotting (I can see birds at ranges that should be extending range, but dont. Looking at their details, they’re being tracked by MLAT).
Of course, with MLAT being triangulation between 3 or more unique sites (?), no one site has a full lock, so it could be argued that this isnt actually an effective range of any one reciever - and that to plot that as a max range for that reciever would be incorrect.
It’s just that MLAT positions are more error prone and it’s therefore not a good idea to use potentially erroneous (and far-out) MLAT positions for your effective range plot. They could mess up the plot, so better not use them for that purpose.
Thanks @Mgunther - makes sence, and my own take on the rationale also makes those plots more what I’d want them for - max range of the current local station.
Was a little confused as JP’s sripts use 2 HWT rings at 10,000 and 40,000 feet…
The config.js here has three colors, at 99999, 10,000 and 30,000 feet.
That, and Im color blind so I couldnt actually see the difference between the rings!
Think I’ll Wget more HWT data at 99999, 10000 and 30000 to match…
// Set Altitudes and Colors for Range Rings
// RangeAltitude is an array of altitudes in feet
// Use 99999 for range at any altitude
// RangeColor is a corresponding array containing the color values of the rings
RangeAltitude = new Array(99999,30000,10000);
RangeColor = new Array('#008000','#000080','#800000');
Thanks to cy80org’s mention of this thread on the “ADS-B Feeder Project Setup Scripts” thread, I decided I wanted to try this out.
First attempt messed up a recent install, but that was ok since it needed reinstalling. Having read warnings about overwriting the existing config.js file, I did a comparison to see what to add. Looks like jprochazka’s setup script has now included the changes from lignumaqua’s script. So simply copied everything from the public_html folder at github.com/lignumaqua/dump1090 and IT WORKS. But YMMV.
So a thank you to both jprochazka and lignumaqua (and all the other contributors).
@lignumaqua I don’t know how easy it would be to implement, or if it’s possible but it would be quite nice to be able to use the range plot as a reference if you want to compare two gain settings or two antennae. For example, build up a range plot and then click a button to store it as a reference and clear the existing plot. The new plot instead of shading between the receiver location and the maximum range, would shade between the reference plot and the new maximum range. This would make it very easy to see differences.
You are missing a few lines at the end of config.js. I also strongly recommend leaving UseMlatDataForRange set to false. As you are in the UK you have plenty of ADS-B messages. These are the total additions at this moment.