-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Virtual VFR does not render properly #241
Comments
I would say make it configurable with a nice note describing the issue. Personally I'd just disable the feature altogether but others seem to like it so I concede. But ultimately it doesn't really matter to me if you want to just use COURSE to get it done. If it matters, somebody can fix it later. |
It is nothing I would rely on but having it available as some extra information is useful. pyEFIS showing you are lined up with runway 28 is nice, especially if you were confused and thought you were lined up with 10.... I think it is more important to show where you are landing, not what the nose of your aircraft is looking at. |
pyavtools library is also flawed To render the runway properly the bearing needs converted to true bearing. pyavtools does not account for the T and does not correct magnetic bearing to true. |
I merged a few changes in pyavtools along with #242 here. I used the Flight Data Recorder feature in FIX Gateway to record my landing at 4I3. With this sample size of one it seems fairly accurate now. |
Nice!
From: Eric Blevins ***@***.***>
Sent: Thursday, July 18, 2024 8:30 PM
To: makerplane/pyEfis ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [makerplane/pyEfis] Virtual VFR does not render properly (Issue #241)
I merged a few changes in pyavtools along with #242 <#242> here.
I used the Flight Data Recorder feature in FIX Gateway to record my landing at 4I3.
Then using the recorded data I used the playback option and recorded a screen cast of pyEFIS and iFLY EFB and combined those with the video from my helmet cam to create this video <https://youtu.be/3ELrnPiSWj4>
With this sample size of one it seems fairly accurate now.
—
Reply to this email directly, view it on GitHub <#241 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHT7H37TVSTBNIBAFHLNQTZNBMX3AVCNFSM6AAAAABK3ITXIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZXHAYTANJYGA> .
You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/ABHT7HY67RJLN5NNNJ337ELZNBMX3A5CNFSM6AAAAABK3ITXIWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUFMJDZI.gif> Message ID: ***@***.*** ***@***.***> >
|
Yesterday I temporarily attached my AHRS/GPS and a Pi5 to the dash in my MiniMax and took a flight over to 4I3 to record some data. This Pi also had android installed with the iFLY EFB application to compare to.
All of the data used by iFLY and Virtual VFR comes from Fix Gateway. iFLY rendered correct the whole time but VirtualVFR was just plain wrong. The runway was to the right off the screen when I'm flying straight down the centerline. I've seen the same issues when using FlightGear plugin in Fix Gateway. The view in Virtual VFR does not match the view in Flight Gear.
Now that I have some real data to replay I started looking into this.
Instead of using HEAD in virtual VFR I changed it to COURSE. Then I made sure that magnetic declination was always 0 in the VirtualVFR code. With that the view from iFLY and VirtualVFR were very similar. I suspect the view angle might account for the slight differences in view.
Using HEAD with correct magnetic declination should render the correct view of what is seen when looking straight out the windscreen. The problem here is one needs precise Magnetic headings and declination corrections.
Using COURSE would render the correct view when looking in the direction of travel, the GPS course is quite accurate and no need to deal with constantly changing magnetic declination.
I suspect my magnetometer needs calibrated when attached to the dash in my MiniMax so that might account for some of the issues I experienced.
But the magnetic declination library used in VirtualVFR is quite old making the issue worse. If we are going to use HEAD we need to make sure that the magnetic declination is kept up-to-date.
I'm not sure what direction we should go here but I'm leaning towards using COURSE for these reasons:
Anyone else have any feedback on this?
The text was updated successfully, but these errors were encountered: