realistic hardware / software ahrs goals

[duecedriver]

With discussions started in multiple threads at this point with issues stemming from finding suitable hardware and coding or interpreting output to utilize solid state gyros and magnetometers for the purpose of backup attitude, it is important to baseline what it is we really NEED not necessarily what is available. While it would be possible to design a system with full inertial navigation functions I dont believe we need it or the hassle.

This should speed development by focusing on the minimal path to success resulting in usable hardware.

What we need

1. AHRS - A solution to provide an accurate and stable backup artificial attitude output recognizable by existing EFB software packages (either implement imu code on raw sensors or select a package with build in linear acceleration correction)
2. GPS - a quality GPSS solution with no less than 5hz (GDS90 standard) refresh rate, WAAS/LAAS, that is either on board with the gyro package or, ideally usb external to permit remote mounting in a suitable location. Benefit of remote USB solutions is their output usually conforms to industry standard data streams and we dont have power stability or signal shape or interference issues on GPIO for such (critical) high frequency data. Must permit storage of last known almanac and ephemeris data for rapid warm and hot restarts and permit user input for start location on cold starts. Usage of iPad internal GPS either as primary or kalman filtered into the solution with the external source to compare derived accuracy. 5hz also provides rapid enough course change and track that heading is derived in perceived real time with minimal lag further negating a magnetometer heading.
3. Selectivity - ability to select via stratux web interface which components are installed. 1/2 radio, gps, ahrs etc so users can build a unit that fits their needs.
4. Compatible output streams - stratux outputs as close to or conformal to industry aviation data bus standards. GDL88/90 or ARINC so that all data streams leaving the unit work with the largest compliment of hardware. If this is not possible or practical due to third party developers of current EFB software not using said industry standards perhaps translators are needed to stratux sends the appropriately reformatted message traffic specific to each client attached. most EFB developers code to specific or multiple hardware devices because the all output differently. IE have a standard data stream that can be chameleonized specific to the attached client/s. Stratux is already gaining traction with several EFBs however those developers with their own hardware will inevitably attempt to lock out this project and will likely patent their data stream if they have not already. Industry standards on file with the FAA have to remain open, hence no lockout. If we want stratux to work will every software package it may have to emulate as many streams as possible.. or we could venture off and develop to the standard and let the software makers add our data stream to their products.

What we dont need and why

1. Magnetic heading - Unless we feel that our gyro panel based heading and our whisky is going to fail as well as our Stratux gps source.. the hassles with implementing a magnetometer are huge: mounting, power routing, nearby ferris interference, physical vibration/movement, etc just dont warrant the effort and even with perfect code, most peoples placement / design / and usage would preclude it from providing anything useful. Provided the mems gyros dont need to see it for their AHRS calcs... we dont NEED it. Most portable software is just looking for and displaying GPS track heading anyway.
2. Pressure alt - again, unless we feel that we are going to see a dual failure of static gauges and the GPS constellation... its really not needed. In the aircraft, changes in window, vent, heating etc will effect the internal pressure of the aircraft and will make the output suspect. additionally, software would have to allow for barometric correction (ie. ability to set local QNH) and it must be calibrated to be of use in EACH application.. HASSLE dump it GPS altitude is more than fine now with 1-3m resolution or better in GNSS / WASS/LAAS implementations.
3. INU functionality - pure position derived via absolute motion analysis is really becoming outdated unless being used in autopilot application. INU derived position is over 900m out after just one hour without kalman filtered GPS updates. Again, unless we feel that the GPS is going to fail and most of us are using a iPad with gps installed as backup. If external usb GNSS solutions are used they are cheap and easy to swap out in flight vs a board in the unit. keeping the gps out of the case reduces size, heat, and placement limitations.

skypuppy has made mention of a quality chip that has onboard quaternion and sensor fusion that negates the need to use such code in stratux... any other hardware out there that warrants a look? We should find a hardware solution that meets the need, easily avail, and cost effective.. baseline it as the hardware and code against it!!

