RY835AI GPS Connections

[duecedriver]

Looking for definitive pinouts and settings based on the latest .5 beta code. These are the latest pinouts most are using but the RY835AI shows multiple trigger grounds... should we be using or tying the grounds to ensure proper operation? There are many people posting of intermittent signal, long lock times, and other abnormalities.. are we hooking this up right!

Also, does the stratux code set the units internal settings for gps refresh rates>? The unit comes factory default at 1HZ but can be modified up to 18Hz. How about baud rates and ports? Some hook up via usb then connect to gpoi and that solves some issues.. so I am thinking this is a gps board settings issue.

Does the hardware store almanac and ephemeris data for warm/hot and assisted startup or do we need to store that via software. I assume some settings (port data/refresh rates/etc) are being retained in the unit via non vol memory while catalog and gps ephemeris are being held by the rechargeable onboard battery. Anyone test how long that battery lasts?

as for the gyros and other sensors.. see my other post.. I believe there are sever good open source code projects that will give us full AHRS and imu/inu functionality.

Power: VDD -> PIN 02 GND -> PIN 06 AHARS Data: SDA1 -> PIN 03 SCL1 -> PIN 05 GPS Data: TXD -> PIN 10 RXD -> PIN 08

spec sheet here http://www.reyax.com/Module/GPS/RY835AI/RY835AI.pdf

[brockhoff]

I thought I was the only one having strange GPS results. It seems to work for a while after I connect the GPS to my laptop and perform a cold reboot. Then re-connect it to Stratux via GPIO. I am open to help with testing and coding.

[egid]

Some discussion a while back regarding long lock times centered around the small capacity of the onboard lithium cell. It's something like 50mAh, which is maybe around a week of standby tops. Most (not all) of us are probably flying less than weekly, so it has plenty of time to drain and then think it's off the coast of Equatorial Guinea.

I don't know that anyone else has fiddled with the wiring, but at the time I wondered about replacing the tiny cell with a bigger one like a lithium CR3032, which is 500mAh.

[duecedriver]

starting a new thread on realistic hardware goals

[brockhoff]

The issue I have with GPS is not related to it being off too long. I can have a WAAS lock on it, power cycle the Stratux. Then end up with either no GPS lock after letting it sit powered on over night. Repeated power off's won't fix it. I have to perform a GPS cold restart to have it re-establish a lock. I have used the ubox windows tool to monitor what is going happening and noticed that it will be quick to pickup a couple of satellites. Not enough to even get to 3D tracking. And they will all drop for a second and it has to find them again.

[jpoirier]

The NEO-M8M data sheet states for both GPS/GLONASS and GPS/BeiDou configs max update rate is 5Hz and a GPS only config is 10Hz. Could someone that's having lock problems try dropping the update rate down to 5 Hz and see if there's any change in behavior.

You'd need to use u-center to get the 5Hz UBX-CFG-RATE-Measurement period values and make changes in main/ry835ai.go

// Set 10Hz update. p.Write(makeUBXCFG(0x06, 0x08, 6, []byte{0x64, 0x00, 0x00, 0x01, 0x00, 0x01}))

from the NEO-M8 data sheet

TCX) or Crystal GNSS GPS & GLONASS GPS &BeiDou GPS

Max nav update rate NEO-M8N 5Hz 5Hz 10Hz NEO-M8N/Q 10Hz 10Hz 18Hz

On Mon, Dec 14, 2015 at 7:01 AM, brockhoff notifications@github.com wrote:

The issue I have with GPS is not related to it being off too long. I can have a WAAS lock on it, power cycle the Stratux. Then end up with either no GPS lock after letting it sit powered on over night. Repeated power off's won't fix it. I have to perform a GPS cold restart to have it re-establish a lock. I have used the ubox windows tool to monitor what is going happening and noticed that it will be quick to pickup a couple of satellites. Not enough to even get to 3D tracking. And they they will all drop for a second and it has to find them again.

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

[duecedriver]

factory default I believe is 1hz and I doubt anyone is changing that config.. could be wrong.

looking at the data sheet and seeing 3 ground signals and most are only wiring one ground to me sounds like it could be an issue.. signal grounds are key to keep noise out of the signal waveforms going to the pi.. garbage in garbage out?

[jpoirier]

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

factory default I believe is 1hz and I doubt anyone is changing that config.. could be wrong.

yes, you're wrong; did you not read the part about the value being set in main/ry835ai.go // Set 10Hz update p.Write(makeUBXCFG(0x06, 0x08, 6, []byte{0x64, 0x00, 0x00, 0x01, 0x00, 0x01}))

[duecedriver]

nope didnt catch that.. honestly having a hard time finding and following documentation on the project..

central documentation would really help people figure out whats going on without having to read all the source code for notes or at least a running doc for each process...

keep in mind that even with a good backup battery ... saved almanac and ephemeris data is only good for a short period of time... ephemeris data is considered good for 30 mins.. otherwise its a cold start

what is probably happening on cold starts is the gps start position might be defaulting back to a lat long of 0 ,0 in that case with an inaccurate start location and no almanac it takes the unit forever to orient to the constellation and get its initial fix and begin the 13 minute almanac download.. then update ephemeris

with a hand held or other consumer gps.. if it senses its a cold start.. it usually asks you to click on a present position on a map to give it a head start.

in the USAF, we were required to take our survival radio/handhelds out periodically from our survival gear and let it update almanac data and get a starting fix.. and they had huge batteries..

for the U-2, it was usually connected to a external gps antenna and let it align and warm up for over an hour during preflight to have a highly precise location and ephemeris updates.. but then my INU was so sensitive it had to calibrate for more than an hour to sense the earths rotation too

[bradanlane]

if allowing the user to specify a default starting point for the GPS will significantly accelerate lock, then that would not be a big thing to add.

Doe the hardware support setting the lat/lon starting position?

What do others think?

[skypuppy]

Have you checked the cgsic site for possible gps sat outage?

On 12/14/2015 07:01 AM, brockhoff wrote:

The issue I have with GPS is not related to it being off too long. I can have a WAAS lock on it, power cycle the Stratux. Then end up with either no GPS lock after letting it sit powered on over night. Repeated power off's won't fix it. I have to perform a GPS cold restart to have it re-establish a lock. I have used the ubox windows tool to monitor what is going happening and noticed that it will be quick to pickup a couple of satellites. Not enough to even get to 3D tracking. And they they will all drop for a second and it has to find them again.

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

[wakkow]

This kind of stuff isn't what I do, but I'm just trying to help so apologies if this is redundant or useless. That said...

Looking over the M8 Documentation Section 9, it lists the ways to speed up starts but most require the host to fetch data from the Internet. Their "AssistNow Autonomous" (Section 9.6) seems the most useful to us as it works completely offline with data it already has:

Based on a broadcast ephemeris downloaded from the satellite (or obtained by AssistNow Online), the receiver can autonomously (i.e. without any host interaction or online connection) generate an accurate satellite orbit representation that is usable for navigation much longer than the underlying broadcast ephemeris was intended for. This makes downloading new ephemeris or aiding data for the first fix unnecessary for subsequent start-ups of the receiver.

It sounds like it adds a few days of life to the last ephemeris. Not great, but better than nothing. It's also disabled by default. Does this sound like something worth turning on?

[brockhoff]

My guess is it is not a problem with the GPS taking long on a cold startup. If I force it to do a cold startup then it will get a 3D lock in about 15-20 mins. After it gets a 3D lock I will power it off/on. So I would expect the battery would be able to hold the satellite almanac and allow it to get 3D lock quickly. this does happen most of the time. But some times it does not. And when It does not then it will never get a 3D lock until I force a cold startup.

I was also thinking about all the ground connections on the RY835AI. I an email to their support and they never answered my question.

This issue does not appear to happen when I connect the RY835AI to the Stratux USB.

[cyoung]

Yes, AssistNow will help - if anyone wants to add in it would be great. @jamez70 ??

[jamez70]

