stratux-uat.log - 107MB

Took a trip from Seattle to Sacramento this weekend, about 5 hours each way. Had a couple instances of the 0 altitude issue; I also had an issue where ownship would get stuck at 4000-odd feet, which screws up nearby traffic altitudes (at 8500, aircraft on the ground at 500msl show as -35, ish).

Otherwise, worked fantastically throughout. Only really lost ADS-B briefly north of Portland; the rest of the trip we had 1-5 towers in view. GPS was pretty much rock solid, even with an unconfigured 1hz rate!

I've run the Kalibrate utility against the two SDRs in my setup. I have measurably different results for the two SDRs.

If others are seeing a similar result then should we allow users to set PPM for each SRR?

I suspect we only set it in the first since that is the one used for UAT and thus more critical - correct?

If we feel PPM will not provide an improvement on the 1090ES receive, then the resolution is to improve the help text for PPM to explain this to the user.

It'd be nice to set the default keyboard layout to US in:

/etc/default/keyboard

XKBLAYOUT="us"

For the latest master branch (as of 8/24 0630Z) targets in WingX appear with a nonsense name "uuuuu" above it. What is interesting is each target has a different number of u's in the name as seen in the screenshot. (This screenshot was with the dump978 sample data, but I've observed this with real signals too. Don't have Foreflight so couldn't test with it.) With release v0.1r2, there was nothing at all displayed above the traffic. Using an original Raspberry Pi and compiling everything from source (ARM6).

 cb transfer status: 1, canceling...

 Library error -5, exiting...

Probably related: antirez/dump1090#33

While it may not be used extensively once we get Stratux to a "release" level of capability, it would be useful and get users to stay engaged with the project if the WebUI had the option to show data such as:

• current tracking aircraft (aka, ones we have heard from in teh past 60 seconds) - the WebUI would display a list with tail number, lat, lon, last time received, etc.
• weather messages - display a list with type, date/time, location (likely ICAO or FAA identifier), and content
• other ?

I can easily integrate this into the new WebUI 'app' if someone can provide the data from teh backend via the socket layer.

I ran Wireshark on my desktop to capture the IP traffic from stratux running on a Raspberry Pi 2. I was expecting to see a heartbeat packet every second; however, it appears that there is a lot of jitter in the heartbeats. It is not uncommon for multiple seconds to elapse between heartbeats.

I don't know much about go; however, looking at the code I'm guessing that either there is some sort of locking issue on outConn on line 273 or the other functions called in the heartbeat loop (lines 275 - 279) are taking up significant time.

Link to the relevant pcap file: https://dl.dropboxusercontent.com/u/1897140/stratux.pcapng

It would be quite useful if the Golang development stack came preinstalled on releases - at least any alpha / beta releases. The software is already available in /root/stratux. If would be convenient if that could be edited, compiled and deployed without having to connect the device to the Internet and manually install the development tools.

Alternately, we could include a script to quickly install the necessary software.

The Weather page in the new WebUI needs more user control than other areas of the web experience.

While the Traffic page will typically see a handful of active targets at any one time and targets come and go within a few minutes, Weather is a different story.

I did a small sampling of pilots and came up with a couple suggestions.

• separate METAR+TAF, PIREP, WINDS, ???? into sections so the user is looking at one section at a time
• limit METAR+TAF to a user configurable watch list

I'm interesting in more feedback.

I've done another all-day test, this time with 0.3b4 stock. It was running with a single R820T2 and a RY835AI. UAT, GPS and AHRS were enabled.

The system was started at 13:05 and continued to log until 18:17, so just over five hours. The Stratux web UI stopped updating the "Uptime" value after 2 hours, 25 minutes which roughly correlates with the time that ForeFlight stopped displaying GPS and ADS-B information and lost the "FreeFlight" data feed. The "Stratux" data feed remained and continued to provide attitude and altitude until the experiment was terminated.

