collecting GPS and PWMs Issue

[KindaNerdy]

hey all,
pretty new here. Second post anyway I am having an issue and was wondering if anyone has some experience or has tried something similar to what I am trying to do?

Basically I have built a baord using a Native Mode 1280n processor. I have a Trimble GPS module hooked up to Com 2. I have it pumping data out at 38400 and configured to send just two nmea strings the RMC and GGA.

I also have a Futabab PCM 9 channel receiver hooked up as well. I am reading in 8 channles of PWM into the processor. So here is my delima. Without reading the PWM's I get the GPS just fine. Reading in the PWM's I get the reading just fine too. I am using the PulseIn command. But since the PulseIn command kills the interrupts I believe I am getting holes in the input data from the GPS. So the GPS data is just Garbage. I have tried to use the one PPS signal from the GPS as in interrupt to the processor and tried to clear the queue with some delay and then read the input buffer. Still just junk data.

So does anyone have any sugestions on how I can make this work?

for the GPS parsing I just read the buffer until I come accross the "$" then from there I look for my header info and determine which string to parse.

thanks for any advice you can provide.

[dkinzer]

But since the PulseIn command kills the interrupts I believe I am getting holes in the input data from the GPS.

If you're using a hardware serial channel (e.g. Com2), disabling interrupts for longer than something approaching two character times (not bit times) will result in data loss. The two character time limit arises from the fact that the hardware UART has two buffers for receiving data - one that holds the last completely received byte and one for the byte currently being received. As long as the last-received byte is read from the register before the next byte is completely received there will be no overrun.

The situation is much, much worse when using one of the software UART channels (Com3 to Com6). For these, disabling interrupts for much over 1/4 of a bit time (not character time) will result in data loss. This arises from the fact that the software UART code utilizes an interrupt to enable sampling the receive pin somewhere in the middle two quarters of a bit's time slot. Delaying those interrupts by more than a quarter bit time skews the sampling time and if it is delayed by more than two quarters the sample timing gets completely out of sync.

You may be able to use InputCapture() to get the same effect as PulseIn() with the advantage that InputCapture() doesn't disable interrupts and, in fact, relies on interrupts in order to work properly.

[KindaNerdy]

Well I thought about the Inputcapture() but from what I read there are only 4 input capture pins? and I need more than that.

At the moment I really only need the GPS time so I may just sync up the RTC with the GPS and then ignore the GPS. but in the future I will need Pos and heading so I guess I will figure something out for that. The issue is I am stuck using the Futaba Receiver at the moment, but eventually will move on to a Radio modem and this should not be a problem any more.

Thanks for the info.

Scott

[dkinzer]

Well I thought about the Inputcapture() but from what I read there are only 4 input capture pins? and I need more than that.

You could use a free-running timer and pin-change interrupts to handle data collection from multiple pins, effectively implementing something like InputCapture() on multiple pins. There will be some latency between the activating edge and the reading of the timer. InputCapture() avoids this by using hardware to capture the timer value when the active edge occurs.

You could add extra hardware to capture a pulse width. There are probably other clever ways of decoding PWM data with and without hardware assist.