If you think that would help we could make it work. uBlox doesn't give access to that freely though if I remember correctly.

I had mentioned previously that at my day job we had to switch uBlox 8 modules because one of them would either take a very long time to lock or not lock at all.

[cyoung]

Just forwarded you my API key for the u-blox AssistNow data files

[jamez70]

Cool thanks. I'll look at it tonight

On Mon, Dec 14, 2015 at 7:27 PM, cyoung notifications@github.com wrote:

Just forwarded you my API key for the u-blox AssistNow data files

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

[jamez70]

Ok, I wrote something and it might work. I did a pull request so you could take a look. If you could, test it. I need to check acknowledgements though before I would call it done.

[jamez70]

Ok I wrote some code, but need to test it more

On Mon, Dec 14, 2015 at 7:28 PM, Jim Jacobsen jamez1970@gmail.com wrote:

Cool thanks. I'll look at it tonight

On Mon, Dec 14, 2015 at 7:27 PM, cyoung notifications@github.com wrote:

Just forwarded you my API key for the u-blox AssistNow data files

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

[MSGTFE]

We have been using the same pin configuration since August, I have seen a picture on reddit recently that had the ground jumped to another pin. Since the beginning we have been using the pin configuration that @duecedriver has posted with a single ground on pin 6. This configuration has seemed to work for a lot of folks. Not sure where the extra ground is coming from, maybe I missed something? IMO I think that some folks are just getting bum GPS units or their soldering skills are not up to the task, also that unit is pretty small, there is a chance that in the process of soldering the headers you could actually damage or overheat it.

[duecedriver]

Well the more I look at the schematic the more inclined I am to thinking we have not taken the time to wire this chip correctly.

From what I remember of digital and analog ic curcuit design..(25 years ago), multiple grounds to ensure voltage floors and waveform squareness are not put on the boards for their good looks.

additionally, there is pin 8 which is an input pin FSYNC for the MPU, it states wire to ground if not used. That makes 4 grounds and we are wiring 1. The PDF spec sheet is poor to explain the circuit logic but it is becoming more clear that we probably have lots of noise going on here, possibly voltage irregularities since there are several 3.3v 2ohm pull-ups in use on these circuits...

there is a blurb in the u-block data sheet that warns that all grounds and voltages be carefully managed to avoid over stressing components as they can be damaged by voltage spikes and voltage float.

Again we are hooking into the pi +5 line that is notoriously unreliable especially when 2 radios are being used without the powered hub, we give it a single ground (which may only gound the 5v power source) not providing a ground for the 3.3v signal generator sources that may further allow voltage float and not provide square waveforms as well as not allowing any onboard filters a current drain.

So convinced that this is (part) the problem I found a blurb in the u-blox hardware integration manual that states

Electromagnetic interference on I/O lines Any I/O signal line with a length greater than approximately 3 mm can act as an antenna and may pick up arbitrary RF signals transferring them as noise into the GNSS receiver. This specifically applies to unshielded lines, in which the corresponding GND layer is remote or missing entirely, and lines close to the edges of the printed circuit board.

https://www.u-blox.com/sites/default/files/NEO-M8_HardwareIntegrationManual_(UBX-13003557).pdf

we are also clearly not utilizing all data i/o pinouts and I cant speak to their individual requirements but this may also explain why folks have less issues over usb.

The USB spec requires the i/o and power to be internally regulated (and all relevant circuits would be tied and grounded appropriately in the onboard usb circuit) .. when utilizing the header pins, we are now responsible for ensuring all power and grounds are good, that all data channels are connected to their various sources and targets, etc..

I am fairly convinced that we need to have someone that is a lot smarter than me reference the hardware integration guides of these chips to figure out how to wire it for full performance.

also the u-bloc guides talk a lot about assisted startup

additionally power wise If the module supply has a power failure, the V_BCKP pin supplies the real-time clock (RTC) and battery backed RAM (BBR). Use of valid time and the GNSS orbit data at start up will improve the GNSS performance, as with hot starts, warm starts, AssistNow Autonomous and AssistNow Offline. If no backup battery is connected, the module performs a cold start at power up.

