BS2P24 with Vdrive2 and GPS
Mr.Ed
Posts: 35
Hi,
Is anybody familiar with using the Vdrive and storing data on a regular basis? I'm a bit stuck here and i was wondering what i was doing· wrong here.
I grab the GPRMC string from the GPS receiver and store it to the Vdrive. But after every 8 or 9 lines i get a bit of rubbish in my loggings. It looks like this :
161028.000,A,5153.2402,N,00436.1043,E,0.48,30.16,130407,,*
161030.000,A,5153.2404,N,00436.1045,E,195417.46211340.6154161030.000,A,5153.2404,N,00436.1045,E,1.41,35.94,130407,,*
161033.000,A,5153.2407,N,00436.1050,E,0.88,28.71,130407,,*
161035.000,A,5153.2404,N,00436.1047,E,0.52,250.15,130407,,*
The first line is the 8th line of the log. The 9th line is garbled and the 10th is ok again. This repeats itself on a regular basis. Is it a unsolicited message from the Vdrive? But how did it get there, then? This is supposed to be GPS data only. And i presume that my GPS receiver is functioning properly. It's an EM406 from coolcomponents.
Anybody any thoughts on this?·
·
Ed.·
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A horse is a horse, of course of course...
Is anybody familiar with using the Vdrive and storing data on a regular basis? I'm a bit stuck here and i was wondering what i was doing· wrong here.
I grab the GPRMC string from the GPS receiver and store it to the Vdrive. But after every 8 or 9 lines i get a bit of rubbish in my loggings. It looks like this :
161028.000,A,5153.2402,N,00436.1043,E,0.48,30.16,130407,,*
161030.000,A,5153.2404,N,00436.1045,E,195417.46211340.6154161030.000,A,5153.2404,N,00436.1045,E,1.41,35.94,130407,,*
161033.000,A,5153.2407,N,00436.1050,E,0.88,28.71,130407,,*
161035.000,A,5153.2404,N,00436.1047,E,0.52,250.15,130407,,*
The first line is the 8th line of the log. The 9th line is garbled and the 10th is ok again. This repeats itself on a regular basis. Is it a unsolicited message from the Vdrive? But how did it get there, then? This is supposed to be GPS data only. And i presume that my GPS receiver is functioning properly. It's an EM406 from coolcomponents.
Anybody any thoughts on this?·
·Ed.·
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A horse is a horse, of course of course...
Comments
Couple of things to try:
Slow down the data string from the GPS to something slower ( 2400 baud, maybe). See what that does to your data file.
I think your data is saying its being repeated every 2 seconds or so, which should be ok, but there may be some timing issues with the Vdrive writing or opening files. Note that the repeated data has exactly the same time stamp as the first part of that string.
Open up Hyperterminal on a PC and watch the data come in from the GPS. See if the garbled data is there as well, which would point at the GPS as the culprit.
Cheers,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk
http://www.siskconsult.com
·
A suggestion I have is to use the DEBUG screen to send exactly what you’re sending to the VDRIVE to verify where the data is corrupted. While it may be on the VDRIVE side, you want to be sure. Which interface mode on the VDRIVE are you using?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Thank you for replying. I'm using the Vdrive with the UART mode, 9600 baud. I tried to slow that down (not succesfully, didn'tknow how), but the garbled data is quite constant. If baudrate would be an issue, so that the stamp cannot keep up, the garbled data would be quite random.
This is what i have sofar, nothing fancy (a bit wobbly, the spacing is off):
'
' BSLogger : Written by Edwin van Brugge (evb.tech@xs4all.nl)
'
' {$STAMP BS2p}
' {$PBASIC 2.5}
' Example $GPRMC
' 200855.000,A,5153.2299,N,00436.1015,E,1.39,157.32,120407,,*
' 123456789012345678901234567890123456789012345678901234567890
'········· 1········ 2········ 3········ 4········ 5········ 6
'
VdriveTX······· CON···· 6
VdriveRX······· CON···· 7
VdriveBD······· CON···· 240
GPS··············CON···· 8
GPSBD·········· CON···· 500
'
a·············· VAR···· Byte
b·············· VAR···· Byte
char··········· VAR···· Byte
mem············ VAR···· Byte
wrcount········ VAR···· Byte
'
WarmUp:
'DEBUG "Warming up Vdrive and GPS for 30 seconds", CR
PAUSE 30000··················································· 'Wait for GPS & USB init
InitVdrive:
'DEBUG "Init Vdrive", CR······································· 'Close and set to ASCII
SEROUT VdriveTX, VdriveBD, [noparse][[/noparse]CR, CR, "CLF Edwin.txt", CR, "IPA", CR]
GetGPSData:
'DEBUG "Collecting GPS data", CR
SERIN GPS, GPSBD, 5000, NoGPSData, [noparse][[/noparse]WAIT ("GPRMC,"), SPSTR 60] 'Grab GPRMC string
CheckLength:
'DEBUG "Checking length of GPS string", CR····················· 'Length of file
FOR mem = 0 TO 59
GET mem, char
IF char = "*" THEN GOTO StoreGpsData
NEXT
StoreGPSData:
'DEBUG "Storing data to USB stick", CR
wrcount = (mem + 2)
SEROUT VdriveTX, VdriveBD, [noparse][[/noparse]CR, CR, "OPW Edwin.txt", CR, "WRF ", DEC wrcount, CR]
FOR mem = 0 TO wrcount
GET mem, char
SEROUT VdriveTX, VdriveBD, [noparse][[/noparse]char]····························· 'Write byte
IF char = "*" THEN GOTO CloseFile
NEXT
CloseFile:
'DEBUG "Closing file", CR
SEROUT VdriveTX, VdriveBD, [noparse][[/noparse]CR, CR, "CLF Edwin.txt", CR]······ 'Close file
PAUSE 2000···················································· 'Resting break
GOTO GetGPSData··············································· 'Start again
NoVdrive:
'DEBUG "No Vdrive data found!", CR
GOTO WarmUp
NoGPSData:
'DEBUG "No GPS data found!", CR
GOTO WarmUp
Maybe i'll try debugging more to see where it goes wrong...
(LAST EDIT: The GPS data from scratchpad RAM is debugging beautifully onto the screen, no errors there!)
Ed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A horse is a horse, of course of course...
Post Edited (Mr.Ed) : 4/13/2007 10:07:51 PM GMT
First I am using the shortened command set, the reason , from my point of view, is that it simplifies what I call the "handshake". Each time I transmit I wait for SERIN rx,baud,[noparse][[/noparse]WAIT (">")] which confirms the vdrive has recieved a byte and is waiting for the next. I removed some of the CR's because everytime you send a CR it sends back the prompt, if this is part of your formatting you·might want to work them back in, but I noticed sometimes that the prompt is really slow to come back.
I only open the file once, I figure if you are writing every two seconds just keep it open until you have collected all your data (my example doesn't actually show this.).
The GET char and transmit char are both contained in·a·one loop which means the previous WRF directive "number of bytes to write" is a constant one, the for next loop (0 TO wrcount) controls bytes to write. I omitted the second check for the asterisk I felt the first check was sufficient. I also feel that the serial instructions "bytes to write" and "data to write" works better in one serial statement but then again I might be wrong.
I included a sub to change the baud in case you ever want to use it, I change baud before any other commands using the initial 9600 when it leaves the sub any other reference to baud should be at the new value.
I hope there is something in there to help
Jeff T.
Jeff T
Last Sunday i took my BSLogger on the road during a 10Km run in Rotterdam. At the same time the Marathon of Rotterdam was held. Unfortunately te weather was way too hot, so the authorities canceled part of the Marathon. They feared people could get killed in these circumstances. I managed to finish my 10Km, in 01 hour, 09 minutes and 52 seconds. I was pretty pleased with that. Now you see why i had to rush my code, and couldn't reply soon enough. Unfortunately, something went wrong and allthough i managed to get a GPS fix between the buildings, NOTHING is recorded. I still don't know why that happened. Technology simply failed on me. Physically things were tough, but i pulled through...
I appreciate your effort in helping me, and i want to push this project further along, having learned from the experience last sunday. I seek to repeat running with the logger and improve performance, making it more fail and fool proof
A few remarks on the way i wrote my code. I give way more carriage returns than necessary. The reason for this is that sometimes i noticed that a command returned a "Bad Command" reply. So giving an extra CR insures that the next command should get through correctly. I know, it is not a nice way to write code, and a lot of overkill. Baudrate was allso on my mind, but if the stamp cannot cope, the rubbish should be more random, and it is not. Actually, i see a returning pattern in the rubbish. The way i see it now, the Vdrive is showing "old data" mixed with true live data. The rubbish is exactly like pieces of GPS string with old timestamp. The software version of my Vdrive is 2.08 i believe. Updating this could make a difference, but i did not look into firmware upgrading sofar. I hoped it could be done by means of the flash drive, but i do not have the proper file for the USB stick.
I will look into your code more closely and get back to you on my finds. You have put work into this and it was way more than i hoped for. I will give your code a try and see if things improve from here. I DO believe in the Vdrive to be the solution to my storage problems, but sofar it did not prove to be very relyable. Lets work on this.
Thanks sofar and i'll get back to you soon...
Ed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A horse is a horse, of course of course...
What I wanted to tell you is at one time I ran a test on the vdrive writing 1Kb a byte at a time as fast as I could with the BS2. There were two places during the write that it would hang for quite a long time , maybe as much as·one second. It would always hang at the same two places.·What I am saying is that this may be a part of the reason your problem does not seem random, it may lay in the capabilities of the vdrive. If the vdrive has hung for 1 second and you try to write again·during that time your results will contain errors, thats the importance of waiting for the prompt to come back.
By adding the statement that waits for the prompt to return I can write at 19200 with 100% success, although to err on the safe side if 9600 will do the job stick with it. If you can work it out so that the writes are in blocks your data should fly.
Jeff T.
P.S nice run.
I tried some of your code and it finally hit me. I see your point. Thank you VERY MUCH.
It is working 100% now, at a baudrate of 9K6 and logging nicely exactly every 2 seconds, wich is fast enough for my purposes. When i debug al the GPS data directly to the screen now, i see that it is not flowing smoothly, but rather jerky. That might be caused by the debugging, or more likely, it could be the Vdrive not responding in a nice flow. When pushing data in, byte per byte, and waiting for the prompt, it HAS·to store it correctly. And it does!
When i try 19K2, it is somewhat faster, but then it records only every 1 or two seconds. Nut much gain for my purposes. I even tried 38K4 but could not get that to work . It might be·an inability of the BS2P24. But again, i don't need it so i did not go further into that. I don't want to risk trying to store too fast and loose data in the end. I know how THAT feels!
I am very pleased with the outcome. Too bad i did not have this setup when i ran my 10Km last Sunday. But i'm not complaining. There will be more 10Km runs.
Thanks for your support, good job!
Ed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
A horse is a horse, of course of course...