knicholson32 / stratux_ahrs Goto Github PK

Love your AHRS Display but was curious if you ever considered adding a Slip / Skid Ball?
Thanks,
[email protected]

hello,
I have buy an ahrs module for my stratux, but it's impossible to have the roll, pitch and accelerometer. i have a error message. The vendor tell me to make an update with a file on this web page. http://updates.stratux.me/builds/
how is the procedure to make an update please?

thanks
Olivier

Describe the refactor proposal
The current G-Meter indicator is almost impossible to read, especially on a phone. It would be useful to convert the G-Meter to some sort of a linear indication, instead of a rotary one as it currently is.

Expected behavior
More readable, colorful, unobtrusive indicator.

Great work until now !!! Is there any possibility for adjusting Baro altitude to QNH ?

When opening the "app" while the phone is in portrait mode (iOS), the program loads with a black bar on the top. This is a known issue with how Safari processes landscape mode.

Will fix as soon as the bug is corrected- for now, open the app while holding the phone in landscape mode.

Currently, the only way to update the AHRS implementation is to sftp files to the pi. Most airplanes are parked out of wifi range, so it would be nice if updates could be handled through a client phone somehow.

Look into CI for AHRS:

• Implement NPM Testing manager
• Use Jest to test javascript functions
• Use TestCafe and Jest to test browser functions
• Use JSHint to configure style
• Use eslint to configure style

Issue
It is often cumbersome to have to open up the Stratux config page at the end of each flight to shut down the Raspberry Pi safely.

Ideal Solution
The Stratux AHRS application already provides an easily accessible menu. It would be fairly trivial to add an option to shutdown Stratux there, and it could use the same XHR post that the Stratux config page uses.

There are other solutions, such as additional hardware, locked file systems, etc, however the easy of use and low cost of this solution makes it appealing.

The Simulate Tag does a good job of showing when the user is in simulate mode, but it would be nice if a click on the badge could revert to normal mode, in case simulation mode is left on somehow.

Describe the solution you'd like
In the online demo, and while simulating at home, the AHRS display fills the entire browser screen. Without using something like Chrome Developer Tools, it is hard to see the display as it might look on a device. It would be useful to have a way (possibly through a url variable: frame=true) to frame the display in a phone or tablet form factor. The extra space could be used to add simulation controls.

Describe alternatives you've considered
Currently can be achieved with developer tools in the browser. Not great for online demos or easy usability tests.

Additional context
General style should mimic the images on the wiki:

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Start Stratux normal
2. Connect to stratus wifi network
3. open browser on 192.168.10.1/ahrs
4. See error: I get 6 red crosses over speed, altitude, track, slip skid and horizon

Smartphone (please complete the following information):

• Device: any

Additional context
Add any other context about the problem here.

It would be nice if the source of simulation data could come from the phone's orientation, if available. Look into using phone accelerometer as crude simulation data while in simulation mode.

Can't display in portrait mode in chrome browser. Also would like to see NM as ground speed unit

Describe the solution you'd like
It would be neat to be able to see a working demo of the AHRS without having to pull the repo and host the web page manually. A demo web page with the ability to change settings and device frames would be neat to have access to.

Additional context
Simulation can currently be controlled via a url variable simulate. This and other variables could be used to allow using production code in a simulated environment.

When displaying a negative altitude, the altitude tape has sizing issues, and no tick marks exist. Probably not vary high priority, however very extreme altimeter settings could cause it to manifest.

System needs to be tested and configured for use on Android devices. Might include adding a manifest file, theme color, launch image, and service worker.

