search

cyoung / stratux

Aviation weather and traffic receiver based on RTL-SDR.
BSD 3-Clause "New" or "Revised" License
1.06k stars 365 forks source link

Web interface additions #43

Closed cyoung closed 9 years ago

cyoung commented 9 years ago

Others?

bradanlane commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

Should we add a button for shutdown?

heelix commented 9 years ago

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 https://github.com/cyoung/stratux/issues/43#issuecomment-140520559.

bradanlane commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/cyoung/stratux/issues/43#issuecomment-140541159.

lastdeadmouse commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/cyoung/stratux/issues/43#issuecomment-140691585.

jpoirier commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago
cyoung commented 9 years ago
bradanlane commented 9 years ago

Can you give some more detail for what you mean by "Mode S code"? What does this do? What problem or feature does this address?

Same questions for "traffic target list"?

bradanlane commented 9 years ago

Back on the subject of RO mode ...

Stratux beta releases have a growing need to capture logs. We should consider have a separate partition for logs so they can be RW.

kdknigga commented 9 years ago

I'm not sure that will help anything. A writable filesystem will still create risk for corruption. On Sep 21, 2015 06:11, "bradanlane" notifications@github.com wrote:

Back on the subject of RO mode ...

Stratux beta releases have a growing need to capture logs. We should consider have a separate partition for logs so they can be RW.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/43#issuecomment-141944016.

bradanlane commented 9 years ago

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

kdknigga commented 9 years ago

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 https://github.com/cyoung/stratux/issues/43#issuecomment-141947637.

cyoung commented 9 years ago

Can you give some more detail for what you mean by "Mode S code"? What does this do? What problem or feature does this address?

It's for ADS-B Out equipped aircraft - FF (or other app) to identify the "ownship" and not show it as traffic.

ssokol commented 9 years ago

IRT the logging question:

I've built similar Pi-based systems that log to either a file in a ramdisk or to a fixed-size in-memory data store (Redis). The data was occasionally (every 5 minutes, IIRC) persisted to a USB flash drive that was mounted, written to, then unmounted. Pulling the plug without running the shutdown routine cost you the last 0 - 5 minutes worth of data but never killed the SD card or the USB drive.

I wonder if you couldn't do the same thing without the flash drive by creating a small partition on the MicroSD. Rather than running the default "expand filesystem" script, the first boot would create a "DATA" partition that could be used for persisting logs.

cyoung commented 9 years ago
bradanlane commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

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

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 commented 9 years ago

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 https://github.com/cyoung/stratux/issues/43#issuecomment-141947637.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/43#issuecomment-141961977.

cyoung commented 9 years ago
bradanlane commented 9 years ago

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 commented 9 years ago

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:

adsbsample

224XS commented 9 years ago

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

ssokol commented 9 years ago

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 https://github.com/cyoung/stratux/issues/43#issuecomment-144060325.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

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

cyoung commented 9 years ago

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

224XS commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

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.