Is there a “switch” to disable UAT Dongle Power Saving?

[Axtel4]

1. Stratux version: 0.5b5
2. Stratux config: single/dual SDR, GPS yes/no (type?), AHRS yes/no, battery, battery cable. 3a. EFB app and version: DroidEFB / Avare 3b. EFB platform: Android KitKat / Lollipop 3c. EFB hardware: ASUS Tablet / LG G3
3. Description of your issue. I have been analyzing the performance of Stratux (see issue 203). The 1090ES analysis has gone well, but I have observed some anomalies with 978UAT. While observing the performance I have noticed that the reception of UAT has decreased since the release of 0.5b3. With 0.5b3 Stratux appears to take longer to acquire tower and display the data. A switch for the “power save” feature would aid in analyzing Stratux performance.

Background: At my location I have an antenna mounted outside for UAT reception. I am also on the edge of the reception range for the closest tower so this allows for the observation of low signal performance. Based on the data I have examined, I appear to have less than 6 dB of Link Margin at my location. With this margin it doesn’t take much to vary between having tower reception and no tower reception. At L-Band frequencies reception can be affected by following losses: the amount of moisture in the air, tropospheric ducting, or Freznel Path Loss in addition to the natural path loss. Each of these losses can push the received signal level below the MSD (Minimum Discernible Signal) threshold for the subject receiver.

Based in what I glean from the code and the Stratux log the new power settings cycle the 978 UAT dongle in 100 second cycles with 50 second “sleep” intervals and 50 second “parse” intervals. If it doesn't parse data during the 50 second “wake” cycle it goes back to sleep until the next wake cycle. If it receives a signal it “stays awake” until the signal is lost and reverts back to the power saving cycles.

My observation is, when receiving signals close to the SDR noise floor (MDS) there doesn't appear to be enough data to achieve a valid parse to keep the SDR awake. I have seen it take up to 45 minutes before it sees a signal that persists long enough for it to process and display the data. I have also observed it acquire the tower data faster (a matter of minutes) if stronger UAT traffic happens to fly by my location.

Working Theory: It may be that when receiving a stronger UAT signal the “channel is left open” thus allowing Stratux to see the weaker Tower Signal without the sleep interruptions. However, with a signal at the MSD level, there is not enough data decided to keep the UAT dongle “awake.”

If Stratux is in an area of high UAT traffic the sleep mode may not be that much of an issue. However, if in the western parts of the US or other areas where UAT traffic is sparse, it may take a long time for Stratux to decode and display UAT traffic or tower data. This may appear to some users as, “my UAT dongle is operating poorly.”

[duecedriver]

@bradanlane I am wondering how we handle the gain on the receivers.. sounds like the ground based SDR ADS crowd have issues with overly strong signals ending up garbled .. i.e. translated for us in the 1090 band.. that close traffic that matters most might not be plotted at the expense of getting distant targets at 100 miles + that we shouldn't care about?

also, gain seems like it would be even more difficult a tradeoff on UAT since we would want to have ungarbled messages from as many (near or far) stations as possible.. since the weather data is station type dependent...

thoughts

[bradanlane]

In my case - which it may not be the norm - strong UAT signals are not the problem. It's the opposite. I have very few ground towers to work with. For a typical locak area flight most towers are 30-90 miles away.

[duecedriver]

i guess that is my point.. in that ground testing is a static environment.. signal strengths except for 1090 do not change..

in flight.. 1090 should be optimized so the gain reliably gets the strongest of signals, sacrificing distant again as distant traffic by definition are not a conflict

however.. UAT will have to be dynamic in that you might be right on top of a low tower and a mid tower might be at the edge of reception range.. if the tower you are on top of garbles due to high gain, you might loose parsable messages.. but getting messages from the weak tower is just as important as it contains messages the ground tower does not...

also, I believe in flight.. since we are not using band pass filters on the antennas.. that there is probably a lot of noise that, if the gain is high, is probably saturating the signal to noise floor further hampering reliable signal parsing..

[bradanlane]

During flight operations, I have no data to suggest that the Stratux SDR is being saturated by a close tower.

Regardless of gain, a nice band pass filter would no doubt improve the system

[duecedriver]

this is in the original dump 1090.. perhaps make these settings avail for both 1090 and UAT on the config page

--device-index Select RTL device (default: 0) --gain Set gain (default: max gain. Use -10 for auto-gain) --enable-agc Enable the Automatic Gain Control (default: off) --freq Set frequency (default: 1090 Mhz) --ifile Read data from file (use '-' for stdin)

[bradanlane]

Making those settings available for a technical user may be of interest, however they probably should not be generally available. If there is enough value in making these settings configurable, then storing them in the stratux.conf or a separate conf file would solve the split usage.

[duecedriver]

i see it as no different than making the ppm field editable... it allows the user to tune the radios to their needs... leaving them blank can keep the device at its default setting but its not like the user can blow himself up by changing them...

[bradanlane]

Agreed and the PPM field is confusing for many users. From a UX perspective, the right design would be to run the calibration under the covers and store the correction and the user never needs to deal with it.

[duecedriver]

hey.. if the ppm is confusing.. should they be operating ann aircraft and/or messing with a DIY piece of avionics anyway?..

given half the comments over on reddit.. some of these folks shouldn't be driving cars...

however back on point.. the SRDs are of such spotty quality control, and the types and varieties of antenna being used never seems to stop, so I dont know if you can write generic gains for the lot.. I still think that its would be better as an adjustable field.. or like you said.. some active tuning algo

