** Please read Tom **

[Puppa-Smurf]

Tom Firstly a big thank you, for providing me with so much productive fun over Christmas.

I cant see a way to email you directly, but would love to send you the following updated files which I have been working on, for you to use or discard.

I have been working on this for a few weeks now and the wife has not been happy with me ;), but I now have it all working where I'm happy to put it in my aircraft, but thought that you may be intrested.

please let me know, and I'll sent you the updated files.

Radar.py <- Have updated this to ahrsui.py <- proivided the option to calibrate and cage the AHRS flighttime.py <- Added the option of deleting / reseting the list stratuxstatus.py <- this gives you the abilty to adjust the pressure altitude setting, short press 10ft long press 100ft. Oled_1in5: controller.py <- all of the adjuested screen setting and additional text and boxes.

Lastly, a big thankyou for all the work that you have done. Best regards James

[bglaplante]

Sounds great. FYI I've got a larger LCD display working. 240x320 See https://github.com/bglaplante/radar-display

[Puppa-Smurf]

The files if anyone is intreested, just worked out that I could up load them ;)

ahrsui.py,txt controller.py.txt radar.py.txt stratuxstatus.py.txt

[TomBric]

Hi Pappa-Smurf and James, thanks for you contributions. I'm happy to include your updates into the main code.

The best way is to do this via the github workflows. So use the "dev" branch, clone it, and then trigger pull requests. @James: I will take your provided files and include them in the next days. Thanks!

BTW: Meanwhile I have also done some updates and included checklists (at the moment for the 3.7 epaper-only).

Thomas

[Puppa-Smurf]

Opps sorry guys, just spotted a small error in the calculation of the pressure in this file. here is the fixed one. controller.py.txt

[TomBric]

Hi James, I just started to modify and include your code. What I do not get is the necessity for the altitude correction. On all systems that I have seen, it was never necessary to change the offset. That was the reason for not implementing such a never needed function. Do you not use a pressure sensor, or is the sensor delivering wrong values? Please keep in mind that the displayed altitude is GPS altitude (needed for FLARM/OGN positions) and all data for the transponder signals are needed in flight-level notation (based on 1013.25 hPa). So changing the altitude offset which a functioning baro sensor will give you wrong collision signalisation.

[Puppa-Smurf]

As a pilot and I have been involved with some other projects. And you will need to do an altitude correction (it was added to stratux in the base code) you will want to zero the system before take-off so that when the system say that someone is 1000ft above, that is correct.

Now every country has a different transition level, where you go onto 1013.25mb, and your on flight levels, but below that (in Oz it's (10,000ft)) you will be on QNH.

So as you fly between pressure regions, the Hight changes and you will need to reset your altimeter to the local pressure setting you have reduced from the radio.

So, you want a method to make that adjustment in pressure because that how you will receive it.

So it's ok while on the ground, as you can just dial in the Hight of the runway (we will know that), but in the air! I hope you see the point!

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: TomBric @.> Sent: Saturday, January 27, 2024 2:59:56 AM To: TomBric/stratux-radar-display @.> Cc: Puppa-Smurf @.>; Author @.> Subject: Re: [TomBric/stratux-radar-display] Please read Tom (Issue #64)

Hi James, I just started to modify and include your code. What I do not get is the necessity for the altitude correction. On all systems that I have seen, it was never necessary to change the offset. That was the reason for not implementing such a never needed function. Do you not use a pressure sensor, or is the sensor delivering wrong values? Please keep in mind that the displayed altitude is GPS altitude (needed for FLARM/OGN positions) and all data for the transponder signals are needed in flight-level notation (based on 1013.25 hPa). So changing the altitude offset which a functioning baro sensor will give you wrong collision signalisation.

- Reply to this email directly, view it on GitHubhttps://github.com/TomBric/stratux-radar-display/issues/64#issuecomment-1912544346, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A6LX56XENWJXNXML7VEXLY3YQP4KZAVCNFSM6AAAAABCIEQD6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJSGU2DIMZUGY. You are receiving this because you authored the thread.Message ID: @.***>

[TomBric]

Hi James, that is right, we also have this in Germany. But the Mode-S or ADSB transponders (on which the collision detection in Stratux is based) are always sending their position in Flight-Level, that means relative to 1013.25 HPa. So stratux has to compare my own height in FL to the transponder signals of the others. That means, if your baro sensor works correctly, there is no need to change the altitude correction. There is also no need to change the pressure correction in stratux above the transition level. You also do not change QNH in your transponder

[Puppa-Smurf]

Hi Tom, I do not disagree with your comments, and I know that encoders are supposed to use a pressure setting of 1013.25mb, which is the pressure setting that we would all use as we go through the transition Zone. (In Australian FIA 10,000ft) but let me give you a little puzzle to think through.

I live under the YPJT approach, where all entering aircraft are to be at 1500ft (which is a good way to test) and all departing aircraft are at 1000ft. YPJT and myself are at ~90ft AMSL and 3nm apart.

I have the Stratux on 24hrs a day to check stability, over time, as I have been working on it, and noticed that during testing I would expect the see aircraft coming over me on the screen at FL +15 and departing aircraft at +10. So far so good! But some times this was not the case as over the course of a day, or the following day the pressure changes significantly, and I get targets flying over +19 or +20, and the same with departing targets. The question, what has changed? Just the pressure I would say, and I am seeing aircraft now 500ft to 600ft sometimes more or less than what I would expect them to be!

So, I adjusted them with the pressure altitude off set on the Stratux (Again, now all good) but over time I would notice the displayed separation would be wrong!

So, I started back calculating from the “FL” variable, and cross referencing that with the Satellite alt of my location, to work out what the actual off set would be from my position to the target! I went so fare down this rabbit hole that I even asked ChatGPT 😉. Which is sad, because I used to be a CFI!

The longshot of all of this was, that I could now dial in the local QNH, on the display, and the targets would be at the expected altitude while on the way in and in the circuit.

Maybe I got it all wrong, but I have been checking and cross referencing it with my own ADSB receiving station, and external ones as well, to see what matched.

My aim! Was to be able to dale in my altitude wile on the runway or when I received a local QNH on the way in so that aircraft were being displayed, at the high I expected them to be.

But again, maybe I am just starting to get old and just got it wrong!

[TomBric]

Hi James, I have implemented all your feature changes in the dev-branch (at least on the oled display for now, others will follow). I have also added the altitude correction in the same manner as it is on the settings page on the web (only in feet correction). Looking at the stratux code I am still convinced, that you should only correct the Pressure-Alt value, if your pressure sensor has uncorrect static pressure.

[TomBric]

Everything is now included in the v2.0 version