Eric: You are using a standard Parallax ProtoBoard? The xtal should be 5MHz. However, since you cannot get it to work at 115200 baud but 110000 does, it would seem the xtal is faulty. The protoboard has a socketed xtal so you could replace it.
If you are using your own design pcb, then perhaps the xtal has incorrect specs, or your pcb layout is way incorrect.
Anyway, something is wrong because you must be able to get 115200 baud working to your USB chip.
Those are odd baud rates as Clusso99 said. I have used 4800 from the GPS and 115200 to the PST from a stock Proto board.
For GoggleEarth logging, I use this Object on a Proto board all the time with a 2GB uSD card, and have logged a 6,000 mile round trip with using less than 1MB of KML data.
There is another logger with some enhancements in the OBEX:
This is what I ordered and paid for:
32812: Propeller Proto Board USB : 1
Also carries a label stating its the Parallax Proto Board...
Is there any way to check xtal speed? Can it be reset?
How bad is this? Does it really need to be replaced??? I seems to work ok (with these baudrates).
Did I burn it somehow? I'm not sure if I can replace it myself :-( At least it doesn't seem to be an expensive item.
Thanks Jim for your suggestion. I tried to understand it (still difficult) and if I'm not mistaken only Longitude and Latitude are logged, where I'm interested in winddata.
Is this the check for the A in the GPGGA string in the PUB GElog | idx, DD, d8, decDD? sdfat.popen(@fname, "a")
Followed with the
I'm not sure I quite understand this part; I need to write/rewrite quite a bit here I'm afraid?!
This is what I ordered and paid for:
32812: Propeller Proto Board USB : 1
Also carries a label stating its the Parallax Proto Board...
Is there any way to check xtal speed? Can it be reset?
How bad is this? Does it really need to be replaced??? I seems to work ok (with these baudrates).
Did I burn it somehow? I'm not sure if I can replace it myself :-( At least it doesn't seem to be an expensive item.
Thanks Jim for your suggestion. I tried to understand it (still difficult) and if I'm not mistaken only Longitude and Latitude are logged, where I'm interested in winddata.
Is this the check for the A in the GPGGA string in the PUB GElog | idx, DD, d8, decDD? sdfat.popen(@fname, "a")
Followed with the
I'm not sure I quite understand this part; I need to write/rewrite quite a bit here I'm afraid?!
Eric
1.) Sounds like a standard Parallax Proto Board, 5Mhz. Are you running it off a standard PC via USB port or a Mac?
2.) It does not look like Goggle Earth KML supports WindData as exported with $II data. That should not be too hard to parse out to a video output, (TV or VGA), or to the SD card for that matter. It just would not plot on Goggle Earth.
Eric: The xtal is socketed. I know it does not look like it. They are just socket pins under the xtal. I think your xtal is faulty. If you contact parallax I am sure they will send you a new xtal. And it is unlikely anything you have done, just a faulty xtal that is out of spec. Sooner or later you will want to run some code that requires a known correct xtal.
Meanwhile, to prove this, try changing you code where it says _XINFREQ = 5_000_000 to _XINFREQ = 5_235_000 and set your baud rates to 4800 and 115200 and the xtal to the value it is outputting.
Eric,
while the Tacktick side s unknown, for sure the serial comm PC side must be well defined. If the baud rate does not fit there is a problem.
Besides a Xtal issue it could be a typo in the program where the frequency is set.
Just to be sure try to export the program and post it.
Under the propeller tool - file there is an option to export the whole project as a zip.
Massimo
Yep, it works! :-)
Thanks for that. You almost had me worried that my board was already broken....
Time to move on!
I was thinking to use the PUB readNEMA from the GPS_IO_mini.spin in the GPS_to_VGA project to extract the desired NMEA data.
I use GPS_IO_mini (a modified version) a lot to extract GPS and wind data, and it works well.
Consider GPS_to_VGA can be adapted to be used with PC terminal with little changes. In place of the VGA object use the serial terminal. Many methods are the same or very similar, so for the first tests you could try to adapt it.
I had problems in the past with this object because the stack space is very tight, so the object as it is works, while if you modify it you can have strange issues. Just to be safe increase the stack space before changing the code.
The "A" on the GPGGA means the GPS position is valid, so you log only in this case.
For SD logging you need a SD adapter. There are a lot of options around and all are ok.
The SD objects are quite forgiving, for instance I have a veroboard adapter with no pull ups working happily with fsrw.
There are even examples on the web of microSD adapters used as sockets and soldered directly....
the line you mentioned
sdfat.popen(@fname, "a")
opens the file with the name string pointed by @fname.
the "a" means the file is opened in append mode (the new data is added at the end of the file).
I found this modified program I used for the first tests with the GPS, I guess I adapted the existing code.
Not very elegant but it should work and get you started:
You have to configure the serial comm with the NMEA/GPS unit in the GPS_IO_mini object.
Eric,
please post the modified code, it will simplify bug hunting, and for sure increase the stack space. There are objects to calculate required stack space too, but for sure GPS_IO_mini is very tight, so first thing is allow a much bigger (3-4 times) stack space.
I tried to play a little with your code, and it looks ok, I'm reading data from an anemometer sending MWV strings (I changed the code), but I only have this string to parse.
In the past I had problems with only 10 as stack space. For a start try to use 30 or 50 in GPS_IO_mini in place of
long gps_stack[10]
With so little stack space it was impossible to get time from RMC strings, and I spent quite a lot of time to figure it. Even if the problem is elsewhere we are sure stack space is not a problem.
tried increasing stack to 50, but still instable :-(
looking at the log I noticed that all RMC data are stable, GLL (time) and VWR are not. So I changed to the timestamp from the RMC sentence, which seemed to give stable timestamps (>500 measurements)
When only logging VWR, I thought stability was good after adjusting the variable resistor, but logging the mix again later still showed instability.
Sometimes i get the feeling the changes are (also) induced by me touching equipment (windmeter or PC-terminal), but it also changes when untouched. Probably coincidence...
Why would the VWR sentence bemore difficult??? data from the Tacktick are not reliable??
RMC is te first of the set to be sent out I think:
$IIRMC,213534,A,5217.975,N,00515.925,E,00.0,048,190112,00,E,A*0D
$IIVWR,032,R,00.0,N,,,,*60
$IIGLL,5217.975,N,00515.925,E,213534,A,A*57
$IIMWV,032,R,00.0,N,A*12
$IIMWV,032,T,00.1,N,A*15
Another thing that comes to mind is serial port buffer dimension.
The one you are using is only 16 bytes.
There are drop in versions with bigger buffer, or different objects.
I'll try to find them and post a link.
Massimo
Hi Massimo.
I'm afraid your solution doesn't work :-(
First of all, it was the FDS to be replaced by the FullDuplexSerial_128ByteBuffers (pretty obvious if you look at the name, so I figured that one out quite quickly..)
I got it to work (GPS-stack at 50), but still the VWR-sentence goes wrong every now and than.
I also checked with a version written to read only VWR-blocks, but that didn;t work either (of course) Somehow it sees the IIVWR as block "0" sometimes.
edit
Suddenly I realised I was putting all sentences in buffer, which is not necessary. I only need RMC and VWR. Adapted the project, and the (original) GPS_IO_mini and all problems seem solved!
Over 600 lines logged without problem
GPS=stack at 50.
I think it's time to start looking at saving data :-)
Suggestions for an object to use??
with fsrw you can first of all mount the SD:
fsrw.mount_explicit(0,1,2,3)
then you can open and append to an existing file doing something similar:
fsrw.popen(string("log.txt"), "a") ' opens File in Append
fsrw.sdstr(gps.date)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.time)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.latitude)
fsrw.sdstr(string(" "))
fsrw.sdstr(gps.N_S)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.longitude)
fsrw.sdstr(string(" "))
fsrw.sdstr(gps.E_W)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.speed)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.heading)
fsrw.sdstr(string(" ",13,10)) ' new line
fsrw.pclose ' close the file
"a" in the popen creates a new file, or if the file already exists it adds at the end (append) the new data.
mind coordinates straight from GPS are not compatible with google earth format, so if you want to see your path on the google earth you must modify them in the propeller (check the objects), of in the PC after having loaded them.
Massimo.
Thanks for your advice again.
Today I read a tutorial about SDcards, and learnt about how they work (http://gadgetgangster.com/tutorials/331). Only how to add them to my project...
Now I see :-)
Only thind: when I wanted to order a microSD Card Adapter (#32312) form my Dutch supplier it is mentioned that the cards cannot be read by a PC $:-(
Is that due to the size, or is the format different. I already have a microcard-USB adapter for my phone, that should work don't you think?
Something else I was thinking: I still have an old, broken, sony camera with Sony memory sticks. Would that work (if I can de-mount the adapter from the camera)??? Or do they use different formatting?
First have to get the cards organised now..
Looking at your code, this will only make a one-rule file?
So it needs the "repeat" loop, but how do you stop it then, so I can remove the card?
The google earth format is not important to me, as my Garmin gps will make a lat/lon-log that I can review later (mapsource, or google earth, or any other gps software) Stricktly speaking I probably don't need the lat/lon in my sd-log, but that's the link to the gps-track if I notice something strange.
This is what I put together on first thought:
pub main | gmt
waitcnt(clkfreq*5 + cnt) 'delay (5 secs) to get terminal program running (if required)
Hi Eric,
I'll try to answer your questions, but take my fsrw handling with a grain of salt, I'm not a competent user at all.
The microSD adapter is perfect for your tasks.
The SD card is readable from the PC for sure. The microSD is very tiny, but they are usually sold with a SD adapter, so they fit in any SD card reader.
SD family is the only you can use. CF, XD, memory stick and so on are not compatible with the objects available.
You are right, the code was in a PUB, called in a continuous loop.
I do not unmount the card. FAT16/32 full system driver marks the partition as "dirty" if not correctly unmounted, but fsrw is less picky, so I simply close the file after every write, and at the end of the day I simply switch off the prop and never had issues. To correctly handle the file closing you could add a button that stops everything on demand...
A couple of considerations:
- close the file after the write, not after the waitcnt.
- If the pc is not connected do not use the pst object, there are reset issues. Either comment out the pst parts or use OBC dummy object (you simply change the object name when not debugging with the PC).
check here: http://forums.parallax.com/showthread.php?122321-PST-with-USB-cable-unplugged
- gps.date sends valid values after some minutes of functioning, so either let the instruments run for some time before switching on the prop logger or wait for a "valid" GPS signal before stating logging
as you can see there are code formatting issues, you must enclose the code between the tags:
[ code] and [/ code] -> Just remove the spaces...
there also is a preview post to verify everything is correctly formatted.
Indent is fundamental in spin....
Hi, next step: the micro-SD has arrived and I followed instructions to connect to pins 0 - 3.
Trying to compile the code (and your code as well) I run into unknown subroutine fsrw.sdstr...
My (freshly downloaded) version of fsrw does not contain a PUB calles sdstr! Did you change names,or add a new PUB?
you re right. Not mine, but a modified version nonetheless
Pub SDStr(ptr)
{{
' Addition by John Twomey AKA: QuattroRS4
' Routine added to write a string
' Use as follows in Program -
' sdfat.sdstr(string("this string will be written to SDcard"))
'
' can also do -
' sdfat.sdstr(string("this string will be written to SDcard",13,10))
' the above adds CR & LF (Carriage Return and Line Feed)
}}
repeat while byte[ptr]
pputc(byte[ptr++])
Thanks again!
No more error messages :-)
But.....
My sd-card doesn't seem to mount :-(
Checked connections, they seem good; but still get: "Failed to mount"
In the manual for the card I see pin 0 and 4 set "out", and pin 1-3 as "in". Do I need to set this somewhere, or is it already in the code??
Eric
pub demo | mount, data
waitcnt(clkfreq*5 + cnt) 'delay (5 secs) to get terminal program running (if required)
gps.start
pst.Start(115200) 'EH: 57600 => 115200
i:=0
pst.str(string("Just a start message",13))
mount := \fsrw.mount_explicit(D0, CLK, DI, CS) 'mount card
if mount < 0
pst.str(string(13, "Failed to mount",13)) 'report and halt when failed
else
pst.str(string(13, "SD-card was found and mounted fine.", 13))
pst.str(string("2nd message",13))
fsrw.popen(string("log.txt"), "a") ' opens File in Append
fsrw.sdstr(String("Conto,Valid,TimeGMT,Lat,Lon,Speed,Heading,AWA,L/R,AWS"))
fsrw ignores uses only four pins. Pin direction is taken care of by fsrw itself.
Check the connections, the pin numbers and the supply are correct.
If you download fsrw there is a demo testing SD speed, that works for sure. check the documentation for configuring the pin numbers and the spi driver.
If this is not working there probably is an hardware issue.
side note:
pin direction is a delicate issue and at the begin can lead to strange behaviors. Check the manual on how this is handled.
Massimo, thanks again!
This helps: i made my first log-file today! 100 lines in log.txt :-)
On my sd-card was a file "NMEA", saved by "GPS_SD_Card_TV_Demo_V2.spin" I was playing with. So the problem was software. I found that the GPS_IO_mini was programmed using pin0 for serXmit, causing the sd-card not to work.....
It still took me all day to get the log-file working, but they were minor spelling errors in code.
Thank God it's Sunday!
Now I have some cleaning up to do of the code; remove all trial an error's and comments
The test file in the fsrw was unclear to me, I couldn't get it to work. It needs a file sysdep.spin I couldn't find... :-(
Next I will try a longer log, but I'm running out or daytime.
HELP!! (again..)
I just can't get this worked out: when I don't add a count in the repeat loop for logging data it won't work!??
I included a LED-flash in the loop, and it flashes nicely, indicating the loop runs. A new file is created on the flashdrive, but it's empty; data is not added!!??
Why would "repeat 10" have an effect on "fsrw.sdstr(String("Date,TimeGMT,Lat,Lon,Speed,Heading,AWA,L/R,AWS"))"
OBJ
gps : "GPS_IO_mini"
fsrw : "fsrw"
LED : "LED"
var
long i
pub demo | mount, data
gps.start 'txpin changed 0=>10 ok
'i:=0
mount := \fsrw.mount_explicit(D0, CLK, DI, CS)
LED.Toggle(5, 50_000_000, 2) 'Toggle(Pin, Delay, Count)
fsrw.popen(string("log.txt"), "a") ' opens File in Append
fsrw.sdstr(String("Date,TimeGMT,Lat,Lon,Speed,Heading,AWA,L/R,AWS"))
fsrw.sdstr(string(" ",13,10)) ' new line
waitcnt(clkfreq*5 + cnt)
repeat 10 '"repeat 10" works :-)
fsrw.sdstr(gps.date) 'but not whithout #??
fsrw.sdstr(string(",")) 'LED flashing indicates proper loop
fsrw.sdstr(gps.time) '
fsrw.sdstr(string(","))
fsrw.sdstr(gps.latitude)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.longitude)
fsrw.sdstr(string(" "))
fsrw.sdstr(gps.E_W)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.speed)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.heading)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.AWA)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.LR)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.AWS) '
fsrw.sdstr(string(" ",13,10))
LED.Toggle(5, 500_000, 4) 'Toggle(Pin, Delay, Count)LED flash => runs loop
waitcnt(clkfreq*2 + cnt) '11 2 lines have identical timecode
'
fsrw.pclose ' close the file
fsrw.unmount 'unmount the card at end program
You're a genius! It works!
Is that experience, or can you explain why this is different from the repeat loop we set up for the Parallax Serial Terminal to parse data to pc, to check data flow?
It does seem a bit over the top to open and close the file every line :-$
Thanks anyway ;-)
The LED added is also comforting. I can see when it's active, now. I probably take it out later to reduce power consumption.
Eric
What a mess you can end up with, cleaning up.....
Comments
If you are using your own design pcb, then perhaps the xtal has incorrect specs, or your pcb layout is way incorrect.
Anyway, something is wrong because you must be able to get 115200 baud working to your USB chip.
For GoggleEarth logging, I use this Object on a Proto board all the time with a 2GB uSD card, and have logged a 6,000 mile round trip with using less than 1MB of KML data.
There is another logger with some enhancements in the OBEX:
http://obex.parallax.com/objects/661/
Regards,
Jim
This is what I ordered and paid for:
32812: Propeller Proto Board USB : 1
Also carries a label stating its the Parallax Proto Board...
Is there any way to check xtal speed? Can it be reset?
How bad is this? Does it really need to be replaced??? I seems to work ok (with these baudrates).
Did I burn it somehow? I'm not sure if I can replace it myself :-( At least it doesn't seem to be an expensive item.
Thanks Jim for your suggestion. I tried to understand it (still difficult) and if I'm not mistaken only Longitude and Latitude are logged, where I'm interested in winddata.
Is this the check for the A in the GPGGA string in the PUB GElog | idx, DD, d8, decDD? sdfat.popen(@fname, "a")
Followed with the
I'm not sure I quite understand this part; I need to write/rewrite quite a bit here I'm afraid?!
Eric
1.) Sounds like a standard Parallax Proto Board, 5Mhz. Are you running it off a standard PC via USB port or a Mac?
2.) It does not look like Goggle Earth KML supports WindData as exported with $II data. That should not be too hard to parse out to a video output, (TV or VGA), or to the SD card for that matter. It just would not plot on Goggle Earth.
Regards,
Jim
Meanwhile, to prove this, try changing you code where it says _XINFREQ = 5_000_000 to _XINFREQ = 5_235_000 and set your baud rates to 4800 and 115200 and the xtal to the value it is outputting.
while the Tacktick side s unknown, for sure the serial comm PC side must be well defined. If the baud rate does not fit there is a problem.
Besides a Xtal issue it could be a typo in the program where the frequency is set.
Just to be sure try to export the program and post it.
Under the propeller tool - file there is an option to export the whole project as a zip.
Massimo
Tried to find the _XINFREQ in my project; no match! Could that be the issue??
Attached my project (I hope; first time for everything...)
Eric
Hi Eric,
You would add these two lines to your CON section
CON _clkmode = xtal1 + pll16x 'Standard clock mode * crystal frequency = 80 MHz _xinfreq = 5_000_000Then change your baud to 115200 and your NEMA baud to 4800.
That should do it.
Jim
Thanks for that. You almost had me worried that my board was already broken....
Time to move on!
I was thinking to use the PUB readNEMA from the GPS_IO_mini.spin in the GPS_to_VGA project to extract the desired NMEA data.
Seems a good idea???
Thanks for your input (again ;-))
Eric
Consider GPS_to_VGA can be adapted to be used with PC terminal with little changes. In place of the VGA object use the serial terminal. Many methods are the same or very similar, so for the first tests you could try to adapt it.
I had problems in the past with this object because the stack space is very tight, so the object as it is works, while if you modify it you can have strange issues. Just to be safe increase the stack space before changing the code.
The "A" on the GPGGA means the GPS position is valid, so you log only in this case.
For SD logging you need a SD adapter. There are a lot of options around and all are ok.
The SD objects are quite forgiving, for instance I have a veroboard adapter with no pull ups working happily with fsrw.
There are even examples on the web of microSD adapters used as sockets and soldered directly....
the line you mentioned
sdfat.popen(@fname, "a")
opens the file with the name string pointed by @fname.
the "a" means the file is opened in append mode (the new data is added at the end of the file).
Massimo
Not very elegant but it should work and get you started:
You have to configure the serial comm with the NMEA/GPS unit in the GPS_IO_mini object.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ pst : "Parallax Serial Terminal" gps : "GPS_IO_mini" var long i pub main | gmt gps.start pst.Start(57600) i:=0 repeat pst.Str(String("Conto: ")) pst.dec(i++) pst.str(String(13)) pst.str((string("Valid "))) pst.str(gps.valid) pst.str(String(13)) pst.str((string("Latitude "))) pst.str(gps.latitude) pst.str(String(13)) pst.str((string("Longitude "))) pst.str(gps.longitude) pst.str(String(13)) pst.str((string("GPS Altitude "))) pst.str(gps.GPSaltitude) pst.str(String(13)) pst.str((string("Speed "))) pst.str(gps.speed) pst.str(String(13)) pst.str((string("Satellites "))) pst.str(gps.satellites) pst.str(String(13)) pst.str((string("Time GMT "))) pst.str(gps.time) pst.str(String(13)) pst.str((string("Date "))) pst.str(gps.date) pst.str(String(13)) pst.str((string("Heading "))) pst.str(gps.heading) pst.str((string(" "))) pst.str(gps.N_S) pst.str(gps.e_w) pst.str(String(13)) waitcnt(clkfreq + cnt)It took me quite some time to figure out how to use your code, but in the end it was too easy.......
Now it works, and worked out h
please post the modified code, it will simplify bug hunting, and for sure increase the stack space. There are objects to calculate required stack space too, but for sure GPS_IO_mini is very tight, so first thing is allow a much bigger (3-4 times) stack space.
Massimo
I did not have time to change the stack space (yet)
Thanks for having a look.
Eric
In the past I had problems with only 10 as stack space. For a start try to use 30 or 50 in GPS_IO_mini in place of
long gps_stack[10]
With so little stack space it was impossible to get time from RMC strings, and I spent quite a lot of time to figure it. Even if the problem is elsewhere we are sure stack space is not a problem.
Massimo
looking at the log I noticed that all RMC data are stable, GLL (time) and VWR are not. So I changed to the timestamp from the RMC sentence, which seemed to give stable timestamps (>500 measurements)
When only logging VWR, I thought stability was good after adjusting the variable resistor, but logging the mix again later still showed instability.
Sometimes i get the feeling the changes are (also) induced by me touching equipment (windmeter or PC-terminal), but it also changes when untouched. Probably coincidence...
Why would the VWR sentence bemore difficult??? data from the Tacktick are not reliable??
RMC is te first of the set to be sent out I think:
$IIRMC,213534,A,5217.975,N,00515.925,E,00.0,048,190112,00,E,A*0D
$IIVWR,032,R,00.0,N,,,,*60
$IIGLL,5217.975,N,00515.925,E,213534,A,A*57
$IIMWV,032,R,00.0,N,A*12
$IIMWV,032,T,00.1,N,A*15
I think I will try MWV-sentence next time
Eric
The one you are using is only 16 bytes.
There are drop in versions with bigger buffer, or different objects.
I'll try to find them and post a link.
Massimo
http://forums.parallax.com/showthread.php?111503-Anyone-worked-with-the-FullDuplexSerial-4port-object-rx-question#7
It is a drop in of full duplex serial mini. Rename the object in GPS_io_mini, and check if anything changes.
Massimo
I'm afraid your solution doesn't work :-(
First of all, it was the FDS to be replaced by the FullDuplexSerial_128ByteBuffers (pretty obvious if you look at the name, so I figured that one out quite quickly..)
I got it to work (GPS-stack at 50), but still the VWR-sentence goes wrong every now and than.
I also checked with a version written to read only VWR-blocks, but that didn;t work either (of course) Somehow it sees the IIVWR as block "0" sometimes.
edit
Suddenly I realised I was putting all sentences in buffer, which is not necessary. I only need RMC and VWR. Adapted the project, and the (original) GPS_IO_mini and all problems seem solved!
Over 600 lines logged without problem
GPS=stack at 50.
I think it's time to start looking at saving data :-)
Suggestions for an object to use??
Thanks,
Eric
Well done, Eric.
For SD card logging you can either use FSRW or FAT16/32 full system driver.
I'm using fsrw, simply because I'm already used to it, but both are first quality objects.
fsrw: http://obex.parallax.com/objects/92/
fat16/32 sull system driver: http://obex.parallax.com/objects/619/
Kye made an appnote about his object, and a more general discussion about SD here:
http://www.parallaxsemiconductor.com/appnotes
check appnote 6.
with fsrw you can first of all mount the SD:
fsrw.mount_explicit(0,1,2,3)
then you can open and append to an existing file doing something similar:
fsrw.popen(string("log.txt"), "a") ' opens File in Append fsrw.sdstr(gps.date) fsrw.sdstr(string(",")) fsrw.sdstr(gps.time) fsrw.sdstr(string(",")) fsrw.sdstr(gps.latitude) fsrw.sdstr(string(" ")) fsrw.sdstr(gps.N_S) fsrw.sdstr(string(",")) fsrw.sdstr(gps.longitude) fsrw.sdstr(string(" ")) fsrw.sdstr(gps.E_W) fsrw.sdstr(string(",")) fsrw.sdstr(gps.speed) fsrw.sdstr(string(",")) fsrw.sdstr(gps.heading) fsrw.sdstr(string(" ",13,10)) ' new line fsrw.pclose ' close the file"a" in the popen creates a new file, or if the file already exists it adds at the end (append) the new data.
mind coordinates straight from GPS are not compatible with google earth format, so if you want to see your path on the google earth you must modify them in the propeller (check the objects), of in the PC after having loaded them.
Massimo
Thanks for your advice again.
Today I read a tutorial about SDcards, and learnt about how they work (http://gadgetgangster.com/tutorials/331). Only how to add them to my project...
Now I see :-)
Only thind: when I wanted to order a microSD Card Adapter (#32312) form my Dutch supplier it is mentioned that the cards cannot be read by a PC $:-(
Is that due to the size, or is the format different. I already have a microcard-USB adapter for my phone, that should work don't you think?
Something else I was thinking: I still have an old, broken, sony camera with Sony memory sticks. Would that work (if I can de-mount the adapter from the camera)??? Or do they use different formatting?
First have to get the cards organised now..
Looking at your code, this will only make a one-rule file?
So it needs the "repeat" loop, but how do you stop it then, so I can remove the card?
The google earth format is not important to me, as my Garmin gps will make a lat/lon-log that I can review later (mapsource, or google earth, or any other gps software) Stricktly speaking I probably don't need the lat/lon in my sd-log, but that's the link to the gps-track if I notice something strange.
This is what I put together on first thought:
pub main | gmt
waitcnt(clkfreq*5 + cnt) 'delay (5 secs) to get terminal program running (if required)
gps.start
pst.Start(115200) 'EH: 57600 => 115200
i:=0
mount := \fsrw.mount_explicit(DO, CLK, DI, CS) 'mount card
if mount < 0
pst.str(string(13, "Failed to mount",13)) 'report and halt when failed
abort
pst.str(string(13, "SD-card was found and mounted fine." 13)) 'report correct mounting
fsrw.popen(string("log(gps.date).txt"), "a") ' opens File in Append
fsrw.sdstr(String("Conto,Valid,TimeGMT,Lat,Lon,Speed,Heading,AWA,L/R,AWS"))
repeat
fsrw.dec(i++)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.valid)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.time)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.latitude)
fsrw.sdstr(string(" "))
fsrw.sdstr(gps.N_S)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.longitude)
fsrw.sdstr(string(" "))
fsrw.sdstr(gps.E_W)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.speed)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.heading)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.AWA)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.LR)
fsrw.sdstr(string(","))
fsrw.sdstr(gps.AWS)
fsrw.sdstr(string(" ",13,10)) ' new line
waitcnt(clkfreq + cnt)
fsrw.pclose ' close the file
sdfat.unmount 'unmount the card at end program
Eric
I'll try to answer your questions, but take my fsrw handling with a grain of salt, I'm not a competent user at all.
The microSD adapter is perfect for your tasks.
The SD card is readable from the PC for sure. The microSD is very tiny, but they are usually sold with a SD adapter, so they fit in any SD card reader.
SD family is the only you can use. CF, XD, memory stick and so on are not compatible with the objects available.
You are right, the code was in a PUB, called in a continuous loop.
I do not unmount the card. FAT16/32 full system driver marks the partition as "dirty" if not correctly unmounted, but fsrw is less picky, so I simply close the file after every write, and at the end of the day I simply switch off the prop and never had issues. To correctly handle the file closing you could add a button that stops everything on demand...
A couple of considerations:
- close the file after the write, not after the waitcnt.
- If the pc is not connected do not use the pst object, there are reset issues. Either comment out the pst parts or use OBC dummy object (you simply change the object name when not debugging with the PC).
check here: http://forums.parallax.com/showthread.php?122321-PST-with-USB-cable-unplugged
- gps.date sends valid values after some minutes of functioning, so either let the instruments run for some time before switching on the prop logger or wait for a "valid" GPS signal before stating logging
as you can see there are code formatting issues, you must enclose the code between the tags:
[ code] and [/ code] -> Just remove the spaces...
there also is a preview post to verify everything is correctly formatted.
Indent is fundamental in spin....
Massimo
Trying to compile the code (and your code as well) I run into unknown subroutine fsrw.sdstr...
My (freshly downloaded) version of fsrw does not contain a PUB calles sdstr! Did you change names,or add a new PUB?
Thanks,
Eric
Pub SDStr(ptr) {{ ' Addition by John Twomey AKA: QuattroRS4 ' Routine added to write a string ' Use as follows in Program - ' sdfat.sdstr(string("this string will be written to SDcard")) ' ' can also do - ' sdfat.sdstr(string("this string will be written to SDcard",13,10)) ' the above adds CR & LF (Carriage Return and Line Feed) }} repeat while byte[ptr] pputc(byte[ptr++])No more error messages :-)
But.....
My sd-card doesn't seem to mount :-(
Checked connections, they seem good; but still get: "Failed to mount"
In the manual for the card I see pin 0 and 4 set "out", and pin 1-3 as "in". Do I need to set this somewhere, or is it already in the code??
Eric
pub demo | mount, data waitcnt(clkfreq*5 + cnt) 'delay (5 secs) to get terminal program running (if required) gps.start pst.Start(115200) 'EH: 57600 => 115200 i:=0 pst.str(string("Just a start message",13)) mount := \fsrw.mount_explicit(D0, CLK, DI, CS) 'mount card if mount < 0 pst.str(string(13, "Failed to mount",13)) 'report and halt when failed else pst.str(string(13, "SD-card was found and mounted fine.", 13)) pst.str(string("2nd message",13)) fsrw.popen(string("log.txt"), "a") ' opens File in Append fsrw.sdstr(String("Conto,Valid,TimeGMT,Lat,Lon,Speed,Heading,AWA,L/R,AWS"))Check the connections, the pin numbers and the supply are correct.
If you download fsrw there is a demo testing SD speed, that works for sure. check the documentation for configuring the pin numbers and the spi driver.
If this is not working there probably is an hardware issue.
side note:
pin direction is a delicate issue and at the begin can lead to strange behaviors. Check the manual on how this is handled.
This helps: i made my first log-file today! 100 lines in log.txt :-)
On my sd-card was a file "NMEA", saved by "GPS_SD_Card_TV_Demo_V2.spin" I was playing with. So the problem was software. I found that the GPS_IO_mini was programmed using pin0 for serXmit, causing the sd-card not to work.....
It still took me all day to get the log-file working, but they were minor spelling errors in code.
Thank God it's Sunday!
Now I have some cleaning up to do of the code; remove all trial an error's and comments
The test file in the fsrw was unclear to me, I couldn't get it to work. It needs a file sysdep.spin I couldn't find... :-(
Next I will try a longer log, but I'm running out or daytime.
Eric
I just can't get this worked out: when I don't add a count in the repeat loop for logging data it won't work!??
I included a LED-flash in the loop, and it flashes nicely, indicating the loop runs. A new file is created on the flashdrive, but it's empty; data is not added!!??
Why would "repeat 10" have an effect on "fsrw.sdstr(String("Date,TimeGMT,Lat,Lon,Speed,Heading,AWA,L/R,AWS"))"
OBJ gps : "GPS_IO_mini" fsrw : "fsrw" LED : "LED" var long i pub demo | mount, data gps.start 'txpin changed 0=>10 ok 'i:=0 mount := \fsrw.mount_explicit(D0, CLK, DI, CS) LED.Toggle(5, 50_000_000, 2) 'Toggle(Pin, Delay, Count) fsrw.popen(string("log.txt"), "a") ' opens File in Append fsrw.sdstr(String("Date,TimeGMT,Lat,Lon,Speed,Heading,AWA,L/R,AWS")) fsrw.sdstr(string(" ",13,10)) ' new line waitcnt(clkfreq*5 + cnt) repeat 10 '"repeat 10" works :-) fsrw.sdstr(gps.date) 'but not whithout #?? fsrw.sdstr(string(",")) 'LED flashing indicates proper loop fsrw.sdstr(gps.time) ' fsrw.sdstr(string(",")) fsrw.sdstr(gps.latitude) fsrw.sdstr(string(",")) fsrw.sdstr(gps.longitude) fsrw.sdstr(string(" ")) fsrw.sdstr(gps.E_W) fsrw.sdstr(string(",")) fsrw.sdstr(gps.speed) fsrw.sdstr(string(",")) fsrw.sdstr(gps.heading) fsrw.sdstr(string(",")) fsrw.sdstr(gps.AWA) fsrw.sdstr(string(",")) fsrw.sdstr(gps.LR) fsrw.sdstr(string(",")) fsrw.sdstr(gps.AWS) ' fsrw.sdstr(string(" ",13,10)) LED.Toggle(5, 500_000, 4) 'Toggle(Pin, Delay, Count)LED flash => runs loop waitcnt(clkfreq*2 + cnt) '11 2 lines have identical timecode ' fsrw.pclose ' close the file fsrw.unmount 'unmount the card at end programIf you do not close the file the content is probably not updated.
OBJ gps : "GPS_IO_mini" fsrw : "fsrw" LED : "LED" var long i pub demo | mount, data gps.start 'txpin changed 0=>10 ok 'i:=0 mount := \fsrw.mount_explicit(D0, CLK, DI, CS) LED.Toggle(5, 50_000_000, 2) 'Toggle(Pin, Delay, Count) fsrw.popen(string("log.txt"), "a") ' opens File in Append fsrw.sdstr(String("Date,TimeGMT,Lat,Lon,Speed,Heading,AWA,L/R,AWS")) fsrw.sdstr(string(" ",13,10)) ' new line '******************************* fsrw.pclose ' close the file waitcnt(clkfreq*5 + cnt) repeat '"repeat 10" works :-) fsrw.popen(string("log.txt"), "a") ' ********************************** opens File in Append fsrw.sdstr(gps.date) 'but not whithout #?? fsrw.sdstr(string(",")) 'LED flashing indicates proper loop fsrw.sdstr(gps.time) ' fsrw.sdstr(string(",")) fsrw.sdstr(gps.latitude) fsrw.sdstr(string(",")) fsrw.sdstr(gps.longitude) fsrw.sdstr(string(" ")) fsrw.sdstr(gps.E_W) fsrw.sdstr(string(",")) fsrw.sdstr(gps.speed) fsrw.sdstr(string(",")) fsrw.sdstr(gps.heading) fsrw.sdstr(string(",")) fsrw.sdstr(gps.AWA) fsrw.sdstr(string(",")) fsrw.sdstr(gps.LR) fsrw.sdstr(string(",")) fsrw.sdstr(gps.AWS) ' fsrw.sdstr(string(" ",13,10)) fsrw.pclose ' close the file ******************************* LED.Toggle(5, 500_000, 4) 'Toggle(Pin, Delay, Count)LED flash => runs loop waitcnt(clkfreq*2 + cnt) '11 2 lines have identical timecode ' ' fsrw.pclose ' close the file +++++ you don't need this ' fsrw.unmount 'unmount the card at end program ++++ you'll never get there...Is that experience, or can you explain why this is different from the repeat loop we set up for the Parallax Serial Terminal to parse data to pc, to check data flow?
It does seem a bit over the top to open and close the file every line :-$
Thanks anyway ;-)
The LED added is also comforting. I can see when it's active, now. I probably take it out later to reduce power consumption.
Eric
What a mess you can end up with, cleaning up.....