Signal Strength Heatmap

Once I installed curl, all seems good now thanks.

Hi @caius

is it possible to get the image without they HWT circle? In the script it’s mentioned “doesn’t work without it”

I was running it this morning for a few hours and my wife : “wow, please print it for our wall, but without that circle”

I could do Photoshop and get it black, but maybe there is a smarter way of doing it :slight_smile:

As a quick fix, you could just remove the lines that plot the range circle. For example, lines 246-248 plot the complete heatmap:

plot dir.'/heatmap' u ($6):($5/1852):($3) with dots lc palette, \
        hwt.'/12121' u  ($4):($3/1852) with lines lc rgb "white" notitle, \
        hwt.'/12121' u ($4):($3/1852) every 359::0::359 with lines lc rgb "white" notitle

If you remove the last two starting hwt and the , \ from the end of the first line it will plot the heatmap without the range circle.

Alternatively you could grab an older version of the script before the range rings were added, though there may have been some bug fixes since then.
https://raw.githubusercontent.com/caiusseverus/adsbcompare/f2143c9e110a87490415692948f4d15ef82d38df/polar.sh

OK, thanks, will give it a try :+1:

I let it running today for four hours (4pm to 8pm local time) with a frequency of 5 seconds.

Good results if living close to busy routes and one of the largest airports (Frankfurt)
Some blind spots where either the antenna needs to be adjusted and geographic limitations cannot be removed :slight_smile:

I also need to play a bit with the value regarding max range

2 Likes

@caius
In regards to the range outline: The process described here Bake a Pi uses a diffraction of 0.25, that’s where some differences come from i guess.

I’m not sure what is strictly “correct”.

I did have a look at the diffraction value before, and from what I can gather from the heywhatsthat technical FAQ it refers to optical diffraction not RF. I’m not sure how much difference it makes to the accuracy of the range, or whether it takes into account ground shape.

I suspect that the difference is not too large, and that the range should probably be taken with a pinch of salt anyway, as practical considerations will have some impact.

@caius
@wiedehopf

Please see this post:

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 :slight_smile:

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.