I also think that the 2 different dongles will need 2 different sets of tuning priorities.. 1090 prioritize close in high power signals so as not to clip them vs UAT which will need some kind of auto gain in my opinion that tries to find a sweet spot.. as you say... auto tuning algorithms would be great... however I think we would need to find a ham nerd that understands the subject far better than us to pull it off...

I think that our priorities for 1090 dont need the band pass filter the ground guys are using since distance is not a priority but in close clean signals.. however anything to reduce the noise floor on UAT would be a welcome addition and help the tuning algos by filtering most of the crap out of the way..

[Ergonomicmike]

@Axtel4 Thanks. I went to /getSettings and confirmed that power savings is "false." I don't know what else to use the page for. When/if I lose Wi-Fi connectivity in the plane next flight, what do I look for on the /getSettings page?

[Ergonomicmike]

@Axtel4 Also, what is port 49002 for? I though I would be clever by setting Avare's I/O plug-in to listen to that port (since iFly hogs port 4000) but no joy. (Won't show the traffic stream when there's traffic.)

[cyoung]

Removed output on that port as of yesterday, it was only used for FF for AHRS but that doesn't work anymore.

https://github.com/cyoung/stratux/commit/fd03b25d04abb296c5a6a0037ca00baec298a73c

[Ergonomicmike]

I must have caught the new build just in time. Out of curosity, why does port 49002 still show then in the getSettings page?

[cyoung]

It's saved in your stratux.conf. If you "sudo pkill gen_gdl90; sudo rm -f /etc/stratux.conf" it will disappear (if you're using the latest build) and not come back the next restart.

[Ergonomicmike]

Apparently I had the build with 28 commits, 'cause port 49002 came back after I removed the file and restarted. But good news - the new make went much easier and faster. (I updated the Pi date which drifted during the time the Pi was off.) Now 49002 stays gone on reboot. I wonder if this change will serendipitously fix the Wi-Fi connectivity problem? (So @Axtel4, did you use this latest build when you had your latest Wi-Fi issue 23 hours ago? UPDATE: P.S. Oh, I can see from @Axtel4's getClients report that he didn't have this commit installed yet.)

[Ergonomicmike]

Okay, I'm confused. I have Stratux listening on 978. No traffic, no towers. getSettings shows PowerSave:false. getClients shows me hooked up to my one tablet (192.168.10.11), port 4000. The time that I am 'LastUnreachable" increments on refresh to a time that appears to be how long the Pi has been up. (But aren't I reachable? I'm connected.) And SleepingFlag is true.

I thought PowerSave false kept things from sleeping?

Update: I rebooted. Still getting SleepingFlag true, but I can refresh the browser and occasionally the Flag reports false. It can toggle as quickly as every few seconds while refreshing. No rhyme or reason that I can see. Status page reports zero ADS-B messages. (Update: short video at https://vid.me/GF3F.)

[cyoung]

LastUnreachable is a counter since an ICMP Destination Unreachable packet was received. This happens when your EFB is closed or in the background (normally, iFly doesn't seem to close the port even when it is in the background).

[Ergonomicmike]

Hmmm ... I didn't have iFly running. If it will be helpful, I can run the test again w/ iFly on one tablet and watch getClients on another.

[cyoung]

LastUnreachable increasing when there is no EFB running is expected behavior. The port will open on the tablet when the app is opened and it should drop to 0.

[Ergonomicmike]

And the true/false sleep Flag?

[cyoung]

Expected behavior is:

EFB open AND in context AND tablet screen on, sleep = false Any of the above not true, sleep = true

[Ergonomicmike]

Okay, I think I've got the big picture now. I ran 3 tablets. Two running iFly, one to monitor Stratux. The LastUnreachable time stops incrementing at the time the iFly's connected. SleepFlag stayed false, even when I changed focus away from iFly. Even when both tablets went to sleep w/ iFly in the background.

Interestingly, even after I took one of the iFly tablets and changed the Wi-Fi to tap this out, Stratux is still showing the LastUnreachable as the time when I first started iFly on this tablet. Even tho the SleepFlag went True. (I'm on a home network address of 192.168.1.x., if that matters to getClients.)

If the Wi-Fi disconnect problem still remains this Saturday, I'll know what to look for if I lose Wi-Fi in the plane.

[Ergonomicmike]

Huh - even after turning off this tablet and rebooting it, getClients is still showing the initial LastUnreachable time from an hour ago. (I cleared the browser cache and refreshed. N/C.) It's like getClients got hung w/o a graceful shutdown of the iFly network. (iFly disconnected gracefully on the other tablet when I changed the Connected Devices to "None.")

[cyoung]

@Ergonomicmike - give v0.5b6 a try

[Ergonomicmike]

Am on it. We might go flying tomorrow. (Wednesday.)

[Ergonomicmike]

As for Wi-Fi connectivity, v0.5b6 is working for me with my two tablets. It might even have been that v0.5b5 would have worked, given that my issue was with my Nook HD+ and a custom ROM.

Figured it's not cool to cross post, and I wasn't sure where to post first. So the story is at https://github.com/cyoung/stratux/issues/180#issuecomment-176015349

As for ADS power savings being disabled - can't A/B it, so can't say definitively. But flew from Phx to Death Valley and had towers most of the way there. (There are no ADS-B towers in Death Valley. Limited, if any, cell phone coverage. (Nothing on Verizon.))

[cyoung]

UAT powersave has been removed.