the pi has no good data/time to feed the unit so after a couple days the unit power on and the onboard clock starts at its hard coded date, it has no location, and it requires the full cold start...

thoughts

[duecedriver]

why dont we put the GPS on the i2c bus with the ahrs?

again. I am trying to get with reyax to see how they are using the 6050.. are they outputing raw axis data or using the 6050 onboard software processing that is supposed to fuse the data. a 6050 on a separate breakout board gives you the option.. I dont know what there are doing here. We are also not using the fsync or interrupts while most of the other people using a 6050 are using these..

lacking the additional grounds that the chip provides may be allowing noise into the ahrs data?

[skypuppy]

It is difficult to use interrupts in standard Linux, which is what's on the Pi. Essentially, you have to change the kernel. It is done but it ain't easy.

On 12/17/2015 08:39 AM, duecedriver wrote:

why dont we put the GPS on the i2c bus with the ahrs?

again. I am trying to get with reyax to see how they are using the 6050.. are they outputing raw axis data or using the 6050 onboard software processing that is supposed to fuse the data. a 6050 on a separate breakout board gives you the option.. I dont know what there are doing here. We are also not using the fsync or interrupts while most of the other people using a 6050 are using these..

lacking the additional grounds that the chip provides may be allowing noise into the ahrs data?

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

[cyoung]

If you want to get DMP (Digital Motion Processor) output from the 6050, play with this:

https://github.com/cyoung/linux-mpu9150

It's not using hardware interrupts, there is a sample queue on the 6050 which is small - and depending on the sample rate, usually can be read in without missing or overflowing. Not the best setup but you can at least use it to evaluate the performance roughly.

[ghost]

@duecedriver -

We don't use FSYNC because this isn't a mobile phone, and we're not trying syncrhonize accelerometer signals with optically stabilized image capture.

Tying the grounds together is a red herring. All of the grounds on the RY835AI board are tied, with < 0.2 Ohm resistance, because the whole bottom layer of the board, save for the signal and power traces, is one big ground plane. Even the gold-plated mount pads on the corners of the board are part of the ground.

In my experience, an electrically "clean" M8N receiver will position lock within three minutes on a cold startup -- that's indoors, with no real-time clock, no almanac, no previous position.

That said, EM interference can be and is a problem. I've seen UART noise show up as gibberish on the serial console (i.e. cat /dev/ttyAMA0 showed random ascii characters interspersed in the NMEA messages), and suspected crosstalk between the TX/RX UART lines (possibly caused my poor repair workmanship by yours truly). That confused the hell out of the receiver and apparently prevented GPS lock. Unplugging the Pi TX / ublox RX line instantly caused the "lock" indicator to flash and normal messages to stream.

[duecedriver]

what I want to know is if its even available in the RY chip.. they have the 6050 on board but it has 2 modes.. which are they using.. the manufactured cant even tell me..

invensence.. the company that makes it finally opened up the code to use it for developers.. you can get a free account to access the standards and some example code routines.. but did reyax make it available or not?

On Dec 17, 2015, at 10:01 AM, cyoung notifications@github.com wrote:

If you want to get DMP (Digital Motion Processor) output from the 6050, play with this:

https://github.com/cyoung/linux-mpu9150 https://github.com/cyoung/linux-mpu9150 It's not using hardware interrupts, there is a sample queue on the 6050 which is small - and depending on the sample rate, usually can be read in without missing or overflowing. Not the best setup but you can at least use it to evaluate the performance roughly.

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

[cyoung]

What modes are you referring to?

[duecedriver]

Things get really complex with the "DMP". The sensor has a "Digital Motion Processor" (DMP), also called a "Digital Motion Processing Unit". This DMP can be programmed with firmware and is able to do complex calculations with the sensor values. For this DMP, InvenSense has a discouragement policy, by not supplying enough information how to program the DMP. However, some have used reverse engineering to capture firmware.

