Together we make EasyVFR

Benachrichtigungen
Alles löschen

Stratux Europe Edition

31 Beiträge
7 Benutzer
4 Likes
4,363 Ansichten
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

As one of the initiators of the Stratux Europe Edition, I am happy to see how smoothly Stratux integrates with EasyVFR 4 (just downloaded and tested). I assume that many EasyVFR users already are running such a combination successfully.

Although Stratux started first for the US market and therefore (besides ADS-B) supports 978MHz UAT, the Stratux Europe Edition Team significantly enhanced the US version for use in Europe to also support 868MHz based traffic. For more information, please visit https://github.com/b3nn0/stratux .

I just updated the EFB configuration wiki accordingly for EasyVFR 4: https://github.com/b3nn0/stratux/wiki/EFB-Configuration

For more question, feel free to contact me - as I have no EasyVFR 3 running, I can only speculate about the configuration there. For both versions it is important to disable the "GDL90: Use MSL instead of HAE" switch in the Stratux settings menu so that traffic altitudes are correctly displayed in EasyVFR. As the Stratux Europe Edition also supports the FLARM-NMEA protocol, I will be testing this shortly and report if it works with EasyVFR and how the required configuration is.

Best,

Stefan

30 Antworten
Beiträge: 2
New Member
Beigetreten: Vor 4 Jahren

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

 

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

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.

Antwort
Beiträge: 2
New Member
Beigetreten: Vor 4 Jahren

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?

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

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.

Antwort
Beiträge: 88
Beta tester
Estimable Member
Beigetreten: Vor 5 Jahren

@Stefan,

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

Thanks

Albrecht

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

@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.

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

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.

Antwort
1 Antwort
Beta tester
Beigetreten: Vor 5 Jahren

Estimable Member
Beiträge: 88
Posted by: @viruspilot

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.

@viruspilot,

thanks a lot. This is very reassuring. I read so many problems with GDL90 and bearingless targets that I was hoping for this to work. I  am in the process of building my stratux, will fly it with EV4 as main display and will report here and in the stratux slack channel as soon as I have it running.

Great work! best regards

Albrecht

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

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.

Antwort
Stewart Buckingham
Beiträge: 443
Moderator
Honorable Member
Beigetreten: Vor 5 Jahren

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

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

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

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

EasyVFR3 downloaded/tested and Stratux Wiki complemented accordingly.

Antwort
Beiträge: 1
New Member
Beigetreten: Vor 3 Jahren

Many thanks, Stefan - that was super-quick!

You are a real star!

 

VBR

Stu B

Antwort
Beiträge: 88
Beta tester
Estimable Member
Beigetreten: Vor 5 Jahren

t yt u    Z

Antwort
Beiträge: 88
Beta tester
Estimable Member
Beigetreten: Vor 5 Jahren

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.

 

Antwort
Beiträge: 993
Admin
Noble Member
Beigetreten: Vor 5 Jahren

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. 

 

Antwort
1 Antwort
Beta tester
Beigetreten: Vor 5 Jahren

Estimable Member
Beiträge: 88
Posted by: @rob-weijers

... 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. ...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. 

 

Posted by: @viruspilot

EasyVFR3 downloaded/tested and Stratux Wiki complemented accordingly.

 

Yes I believe I used GDL90 since I used the "automatic source" setting and E4 found and connected the Stratux automatically. I did get a message that E4 is switching to GDL90 as GPS source.

Unfortunately I can't do more testing right now because my T-beam PCB quit working. I ordered replacement parts, but this will take some weeks.

ASAP I will test this with the upcoming version using both the GDL90 Stratux / automatic as source setting and the Flarm(TCP) fixed setting. It would be easy to cover the GPS antenna of the Stratux with some metal and see how E4 handles this.

Is there a way to protocol the GDL90 / NMEA comm seen by E4?

Maybe in the meantime Stefan Geyersberger could help with testing if he reads it?

Best

Albrecht

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

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.

Antwort
1 Antwort
Admin
Beigetreten: Vor 5 Jahren

Noble Member
Beiträge: 993

@viruspilot Should be no problem, what should be the threshold value for NACp to consider it not reliable? 

 

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

NACp <=4 is considered not reliable

from the GDL90 spec:

MFD Recommendation: Targets with either a NIC or NACp value that is 4 or lower (HPL >= 1.0 NM, or HFOM >= 0.5 NM) should be depicted using an icon that denotes a degraded target.

Antwort
Beiträge: 88
Beta tester
Estimable Member
Beigetreten: Vor 5 Jahren

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

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

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

Antwort
Beiträge: 131
Beta tester
Estimable Member
Beigetreten: Vor 5 Jahren

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.

20210904 124210

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?

Antwort
Beiträge: 131
Beta tester
Estimable Member
Beigetreten: Vor 5 Jahren

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:

20210904 132638
Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

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

Antwort
Beiträge: 131
Beta tester
Estimable Member
Beigetreten: Vor 5 Jahren

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 ? 

Antwort
Beiträge: 993
Admin
Noble Member
Beigetreten: Vor 5 Jahren

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.

 

 

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

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.

Antwort
1 Antwort
Admin
Beigetreten: Vor 5 Jahren

Noble Member
Beiträge: 993

Hi Stefan,

Based on what do you draw that conclusion? Of course I keep the option open there is something going on, but in general I dare to question that since we spent so much time on all the stratux forks and various ways devices like PAW and SkyEcho2 implement the GDL90 "altitude" datafield in message 10 (own ship, should be pressure alt), message 20 (Traffic report, pressure altitude) and message 11 (own ship geometric altitude) ;-).

 

Depending on if EV4 receives these 3 messages and the content of message 10 and 11 EV4 tries to determine if the device is giving actual pressure altitude or just "stupidly" just the GPS derived altitude. If the latter, EV4 will try to convert it internally to pressure altitude by searching the nearby METAR for QNH and temperature to use to correct from GPS to estimated pressure altitude. 

Maybe you can email me the details how your implementation provides these three Altitude data elements to further evaluate the mechanism EV4 uses. 

Would that be an idea? 

 

Antwort
Beiträge: 16
Beta tester
Themenstarter
Eminent Member
Beigetreten: Vor 3 Jahren

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?

Antwort
Mein Warenkorb
Dein Warenkorb ist leer.

Sieht so aus, als hättest du noch keine Wahl getroffen.