Data Logging help needed

[donrecardo]

Hi
My aim is to take a GPS receiver on my dinghy and once per second
over the course of two 80 minute races data log the.....

UTC
Lat
Lon
Speed

So that on returning home I can overlay the data on to a map to see where
I could have been a little quicker.

I had the GPS receiver hooked to a picaxe 18X but ran out of byte variables
so changed to a 20X2. This now works just as I wanted using the following code

'Using a 20X2 chip because I need more than 14 byte variables
'Input B.7 is fed from the output of a GPS receiver which runs
'at 9600 baud

init:
	setfreq m8
	let dirsB = %01111111
main:

	serin b.7, t9600_8, ("$GPRMC"),b0,b1,b2,b3,b4,b5,b6,b0,b0,b0,b0,b0,b0,b0,b7,b8,b9,b10,b0,b11,b12,b13,b14,b0,b0,b0,b0,b0,b15,b16,b17,b0,b18,b19,b20,b21,b0,b0,b0,b22,b0,b23

	sertxd ("UTC  ",b1,b2,":",b3,b4,":",b5,b6,"     Lat.  ",b7,b8," : ",b9,b10,".",b11,b12,b13,b14,"     Lon.  ",b15," : ",b16,b17,".",b18,b19,b20,b21,"     ",b22,".",b23,"  Kn",cr,lf)

goto main

All the b0 variables are just to remove the unwanted stuff and the Sertxd line
is simply so that I could see what is happening whilst experimenting and can
now be removed .
So far so good , everything is working as expected ( well better than as
expected really because I didnt expect it to work )

I also own an AXE110 data logger and extender board , fully populated with
24LC512 chips . I ran a test using the supplied light and temp sensors and
was able to produce a graph in Excel with the logged data
So the plan is now to log the received GPS data into the logger but I haven't
a clue how to go about getting all that data into the logger in a nice orderly
fashion once every second . I looked at " new mission" in the program editors
data logger wizard but that only seems to deal with reading sensors.
Can someone please help me with the code that I will need ?

Lastly will I have enough space on the eight 24LC512 chips to hold the once
per second data from two (80 minute) races ?, Im not sure how to calculate
how much room it will need . I assume as there will be ( 80 * 60 ) +
(80 * 60 ) = 9600 readings with 23 bytes of data per reading thats a total of
220800 bytes, and I assume each data chip holds 512K bits = 64K bytes so 8
chips hold 512000 bytes which is more than twice that which I require .
I dont know if it uses up some memory for other things like like address
pointers and such ?

I was just previewing my post before submitting it when I realised I can
actually reduce the amount of data I need to save . The lake I sail on is
only 27 acres in size and because of where its situated my degrees Lat and
degrees Lon will never change , I will allways be 001 deg west and 52
degrees north , so b1,b2,b7 and b8 are not really needed. Only the minutes
and decimal minutes Lat and long would ever change

Don

 

[PerthEng]

Have a look at what westy did for modified AXE110 datalogger program code for another forum member.

Goes under the heading of adding time stamping to AXE110 code in the finished projects area

 

[donrecardo]

Thanks for that , I will go read it now

I hope it makes sense to me


Don

 

[westaust55]

You will need to replace the sensor input routine with your own SERIN command.

In the time stamping code PerthEng has mentioned, I also restructured how the data was saved. Lots of comments from the original datalogger wizard produced code and my mofifications to make understanding easy.
It will depend upon your final number of variables as to what will be the best way/structure to save the data into the AXE110 EEPROMS.

 

[InvaderZim]

You could use the GPS's "speed" data, or you could ignore it and re-calculate it using your position and time data. It could conceivably be more accurate either way, or neither way, but you would save memory, hassle, etc., by not dealing with speed.

 

[donrecardo]

Sorry for the delay in replying ,

I havent lost interest , I have been trying to get my head around it all , but
I am still failing.

I have tried to follow the example referred to about adding the time stamp
but I dont quite think that is relevent in my case as I wont be getting the
time from the RTC it will be the first 6 of my 23 variables that I obtain with
my serin command that will give me the time.

I am not sure I am on the right track but I was thinking , as my variables
are arranged as

b1 - b6 = time = 6 vars
b7 - b14 = longitude = 8 vars
b15 - b21 = latitude = 7 vars
b22 - b23 = speed = 2 vars

If I think each block as though they were 8 vars each and then write

the 6 time vars and 2 speed vars into address 0 of each of the 8 memory
chips
the 8 longitude vars into address 1 of each memory chip
the 7 latitude vars into address 2 of each memory chip ( leave last 1 empty)

Serin the data into the variables again and now put them into adresses
3, 4 and 5 of each chip then 6,7 and 8 etc

I am assuming this is the method I should be aiming for ? although I am
probably barking up the wrong tree, worse still although I think this is the
way to go I havent a clue how to do it , I dont really klnow how to code this

Don

 

[westaust55]

Don, what you describe is exactly correct as a form of plain English (pseudo code) description.

I do not have time this evening to write anything further for you, but may get a chance tomorrow evening if no-one else has come to your aid in the mean time.

 

[westaust55]

I am not sure I am on the right track but I was thinking , as my variables
are arranged as

b1 - b6 = time = 6 vars
b7 - b14 = longitude = 8 vars
b15 - b21 = latitude = 7 vars
b22 - b23 = speed = 2 vars

Since you have a full set of 8 EEPROMS, and are looking to save 24 bytes of data, we can save them as three groups of 8.
Thus one record set will occupy three consecutive bytes in every EEPROM.

The attached (untested) piece of program code should do that for you.

There are alternative ways such as writing to one EEPROM until it is full and then moving onto the next which would allow you to neatly write 8 bytes of data in one writei2c type statement but then you need to implement address checking for when to switch to the next EEPROM. Reason you would only write 8 bytes at a time this way is due to EEPROM paging systems – but it could save a few bytes of program space if program space does start to get tight.

 

[donrecardo]

Hi Westaus
Thats great,thank you

I didnt want to ask right away for a working example of code , before I had a
good chance to think about it ,thats why I waited a couple of days before
replying to the earlier posts. if I can partly work it out for myself it seems to
sink in and stick in my brain a bit better. I was pleased that my pseudo code
was along the right lines. At least it means I understand the principle of
what was needed even if I didnt know quite how to code it, but
understanding the principles helps me to understand your code better and
follow what it is doing.
I had looked at the code from the data log wizard but I found that rather
difficult to follow.

I just had a quick look at your code example and most of it seems to make
sense to me , except for the very last lines

'reload the last address from data memory
read 0,b6
read 1,b7

I assume this is used to set the high and low bytes of " address " to the next
location to write to after doing the next serin of new data. If this is so then
what confuses me is we are loading the address into b6 and b7 which are
variables that are already going to be used to hold some of the 24 chunks of
data unless of course we set " address " = b6 and b7 before
the serin command which means b6, and b7 are free to be used again

Thanks again, I shall give it a try over the weekend and report back on how
it goes

Don

 

[westaust55]

The lines:

'reload the last address from data memory
read 0,b6
read 1,b7​

are a remanent/remainder from the wizard based program and my variant for time stamping.

Ultimately even with variables b0 to b23 used, you will need to assign variables for other functions such as the EEPROM address pointer (a word variable required).

The easiest way to keep track of the variable usage is to use SYMBOL statements at the start of the program.