Hi Stefan, Very nice initiative! I just finished building my (TTGO based) FLARM/FANET TX/RX unit and would like to proceed with the combining of the Stratux ADS-B and the TTGO devices. Just found the manual for combining the two into one case.  

What is still somewhat unclear to me is if an active internet connection is required in order to show up on the displays of fellow pilots (FLARM/FANET and ADS-B)? Or will this data be sent via LORA and processed by the OGN-servers (for FLARM/FANET). I understand that there is also an adhoc network through which the units communicate with each other. This lead me to believe no active internet connection is required. For ADS-B and the movingmap I can understand an active internet connection (either WiFi or 4g/5g) is required.

Thnx.

Jesper

Jesper,

if your TTGO is FLARM TX capable (e.g. using SoftRF) or if your TTGO is OGN TX capable (e.g. using esp32-ogn-tracker) an active internet connection is not required to show up on any other device that is capable of receiving FLARM or OGN, including Stratux Europe Edition as the TX (868MHz) is directly received (this is what you might describe as adhoc). This is furthermore true for ADS-B traffic - it will be received with Stratux also with no active internet connection required (adhoc).

The OGN servers are typically used for tracking and logging rather than traffic warning.

Thnx for the clear reply!

Reading through the complete website, I found 2 options for building a stratux with FLARM capability.

1. Stratux with a separate TTGO board (this wil enlarge the casing) This will send and recieve FLARM signals.

2. One complete unit, https://www.amazon.de/gp/product/B08BS4MP22/ref=as_li_tl?ie=UTF8&camp=1638&creative=6742&creativeASIN=B08BS4MP22&linkCode=as2&tag=crewdog01a-21&linkId=bbfac6219190334d51a944a50265ccf2 (As far as I can find this only incorporates FLARM RX and no TX) 

Without letting this becoming a "Stratux build post" I was wondering what in your opinion what would be the best option?

Let's continue this discussion in the Slack channel. Your linked complete unit is a RX only device but you can easily extend it to an OGN TX device.

@Stefan,

did you try the FLARM-NMEA protocol in the meantime with EV4 and Stratux? Any experience / setting recommendations?

Thanks

Albrecht

@Albrecht, it was a while ago that I tested it - I remember that it worked right away but let me test it once again. I will make some notes then accordingly in the Stratux Europe Wiki which so far only covers the GDL90 mode which works right away.

So I have verified how to do the settings to use FLARM-NMEA and have changed the Stratux Wiki accordingly:

easyvfr-using-flarm-nmea-protocol

I had no chance yet to test it while flying. Just noticed that when for some reason the FLARM-NMEA connection fails then easyVFR automatically falls back to GDL90.

With my Stratux development board here at my office window, I can see some bearingless targets on the EV4 screen, presented as a circle and as a banner.

Thanks for your work on this Stefan, and for posting settings for EasyVFR into the Stratux Wiki. We really appreciate your work! Just one point, though, if I may - it seems the settings you advise are for EasyVFR4 - they do not correspond directly to the options that are available in EasyVFR 3 . EasyVFR3 does support Electronic Conspicuity both via FLARM protocol and by GDL90, and it is still in widespread use, both in regions not yet released in EasyVFR4 and by users whose devices are older and not suitable for EasyVFR4. So as to avoid confusing any EasyVFR3 users, could you please make the small change to ensure your advice is shown as being for EasyVFR4? (If you were able to provide also the corresponding advice for EasyVFR3 users, that would be "the icing on the cake"!)

VBR

Stu B

More than happy to do this, will download and test EasyVFR3 as soon as possible and complement the Stratux Wiki accordingly.

EasyVFR3 downloaded/tested and Stratux Wiki complemented accordingly.

Many thanks, Stefan - that was super-quick!

You are a real star!

VBR

Stu B

t yt u    Z

I would like to ask the devloper team how the setting "automatic NMEA source" is supposed to handle different GPS sources in EV4.

I am currently building my Stratux EU and I noticed that with this setting active EV4 switched from the internal GPS of the tablet (which is extremely sensitive and reliable) to the Stratux GPS. Would be fine, but when the Stratux lost position (under a roof, with a poor passive GPS antenna) EV4 would still indicate a 3D fix although the Stratux had no fix and E4 did not switch back to the internal GPS which had a fix.

So I am afraid now that EV4 does not recognize a bad GPS source connected through GDL90 and sticks to that source even when it lost the fix.

Best regards,

Albrecht.

Hmmm, you might be on to something. I did find a bug where the automatic switching from external GPS to internal GPS only occurs if the connection to the external GPS is entirely lost. When the tablet is still connected to the external device but the external device reports a bad reception, then the current version of EV4 will stick with the external device and not auto-switch back to the internal GPS. I fixed that in the upcoming version.

However, you should get a warning when the external GPS doesn't provide an accurate fix. Since you didn't get that, the question is now why not. I suspect you are  using GDL90, and in that case EV4 checks the NIC value of the ownship report, and considers a value of 0, 7 or 8 as accurate. Does somebody now how we can detect for the stratux eu fork that GPS position is unreliable when using GDL90?

