I apologize for the numerous posts over the last couple of days. Implementing the OLA has had me thinking of ways I could put it to use in lots of applications.
Right now, though, I’m having a legitimate issue with the logger.
I’m using the OLA to log the raw low-level packets coming from an XSens IMU. The IMU uses RS232, so I’ve interposed a sparkfun max3232 between it and the OLA. Data is being transmitted from the IMU at 115.2kbaud.
The problem is this: My log files on the OLA are unreadable. They contain hex values, but the data packets from the IMU are nowhere to be found. It’s almost like the logic levels are inverted (I have a block of 00 bytes that are instead being logged as FF), but inverting bits doesn’t actually produce any readable packet structures either.
I removed the OLA and attached another microcontroller (Teensy 4.0) to the same RX,TX,GND contacts and echoed the binary data to a serial monitor. When I do that, the data frames appear as they should. This tells me that the max3232 is wired correctly and that it’s not an issue of noise. So I’ve isolated the issue to the OLA itself.
What could be going on here? The IMU transmits 8N1 bytes. Does the OLA expect 8N2? Does it use a parity bit? I could really use some guidance here…
I’m sure you will know this already, but true RS232 signals are inverted: they use a -ve voltage for a logical 1, and a +ve voltage for logical 0. 3.3V UART serial uses 3.3V for logical 1 and 0V for logical 0. The MAX3232 does the inversion for you. If the data is being logged correctly on the Teensy, then it seems unlikely that it is a voltage inversion problem.
Please check you have the correct baud rate selected for the RX pin: use Menu 4 (Configure Serial Logging) then Option 2 to change the baud rate to 115200. (The terminal and serial pin have separate baud rate settings.)
We have noticed that the serial logging can be unreliable if you are trying to log large amounts of serial data and the OLA is also logging sensor data. The workaround here is to disable the sensor logging, so that the OLA is only logging the serial data. Use Menu 1 Option 1 to disable logging to the microSD card. (The serial data will still be logged to SD card. That is enabled/disabled separately via Menu 4 Option 1). So the OLA has less to do, you can also disable display of the sensor data on the terminal: use Menu 1 Option 2 to disable ‘logging’ to the terminal. We are looking into this issue, but we don’t have a reliable fix yet.
If you want to know how much serial data is being logged, you can use a hidden menu to enable debug messages. Open the main menu and type d to access the debug menu. You will then see periodic messages telling you how many serial characters have been received and logged. Please note: if the OLA is busy logging a lot of serial data , the debug messages don’t get sent.
Yes, I thought of the inversion first, but I confirmed that the MAX3232 was wired correctly and performing the inversion+shift. Like you say, the fact that the Teensy makes an inverted signal an unlikely cause.
I disabled the sensor logging as you suggested. I also confirmed that the serial logging baud rate (under menu 4) was correctly set at 115200. The problem persists.
I get the same behavior at 230400 baud. I haven’t tried reducing it to a lower value yet.
The quantity of serial data appears seems suspect. I’m looking at two log files: one from the OLA and one from the Teensy connected to the same Rx pin (Tx left disconnected). When the IMU is powered on, it sends some wakeup chatter, followed by a configuration packet of defined length, and which contains a recognizable block of bytes, so I’m using that config packet as my “yardstick”.
I trimmed both files to eliminate bytes prior to that recognizable pattern of bytes (a block of 00 bytes on the Teensy, which show up as FF bytes on the OLA). With that done, there are a total of 1440 bytes logged by the teensy and 1248 by the OLA.
I just tried eliminating all of the added cable length between the MAX3232 and the OLA to ensure that I wasn’t getting any sort of strange capacitance/ripple. I get the same result.
Is there a possibility that I just have a faulty OLA board?
Version v16 of the OLA firmware is just about ready for release. Once you have that version installed, you will be able to perform a serial loop-back test by outputting the sensor data to the TX pin and looping it back to the RX pin using a jumper wire. If everything is working correctly, the serialLog file should be a faithful copy of the dataLog file.
Until then, maybe you could try logging serial data from a different source? Perhaps simple NMEA data from a GPS/GNSS receiver? That would allow you to check that the RX pin is working correctly.
I’m based in the UK and am just about to down tools for the day. Let me know how you get on and I’ll pick this up tomorrow.
The TX and RX pins are checked during manufacture, so it seems unlikely that the RX pin itself is causing your issues. I suspect it is more likely to be linked to the amount of data the IMU is sending.
You can perform a loop-back test - to test your RX pin - by:
Use Menu 4 Option 4 to set the baud rate to (e.g.) 115200 or 230400
Use Menu 4 Option 1 to enable serial data logging
Use Menu 4 Option 2 to enable serial data output to the TX pin (this is a new feature for 1.6)
Use a jumper wire to connect the TX pin to the RX pin
Let the OLA log IMU data - from the built-in IMU - for a minute or so
Then:
Open the menu and select “q” followed by “y” to quit logging. Disconnect the USB cable. Pull the SD card and examine the most recent data and serial log files. They should be identical, except: the serial file won’t contain the first line of helper text; the serial file may be missing the last few entries (opening the menu causes the data currently in the serial buffer to be lost).
In v1.6, you can also use the new “s” menu to list and type the files to the terminal and transfer files using ZMODEM. So you can now examine and transfer your files without needing to remove the SD card.