-
Notifications
You must be signed in to change notification settings - Fork 220
Log Names #160
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Actually, the change in behavior you're requesting is quite easy to make. In the newlog() function, a minor rearrangement of the code in lines 428 through 454 (from v3.21) would give you the desired operation, as follows:
The only side-effect is that the first log file generated on a new OpenLog unit off the production line would be "LOG00001.TXT" instead of "LOG00000.TXT". The user would never notice this, but this might cause a minor problem with production testing. |
Thanks for the reply. I have not been able to locate the source code. Can Dave On Fri, Oct 25, 2013 at 5:52 PM, dlkeng notifications@github.com wrote:
Dave Newland |
Go to https://github.com/sparkfun/OpenLog On the right side of the screen is a column of items. The bottom item is a button labeled Download ZIP. |
This is a simple enough change to make. I'll try to roll it into the next version. |
Another side-effect of the suggested changes, that the user might notice, is item # 4 on the "set" submenu: "Reset new file number". When this is done with the above suggested changes in place, the response "New file number reset to zero" is not true anymore - it will be reset to one (unless an empty file with the name of "LOG00000.TXT" exists on the SD card, in which case it will be reused). |
I have another suggestion or two. The documentation doesn't seem to mention the maximum number allowed for I was hoping that zero would disable the escape to command mode feature. It Thanks, On Fri, Oct 25, 2013 at 5:52 PM, dlkeng notifications@github.com wrote:
Dave Newland |
It looks like it is hard-coded from 1 to 9 escape characters. See lines 2061 to 2068:
It is stored in a byte variable, so this code could be changed to support a larger value up to about 254. |
To address the log name issue, I moved
towards the end of newlog()
This works and only adds one variable increment which takes 6 bytes. This fix also starts the logs at 0. dlk's solution adds an sprintf() which takes 80 bytes. Double check me but I think this will work. Will go into v3.3. |
Log file name increments correctly in v3.3. |
OpenLog creates a new log file each time it powers up. It will use the next sequential number so you have LOG00008.TXT then LOG00009.TXT if you don't erase anything.
I find that if you erase the log files with a computer and then put the chip back into OpenLog it will start with the last number (00009) instead of moving on to the next (00010). Now if I move the newly created logs to my computer I will have two 00009 logs. Then all of the logs need to be renumbered. You can cycle the power once to create a fake log that can be tossed (until someone forgets). You could also leave a copy of the last log on the chip (waste of space) or create a blank one (waste of time).
I am not touching the config file (57600,36,3,0,1,1,0) or anything, just - creating a few logs by cycling the power, moving the chip to a computer, erasing the logs, moving the chip back to OpenLog, creating a few more logs.
The text was updated successfully, but these errors were encountered: