The setup.sh script from the How to feed, Scripted Setup – For Power Users comfortable with SSH who don’t want to re-image is imho ambiguous. The script asks for latitude, longitude, that is clear. But then asks for "atitude" with a mask title "longitude". I suppose it asks for altitude. But in which unit? in meters or feet? Could someone correct it? Thank you.
Altitude in meters above sea level. This is original script from Joe Prochazka. see: https://github.com/jprochazka/adsb-exchange You can ask Joe to fix it.
Yes I'm sure. Look here: https://www.adsbexchange.com/mlat-beta/ I googled a bit and this confirmed on some other websites. Probably you can enter altitude in feets using xxxft.
Ok is is very probably meters, for me it's fine. I suppose many (specially in us) may have made here a mistake. We will have to re-run /home/pi/adsb-echange/setup.sh.
Why can't you switch to metric? Because it's French? Just a joke but recalculating everything from/to is really complicated.
I have got no problem with metric. I just pointed out, that those who assumed erroneously that the altitude were in feet during the setup, should re-run /home/pi/adsb-echange/setup.sh and enter the correct data. That is not "recalculating everything" just entering the correct data once. It is important for correct MLAT calculations.
I understand your point. But please don't be so serious. How accurate MLAT can be? +/- something. If you read some forums altitude is not very important. Run some equations with altitude in meters and same equations with altitude in feet. What will be a difference? IMO difference in system time on feeders can have bigger influence. (alt error is fixed value, time error is variable). But you are right, try to make everything clear. BR Marcin
System time is the big issue. Basically MLAT measures signal strength because we know the location of the receivers, the speed at which RF (speed of light) travels, and can compare the time recieved that each reciever 'hears' the 1090 mhz squawk. Then we look at 4+ of the receivers hearing the squawk and can generalize a location based on the signal strength and location of the receivers. https://en.wikipedia.org/wiki/Radio_wave Example if Rec 1 hears it a 300 mile, rec 2 hears it a 50 miles, 4 hears it at 150 miles. rec 3 hears it a 200 miles .... (I did the signal db calulation to make it miles - let's just assume it's easier that way) We basically draw a circle around each reciever and where they 'overlap' the most .. that's where we MLAT (estimate) the plane to be. Make sense? So little bits of alttiude .. meters vs feet .. not a big deal. I actually had no idea what it was either. I've edited the install to tell the user meters. Altitude of receiver not so important.. The speed of light in a vacuum is 186,282 miles per second (299,792 kilometers per second), and in theory nothing can travel faster than light. In miles per hour, light speed is, well, a lot: about 670,616,629 mph. If you could travel at the speed of light, you could go around the Earth 7.5 times in one second. To calculate antenna length: === wavelength = speed of light / frequency wavelength = 299,792,000 m/s / 1,090,000,000Hz wavelength = 0.275m = 275mm half wavelength = 137.5mm quarter wavelength = 68.75mm === So you can see how much even a fraction of a second can throw off MLAT calculations. Some knuckle head is 1 ms off .. that's a lot of distance 186 miles (if I did the math right) MLAT isn't that accurate to begin with, not compared to ADS-B. Antenna at higher altitude will give you more horizon as limited by RF interference, terrain, and curve of the earth. Eventually you run out of horizon because the earth is round. IF we consider only the geometry, the formula for distance (miles) is 1.22 multiplied by the square root of the height (feet) of the aircraft. So, at 10,000 feet you can see 122 miles, at 30,000 feet you can see 211 miles, and at 40,000 feet you can see 244 miles
You are right James. System time is important. Another aspect to consider is the processing latency. Can we assume that most of the contributors will use a Raspberry pi with a RTL receiver? In that case the time, network and processing latency should be pretty homogeneous, since most will use the default time-server and the same hardware/software. The Linux-NTP client is compensating network latency quite well, as long as it is homogeneous.
I think we can assume that most are using the Pi since the MLAT client is python based. Assuming system clocks are synced and processing time to timestamp the data is relatively fast - deviation is minimal. In theory MLAT should be within a 1km, but can be off by 10km or more.
