[0.3b1] Ownship traffic target displayed in FF 7.3 when RY835AI GPS active

[ghost]

Configuration:

• Stratux 0.3b1 from most recent image (except with hostapd v2.4 rebuilt from w1.fi git repository)
• Dual NooElec RTL-SDR
• RY835AI module on USB connection
• ForeFlight 7.2 (iPad) and ForeFlight 7.3 (iPhone)

During initial ground testing of my RY835AI, I noticed a ground traffic target at my location in ForeFlight 7.2 and 7.3 -- note the brown color. This disappears when GPS is disabled, or when traffic is disabled.

The target is not displayed in Avare or FltPlan Go, nor is a traffic report visible in the data stream on port 43211 through using Avare Connect.

Have not flown with it yet, so I can not comment on whether this is present in flight.

[cyoung]

Is it persistent or only appears on startup/link?

[ghost]

Persistent. When in motion on the ground, the target appeared as airborne traffic at 4000' MSL. I had similar results in flight yesterday. Let me know if there's anything you'd like to see from the logs on my 0.3b2 image before I wipe it and move to 0.3b3.

[JohnOCFII]

I'm seeing the same thing with 0.3b3 and ForeFlight 7.3.

[cyoung]

Two issues here. First one that @AvSquirrel was having on the ground may be a bug. The second one, AFAIK, is the "TIS-B shadow" that seems to be a problem with other receivers also. I think we can fix it by giving a list of traffic targets in the web interface and having a method to select it as ownship.

[JohnOCFII]

The second one, AFAIK, is the "TIS-B shadow" that seems to be a problem with other receivers also.

Yeah, I can't remember what happens with our Stratus 2 / ForeFlight combination. Part of our club has ADS-B Out, and I fly those aircraft when I can. Of course, my car does not have ADS-B out. :)

[cyoung]

The screenshot above that shows in a car then? TIS-B shadows happen in aircraft without ADS-B Out

[JohnOCFII]

The screenshot above that shows in a car then? TIS-B shadows happen in aircraft without ADS-B Out

Yes, that screen shot was from a car. I'm trying to remember if ForeFlight/Stratus does anything to suppress that aircraft without ADS-B Out. My next chance for testing in a plane with Stratux and Stratus will be this coming Friday.

[egid]

I saw this in flight, too. When the shadow (with a hard-coded altitude, for some reason) gets selected as ownship, ForeFlight uses that as the offset for all other traffic. If you're up high, you get some pretty weird relative altitudes.

[ghost]

@cyoung - all of the screenshots above were taken on the ground. The screenshot in the OP was in my office; the two in my second post were from my car. Neither one, obviously, was equipped with any sort of transponder.

I saw similar results in a Mode C equipped aircraft (i.e. no ADS-B Out, and no Mode S code) in areas where I was outside TIS-B coverage, and/or not outside the "hockey puck" of a suitably equipped aircraft. As was the case on the ground, the phantom target appeared with a relative altitude that placed it at 4000'.

I also observed @egid 's relative altitude bug on other traffic -- if I was at 9500', an ADS-B target at 7500' would be shown as +35 rather than -20.

During my return to the Minneapolis area today, I also observed that the TIS-B target corresponding to my airplane was being tagged as Ownship in ForeFlight. When this occurred, the phantom target disappeared from the map:

[egid]

@AvSquirrel's screenshots show the exact same data I was seeing, aside from GS (which may be coming from the GPS). 4,075', 960 ft/min.

I either had a ghost, or the bad relative altitudes, never both. Seems like it could be related to the 0 alt bug?

[ghost]

@egid, @cyoung - Think I found it. Looks like an error in handling of ownship pressure altitude in gen_gel90 when there is no valid pressure altitude.

GDL90 format stores ownship pressure altitude as a 12-bit offset integer (25 foot intervals from 0x000 = -1000' MSL to 0xFFE = +101,350' MSL). Default value of alt is therefore 0xFFF, corresponding to "invalid altitude".

The problem occurs during reading / conversion of the ownship pressure altitude. Currently, we look to see if there is a valid temperature/pressure signal. If so, it immediately assigns pressure_alt to alt as a uint16. Then, regardless of whether altitude is valid, it adds 1000 to alt and divides by 25.

This effectively treats the coded 0xFFF "invalid altitude" as an actual altitude of 4095'. This is stored as 203 (0x0CB) ... which decodes to 4075'.

