NTRIP caster support in future Pia images

FlightAware Feature Requests and Ideas
1

NTRIP can give up to 1 cm precision to unit itself. Either if correction is emited by geodetic Total Station, IP link from national/private/free correction facility / geodetic service and/or user’s own real or virtual total station for better precision support.

With flights tracked only by single sensor, and even with multiple sensors, routes could be a little bit more correct. For large airplanes 1 cm is not maybe important, but for drones it could be good to have this as future feature, e.g. to track parcel deliveries…

2

NTRIP effective range isn’t very large.
Stationary stations, like ADS receivers, can benefit more from GNSS if they set their receiver to stationary mode.

GPS is starting to broadcast on more frequencies, increasing precision. I have GPS units that can receive L1C/A(original GPS signal), L2C (new) and L5(new specifically for aircraft and Safety of Live transportation). L1 is coming but only available on a handful of GPS satellites. GPS.gov: New Civil Signals
BeiDou, Glonass and Galileo already use multiple frequencies.
QZSS (Regional) and IRNSS will also increase the accuracy of GNSS.

My Sports watch supports GPS,Galileo and Glonass on multiple bands.

There are handheld GNSS units available, for less that $US400, that support multiple bands as well as multiple GNSS systems. They will only get cheaper as they become more common.

Penn State has a free online course that explains, in a little more detail, how GNSS systems work.
https://www.e-education.psu.edu/geog862/home.html
It is fairly easy to understand.

3

I don’t understand, you are worried about the precision of the receiver location?

For non-mlat, the position can be 10km+ or even 100km+ wrong and everything will still (mostly) work, the receiver location is only used at a very coarse level (“is this position implausibly far away?” / “which octant of the earth is this surface position in?”)

For mlat using a rtlsdr dongle, the limiting factor is the timing precision of the dongle; that introduces errors of +/- 300m. A receiver location that’s correct to within +/- 10m is more than good enough in that case.

Neither case needs anything like 1cm precision.

4

Re:Obj

This is future feature, when number of drones would outnumber maybe 1:4 number of present aircrafts, when separation will become critical problem.

Present “stick” errors will not exist in “X” version of the “stick”; which is under development, the same is with integrated boxes.

Understanding however that this is not feature for amateur use, but for MLAT,
where idea was, just to include this in software, since by uncommenting 2 lines,
receiver could have improved GPS precision. Some data traffic use penalty, yes, but it’s worth it.

Some countries offer GPS correcting data (several classes might exist, such as sub-meter, sub-centimeter, sub-milimeter) flow for free. Not from single total station, but from total station network, where usually 1 such system is positioned on approproate location, each being ~10 miles apart, usually operated by governmental geodetic survey service. In some countries it’s private, but also accessible for free, etc. But the point is devices which need precision, e.g. we can do this to our smartphone, then it’s also applicable to ADS-B receivers as well with just entering server IP, port, login and password and it should work.

NTRIP caster support which could without changing any hardware (included in future firmware updates) enable present units to output better data is usefull for everybody.

Regardless to as you called it “dongle” precision in hundred yards, it’s not the dongle we want to make better with this, but to limit error in GPS antenna from 4-5 yards to 1 inch.

If such “feature” as NTRIP support is then used in many MLAT-capable units, things would improve not just in 5th specific space octant, where such receiver would operate, but in wider area.

Neither commercial aviation nor present development of traffic needs this feature, but in the future, things would change, drastically and R&D Flighaware team has a simple solution for improvements, since NTRIP is global standard. Flightware receiver (unit)s are ALL already connected to Internet, and to pick it’s correction from some internet server, makes it possible, with firmware upgrade, to boost precision worldwide on any unit curently without changing anything in hardware/antenna/cables.

I repeat, for drones, every centimeter of precision counts. Drones, like Dronamics Black Swan already have in planning their Dronodrome network.

