05b3 lock ups after a little more than an hour of flight.

[braddward]

I went up yesterday and today and had the same thing happen after a little over an hour of flight on 05b3.

The stratux appeared to be locked up. I power cycled and it came back online without a problem.

Here's a link to the logs: https://app.box.com/s/xrcwvnrfu4kqbw1evgugmvanmto0j0s3

Did the fixes to set the system date/time from the GPS go in after this release?

[cyoung]

Those fixes are not in v0.5b3.

What app were you using, which GPS, how many SDRs?

Was the app receiving heartbeats after lockup? In FF you you can tell by whether it shows up in the devices or shows "FreeFlight".

[braddward]

ry835a GPS with Foreflight on iPad and 2 SDR's. I don't believe that it was receiving heartbeats when it happened.

Both times I was alone so I couldn't spend much time messing with it. I did try the web interface today and that didn't respond. It seemed like the entire Pi was locked up.

Except for this I will say that the GPS has been working more reliably.

On Sat, Jan 2, 2016 at 4:50 PM cyoung notifications@github.com wrote:

Those fixes are not in v0.5b3.

What app were you using, which GPS, how many SDRs?

Was the app receiving heartbeats after lockup? In FF you you can tell by whether it shows up in the devices or shows "FreeFlight".

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

[jzeevi]

No logs, but that happened to my unit today every hour or so....

Josef Sent from a phone with a tiny screen

On Jan 2, 2016, at 4:05 PM, braddward notifications@github.com wrote:

I went up yesterday and today and had the same thing happen after a little over an hour of flight on 05b3

The stratux appeared to be locked up I power cycled and it came back online without a problem

Here's a link to the logs: https://appboxcom/s/xrcwvnrfu4kqbw1evgugmvanmto0j0s3

Did the fixes to set the system date/time from the GPS go in after this release?

— Reply to this email directly or view it on GitHub.

[jzeevi]

In to different flights, this has happened. FWIW, it may be time related rather than "powered on" related. In both flights, the Stratux disappeared from Foreflight.

In flight one, after power up and sync to FF, while waiting for engine warmup, my own ship signal disappeared. I checked the devic settings a Freeflight was gone and the web page wouldn't connect.

In flight two, "no fix" appeared and the device was also missing.

In both cases a power cycle helped. I couldn't restart as the device wasn't connected to the webui.

Josef

Sent from my iPad

On Jan 2, 2016, at 4:50 PM, cyoung notifications@github.com wrote:

Those fixes are not in v0.5b3.

What app were you using, which GPS, how many SDRs?

Was the app receiving heartbeats after lockup? In FF you you can tell by whether it shows up in the devices or shows "FreeFlight".

— Reply to this email directly or view it on GitHub.

[Axtel4]

I had over three hours of flight time yesterday with Stratux build v0.5r3 a99173a with no lock up issues. Stratux with 2 SDRs, RY835 stayed connected to DroidEFB on my Smart phone and tablet the entire flight time.

[GrayFlyer]

I too have been having this problem going back several versions. I am running dual SDR's with a RY835. I recently thought I had it narrowed down to a defective Pi, but have been proven wrong. It's not the tablet, because I have an iFly 720 and a tablet connected and both lose connection at the same time. The usual lockup occurs around 45 to 60 minutes, and a reboot fixes it, but it sometimes occurs in as little as 15 minutes. Power good, temps 90 - 105F. Running v0.5b3.

[cyoung]

@braddward - could you include /var/log/stratux.log?

[braddward]

Hi Chris,

It's in the uploaded file. Stratux.log is in the root and I included the stratux folder as well.

On Jan 2, 2016, at 18:17, cyoung notifications@github.com wrote:

@braddward - could you include /var/log/stratux.log?

— Reply to this email directly or view it on GitHub.

[braddward]

But - here's the link to just the stratux.log just in case. https://app.box.com/s/in6a072weoisv1eqg2jp4pju0gscw9dv

On Sat, Jan 2, 2016 at 7:12 PM Brad Ward braddward@gmail.com wrote:

Hi Chris,

It's in the uploaded file. Stratux.log is in the root and I included the stratux folder as well.

On Jan 2, 2016, at 18:17, cyoung notifications@github.com wrote:

@braddward https://github.com/braddward - could you include /var/log/stratux.log?

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

[Ergonomicmike]

Just got back home. The stratux hung again on the way home. (Rats - I forgot to enable logging on first boot. It's running a 16GB card. I'm goona leave logging on until v1.0.) I had to pull the SDR and the power again to get it back up. And it came up in 1090, even tho I shut it down in 978.