The MPU6050 is a 6 degree of freedom chip from Invensense, containing a tri axis accelerometer and a tri axis gyroscope. It is operated off a 3.3V supply, and communicates via I2C at a maximum speed of 400kHz. This chip is also available in an SPI package known as the MPU6000, which I would have preferred to use given the choice due to the much higher throughput of SPI. However for some reason the world seems to prefer the I2C version, so this was the only version I could find with a breakout board.

The main pros of this chip are as follows:

Selectable +-2/4/8/16g accelerometer range Selectable +-250/500/1000/2000 degrees/s gyroscope range 16 bit output from both sensors Gyroscope linear acceleration sensitivity of 0.1 degrees/s, a vast improvement over the tri axis gyroscopes of other companies. Low noise on both outputs, see the datasheet Data output rate up to 1000Hz, although the built in digital low pass filter has a maximum corner frequency of 256Hz. However, the register map documentation mentions turning off the DLPF, so I'm not sure which to believe at the moment. Another feature of this chip is the onboard digital motion processor (DMP). In theory this can be used to directly output euler angles, quaternions, or a direction cosine matrix, and even perform filtering along with integrating the data from an external I2C compass. This sounds great on paper, but in reality Invensense have been very reluctant to provide any sort of source code or documention on how to use the DMP unless you sign a non disclosure agreement, so as far as I know nobody has really got this working to it's full potential as of yet.

To summarise, this chip is a massive improvement over all the previous sensors I have used, and it comes in a single package. There is even a 9DoF MPU9150 version coming, which I intend to acquire as soon as it's released in 2012 Q2.

let the discussion begin

[duecedriver]

For Internal GPS with optional external antenna - this board has possibilities..

Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3

Very small, greater than 10hz updates, WAAS, backup batt, good filtering, low voltage protection

https://www.adafruit.com/product/746

TECHNICAL DETAILS

Satellites: 22 tracking, 66 searching Patch Antenna Size: 15mm x 15mm x 4mm Update rate: 1 to 10 Hz Position Accuracy: < 3 meters (all GPS technology has about 3m accuracy) Velocity Accuracy: 0.1 meters/s Warm/cold start: 34 seconds Acquisition sensitivity: -145 dBm Tracking sensitivity: -165 dBm Maximum Velocity: 515m/s Vin range: 3.0-5.5VDC MTK3339 Operating current: 25mA tracking, 20 mA current draw during navigation Output: NMEA 0183, 9600 baud default DGPS/WAAS/EGNOS supported FCC E911 compliance and AGPS support (Offline mode : EPO valid up to 14 days ) Up to 210 PRN channels Jammer detection and reduction Multi-path detection and compensation Revision History:

As of 8/10/2014 we are shipping with firmware v. 5632 which improves altitude calculations and stability. It is equivalent in all other functionality and is a drop-in replacement. Breakout board details:

Weight (not including coin cell or holder): 8.5g Dimensions (not including coin cell or holder): 25.5mm x 35mm x 6.5mm / 1.0" x 1.35" x 0.25"

The breakout is built around the MTK3339 chipset, a no-nonsense, high-quality GPS module that can track up to 22 satellites on 66 channels, has an excellent high-sensitivity receiver (-165 dB tracking!), and a built in antenna. It can do up to 10 location updates a second for high speed, high sensitivity logging or tracking. Power usage is incredibly low, only 20 mA during navigation.

Best of all, we added all the extra goodies you could ever want: a ultra-low dropout 3.3V regulator so you can power it with 3.3-5VDC in, 5V level safe inputs, ENABLE pin so you can turn off the module using any microcontroller pin or switch, a footprint for optional CR1220 coin cell to keep the RTC running and allow warm starts and a tiny bright red LED. The LED blinks at about 1Hz while it's searching for satellites and blinks once every 15 seconds when a fix is found to conserve power. If you want to have an LED on all the time, we also provide the FIX signal out on a pin so you can put an external LED on.

