Release candidate

[whipple63]

This version contains 3 changes (in 3 commits):

1. Reset option added to debug menu (via resetArtemis) We occasionally get in a state where something in the software is out of whack. We have remote access to our system, but physical access is much more difficult. The ability to reset from the menu would be a significant benefit. We might even use this feature to do daily resets to assure stability.
2. Turned off automatic increment of file number after using SD card menu (issue #140) Having looked into this, the one thing a user can do from the SD card menu that affects files is to delete them. In the existing (pre-modification) version, findNextAvailableLog is always called. This has the effect of incrementing the file number. The desired effect is to not increment the file number. Since the user can interfere by deleting files, this new version checks to see if the current sensorDataFile/serialDataFile still exists. If it was deleted, findNextAvailableLog is still called. Otherwise it is not. Although this brings up the question is this what should happen? The routine findNextAvailableLog begins its search at settings.nextDataLogNumber. If the user has deleted several (or all) data files, perhaps the search should begin at dataLogNumber 1. This could take a long time if there are a lot of files, but maybe that’s the right thing to do if files have been deleted. Perhaps that check should be done in setup too. Often I will take the SD card out, copy the data files, delete them, and put the card back in. How else can the file number be reset besides manually editing the settings file?
3. Added timeout to SD card menu We occasionally get stuck in the SD card menu. We do automated file downloads via a Bluetooth link. If we lose connectivity while in the SD card menu sampling does not resume until connectivity can be re-established and the remote system recognizes the problem and fixes it. (Connectivity loss is on purpose because the sensor sometimes goes under water.) A timeout in the SD card menu will allow sampling to continue.

[PaulZC]

Hi Anthony (@whipple63 ),

Thanks for submitting this pull request. (I guess you and Ryan are working together on this?)

Merging into release_candidate for testing...

Best wishes, Paul

[whipple63]

Yep, we sure are. Thanks a million!

[PaulZC]

This seems to be working nicely. I've added your code to v2.5. Ihave also added support for the ISM330DHCX (IMU) and MMC5983MA (Mag) - primarily for the IMU-less version of the OLA.

I take your point about resetting the log file count to zero. Personally, I quite like that it never resets. The count simply keeps on incrementing, making each file unique even if you do delete the older files. However, it should be straightforward to add a reset-count option in the SD or debug menu. I'll have a go at that now, while I'm in there...

I should have a BETA binary for you to test shortly.

[whipple63]

I also found a print statement bug in menuAttachedDevices. I was just compiling to see if I fixed it correctly, but since you are working on it now, here is what I have for lines 2464-2490:

if (sensorSetting->log == true)
{
  char tempStr[16];

  SerialPrint(F("2) Log Pressure: "));
  if (sensorSetting->logPressure == true) SerialPrintln(F("Enabled"));
  else SerialPrintln(F("Disabled"));

  SerialPrint(F("3) Log Temperature: "));
  if (sensorSetting->logTemperature == true) SerialPrintln(F("Enabled"));
  else SerialPrintln(F("Disabled"));

  SerialPrint(F("4) Log Depth: "));
  if (sensorSetting->logDepth == true) SerialPrintln(F("Enabled"));
  else SerialPrintln(F("Disabled"));

  SerialPrint(F("5) Log Altitude: "));
  if (sensorSetting->logAltitude == true) SerialPrintln(F("Enabled"));
  else SerialPrintln(F("Disabled"));

  olaftoa(sensorSetting->fluidDensity, tempStr, 1, sizeof(tempStr) / sizeof(char));
  SerialPrintf2("6) Fluid Density (kg/m^3): %s\r\n", tempStr);

  olaftoa(sensorSetting->conversion, tempStr, 3, sizeof(tempStr) / sizeof(char));
  SerialPrintf2("7) Pressure Conversion Factor: %s\r\n", tempStr);
}
SerialPrintln(F("x) Exit"));

Tony

[PaulZC]

Good find - thanks! Yes, the pesky Artemis %.02f issue... I thought I'd changed all of those!

[PaulZC]

Hi Tony (@whipple63 ),

Please give these binaries a try:

https://github.com/sparkfun/OpenLog_Artemis/blob/main/Binaries/OpenLog_Artemis-V10-v25_BETA.bin

https://github.com/sparkfun/OpenLog_Artemis/blob/main/Binaries/OpenLog_Artemis-V10-v25-NoPowerLossProtection_BETA.bin

Your log file reset option is in the debug menu. Let me know if it does what you need.

I'm on UK time and downing tools for tonight. If you're still making changes - that you'd like included in v2.5 - let me know and I'll wait for them before I do the release.

Thanks, Paul

[whipple63]

I will test these on the bench immediately and probably put one in the field this afternoon.

[whipple63]

Behavior is a bit quirky. I had 5 data files, deleted them all from the SD card menu, went to debug menu and set next data log number to 1 and returned to logging. Data file 5 re-appeared (which was kind of expected in-between menus) and then we started logging to file 0 (not 1).

[PaulZC]

The logging to file zero is expected. There's some slightly strange historical wizardry in findNextAvailableLog which means it checks to see if the previous file was empty and re-uses it if it is. This was to prevent a new file being created at every boot, even if the previous one had no data in it.

But file 5 reappearing is a bit annoying. Ah. OK. It's your file name logic fighting with mine.

You open the SD menu. Delete the files. Exit that menu. exists(sensorDataFileName) is false, so you beginDataLogging using the next available file which is 6 that becomes 5 for the reason above.

Then you open the debug menu, set the number to 1 and a new file 0 is created when you exit the debug menu...

OK. To fix this, I need to let you reset the log file number inside the SD card menu. I don't really want to do that as that menu is supposed to be command-line-like. But needs must.

Unless you come up with a better method, I'll change it like this in the morning.

Cheers for now, Paul

[PaulZC]

OR - how about this? If you delete any files in the SD menu, then the next file number is automatically set to 1. So the code will attempt to start logging to file zero when you exit the menu.

[whipple63]

Someone might have just deleted the current file. What about if any file was deleted, call findNextAvailableLog with an argument of either 0 or 1? (You know I don't feel that strongly about having to reset the file numbers - we could always just undo!)