Doug is right (#20): the further development should prefer portrait mode in my opinion.
In portrait mode it would be possible to split the screen similar to Aspen Avionics E5:
in the upper section the display with the 2019 Release elements without heading,
in the lower section compass arc selectable from GPS or magnetic sensor (additional in Stratux necessary or are iPhone`s sensors suitable?) and heading bug input referring to this with values in true or magnetic north.
Perhaps it is possible to get values of lateral course deviation from Foreflight or a simple app running in Raspberry. In this way it could be possible to display a HSI screen ...

I´m very curious about the further development. Many thanks for the until now done.
Kind regards
Franz

It would definitely be nice (for development and bug monitoring later on) to have the javascript console piped to a console that is visible form the AHRS menu, especially since this is designed to run on mobile devices with no native console. Perhaps a development page can be added with the console (and other useful items) to keep it out of the way for users that aren't interested.

It is hard to tell if you are in simulation mode, other than by looking at the data and interrupting. Because it is possible (because of cashing) that someone could accidentally have simulation mode activated during flight, there should be an easy way to tell that the data is bad.

Describe the refactor proposal
Currently, the satellite badge shows how many satellites are being used for a GPS lock. This doens't say anything direct about the GPS location accuracy though. It would be nice to convert this badge to meter accuracy instead.

Expected behavior
The satellite badge should show GPS accuracy in meters (or many a unit of choice).

Issue

When starting the display in portrait mode, a space is carved out for the status bar. Upon transitioning the display to landscape mode and back to portrait mode, the safari webapp recalculates the status bar dimensions and for some reason converts it to black-transparent. There should be a soft-fix for this.

The below images illustrate this transition. Notice the status bar on the left of the display.

... transition to landscape and back to portrait ...

Proposed Fix

When the display starts up, if it is running on an iPhone and is in portrait mode, it should save the dimensions of the screen. If it ever returns to portrait mode from landscape and the screen width has increased, it should fill the gap with black and float right, creating space for the status bar.

In my opinon, one of the most useful flight instruments out there is the Flight Path Angle and/or Flight Path Vector displays. Flight Path Angle is a display of your current angle of climb or descent, in degrees, shown above or below the horizon. Flight Path Vector is the same display, but with lateral movement to indicate wind drift (difference between ground track and heading). FPA/FPV vs. Pitch indicator is also a "poor man's AOA gauge" that helps you see visually when you are approaching stalling angle of attack.

I would love to see this instrument implemented in this project!

Let me know what I can do to help, especially beta testing.

Thanks.

Despite code in place to reconnect the AHRS websocket upon a failure, sometimes the display will disconnect and never reconnect, requiring a restart of the "app".

Look into updating the disconnect-detection to prevent this from happening.

Issue

When the display is rotated to landscape from portrait mode on the iPhone (doesn't seem to do it on the iPad), the status bar carves a space at the top but does not populate, as seen below. This is related to the webapp issue that causes #4.

Proposed Fix

Not sure what to do here- maybe experiment with shifting the viewport? Look into this more.

Sorry, i´m not familiar with GitHub ...
Is it possible for me to reopen a closed issue?
Below issue #16 i wrote a request for an enhancement, but i´m not sure if you are notified because this issue is closed.
Thank you for your answer.

Include a basic startup message / banner that is on by default, letting the user know that they should not risk their life over this AHRS. If they change the config file, they should be able to turn the message off (signifying that they understand this system's limitations).

Perhaps create a custom alert (instead of the default HTML one) so that it is less invasive.

Several elements onscreen are highlightable. They ideally shouldn't be.

It would be nice to be able to see what is going on with some more detail. The image shows the atom error message alert. Something like this would be cool, but maybe more subtle.

Basically this would take console logs / warns / errors and display them really small as a tag, just to allow us to see what is going on. Should be configurable in the configuration file.

• Include additional images highlighting the features of the sub-menu
• Rewrite instructions for how to calibrate
• Update old images

Describe the refactor proposal
When entering aircraft speeds (arcs) into the speed tape configuration, the entered values should be represented by the specified unit entered. At the moment, the bands are configured in MPH regardless of what unit the speed tape actually uses. This is confusing and not applicable, as most aircraft use knots anyways.

Expected behavior
The values entered into the speed tape configuration should match the speed tape unit. For example, if the unit is 'kts', all values in the configuration would be interpreted by the system as 'kts'.

Screenshots

/** ******************************** SPEED ********************************* **/
var speedTape = {
  lowerSpeed: 0, // <--- Here
  upperSpeed: 200, // <--- Here
  speeds: [
    // Speed color band configurations given in MPH
    {
      color: COLORS.WHITE,
      start: 55, // <--- Here
      end: 115   // <--- Here
    },
    {
      color: COLORS.GREEN,
      start: 64, // <--- Here
      end: 140   // <--- Here
    },
    {
      color: COLORS.YELLOW,
      start: 140, // <--- Here
      end: 171    // <--- Here
    },
    {
      color: COLORS.RED,
      start: 171, // <--- Here
      end: 200    // <--- Here
    }
  ],
  units: UNITS.MPH // <--- Based on this unit
};
/** ******************************** ***** ********************************* **/

Additional context
Most airplanes these days use knots, not mph. It really doesn't make sense to lock it to those units, even though we can display any unit we want.