Connect OpenLog with Razor 9DOF IMU (AHRS firmware)

[andreas-bulling]

As the sf9domahrs project doesn't seem to be very active at the moment I decided to post this issue here. Sorry if it's out of scope, just close the issue if there's nothing you can do about it.

I'm trying to connect the OpenLog v1.61 to the Razor IMU with AHRS firmware. Setting both to 57600 bps works fine if I connect to each module using the FTDI cable and screen: The IMU nicely transmits the raw data and also OpenLog seems to work (config.txt was set to 57600 bps and also the baud menu shows 57600 bps as the current baud rate).

However, if I directly connect the two it doesn't work anymore: The data is not completely corrupt as what happens if the baud rate was completely wrong. I do see part of the data columns but it's riddled with a lot of strange characters...

Any idea what happens here? I've selected "Adruino Pro or Pro Mini (3.3V, 8MHz) w/ ATmega328" in the GUI...

[tz1]

The OpenLog has a 16Mhz crystal. Many of the sparkfun units (including their 9DOF) also have 16Mhz crystals.

You need it setup for automatic acquisition (or manually start it then cross the wires).

If you have a fragmented or heavily used or slow SD card you can have problems at the higher baud rates. Try erasing it with a utility designed for SD cards (panasonic has one, It is mentioned here).

[nseidle]

Hi Tz - Thanks for your help! But I don't really understand your comments.

OpenLog and 16MHz resonator: Yes, but how does that relate to Andy's problem? A possible serial data rate mismatch? Please explain.

'Automatic acquisition' : Do you mean setting OpenLog up to start in NewLog mode? Automatic logging? v1.61 should turn on in NewLog mode by default. But Andy, this is something good to check.

Fragmented SD card: Andy's problem is corrupted characters, not dropped characters. I don't think a slow SD card will result in corrupt chars.

Andy - I was hoping it was a power issue, for example OpenLog was not being properly powered by the Razor, but this is not the case. The Razor has 3.3V on the header pins connecting to OpenLog.

I'd recommend trying slower baud rates. Try 9600 on both Razor and OpenLog and see if the corruption goes away. If it does, it may be a problem with the Razor getting it's UART set to a slightly different baud rate than OpenLog, just enough to get some chars, but corrupt others. If that is the culprit, come back and let us know.

-Nathan

[tz1]

Andy said he set it to 8Mhz for something, but didn't describe the process. There were no logs or examples attached so I don't quite know what pattern he describes - a wrong baud rate may make a pattern of "corrupt" characters - it would depend if 1 out of every 5-20 were wrong, or if every other character was wrong. If there are long strings of good characters, and there is problem with the SD, you would lose random chunks and would cause what might appear to be an infrequent corrupt character.

Yes, automatic acquisition would be NewLog mode - I forgot the name for it.

If possible, see if you can calculate the actual divisor being put into the baud rate register on each unit - it is possible that one is rounding up, the other down, so are far enough apart - but both world work on an FTDI since the baud rate is precise.

[nseidle]

Baud rate divisor getting calculated slightly different. Yep. That's my guess.

[tz1]

This is the routine I use. It finds the value closest to the desired target:

init_uart( unsigned centibaud ) { // desired baud / 100, e.g. 57600 is 576
    unsigned acc,count;
    // we don't do this often, and it should be more accurate than divides
#define BCLK (F_CPU/800)
    acc = 0;
    count = 0;
    while( acc < BCLK )
        acc += centibaud, count++;
    if( acc - BCLK > centibaud >> 1 )
        count--;
    UBRR0 = count - 1;
...

[andreas-bulling]

Hi guys,

thanks a lot for your fast and insightful comments - I didn't know about this baud rate divisor thing, this might indeed cause the described problems. I will have a look at it although I'm worried that I won't be able to fix the code for OpenLog/Razor appropriately - it's the first time I work with an Atmel chip ;-)

That's how the data looks like:

