10 years, 9 months ago.

Data freezes when logging from two Serial/UART sensors using MODSERIAL and MODGPS

Hi,

I'm doing a project similar to http://mbed.org/users/lhiggs/code/UM6_IMU_AHRS_2012/, where I'm trying to log accelerometer data at 100Hz (UM6, CH Robotics orientation sensor) and GPS data at 20Hz to an sd card. I've adapted LHiggs code to include ModGPS.

For some reason as soon as I pick up a gps signal the accelerometer data freezes i.e. the time and gps signals continue to print out but the UM6 signals fixes on a single value. This has the same effect whether I'm printing to pc or file or both.

Is there a problem with using MODgps and MODSerial?

My code is published here:

http://mbed.org/users/njewin/code/LogData_UM6-to-SDcard/

Any suggests for cause of bug very much appreciated,

Nathan

I've created a simplified program for the purposes of debugging:

http://mbed.org/users/njewin/code/UM6withGPS/

This attempts just to print to pc from UM6 and GPS, but with the same result.

posted by Nathan Ewin 08 Jul 2013

2 Answers

10 years, 9 months ago.

Your program is still quit complex, and since you need that specific device to debug, it is hard for us to find the issue here.

Does your UM6 LED still flash? What if you only give your RX IRQ the task to flash an LED, and nothing else? Then you at least see if it still gets data.

Hi Erik,

Yes I release its difficult to reproduce, just hoping someone more experience can spot whats wrong with the code.

The LED continues to flash - so there is still data being transmitted from the sensor. I also thought that the buffer (um6_uart.rxBufferGetCount()) might be overflowing, but this doesn't appear to be the case.

posted by Nathan Ewin 16 Jul 2013

So you still get data, only data isn't properly processed. Wouldn't that imply that Process_um6_packet() is the issue? The problem is that it is a quite complex function. I think it can also be a bit clearer than it currently is.

A way to debug the current function might be giving it an int as return value. Increment the int in different stages of your function, and return the value at the end of your function. Then you can see how far it got.

posted by Erik - 16 Jul 2013

Thanks, thats a really useful deugging technique - obvious, once you've said it!

I've found that its exiting the process_um6_packet() function at:

/* If checksum does not match, exit function */

if ( checksum != new_packet.checksum ) {

return; }

So I need either work out why its not getting the correct check sum (when the gps is active) or possibly get it to reset.

posted by Nathan Ewin 17 Jul 2013
Nathan Ewin
poster
10 years, 9 months ago.

I think I've got to the bottom of it. It turns out from this thread:

http://mbed.org/forum/mbed/topic/1960/

that the um6 uart interrupt isn't necessary, and by removing it I seems to have removed the problem.

Thanks again for your help.

Nathan