I’m new to SparkFun’s Artemis hardware, but I am eager to fully take advantage of this platform’s potential. I have several sensors I would like to use for a project that is not “auto-detectable” on the OpenLog Artemis at this time. Since I am on a time crunch, I don’t think I’ll be able to add them to the OpenLog myself. Instead, I wanted to use a RedBoard Artemis to send logging commands to the OpenLog. I wanted to quickly verify that the system and hookups were all working by using some of the example sketches from this library: https://github.com/sparkfun/SparkFun_Qw … no_Library. The code compiles fine, uploads successfully most of the time, and it seems to execute correctly from what I see in the serial terminal. However, whenever I go to read the SD card on my computer, I see no evidence that a string was written to an existing file on the SD card, or even a new file being created in the first place. The only thing on the SD card are things from the OpenLog itself (dataLog, OLA settings, serialLog). The dataLog has stuff from the OpenLog only, no input or adjustments from the RedBoard. The serialLog is completely empty. I will attach the OLA_settings below as that might be helpful.
The RedBoard hasn’t been used until now (from my understanding). The OpenLog Artemis is new. I have the RedBoard connected to my PC through USB-C, and then the OpenLog Artemis is connected to the RedBoard via QWIIC. I’ve tested this on the basic settings of the OpenLog as well as changing some logging settings to on/off. I’ve used formatted SDs in exFAT and FAT32. I am using Arduino IDE.
From what I can tell, it seems like everything should be plug-in-play type of thing, but I can’t seem to get it to be so. It seems like I’m missing a step along the setup process. Any advice would be appreciated. Please let me know if further background information is needed.
I think you might be getting yourself mixed up here? OpenLog Artemis and the Qwiic OpenLog are two very different products. OpenLog Artemis will recognize and log data from a list of supported I2C sensors. The Qwiic OpenLog is a different type of logger, you push data to it over I2C and it writes it to SD card.
If the sensors you want to use are not on the list supported by OLA, then you could:
Adapt the example code for that sensor so it runs on the RedBoard Artemis and outputs the sensor readings as Serial1 (UART) text data.
Connect the Serial1 TX pin on the RedBoard to the RX pin on the OpenLog Artemis, and the OLA will log that serial data to one file while logging data from any supported, connected I2C sensors to a separate file.
You need to connect GND to GND also.
You can find the list of sensors that the OLA supports here:
Thanks for the input! I’ve got mixed results now and some new issues have popped up.
First off, it seems like the only time I get consistent logging is after I’ve sent over new code to the setup. When I power off the setup, read the SD card, re-insert it, and power it on again, it will not log. I am not sure if it’s me unplugging the setup that messes everything up. Also, I don’t really understand why the only time I can get it to log is directly after a new upload.
Another thing, I am having trouble keeping the settings the same between new sketches and between checking the SD card, especially the RTC from resetting. Again, I don’t know if it is due to my method of powering off the system.
Finally, I’ve encountered a few instances where the SD card becomes corrupted, or at least Windows says I need to format it again. This seems to happen whenever I press the reset button on the OpenLog Artemis.
I think that’s all the major issues/inconveniences for now. Again, please let me know if I need to provide any more information.
You do need to be careful how you ‘power down’ the OLA so it stops logging cleanly and closes the files correctly. Please have a read through of the hook-up guide, especially the section on Low Power Considerations. Adding and enabling a ‘stop logging’ button may be a good idea for your application?
If I’m understanding this section correctly, I just need to ground pin 32 on the OpenLog Artemis module whenever I want to physically put it in deep sleep mode (in a way, off). This can all be done physically, and there is no additional coding that needs to be done, correct?
I’ve encountered another hiccup with the OpenLog Artemis. It seems like the only RTC timestamp to log in to the serial is 10. I have tried 13, 27, and other unformatted deci timestamp tokens, but they seem to be unrecognized by the OpenLog. I have done the Q->Y approach to safely close the OpenLog, and I have enabled Pin 32 turn-off to safely turn off after a log session. I also check the OpenLog settings on the SD card, which for some reason seem to differ from the settings I just saved from the Q->Y. Is there an optimal way to call in a timestamp token for OpenLog to see it consistently? I’ve been using Serial1.print(10); function.
Just so that I can get the best results, I would like the timestamp to be on the same line as the token. I believe “10” puts the timestamp underneath the token. If/When I get consistent token calling results, which option (10,13,27, other) would be best to achieve this result?
For reference, I would like each line of data to be: “end line”, or “end line”.
You can enable and adjust the serial timestamp token in the Configure Serial Logging menu - but I guess you already did that? Once enabled, it defaults to decimal 10 (Hex 0x0A) which is line feed. 13 is carriage return - another good choice.
You need to make sure that your serial device / RedBoard code is adding the terminator correctly. Just to make sure you can use Serial1.print(“\r\n”); to print both a carriage return and a line feed. println should add both automatically, but it’s good to do it manually just to make sure both are sent. Another way is to use write: Serial1.write(10); and Serial1.write(13); . Be careful with Serial1.print(10); as it will send the ASCII characters “1” and “0”…
Sadly, there is no way to adjust the printing format of the timestamp - unless you change and recompile the code. The relevant lines are here: