Retrieving data from EEPROM

nerdegutta · Nov 7, 2013

With reference to this thread:

http://www.picaxeforum.co.uk/showthread.php?24517-Oh-no-not-another-GPS-logger

The logger is set to save data every 7 sec.
I haven't bothered to save the date from the GPS, but I save lat, lon, hour and minute. I was wondering why the time is not saved in the order it is received. I don't know how to describe it, but check the attached gps_data.txt.

Source code is also attached.

For schematic, see the linked thread.

Thanx.

- nerdegutta

hippy · Nov 8, 2013

Not sure why it isn't working as expected but you need to determine whether it's -

1) the output routine not sending the correct value out
2) incorrect data is being retrieved from the EEPROM
3) incorrect data is being put into the EEPROM
4) the GPS reporting incorrect data

Paix · Nov 8, 2013

It goes without saying that I'm with Hippy on this one. If you have room, you need to report only the pertinent fields until you are confident about them.
Logically filling the EEPROM with known good data and checking the output translation is absolutely sound, but is also likely to be tedious. . .

Is there any way that you can also capture the GPS stream data directly to a PC (preferably Linux) and post process using command line tools to extract the appropriate fields for the period? A minimal dataset gives less room for errors to lurk unseen, hidden by the visual noise of adjacent data.

Can you verify that Gps_data.txt is the output data from your program? (I looked over the code, but concentrated only on the reading/writing of data not any top and tail formatting that you might be generating. Even I have to discard information to be able to focus my mind . . . !

I am assuming, having looked at both threads, that the time is reported in the format T99:99:99Z ?

You state that you are reading the GPS stream every 7 seconds, but your reported times appear to be Thh:mm:00Z so I suspect that it is an interpretation of the time that is flawed somewhere. Significantly the flow of time seems to be from 18:34, 18:35, 18:36 and then 18:34. Time from GPS satellites doesn't go backwards, so I have to ask, Is your test data synthetic with typos or is this a framing error of sorts?

Is the date displayed and the time frame generally what you expect it to be?

I probably can't help you, but hopefully can ask the right questions to assist others in doing that. What we do need to know is what you know that we are merely having to guess at. Your hh:mm fields could almost be temperature and given that your location is "Europe", then that might almost be the case. Another good reason for giving at least a country . . . it does actually help at times.

Your ball I think . . .

nerdegutta · Nov 8, 2013

hippy said:
Not sure why it isn't working as expected but you need to determine whether it's -

1) the output routine not sending the correct value out
2) incorrect data is being retrieved from the EEPROM
3) incorrect data is being put into the EEPROM
4) the GPS reporting incorrect data

1) In the exctract_GPS_data
2) The data is correct retrieved. I have this code to see that it is OK:

Code:

	' debugging data sent to terminal
	sertxd("Wayp :",#Waypoints,cr,lf,"Time :",#Hour,":",#Minute,"Z",cr,lf,"Lat  :",#LatDeg1,#LatDeg2,".",#Latmin1,#LatMin2,#LatMin3,#LatMin4,#LatMin5,cr,lf,_
			"Lon  :",#LonDeg1,#LonDeg2,".",#LonMin1,#LonMin2,#LonMin3,#LonMin4,#LonMin5,cr,lf,"Calculated LAT :",#LatDeg1, #LatDeg2,".",#LatDecMin,cr,lf,_
			"Calculated LON :",#LonDeg1,#LonDeg2,".",#LonDecMin,cr,lf)

3) The data sent to the GPS is processed by the code, and should be correct.
4) The GPS is sending/reporting correct data. I've got a slightly different circuit, with slightly different code, that sends data straight to the PC and into Google Earth. "Live tracking" works as it should.

Paix said:
It goes without saying that I'm with Hippy on this one. If you have room, you need to report only the pertinent fields until you are confident about them.
Logically filling the EEPROM with known good data and checking the output translation is absolutely sound, but is also likely to be tedious. . .

.. tell me about it...

Paix said:
Is there any way that you can also capture the GPS stream data directly to a PC (preferably Linux) and post process using command line tools to extract the appropriate fields for the period? A minimal dataset gives less room for errors to lurk unseen, hidden by the visual noise of adjacent data.