-0 ��.0&j�r00368 370 382 -9��225�� 0 �-0.04 0 �j0.0�368 370 38&j� 5 225��0 �-0.08 r�� -0 ��368 370�3�j� 7 224 0��j -0.04�r��j�r���368 370�3�j� 6�223 �� -0.06 r��-0 ��368 370 382 -9 �2&�0 0C�-0.05 0.Lj�.0�367 3�38Lj�7 225 �318 -279 397 �-0.04 0)�0.N�368 370 382 -8 �2�j�318 -2S�39SH�-0.0�r12 1.88368 370 382 KN�225 �318 �279 397 -0.��.15~& ��368 370 38Lj�6 225 -318 -27N�3NSH�-0.06 r��3 ��3�37�3�j� 5 22Mj�31j�2S�39SH�-0.10 0)�4 N�36�3�382 -8��22j�318j�27N�397C�-0 ��.1~M ��368 370 38Lj� 5 226 -322 -277 396 �-0.12 r���� ��3�370 382 -9 �226j�32&j�2��396 -0.13 0.19 7.9�368 370 38&j�6 223 -322 -277 3NSH�-0.14 0.19 8.98368 370 382 KN�225 -322 -277 396 �-0.12 0.21 10.033�370 381 -7 �224 -322 -277 396 -0.13 0.2L�11)��369 370 382j���22j�32&j�277 3NSH�-0.07 r��12.253�36N�38Lj� 6 22Mj�321j�27�390C�-0.08 r��1&iV�36�370�38&j���226 -321 -276 390 -0.��r29 14.52368 370 382 -N��226 -321 -276 390 �-0.12 0.30 15���36�369�382 KN�224 -321 -276 390 -0.L�.31�16.87368 370 382 -8 7�2�j�32Lj�2��390 -0.09�r�0 18 ��368 370 38&j.���225 -3�j�276 390 -0.07�r���1NI��3�3�3�j8 6�2�j3Lj�272 388 -0.0�r32 20.46368 370 382 -8��2�&j�31j�272�388C�-0.08 r�� 21.72368 370 381 -��224 -3Lj�272 388 -0.��r29 22.94368 370 382 -N��225 -318 -272 388 �-0.05 0i�24.2336�37�382j�� 224j�31j�2��388C�-0.��r30�25.3�367�37�3�j� 6 22j�31j�272 388 -0.02 0i��2� ��368�37�381 -9 6�227 �320 -278 394 -0.04 0i&�28.07368�370�382 K�225 -320 -278 394 �-0.0&�r�1�29.42368 370 381 KN�224 -320 -278 394

There should be 11 columns in total (euler angles plus 9 raw sensor values) and some values are clearly visible. Others seem to be corrupted and some lines are longer and seem to contain data from the next (?) column...

[andreas-bulling]

BTW, where does the init_uart() function need to go, how should I - in principle - include it in the Razor/OpenLog codebase?

[andreas-bulling]

Hm, I just noticed that the 1.61 firmware source code doesn't seem to be available - or maybe I just didn't find it?

[andreas-bulling]

Just tried to reduce the baud rate - 19200 works fine...

[andreas-bulling]

There is also a topic on this issue in the Sparkfun forum: http://forum.sparkfun.com/viewtopic.php?f=14&t=20816

[andreas-bulling]

Allright, after reading into a lot of different things this morning some things that may be relevant:

1) OpenLog seems to run at 16MHz - is this true for both V1 and V2?

2) Razor by default runs at 8MHz => maybe that's part of the problem if I combine the two?

3) How should OpenLog V2 be uploaded, i.e. which board should be selected in the Arduino GUI? => maybe a made a mistake here?

4) If the mismatch in clock frequency is the cause of the problems: Is it possible (and if yes how) to run the OpenLog at 8MHz or the Razor at 16MHz?

[tz1]

The init_uart would have to be on each device. The whole thing is in the UART directory on my sparkfun github repo: http://github.com/tz1/sparkfun (there are examples for the command line utils and test programs in the other directories).

The log looks like a moire pattern so it is probably the slightly off baud rates - when they happen to be in sync you get long strings of good characters, but then they drift out of phase and they lose the framing, but eventually drift back in.

[andreas-bulling]

May I still call Serial.begin() before/after inituart() or should these calls be commented out completely?

[tz1]

My routine would be a replacement. If you are going to use the Arduino library, you should look into the Arduino library serial routines and clone them for the 9dof.

