Web interface additions

[cyoung]

• PPM and/or calibrate button.
• WiFi SSID.
• Replay log on/off - might be best to put it all together into a single "debug mode".

Others?

[bradanlane]

I already worked on the log toggling. It requires that logs be created/opened at startup regardless of logging state. This allows logging to be toggled without a system restart.

I would think PPM calibration would not change. My suggestion would be to store it in the Stratux.conf file. If it's absent, the calibration is run ahead of normal startup and stored.

What is the request for "WiFi SSID"? To make it configurable? Is there the expectation of having two Stratux devices in the same airplane? If not, what value does the configurability provide?

[heelix]

For what it is worth, I've got a couple of these units on my desk. One is newer hardware, the other older. I've been getting around it by having one wired, the other wireless, but it would be nice to have both on the wireless network so I could compare them in the air.

[rgutlon]

re: WiFi SSID. I'm not certain if the plan is to simply display the value or allow it to be changed. Those of us using the device with FlyQ 2.0 have to rename the SSID to NavWorxWIFI for the application to recognize the correct protocol. This may change with FlyQ 2.1 (waiting for approval in the app store). At the moment it requires a quick SSH into the device and a simple modification to /etc/hostapd/hostapd.conf (followed by a restart).

[bradanlane]

Now this makes more sense. I was not aware FlyQ needed a specific SSID. In this case, having it default to "stratux" but able to be changed from a GUI would make life easier for FlyQ users.

[JohnOCFII]

Should we add a button for shutdown?

[heelix]

I would. I like having my card in read/write mode. Been SSH'ing in from
the tablet to power down the Pi. A button would be nice.

On Tue, Sep 15, 2015 at 3:02 PM, JohnOCFII notifications@github.com wrote:

Should we add a button for shutdown?

—
Reply to this email directly or view it on GitHub
#43 (comment).

[bradanlane]

The best solution will be having the SD card be read-only with SSH script/commands to toggle into and out of read-write mode. A completed device should be as simple as having a power button for on/off and be tolerant of power failures and batteries running down. Having a shutdown script is a crutch.

[JohnOCFII]

Having a shutdown script is a crutch.

Sure it is, but since it's so easy to add a shutdown button to the Web UI, isn't it better than nothing? Having an easy shutdown from the Web UI isn't going to slow down developers working on the better solution that you propose.

[bradanlane]

My fear is that we (1) do a short term solution and then rely upon it, and (2) spend time on temporary code when we have high priority work than needs the limited developer cycles. In my past experience, anytime a "good enough" solution was put in a product, it became permanent and was the go to answer when users had a problem. In this case, there are already users reporting corrupted SD cards. Either the product can improve for the end user or the user workload can be increased to compensate for the product.

[heelix]

Nothing is as permanent as that which was deemed temporary. This was
something I was kicking around. Might be able to add both bits in when I
get home this weekend.

On Tue, Sep 15, 2015 at 4:06 PM, bradanlane notifications@github.com
wrote:

My fear is that we (1) do a short term solution and then rely upon it, and
(2) spend time on temporary code when we have high priority work than needs
the limited developer cycles. In my past experience, anytime a "good
enough" solution was put in a product, it became permanent and was the go
to answer when users had a problem. In this case, there are already users
reporting corrupted SD cards. Either the product can improve for the end
user or the user workload can be increased to compensate for the product.

—
Reply to this email directly or view it on GitHub
#43 (comment).

[lastdeadmouse]

If you're sshing into the box to make changes anyway, what's one more command to remount RW? RO is certainly the best solution for a device that people may rely on in flight.

[jpoirier]

How is a shutdown switch/button a crutch?

As I've stated before, there's a canonical way of shutting down a Linux system, and/or OS, and users have a reasonable expectation of being able to shutdown the system normally regardless of the type of file system-an RO file system doesn't preclude a shutdown button/switch. Having a shutdown button on the web interface is a nice touch that requires minimal code and has zero drawbacks.

SD card corruption is a well defined problem with well defined solution/s. It's not a showstopper at this stage in the development process, i.e. beta/development software during testing, and imho, it doesn't happen often enough to warrant an RO image. Yeah, it makes sense for release images from 1.0 on to be RO but not now. If it appeases both sides, create both an RW and an RO image.