As seems to be the case when this occurs, memory usage was very high. I was able to log in and capture memory usage, CPU, etc. (see below) but was unable to successfully kill the gen_gdl90 process. Attempting to do so - first by attaching to the screen session and issuing a Ctr+c, then using the kill command - left the process defunct but still resident in memory. I attempted a clean shutdown using "poweroff" but the system hung during the shutdown.

Stratux.log is available here: https://gist.github.com/ssokol/34a6eca6b9d0016640c0

The other Stratux logs are available if you need them.

Problem statement:

GPS position accuracy is hard coded as NACp = 11 (0xb) in gen_gdl90.makeOwnshipReport() . ForeFlight thererfore reports accuracy as 3m any time a valid ownship GPS position is received, regardless of actual accuracy.

Solution

• Update ry835ai.go to extract DGPS status from the GGA message, then calculate and output an NACp value based on HDOP, type of nav solution, and possibly number of satellites.
• Update ownship msg[13] to use variable NIC = 0, and the variable NACp value from updated ry835ai.go
• Correlation between NACp, HDOP, type of navigation solution, and number of satellites received is TBD

Additional comments
ForeFlight appears to be using accuracy estimates based on the ownship NACp value. Any value less than 8 will show as "Poor". Values of 8 or greater will show a position estimate of (IIRC) 100m, 30m, 10m, or 3m per the table below.

Getting a decent Estimated Position Uncertainty (EPU) may be a challenge. EPU is "defined as the radius of a circle centered at the true horizontal position within which the measured horizontal position lies with 95% probability". In other words, the 2σ horizontal position variation. This can be calculated readily for a GPS receiver in a fixed location.

The NMEA messages include HDOP (horizontal dilution of position), which indicates the uncertainty of the measurement due to the geometry of the satellites used for the position solution. However, this does not account of other error sources (multipath, clock error, atmospheric effect, etc.)

I think that combining the presence / absence of DGPS (i.e. WAAS) along with HDOP may get us close. I'm running a series of long (i.e. 8+ hour) evaluations with the GPS module located in one position to calculate total position variation for multiple conditions (5, 8, 12 satellites with / without WAAS, and with / without GLONASS) to get a baseline. I'll update this issue with my test results as they complete.

I also think we should report NIC = 0. This is an intergrity / containment measurement of "trust" in the GPS system. It's relevant for traffic separation, but not for evaluating the performance of the raw position data. ForeFlight doesn't seem to use it, so it would make sense to drop it.

The GPS serial port for the RY835AI can be connected via USB or GPIO UART.
Add GPS serial port config to stratux.conf to allow switching between the two ports without recompile of RY835AI.go.
Default to /dev/ttyACM0 (USB).
Suggested code updates:

gen_gdl90.go
line 374 add
GPS_Input serial.Config
line 448 add
globalSettings.GPS_Input = serial.Config{Name: "/dev/ttyACM0", Baud: 9600}

RY835AI.go line 54
serialConfig = &globalSettings.GPS_Input

Just checking :)

1. What determines when the Wi-Fi icon is displayed (top left)? My home network shows it when connected, but stratux doesn't.
2. Any difference with newer hostapd versions?
3. Any difference with another adapter?
4. Any difference with Wi-Fi Assist OFF (Settings -> Cellular Data -> Wi-Fi Assist)?

The last tab in the WebUI with nothing yet created is the Logs tab.

How do we see logs being used and what would be most useful to enable for users to assist with that use?

Not sure if it is happening in other apps.

Restarting the app works for me, but some users are reporting that restarting the app doesn't fix the issue.

TravisCI (travis-ci.com) provides free continuous integration services to open source projects.

It would be beneficial to set this up for the Stratux project, as it ensures builds and tests succeed on commits, pull requests, etc. Setup requires the the repository owner to log into TravisCI and enable support for the repository. Then, a .travis.yml file needs to be added to the repository to specify how to build and test the project. Instructions are at http://docs.travis-ci.com/user/getting-started/ .

@cyoung - if you are interested in getting this setup, log into TravisCI and enable support, and I'll create a pull-request adding the appropriate .travis.yml file.

