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.”

[Ergonomicmike]

Such a switch would be a good idea for us SW pilots. The text description could warn the user that "This option might keep towers locked in sparse areas, but will consume more power."

Axtel4's emperical observations correspond well with what I vaguely remember from my early days of engineering. PLL's had just come on scene and there were all sorts of IEEE articles about statistical time to lock vs. signal strength. IIRC, the graphs looked like hysteresis charts for magnets - the point being that once locked, it was easier for a PLL to stay locked.

I don't know when sleep was implemented, but FWIW, I have flown PHX to Las Vegas low with ADS-B 99% of the way with earlier non-beta releases of Stratux. But I can't keep ADS-B now from PHX to TUS w/ v0.5b5 which offers more towers enroute. (Could be a combination of issues.)

[cyoung]

@Axtel4 - what is the typical UAT rate from your antenna with earlier versions? It takes only 1 message per minute to keep the dongle "awake".

Even so, perhaps we're cycling it too much and not giving the SDR enough time to warm up and stabilize, such that it picks up weaker signals.

Could you give this a try to see? While stratux is running and hooked up to your antenna, run "tail -f /var/log/stratux.log". If you expect more than 1 message/minute, it should never sleep.

https://github.com/cyoung/stratux/blob/master/main/sdr.go#L351 to

 if stratuxClock.Since(lastUATCheck) >= 10*time.Minute {

https://github.com/cyoung/stratux/blob/master/main/sdr.go#L356 to

 stopCheckingUATUntil = stratuxClock.Time.Add(8 * time.Minute)

[Ergonomicmike]

Good point about the SDR stabilizing. I put my Stratux outside one morning to run some tests inside. OAT was freezing. I was surprised that I wasn't getting much traffic. I had to change the PPM from 25 to 50 until the SDR warmed up to receive properly.

[Axtel4]

what is the typical UAT rate from your antenna with earlier versions?

I looked at some of the older logs and it was intermittent in the low single digits with max rate in the teens.

Could you give this a try to see? While stratux is running and hooked up to your antenna,

I will but it will may be a couple of days until the ice is off the antennas.

[Ergonomicmike]

Isn't ice on the antennas a good test case? Low signal strength.

[Axtel4]

Maybe too good. I haven't see any UAT activity all evening.

[bkwny]

Is the shutoff done only for the purpose of saving power? If so, it seems people running off ship's power might want to disable the periodic shutoff, right? Could the power-saving setting be a setting on the web management screen? And eventually rolled into some more complete configuration management facility? And if it's OK to shut off the 978 dongle occasionally for saving power, is it also OK to shut off the 1090 dongle occasionally for saving power? Why or why not?

[cyoung]

It's OK, but it probably shouldn't be done based on message rate because there seems to always be 1090ES traffic.

The power saving will either be always enabled or not in there at all. The only benefit of turning it on or off would be if a user regularly receives less than 10-20 UAT messages per minute. If that's the case, they need a better antenna.

On the other hand, if the power saving feature is reducing actual reception then we should investigate that. If there is data that supports the hypothesis, then we will work on fixing it. If it proves too difficult to resolve, we will remove power saving altogether.

[Ergonomicmike]

A switch in the next beta, accessible via the WebUI, would allow me to A/B in flight over remote parts of the desert SW and gather empirical data. Perhaps the log files should also be modified to know when power saving is on/off. That way, a smart guy looking at the logs could see if there's any night/day difference in receive rates when power saving is on/off.

[bradanlane]

I ended up eliminating the code in my local build. It didn't serve any purpose in-flight since I always wanted Stratux to be listening for UAT.

[cyoung]

That's a good point. I'll probably eliminate it in any case, if there is a general "sleep" mode or idle shutoff then it should shut everything off. I'm interested to see if it is causing actual reception issues or it's really a red herring in any case. From what I'm seeing, it is working as expected minus perceived or actual reduction in sensitivity on the UAT radio.

[skypuppy]

Any results on thermal issues?

On 01/22/2016 01:25 PM, cyoung wrote:

That's a good point. I'll probably eliminate it in any case, if there is a general "sleep" mode or idle shutoff then it should shut everything off. I'm interested to see if it is causing actual reception issues or it's really a red herring in any case. From what I'm seeing, it is working as expected minus perceived or actual reduction in sensitivity on the UAT radio.

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

[Ergonomicmike]

@bradanlane Is eliminating the code (and/or changing a line to ham string it) something easy that a noob can do in a minute by simply SSH'ing in?

[bradanlane]

eliminating the code requires golang changes since there is not pre-compiler capability and nothing that can fake the logic to keep the SDR running at all times.

[Ergonomicmike]

Rats. That's what I expected. Thanks.

[cyoung]

@Ergonomicmike - are you able to git pull and compile? If so I'll make a branch with a switch for A/B testing.

[Nokomis449]

Ergo - I've only done it once, and it was easy. I'd use a 2nd SD card just in case. I got the instructions from a reddit/Stratux post:

To compile from scratch: sudo su - rm -rf stratux git clone https://github.com/cyoung/stratux cd stratux export PATH=/root/go/bin:${PATH} export GOROOT=/root/go export GOPATH=/root/go_path make make install

If I'm correct (remember, I've only done it once), the only thing that'll change is the "git clone..." line. I'd also like to test this if a branch is made.

[Axtel4]

I would be interested in the switch build. I've pulled a number of commits and compiled the xode, but is pulling a branch a different process?

I'm interested to see if it is causing actual reception issues or it's really a red herring in any case.

So am I. Here is the test plan: Take Stratux and the test code to the airport and test with a moderate line of sight signal from a tower. After establishing a baseline with the tower a precision variable attenuator will be used to determine the MSD of the receiver with the "power setting" feature disabled. After that is determined the "power save" feature will be enabled to determine if "power save" affects reception. If it does, the attenuation will be decreased until Stratux starts receiving. From there amount of signal level for reception can be determined. Using this method would provide for more consistent results than monitoring Stratux performance from an appreciable distance. A tower is a know entity and meaningful measurements can be made after the Stratux set-up is characterized.