[bradanlane]

From a user experience design methodology - which is where I come from - "implement both" not ideal.

While a systematic shutdown process is proper for Linux users, the target audience for Stratux is not a Linux user, or even a computer user.

We should not consider the Stratux as a "computer" and thus we should not apply computer methodology when choosing the best experience for Stratux.

My car radio "system" is really a computer but I do not have a shutdown sequence for it. I just turn off the ignition.

The Stratux is targeted at a pilot, flying an airplane. We want to minimize their workload.

[224XS]

Here is two simple suggestions for additions to the web UI.
1)Create a third DIV with button links to the three log files - just a convenience
2)Add to the status message a field with the RaspPi's current df (free disk space) and display it in the web UI

[bradanlane]

Thanks for the suggestions. There are a ton of options that could go into the WebUI. The more we list out, the better we can design how to organize, controls, status, details, etc.

From your suggestions, my first reaction is that info about the RPi would get grouped as system status. The current CPU temp goes there too. The access to logs files goes together with details. Other things that might appear there would be if we wanted to stream the UAT and 1090 messages to the WebUI, or let the user "watch" for specific airport METARs, TAFs, etc.

At this stage it's great to capture the suggestions and not focus on the implementation.

[kdknigga]

While I do agree that RO is best long term, I think your arguments against
a shutdown button are weak.

While the end user shouldn't have to know Linux or Go to make Stratux work,
remember that this is a device that users have to assemble after sourcing
all of the parts themselves. That in itself takes away the expectation
that it should "just work" in the same way a car radio does. If someone is
looking for something like that Sportys would love to sell them a Stratus.

Also, a shutdown button is hardly a substantial increase in workload, and
certainly not during flight. Add "click Stratux shutdown button" to your
after parking checklist.

And finally, in the future when we do have RO by default with RW as an
option, it still would be nice to have an easier way to shut down a RW
image than ssh.
On Sep 16, 2015 4:52 AM, "bradanlane" notifications@github.com wrote:

From a user experience design methodology - which is where I come from -
"implement both" not ideal.

While a systematic shutdown process is proper for Linux users, the target
audience for Stratux is not a Linux user, or even a computer user.

We should not consider the Stratux as a "computer" and thus we should not
apply computer methodology when choosing the best experience for Stratux.

My car radio "system" is really a computer but I do not have a shutdown
sequence for it. I just turn off the ignition.

The Stratux is targeted at a pilot, flying an airplane. We want to
minimize their workload.

—
Reply to this email directly or view it on GitHub
#43 (comment).

[jpoirier]

On Wed, Sep 16, 2015 at 4:52 AM, bradanlane notifications@github.com
wrote:

From a user experience design methodology - which is where I come from -
"implement both" not ideal.

As a user-which is where I'm coming from-"implement both" is ideal.

The Stratux is targeted at a pilot, flying an airplane. We want to
minimize their workload.

Lol Using the shutdown button would be opt in... But if bringing up the web
page on the device you're already using and tapping a shutdown button
significantly increases your workload in any conceivable way you probably
shouldn't be flying a plane-for reals.

[bradanlane]

What I may not have been articulating very well is that I believe "not needing a shutdown button" in the WebUI is preferable to needing one. Implementing a shutdown button in the WebUI takes off the pressure to making the system stable enough to not need one.

[cyoung]

Both points are valid - but let's not get too wrapped up in the shutdown button. It's important but in (I think) 1k+ installs I know of two cases of SD card corruption. There are issues right now that are occurring more often than SD corruption, so we might be better off focusing on those first.

[lastdeadmouse]

Though I'm sure the rate is actually my much higher than reported (I've lost 2 myself), I agree that there are more important issues. The first thing I do now is make my card read only anyway.

[bradanlane]

Do we have the necessary pull request available for "read only" mode and if not, @lastdeadmouse, is your method something which could be incorporated into the master stream?

[lastdeadmouse]