I’d like to suggest we re-establish a model-view-controller (MVC) architecture. The implementation of this MVC would be to re-introduce an HTTP server and PHP. The HTTP server handles the “view”, PHP handles the “controller”, and the existing socket layer handles the “model” (aka data). There are three reasons for this:

• We off load business logic, data conversion, and most error handling to the controller. We reduce, to a minimum, any work load for the ADSB engine.
• We enable non-data-centric operations such as log management, log interactions, error reporting, etc. with no impact on the ADSB engine. We also are able to accomplish tasks which manipulate the engine such as administration, system start/stop, and update.
• We make it easier for the various developers to contribute their area of expertise with minimal impact on others. We also reduce the complexity of pull-requests and merges because the code is better insulated.

The lightest implementation I recomend is lighttpd with php5-cgi for the view and controller. We would change the http port of the socket interface to something other than port 80. Most of the controller code is currently being forced into JavaScript.

Separation to MVC will add flexibility for alternative front-ends. It will simplify starting with upgrading the WebUI and then adding platform Apps for iOS and Android when need and resource allow.

As part of this transition, we can consider breaking up some of the model interfaces for performance reasons. For example, the current model has “settings” separate from “status”. This is perfect. However, the “status” could be reduced to only contain “system status”. Then we can create one or more interfaces for details such as METARs, winds, message types and counts, etc.

The GDL 90 data interface specification document is fairly specific to Garmin boxes, so there is some interpretation to be done when applying the spec to other hardware.

Currently, stratux sends an Initialization message every second. It seems to me that stratux plays the roll of the Garmin GDL 90 itself. In that case, according to Table 2 on page 9 of the specification, it should consume not produce Initialization messages.

Section 3.2 says "The Init message is sent by the Display once per second, and is described in Table 4." Statux does not seem to fill the role of a "display"; furthermore, the flags in the initialization message do not seem like items one can reasonably expect stratux to set.

I very well could be missing something, but it seems to me that stratux should not be sending Initialization messages.

I have a Raspberry Pi 2 Model B. The right wifi.

I put the latest image on the SD card and boot. When I connect a HDMI cable and monitor to see what is happening. It boots up and goes to the Raspberry Pi Config page.

I can't access the web page. I see nothing in fore flight when I connect to the stratux wifi which works.

What is wrong?

I also see no log fixes on the SD card nor an ETC directory. Only directory is Objects.

I also can't SSH to the device.

Disregard. I don't have the Pi 2. I have the Pi + B.

Received my RY835AI yesterday and have it connected and working. On the bench, in ForeFlight, the compass / DG indicator continuously drifts in a circle and the SynVis display appears to orbit around the PoV as if the aircraft was in a continuous right turn. It appears to be turning at about 2 - 3 degrees per second. In the absence of a track value from the GPS, is the heading being set by the magnetometer? If so, wow does it drift.

Please let me know what logs / data I can attach that may help answer this.

I have a Pi Kit that uses another wifi adapter that I would like to use for this project. www.canakit.com.

Is it possible to add the drivers for other adapters to the image?

07:42:44.279269 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:44.478652 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:44.722414 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:44.884646 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:44.969908 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:45.078377 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:45.278579 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:45.478433 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:45.678527 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:45.879260 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:45.969995 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36
07:42:46.078459 IP 192.168.10.10 > 192.168.10.1: ICMP 192.168.10.10 udp port 43211 unreachable, length 36

FF control messages:

wake

07:40:46.828028 IP (tos 0x0, ttl 64, id 20545, offset 0, flags [none], proto UDP (17), length 88)
    192.168.10.10.50113 > 192.168.10.255.50113: [udp sum ok] UDP, length 60
        0x0000:  4500 0058 5041 0000 4011 93fa c0a8 0a0a  E..XPA..@.......
        0x0010:  c0a8 0aff c3c1 c3c1 0044 5f80 fffe 6900  .........D_...i.
        0x0020:  2d00 6300 6100 6e00 2d00 7000 6c00 6100  -.c.a.n.-.p.l.a.
        0x0030:  7900 2d00 6600 6600 6d00 2d00 7500 6400  y.-.f.f.m.-.u.d.
        0x0040:  7000 3a00 2b00 3a00 2d00 3a00 3d00 3a00  p.:.+.:.-.:.=.:.
