OpenLog reading a params file

[johndk]

I've been using OpenLog to capture data for later analysis. It works great, especially when you create csv files that import nicely into Excel. However, I would like to be able to read some parameters from a params.txt file to set some of the conditions of the programs I'm running. I'm having trouble capturing the read.

I'm trying this code on a 28x2 after I put the OpenLog in command mode.

ptr = sp_params
serout log_rxi,T9600_8,("read PARAMS.TXT 29,10",cr)
serin log_txo,T9600_8,(@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr)

to read

run time in hr;period in sec
5;60

from the params.txt file and extract the 5 and the 60. It should go to position 29 and read the next 10 characters. But I get nothing captured to scratchpad. What am I missing?

 

[hippy]

Not familiar with OpenLog but, if the program is getting past the SERIN then it must have read something, and that something must have been placed in scratchpad. Perhaps fill the scratchpad area with $FF or something so you can tell if $00 are being received.

You could start with reading just the first byte, then read the first two, build up from there.

 

[Jeremy Harris]

My experience with OpenLog is that it is fine when you read whole files, as long as the serial timing is spot on, but does have some quirks. It was really intended as being just a very simple device for reading a stream of serial data into a file, such as that from GPS, and doesn't always respond as you wish when trying to do things such as you are trying to do.

Is there any way you can read the whole text file, parse out the bits you need, then just use them and discard the rest, rather than trying to get the OpenLog to do it?

In theory it "should" do what you want, but I found that the OpenLog didn't always do what I expected. Also, there are some timing issues with it, in that is is fairly senstive to baud rate and in Command mode it sometimes needs pauses between instructions to respond correctly. I found that I need to send single, rather than concatenated, commands with small pauses between to get some commands to work.

It might be worth going over to the SparkFun community and asking them, as they still have the repository for all the code with all the known issues logged, I believe (some time since I've been over there, but I think they put it all up on GitHub).

 

[johndk]

I could easily read the entire file and parse the results. But I can't find the documentation do do that other than what I've stated. Does anyone have any code to read an entire file from OpenLog? As to checking to make sure it hasn't written 'something' to sp, my code actually hangs on the serin part. So it seems a problematic way of streaming the file contents.

However, I frequently use the following to check if OpenLog is in the command mode.

serin [logger_pause,cmd_error],log_txo,T9600_8,(">")

That works flawlessly, but is comparing the input byte to ">", not capturing it.

I really like OpenLog. It's very versatile and "bulletproof". I'm sure there's a way to read file data into variables. I just haven't found it yet.

 

[johndk]

I think I just solved my own problem, although I haven't tried it yet. As often as I refer to the basic manual, I keep finding little syntax things that trip me up. As I was thinking about my problem, it occurred to me that I should check the syntax. And sure enough, it looks like the parenthesis indicate a comparison ... just as I mentioned in my previous post. That's why the program would hang there, waiting for the correct byte sequence. So if I read the syntax correctly, if I drop the parens, the statement should populate my scratchpad with the OpenLog output. Still to be tested, but logical enough.

 

[hippy]

And sure enough, it looks like the parenthesis indicate a comparison

You are right; SERIN (...) specifies qualifiers, so will be waiting to match what's within the brackets rather than store the data. I did not spot that in your first post.

 

[johndk]

Works almost like a charm. OpenLog doesn't want to recognize the first parameter in "read PARAMS.TXT 29,10" which indicates it should start to send characters starting at character #29. It actually always starts at the beginning of the file and puts in 3 garbage characters. Whatever the reason, it's consistent, so easy to work around. Other than that, I'm happy that I can get a parameter set from a uSD card.

Anyone reading this, if you haven't tried OpenLog, you should. Except for a few little quirks, it's almost bullet proof. And you can store up to 64Gb of data!

 

[Jeremy Harris]

I agree with you 100% about OpenLog, they are superb little units, once you get used to their quirks.

I have three running on various projects 24/7, all with Picaxes doing all the work and feeding logger data to the OpenLog. Well, one is actually an SDLogger, same thing (almost - some minor differences) that uses a full size SD card, rather than a µSD card.

I spent a long time trying to get a VDrive2 working, but failed miserably, whereas I had the OpenLog working in minutes. For anyone wanting to use one I do suggest reading both the documentation plus searching this forum for projects that have used them, as most of the quirks have been documented here somewhere. My own projects that I've documented here are:

http://www.picaxeforum.co.uk/showthread.php?20551-Environmental-uSD-card-data-logger

http://www.picaxeforum.co.uk/showthread.php?23893-Air-quality-monitor-and-logger

http://www.picaxeforum.co.uk/showthread.php?20563-Data-logging-to-a-microSD-card