Since it never used to do this - and I had flown v0.5b3 when it first came out - I'll re-image and re-do the dump1090 change. Unfortunately, we have 5 days of rain forecast this coming week, so no flying/testing for a while.

I notice others having similar problems all of a sudden. Wouldn't be a Y2016 thing, would it?

[Ergonomicmike]

I powered the Stratux back up here at home just in case I had enabled logging after the first flight. I noticed that a lot of the logs wouldn't have done any good because they were zero length. That is, if the SDR doesn't initialize, then no data to log. Is there a diagnostic log that logs the steps the Pi is going thru? Should I set debug true in the config file?

[skypuppy]

dmesg?

On 01/02/2016 08:31 PM, Ergonomicmike wrote:

I powered the Stratux back up here at home just in case I had enabled logging after the first flight. I noticed that a lot of the logs wouldn't have done any good because they were zero length. That is, if the SDR doesn't initialize, then no data to log. Is there a diagnostic log that logs the steps the Pi is going thru? Should I set debug true in the config file?

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

[Ergonomicmike]

@skypuppy I had to look up dmesg. (Will forever be a noob w/ Linux.) You'll have to talk me thru it.

I read that it needs to run syslog in the backgound to capture an output file. Does syslog currently run on the pi? If so, is the dmesg logfile in the list of other log files?

Might be moot at this point in time 'cause I see that Chris is building b4 now. Perhaps this issue is fixed.

[skypuppy]

from a text console, just enter "dmesg" and if it is logging (and it is usually turned on) you should see a lot of Greek flowing down your screen. If you "dmesg | grep " it should show you what happened with stratux at the kernel level. For example, "dmesg | grep rtl" will show you all the kernel messages related to the rtl-sdr radios. Or, "dmesg | grep gdl90" and so on. Since last boot.

Skypuppy

On 01/02/2016 09:23 PM, Ergonomicmike wrote:

@skypuppy https://github.com/skypuppy I had to look up dmesg. (Will forever be a noob w/ Linux.) You'll have to talk me thru it.

I read that it needs to run syslog in the backgound to capture an output file. Does syslog currently run on the pi? If so, is the dmesg logfile in the list of other log files?

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

[skypuppy]