func makeOwnshipReport() bool {
...
    // This is **PRESSURE ALTITUDE**
    alt := uint16(0xFFF) // 0xFFF "invalid altitude."

    if isTempPressValid() {
        alt = uint16(mySituation.pressure_alt)
    }
    alt = (alt + 1000) / 25
    alt = alt & 0xFFF // Should fit in 12 bits.

    msg[11] = byte((alt & 0xFF0) >> 4) // Altitude.
    msg[12] = byte((alt & 0x00F) << 4)

Instead, the conversion should be moved inside the if statement. This should keep the 0xFFF value from being overwritten.

func makeOwnshipReport() bool {
...
    // This is **PRESSURE ALTITUDE**
    alt := uint16(0xFFF) // 0xFFF "invalid altitude."

    if isTempPressValid() {
        alt = uint16((mySituation.pressure_alt + 1000) / 25)
    }
    alt = alt & 0xFFF // Should fit in 12 bits.

    msg[11] = byte((alt & 0xFF0) >> 4) // Altitude.
    msg[12] = byte((alt & 0x00F) << 4)

Haven't tested yet -- need to upgrade golang on my RPi before I can compile with the current Makefile.

[cyoung]

Good catch! Fixing it now. I'll make up an image for you to test with.

[cyoung]

Ref 75f6056

[ghost]

Huh. It's passing the correct (invalid) altitude now, but...

[cyoung]

The correct altitude being 0xFFF?

[cyoung]

Perhaps it's better just to throw in the GPS alt into the pressure alt field in the ownship report. Could you try that and see if you get the shadow or if FF "learns" it as ownship?

[ghost]

Right. Going off p. 20 in the GDL-90 spec:

The Altitude field "ddd" contains the pressure altitude (referenced to 29.92 inches Hg), encoded
using 25-foot resolution, offset by 1,000 feet. The 0xFFF value represents that the pressure
altitude is invalid. The minimum altitude that can be represented is -1,000 feet. The maximum
valid altitude is +101,350 feet.

Examples:

    -1,000 feet        0x000
    0 feet        0x028
    +1000 feet        0x050
    +101,350 feet        0xFFE
    Invalid or unavailable        0xFFF 

I haven't hooked up the pressure transducer yet, so it's correctly passing 0xFFF as the altitude. ForeFlight should treat that as invalid, but it's decoding it as a real altitude.

I'll change it to GPS altitude and try again.

[ghost]

That did it. The phantom target appeared for an instant, but disappeared once I got a GPS lock.

[cyoung]

Your pressure alt is 701', could you try throwing in 700' and see if that satisfies whatever heuristic it uses to determine if this "traffic" is ownship?

[ghost]

Very interesting.

ForeFlight 7.3.1 uses the "ownship geometric altitude message" (0x0b) as its GPS altitude source when an external GPS is connected. If this message is received and valid, it will override the internal Apple GPS for the GPS altitude source, and will be used as the altitude to which all ForeFlight functions (Hazard Advisor, ADS-B traffic, and ownship detection) are referenced.

If ForeFlight receives an "ownship report message" (0x0a), it will use the heading, track, ground speed, and lat/lon provided in that message as the navigation source, overriding the internal GPS for those functions.

Those elements, along with other elements in that message (ICAO code, tail number, pressure altitude, NIC / NACp) are used to create an ownship traffic target. If the reported pressure altitude in that message is more than ±1000' from the ForeFlight GPS altitude (internal GPS or ownship geometric altitude), that target will be displayed on the map. Otherwise, it will be detected as ownship, and its details will be viewable from the FreeFlight menu.

It's not necessary for the ownship message to be received for ForeFlight to detect ownship. Traffic messages (0x14) also seem to trigger ownship detection if they are within ±1000 feet of the GPS altitude, and are sufficiently close in lat/lon to the ForeFlight GPS position.

[ghost]

Visual examples:

Ownship geometric altitude and pressure altitude both set to 10,000'. Ownship message is adjusted to offset lat/lon several miles from true position, and to indicate "in flight" with 88° track and 110 knot ground speed. Ownship is detected and traffic icon is no longer visible.

Ownship geometric altitude increased to 11,005'. Ownship no longer detected, and traffic icon appears.

[cyoung]

Good work, as always. I'll make it default to GPS altitude if pressure altitude is not available - temporarily. I think there were some other apps also that didn't correctly implement this, so this way will probably be better.

[egid]

Nice. Plane is down in the shop so it may be a beta release or two before I can test this out, but it looks like a great solution.

[ghost]

@cyoung - thanks!

I've been playing with ownship pressure altitude a bit more. Once ForeFlight detects a valid ownship signal (i.e. pressure altitude within ±1000' of GPS altitude), it switches to using ownship pressure altitude, rather than GPS altitude, as the datum for calculating relative altitude of other traffic. It will also continue to track the ownship signal regardless of future deviations in ownship pressure altitude.

That explains the weird relative altitudes that @egid and I saw on the pre-0.3b4 releases. On the ground, ownship was never detected, because the bad hardcoded pressure altitude of 4075' was well above my GPS altitude. Relative altitudes of other aircraft continued to display correctly. Once I reached a GPS altitude of 3075', ForeFlight decided that the ownship signal was valid, and began tracking it. That switched the datum height for relative traffic to 4075', regardless of my actual altitude. I could climb to 9500', and it would still show traffic at 5500' as +15, rather than -40.

 

Thinking longer term, you may want to handle the ownship pressure altitude differently depending on which Stratux and aircraft hardware is installed. In decreasing order of accuracy:

• Detect ownship ADS-B Out, and set Stratux ownship ICAO code, callsign, pressure altitude, GPS position, etc. based on that signal
• Detect ownship Mode S, and set Stratux ownship ICAO code, callsign, and pressure altitude based on that signal
• Use RY835AI pressure altitude for ownship pressure altitude.
• Use GPS altitude, corrected for local altimeter (FIS-B METAR data?) for ownship pressure altitude

My recollection is that Stratus 2 takes the first approach; the actual aircraft ICAO code, callsign, emitter category, integrity, etc. appears in the ForeFlight ownship menu when you're flying an ADS-B equipped airplane. Stratus detection is likely position and/or signal strength based, and you might be able to take a similar approach. Hard coding of ICAO address would be another approach, and might be more straightforward to implement for users who fly a single airplane (and who don't use UAT anonymizing).

