Great!
I think the problem is related to the way the file system is handled.
I'm not an expert so take it accondigly...
My guess is you are writing to the SD card, but the index of the file is not updated, so Windows thinks it is empty.
Maybe pflush is better... is simply updates the FAT without the need of closing it.
As spring is aproaching, I'm building the Propeller into a box, but I haven't solved the power connection to the boat battery yet.
What would be the smartest method you think to reduce 12V to 6-9V for the Propeller?
I'm still struggling with instable data flow; could it be that too much data is stored (everything following a $ is stored; 6 sentences from which I only need 2) or data flow is too fast??
Without clear reason logged data changes like
255, A, 210838, 5217.979, 00515.921, 00.0, 164, IIVWR, R
256, A, 210838, 5217.979, 00515.921, 00.0, 164, IIVWR, R
257, A, 210840, 5217.981, 00515.920, 00.0, 164, 037, 00.0
258, A, 210840, 5217.981, 00515.920, 00.0, 164, 037, 00.0
259, A, 210840, 5217.981, 00515.920, 00.0, 164, 037, 00.0
260, A, 210840, 5217.981, 00515.920, 00.0, 164, IIVWR, R
261, A, 210844, 5217.982, 00515.919, 00.0, 164, IIVWR, R
Sentences coming in:
$IIRMC,110857,A,5217.977,N,00515.917,E,00.0,284,150112,00,E,A*08
$IIVWR,079,R,00.0,N,,,,*6F
$IIGLL,5217.977,N,00515.917,E,110857,A,A*5C
$IIMWV,079,R,03.6,N,A*18
$IIMWV,079,T,04.2,N,A*1D
As soon as I log data from the VWR-sentence I run into trouble. Logging VWR alone, everthing is ok, so it's not the data itself, or the stream not being consistent...
Is it important to log in the same order as data comes in??
Massimo, thanks for your input again.
attached my project for your evaluation.
I tried increasing the gps_stack even up to 1000 without success, and played with the size for the bytes and longs without effect...
I added the 3rd and 4th datablock of the VWR-sentence to the log, so when shifted, the data is logged anyway. It's only more work cleaning up in Excel afterwards :-(
$IIVWR,088,R,02.5,N,,,,*66
' 0 1 2 3 4
Only logging the VWR gives faultless logs.
I'm not sure I understand the other serial object, or its advantage for me.
GPS_IO_mini again! It has a tendency to corrupt its own memory with short GPS sequences. As it - in this case - processes more bytes then the incoming message which in turn may create more than the reserved 20 pointers. As a quick fix could you try changing the repeat j from 0 to 78 in copy_buffer to repeat j from 0 to cptr -1 and see if that makes a difference?
Eric,
if kuroneko's solution is not working I would try with another serial object.
The one I posted above is very good, and you can custom set the buffer for each port, both rx and tx.
The full duplex serial you are using has only 16 bytes as a buffer, and it could be a problem.
I'll try to modify your object to adapt it to the other serial object.
Thanks guys!
At the moment I first have to solve my power supply, the connection to the 12V board battery I ordered components to cut down to 9V, they're supposed to come in tomorrow....
Then I will try your suggestions.
The other serial object, do the ports need to be custom set? Or do they already have a "standard" setup?
I looked at it (briefly) but I need more time to dig into it.
Please find attached this modified version.
I simply switched to a 4ports version. Not the latest, but I'm using this one with success, so I guess it is a nice starting point.
As you can see this version is very similar to the one you are using, but you can have up to 4 ports running at the same time, and set arbitrary buffer size.
Let us know.
Massimo
As a quick fix could you try changing the repeat j from 0 to 78 in copy_buffer to repeat j from 0 to cptr -1 and see if that makes a difference?
You hit the nail on the head Kuroneko!
The components arrived, and I was able to put it all together yesterday, so I logged overnight and it didn't fail once!
I'm not sure how much cptr-1 is different from 78, but for now I'm happy as I need to mount the anemometer to my mast and erect it tomorrow. Next time I will have to do the loggin on my boat :-)
Spring is in the air!
Can anybody help me get started with decimal calculations in Spin?
After extensive data-logging and analysing using Excel, I run into Excels limitations. Changing to Access did not help so far...
Time for the next step in this project: I would like the Propeller to do some of the calculations to lighten tasks for Excel....
But this is a poblem: I just can't figure out how to make decimal calculations in Spin :-(
I've managed to do simple calculations following the tutorial, but how to work with decimals?? I have looked at several projects in the OBEX, but they are way beyond my reach....
The first calculation I would like to make is the VMG (Velocity Made Good = boatspeed in the direction of the wind) normally calculated from BoatSpeed (BS and TrueWindAngle (TWA):
VMG=BS * cos(TWA)
Boatspeed and TWA are presented by the GPS and Tacktick Unit in NMEA sentences which are captured by "GPS_IO_mini echo all buff" and logged in a file on SD-card (see below)
Boatspeed and Windspeed are logged in decimals...
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
' Prop Chip Hookup:
D0 = 0 ' Connect to Pin 0 ' I've set these pins to match the SD card holder connections
CLK = 1 ' Connect to Pin 1 ' These are the correct pin numbers for my SD Card holder
DI = 2 ' Connect to Pin 2 ' In addition, connect the first pin (VDD) to +3.3 Volts, and
CS = 3 ' Connect to Pin 3 ' connect the second pin (VSS) to ground.
' My card holder has 6 pins (the 4 data lines, and 2 power lines.)
' I got it from uController.com and it works very well.
[COLOR="#FF8C00"]CON
cnv = PI/180.0[/COLOR]
OBJ
gps : "GPS_IO_mini echo all buff" 'solution by Kuroneko: to solve the "shift-problem"
fsrw : "fsrw"
LED : "LED"
[COLOR="#FF8C00"] fs : "FloatString"
f : "Float32"
[/COLOR]
pub demo | mount, data, [COLOR="#FF8C00"]bs, twa, vmg[/COLOR]
gps.start 'txpin changed 0=>10 ok
[COLOR="#FF0000"] f.start
[/COLOR]
mount := \fsrw.mount_explicit(D0, CLK, DI, CS)
LED.Toggle(5, 50_000_000, 2) 'Toggle(Pin, Delay, Count) Start-up LED-signal
fsrw.popen(string("log.txt"), "a") ' opens File in Append
fsrw.sdstr(string("project11"))
fsrw.sdstr(string(13,10))
fsrw.sdstr(String("Date,TimeGMT,BoatSpeed,Heading,L/R,AWS,AWA,TWA,T/R,TWS")) 'Table header
fsrw.sdstr(string(" ",13,10)) 'string(" ",13,10) new line
fsrw.pclose ' close the file
waitcnt(clkfreq*5 + cnt)
repeat '
fsrw.popen(string("log.txt"), "a") 'opens File in Append
fsrw.sdstr(gps.RMC8date) 'date
fsrw.sdstr(string(","))
fsrw.sdstr(gps.RMC0time) 'time '
fsrw.sdstr(string(","))
fsrw.sdstr(gps.RMC6bs) 'boat speed bs, AWS, AWA for calculationss in Excel
fsrw.sdstr(string(","))
fsrw.sdstr(gps.RMC7heading) 'boat heading
fsrw.sdstr(string(","))
fsrw.sdstr(gps.VWR1LR) 'wind left right
fsrw.sdstr(string(","))
fsrw.sdstr(gps.VWR2AWS) 'apparent wind speed
fsrw.sdstr(string(","))
fsrw.sdstr(gps.VWR0AWA) 'apparent wind angle
fsrw.sdstr(string(","))
fsrw.sdstr(gps.MWV0TWA) 'true wind angle
fsrw.sdstr(string(","))
fsrw.sdstr(gps.MWV1TR) 'true or relative
fsrw.sdstr(string(","))
fsrw.sdstr(gps.MWV2TWS) 'true wind speed
fsrw.sdstr(string(" ",13,10)) 'string(" ",13,10)carriage return, line feed (why both?)
[COLOR="#FF8C00"] bs := fs.StringToFloat(gps.RMC6bs)
twa := fs.StringToFloat(gps.MWV0TWA)
vmg := f.FMul(bs, f.Cos(f.FMul(twa, cnv))) ' deg to rad
fsrw.sdstr(fs.FloatToString(vmg)) ' write VMG to file (as string)
[/COLOR]
fsrw.pclose 'close the file
LED.Toggle(5, 500_00, 4) 'Toggle(Pin, Delay, Count) LED flash => runs loop
waitcnt(clkfreq*2 + cnt)
This requires FloatString 1.2 (OBEX). It basically takes both strings for BS and TWA and converts them to floating point numbers. The resulting number is converted back to a string and written as such to the file. HTH
Nice and short coding as far as I can judge (but you know I'm a novice)
I've programmed the Propeller and it seems to run (after considerable issues that I could solve, like downloading the wrong FloatString)
I can't check the output yet, as it doesn't get any input on my desk
Will try on my boat on Tuesday, and let you know.
Hi!
Please read my post considering Kuroneko is a coding Guru, while I cannot even considered a programmer.. :-)
Anyway you can do that also using integers.
You can scale angle and speed to consedr decimals.
Say you have an input data like 12.3. If you multiply by 10 you can have an integer like 123, and consider also the first decimal place. If you multiply by 100 you get the 2nd decima place and so on.
I tried to do everything using integers, using cartesian planar projection (or if you prefer for what we care Earth is flat).
VMG uses the cos tables in the ROM and the multiply high, in case you want to test and investigate some aspects of the Propeller.
Talking of concidences...
After a couple of years of saillessness (??) I talked to a friend 2-3 days ago, and he was looking for a Nmea to Wifi solution, to be used with a phone/tablet application called iregatta.
I don't know if the app has the features you request, but a wifly module and a R485 to serial converter are probably enough.. I did a rapid test with an RS485 anemometer in the office and my friend connected over the internet and was able to read the data.
After all today's phones are extremely powerful.
Probably the drawback are you don't have the satisfaction of creating your own tool, direct sunlight visibility is still a problem and battery life is marginal, but the results look interesting.. I'll test it in the next weeks, and I'll report back in case you are interested.
Massimo
@SailingEric: Minor update, you'll need to add an f.start somewhere at the beginning of the method (e.g. after gps.start). For your example of BS=3.8 and TWA=314 this gives me VMG=2.639723.
@ Kuroneko: the F.start I finally figured out myself :-) VMG's came out wrong, now I found a typo in the formula :-(
next time, next try...
@Max72: you're right, modern phones and tablets have great options, but next to clarity of screen and power, water splash doesn't make them happy...
Do you prefer the Trig Functions.spin over Float32.spin?
Yesterdays log was problematic: lost power many times. I have to look for a poor contact somewhere :-(
And I thought I had just made a new and better housing....
I agree with you about splash too and anything related to tablets/phones.
Anyway I should be able to test a tabled app soon. I'm curious to seehow it works....
I tried to do everything using integers only, and the trig object is simply the result of my experiments. XTE needs fixing by the way... I converted everything to integers, and used a flat earth appoximation.
Float needs attention too. For instance float rounds too heavily GPS coordinates so you still need some care when handling them.
I used spin only, so it requires a cog less. Spin is much slower than assembly, so I'm confident using floats will speed up things. There is much more code to be executed when handling floats, but assembly is blazing fast.
When things are working intermittently it's very difficult to find the issue. If you switched housing the first guesses are a bended board due to the tightening, or an open contact/short with some wire coming from outside, possibly power.
Comments
I think the problem is related to the way the file system is handled.
I'm not an expert so take it accondigly...
My guess is you are writing to the SD card, but the index of the file is not updated, so Windows thinks it is empty.
Maybe pflush is better... is simply updates the FAT without the need of closing it.
Massimo
As spring is aproaching, I'm building the Propeller into a box, but I haven't solved the power connection to the boat battery yet.
What would be the smartest method you think to reduce 12V to 6-9V for the Propeller?
I'm still struggling with instable data flow; could it be that too much data is stored (everything following a $ is stored; 6 sentences from which I only need 2) or data flow is too fast??
Without clear reason logged data changes like
255, A, 210838, 5217.979, 00515.921, 00.0, 164, IIVWR, R
256, A, 210838, 5217.979, 00515.921, 00.0, 164, IIVWR, R
257, A, 210840, 5217.981, 00515.920, 00.0, 164, 037, 00.0
258, A, 210840, 5217.981, 00515.920, 00.0, 164, 037, 00.0
259, A, 210840, 5217.981, 00515.920, 00.0, 164, 037, 00.0
260, A, 210840, 5217.981, 00515.920, 00.0, 164, IIVWR, R
261, A, 210844, 5217.982, 00515.919, 00.0, 164, IIVWR, R
Sentences coming in:
$IIRMC,110857,A,5217.977,N,00515.917,E,00.0,284,150112,00,E,A*08
$IIVWR,079,R,00.0,N,,,,*6F
$IIGLL,5217.977,N,00515.917,E,110857,A,A*5C
$IIMWV,079,R,03.6,N,A*18
$IIMWV,079,T,04.2,N,A*1D
As soon as I log data from the VWR-sentence I run into trouble. Logging VWR alone, everthing is ok, so it's not the data itself, or the stream not being consistent...
Is it important to log in the same order as data comes in??
Eric
What serial object do you use?
Try the modified 4 ports:
http://forums.parallax.com/showthread.php?137349-yet-another-variant-fullDuplexSerial4portplus
You can set duffer dimensions...
Do you write directly? Can you group data on an intermediate buffer?
Could you post the code?
Massimo
attached my project for your evaluation.
I tried increasing the gps_stack even up to 1000 without success, and played with the size for the bytes and longs without effect...
I added the 3rd and 4th datablock of the VWR-sentence to the log, so when shifted, the data is logged anyway. It's only more work cleaning up in Excel afterwards :-(
$IIVWR,088,R,02.5,N,,,,*66
' 0 1 2 3 4
Only logging the VWR gives faultless logs.
I'm not sure I understand the other serial object, or its advantage for me.
Happy Easter,
Eric
if kuroneko's solution is not working I would try with another serial object.
The one I posted above is very good, and you can custom set the buffer for each port, both rx and tx.
The full duplex serial you are using has only 16 bytes as a buffer, and it could be a problem.
I'll try to modify your object to adapt it to the other serial object.
Massimo
At the moment I first have to solve my power supply, the connection to the 12V board battery I ordered components to cut down to 9V, they're supposed to come in tomorrow....
Then I will try your suggestions.
The other serial object, do the ports need to be custom set? Or do they already have a "standard" setup?
I looked at it (briefly) but I need more time to dig into it.
Eric
I simply switched to a 4ports version. Not the latest, but I'm using this one with success, so I guess it is a nice starting point.
As you can see this version is very similar to the one you are using, but you can have up to 4 ports running at the same time, and set arbitrary buffer size.
Let us know.
Massimo
You hit the nail on the head Kuroneko!
The components arrived, and I was able to put it all together yesterday, so I logged overnight and it didn't fail once!
I'm not sure how much cptr-1 is different from 78, but for now I'm happy as I need to mount the anemometer to my mast and erect it tomorrow. Next time I will have to do the loggin on my boat :-)
Spring is in the air!
Eric
After extensive data-logging and analysing using Excel, I run into Excels limitations. Changing to Access did not help so far...
Time for the next step in this project: I would like the Propeller to do some of the calculations to lighten tasks for Excel....
But this is a poblem: I just can't figure out how to make decimal calculations in Spin :-(
I've managed to do simple calculations following the tutorial, but how to work with decimals?? I have looked at several projects in the OBEX, but they are way beyond my reach....
The first calculation I would like to make is the VMG (Velocity Made Good = boatspeed in the direction of the wind) normally calculated from BoatSpeed (BS and TrueWindAngle (TWA):
VMG=BS * cos(TWA)
Boatspeed and TWA are presented by the GPS and Tacktick Unit in NMEA sentences which are captured by "GPS_IO_mini echo all buff" and logged in a file on SD-card (see below)
Boatspeed and Windspeed are logged in decimals...
Date,TimeGMT,BoatSpeed,Heading,L/R,AWS,AWA,TWA,T/R,TWS
290713,180357,04.0,315,L,17.3,038,312,T,13.9
290713,180359,03.8,310,L,16.7,038,314,T,14.1
290713,180401,03.4,307,L,16.8,039,312,T,14.0
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 ' Prop Chip Hookup: D0 = 0 ' Connect to Pin 0 ' I've set these pins to match the SD card holder connections CLK = 1 ' Connect to Pin 1 ' These are the correct pin numbers for my SD Card holder DI = 2 ' Connect to Pin 2 ' In addition, connect the first pin (VDD) to +3.3 Volts, and CS = 3 ' Connect to Pin 3 ' connect the second pin (VSS) to ground. ' My card holder has 6 pins (the 4 data lines, and 2 power lines.) ' I got it from uController.com and it works very well. [COLOR="#FF8C00"]CON cnv = PI/180.0[/COLOR] OBJ gps : "GPS_IO_mini echo all buff" 'solution by Kuroneko: to solve the "shift-problem" fsrw : "fsrw" LED : "LED" [COLOR="#FF8C00"] fs : "FloatString" f : "Float32" [/COLOR] pub demo | mount, data, [COLOR="#FF8C00"]bs, twa, vmg[/COLOR] gps.start 'txpin changed 0=>10 ok [COLOR="#FF0000"] f.start [/COLOR] mount := \fsrw.mount_explicit(D0, CLK, DI, CS) LED.Toggle(5, 50_000_000, 2) 'Toggle(Pin, Delay, Count) Start-up LED-signal fsrw.popen(string("log.txt"), "a") ' opens File in Append fsrw.sdstr(string("project11")) fsrw.sdstr(string(13,10)) fsrw.sdstr(String("Date,TimeGMT,BoatSpeed,Heading,L/R,AWS,AWA,TWA,T/R,TWS")) 'Table header fsrw.sdstr(string(" ",13,10)) 'string(" ",13,10) new line fsrw.pclose ' close the file waitcnt(clkfreq*5 + cnt) repeat ' fsrw.popen(string("log.txt"), "a") 'opens File in Append fsrw.sdstr(gps.RMC8date) 'date fsrw.sdstr(string(",")) fsrw.sdstr(gps.RMC0time) 'time ' fsrw.sdstr(string(",")) fsrw.sdstr(gps.RMC6bs) 'boat speed bs, AWS, AWA for calculationss in Excel fsrw.sdstr(string(",")) fsrw.sdstr(gps.RMC7heading) 'boat heading fsrw.sdstr(string(",")) fsrw.sdstr(gps.VWR1LR) 'wind left right fsrw.sdstr(string(",")) fsrw.sdstr(gps.VWR2AWS) 'apparent wind speed fsrw.sdstr(string(",")) fsrw.sdstr(gps.VWR0AWA) 'apparent wind angle fsrw.sdstr(string(",")) fsrw.sdstr(gps.MWV0TWA) 'true wind angle fsrw.sdstr(string(",")) fsrw.sdstr(gps.MWV1TR) 'true or relative fsrw.sdstr(string(",")) fsrw.sdstr(gps.MWV2TWS) 'true wind speed fsrw.sdstr(string(" ",13,10)) 'string(" ",13,10)carriage return, line feed (why both?) [COLOR="#FF8C00"] bs := fs.StringToFloat(gps.RMC6bs) twa := fs.StringToFloat(gps.MWV0TWA) vmg := f.FMul(bs, f.Cos(f.FMul(twa, cnv))) ' deg to rad fsrw.sdstr(fs.FloatToString(vmg)) ' write VMG to file (as string) [/COLOR] fsrw.pclose 'close the file LED.Toggle(5, 500_00, 4) 'Toggle(Pin, Delay, Count) LED flash => runs loop waitcnt(clkfreq*2 + cnt)This requires FloatString 1.2 (OBEX). It basically takes both strings for BS and TWA and converts them to floating point numbers. The resulting number is converted back to a string and written as such to the file. HTHNice and short coding as far as I can judge (but you know I'm a novice)
I've programmed the Propeller and it seems to run (after considerable issues that I could solve, like downloading the wrong FloatString)
I can't check the output yet, as it doesn't get any input on my desk
Will try on my boat on Tuesday, and let you know.
Thanks again for your help
Eric
Please read my post considering Kuroneko is a coding Guru, while I cannot even considered a programmer.. :-)
Anyway you can do that also using integers.
You can scale angle and speed to consedr decimals.
Say you have an input data like 12.3. If you multiply by 10 you can have an integer like 123, and consider also the first decimal place. If you multiply by 100 you get the 2nd decima place and so on.
I tried to do everything using integers, using cartesian planar projection (or if you prefer for what we care Earth is flat).
VMG uses the cos tables in the ROM and the multiply high, in case you want to test and investigate some aspects of the Propeller.
Talking of concidences...
After a couple of years of saillessness (??) I talked to a friend 2-3 days ago, and he was looking for a Nmea to Wifi solution, to be used with a phone/tablet application called iregatta.
I don't know if the app has the features you request, but a wifly module and a R485 to serial converter are probably enough.. I did a rapid test with an RS485 anemometer in the office and my friend connected over the internet and was able to read the data.
After all today's phones are extremely powerful.
Probably the drawback are you don't have the satisfaction of creating your own tool, direct sunlight visibility is still a problem and battery life is marginal, but the results look interesting.. I'll test it in the next weeks, and I'll report back in case you are interested.
Massimo
@ Kuroneko: the F.start I finally figured out myself :-) VMG's came out wrong, now I found a typo in the formula :-(
next time, next try...
@Max72: you're right, modern phones and tablets have great options, but next to clarity of screen and power, water splash doesn't make them happy...
Do you prefer the Trig Functions.spin over Float32.spin?
Yesterdays log was problematic: lost power many times. I have to look for a poor contact somewhere :-(
And I thought I had just made a new and better housing....
Eric
Anyway I should be able to test a tabled app soon. I'm curious to seehow it works....
I tried to do everything using integers only, and the trig object is simply the result of my experiments. XTE needs fixing by the way... I converted everything to integers, and used a flat earth appoximation.
Float needs attention too. For instance float rounds too heavily GPS coordinates so you still need some care when handling them.
I used spin only, so it requires a cog less. Spin is much slower than assembly, so I'm confident using floats will speed up things. There is much more code to be executed when handling floats, but assembly is blazing fast.
When things are working intermittently it's very difficult to find the issue. If you switched housing the first guesses are a bended board due to the tightening, or an open contact/short with some wire coming from outside, possibly power.
Good luck.