It's not something I would incorporate using spindle, as that is intended to provide more of a base installation image. It would be better suited for a preset image distribution. That said, it would be possible to incorporate unionfs ,using something close to http://blog.pi3g.com/2014/04/make-raspbian-system-read-only/ as a base. That tutorial is almost exactly what I do, I just never clean up the logs.

When ever I want to make a change, I just "mount -o remount,rw /" or "/boot" depending on what I need to change. It's sort of the standard for editing any ro linux filesystem, as most of us Android guys know ;)

[bradanlane]

Interesting. On a 2014 project I did similar to Stratux, I used a solution similar to that described here ...

https://www.raspberrypi.org/forums/viewtopic.php?p=213440

... without step #6. This does not use unionfs. I then added two script command files (raspi-ro & raspi-rw) which were nothing more than the same remount commands you described.

[lastdeadmouse]

I used unionfs-fuse on another project a while back to accomplish pretty much the same goal on a kiosk which is really why I went that route. Either way, with a good RO solution, running from ramdisk, it is faster, safer, and needs nothing more than a pull of the plug (or an inline on/off switch on the power cable). I don't like the idea of potential filesystem corruption resulting from power outage/issue possibly causing an issue when I'm in the air, or corruption that goes unnoticed until it doesn't.

As for a separate remount script, it's still one command to issue one command. I guess to me it's like bananas in individually wrapped packaging.

[bradanlane]

I created the two scripts because I was shipping the turnkey using a to mostly noobs. It was easier to write a cheat sheet that didn't expose too much Linux :-)

[cyoung]

• Mode S code for ownship

[cyoung]

• Traffic target list - select ownship (for non ADS-B Out aircraft being tracked as a TIS-B target).

[cyoung]

• Tower list and signal level (0-150%).

[bradanlane]

What is all available data related to a tower which we could work with?

Eg: time last received, ID, lat/lon, messages received, etc.

How is signal strength determined?

Do we know how how many messages we were able to process correctly vs those which were corrupted?

I'm not suggesting we display everything possible but, by knowing what is possible, we can decide what combination makes sense and how to organize and visualize the available information.

On Sep 21, 2015, at 8:49 PM, cyoung notifications@github.com wrote:

Tower list and signal level (0-150%).
—
Reply to this email directly or view it on GitHub.

[cyoung]

lat/lon, messages received (or message rate), time last received, time receiving, types of messages received (ping/radar/METAR/TAF/winds aloft/other), distance (if gps enabled), signal strength.

Signal strength is the average (scaled) amplitude of the signal received, averaged over each UAT message.

We know how many messages were identified as UAT frames but thrown out for errors otherwise. Don't know how many UAT frames are partially received. Not a good metric IMO.

[bradanlane]

thanks. UAT messages received vs 'thrown out' is what I was trying to ask about.

As for signal strength, I'm still a bit confused. what does "100% strength" mean? It seems what we have is "average relative signal strength". Based on the description, it would seem like two identical systems - one circling 10nm from a tower and the other circling 30nm from the same tower, would both compute the same relative signal strength.

Am I understanding this correctly?

Depending on what we really have for signal data, labeling and displaying it will be different.

[bradanlane]

The next pull request of the WebUI will - thus far - include the following:

• UI for setting PPM for up to two SDRs (is there a way for the WebUI to know how many SDRs there are? if not, I will use the status of UAT_Enabled and ES_Enabled)
• WiFi SSID (default will be "stratux")
• toggle for logs (initially it will be all logs: es, uat, gps, ahrs, and main)

If someone can implement the back-end, then I can add the following "streams":

• active traffic list
• weather messages
• active tower list
• AHRS pitch/roll/heading/altitude, other (?)
• GPS lat, lon, altitude, ground-speed (?)

for the streams the client will have separate screens and can either poll for the data or will need to signal the backend to start/stop pushing those messages. (I can do either based on your suggestion).

[lastdeadmouse]

For retention of logs in RO mode, a decent method may be a custom shutdown
script which remounts and copies logs to a writable partition. Would still
protect against corruption during normal use, but if you'd like to debug,
manually shutdown to capture logs.