For those unfamiliar with the Dronamics, it’s ICAO code is OY/DXE, they are from Bulgaria, developed by Rangelov brothers, Black Swan UAS has LUAS licene form Malta, is World’s First Cargo Drone Airline with IATA and ICAO Designator Codes (curently operating in Europe) and can carry 350 kg of cargo with 2500 km range. This feature, is intended to help us better monitor operators like them, and soon Amazon and others.

5

Jon:
For single total station, you are correct, but adding GNSS and NTRIP support can not do any harm to any setup, just help. If there is only 1 total station, receiver reading data from it via Internet if it’s 10 km away, would have sub-1cm precision. For devices far from such total station, precision would be few cm, but even that would be better then 4-5 m.

Since 7 days ago, Dronamics and Qatar Airways Cargo have formalized a first-of-its-kind interline agreement between a cargo drone airline and an international airline, aviation landscape is rapidly changing. So should ADS-B reception.

6

Could you clarify whether you’re talking about

(a) consuming NTRIP data on piaware to improve piaware’s knowledge of its own position (if so, I’m not sure how this is relevant at all – see my earlier comments); or
(b) emitting NTRIP correction data from a piaware install at a well-surveyed location

If (b) I’m not sure how that’s something piaware should be coordinating, isn’t that something that can (and probably should) be done standalone? Typical piaware install does not have a well-surveyed location (or even a GPS antenna!)

2 Likes
7

It’s obviously only a)

For b) another unit (Pi or similar) might become an RTK for it.
e.g. : Real-Time Kinematic (RTK)

For those interested in experimenting with b), there is open-source solution here:

Hardware needed:

  • Raspberry Pi Model b (e…g. Pi3)
  • 8GB Micro SD card storage (e.g. Sandisk MAX ENDURANCE card)
  • U-blox GPS module that supports RXM-RAWX output (e.g. Neo-M8T, caution not M8, must have T mark as well)
  • 4g USB dongle (Huawei Unlocked E3372h) or WiFi support for internet connection. Permanent IP or Dyndns would be smart thing to have too.
  • proper antenna and cable.

After proper setup, RTK unit gives data on following streams:

localhost:4000 provides the multiplexed GNSS serial stream
localhost:4001 provides the corrected rover stream

a) solution to improve Flightware Pia-precision could gather this data from RTK ports 4000 and 4001 without and hardware change. Just be made available in firmware.

One day…this was just a feature request.

8

Thanks for clarifying. Going back to your earlier posts:

I don’t know how drones are relevant. My understanding of the current conspicuity protocols are that they’re all ADS-B-like in that the position is determined by the drone, not the receiver. multilateration doesn’t even enter the picture.

I don’t think you understand the limitations here.

For receivers without inherent clock synchronization (i.e. a GPSDO) we’re already at the limits of what the synchronization techniques can do – this seems to be mostly limited by the precision of the ADS-B positions used for synchronization. Typically I see around 0.5us accuracy for a rtlsdr dongle; even with a GPSDO receiver (using the timestamps as a dumb clock) which has considerably better inherent clock accuracy than a rtlsdr, the overall synchronization accuracy doesn’t improve.

For receivers with inherent clock synchronization (e.g. a Radarcape-style receiver which generates timestamps tied to GPS time) the precision depends on how good that clock synchronization is, and that’s inherently tied to the hardware’s GPS implementation (since you’re really solving for X/Y/Z/time, not merely X/Y/Z – if you want to improve the accuracy of X/Y/Z, you have to improve the time accuracy too…). Nothing that piaware does after the fact is going to help with that; you need to feed it into the GPS implementation. FWIW Radarcape-style receivers typically achieve <45ns time errors which is somewhere around 10-15m error.

I do not understand where we would usefully include NTRIP in a piaware image. Can you provide a concrete example of how this would work?

This reads like an ad.

9

Future Amendments to the Airspace Requirements on ADS-B and Mode S which are under development, especially in Extended Squitter domain, will go in direction explained in feature request.