Two features that really stand out about version 3 MTK3339-based module is the external antenna functionality and the the built in data-logging capability. The module has a standard ceramic patch antenna that gives it -165 dB sensitivity, but when you want to have a bigger antenna, you can snap on any 3V active GPS antenna via the uFL connector. The module will automatically detect the active antenna and switch over! Most GPS antennas use SMA connectors so you may want to pick up one of our uFL to SMA adapters.

The other cool feature of the new MTK3339-based module (which we have tested with great success) is the built in datalogging ability. Since there is a microcontroller inside the module, with some empty FLASH memory, the newest firmware now allows sending commands to do internal logging to that FLASH. The only thing is that you do need to have a microcontroller send the "Start Logging" command. However, after that message is sent, the microcontroller can go to sleep and does not need to wake up to talk to the GPS anymore to reduce power consumption. The time, date, longitude, latitude, and height is logged every 15 seconds and only when there is a fix. The internal FLASH can store about 16 hours of data, it will automatically append data so you don't have to worry about accidentally losing data if power is lost. It is not possible to change what is logged and how often, as its hardcoded into the module but we found that this arrangement covers many of the most common GPS datalogging requirements.

Comes with one fully assembled and tested module, a piece of header you can solder to it for breadboarding, and a CR1220 coin cell holder

[duecedriver]

Adafruit 9-DOF Absolute Orientation IMU Fusion Breakout - BNO055 ~ $35

Absolute Orientation (Euler Vector, 100Hz) Three axis orientation data based on a 360° sphere Absolute Orientation (Quaterion, 100Hz) Four point quaternion output for more accurate data manipulation Angular Velocity Vector (100Hz) Three axis of 'rotation speed' in rad/s Acceleration Vector (100Hz) Three axis of acceleration (gravity + linear motion) in m/s^2 Magnetic Field Strength Vector (20Hz) Three axis of magnetic field sensing in micro Tesla (uT) Linear Acceleration Vector (100Hz) Three axis of linear acceleration data (acceleration minus gravity) in m/s^2 Gravity Vector (100Hz) Three axis of gravitational acceleration (minus any movement) in m/s^2 Temperature (1Hz) Ambient temperature in degrees celsius

question is if the Quaterion vector outputs are fully compensated for linear accel forces.. it will it work in accelerated flight?

[duecedriver]

USB GPS

BU-353-S4 cheap at ~30

but slow updates.. 1hz

4800 baud

did I mention cheap...

[ssokol]

Since (hopefully) nobody would be crazy enough to use Stratux for IFR navigation, 1 hz is probably good enough. Here's my thinking:

High cruise in my Tiger is 139 knots / 150 MPH. That's 220 feet per second. Depending on the internal delays in the system that puts my actual position somewhere between 0 and ~300 feet of what the GPS shows. Considering that 99.9% of the time I'm looking at the sectional view which is a 1:500,000 scale, I think +/- 300 feet is fine.

With the BU-353-S4 I've got the BOM for a UAT + GPS Stratux down to $120. That puts it in range of even the cheapest guys at my home airport.

If you want to step up to a 5 hz or 10 hz, the Adafruit breakout makes perfect sense. I've got several here - I'll try to work up a case that supports both internal (patch) and external (pigtail) applications.

On Mon, Dec 14, 2015 at 9:15 AM, duecedriver notifications@github.com wrote:

USB GPS

BU-353-S4 cheap at ~30

but slow updates.. 1hz

4800 baud

did I mention cheap...

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

Steven Sokol 408 Camelot Drive Liberty, MO 64068

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

[duecedriver]

not so much for position awareness but fluid motion and fluid heading.. .again as a backup source to compliment ahrs a fluid heading makes flying backup much easier..

I once brought a 300 million dollar U-2 back after complete electrical failure with a gamin 296

choppy updates suck...

will 1hz work.. yep.. is 5hz better.. you bet.. that is why its the GDL90 spec.. is 10hz overkill.. yep...

does your BU-353 currently plug and play with straux or did you add code?

[jpoirier]

On Mon, Dec 14, 2015 at 10:12 AM, duecedriver notifications@github.com wrote:

I once brought a 300 million dollar U-2 back

which variant?