On Mon, Sep 21, 2015 at 7:42 AM, Kris Knigga notifications@github.com
wrote:

Off the top of my head I can't think of any good way to do it. Any writing
risks corruption in the event of an unclean shutdown while writes are in
flight.

I'll do some research today.

@kdknigga https://github.com/kdknigga - any suggestion for keeping the
fs
RO while allowing for logging?

I momentarily thought we could log to ram disk and periodically push to SD
but if we are looking for a system lockup or other failure, the "push"
might not happen. Perhaps the push could be a cronjob?

(I'm tossing stuff out looking for suggestions)

—
Reply to this email directly or view it on GitHub
#43 (comment).

—
Reply to this email directly or view it on GitHub
#43 (comment).

[cyoung]

• Settings tooltips - explain all settings that aren't self-explanatory like "Traffic Source".

[bradanlane]

I concur. I'll make sure the layout provides for descriptions and/or more detailed prompts.

On Sep 24, 2015, at 10:45 PM, cyoung notifications@github.com wrote:

Settings tooltips - explain all settings that aren't self-explanatory like "Traffic Source".
—
Reply to this email directly or view it on GitHub.

[224XS]

I'd like to take a whack at a traffic back-end. I did a traffic "cockpit view" for an OS X backend to dump1090 a couple of months ago and I thought the schematic pilot view had some promise:

[224XS]

For traffic stream application, what do you think about streaming via Server-Sent Event protocol as opposed to polling?

[ssokol]

Hmm... Why not just use the websocket? It's fast; there's support in all
browsers for it; it can handle multiple data types; there are libraries for
support available for all major languages / frameworks. SSE isn't available
in the Microsoft browsers. It's also not as widely covered in non-browser
environments.

On Tue, Sep 29, 2015 at 8:36 AM, 224XS notifications@github.com wrote:

For traffic stream application, what do you think about streaming via
Server-Sent Event protocol as opposed to polling?

—
Reply to this email directly or view it on GitHub
#43 (comment).

Steven Sokol
408 Camelot Drive
Liberty, MO 64068

mobile: +1 816-806-8844
fax: +1 816-817-0441

[cyoung]

@224XS - seems nice, but would be ideal to have an alternative for users that don't have the external GPS.

[224XS]

I guess I was thinking that there is no need for full duplex comms, so no absolute requirement for the extra complexity. Firefox, Chrome, Opera and Safari support SSE. Im not a windows guy, but I heard IE died a long time ago on mobile. I'd certainly change my thinking if IE is still a major player in the space where FF and WingX play.

As for non-browser apps. A browser is likely to already be available and open (for the Stratux UI page).
Non browser apps can get more featured, like my example above, but where possible, one trick pony apps for pilots seem to make sense. Im perfectly happy to work outside my own box however.

[224XS]

@cyoung : two thoughts bat your comment:
Of course we should not leave anyone out. The target table like the pic, would work simply. No sorting by distance though.
Most display devices except the cheapest iPads have internal GPS. If there were no GPS (int or BT External) the Moving maps in WingX or FF would not function. Might be "interesting" though to access the Location Manager or equivalent from JS in browser.

[bradanlane]

@224XS - I'd suggest we standardize on REST getter/setter for forms data and anything that is not dynamic; websocket for anything that is streaming. It simplifies initial coding and long term maintenance. (unless there is a significant advantage to SSE.)

[224XS]

OK, seems there is a consensus re websockets! Works for me.

Assuming we proceed, should be stream the maximal data set for each target, or just ICAO, position, course, speed, and altitude?

More is always good, but bandwidth and cpu have a say. I don't have a great feel for the load on the RaspPi and older display devices while running Stratux and FF etc. I think the flight track non-pilot hobbyists want it all (equipment type, etc.) but in flight it is hard to display it all without clutter. Maybe a display modal system. In my previous app, it was tough enough to fit just the flight relevant data into a table that fit the screen. My first instinct is to go for displays that increase situational awareness in the flight environment.

[ssokol]

I definitely agree with the "less is more" sentiment here. I want to
clearly see where traffic is - I don't really care if it's a 2 pound drone
or a 747.

I would want to see altitude as digits - perhaps color coded depending on
how close it is to ownship altitude. Course should be graphical - the
standard pointer icon. I think speed is best displayed with a track line
indicating where the target will be in 1 minute. (The actual speed value
doesn't tell you much unless you perform math in your head.) N-number /
call sign helps correlate what you see with what you hear from ATC.

Anything else should be a dril-down. Tap / click the target and it pops up
whatever additional data is available.

On Tue, Sep 29, 2015 at 9:20 AM, 224XS notifications@github.com wrote:

OK, seems there is a consensus re websockets! Works for me.

Assuming we proceed, should be stream the maximal data set for each
target, or just ICAO, position, course, speed, and altitude?

More is always good, but bandwidth and cpu have a say. I don't have a
great feel for the load on the RaspPi and older display devices while
running Stratux and FF etc. I think the flight track non-pilot hobbyists
want it all (equipment type, etc.) but in flight it is hard to display it
all without clutter. Maybe a display modal system. In my previous app, it
was tough enough to fit just the flight relevant data into a table that fit
the screen. My first instinct is to go for displays that increase
situational awareness in the flight environment.

—
Reply to this email directly or view it on GitHub
#43 (comment).

Steven Sokol
408 Camelot Drive
Liberty, MO 64068

mobile: +1 816-806-8844
fax: +1 816-817-0441

[bradanlane]

@cyoung - from your original list, you mentioned PPM. I have ability to set the PPM. Are you suggesting there is a way from the UI to run Kalibrate on Stratux and get back the results?

[ssokol]

That reminded me of something else that should be in the UI: AHRS
calibration and offset control. At the very least, we need a way to tell
Stratux "ok, we're level now". It's also useful to be able to manually
adjust the pitch and roll values.

On Tue, Sep 29, 2015 at 9:31 AM, bradanlane notifications@github.com
wrote:

@cyoung https://github.com/cyoung - from your original list, you
mentioned PPM. I have ability to set the PPM. Are you suggesting there is a
way from the UI to run Kalibrate on Stratux and get back the results?

—
Reply to this email directly or view it on GitHub
#43 (comment).

Steven Sokol
408 Camelot Drive
Liberty, MO 64068

mobile: +1 816-806-8844
fax: +1 816-817-0441

[cyoung]

PPM can be set now with in the globalSettings struct and is used. No, there isn't anything to do it automatically. Some people are using SDR# and such to do it. There isn't any AHRS calibration code hooked to something that can be triggered by the web interface easily at this point.

[bradanlane]

These are all good suggestions and a good discussion. Two suggestions:

• can we organize these somewhere and optionally vote up/down a priority so these get worked on in some order and we dont lose things
• there is a bunch of back-end work associated with these. It's not "just UI" :-)

[bradanlane]

@cyoung - yes, I already have PPM working from the new WebUI. I had to use a different JSON syntax since all the prior settings were bool and I needed an int to work with the current sdr code.

[bradanlane]

@cyoung - "tool tips" are not a common construct for mobile apps because there is no "hover" event and having help text "in line" really expands the interface.

In pull request #67 I have implemented context sensitive help pages. They are accessed from the help button in he upper right and either "slide in" for small screens or "push in" for larger screens.

[cyoung]

v0.4r1 todo

• Ownship Hex (ae37369)
• /getTowers integration
• Traffic display
• Weather display
• Logs display
• Replay log on/off otf (me)

future

• Receiver calibration
• GPS display
• AHRS display
• AHRS calibrate
• WiFi SSID (this is less useful now - or maybe useless - as FlyQ is the only one that needed it and config workarounds are used now)

[rgutlon]

v0.4r1 Weather Watch List Bug

• Settings -> Configuration -> Watch List
  • Once you add entries into this field they cannot be removed. You can append entries to the list, but backspacing over existing entries has no effect (ie the change is not being written to /etc/stratux.conf).

[bradanlane]

let me look at (and fix) that

[bradanlane]

I'm moving this to its own issue since you are reporting a bug - #72

[bradanlane]

I think this thread has run its course. Thanks for all the input. If you have future suggestions, please create a new issue for you specific idea.