[andreas-bulling]

Hm, can't get this working, I think I need to look much more into the sourcecode and the AVR platform :-/

[nseidle]

Sorry it has taken me so long to get to this.

I see some of the problem. IMU is set to work at 38400. OpenLog can't log at that rate. I'll try to get Aaron to add baud options to the IMU and I'll try to add 38400 to OpenLog. Then I can test more.

[nseidle]

Hi - I am able to log from IMU 9DOF loaded with AHRS v1.1: http://code.google.com/p/sf9domahrs/downloads/list

I did not experience the problems that you listed. Probably because I've been working with v2 of OpenLog. Can you re-visit this problem for me? I'd like you to try again with v2 if possible.

I added 38400 support in OpenLog and found a couple of un-related bugs in v2.4 and pushed v2.41 of OpenLog. Please give it a try. I'll close this issue in two weeks if I don't hear back of any problems. -Nathan

[wlharmon]

Does 38400 baud drop chars like 57600 does? It appears to drop around every 60k characters at 57600baud.. Once the file hits 2.5MB, it drops more often.. I only logged 8MB out of 10MB. The Rate is about 5650 bytes/second from the Arduino. BTW, my card is clean - there was only two files on it.. I am curious as whether the drops still occur when logging through a FTDI board?

[andreas-bulling]

@nseidle: Thanks for pushing the new version, I will give the firmware a try ASAP. Which baudrate did you use for your tests, 38400?

[nseidle]

@andy - I used 57600 for the tests. Also - I believe Aaron pushed a new version of the 9DOF test firmware that support alternate baud rates as well: http://github.com/a1ronzo/SparkFun-9DOF-Razor-IMU-Test-Firmware

@wlharmon - I'm using OpenLog v2.41 at 57600 and the AHRS v1.1 firmware from Jordi. I've got a fresh 8GB card FAT32 that was formatted with SDFormatter. I'm still running tests, but with 350k logged (takes around 10 minutes?), no characters are dropped.

[nseidle]

@wlharmon - Are you running the AHRS software? If not, please start a different issue.

[BDK-FPE]

I'm having a very similar issue, and I apologize if it shouldn't be posted in the OpenLog forum. I recently purchased an Arduimu V2+ and an OpenLog board. I'm running ArduIMU version 1.8.2, and OpenLog v2.5. I'm relatively new to micros and am trying to learn along the way. When connecting the IMU to a terminal at 57,600 via the FTDI cable, I get excellent ASCII data. I also have successfully configured the OpenLog and it is responding as it should when viewed in a terminal. The issue that I have is that when I use OpenLog to record data from the ArduIMU, the data looks like a bunch of characters that don't make sense. I believe it's very similar to the issue Andy was having above - except with the ArduIMU hardware instead of the 9DOF. Would anyone have any recommendations on what I might be able to do to get them to work together properly? Thanks in advance for any advice you might be able to offer!

[BDK-FPE]

Also - what board should be selected when uploading a sketch? Thanks much!

[nseidle]

What version of Arduino are you using? I'm going to chalk this one up to Arduino IDE doing some bad baud calculations in the background. I recommend running at a different than 57600 baud rate (either 38400 or 115200). See issue 63: https://github.com/nseidle/OpenLog/issues/closed#issue/63

[BDK-FPE]

Hi Nate - thanks for the reply! I am indeed using Arduino V0022, and seem to be experiencing the very issue you outlined in number 63. For now, I've turned the OpenLog, ArduIMU, and GPS down to 38,400 and everything works excellently. Eventually I'd like to turn it up to 57,600 for improved throughput, but it's working well for now. What an amazing set of hardware (ArduIMU and OpenLog) - you guys do top notch work. Let me know if there's anything I can do to help (i.e. provide data, etc.) and I'd be happy to.

[nseidle]

Glad to hear it! Sorry it took me so long to reply. If you find a good solution for 57600bps, do let us know.

[devangel77b]

I have a similar problem. I am trying to connect a Razor IMU AHRS to an Open Logger. To recap - The best way to do that for now is to update the OpenLog to v 2.x and set both to 38400?

[nseidle]

That's correct.