The DMP ("Digital Motion Processor") can do fast calculations directy on the chip. This reduces the load for the microcontroller (like the Arduino). The DMP is even able to do calculations with the sensor values of another chip, for example a magnetometer connected to the second (sub)-I2C-bus.

[duecedriver]

the DMP package is supposed to do all the vector calcs etc.. it is on an i2c bus with the compass and pressure sensor according to the reyax .pdf but they cant tell me if the installed it to use the DMP or not.. invensence has a developer section I think I sent you a link where you can now download the code and the developers tools and specs for the 6050 but if it was not installed by reyas to get at it.. it may or may not work...

[duecedriver]

there is probably a world of difference on how the bus and signal noises are on the ground in the kitchen vs in the aircraft sitting on top of the avionics stack with a 60 yo generator providing enough noise to power detroit ...and a transponder and other radios leaking RF

[duecedriver]

@AvSquirrel

ok fair enough on fsync.. however according to the manufacturers integration doc.. if it is not used it is supposed to be grounded.

additionally, if a singe ground would work I dont see why they provide 3..

again... I have read the integrators docs for the 6050 and the GPS chip on this board and they all harp on the ground criticality as well as RF shielding and ESD damage potential ...

[duecedriver]

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..

and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups

again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

[ghost]

@duecedriver

Remember that Arduino is a microcontroller, which lives and dies by interrupts. Raspberry Pi is a full-fledged 32-bit computer with a gigabyte of RAM... it's a completely different world.

When you get down to nuts and bolts, the Reyax board is nothing more than a breakout board that puts four useful little modules onto a single piece of epoxy glass for the sake of convenience -- you have a common filtered power source to supply for all modules, and three modules (gyro/accel, pressure sensor, magnetometer) are electrically combined onto the same I2C bus to create an ersatz 10-DOF sensor.

I'd guess that the purpose for three grounds (really four, if you count the USB connector) is to provide a dedicated solder point for each set of signal leads. Notice that one is adjacent to the GPS UART pins; one is near the gyro/accel/pressure/magnetometer I2C, and the third is near the GPS I2C.

[duecedriver]

exactly ..dedicated grounds for each signal path… roger that…

yes.. I know the RY chip is packaged bunch of chips.. hence not finding the info I needed from rayax I looked up the individual microchips… so again it comes down to the question.. is the 6050 processor set up to use on board IMU code or not.. if it is supposed to do sensor fusion we are either 1 not using the proper commands to get the data or activate the controller 2 getting too much noise on the i2c bus to the pi thereby not getting good signals since in the video of it running in an aircraft .. it does not seem to respond at all to aircraft motion…

lets not forget the instructions say to ground rsync if not in use so that is another ground..

i read a whole bunch on the proper setup of i2c busses and is seems a bit more involved than just connecting 2 wires for clock and data…

On Dec 17, 2015, at 2:44 PM, AvSquirrel notifications@github.com wrote:

@duecedriver https://github.com/duecedriver Remember that Arduino is a microcontroller, which lives and dies by interrupts. Raspberry Pi is a full-fledged 32-bit computer with a gigabyte of RAM... it's a completely different world.

When you get down to nuts and bolts, the Reyax board is nothing more than a breakout board that puts four useful little modules onto a single piece of epoxy glass for the sake of convenience -- you have a common filtered power source to supply for all modules, and three modules (gyro/accel, pressure sensor, magnetometer) are electrically combined onto the same I2C bus to create an ersatz 10-DOF sensor.

I'd guess that the purpose for three grounds (really four, if you count the USB connector) is to provide a dedicated solder point for each set of signal leads. Notice that one is adjacent to the GPS UART pins; one is near the gyro/accel/pressure/magnetometer I2C, and the third is near the GPS I2C.

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

[skypuppy]

The Bosch BNO055 has it, too, and is active and available as soon as the chip is powered up. It's also easy to use. :)

On 12/17/2015 01:14 PM, duecedriver wrote:

Things get really complex with the "DMP". The sensor has a "Digital Motion Processor" (DMP), also called a "Digital Motion Processing Unit". This DMP can be programmed with firmware and is able to do complex calculations with the sensor values. For this DMP, InvenSense has a discouragement policy, by not supplying enough information how to program the DMP. However, some have used reverse engineering to capture firmware.

The DMP ("Digital Motion Processor") can do fast calculations directy on the chip. This reduces the load for the microcontroller (like the Arduino). The DMP is even able to do calculations with the sensor values of another chip, for example a magnetometer connected to the second (sub)-I2C-bus.

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

[skypuppy]

I have not look at the electrical specs in a long time. Sometimes there is a sinal ground as well as power ground. Definitely so with thermocouples.

On 12/17/2015 01:22 PM, duecedriver wrote:

@AvSquirrel https://github.com/AvSquirrel

ok fair enough on fsync.. however according to the manufacturers integration doc.. if it is not used it is supposed to be grounded.

additionally, if a singe ground would work I dont see why they provide 3..

again... I have read the integrators docs for the 6050 and the GPS chip on this board and they all harp on the ground criticality as well as RF shielding and ESD damage potential ...

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

[skypuppy]

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux. Yes, it can be done but it is a real PIA.

On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..

and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups

again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

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

[jzeevi]

I don't understand. I use interrupts in Linux all the time.

Josef Sent from a phone with a tiny screen

On Dec 17, 2015, at 3:49 PM, skypuppy notifications@github.com wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux. Yes, it can be done but it is a real PIA.

On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..

and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups

again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

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

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

[kdknigga]

Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux.

Huh? What's listed in /proc/interrupts?

On Thu, Dec 17, 2015, 15:49 skypuppy notifications@github.com wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux. Yes, it can be done but it is a real PIA.

On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..

and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups

again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

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

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

[jamez70]

Those are in kernel modules On Dec 17, 2015 4:11 PM, "Kris Knigga" notifications@github.com wrote:

Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux.

Huh? What's listed in /proc/interrupts?

On Thu, Dec 17, 2015, 15:49 skypuppy notifications@github.com wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux. Yes, it can be done but it is a real PIA.

On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..

and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups

again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

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

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

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

[kdknigga]

Those are in kernel modules

Some of them, sure, but not all of them.

But, I fail to see how that's a problem. On Dec 17, 2015 16:25, "jamez70" notifications@github.com wrote:

Those are in kernel modules On Dec 17, 2015 4:11 PM, "Kris Knigga" notifications@github.com wrote:

Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux.

Huh? What's listed in /proc/interrupts?

On Thu, Dec 17, 2015, 15:49 skypuppy notifications@github.com wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux. Yes, it can be done but it is a real PIA.

On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..

and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups

again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

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

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

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

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

[skypuppy]

Hardware interrupts? You must have some of the rare real-time kernels.

On 12/17/2015 04:07 PM, Josef Zeevi wrote:

I don't understand. I use interrupts in Linux all the time.

Josef Sent from a phone with a tiny screen

On Dec 17, 2015, at 3:49 PM, skypuppy notifications@github.com wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux. Yes, it can be done but it is a real PIA.

On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..

and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups

again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

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

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

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

[jamez70]

You can do user space interrupts but don't hold your breath

On Thu, Dec 17, 2015 at 10:00 PM, skypuppy notifications@github.com wrote:

Hardware interrupts? You must have some of the rare real-time kernels.

On 12/17/2015 04:07 PM, Josef Zeevi wrote:

I don't understand. I use interrupts in Linux all the time.

Josef Sent from a phone with a tiny screen

On Dec 17, 2015, at 3:49 PM, skypuppy notifications@github.com wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux. Yes, it can be done but it is a real PIA.

On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..

and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups

again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

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

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

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

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

[skypuppy]

And they are a pain in the patoot to code for, while keeping everything else on the stack rolling and in sync, not losing polled samples, etc.

On 12/17/2015 04:25 PM, jamez70 wrote:

Those are in kernel modules On Dec 17, 2015 4:11 PM, "Kris Knigga" notifications@github.com wrote:

Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux.