Non-ADS-B detection of ownship altitude could be trivial for Mode S aircraft if you can look for a specific ICAO address.

The Bosch pressure transducer on the RY835AI looks pretty accurate per its spec sheet (±1m typ accuracy; ~±10m long term drift). Gage error in most unpressurized aircraft would be the typical alternate static error. This approach obviously wouldn't work for pressurized aircraft.

GPS altitude by itself could easily be off by ±800' on high / low pressure days. However, if you can apply a local altimeter correction from a local FIS-B METAR to geometric altitude, it should provide a reasonably close approximation of the local pressure altitude. It might even be more accurate than an uncalibrated transducer without a real static line.

[emuyshondt]

Would it be possible to use the internal barometer in newer iPhones and iPads (I think iPhone 6 and newer, as well as iPad Air2 and newer) to set pressure altitude? 

_____________________________

From: AvSquirrel notifications@github.com
Sent: Saturday, September 26, 2015 7:27 AM
Subject: Re: [stratux] [0.3b1] Ownship traffic target displayed in FF 7.3 when RY835AI GPS active (#41)
To: cyoung/stratux stratux@noreply.github.com

@cyoung - thanks!

I've been playing with ownship pressure altitude a bit more. Once ForeFlight detects a valid ownship signal (i.e. pressure altitude within ±1000' of GPS altitude), it switches to using ownship pressure altitude, rather than GPS altitude, as the datum for calculating relative altitude of other traffic. It will also continue to track the ownship signal regardless of future deviations in ownship pressure altitude.

That explains the weird relative altitudes that @egid and I saw on the pre-0.3b4 releases. On the ground, ownship was never detected, because the bad hardcoded pressure altitude of 4075' was well above my GPS altitude. Relative altitudes of other aircraft continued to display correctly. Once I reached a GPS altitude of 3075', ForeFlight decided that the ownship signal was valid, and began tracking it. That switched the datum height for relative traffic to 4075', regardless of my actual altitude. I could climb to 9500', and it would still show traffic at 5500' as +15, rather than -40.

 

Thinking longer term, you may want to handle the ownship pressure altitude differently depending on which Stratux and aircraft hardware is installed. In decreasing order of accuracy: Detect ownship ADS-B Out, and set Stratux ownship ICAO code, callsign, pressure altitude, GPS position, etc. based on that signal Detect ownship Mode S, and set Stratux ownship ICAO code, callsign, and pressure altitude based on that signal Use RY835AI pressure altitude for ownship pressure altitude. Use GPS altitude, corrected for local altimeter (FIS-B METAR data?) for ownship pressure altitude

My recollection is that Stratus 2 takes the first approach; the actual aircraft ICAO code, callsign, emitter category, integrity, etc. appears in the ForeFlight ownship menu when you're flying an ADS-B equipped airplane. Stratus detection is likely position and/or signal strength based, and you might be able to take a similar approach. Hard coding of ICAO address would be another approach, and might be more straightforward to implement for users who fly a single airplane (and who don't use UAT anonymizing).

Non-ADS-B detection of ownship altitude could be trivial for Mode S aircraft if you can look for a specific ICAO address.

The Bosch pressure transducer on the RY835AI looks pretty accurate per its spec sheet (±1m typ accuracy; ~±10m long term drift). Gage error in most unpressurized aircraft would be the typical alternate static error. This approach obviously wouldn't work for pressurized aircraft.

GPS altitude by itself could easily be off by ±800' on high / low pressure days. However, if you can apply a local altimeter correction from a local FIS-B METAR to geometric altitude, it should provide a reasonably close approximation of the local pressure altitude. It might even be more accurate than an uncalibrated transducer without a real static line.

—
Reply to this email directly or view it on GitHub.

[cyoung]

3c50cd5