[ssokol]

I can buy the need for smooth heading updates if you're using the angular velocity as an input to the AHRS. That's where an integrated unit like the RY835AI could have really shined - it had everything onboard that you need to factor out accelerations. I wonder if Adafruit would consider combining their Ultimate GPS breakout with their Absolute Position breakout - if the BNO055 can accept an outside angular velocity feed from the GPS.

On Mon, Dec 14, 2015 at 10:12 AM, duecedriver notifications@github.com wrote:

not so much for position awareness but fluid motion and fluid heading.. .again as a backup source to compliment ahrs a fluid heading makes flying backup much easier..

I once brought a 300 million dollar U-2 back after complete electrical failure with a gamin 296

choppy updates suck...

will 1hz work.. yep.. is 5hz better.. you bet.. that is why its the GDL90 spec.. is 10hz overkill.. yep...

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

Steven Sokol 408 Camelot Drive Liberty, MO 64068

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

[duecedriver]

nope, not talking angular velocity.. the ahrs really needs both the gyro package and linear acceleration package fused for angularity.. perhaps even the magnetometer

nope I am talking strictly looking at a moving map EFB with GPS track heading being displayed either via text or simulated compass rose/HSI ring

@jpoirier it was a U-2S block 10 with full sensor compliment oh... and it was night over enemy territory

http://archive.defense.gov/transformation/articles/2006-06/ta062306a.html

when we (upgraded) the fleet from round dials to glass.. the whole PFD/MFD system was bespoke written from scratch because off the shelf components would not have worked with our sensor packages.. it failed a lot especially when it was new.. it ran on a x486 computer I shit you not..

[skypuppy]

I'll just add this: a full-function accurate IMU's need the magnetometer and gyro and accelerometer. When used together with proper algorithms, each sensor is used to make up for the shortcomings of the other -- and they each have somewhat severe limitations when used alone. a 9+ DOF unit already has all three on the chip. Regardless, no IMU is going to be accurate in all 3 axes over a period of time without external reference. Just ask the Navy how they do it in their submarines. Further, there is lots more excellent data we can use for other aviation knowledge purposes.

I remember from flight training that interior static ports are not nearly as accurate as one sampling baro pressure from an appropriate place outside the aircraft. Freescale used to make sensor chips with barbed port right on the chip for easy attachment of a hose to get pressure data from anywhere one chose; don't know if they still make them. I have a few but they're all 5V pieces. I'm looking now for one that uses I2C rather than 0-5V analog output.

I think knowing the aircraft's attitude electronically is rather important. It is extremely useful if used to drive an autopilot (future.) It can also be used to help determine track over ground in high wind situations (crabs and slips) but I wouldn't use it for landing. :) Now we're getting into fly-by-wire territory.

Lastly, I think a magnetometer is extremely important in the event of a GPS outage, and they occur during normal maintenance, and sometimes due to bad guys. The mag is essentially a DG backup without it's limitations. Some well designed chips, again like the BNO055, claim that after initial (easy) mag calibration, location and orientation of the chip don't matter very much unless you put some large hunk of metal near it later; requiring another calibration.

CPU overhead for the BNO055, theoretically, is lower than the 6050, because all the magic can be internal to the chip. But if you really wanted to, you can get the individual data from each sensor and perform tests against the chip's output. Btw, a couple of groups outside Bosch have already done so and get better results with the software inside the BNO055 than the external calcs can determine! That is, with firmware version 3+, anyway.

There is nothing wrong with the RY chip for it's stated purposes but we can do so much more with the Bosch unit. The only downside is that it does not come with a GPS built-in, but with all the problems cropping up with the RY unit, maybe it is time to look elsewhere for such an important function. (warning: possible political rant) I'm guessing that the problems associated with the RY hardware are due to the unit's country of manufacture. They screw up everything else they make (read the book, "Poorly Made in China.")

Skypuppy

On 12/14/2015 07:37 AM, duecedriver wrote:

With discussions started in multiple threads at this point with issues stemming from finding suitable hardware and coding or interpreting output to utilize solid state gyros and magnetometers for the purpose of backup attitude, it is important to baseline what it is we really NEED not necessarily what is available While it would be possible to design a system with full inertial navigation functions I dont believe we need it or the hassle

This should speed development by focusing on the minimal path to success resulting in usable hardware

What we need

1 A solution to provide an accurate and stable backup artificial attitude output recognizable by existing EFB software packages (either implement imu code on raw sensors or select a package with build in linear acceleration correction)

2 GPS - a quality GPSS solution with no less than 5hz (GDS90 standard) refresh rate, that is either on board with the gyro package or, ideally usb external to permit remote mounting in a suitable location Benefit of remote USB solutions is their output usually conforms to industry standard data streams and we dont have power stability or signal shape or interference issues on GPIO for such (critical) high frequency data Must permit storage of last known almanac and ephemeris data for rapid warm and hot restarts and permit user input for start location on cold starts Usage of iPad internal GPS either as primary or kalman filtered into the solution with the external source to compare derived accuracy 5hz also provides rapid enough course change and track that heading is derived in perceived real time with minimal lag further negating a magnetometer heading

3 ability to select via stratux web interface which components are installed 1/2 radio, gps, ahrs etc so users can build a unit that fits their needs

4 stratux outputs as close to or conformal to industry aviation data bus standards GDL88/90 or ARINC so that all data streams leaving the unit work with the largest compliment of hardware If this is not possible or practical due to third party developers of current EFB software not using said industry standards perhaps translators are needed to stratux sends the appropriately reformatted message traffic specific to each client attached most EFB developers code to specific or multiple hardware devices because the all output differently Stratux is already gaining traction with several however those developers with their own hardware will inevitably attempt to lock out this project and will likely patent their data stream if they have not already Industry standards on file with the FAA have to remain open, hence no lockout If we want stratux to work will every software package it may have to emulate as many streams as possible or we could venture off and develop to the standard and let the software makers add our data stream to their products

What we dont need and why

1 Magnetic heading - Unless we feel that our gyro panel based heading and our whisky is going to fail as well as our Stratux gps source the hassles with implementing a magnetometer are huge: mounting, power routing, nearby ferris interference, physical vibration/movement, etc just dont warrant the effort and even with perfect code, most peoples placement / design / and usage would preclude it from providing anything useful Provided the mems gyros dont need to see it for their AHRS calcs we dont NEED it Most portable software is just looking for and displaying track heading anyway

2 Pressure alt - again, unless we feel that we are going to see a dual failure of static gauges and the GPS constellation its really not needed In the aircraft, changes in window, vent, heating etc will effect the internal pressure of the aircraft and will make the output suspect additionally, software would have to allow for barometric correction (ie ability to set local QNH) and it must be calibrated to be of use in EACH application HASSLE dump it

3 INU functionality - pure position derived via absolute motion analysis is really becoming outdated unless being used in autopilot application INU derived position is over 900m out after just one hour without kalman filtered GPS updates Again, unless we feel that the GPS is going to fail and most of us are using a iPad with gps installed as backup If external usb GNSS solutions are used they are cheap and easy to swap out in flight vs a board in the unit

skypuppy has made mention of a quality chip that has onboard quaternion and sensor fusion that negates the need to use such code in stratux any other hardware out there that warrants a look? We should find a hardware solution that meets the need, easily avail, and cost effective baseline it as the hardware and code against it!!

let the discussion begin

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/147.

[skypuppy]

I've been using this chip for over a year now and love it! I have not specifically utilized it's capability to use GPS and GLONASS and other sat systems in software (other than what it does internally), but it is on my to-do list. Eventually. The math on that is extremely difficult for my little head.

Oh, and i use their external antenna on one of my chips and that makes a world of difference when there is not clear sky overhead.

Skypuppy No, no financial connection with Adafruit whatsoever. :)

On 12/14/2015 08:21 AM, duecedriver wrote:

For Internal GPS with optional external antenna - this board has possibilities..

Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3

Very small, greater than 10hz updates, WAAS, backup batt, good filtering, low voltage protection

