Thanks. The post linked to in that thread appears to be dead unfortunately. I’ll do some testing to see what difference it makes.
Here’s some plots with different refraction values. It does make a considerable difference.
Heatmap with 0.0:
Heatmap with 0.14:
heatmap with 0.25:
The altitude plot has data for several range rings in it. The green line represents the heywhatsthat range:
altitude with 0.0:
altitude with 0.14:
altitude with 0.25:
To me it looks like 0.14 fits the data best, at least for my location. 0.25 puts the range beyond the theoretical horizon (the white line) which could well be correct. The difference for high altitudes looks to be about 30 miles or so. Be interesting to see if anyone else gets similar results. Remember to delete the old upintheair.json before running if you change the value.
Yes, when the forum format was changed to current “Discourse”, most links became broken. Anyway, I could locate it, seems my memory is not yet affected by ageing 
Please read the last paragraph.
1 Like
I am trying to get the polar.sh to work on the Odroid N2, arm64 running on Stretch. Installed curl; made directory polar. Copied the file from github and made the sh file executable. But then the fun stops. I tried unsuccessfully to install gnuplot packages with error message as below. Similar for the nox file.
root@odroid-stretch64:~/polar# curl -sO http://ftp.debian.org/debian/pool/main/g/gnuplot/gnuplot-data_5.2.6+dfsg1-3_all.deb
root@odroid-stretch64:~/polar# ls -ls
total 664
4 -rw-r--r-- 1 root root 323 Sep 3 20:04 gnuplot-data_5.2.6+dfsg1-3_all.deb
376 -rw-r--r-- 1 root root 381891 Sep 3 19:58 polarheatmap-2019-09-03
0 -rw-r--r-- 1 root root 0 Sep 3 19:58 polarheatmap-2019-09-03.png
12 -rwxr-xr-x 1 root root 10743 Sep 3 19:52 polar.sh
272 -rw-r--r-- 1 root root 278497 Sep 3 19:58 upintheair.json
root@odroid-stretch64:~/polar# sudo dpkg -i ./gnuplot-data_5.2.6+dfsg1-3_all.deb
dpkg-deb: error: './gnuplot-data_5.2.6+dfsg1-3_all.deb' is not a debian format archive
dpkg: error processing archive ./gnuplot-data_5.2.6+dfsg1-3_all.deb (--install):
subprocess dpkg-deb --control returned error exit status 2
Errors were encountered while processing:
./gnuplot-data_5.2.6+dfsg1-3_all.deb
root@odroid-stretch64:~/polar#
When I ran it without the packages installed, I get the following (truncated):
Processing heywhatsthat.com data:
Retrieving terrain profiles from heywhatsthat.com:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 271k 0 271k 0 0 54646 0 --:--:-- 0:00:05 --:--:-- 72657
set theta clockwise top
^
"/dev/stdin", line 22: unrecognized option - see 'help set'.
cp: cannot stat 'polarheatmap_low-2019-09-03.png': No such file or directory
cp: cannot stat 'polarheatmap_high-2019-09-03.png': No such file or directory
cp: cannot stat 'elevation-2019-09-03.png': No such file or directory
cp: cannot stat 'altgraph-2019-09-03.png': No such file or directory
cp: cannot stat 'closealt-2019-09-03.png': No such file or directory
cp: cannot stat 'closerange-2019-09-03.png': No such file or directory
Graphs available at :
http://192.168.86.250/dump1090-fa/data/plots.html
Any suggestions on how to proceed? I think I am doing something trivially wrong
I looked through the thread but could not find the answer. Apologies if I missed it.
Yes, I agree.
Using curl for downloading is a bad idea @caius, wget would have at least shown a 404 error.
These are the current URLs you want:
wget -O gnuplot-data.deb http://ftp.debian.org/debian/pool/main/g/gnuplot/gnuplot-data_5.2.7+dfsg1-3_all.deb
wget -O gnuplot-nox.deb http://ftp.debian.org/debian/pool/main/g/gnuplot/gnuplot-nox_5.2.7+dfsg1-3_armhf.deb
sudo dpkg -i gnuplot-nox.deb gnuplot-data.deb
2 Likes
I’ve updated the readme.
1 Like
I’ve noticed there is a problem with the display of the terrain profile in the Azimuth/Elevation plot.
At first I thought it was just inverted but it seems to be that the underlying json data only contains negative values.
It appears, if the elevation of a point is +1 it is displayed as -1 and if the elevation is -1 it is also displayed as -1.
Attached are a clip of my HeyWhatsThat profile and my Az/El plot to show the problem.
I think the problem lies with HeyWhatsThat but I’m not 100% sure.
Interesting. I don’t think the problem is with the data from heywhatsthat, at least not directly.
The profile that is shown on their page isn’t available through their API. You can’t get a direct representation of the horizon through it, so I’ve used available range data to generate what should be a rough approximation of the horizon.
The way the script works, is that it requests a range ring for an altitude very close to that of the receiver. This data is returned as a series of latitude/longitude points, one for each degree of bearing surrounding the location set in the heywhatsthat ID. The script then calculates the bearing and elevation between the receiver location set in the script and location and elevation in the upintheair.json file (the elevation is known because that’s what the script requested). These results are what’s plotted as the line on the elevation plot.
The thinking behind this (and this may be a flawed way of doing it), is that the further away you get from any particular point at the same altitude, the lower the angle with the horizon that point will be. The result is that in order to obstruct the horizon, something has to be both close enough and tall enough to give a positive angle to the horizon. eg. It doesn’t matter if a hill is 200m tall if it’s 100 miles away, because it’s still beyond the horizon and doesn’t obstruct anything.
Heywhatsthat returns the furthest location an object at the chosen altitude can be before it disappears below the land. By choosing an altitude similar to the receiver, those locations are going to be fairly close to the receiver, making high local landscape features the dominating factor. A close by hill should give a positive angle to the horizon, as you look up to the top of it.
I think the problem you are getting is possibly because something isn’t set quite correctly in either the script or on heywhatsthat.
Check the following:
The latitude and longitude set in the script and the heywhatsthat ID match exactly.
The altitude of the receiver set in the script and on heywhatsthat ID match exactly - in the script this should be the receiver height in meters above sea level.
Once you’ve checked those, delete the upintheair.json file and run the script again and see what output you get.
Your logic sounds reasonable to me.
I’ve checked all of those and deleted the json but I still get the same results.
Unfortunately I don’t seem to be able to get my head around how you are exactly calculating things at the moment. I need to spend a bit more time looking at your script in more detail.
I stopped the script deleting the temp directories and looked at the range ring it generated (my height + 10m) and it contains negative values for the elevation figures. I presume the heights are in feet in the file and it is:
Lat,Long,Height,Bearing,Elevation
See example extract below:
50.856412,-1.030337,289.083964,170.000003,-3.200922,
50.856404,-1.030408,289.083964,171.000003,-3.200924,
50.856398,-1.030479,289.083964,172.000003,-3.200925,
50.856392,-1.030550,289.083964,173.000003,-3.200926,
50.856386,-1.030622,289.083964,174.000003,-3.200927,
50.856382,-1.030693,289.083964,175.000003,-3.200928,
50.856379,-1.030765,289.083964,176.000003,-3.200929,
50.856103,-1.030814,319.417858,177.000003,-2.897258,
50.856101,-1.030893,319.417858,178.000003,-2.897258,
50.856100,-1.030973,319.417858,179.000003,-2.897259,
50.856099,-1.031052,319.417858,180.000003,-2.897259,
50.856100,-1.031131,319.417858,180.999997,-2.897259,
50.856101,-1.031211,319.417858,181.999997,-2.897258,
50.855920,-1.031305,339.876901,182.999997,-2.723066,
I am at 67m ASL (219ft according to HWT)
The range ring is generated for 77m.
@caius It would seem to me that it’s more robust to use 1000 ft above or maybe 5000 ft above and calculate using that.
Also to reduce user errors, maybe just get the lat/long and altitude from the upintheair.json, it’s included in there.
The data is lat, lon, range, bearing and elevation angle. Range, bearing and elevation angle are calculated. Heights are in metres.
There’s something weird going on because if I manually calculate the elevation using the height data you gave, I get a positive result for elevation.
Possibly - I need to do some testing on how it looks.
Could do, but I also want the script to be able to work without the heywhatsthat thing eventually because it only covers up to 60 degrees latitude and someone already had trouble because of that.
Just overwrite the variables if the heywhatsthat is available
Otherwise the user input stays.
@LawrenceHill I’ve found the problem. There was a bug in how the altitude value for the upintheair data was being handled which meant that it wasn’t being used correctly (at all in fact).
I’m just running some tests and I’ll upload a corrected version.
1 Like
OK I’ve updated the script - give it a try and see if it fixes the immediate problem.
I’ll do some more experimenting to see if a different requested altitude looks any better.
1 Like
That change shouldn’t have affected the horizon line, but I changed it because previously it was using the small angle approximation for tangents, which works ok when aircraft are close to the horizon but for aircraft closer in and higher up it produces quite significant errors:
Difference for low flying aircraft doesn’t become apparent until it’s very close - at ~3000 feet:
but for high altitude it’s much more apparent - at ~40000 feet:
It’s not a massive change but it was bugging me.
There is still a small angle approximation in there for the dip below the horizon with range, but for the maximum range in use here that shouldn’t be an issue.
1 Like
I’ve done some testing with different range ring altitudes - altitudes are +receiver height, in this case 41m.
Here is the actual profile:
+1m:
+10m
+200m
+1500m
Having identified the bug in the script that was causing the issues, it seems that there isn’t actually much difference in the results (at least for my location), except that the higher the altitude chosen, the lower the line is. It’s not a large difference though.
My thinking is that the lowest altitude possible (receiver height +1m) ring would ensure that any close land features are included that might possibly be missed by selecting a higher altitude.
1 Like
Could I propose a change where the script sets the width of the graphics in the plots.html file to be 100% instead of a fixed pixel width? helps scaling with small and larger screen sizes
For that you can edit the script and change the 1800 pixel setting.
For me i have replaced them with 1600 pixel to feet the webpage ;+)