I think I've debugged one of the issues I was having with my OpenLog connecting to Ardupilot. This will probably be blatantly obvious to you veteran Arduino Programmers, but it got me, so I figured I'd post in case it helps anyone else.
After a few flights with only the open log and the ArduIMU, I decided to integrate the ArduPilot board and move the logger to the Ardupilot board. My ArduIMU was now talking to the ArduPilot, and I hacked up the ArduPilot code to remove the autopilot/radio functionality and simply combine the ArduIMU input with barometric pressure, and spit out the aircraft parameters as fast as possible.
While stripping down the ArduPilot code for my purposes, I made a whole bunch of changes at once (Mistake #1).
Once everything was back together, I found that I was only getting a log created about half the time. Sometimes there would mysteriously be no log file created. Other times, I would have a small file filled with a bunch of null characters. While debugging I would connect the OpenLog to my FTDI cable and find that it was now operating at 9600baud rather than the desired 57600baud.
The reset to 9600 was the clue. The OpenLog has an emergency reset function. If you get the OpenLogger stuck in an unknown baud rate, you can power it up with the RX line grounded. When this is detected, the OpenLogger goes back to 9600baud on the next power cycle.
So here's my current theory.
One of the changes I made to the ArduPilot code was to add a delay at startup. The reason I added this delay was because of the instructions in the OpenLog datasheet. The OpenLog instructions state: "Turn on OpenLog, wait ~2 seconds and start throwing text at it!" So I added a delay(3000); statement to the void setup() function.
It took a few days of working backwards to figure out what was causing the OpenLog problems. Then I stumbled on this page in the Arduino Reference library:
http://www.arduino.cc/en/Tutorial/DigitalPins
Thats when I realized that I had placed the delay() function before the Serial.Begin() functions in setup().(Mistake #2) I think this meant that during the 3 second delay, the serial pins were in their default input/high impedance state, giving a somewhat random response from the serial logger at the other end.
I moved the delay() line to the end of the setup() function (after the all the initialization is done) and I did 10 powercycles in a row. Each one resulted in log being correctly written to the microSD card.
Tom
Comments