https://www.adafruit.com/product/746

TECHNICAL DETAILS

Satellites: 22 tracking, 66 searching Patch Antenna Size: 15mm x 15mm x 4mm Update rate: 1 to 10 Hz Position Accuracy: < 3 meters (all GPS technology has about 3m accuracy) Velocity Accuracy: 0.1 meters/s Warm/cold start: 34 seconds Acquisition sensitivity: -145 dBm Tracking sensitivity: -165 dBm Maximum Velocity: 515m/s Vin range: 3.0-5.5VDC MTK3339 Operating current: 25mA tracking, 20 mA current draw during navigation Output: NMEA 0183, 9600 baud default DGPS/WAAS/EGNOS supported FCC E911 compliance and AGPS support (Offline mode : EPO valid up to 14 days ) Up to 210 PRN channels Jammer detection and reduction Multi-path detection and compensation Revision History:

As of 8/10/2014 we are shipping with firmware v. 5632 which improves altitude calculations and stability. It is equivalent in all other functionality and is a drop-in replacement. Breakout board details:

Weight (not including coin cell or holder): 8.5g Dimensions (not including coin cell or holder): 25.5mm x 35mm x 6.5mm / 1.0" x 1.35" x 0.25"

The breakout is built around the MTK3339 chipset, a no-nonsense, high-quality GPS module that can track up to 22 satellites on 66 channels, has an excellent high-sensitivity receiver (-165 dB tracking!), and a built in antenna. It can do up to 10 location updates a second for high speed, high sensitivity logging or tracking. Power usage is incredibly low, only 20 mA during navigation.

Best of all, we added all the extra goodies you could ever want: a ultra-low dropout 3.3V regulator so you can power it with 3.3-5VDC in, 5V level safe inputs, ENABLE pin so you can turn off the module using any microcontroller pin or switch, a footprint for optional CR1220 coin cell to keep the RTC running and allow warm starts and a tiny bright red LED. The LED blinks at about 1Hz while it's searching for satellites and blinks once every 15 seconds when a fix is found to conserve power. If you want to have an LED on all the time, we also provide the FIX signal out on a pin so you can put an external LED on.

Two features that really stand out about version 3 MTK3339-based module is the external antenna functionality and the the built in data-logging capability. The module has a standard ceramic patch antenna that gives it -165 dB sensitivity, but when you want to have a bigger antenna, you can snap on any 3V active GPS antenna via the uFL connector. The module will automatically detect the active antenna and switch over! Most GPS antennas use SMA connectors so you may want to pick up one of our uFL to SMA adapters.

The other cool feature of the new MTK3339-based module (which we have tested with great success) is the built in datalogging ability. Since there is a microcontroller inside the module, with some empty FLASH memory, the newest firmware now allows sending commands to do internal logging to that FLASH. The only thing is that you do need to have a microcontroller send the "Start Logging" command. However, after that message is sent, the microcontroller can go to sleep and does not need to wake up to talk to the GPS anymore to reduce power consumption. The time, date, longitude, latitude, and height is logged every 15 seconds and only when there is a fix. The internal FLASH can store about 16 hours of data, it will automatically append data so you don't have to worry about accidentally losing data if power is lost. It is not possible to change what is logged and how often, as its hardcoded into the module but we found that this arrangement covers many of the most common GPS dataloggin g requirements.

Comes with one fully assembled and tested module, a piece of header you can solder to it for breadboarding, and a CR1220 coin cell holder

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

[skypuppy]

If one reads the whitepapers, if you use the on-chip calculations, then yes, full compensation is factored in. I'm still coming to grips with quaternions but the bottom line is they don't get tripped up when at 180 degrees. Further, it is fairly easy to change a quad to cartesian, except for that divide by 0 problem at 180.

On 12/14/2015 09:05 AM, duecedriver wrote:

Adafruit 9-DOF Absolute Orientation IMU Fusion Breakout - BNO055 ~ $35