I do have a few questions about the Signal Strength (rs / ss) in the stratus.log and on the Towers Web UI page.

1) What is the update rate of the Strength parameter on the Web UI? This will determine the minimum dwell time required at each attenuator setting for a stable measurement.

2) How is the rs/ss value in the stratux.log determined and what is the reference point? Reading through Phil Karn's comments in the fec code I found the following:

Compute sum of squares of a buffer of 16-bit signed integers. This is useful in DSP for finding the total energy in a signal.

Is this a representation of the power density within the Pulse Envelope? If so, is it an arbitrary number, or has it been referenced to a know entity like the Noise Floor of the receiver? In most receiver systems, the receiver sensitivity is measured against a known stimulus and is measured in either dBm or uV (microsvolts). It would be helpful for future testing if the rs/ss could be characterized to one of those references.

[Ergonomicmike]

Hi Chris and Jeff:

I would really like to try the switch, esp. since I plan to shoot some approaches tomorrow, but for two things: 1) I use iFly (for Android). According to Chris, he confirmed the wi-fi problem when he flew. (Issue 180.) I presume I would still have that issue. Unless the network commit changes afterward fixed it. https://github.com/cyoung/stratux/commit/5aca8adea2b4f8c6fe7baf312088bafa152a73be

So if Chris were going to make a branch for the UAT switch, he would probably have to include the instructions for the network commit too. (Jeff is also an iFly user, with a box and an app, IIRC. So he might be a good candidate for the wi-fi test here.)

2) I'm a total noob. Jeff's instructions look easy. And I saw someone's instructions in the reddit forum for how to compile a build with commits. But I'm a dumb noob: do I have to Select Option 1 after sudo su - to make the entire card one big Stratux partition? Or just exit out of the dialogue? From the looks of it, I compile in situ, on the Pi? Frankly, it would be easier to let Jeff do it and post his image in dropbox or something. (Am grinning.) Or easier to wait until v0.5b6 is out. But since others are chiming in, I'm game if you are. The worse that can happen is that I re-image back to 5b.

[Nokomis449]

