Incomplete println output in SD card file

[mantonakakis1]

Got my qwiic openlog up and running, and it writes to the SD card. I've run through a few of the examples, and noticed a bug - often, the datalog file will have incomplete lines. For example, if the command in the sketch is: myLog.println("This is recorded to the default log file"); ...then the corresponding line in the log file on the SD card is:

This is

Sometimes the complete line is printed without issue, but pretty often it will cut off lines in random spots, with no apparent repeatability. For example, after the log mentioned before, I deleted everything but the config file from the SD card and tried again, and this was the full output:

Run OpenLog N This i This i If you want to write to a

I am using a slightly modified Example3_CreateFile sketch - added some delays to make it easier to catch the Serial Monitor outputs, but the same issue arises regardless. Also using "SerialUSB" instead of "Serial" because I'm using a SparkFun SAMD21 Pro RF board.

I've tried two different SAMD21 boards and two different qwiic OpenLog boards with no difference - randomly cut off lines.

Here's my sketch:

#include <Wire.h>
#include "SparkFun_Qwiic_OpenLog_Arduino_Library.h"
OpenLog myLog; //Create instance

int ledPin = 13; //Status LED connected to digital pin 13

void setup()
{
  delay(10000);

  pinMode(ledPin, OUTPUT);
  delay(1000);

  Wire.begin();
  delay(1000);
  myLog.begin(); //Open connection to OpenLog (no pun intended)
  delay(1000);
  SerialUSB.begin(9600); //9600bps is used for debug statements
  delay(1000);
  SerialUSB.println("Run OpenLog New File Test"); //Goes to terminal
  delay(1000);
  myLog.println("Run OpenLog New File Test"); //Goes to the default LOG#.txt file
  delay(1000);
  myLog.println("This is recorded to the default log file");
  delay(1000);
  myLog.create("NewFile.txt");
  delay(1000);
  myLog.println("This is also recorded to the default log file. But a new file has been created");
  delay(1000);
  myLog.println("If you want to write to a file use appendFile in example 2");
  delay(1000);
  SerialUSB.println("Done!");
}

void loop()
{
  //Blink the Status LED because we're done!
  digitalWrite(ledPin, HIGH);
  delay(100);
  digitalWrite(ledPin, LOW);
  delay(1000);
}

[nseidle]

I don't have an immediate answer. Arduino will reset the board quite a few times as the com port opens and closes with each new sketch being loaded. The 10s delay at the top of your sketch should filter out those partial resets. I have not tested on a SAMD21 before but I don't know of any I2C issues. Have you tried Qwiic OpenLog on an Uno? Might be a good way to pin down weirdness.

[mantonakakis1]

Have you tried Qwiic OpenLog on an Uno? Might be a good way to pin down weirdness.

I'll give that a try next - I've got a BlackBoard I can try it on (and probably a few others laying around). Will post if I get any different results.

[mantonakakis1]

Ran a few of the first examples here on the BlackBoard, seems to work fine so far. I'll be doing more with it soon (e.g. writing accelerometer values), and will update here with results.

[nunomiguelferreira]

I'm having the same problem when using this logger with a Feather M0 based system. Simple examples work well in an Arduino Uno but when using with a Feather M0 it drops letters in a random manner. Any ideas of what to change? I'm using delays and such to avoid the letter loss, but even then I can't get any consistent results.

[adamgarbo]

I'm curious, has there been any progress on this issue over the past year?

As I mention in this post , I'm also experiencing this problem with a SparkFun Qwiic Micro SAMD21. When I connect the Qwiic OpenLog to an Artemis Nano or Edge (my only other Qwiic boards on hand), I experience none of the same problems with missing text.

It would be great to pin down why the Qwiic OpenLog is unable to work with all SAMD21 boards, especially since the 1" Qwiic Micro is a perfect match to stack on top of the OpenLog.

[johnhulth]

I'm also having the same problem as the thread starter, Im also using the SparkFun SAMD21 Pro RF board. Any updates on this issue?

[adamgarbo]

Hi John,