Absolute Orientation (Euler Vector, 100Hz) Three axis orientation data based on a 360° sphere Absolute Orientation (Quaterion, 100Hz) Four point quaternion output for more accurate data manipulation Angular Velocity Vector (100Hz) Three axis of 'rotation speed' in rad/s Acceleration Vector (100Hz) Three axis of acceleration (gravity + linear motion) in m/s^2 Magnetic Field Strength Vector (20Hz) Three axis of magnetic field sensing in micro Tesla (uT) Linear Acceleration Vector (100Hz) Three axis of linear acceleration data (acceleration minus gravity) in m/s^2 Gravity Vector (100Hz) Three axis of gravitational acceleration (minus any movement) in m/s^2 Temperature (1Hz) Ambient temperature in degrees celsius

question is if the Quaterion vector outputs are fully compensated for linear accel forces.. it will it work in accelerated flight?

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

[bradanlane]

A little background from a couple months ago ...

@cyoung and I went back and forth on the offline data for the GPS. The longest window we could do is 30 days. This means the user needs to perform some action from a desktop or mobile device which has connectivity to both the Stratux and to the Internet in order to fetch updates and load them to the Stratux.

There was no good solution to insure all the moving parts were connecting with the necessary infrastructure for every user and our target user is someone with minimal Linux and infrastructure knowledge.

[skypuppy]

Isn't that what the internal gyro's, accelerometers, and mag's do?

On 12/14/2015 10:28 AM, Steven Sokol wrote:

I can buy the need for smooth heading updates if you're using the angular velocity as an input to the AHRS. That's where an integrated unit like the RY835AI could have really shined - it had everything onboard that you need to factor out accelerations. I wonder if Adafruit would consider combining their Ultimate GPS breakout with their Absolute Position breakout - if the BNO055 can accept an outside angular velocity feed from the GPS.

On Mon, Dec 14, 2015 at 10:12 AM, duecedriver notifications@github.com wrote:

not so much for position awareness but fluid motion and fluid heading.. .again as a backup source to compliment ahrs a fluid heading makes flying backup much easier..

I once brought a 300 million dollar U-2 back after complete electrical failure with a gamin 296

choppy updates suck...

will 1hz work.. yep.. is 5hz better.. you bet.. that is why its the GDL90 spec.. is 10hz overkill.. yep...

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

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/147#issuecomment-164485179.

[skypuppy]

Yes, agree with target audience. Does make it tough, though. If the RY chip GPS is indeed doing a 0,0 cold start every time, that is a terrible design flaw. I know of no other chip that does not store it's last known point somewhere in it's non-volatile memory.

On 12/14/2015 03:00 PM, bradanlane wrote:

A little background from a couple months ago ...

@cyoung https://github.com/cyoung and I went back and forth on the offline data for the GPS. The longest window we could do is 30 days. This means the user needs to perform some action from a desktop or mobile device which has connectivity to both the Stratux and to the Internet in order to fetch updates and load them to the Stratux.

There was no good solution to insure all the moving parts were connecting with the necessary infrastructure for every user and our target user is someone with minimal Linux and infrastructure knowledge.

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

[bradanlane]

How silly of me. We don't need to ask the user for their default location. We could write out the GPS location on a sparse interval such as once every five minutes. Assuming the GPS will let us load an initial estimated position, this would be so much better than defaulting to 0,0.

[JohnOCFII]

Here's another inexpensive sensor breakout board. Based on 9150.

http://www.ebay.com/itm/MPU-9150-9DOF-3-Axis-Gyroscope-Accelerometer-Magnetic-Field-Replace-MPU-6050-/381374423634?hash=item58cbafe252:g:4FYAAOSw~uhUm3qA

or maybe this one: http://www.ebay.com/itm/AK8975-Three-axis-Electronic-Compass-High-Precison-Compass-Module-For-arduino-/201087301630?hash=item2ed1bcb7fe:g:RL8AAOSwA-ZTbJ1b

Out of my league, but these two were being discussed in relation to some RC GPS stuff I'm following.

[cyoung]

Good discussion, but mostly not relevant now that AHRS is merged.