And I believe Raspbian has it on by default. (Raspbian is a version (currently) of Debian Linux specifically modified for the RPi 1 and 2. Btw.

On 01/02/2016 09:23 PM, Ergonomicmike wrote:

@skypuppy https://github.com/skypuppy I had to look up dmesg. (Will forever be a noob w/ Linux.) You'll have to talk me thru it.

I read that it needs to run syslog in the backgound to capture an output file. Does syslog currently run on the pi? If so, is the dmesg logfile in the list of other log files?

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

[Ergonomicmike]

Tnx. But the best I will ever be able to do is to get a log file from my crashed system and post it on the web for you guys to analyze. (Clint Eastwood said that a man has got to know his limitations. That's mine! I'm pushing it posting in the github.)

[jpoirier]

On Sat, Jan 2, 2016 at 10:23 PM, Ergonomicmike notifications@github.com wrote:

Tnx. But the best I will ever be able to do is to get a log file from my crashed system and post it on the web for you guys to analyze. (Clint Eastwood said that a man has got to know his limitations. That's mine! I'm pushing it posting in the github.)

You'll be surprised at how quickly you move up the tech continuum...

[skypuppy]

I was dragged kicking and screaming all the way up to rung 3 out of

100. Working on rung 4.

On 01/02/2016 10:28 PM, Joseph Poirier wrote:

On Sat, Jan 2, 2016 at 10:23 PM, Ergonomicmike notifications@github.com wrote:

Tnx. But the best I will ever be able to do is to get a log file from my crashed system and post it on the web for you guys to analyze. (Clint Eastwood said that a man has got to know his limitations. That's mine! I'm pushing it posting in the github.)

You'll be surprised at how quickly you move up the tech continuum...

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

[skypuppy]

The more you learn, the more you learn what you don't know. It's an exponential growth factor.

I'm just crazy enough to enjoy the ride, though!

On 01/02/2016 10:28 PM, Joseph Poirier wrote:

On Sat, Jan 2, 2016 at 10:23 PM, Ergonomicmike notifications@github.com wrote:

Tnx. But the best I will ever be able to do is to get a log file from my crashed system and post it on the web for you guys to analyze. (Clint Eastwood said that a man has got to know his limitations. That's mine! I'm pushing it posting in the github.)

You'll be surprised at how quickly you move up the tech continuum...

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

[cyoung]

@braddward, @GrayFlyer, @Ergonomicmike - I've just put up v0.5b5, give it a try.

[Ergonomicmike]

Just saw it. Will write image and head to the airport in the rain.

[braddward]

Thanks. I'll give it a try hopefully this weekend if the weather cooperates!

On Thu, Jan 7, 2016 at 12:35 PM Ergonomicmike notifications@github.com wrote:

Just saw it. Will write image and head to the airport in the rain.

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

[cyoung]

Any updates?

[braddward]

I flew today for about 1.5 hours with no issues on the latest image.

On Sun, Jan 10, 2016 at 3:06 PM cyoung notifications@github.com wrote:

Any updates?

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

[GrayFlyer]

Everything is ready for a test flight, except the weather. Looks like some decent weather tomorrow for a flight with 0.5b5 and the latest iFly beta software.

[GrayFlyer]

I flew 0.5b5 today for about 50 minutes with no lock-ups, but the AHRS would not connect with either iFly or the web UI. I tried a reboot of the Stratux, but still no luck. It seems like connection with AHRS is hit or miss since 0.5b4 or maybe even before. Pressure altitude worked just fine and the RY835AI was showing down to 0.7M accuracy on the UI at times. The best I've seen with 0.5b4 was 2M.

[Nokomis449]

That's exactly what I've seen since 0.5b3. Hit or miss AHRS, but pressure altitude works fine, GPS works fine. 0.5b2 AHRS works fine.

[GrayFlyer]

I flew 0.5b5 again today and had a lock-up after 16 minutes in flight (27 minutes of connect time,) rebooted and flew for another 40 minutes without another lock-up. After the lock-up iFly reported Stratux as disconnected with no heartbeat, but a total of 5 heartbeats accumulated which seems very low for 10 minutes or so in flight, and notice the flight duration of 46 seconds in the background which is about right for 5 heartbeats.

No AHRS on the UI or iFly, but good pressure altitude.

All in all not a problem losing connection as the iFly 720 seamlessly changes over to it's internal GPS when connection with the ADSB GPS is lost, and a reboot always repairs the connection.

[skypuppy]

Do you have cpu temps in your logs?

Also, very strange, but the RPi2 processor is reportedly susceptible to UV, to the point of destruction.

Another possibility is a buggy compiler. Or dips in supply power. Or bugs in how C code meshes with go code at compile/link time (even though go is written in C.) Or some other intermittent hardware failure. Do you perhaps have an Element14 RPi2, the ones made in communist China? The RY chip(s) are definitely from China, so they may have intermittent hardware problems that corrupt the system.

Grasping at straws here.

Skypuppy

On 01/13/2016 07:20 PM, GrayFlyer wrote:

I flew 0.5b5 again today and had a lock-up after 16 minutes in flight (27 minutes of connect time,) rebooted and flew for another 40 minutes without another lock-up. After the lock-up iFly reported Stratux as disconnected with no heartbeat, but a total of 5 heartbeats accumulated which seems very low for 10 minutes or so in flight. No AHRS on the UI or iFly, but good pressure altitude.

All in all not a problem losing connection as the iFly 720 seamlessly changes over to it's internal GPS when connection with the ADSB GPS is lost, and a reboot always repairs the connection. screenshot_2016-01-13-17-04-12 https://cloud.githubusercontent.com/assets/16521434/12313154/fe469d26-ba32-11e5-9bf5-345c2cae4d63.png

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

[bradanlane]

On the possibilities of the lockup, my money is still with the recent changes to compile librtlsdr into gen_gdl90.

RTLSDR isn't guaranteed to be thread-safe and we have introduced a few ways we could be executing in the library from multiple code paths simultaneously.

[ssokol]

WRT the lockup theory from @bradanlane... I've talked to a number of avionics gurus over the past few years about approaches to writing software. I get the impression that many of them prefer to build systems as a cluster of independent single-threaded applications rather than relying on multiple threads within any one application. Threads -- and especially threads that are managed by the language runtime -- introduce the potential for subtle bugs that are often very difficult to reproduce and eliminate.

I'm not suggesting that we make a major architectural change at this point, but it is something to consider for the future.

On Thu, Jan 14, 2016 at 6:31 AM, bradanlane notifications@github.com wrote:

On the possibilities of the lockup, my money is still with the recent changes to compile librtlsdr into gen_gdl90.

RTLSDR isn't guaranteed to be thread-safe and we have introduced a few ways we could be executing in the library from multiple code paths simultaneously.

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

Steven Sokol 408 Camelot Drive Liberty, MO 64068

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

[bradanlane]

I've been testing this very architecture. With the current gen_gdl90, we launch a separate process for handling dump1090. I went ahead and moved rtl_sdr|dump978 to also be a separate process. It doesn't appear to be any more/less CPU and its stable, predictable, and log-able.

I'm not suggesting Stratux change. I just wanted to test the alternate system architecture.

[GrayFlyer]

I've been trouble shooting this crash problem on the hardware end for some time now. I replaced the China produced Pi with the one from Great Britian with no improvement. I've replaced the SD card, the Edimax wifi dongle, the SDR, and tried several power configurations. Currently I'm supplying 5v from a 12v switching PS located 2" from the GPIO, with parallel connections; solid red led at all times, even when starting the Lycoming. The CPU was running 73F just a minute before crashing (fan cooled in glove box on a cold evening) my normal CPU temp is around 90F. I recently relocated the Edimax away from the power supply just to be sure.

[gitmoregrits]

For what it's worth, I had very similar problems with the KMASHI battery (the one initially recommended for the Stratux build). With the Anker (20000 mah?) battery I have zero lock ups and obviously longer up times due to increased capacity. I know you're running on your ship power but it may make sense to try an Anker if you have one to see if you exhibit any different behavior. I have flown about 5 hours now with the Anker and haven't had one lock up where as before I was seeing lockups approximately every 30-45 mins.

[GrayFlyer]

Thanks for your observation.  I also have a "portable" Stratux that
runs on a 10ah Anker battery and I don't recall having a lock up
with it, but I seldom run it for over 20 minutes because of high CPU
temps on the glare shield.  I wonder what the power supply set up is
for some of the others that have experienced lock ups is?

I'll give my portable Stratux some more air time and see how it
fares.

On 1/14/2016 11:12 AM, gitmoregrits
  wrote:

  For what it's worth, I had very similar problems with the
    KMASHI battery (the one initially recommended for the Stratux
    build). With the Anker (20000 mah?) battery I have zero lock ups
    and obviously longer up times due to increased capacity. I know
    you're running on your ship power but it may make sense to try
    an Anker if you have one to see if you exhibit any different
    behavior. I have flown about 5 hours now with the Anker and
    haven't had one lock up where as before I was seeing lockups
    approximately every 30-45 mins.
  —
    Reply to this email directly or view
      it on GitHub.

[skypuppy]

I'm moving that way toward major structural changes via c/c++ and Qt, with POSIX threads, signals and slots, and using monolithic software. But due to my physical limitations it could be months or years before I have anything even remotely usable. Also, NOT using the RY parts and trying to not use any Chinese parts.

If that is reason to ban me, then so be it. Meanwhile, in the real world, I'm still using 0.4r4.

Skypuppy

On 01/14/2016 07:15 AM, Steven Sokol wrote:

WRT the lockup theory from @bradanlane... I've talked to a number of avionics gurus over the past few years about approaches to writing software. I get the impression that many of them prefer to build systems as a cluster of independent single-threaded applications rather than relying on multiple threads within any one application. Threads -- and especially threads that are managed by the language runtime -- introduce the potential for subtle bugs that are often very difficult to reproduce and eliminate.

I'm not suggesting that we make a major architectural change at this point, but it is something to consider for the future.

On Thu, Jan 14, 2016 at 6:31 AM, bradanlane notifications@github.com wrote:

On the possibilities of the lockup, my money is still with the recent changes to compile librtlsdr into gen_gdl90.

RTLSDR isn't guaranteed to be thread-safe and we have introduced a few ways we could be executing in the library from multiple code paths simultaneously.

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

Steven Sokol 408 Camelot Drive Liberty, MO 64068

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

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

[skypuppy]

Your results seem to confirm cyoungs assertions that it is code related.

Skypuppy

On 01/14/2016 09:36 AM, GrayFlyer wrote:

I've been trouble shooting this crash problem on the hardware end for some time now. I replaced the China produced Pi with the one from Great Britian with no improvement. I've replaced the SD card, the Edimax wifi dongle, the SDR, and tried several power configurations. Currently I'm supplying 5v from a 12v switching PS located 2" from the GPIO, with parallel connections; solid red led at all times, even when starting the Lycoming. The CPU was running 73F just a minute before crashing (fan cooled in glove box on a cold evening) my normal CPU temp is around 90F. I recently relocated the Edimax away from the power supply just to be sure.

<<>>

screenshot_2016-01-13-17-02-21 https://cloud.githubusercontent.com/assets/16521434/12328620/265ca1c6-baaa-11e5-83f4-b7d3755d1d1b.png

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

[Ergonomicmike]

@ssokol I'm glad someone much more knowledgeable than I mentioned that single threads are safer than multi. I can't bring anything to the table except to say that I got burned once in a college project by a race condition. Who knows what's going on inside a mult-core chip with stuff being swapped in/out of internal caches by an OS or code in the CPU?

I think it was ssokol who provided a command line switch for some operation that set how many cores would be used. Perhaps as an easy, first pass way to implement safer threads would be to set any operation that allows for single thread set to single thread? (Are there some processes that require more than one core?)

[skypuppy]

maybe it's time to implement resource locks.

On 01/14/2016 01:24 PM, Ergonomicmike wrote:

@ssokol https://github.com/ssokol I'm glad someone much more knowledgeable than I mentioned that single threads are safer than multi. I can't bring anything to the table except to say that I got burned once in a college project by a race condition. Who knows what's going on inside a mult-core chip with stuff being swapped in/out of internal caches.

I think it was ssokol who provided a command line switch for some operation that set how many cores would be used. Perhaps as an easy, first pass way to implement safer threads would be to set any operation that allows for single thread set to single thread? (Are there some processes that require more than one core?)

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

[jzeevi]

Single threads are safer, but less responsive and, as noted, demand a deliberate and thoughtful approach to the SW design. However, the multi-core comment isn’t applicable to a good design as the HW’s just there to support the effort. Poor design (or no design) is a rat-hole that once headed down, is difficult to get out of. (gah – what horrible grammar). Multi-threaded designs are easy enough to accomplish and don’t require 40 years of embedded experience to understand. Always preferred in complex systems where the processing is less related and more parallel. On a multi-core system, a multi-threaded design wins hands-down except for the most trivial.

I think in your note you may be confusing single core with single thread. But, most reasonable OS’s (linux especially) have good handles on process to core assignment although it usually requires the SW to request running on a different core. (I did some ARM A57 development that had 30 threads (two processes) on 16 cores with no trouble doing real-time network traffic at gigabit phy rates).

I’m fond of saying (not sure where I got it): If you don’t know where you’re going, any road will get you there.

Note: I suspect SW engineering isn’t the problem here, but implementation “oopses”. J

From: Ergonomicmike [mailto:notifications@github.com] Sent: Thursday, January 14, 2016 1:24 PM To: cyoung/stratux Cc: Josef Zeevi Subject: Re: [stratux] 05b3 lock ups after a little more than an hour of flight. (#180)

@ssokol https://github.com/ssokol I'm glad someone much more knowledgeable than I mentioned that single threads are safer than multi. I can't bring anything to the table except to say that I got burned once in a college project by a race condition. Who knows what's going on inside a mult-core chip with stuff being swapped in/out of internal caches.

I think it was ssokol who provided a command line switch for some operation that set how many cores would be used. Perhaps as an easy, first pass way to implement safer threads would be to set any operation that allows for single thread set to single thread? (Are there some processes that require more than one core?)

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/180#issuecomment-171751023 . https://github.com/notifications/beacon/APJ34Wg2BkKW56n7bp7QtdEQWw_ULxhnks5pZ-1lgaJpZM4G9m8K.gif

[Ergonomicmike]

You're correct - I confused threads with cores.

[Ergonomicmike]

And IIRC, early Intel uP's ran faster with their hyper-threading/predictive processing off rather than on. Maybe those days are behind us. But I'll be forever leery of race conditions. And since this issue is about "random" lock-ups, that's my usual suspect.

[skypuppy]

compilers are much better nowadays. :) We need a good debugging session where we can trap when two or more sdr messages arrive during the same function processing phase. It could be that one sdr message is clobbering the current cycle.

Impossible to replicate this problem with the current information, but it must be done to prevent the app from crashing.

On 01/14/2016 01:43 PM, Ergonomicmike wrote:

And IIRC, early Intel uP's ran faster with their hyper-threading/predictive processing off rather than on. Maybe those days are behind us. But I'll be forever leery of race conditions. And since this issue is about "random" hangs, that's my usual suspect.

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

[jzeevi]

Yes, those days are well behind us. Ah, the good old days when Intel couldn’t do floating point (our team discovered that in parallel with several others).

It is wise to be leery of race conditions! But that’s not a reason to avoid multi-anything programming. One only has to be thoughtful and deliberate about it.

And, since we’ve drifted so far off topic, I call Pizza on myself. J

From: Ergonomicmike [mailto:notifications@github.com] Sent: Thursday, January 14, 2016 1:44 PM To: cyoung/stratux Cc: Josef Zeevi Subject: Re: [stratux] 05b3 lock ups after a little more than an hour of flight. (#180)

And IIRC, early Intel uP's ran faster with their hyper-threading/predictive processing off rather than on. Maybe those days are behind us. But I'll be forever leery of race conditions. And since this issue is about "random" hangs, that's my usual suspect.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/180#issuecomment-171756481 . https://github.com/notifications/beacon/APJ34XcOIgpnKCtJT962pIXv-bhOB4L3ks5pZ_H7gaJpZM4G9m8K.gif

[cyoung]

@GrayFlyer - looking at your screenshots, I see you're using an Amazon Fire. Have not tested on this platform yet. Do you have another device (Android or iOS) that you're able to connect to stratux to see if you experience the same?

[GrayFlyer]

Hey Chris,

Yes, I currently run iFly and Avare on my Samsung Tab S and have ran
iFly on my iPad 2, all with the same experience.  The Amazon Fire
that I'm running iFly on is a rooted $49.99 model, lots of bang for
the buck!  I run the tablets in parallel with my iFly 720, and also
use them for access to your UI.  When the problem occurs it affects
both connected devices.

FWIW, I just flew with my portable battery powered Stratux for about
an hour with no problems on 0.5b5 with my iFly 720 and the Fire for
the UI.

Thanks for looking into this!

Dave

On 1/14/2016 5:39 PM, cyoung wrote:

  @GrayFlyer - looking at your
    screenshots, I see you're using an Amazon Fire. Have not tested
    on this platform yet. Do you have another device (Android or
    iOS) that you're able to connect to stratux to see if you
    experience the same?
  —
    Reply to this email directly or view
      it on GitHub.

[cyoung]

Ok, so here's what we have currently on the lockups -

1. @braddward was using FF on v0.5b3, upgrading to v0.5b5 appears to have fixed it and the problem has not resurfaced.
2. @GrayFlyer, @Ergonomicmike are using iFly on various platforms and the problem is still persisting.
3. @Axtel4 reports v0.5b3 did not have any issues with DroidEFB.
4. @jzeevi reported issues with an unknown stratux version with FF.

So @jzeevi, @GrayFlyer, and @Ergonomicmike remain now.

@jzeevi - have you tried v0.5b5 with FF? What version was giving you issues originally?

@GrayFlyer, @Ergonomicmike - I'm going to branch off your reports and consider that this may actually be a separate issue with the way stratux works with iFly.

Going to go flying today with iFly GPS 9.4.36b on Android 4.2 (cheap tablet) and see what happens - first time trying out the app.

[jzeevi]

Initially this was with .5b3. Over the weekend I flew with .5b5 and had a similar thing. I wound up rebooting to tees tableau the connect.

Josef Sent from a phone with a tiny screen

On Jan 19, 2016, at 7:54 AM, cyoung notifications@github.com wrote:

Ok, so here's what we have currently on the lockups -

1. @braddward was using FF on v0.5b3, upgrading to v0.5b5 appears to have fixed it and the problem has not resurfaced.
2. @GrayFlyer, @Ergonomicmike are using iFly on various platforms and the problem is still persisting.
3. @Axtel4 reports v0.5b3 did not have any issues with DroidEFB.
4. @jzeevi reported issues with an stratux unknown version with FF.

So @jzeevi, @GrayFlyer, and @Ergonomicmike remain now.

@jzeevi - have you tried v0.5b5 with FF? What version was giving you issues originally?

@GrayFlyer, @Ergonomicmike - I'm going to branch off your reports and consider that this may actually be a separate issue with the way stratux works with iFly.

Going to go flying today with iFly GPS 9.4.36b on Android 4.2 (cheap tablet) and see what happens - first time trying out the app.

— Reply to this email directly or view it on GitHub.

[GrayFlyer]

@cyoung. Be sure to turn on ADSB logging (under wireless devices) After your flight look in the iFly files under "user" for it and also #logs (on by default) Even if you don't have a problem, you may find some clues in those files.

[cyoung]

I've added http://192.168.10.1/getClients to the current master branch for debugging - suspect it has to do with sleepmode.