Huh? What's listed in /proc/interrupts?

On Thu, Dec 17, 2015, 15:49 skypuppy notifications@github.com wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux. Yes, it can be done but it is a real PIA.

On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..

and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups

again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

— Reply to this email directly or view it on GitHub

https://github.com/cyoung/stratux/issues/142#issuecomment-165555930.

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

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

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

[skypuppy]

Yeah, hardware interrupts that are not handled in real-time are not true interrupts. They're more of a 'tickle.'

On 12/17/2015 10:03 PM, jamez70 wrote:

You can do user space interrupts but don't hold your breath

On Thu, Dec 17, 2015 at 10:00 PM, skypuppy notifications@github.com wrote:

Hardware interrupts? You must have some of the rare real-time kernels.

On 12/17/2015 04:07 PM, Josef Zeevi wrote:

I don't understand. I use interrupts in Linux all the time.

Josef Sent from a phone with a tiny screen

On Dec 17, 2015, at 3:49 PM, skypuppy notifications@github.com wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux Torvalds did not include interrupt handling in the kernel of Linux. Yes, it can be done but it is a real PIA.

On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..

and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups

again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

— Reply to this email directly or view it on GitHub

<https://github.com/cyoung/stratux/issues/142#issuecomment-165555930 .

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

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

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

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

[duecedriver]

not mine but found this...

I got a kernel level ISR working for a data acquisition project. I found that user level ISRs (with wiringPi for example) have a latency of 25us and up. I needed a little better so I came up with this kernel level driver for interrupting on the rising edge of a gpio and writing data to a file, latency is reduced to 2.5us to 7us. There were lots of challenges, I put a description of the project here https://sites.google.com/site/hamlinhomeprojects/projects/raspberry-pi-isr the source code is attached. Enjoy,

[duecedriver]

some folks are citing that interrupts are required to use on board processing on the 6050... otherwise we are just reading raw angles? In order to use the on board calcs and the FIFO we need to wire the interupts...

found this

I tried benchmarking the frequency of the DMP example, and here's what I noticed:

The MPU interrupts the code at 200Hz However, the reading of the data is limited to 160Hz The FIFO overflows, which is the reason for the drop in frequency

https://github.com/jrowberg/i2cdevlib/issues/135

again how this translates to the rayax board is anyones guess.. they have yet to return my email.

[jamez70]

The tricky part can be to build the kernel module against the kernel, but I don't expect that to be a problem If the BMP180 continues to lock up the bus a kernel module solution may be the only way to recover from that.

On Fri, Dec 18, 2015 at 10:15 AM, duecedriver notifications@github.com wrote:

some folks are citing that interrupts are required to use on board processing on the 6050... otherwise we are just reading raw angles? In order to use the on board calcs and the FIFO we need to wire the interupts...

I tried benchmarking the frequency of the DMP example, and here's what I noticed:

The MPU interrupts the code at 200Hz However, the reading of the data is limited to 160Hz The FIFO overflows, which is the reason for the drop in frequency

jrowberg/i2cdevlib#135 https://github.com/jrowberg/i2cdevlib/issues/135

again how this translates to the rayax board is anyones guess.. they have yet to return my email.

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

[1-prop-head]

Looks like REYAX has placed some updated information concerning the NEO-M8N it can be found here https://www.u-blox.com/en/product-resources/2688 On the wiring the data sheet instructs us to attach a ground wire on FSYNC that seemed to help me with mine to sync.

[duecedriver]

Been saying that for weeks. Also probably need to wire the rest of the grounds too since it's a voltage drain design and stray current and noise has to go across the board to a single drain the way most are hooking up. See my comments over on Reddit concerning signal noise and shielding.

[1-prop-head]

About those grounds. It is very difficult to get enough heat into the board to make a reliable solder flow connection on the grounds. The plated through ground connection holes are not buffered from the board and you are required to heat up a lot of copper to get a good flow. I am cranking my solder pencil up and still not getting a great feeling about the heat penetration on the ground connection