Can you verify that Gps_data.txt is the output data from your program? (I looked over the code, but concentrated only on the reading/writing of data not any top and tail formatting that you might be generating. Even I have to discard information to be able to focus my mind . . . !

When I'm debugging/programing the code, I use PE's Terminal. Everything is coming up as expected

Paix said:
I am assuming, having looked at both threads, that the time is reported in the format T99:99:99Z ?

While deciding what data to be stored, the second where ruled out.

Paix said:
You state that you are reading the GPS stream every 7 seconds, but your reported times appear to be Thh:mm:00Z so I suspect that it is an interpretation of the time that is flawed somewhere. Significantly the flow of time seems to be from 18:34, 18:35, 18:36 and then 18:34. Time from GPS satellites doesn't go backwards, so I have to ask, Is your test data synthetic with typos or is this a framing error of sorts?

Is the date displayed and the time frame generally what you expect it to be?

The date is hardcoded, since it is not necessary to store. Yes, it is how I expect it to be.

Paix said:
I probably can't help you, but hopefully can ask the right questions to assist others in doing that. What we do need to know is what you know that we are merely having to guess at. Your hh:mm fields could almost be temperature and given that your location is "Europe", then that might almost be the case. Another good reason for giving at least a country . . . it does actually help at times.

Your ball I think . . .

Thank you for your input.

Looks like there is a pattern. A page-wise pattern. Changing page for each write cycle. Could this be the case?

BWT: I'm in Norway.

- nerdegutta

nerdegutta · Nov 10, 2013

I think there is some strange things with the SaveTo24LC16B procedure:

Code:

SaveTo24LC16B:
	If MemPos > $7FF Then EpromFull					' if MemPos is bigger than 2048 then eeprom is full
	deviceID = Mempos / 256 * 2 | $A0					' configuring the deviceID
	HI2CSetup I2CMASTER, deviceID, I2CSlow, I2Cbyte			' configuring the I2C connection
	HI2COut Mempos, (Hour,Minute,LatDeg1,LatDeg2,LatMin1,LatMin2,LatMin3,LatMin4,LatMin5,LonDeg1,LonDeg2,LonMin1,LonMin2,LonMin3,LonMin4,LonMin5)
	Pause 10
	Mempos = Mempos + 16
return

The program is set to save twice a minute, but going through the saved/retrieved data there is a pattern. Please see attached raw_master.txt
When I load this file into Google Earth, I get a part of the route I drove. I Edited the file to this:

Code:

<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.0">
<trk>
<trkseg>
<name>Track</name>
<trkpt lat="xx.4185" lon="xx..2497"><time>2013-01-01T19:22:00Z</time></trkpt>
<trkpt lat="xx.4162" lon="xx..2422"><time>2013-01-01T19:22:00Z</time></trkpt>
<trkpt lat="xx.4152" lon="xx..2384"><time>2013-01-01T19:23:00Z</time></trkpt>
<trkpt lat="xx.4109" lon="xx..2430"><time>2013-01-01T19:23:00Z</time></trkpt>
<trkpt lat="xx.4063" lon="xx..2480"><time>2013-01-01T19:24:00Z</time></trkpt>
<trkpt lat="xx.4015" lon="xx..2520"><time>2013-01-01T19:24:00Z</time></trkpt>
<trkpt lat="xx.3965" lon="xx..2547"><time>2013-01-01T19:25:00Z</time></trkpt>
<trkpt lat="xx.3911" lon="xx..2561"><time>2013-01-01T19:25:00Z</time></trkpt>
<trkpt lat="xx.3860" lon="xx..2579"><time>2013-01-01T19:26:00Z</time></trkpt>
<trkpt lat="xx.3860" lon="xx..2520"><time>2013-01-01T19:26:00Z</time></trkpt>
<trkpt lat="xx.3847" lon="xx..2443"><time>2013-01-01T19:27:00Z</time></trkpt>
<trkpt lat="xx.3837" lon="xx..2345"><time>2013-01-01T19:27:00Z</time></trkpt>
<trkpt lat="xx.3848" lon="xx..2248"><time>2013-01-01T19:28:00Z</time></trkpt>
<trkpt lat="xx.3871" lon="xx..2164"><time>2013-01-01T19:28:00Z</time></trkpt>
<trkpt lat="xx.3874" lon="xx..2082"><time>2013-01-01T19:29:00Z</time></trkpt>
<trkpt lat="xx.3840" lon="xx..2028"><time>2013-01-01T19:29:00Z</time></trkpt>
</trkseg></trk>
</gpx>

And I get the exact same route. There is something strange going on here, and I need some advice/pointers in the right direction.

Thanks for reading.

View attachment raw_master.txt

- nerdegutta

rossko57 · Nov 10, 2013

nerdegutta said:
<trkpt lat="xx.4185" lon="xx..2497">

Obviously those are not valid lat/long values, but it's a bit meaningless without seeing the data they are derived from.
Your GPS data source seems to be in degrees & minutes, sure there is no confusion with purely decimal degrees (as used in GPX)? 22 30' is 22.50 degrees

rossko57 · Nov 10, 2013

nerdegutta said:
I think there is some strange things with the SaveTo24LC16B procedure:
...
If MemPos > $7FF Then EpromFull

Further thinks; you have assigned Mempos as a byte variable....

nerdegutta · Nov 10, 2013

rossko57 said:
Obviously those are not valid lat/long values, but it's a bit meaningless without seeing the data they are derived from.
Your GPS data source seems to be in degrees & minutes, sure there is no confusion with purely decimal degrees (as used in GPX)? 22 30' is 22.50 degrees

And why wouldn't these values be valid lat/lon? The xx. is for hiding my location.

rossko57 said:
Further thinks; you have assigned Mempos as a byte variable....

Hm... Yes, I have. I will check into that.

Thanks

- nerdegutta

nerdegutta · Nov 10, 2013

rossko57 said:
Further thinks; you have assigned Mempos as a byte variable....

I changed the mempos from

Code:

symbol Mempos = b18

to

Code:

symbol Mempos = w11

And now it works as expected.

All the data is read back as it should be. I've just tested around my house.

So... The Mempos was assigned as a byte, which can only have a value of 255, and the SaveTo24LC16B procedure checks if Mempos is greater than 2048, it tell the program that the EEPROM is full. A bell should have rang out loud, when I wrote:

Code:

If Mempos > $7FF Then EpromFull

Because as originally, the Mempos would only be 255...

Thank you all!

- nerdegutta

rossko57 · Nov 10, 2013

nerdegutta said:
And why wouldn't these values be valid lat/lon? The xx. is for hiding my location.

Well xx isn't valid nor is .. (double dot)
It makes it a bit difficult if the data isn't as you expect but you don't show the data.
Anyway, sorted now

nerdegutta · Nov 10, 2013

Yes, sorted out now.

Thanks.

- nerdegutta

Retrieving data from EEPROM

nerdegutta

Senior Member

Attachments

hippy

Ex-Staff (retired)

Paix

Senior Member

nerdegutta

Senior Member

nerdegutta

Senior Member

rossko57

Senior Member

rossko57

Senior Member

nerdegutta

Senior Member

nerdegutta

Senior Member

rossko57

Senior Member

nerdegutta

Senior Member