(By the way, I'm Jeff) Ergo, you'll need to do the compile steps on an existing Stratux image. Therefore, there will be no "option 1". Also, I'm basically a noob myself at compiling with linux so someone correct me if I'm off base.

[kdknigga]

I don't think you should need to do:

rm -rf stratux git clone https://github.com/cyoung/stratux

Just go into /root/stratux and do 'git pull'.

On Fri, Jan 22, 2016, 21:03 Nokomis449 notifications@github.com wrote:

(By the way, I'm Jeff) Ergo, you'll need to do the compile steps on an existing Stratux image. Therefore, there will be no "option 1". Also, I'm basically a noob myself at compiling with linux so someone correct me if I'm off base.

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

[Ergonomicmike]

If it's as easy as "git pull," from inside Stratux (via SSH), then it sounds like even this caveman could do it.

[Nokomis449]

Same here. Just have some popcorn and patience, it takes several minutes to complete. Oh, you'll also need to kill dump1090 first. I forget the command I used; I think it was "killall -9 dump1090".

[cyoung]

@Ergonomicmike @Axtel4

Copy/paste the following into an SSH session (sudo to root first).

echo "arm_freq=900" >>/boot/config.txt
echo "sdram_freq=450" >>/boot/config.txt
echo "core_freq=450" >>/boot/config.txt
echo "net.core.rmem_max = 167772160" >>/etc/sysctl.conf
echo "net.core.rmem_default = 167772160" >>/etc/sysctl.conf
echo "net.core.wmem_max = 167772160" >>/etc/sysctl.conf
echo "net.core.wmem_default = 167772160" >>/etc/sysctl.conf

(wifi lockup related)

git pull ; make ; make install

[Axtel4]

@cyoung thanks. I updated with the WiFi lock up changes last night. I'll pull the Power Save commit and compile.

[Ergonomicmike]

Just so Chris knows how dumb I am, I didn't follow his instructions to the letter at first, and hadn't moved to the root directory first. After I got that figured out (thanks to @kdknigga's previous post) it seemed to work for a while. It downloaded a bunch of stuff, some which looked familiar.

But on make install, it said that I didn't specify a target. Am guessing I missed a Path somewhere? Am re-imaging and trying again.

(Jeff, if you get it working, you should video it and put it up on your youtube for us dummies.)

[Axtel4]

@cyoung I now have two AHRS switches on the settings page. Is the second (bottom) switch the Power Save Switch?

![switch](https://cloud.githubusercontent.com/assets/15059010/12528435/ccb55476-c15a-11e5-887b-d41900cb1b98.JPG Edit: The bottom AHRS Switch is for the "Power Setting."

[cyoung]

@Ergonomicmike - if you get an error, there's still something wrong. BTW @Nokomis449 " git clone https://github.com/cyoung/stratux --recursive" now. Thanks for continuing to work with it and know that soon we'll have a lot of this simplified with an update process that doesn't involve either this nor downloading a whole new image.

@Axtel4 - should be the last one, that was the intention at least. Check /etc/stratux.conf and you should see it toggle PowerSave between false/true.

[Ergonomicmike]

Yeah, I've tried it 5 times now. I found a thread in the reddit about how to compile an image (www.reddit.com/r/stratux/comments/3v9vsr/howto_building_stratux_from_source/) - I followed the last few steps there, except replaced the git clone with git pull (and the link to your github?). It seems to go okay - I get two errors during downloads about certificates being bad. (I use BIND on my desktop - don't know if that has trouble with some of these urls.) But when it comes to make install, I either get a "no target" error or another, longer, error about GO something that's missing. For now I'm just going to copy your echo commands into config for 5b and see if iFly stays connected for all of tomorrow's flight.

iFly released another beta tonight and says that they've improved some ADS-B issues too. So hopefully, the Wi-Fi problem will not be a problem while shooting PP ILS's.

[Axtel4]

@Ergonomicmike Here is my recipe for updating "on the fly." The basic tools needed are already in the image so (www.reddit.com/r/stratux/comments/3v9vsr/howto_building_stratux_from_source/) is no longer necessary.

This method assumes that the code will be compiled on the Stratux Raspberry Pi.

Download and install a fresh image. (i.e. 0.5b5)

Connect Stratux to the internet.

SSH into Stratux and log in. Note: you will need to access Stratux either with your computer via Ethernet or with a keyboard and monitor connected directly to Stratux.

Switch to Super User “Mode”: sudo su -

Kill the current Stratux session: pkill gen_gdl90 Note: If you are connected to Stratux via Wi-Fi you will lose your connection when gen_gdl90 is “killed.”

Go to the Stratux directory: cd /root/stratux i.e. pi@raspberrypi ~ $ sudo su - root@raspberrypi:~/stratux#

Pull the latest commits: git pull This may take a loooonnnngggg time. Note: If you are not in the Stratux directory you will get pull errors.

Set up the correct Path environment by sequentially entering the following export commands into your SSH session: export PATH=/root/go/bin:${PATH} export GOROOT=/root/go export GOPATH=/root/go_path

Compile the code: make Note: If the PATHs are not set correctly you will get make errors.

Install the code: make install

Reboot Stratux and enjoy the latest updates.

[Nokomis449]

Thanks for the step-by-step, Axtel4.

[skypuppy]

Thanks, Axtel4. Does this pull the most recent, beta code at the time of download? I notice that on the "official" stratux web page, 0.4r4 is still the image people download (as in most stable?)

Thanks, Skypuppy

On 01/23/2016 08:26 AM, Axtel4 wrote:

@Ergonomicmike https://github.com/Ergonomicmike Here is my recipe for updating "on the fly." The basic tools needed are already in the image so (www.reddit.com/r/stratux/comments/3v9vsr/howto_building_stratux_from_source/ http://www.reddit.com/r/stratux/comments/3v9vsr/howto_building_stratux_from_source/) is no longer necessary.

This method assumes that the code will be compiled on the Stratux Raspberry Pi.

Download and install a fresh image. (i.e. 0.5b5)

Connect Stratux to the internet.

SSH into Stratux and log in. Note: you will need to access Stratux either with your computer via Ethernet or with a keyboard and monitor connected directly to Stratux.

Switch to Super User “Mode”: |sudo su -|

Kill the current Stratux session: |pkill gen_gdl90| Note: If you are connected to Stratux via Wi-Fi you will lose your connection when gen_gdl90 is “killed.”

Go to the Stratux directory: |cd /root/stratux| i.e. pi@raspberrypi ~ $ sudo su - root@raspberrypi:~/stratux#

Pull the latest commits: |git pull| This may take a loooonnnngggg time. Note: If you are not in the Stratux directory you will get pull errors.

Set up the correct Path environment by sequentially entering the following export commands into your SSH session: |export PATH=/root/go/bin:${PATH}| |export GOROOT=/root/go| |export GOPATH=/root/go_path|

Compile the code: |make| Note: If the PATHs are not set correctly you will get |make| errors.

Install the code: |make install|

Reboot Stratux and enjoy the latest updates.

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

[Axtel4]

Does this pull the most recent, beta code at the time of download?

Yes it does. I have been using it since 0.4r2. It also leaves any of the conf files you may have modified intact. That can be a downside, but you can "import" updated conf settings just reference what @cyoung posted earlier for an example of the process:

Copy/paste the following into an SSH session (sudo to root first).

echo "arm_freq=900" >>/boot/config.txt echo "sdram_freq=450" >>/boot/config.txt echo "core_freq=450" >>/boot/config.txt echo "net.core.rmem_max = 167772160" >>/etc/sysctl.conf echo "net.core.rmem_default = 167772160" >>/etc/sysctl.conf echo "net.core.wmem_max = 167772160" >>/etc/sysctl.conf echo "net.core.wmem_default = 167772160" >>/etc/sysctl.conf

One thing I do is periodically is back up my builds using Win32DiskImager. This way I can easily revert back to a stable condition without rebuilding the code again if I do something to mess up my image. I can post something on that later if anyone is interested. (I am sure there is a Mac way to do it, but I wouldn't have a clue.)

Disclosure: I am not a programmer and I didn't know the Raspberry Pi exited until I stumbled across the Stratux project a few months ago while researching Pi Aware. I also want thank @cyoung and all the other folks here and on Reddit who had the patience to answer the questions I have had about the project as I stumble through the learning curve.

[Ergonomicmike]

Tnx @Axtel4 for the instructions. I had done most of that before, but I didn't have the 3 export paths.(For total noobs like me, be advised that when you do sudo su - for the first time, you get a Pi Configuration screen. Use the Tab key to jump to Finish, and hit Enter to click the button. Then do sudo su - again.)

Unfortunately, it's still not working for me. I hate to clog up this thread with code about what happened when I tried it, but in the case that I've found a bug for get pulling (for future releases that do it automagically), here's my screen. There are a few Fatal HTTP errors on the make - unable to download some stuff. (BTW, the git pull operation took only a few seconds. The make is the one that takes about 5 minutes of downloads.)

Edit: Bear with me as I try to get mark down to work for this code. (Update: This is the best I can do. Sorry.)

root@raspberrypi:~# pkill gen_gdl90
root@raspberrypi:~# cd stratux
root@raspberrypi:~/stratux# git pull
remote: Counting objects: 137, done.
remote: Compressing objects: 100% (18/18), done.
remote: Total 137 (delta 49), reused 47 (delta 47), pack-reused 72
Receiving objects: 100% (137/137), 54.68 KiB, done.
Resolving deltas: 100% (84/84), completed with 24 local objects.
From https://github.com/cyoung/stratux
   0f4fa6d..f5bed44  master     -> origin/master
   7ff7115..5979969  gh-pages   -> origin/gh-pages
* [new branch]      serialout  -> origin/serialout
* [new branch]      simplify_startstop -> origin/simplify_startstop
Fetching submodule linux-mpu9150
remote: Counting objects: 12, done.
remote: Total 12 (delta 7), reused 7 (delta 7), pack-reused 5
Unpacking objects: 100% (12/12), done.
From git://github.com/cyoung/linux-mpu9150
   f2e58a0..af55080  master     -> origin/master
Updating 0f4fa6d..f5bed44
Fast-forward
 .gitignore                         |    1 +
 CONTRIBUTING.md                    |    3 +
 LICENSE                            |    4 +-
 Makefile                           |    4 -
 README.md                          |    3 +
 docs/UBX-CFG-default.txt           |   76 ++++++++
 docs/UBX-CFG-stratux-38400baud.txt |   76 ++++++++
 image/spindle/wheezy-stage4        |   13 ++
 init.d-stratux                     |    7 +-
 linux-mpu9150                      |    2 +-
 main/gen_gdl90.go                  |   39 +++-
 main/managementinterface.go        |   21 +++
 main/monotonic.go                  |    9 +
 main/network.go                    |   28 ++-
 main/ry835ai.go                    |   37 ++--
 main/sdr.go                        |   62 +++++--
 main/traffic.go                    |    9 +
 main/uibroadcast.go                |   10 ++
 mpu6050/mpu6050.go                 |    4 +-
 web/plates/js/settings.js          |   14 +-
 web/plates/settings.html           |  349 +++++++++++++++++++-----------------
 21 files changed, 558 insertions(+), 213 deletions(-)
 create mode 100644 CONTRIBUTING.md
 create mode 100644 docs/UBX-CFG-default.txt
 create mode 100644 docs/UBX-CFG-stratux-38400baud.txt
root@raspberrypi:~/stratux# export PATH=/root/go/bin:${PATH}
root@raspberrypi:~/stratux# export GOROOT=/root/go
root@raspberrypi:~/stratux#  export GOPATH=/root/go_path
root@raspberrypi:~/stratux# make
make xdump978
make[1]: Entering directory '/root/stratux'
 cd dump978 && make lib
make[2]: Entering directory '/root/stratux/dump978'
gcc -c -O2 -g -Wall -Werror -Ifec -fpic -DBUILD_LIB=1 dump978.c fec.c fec/decode_rs_char.c     fec/init_rs_char.c
gcc -shared -lm -o ../libdump978.so dump978.o fec.o decode_rs_char.o init_rs_char.o
make[2]: Leaving directory '/root/stratux/dump978'
sudo cp -f ./libdump978.so /usr/lib/libdump978.so
make[1]: Leaving directory '/root/stratux'
make xdump1090
make[1]: Entering directory '/root/stratux'
git submodule update --init
Submodule 'dump1090' () registered for path 'dump1090'
Submodule 'linux-mpu9150' () registered for path 'linux-mpu9150'
Submodule path 'linux-mpu9150': checked out 'af550804eff32bbef740bbaeb62eb0b4094496c7'
cd dump1090 && make
make[2]: Entering directory '/root/stratux/dump1090'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/root/stratux/dump1090'
make[1]: Leaving directory '/root/stratux'
make xlinux-mpu9150
make[1]: Entering directory '/root/stratux'
git submodule update --init
Submodule 'dump1090' () registered for path 'dump1090'
Submodule 'linux-mpu9150' () registered for path 'linux-mpu9150'
cd linux-mpu9150 && make -f Makefile-native-shared
make[2]: Entering directory '/root/stratux/linux-mpu9150'
gcc -Wall -fPIC -DEMPL_TARGET_LINUX -DMPU6050 -I eMPL -I glue -c eMPL/inv_mpu.c
eMPL/inv_mpu.c:2360:12: warning: ‘setup_compass’ defined but not used [-Wunused-function]
gcc -Wall -fPIC -DEMPL_TARGET_LINUX -DMPU6050 -I eMPL -I glue -c eMPL/inv_mpu_dm            p_motion_driver.c
gcc -Wall -fPIC -DEMPL_TARGET_LINUX -DMPU6050 -I eMPL -I glue -c glue/linux_glue.c
gcc -Wall -fPIC -DEMPL_TARGET_LINUX -DMPU6050 -I eMPL -I glue -c mpu9150/mpu9150.c
gcc -Wall -fPIC -DEMPL_TARGET_LINUX -DMPU6050 -c mpu9150/quaternion.c
gcc -Wall -fPIC -DEMPL_TARGET_LINUX -DMPU6050 -c mpu9150/vector3d.c
gcc -Wall -fPIC -I eMPL -I glue -I mpu9150 -DEMPL_TARGET_LINUX -DMPU6050 -c libimu.c
gcc libimu.o inv_mpu.o inv_mpu_dmp_motion_driver.o linux_glue.o mpu9150.o quaternion.o vector3d.o -shared -o libimu.so
sudo cp -f ./libimu.so /usr/lib/libimu.so
gcc -Wall -fPIC -I eMPL -I glue -I mpu9150 -DEMPL_TARGET_LINUX -DMPU6050 -c imucal.c
gcc -Wall -fPIC inv_mpu.o inv_mpu_dmp_motion_driver.o linux_glue.o mpu9150.o qua            ternion.o     vector3d.o imucal.o -lm -o imucal
make[2]: Leaving directory '/root/stratux/linux-mpu9150'
make[1]: Leaving directory '/root/stratux'
make xgen_gdl90
make[1]: Entering directory '/root/stratux'
go get -t -d -v ./main ./test ./linux-mpu9150/mpu ./godump978 ./mpu6050 ./uatparse
github.com/dustin/go-humanize (download)
github.com/jpoirier/gortlsdr (download)
github.com/kidoman/embd (download)
github.com/golang/glog (download)
github.com/tarm/serial (download)
Fetching https://golang.org/x/net/icmp?go-get=1
Parsing meta tags from https://golang.org/x/net/icmp?go-get=1 (status code 200) 
get "golang.org/x/net/icmp": found meta tag main.metaImport{Prefix:"golang.org/x/net", VCS:"git", RepoRoot:"https://go.googlesource.com/net"} at https://golang.org/x/net/icmp?go-get=1
get "golang.org/x/net/icmp": verifying non-authoritative meta tag
Fetching https://golang.org/x/net?go-get=1
Parsing meta tags from https://golang.org/x/net?go-get=1 (status code 200) golang.org/x/net (download) # cd .; git clone https://go.googlesource.com/net /root/go_path/src/golang.org/x/net
Cloning into '/root/go_path/src/golang.org/x/net'... error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://go.googlesource.com/net/info/refs
fatal: HTTP request failed
package golang.org/x/net/icmp: exit status 128
Fetching https://golang.org/x/net/ipv4?go-get=1
Parsing meta tags from https://golang.org/x/net/ipv4?go-get=1 (status code 200)
get "golang.org/x/net/ipv4": found meta tag main.metaImport{Prefix:"golang.org/x/net", VCS:"git", RepoRoot:"https://go.googlesource.com/net"} at https://golang.org/x/net/ipv4?go-get=1get "golang.org/x/net/ipv4": verifying non-authoritative meta tag package golang.org/x/net/ipv4: cannot find package "golang.org/x/net/ipv4" in any of: /root/go/src/golang.org/x/net/ipv4 (from $GOROOT) /root/go_path/src/golang.org/x/net/ipv4 (from $GOPATH)
Fetching https://golang.org/x/net/websocket?go-get=1
Parsing meta tags from https://golang.org/x/net/websocket?go-get=1 (status code 200)
get "golang.org/x/net/websocket": found meta tag main.metaImport{Prefix:"golang.org/x/net",     VCS:"git", RepoRoot:"https://go.googlesource.com/net"} at https://golang.org/x/net/websocket?go-get=1
get "golang.org/x/net/websocket": verifying non-authoritative meta tag package golang.org/ /net/websocket: cannot find package "golang.org/x/net/websocket" in any of: /root/go/src/golang.org/x/net/websocket (from $GOROOT) /root/go_path/src/golang.org/x/net/websocket (from $GOPATH)
github.com/gonum/plot (download)
github.com/gonum/floats (download)
github.com/gonum/internal (download)
github.com/golang/freetype (download)
# cd .; git clone https://github.com/golang/freetype /root/go_path/src/github.com/golang/freetype
Cloning into '/root/go_path/src/github.com/golang/freetype'...error: The requested URL returned error: 403 while accessing https://github.com/golang/freetype/info/refs
fatal: HTTP request failed
package github.com/golang/freetype: exit status 128
package github.com/golang/freetype/truetype: cannot find package "github.com/golang/freetype/truetype" in any of: /root/go/src/github.com/golang/freetype/truetype (from $GOROOT /root/go_path/src/github.com/golang/freetype/truetype (from $GOPATH)
Fetching https://golang.org/x/image/math/fixed?go-get=1
Parsing meta tags from https://golang.org/x/image/math/fixed?go-get=1 (status code 200) get "golang.org/x/image/math/fixed": found meta tag main.metaImport{Prefix:"golang.org/x/image", VCS:"git", RepoRoot:"https://go.googlesource.com/image"} at https://golang.org/x/image/math/fixed?go-get=1
get "golang.org/x/image/math/fixed": verifying non-authoritative meta tag
Fetching https://golang.org/x/image?go-get=1
Parsing meta tags from https://golang.org/x/image?go-get=1 (status code 200 golang.org/x/image (download)
# cd .; git clone https://go.googlesource.com/image /root/go_path/src/golang.org/x/image
Cloning into '/root/go_path/src/golang.org/x/image'...error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://go.googlesource.com/image/info/refs
fatal: HTTP request failed
package golang.org/x/image/math/fixed: exit status 128
github.com/llgcode/draw2d (download) package github.com/golang/freetype/raster: cannot find package "github.com/golang/freetype/raster" in any of: /root/go/src/github.com/golang/freetype/raster (from $GOROOT) /root/go_path/src/github.com/golang/freetype/raster (from $GOPATH)
Fetching https://golang.org/x/image/draw?go-get=1
Parsing meta tags from https://golang.org/x/image/draw?go-get=1 (status code 200)

get "golang.org/x/image/draw": found meta tag main.metaImport{Prefix:"golang.org/x/image", VCS:"git", RepoRoot:"https://go.googlesource.com/image"} at https://golang.org/x/image/draw?go- get=1 get "golang.org/x/image/draw": verifying non-authoritative meta tag package golang.org/x/image/draw: cannot find package "golang.org/x/image/draw" in any of: /root/go/src/golang.org/x/image/draw (from $GOROOT) /root/go_path/src/golang.org/x/image/draw (from $GOPATH) Fetching https://golang.org/x/image/font?go-get=1 Parsing meta tags from https://golang.org/x/image/font?go-get=1 (status code 200) get "golang.org/x/image/font": found meta tag main.metaImport{Prefix:"golang.org/x/image", VCS:"git", RepoRoot:"https://go.googlesource.com/image"} at https://golang.org/x/image/font?go-get=1 get "golang.org/x/image/font": verifying non-authoritative meta tag package golang.org/x/image/font: cannot find package "golang.org/x/image/font" in any of: /root/go/src/golang.org/x/image/font (from $GOROOT) /root/go_path/src/golang.org/x/image/font (from $GOPATH) Fetching https://golang.org/x/image/math/f64?go-get=1 Parsing meta tags from https://golang.org/x/image/math/f64?go-get=1 (status code 200) get "golang.org/x/image/math/f64": found meta tag main.metaImport{Prefix:"golang.org/x/image", VCS:"git", RepoRoot:"https://go.googlesource.com/image"} at https ://golang.org/x/image/math/f64?go-get=1 get "golang.org/x/image/math/f64": verifying non-authoritative meta tag package golang.org/x/image/math/f64: cannot find package "golang.org/x/image/math/f64" in any of: /root/go/src/golang.org/x/image/math/f64 (from $GOROOT) /root/go_path/src/golang.org/x/image/math/f64 (from $GOPATH) Fetching https://golang.org/x/image/tiff?go-get=1 Parsing meta tags from https://golang.org/x/image/tiff?go-get=1 (status code 200) get "golang.org/x/image/tiff": found meta tag main.metaImport{Prefix:"golang.org /x/image", VCS:"git", RepoRoot:"https://go.googlesource.com/image"} at https://golang.org/x/image/tiff?go- get=1 get "golang.org/x/image/tiff": verifying non-authoritative meta tag package golang.org/x/image/tiff: cannot find package "golang.org/x/image/tiff" in any of: /root/go/src/golang.org/x/image/tiff (from $GOROOT/ /root/go_path/src/golang.org/x/image/tiff (from $GOPATH) bitbucket.org/zombiezen/gopdf (download) github.com/ajstarks/svgo (download) github.com/kellydunn/golang-geo (download) github.com/erikstmartin/go-testdb (download) github.com/kylelemons/go-gypsy (download) github.com/lib/pq (download) github.com/ziutek/mymysql (download)

cd .; git clone https://github.com/ziutek/mymysql /root/go_path/src/github.com//ziutek/mymysql

Cloning into '/root/go_path/src/github.com/ziutek/mymysql'... error: The requested URL returned error: 403 while accessing https://github.com/ziutek/mymysql/info/refs fatal: HTTP request failed package github.com/ziutek/mymysql/godrv: exit status 128 Makefile:16: recipe for target 'xgen_gdl90' failed make[1]: * [xgen_gdl90] Error 1 make[1]: Leaving directory '/root/stratux' Makefile:10: recipe for target 'all' failed make: * [all] Error 2 root@raspberrypi:~/stratux# make install cp -f gen_gdl90 /usr/bin/gen_gdl90 cp: cannot stat `gen_gdl90': No such file or directory Makefile:67: recipe for target 'install' failed make: *\ [install] Error 1 root@raspberrypi:~/stratux#

[Axtel4]

@Ergonomicmike Question, was the latest attempt for the previous build attempt (www.reddit.com/r/stratux/comments/3v9vsr/howto_building_stratux_from_source/) build, or from a fresh 0.5r5 image install?

I think I remember seeing those errors when I first built my Go from the source code using the @ssokol method (https://github.com/ssokol/stratux/wiki/Compiling-Stratux-on-the-Raspberry-Pi-2). However, when I pulled a later image and complied from there I didn't remember seeing those errors.

If I get some time this weekend I'll pull another image and try the build process again from a fresh start.

[Ergonomicmike]

Hi @Axtel4. Fresh 0.5b5 image. Do I need to do it from the last official release? (.4r4?)

[Axtel4]

No, your can jump in at the 0.5b5 image. That image contains the 0.4r4 code plus all the subsequent changes. Note: Going this route you will now bee on the "cutting edge" and will leave the security of the released version. But, there were a lot of features and improvements added since 0.4r4.

I pulled and built up from a fresh 0.5b5 image on 08-Jan. Since that point I have rolled in the commits from Jan 05 through today (Jan 22). I pulled the 0.5r5 image to compare against my builds from 0.4r2 as a sanity check. The builds were equivalent so I archived my 0.4r2 based builds and proceeded with updating from the based 0.5b5 build since it was fresher.

[Nokomis449]

My "make" was failing, and I tried several times with the same errors - the "Go" certificate was invalid. Then I banged my head on the brick several times when I realized I was making the noobest of noob mistakes. I hadn't set the time on the Pi, so as far as the Pi knew, the date on the Go certificate wasn*t valid until way in the future. I set the time correctly, and everything worked. I post this just in case someone else has the same issue.

[Ergonomicmike]

I'm guessing that is my issue too. So how do noobs set the time on the Pi?

[Nokomis449]

Try sudo date -s "Jan 23 21:51" (leave the quotes). Like magic, mine knew the year! There's several other formats, try "man date" for more info.

[Axtel4]

I had a chance to do some more testing today. Here is what I observed. UAT Power Save Part 2

There is a correlation between the Power Save feature and marginal signal performance. With moderate to strong signals, the performance may not be noticeable to the user. However, as the receive signal moves closer to the receiver noise floor the change in performance with the Power Save feature would be perceived as “poor” UAT reception. The Power Save feature is useful for instances where a user is looking for maximum endurance of Stratux in portable operations. However, there is a trade off with weak signal performance when using the feature. Hopefully this data will aid the Stratux user in determining the best use of the Power Save feature for their particular situation.

tl;dr Today presented a good opportunity to go to the airport for some testing. With the low IFR ceilings and low visibility there was not any UAT air traffic to complicate analyzing the tower reception. The test set up was as follows:

Test set-up: Stratux was placed on the dashboard of my truck and the truck was parked approximately 2 miles from and with line of sight to the UAT tower. The Stratux UAT antenna was the same antennas used in the Issue 203 analysis. A variable attenuator, a fixed value 10 dB pad and 12 inches is coax was placed between the UAT Whip antenna and the 978 UAT SDR dongle. Three devices (two smart phones and a tablet) were connected to Stratux to monitor performance. Two devices monitored various Web UI pages while the third device monitored the Stratux Weather data via an EFB App.

Reception Baseline: The original intent was to use the signal reading on the Web UI Tower page to gage the receiver performance. However, it proved to be too inconsistent to provide any useful data, but a good indication of the Stratux receive performance was found to be the Current UAT Message message bar on the Status Web UI page.

The first objective was to determine if there was more than one signal path to the 978 UAT dongle. If a signal is strong enough to enter the 978 UAT via a path other than the antenna port any other measurements would be suspect. Stratux was set up in stock configuration and allowed to acquire and stabilize with the UAT Tower signal. The UAT antenna was removed and the receive parameters were monitored and were found to drop to a no signal condition with the antenna removed. The next step was to determine the amount of attenuation was required to present a below Minimum Discernible Signal (MSD) level to the dongle. Stratux was reconnected to the antenna and attenuators in the following final test configuration:

Stratux > 12” Coax > 10 dB pad > Veneer Adjustable Variable Attenuator > UAT Whip Antenna.

Power Save OFF / ON - Minimum Signal Level: In the above test configuration the “Power Save” switch was set to “OFF” and the Variable Attenuator was adjusted until a rate of one UAT message per minute was observed on the Stratux Status page. After the reference level was established, the “Power Save” switch was placed in the “ON” position and the message rate was observed as falling to 0 messages per minute. The variable attenuator was adjusted to increase the signal level to the UAT dongle until the messages rate stabilized at one UAT message per minute. This was a repeated a total of five runs and the attenuation level was averaged. The average attenuation between Power Saving OFF to ON was found to be approximately 2.72 dB.

Power Save OFF / ON - Weather Data: Next objective was to quantify the decoding and display of Weather Data on the EFB. After some experimentation it was found a message rate of 50 messages / minute provided a reasonable interval to receive and decode weather data with a time period of less than two minutes. The signal level was set for a rate of 50 messages / min with the Power Save switch to OFF while monitoring the Status page. Stratux was rebooted and the Web IU weather page and EFB App was monitored for weather data. Stratux would display weather in the Web UI / EFB App within 100 seconds average in 5 runs. The Power Save was enabled and the above process was repeated. The average time for the Web UI / EFB App to display weather was in excess of 7 minutes.

Thoughts: It appears the Power Save feature doesn’t decrease the sensitivity, but reduces the amount of data available for decode and presentation of the data to a client application during a given period of time. At low signal levels, the message rate is naturally reduced due to the signal to noise ration of the desired signal. Enabling the Power Save feature further reduces the message rate to the client by 40% to 50% by reducing the amount of time Stratux is outputting data to the client. With the reduced message rate, the client app has to “wait” longer to have enough data to present to the user. Under moderate to high signal reception, there is a high enough message rate that the reduction is not “noticed” by the client and ultimately by the end user.

[skypuppy]

I'm kinda working on a time-setter that will run before any of the stratux software starts, so it get's complicated rapidly. Basically I try in this order:

0. if the nntp servers available (ethernet connected to the Pi, done, and continue starting stratux. (This is the default way the pi UNIX is setup, btw.)
1. look for a real-time clock (RTC) and if found set the system time,
2. get time from the gps, if valid. Variables here are just how long do we wait if we don't have an instant fix? A few seconds? Up to 4 minutes? 15? even 45? My guess is a few seconds.
3. If all else fails, use the web interface to set the clock via the connected tablet/phone, etc. This is probably the easiest as nearly all devices that stratux reports to have their own RTC. It involves putting a small app the Pi AND on the tablet, though. So I don't know if people will agree to that. It is my preferred method. 3b. If the tablet stratux talks to does not have an RTC, then ask the user for the time of day and send that to the Pi.

What do you guys think?

Skypuppy

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

I'm guessing that is my issue too. So how do noobs set the time on the Pi?

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

[skypuppy]

Excellent work again, @Axtel4.

On 01/23/2016 10:13 PM, Axtel4 wrote:

I had a chance to do some more testing today. Here is what I observed. UAT Power Save Part 2

There is a correlation between the Power Save feature and marginal signal performance. With moderate to strong signals, the performance may not be noticeable to the user. However, as the receive signal moves closer to the receiver noise floor the change in performance with the Power Save feature would be perceived as “poor” UAT reception. The Power Save feature is useful for instances where a user is looking for maximum endurance of Stratux in portable operations. However, there is a trade off with weak signal performance when using the feature. Hopefully this data will aid the Stratux user in determining the best use of the Power Save feature for their particular situation.

tl;dr Today presented a good opportunity to go to the airport for some testing. With the low IFR ceilings and low visibility there was not any UAT air traffic to complicate analyzing the tower reception. The test set up was as follows:

Test set-up: Stratux was placed on the dashboard of my truck and the truck was parked approximately 2 miles from and with line of sight to the UAT tower. The Stratux UAT antenna was the same antennas used in the Issue 203 analysis. A variable attenuator, a fixed value 10 dB pad and 12 inches is coax was placed between the UAT Whip antenna and the 978 UAT SDR dongle. Three devices (two smart phones and a tablet) were connected to Stratux to monitor performance. Two devices monitored various Web UI pages while the third device monitored the Stratux Weather data via an EFB App.

Reception Baseline: The original intent was to use the signal reading on the Web UI Tower page to gage the receiver performance. However, it proved to be too inconsistent to provide any useful data, but a good indication of the Stratux receive performance was found to be the Current UAT Message message bar on the Status Web UI page.

The first objective was to determine if there was more than one signal path to the 978 UAT dongle. If a signal is strong enough to enter the 978 UAT via a path other than the antenna port any other measurements would be suspect. Stratux was set up in stock configuration and allowed to acquire and stabilize with the UAT Tower signal. The UAT antenna was removed and the receive parameters were monitored and were found to drop to a no signal condition with the antenna removed. The next step was to determine the amount of attenuation was required to present a below Minimum Discernible Signal (MSD) level to the dongle. Stratux was reconnected to the antenna and attenuators in the following final test configuration:

Stratux > 12” Coax > 10 dB pad > Veneer Adjustable Variable Attenuator

UAT Whip Antenna.

Power Save OFF / ON - Minimum Signal Level: In the above test configuration the “Power Save” switch was set to “OFF” and the Variable Attenuator was adjusted until a rate of one UAT message per minute was observed on the Stratux Status page. After the reference level was established, the “Power Save” switch was placed in the “ON” position and the message rate was observed as falling to 0 messages per minute. The variable attenuator was adjusted to increase the signal level to the UAT dongle until the messages rate stabilized at one UAT message per minute. This was a repeated a total of five runs and the attenuation level was averaged. The average attenuation between Power Saving OFF to ON was found to be approximately 2.72 dB.

Power Save OFF / ON - Weather Data: Next objective was to quantify the decoding and display of Weather Data on the EFB. After some experimentation it was found a message rate of 50 messages / minute provided a reasonable interval to receive and decode weather data with a time period of less than two minutes. The signal level was set for a rate of 50 messages / min with the Power Save switch to OFF while monitoring the Status page. Stratux was rebooted and the Web IU weather page and EFB App was monitored for weather data. Stratux would display weather in the Web UI / EFB App within 100 seconds average in 5 runs. The Power Save was enabled and the above process was repeated. The average time for the Web UI / EFB App to display weather was in excess of 7 minutes.

Thoughts: It appears the Power Save feature doesn’t decrease the sensitivity, but reduces the amount of data available for decode and presentation of the data to a client application during a given period of time. At low signal levels, the message rate is naturally reduced due to the signal to noise ration of the desired signal. Enabling the Power Save feature further reduces the message rate to the client by 40% to 50% by reducing the amount of time Stratux is outputting data to the client. With the reduced message rate, the client app has to “wait” longer to have enough data to present to the user. Under moderate to high signal reception, there is a high enough message rate that the reduction is not “noticed” by the client and ultimately by the end user.

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

[Ergonomicmike]

Okay, I finally got make install to work, thanks to @Nokomis449 and @Axtel4. In true "hacker" form (which, by my definition, is blindly shotgunning to get something to work without really understanding what you're doing), I don't know what I did different that made the difference.

Before trying the build process again, I set the Pi time to current UTC, hacking my way thru the date command. I ran the 3 PATH commands. Then I tried make again. I still got 2 download errors. So then I re-applied the 3 PATH commands. Then I ran make again. It completed really quick. So I guess it picked up the two remaining downloads. To my surprise, it did the make install quickly after that.

This build process will need to be a bit more robust for it to work automagically for your typical user. If the current time is truly required to get the make downloads, then per @skypuppy's suggestions, an Internet connection to nntp time servers, or to time from GPS, or a way to set time from the UI will be necessary. (Or, this is really wild - tune the SDR to 10 MHz to get WWV like those cheap self-setting "atomic" clocks?)

[Ergonomicmike]

Question: (@cyoung) Now that I have the new build with the Power Save switch, which way does the switch work? When the second AHRS switch is "off" (to the left) is that Power Save off? I'm confused because when the switch is to the left, that is the default. And I could make an argument that the default is power savings on.

[Axtel4]

To the left is switch off. If you navigate a Web UI page to 192.168.10.1/getSettings or /192.168.10.1/getStatus you should see the Power Save setting togglevwith the change of the switch. You may need to refresh your browser session to see the setting change.

Edit: 192.168.10.1/getSettings will give you client status (LastUnreachable) and the power save setting (PowerSave).

{"UAT_Enabled":true,"ES_Enabled":true,"GPS_Enabled":true,"NetworkOutputs":[{"Conn":null,"Ip":"","Port":43211,"Capability":5,"LastUnreachable":"0001-01-01T00:00:00Z","SleepFlag":false},{"Conn":null,"Ip":"","Port":49002,"Capability":2,"LastUnreachable":"0001-01-01T00:00:00Z","SleepFlag":false}],"AHRS_Enabled":true,"DEBUG":false,"ReplayLog":false,"PPM":40,"OwnshipModeS":"F00000","WatchList":"","PowerSave":true}

[duecedriver]

@Axtel4 how does the power savings algorithms tie in with the fact that certain products update at different time intervals and that certain data is only avail from certain types or towers.. I.e. Low, surface, high.. Etc or that you may want messages simultaneously form them all even the weakest one

https://bruceair.wordpress.com/2014/09/09/flight-information-service-fis-b-weather-and-info-in-the-cockpit/

[bradanlane]

if we want the UAT power savings feature to get into the master, I'm happy to do the small amount of cleanup to the UI (eg, better labeling, context help, etc.).

Since I have had to code out the power savings for my use, I'm happy to have the switch in the main code stream ... assuming the feature will persist permanently or for some extended period.

[cyoung]

No switch except for testing. It either works as intended or not, so it's either in or out. I assume your reason for turning it off is the same as above - reception issues?

[bradanlane]

I turned it off for three reasons:

1. I was seing odd behavior and it was hard to diagnose if the 978 received was being toggled
2. in spotty coverage I was missing messages
3. under real world usage, it should only get triggered when on the ground