0x0050:  6900 5000 6100 6400                      i.P.a.d.

sleep

07:40:43.118753 IP (tos 0x0, ttl 64, id 29141, offset 0, flags [none], proto UDP (17), length 72)
    192.168.10.10.50113 > 192.168.10.255.50113: [udp sum ok] UDP, length 44
        0x0000:  4500 0048 71d5 0000 4011 7276 c0a8 0a0a  [email protected]....
        0x0010:  c0a8 0aff c3c1 c3c1 0034 09a2 fffe 6900  .........4....i.
        0x0020:  2d00 6300 6100 6e00 6e00 6f00 7400 2d00  -.c.a.n.n.o.t.-.
        0x0030:  7000 6c00 6100 7900 2d00 6600 6600 6d00  p.l.a.y.-.f.f.m.
        0x0040:  2d00 7500 6400 7000                      -.u.d.p.

active (every 10 sec)

07:40:46.827974 IP (tos 0x0, ttl 64, id 16702, offset 0, flags [none], proto UDP (17), length 74)
    192.168.10.10.50113 > 192.168.10.255.50113: [udp sum ok] UDP, length 46
        0x0000:  4500 004a 413e 0000 4011 a30b c0a8 0a0a  E..JA>..@.......
        0x0010:  c0a8 0aff c3c1 c3c1 0036 c29d fffe 6900  .........6....i.
        0x0020:  2d00 7700 6100 6e00 7400 2d00 7400 6f00  -.w.a.n.t.-.t.o.
        0x0030:  2d00 7000 6c00 6100 7900 2d00 6600 6600  -.p.l.a.y.-.f.f.
        0x0040:  6d00 2d00 7500 6400 7000                 m.-.u.d.p.

Sorry for the utterly vague subject line on this. I've been trying to nail it down to a specific pattern but so far it seems to be just that - vague. I'm running the image from v0.3b4 but with the latest code pulled from Github. System has either single or dual SDRs and an RY835AI. Tried on two different Pi units with a combination of three different SDR dongles. Only have one RY835AI, so that is common across all tests.

Here's the fact pattern as I've seen it:

• Happens in as little as 5 minutes or as much as an hour
• The "FreeFlight" device disappears from ForeFlight
• The "Stratux" device is still showing as connected
• AHRS and baro altitude functions continue to work in FF*
• GPS and 1090 ES functions stop working ("No Fix" and all traffic disappears)
• The uptime counter stops in the admin UI
• I SSH in and check, and gen_gdl90 is still running
• free -mh shows no indication of a memory leak
• It continues to dump data to the stratus.log file including an uptime value
• Log memory values remain consistent at Alloc = 5 - 10mb, Sys = 17mb
• If I try to kill it either with Ctrl+C in the screen session or using kill -9, it becomes 'defunct'
• Unable to cleanly reboot - hangs and requires a hard reset
• If the thread (?) has not yet hung, I can cleanly kill the process and I can cleanly reboot

I've tried multiple power sources, all rated at 2.1 amps and above. I've changed power cables. The rig is not in a case, so it's not heat. Here's the kicker - when I unplug the RY835AI and turn off GPS / AHRS, it doesn't seem to happen. I'm running it overnight to see if that holds true for a really long run. If it fails, I'll update this issue with the log files.

Is anyone else seeing this on the current version of the software?

dhcpd changes file but no notification event is triggered.

FlyQ 2.1 was released the day before yesterday and it's not working (again) with stratux.

Some may recall FlyQ doesn't allow users to select the ADS-B device ... they attempt to automatically connect based on protocol or some other variable.