Platforms that will not take into account slowing down of airine traffic (due to many constraints including climate change) and boost in drone traffic is not future-proof and will not survive for long (and /or might be bought by Starlink/SpaceX for certain problems to be solved faster). Drones however need a specific precision-issue problem to be solved. If not today, tommorow then. ADS-B Out included.

10

I mean, sure, I get the precision issue.

I don’t understand how the receiver side - piaware - can do anything about the precision of a position determined on the drone itself.

Can you explain what piaware would do with NTRIP data? Please be specific.

11

Use of GPS antenna at receiver location, with augmented precision to sub-1cm, can help to better align antenna in 1GHz spectrum. It matters, presuming GPS antenna and ADSB antenna are on same (sub)pole.

Setups without outdoor GPS antenna added, can not utilize much of such derived feature(s).

This is one example. Future (2025 and beyond), where we are going, is going to be ASB-D Out also for present Rx-only sites, from which drones would triangulate.

12

And at the end, not to be missunderstood, platforms that will not survive future changes, I was reffering to Radarbox and such (which sell sofas on Ebay)…

https://www.ebay.com/str/airnavradarbox

13

Okay. So you are suggesting that the piaware image should feed NTRIP data to GPS hardware running on the piaware receiver, and use this to find a more accurate GPS-derived receiver position?

I note that the piaware images currently have no direct support for GPS hardware. You can install gpsd and configure it for your hardware, if you like. I presume you can configure gpsd to consume NTRIP data. This isn’t really a piaware thing at all; piaware will consume whatever location information gpsd produces.

the gpsd manpage has this to say:

gpsd can use differential-GPS corrections from a DGPS radio or over the net, from a ground
station running a DGPSIP server or a Ntrip broadcaster that reports RTCM-104 data; this
will shrink position errors by roughly a factor of four. When gpsd opens a serial device
emitting RTCM-104, it automatically recognizes this and uses the device as a correction
source for all connected GPSes that accept RTCM corrections (this is dependent on the type
of the GPS; not all GPSes have the firmware capability to accept RTCM correction packets).

Let’s assume you have that more accurate positioning data. How does knowing the receiver location to sub-1cm (versus the current situation where a location is manually entered and is probably precise to, let’s say, 15m – smartphone GPS coordinates or similar) help improve the accuracy of reported ADS-B positions in a meaningful way?

to reiterate what I said earlier –

  • mlat does not benefit from this increased precision, because other errors in the system are several orders of magnitude larger; and mlat is used only for non-ADS-B targets, anyway
  • ADS-B and ADS-B-like schemes do not benefit from this increased precision, because the aircraft position data is determined by the transmitter, not the receiver.

I think it’s unlikely that hobbyist ADS-B equipment will ever have transmit capabilities on regulated bands, simply because of the very high regulatory compliance costs.

14

Personally, I’m against entering coordinates by hand, and using other coordinates from other source, which could be tweaked. This is why certain locations on Coverage map are not correct and show closest airport being in 500+km distant countries. On order of magnitude, such locations happen to be 20+% of all installed equipment per country, which makes a wrong imperssion on certain coverage issues as well. Regarding other issues, it’s good to know that user is allowed to start certain deamons on the boxes if he/she deems appropriate.

That’s why I like Flightwrare, because of it’s open architecture, and that we can talk about plenty of topics, that might not be curently important, but will be important in the future.

For certain areas of the World (e.g. Alaska), ADS-B is all you have, and there is no other non-ADSB systems in existance (so to speak), so it might be easier to have fix point terrestrial ADSB-Out as NDB/VOR alternative, assuming, user provides only internet access and has no root access to equipment. But that is going out of the scope of this discussion.

Remark by obj that we can implement deamons we need ourself is satisfactory answer and any experience with such effort will be shared with FA audience, and Administrators.

Best Regards.
S.