SparkFun is aware of the issue but I haven't heard any updates on whether there will be a fix: https://forum.sparkfun.com/viewtopic.php?p=211975#p211975

I've had to abandon my SAMD21/Qwiic OpenLog project, though it does appear that the SparkFun Artemis boards can work with the Qwiic Openlog. Just don't ask why!

[AndyEngland521]

Well folks @adamgarbo @johnhulth @nunomiguelferreira @mantonakakis1 it seems that whenever the OpenLog NAK'd, the return value of 0 would prevent the rest of the println statement from executing. Anyway, I added a #ifndef in the proper functions to make sure we don't return 0 on SAMD21 architectures.

v3.0.1 seems to be working for me, let me know if it works for you!

[johnhulth]

Thanks Andy, this fix helped. No cut lines anymore, but i still have some missing characters that don't print, hopefully this can be taken care of with some delays();, as recommended in the hookup guide. Also, it seams to work better with Wire.setClock(100000); compared to Wire.setClock(400000);

[lacomj]

Like others, I have this problem very consistently on three different SAMD21 boards (MKR 1010, nano 33 IoT, and Redboard Turbo). The only way I can get it to behave is to write to the logger one byte (one character) at a time, with a delay(15) after each and every character. Shorter delays than about 15 ms will lead to dropped characters in the file. I do not have this problem on other boards like the UNO.

[MPH01]

SparkFun Qwiic OpenLog 3.0.2 library/board with SparkFun Qwiic Micro - SAMD21 has same issue as others have reported. Missing/incomplete data written to SD card. This is after reducing Wire freq, adding delays (that my project could tolerate). I have to abandon this setup.

I used same Qwiic OpenLog board with SparkFun Qwiic Pro Micro - USB-C (ATmega32U4). Worked as expected with Wire.setClock(400000); etc.

My one contribution, the pull up resistance from data lines was only 700 ohm. This is with GPS, accelerometer and 3 other I2C components. Seemed low. So I tried 2k and 4.7k resistors but honestly I'm not sure if they had desired effect. They didn't improve the situation.

• But could the lack of pull up resistance be an issue?

If anyone figures out why SAMD21 is problematic please post it.

[jonnerd154]

I'm suffering the same problem with the Qwiic OpenLog on an Arduino Nano 33 IoT (SAMD21).

I don't think it's the pulls: I2C lines look nice and crisp on the 'scope; adding additional/stronger pullups made things worse. Rise time is ~480nS. I have a total of 4 devices on the bus, no extra pulls, running the I2C clock at 100k.

I've tried setting Wire.setClock(10000) and Wire.setClock(400000), but neither works - can't see the OpenLog unless it's set to (the default) 100k. Also have 15ms delays between every ~15 bytes transmitted, and am using a Class 10 SD card: I don't think it's a write latency/RAM buffer overflow.

Right now I'm working to find (an easy) way to use the logic analyzer and look for dropped bytes. Not trivial with the amount of data that comes through. I'll report back!

[jonnerd154]

Update - I was able to confirm that the missing byte was NOT transmitted by the SAMD21: the problem appears to be on the controller, not on the OpenLog.

Here's an example of a line that is missing characters - real data, actually logged to my OpenLog: [01/12/200, 11:29:51P, 22.56, 0.88, -0.60, 000, 0.88, -0.60, 0.0, 0.88, -0.60, 0.00]

There are FOUR missing characters in that line. It should read (as echo'd over UART for debug): [01/12/2000, 11:29:51PM, 22.56, 0.88, -0.60, 0.00, 0.88, -0.60, 0.00, 0.88, -0.60, 0.00]

Here's a trace from the logic analyzer, clearly showing the first of those missing characters. You see /12/200 ...and then the comma.

[jonnerd154]

I have a PR open that solves this problem: https://github.com/sparkfun/SparkFun_Qwiic_OpenLog_Arduino_Library/pull/16

Thanks to @AndyEngland521 for the initial fix, I just riffed off of your work!

FYI: @MPH01, @lacomj, @johnhulth, @adamgarbo, @nunomiguelferreira, @mantonakakis1