Datalogger + BS2 or SX ( @115200 )
Unsoundcode
Posts: 1,532
This project is something I have kept returning to over a period of time and recently discovered a couple of important points that had previously eluded me. The included explanations are complete enough to provide enough information to add or subtract the different features supported by the Datalogger.
The most important feature to my mind is initialisation and detection of the logger and memory stick , beyond that it is simplicity in itself to call the various VDAP instructions contained in various subroutines , the VDAP firmware instructions· are a must for reference and can be found at this link
http://www.parallax.com/Portals/0/Downloads/docs/prod/comm/VDAPFirmwareSpec.pdf
The method is to eliminate the use of CTS/RTS and to use information returned from the Datalogger as sychronization. Because the VDAP firmware is very explicit on the instructions received and in turn the response it replies with then with careful thought and programming we can reduce the overhead of coding for errors that otherwise might appear. That is not to say there is no room for improved error detection , but initially I feel it should not be needed.
One subroutine that could easily give an erroneous reply is SIZE , SIZE will read the size of a file in bytes , being limited to a word value then anything greater than 65535 bytes cannot currently be read accurately , this should not affect performance.
Data transfer is at 4800 baud which will give for example a packet write of 10 bytes in excess of 14 times per second including data aquisition. The attached BS2 example will write two files to a drive in two different ways indexing the filename as 1 and 2 respectively.
The program is very robust and very reliable , thoughts positive or negative are welcome
Jeff T.
·
Uploaded SX version 6/3/09 (see post #6)
Post Edited (Unsoundcode) : 6/3/2009 2:19:55 PM GMT
The most important feature to my mind is initialisation and detection of the logger and memory stick , beyond that it is simplicity in itself to call the various VDAP instructions contained in various subroutines , the VDAP firmware instructions· are a must for reference and can be found at this link
http://www.parallax.com/Portals/0/Downloads/docs/prod/comm/VDAPFirmwareSpec.pdf
The method is to eliminate the use of CTS/RTS and to use information returned from the Datalogger as sychronization. Because the VDAP firmware is very explicit on the instructions received and in turn the response it replies with then with careful thought and programming we can reduce the overhead of coding for errors that otherwise might appear. That is not to say there is no room for improved error detection , but initially I feel it should not be needed.
One subroutine that could easily give an erroneous reply is SIZE , SIZE will read the size of a file in bytes , being limited to a word value then anything greater than 65535 bytes cannot currently be read accurately , this should not affect performance.
Data transfer is at 4800 baud which will give for example a packet write of 10 bytes in excess of 14 times per second including data aquisition. The attached BS2 example will write two files to a drive in two different ways indexing the filename as 1 and 2 respectively.
The program is very robust and very reliable , thoughts positive or negative are welcome
Jeff T.
·
Uploaded SX version 6/3/09 (see post #6)
Post Edited (Unsoundcode) : 6/3/2009 2:19:55 PM GMT
Comments
DJ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Instead of:
"Those who can, do.· Those who can't, teach." (Shaw)
I prefer:
"Those who know, do.· Those who understand, teach." (Aristotle)
·
The BS2 with its single slot , no SPRAM and limited baud rate make it a challenge to use with the Datalogger.
I wanted to put something out that I have learnt by trial and error that demonstrated in a different way to the "norm" that it is possible to develop a useful application with a plain BS2 Stamp.
Apart from the ability to log at a decent speed the whole thing can fit in less than 40% of EEPROM leaving a fair amount of room for other tasks.
I also wanted the SimpleLog example to work first time for everyone that tried it , it instills a lot of confidence if things work first time.
Thats where it gets a little uncertain , I would love to hear if there are any problems I may have missed or if in the main it proves successful. For me it works without a hitch.
regards
Jeff T.
Absolutely correct, which is why·that approach is·a great teaching tool.
BTW - if my evening goes as planned, I'll be exploring the wonders of VB 'structures'.
Later,
DJ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Instead of:
"Those who can, do.· Those who can't, teach." (Shaw)
I prefer:
"Those who know, do.· Those who understand, teach." (Aristotle)
·
In making the project connection even more simple,
have you thought about using one wire for the serial interface
instead of two wires?
Here's an example of a one wire one pin interface for serial Tx/Rx.
http://forums.parallax.com/attachment.php?attachmentid=60089
humanoido
Having only used the Datalogger with the BS2 series it was a treat to see the gain in speed , tested using 115200 baud with 5000 bytes in 5 byte packets @ < 12 Sec (the timing is a close approximation).
The connection is basically the same as for a Stamp with the addition of a seperate tx/rx line for a debugging terminal which I connected to via a Max233. These connections should be obvious by the pin assignments at the heading of the SX/B code.
The heart of the program is a sub routine that transmits VDAP instructions that are stored as data instructions , combined with the text from the original post it shouldn't be too difficult to add more of the VDAP features.
Jeff T.
Nice stuff, as usual!!
I have a logger app for a PLC project and this may get it closer to the front burner, again.
Cheers,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk
http://www.siskconsult.com
·
I believe the SX / Datalogger combination would work well for your application.
Here's something that doesn't hit you in the eye and is worth consideration from anyone that wants a faster throughput.
The Get_data sub routine was hashed together just so I could write some example data to a text file allowing people to quickly test the program and examine the results on their PC.
Each sample is a 5 byte packet which is made up of 1 byte value converted to 3 ASCII characters then formatted with 1 byte carriage return and 1 byte line feed.
So although 5000 bytes are written it actually only equates to 1000 samples. If instead of writing as a text file you were to write to a binary file·, removing the formatting, you could theoretically reduce the time writing 1000 1 byte samples from ~12 Sec down to ~3 Sec. (300 samples per sec)
When it came time to read the data back at the PC you would need a simple reader to read the binary file and format it as a text file that created a table for the samples.
regards
Jeff T.