For completeness, when FLARM protocol is used then the GPS position accuracy is taken from the either $GPGSA message where a value of 3 is required to consider it reliable, or the $PFLAU message if it flags the GPS as valid. 

Stratux is using a fixed NIC = 8, this explains the behavior. Could EV4 read NACp instead? This value is automatically derived from the Stratux GPS and also embedded in GDL90.

NACp <=4 is considered not reliable

from the GDL90 spec:

Wow, thanks a lot. You guys are incredible. Can't wait to fly with the combination of EV4 and Stratux EU.

@viruspilot Does this spec also apply for own ship position?

Maybe the best implementation for cross device compatibility would then be exactly as the wording in Stefan's specs:

NIC OR NACp <= 4 ---> no fix

@Albrecht Yes, traffic and ownship are using the same data format according to §3.5.1 of the GDL90 spec.

Good stuff in this thread, thanks!
I've been flying with Stratux EU for quite some time, including OGN traffic detection. It all just works in EV4.

That said, I've had a number of instances where EV4 gave me traffic alerts and showed the traffic 150 - 300ft lower than reality. Yesterday I got an alert for a chopper 300ft below, which was actually same altitude.

Today I tested against my desktop version, and with AGL synchronized, I am seeing different altitude reports on Android than on Windows.

Both get their information from the same Stratux (v1.6 eu25) source, both have AGL set the same. Stratux reports GPS solution 3D +SBAS, 3.5m with 10 satellites. ADS-B traffic shows same altitude, but Mode-S shows different altitudes. Could this still be a setting on my end, or is there a difference in Windows and Android? Any ideas?

As an experiment I started EV3 (Flarm mode) and EV4 (GDL90 mode) side by side on the same tablet. That too shows an altitude difference:

Do you have a baro module installed in your Stratux?

Can you switch to FLARM mode in EV4 and compare then?

I recommend this article fore more background: https://github.com/b3nn0/stratux/wiki/Altitudes-in-Stratux-EU

Btw, a few hours ago a new Stratux version was released, no changes that would affect altitudes though:

https://github.com/b3nn0/stratux/releases/tag/v1.6r1-eu026

Hi Stefan,
I started up fresh and found both EV3 and EV4 showed identical altitudes. Then I changed EV4 from automatic to Flarm (UDP), still identical.

Then I switched back to Automatic. It selected GDL Stratux, and right away I had 160ft difference! Switched to various modes again, and only Flarm (UDP) gets the altitudes in sync again. All others are now out of sync. Also noteworthy is that only the switch to Flarm (UDP) and any of the others result in a yellow "GPS Source Changed" box. Switching between the sources that are off does not show that yellow box. Switching to Internal GPS has an offset too, and traffic still shows.

My Stratux at home does not have a AHRS/Baro module installed, and the setting for this in the configuration screen is off.

The Stratux in my plane does have a AHRS/Baro module installed. It runs an older version (eu016), as the hardware isn't capable of running the newer versions. That's the one I had 300ft difference with. I'll try Flarm on that one next time I fly.

Btw, the new Stratux eu026 release is partially my 'fault', I reported the memory leak ? 

Guys, just a quick message before all kind of ghost hunting is taking place. I don’t have much time now but I thought its urgent to drop this message here: 

EV4 (and EV3 too, but in a lesser way) try to handle all the different altitudes in “most sensible” way. Realise ADS-B traffic always transmit their altitudes as pressure altitude (aka qnh 1013). If EV4 doesn’t know what altitude its own gps is providing it assumes GPS based, and it uses nearby METAR to correct local qnh to 1013 (27ft per milibar) and estimate its own pressure altitude. So an updated metar data download on one device can cause already a difference with other devices. 

basically only when EV4 is using a GDL90 compatible gps receiver that sends both correct ownship and geoaltitude messages (I don’t know from memory what message its called exactly) then the differences compared to the detected traffic will be the smallest.

To make things complex, many “homekit” systems like stratux and PAW have different implementations (“forks”) all handling gps altitude differently. Some simply put gps altitude as pressure altitude, even if there is no pressure sensor installed. But even of a pressure sensor is available then differences can occur because the pressure sensor is inside your cabin, while the traffic detected could have its pressure from an certified airpressure system (pitot), what can cause differences also.

so IMHO, don’t try to hunt for a few hundred feet difference in “visual altitude” compared to what all these traffic systems claim the difference is. There are simply too many differences in what altitude definitions are used and how they are phisically implemented in the involved aircraft systems.

Just to reiterate, there is still a ~200ft error to the correct pressure altitude difference in case of GDL90 ADSB traffic. Other EFBs show it correctly.

Hi Rob,

all Stratux forks including the Stratux Europe Edition have always transmitted the PALT in message 10 (and 20) but there was a change in message 11: in our latest Stratux Europe Edition (and actually since Mai 2021) we transmit the ellipsoidal altitude according to the spec but in earlier versions it actually was geoid altitude but flagged with the ForeFlight extension message flag.

Does this help?