Under FlyQ 2.0 CYoung determined changing the SSID to NavWorxWIFI was the solution ... and it worked! But reports are coming in this is not working with either stratux v0.3b3 or v0.2r1 and FlyQ 2.1. Same behavior as before ... immediate (and repeated) connect and disconnects from the ADS-B device. A bit disappointing as a number of us wrote Seattle Avionics and were under the impression this would no longer be an issue in this release.

Thought I would mention this here in case someone sees an easy workaround on the backend.

https://www.reddit.com/r/stratux/comments/3iv2zk/flyq_efb_stratux_not_working/cve3tsq

Pi USB hub issues.

Howdy. Here's a video that best exhibits the issue I'm having: https://youtu.be/Cqjrd-AVHYw

The screen grab is from my Galaxy S4 but the same exact glitch happens in my Ipad 2 3g , but I don't know if that's sufficient evidence to say the stratux is culprit.

Basically, if I'm not in range of a GBT and picking up raw 978 from airborne aircraft, I'll have 2 targets for each plane following/right on top of each other, one will show whatever the plane is squawking (ie 1200) and the other the actual tailnumber for the aircraft. Haven't tested with 1090es yet (trying to figure how to enable that still pardon the noobness).

This came up in a Reddit thread but I'm not sure it was really fleshed out. I've had some 978 and 1090 antennas made (hopefully will be here this week then I can get them out to everyone). Since they are tuned to each respective frequency, it would be good to bind the UAT and ES processes to the correct receivers. Has anyone determined if there is a way to detect which one is which, and bind the process to one or the other? Is one USB port always the lower numbered one?

I'm hoping that the log file is persistent across shutdowns, as I flew for about 90 minutes, shutdown, drove home, powered up and grabbed this log.

No known crashes. About halfway through the flight the ForeFlight display did show 'o' for aircraft altitudes. Selecting the target did show the correct altitude. I've attached a screen shot in addition to the UAT log.

Here is the zip'd up log file: https://dl.dropboxusercontent.com/u/2506999/stratux-uat.log.zip

Was in a car within a few miles of DFW airport. Unfortunately I did have both 978 and 1090 enabled. When the unit gets in this state, the web page no longer responds, and the unit stops responding to Foreflight (however it is still showing connected via wifi).

I power cycled the unit twice in the same location, and in both cases within two minutes the system had locked up again. I have only seen this occur in very high traffic areas.

I also noticed before the system locked it had received about 800 Unknown UAT traffic type messages (I believe it was type 9999).

Here is the UAT file

I have the ES logs as well, but they are 192MB.

First, thanks for this fantastic project. Now have wx in the Glasair.

I just downloaded v0.4r2. I notice its .img is 1GB smaller than previous releases, even tho the zip file is same as others. (I dnld'd & decompressed it twice.) It boots quickly, but it never makes the wireless WiFi blink. No stratux SSID either. Is it just me or is there something missing from the image?

I get gps via pin or USB, I get AHRS in foreflight,
but in wingxpro I can see the embedded AHRS status is green but on the synthetic vision page I get NO AHRS and no input.
I have tried changing the port in the stratux.conf per the flyq directions and that made no difference

I'm having trouble building the go code...I get the following on raspian:

GOARCH=6 go-linux-arm build gen_gdl90.go traffic.go ry835ai.go
/bin/sh: 1: go-linux-arm: not found
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 127

If i just run go build gen_gdl90.go traffic.go and ry835ai.go i get:

github.com/tarm/serial

/usr/lib/go/src/pkg/github.com/tarm/serial/serial_linux.go:114: undefined: syscall.TCIOFLUSH

github.com/kidoman/embd

/usr/lib/go/src/pkg/github.com/kidoman/embd/detect.go:58: undefined: strings.TrimSuffix

Any ideas?

Thanks!
Felix

I (and others, mostly on Reddit) have occasionally gotten a bit confused about the state of various features, especially AHRS. I've got a pretty good read on project status now, but I know others still aren't clear on things.

Might help avoid confusion if there was a list of things that work, mostly work, are in progress, on the roadmap but unstarted, that sort of thing.

UAT uplink messages perhaps?

Assume I power up Stratux at 09:00, then turn it off at 12:00 (noon), and finally power it up again the next day at 09:00. I get different results based on how I turned Stratus off.

If at 12:00 I pull the power from Stratux, then on the "next day" the UPTIME starts at 00h00m00s.
If at 12:00 I SSH to the device and execute "shutdown now" then on the "next day" the UPTIME starts at 24h00m00s.

It is as if a controlled shutdown somehow preserves the original start time.

I know this has been discussed ad nauseum on previous issue, but I've seen enough requests that it's probably worth collecting thoughts in one place.

Background

The Raspberry Pi is not a traditional embedded system. It's a full Linux computer system on a very small board. Like all Linux systems, the Pi normally requires an orderly shutdown to prevent data loss and filesystem corruption. If the power is pulled in the middle of a write operation, bad things (tm) can happen, including a complete corruption of the system. This is always painful, but it is particularly painful in an avionics system.

Stratux Read Only Requirements

1. Store DHCP lease information. This data does not need to be persistent between reboots.
2. Store the stratux.conf configuration data. This data does need to be persistent between reboots.
3. Store log files when logging is enabled. This data may need to be persistent between reboots.

[Please add other requirements here.]

Strategies For Read Only Operation

1. Remove unnecessary stuff that tries to write to the filesystem:
   1. dphys-swapfile
   2. other packages?
2. Replace the default syslog system with the BusyBox syslogd which writes to memory
3. Use tmpfs (ramdisk) for:
   1. /tmp
   2. /var/tmp
   3. /var/log
   4. /var/lib/dhcp
4. Disable fsck by appending "fastboot" to the /boot/cmdline.txt file
5. Disable swap by appending "noswap" to the /boot/cmdline.txt file
6. Force read-only file access by appending "ro" to the /boot/cmdline.txt file
7. Add an "ro" and an "rw" script to "/usr/bin" to allow advanced users to easily switch between read-only and read/write modes.

That handles the basics. I've done some experiments with this and it seems to work with a small tweak to the isc-dhcp-server init file (have to add "touch /var/lib/dhcp/dhcp.leases" before you start up the server).

What this doesn't handle are:

1. Creation of and edits to /etc/stratus.conf made by the UI
2. Log file persistence

My personal thought on that is to create an additional small partition as part of the image. Something like 500 mb to 1 gb. Format it with something that can be read by any computer (i.e. FAT32). When Stratux boots up it checks to see if it can mount this partition. If so, great - it mounts it and uses it for the configuration file and for logging. If it can't mount / read / use the filesystem it uses the format command to recreate it. It then writes a default stratux.conf and alerts the user through the GUI that the configuration was recreated and needs some attention. (The stratux.conf config data can easily be cached on the browser in localStorage, making replacement trivial.)

A variation on this theme:

Mount the config / log partition read only at boot. Remount it read/write when necessary to update the configuration or to copy log data from memory to the filesystem. Have a log rotation feature built into Stratux that handles this so that every minute or so the log data gets saved. This minimizes the chance of data loss.

Experience

I've tested the first part of this scenario and it seems to work. I have yet to try the additional partition. I'm not sure how much complexity that adds to the spindle configuration that is currently being used to build images.

I will attach the scripts that I've been using to this issue in case anyone wants to try it out.

Running v0.3b2 I seem to be having some kind of intermittent problem accessing the GPS. The process starts and other features (1090ES, AHRS, baro altitude) appear to work, but I never receive a GPS location and the web console shows 0 satellites. If I kill all processes and restart the stratux service, then the GPS works. The RY835AI is indicating a solid fix (red blinking GNSS LED).

Here's the log: https://gist.github.com/ssokol/0e417e9b0ded417d5fc5

(reported by @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).

Configuration:

• Stratux 0.3b1 from most recent image (except with hostapd v2.4 rebuilt from w1.fi git repository)
• Dual NooElec RTL-SDR
• RY835AI module on USB connection
• ForeFlight 7.2 (iPad) and ForeFlight 7.3 (iPhone)

During initial ground testing of my RY835AI, I noticed a ground traffic target at my location in ForeFlight 7.2 and 7.3 -- note the brown color. This disappears when GPS is disabled, or when traffic is disabled.

The target is not displayed in Avare or FltPlan Go, nor is a traffic report visible in the data stream on port 43211 through using Avare Connect.

Have not flown with it yet, so I can not comment on whether this is present in flight.

When executing the "reboot" command as root (sudo su -), the system hangs a some point in the cycle. I can't tell if it's during the shutdown phase or the subsequent startup phase. During the shutdown process both the red power / user LED and the the green disk activity indicator LED come on for a sustained period. Eventually (10 seconds?) the green LED goes out leaving a solid red. Network and USB are both shut down (LEDs go off on the SDR and Wifi modules).

This has happened on two different Pi units, each running a different copy of the 3b3 image. If somebody else can confirm this, I'll try to hook the Pi up to an HDMI monitor and see what that shows during the reboot process.

I tend to leave the Stratux running. Consistently I have noticed the web interface hangs and the system stops responding to foreflight if it has been left running long enough. I believe this time the web interface showed about 17hours before it stopped responding.

1898 pts/0 Zl+ 1007:15 [gen_gdl90] <defunct>

pi@raspberrypi ~ $ free -m
total used free shared buffers cached
Mem: 927 914 13 0 6 22
-/+ buffers/cache: 885 41
Swap: 99 21 78

Granted I will not sit in an airplane for 17 hours with my stratux, but it might indicate a lower level problem.

I have not rebooted the Stratux, if there is any other detail that would be helpful.

This would be useful both for debugging and for scenarios where there is already a wifi network in the aircraft. At first booth Stratux should start up in AP mode as it does now. The UI should allow the user to toggle between AP and client mode. In client mode, the admin would specify the SSID and password. If the Stratux did not establish a connection to the specified SSID it should fall back to AP mode.

• 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?

I've got Stratux v.03b2, and was attempting to use a UBLOX GPS. I'm seeing traffic on /dev/ttyAMA0, and the stratux.log says it is getting GPS data, but neither the Stratux WebUI nor ForeFlight are seeing that I have GPS.

Log file here: https://dl.dropboxusercontent.com/u/2506999/stratux09172015.log.zip

GPS tty output here: https://dl.dropboxusercontent.com/u/2506999/GPSTest09172015.txt.zip

Any ideas?

Thanks,

John

I downloaded v0.4r1 last night. ForeFlight and the WebUI both lose connection after 2:18. I can still connect from the same device using SSH.

I've attached logs, but on quick look, nothing stands out.

I can restart with sudo shutdown -r now, but same thing happens.

[Well, I tried to attach logs - even renaming them .txt didn't help, so I zipped them up and they are on DropBox.

https://www.dropbox.com/s/sknrkyjrc5g1e21/Stratux-logs20151006.zip?dl=0

If anyone is interested in implementing GDL39 -

http://www.chartbundle.com/tech/gdl39/

Interesting paper: http://cseweb.ucsd.edu/~savage/papers/CCS14MobileCockpit.pdf

UAT log here - seems to have missed most of the flight, though (09:40-10:20, log starts at 10:20).

Went up today with v0.3b1, a single NooElec dongle, and powered off an Anker. No battery issues the whole flight. Most of the time was just the KPAE hi ADS-B tower, it picked up one other towards the tail end.

We had two iPad Minis in the plane - a retina, and my original - both running ForeFlight latest. My original Mini kept locking up with the traffic view enabled; shortly after that, the pi would crash (or hang) with solid power and no activity LED. The Retina mini seemed more stable, slightly.

After using the init.d script to stop stratux, it is still running.

pi@raspberrypi ~ $ sudo /etc/init.d/stratux stop
[ ok ] Stopping Stratux ADS-B Receiver: stratux.
pi@raspberrypi ~ $ ps -e | grep 'gen_gdl90'
 1882 pts/2    00:00:02 gen_gdl90