See my previous post #429.I'd like to know more about what you've been suggesting recently, also mentioned by Hippy then, I think - HSERIN background receive. If needed, I can repeat the SERIN statements that have been used with success in recent years.
A search of manual 2 on ATAN will find it documented, see page 26, where it clearly says it is supported on X2.Since the above, I googled and found an ATAN function - which seems to be supported on X2 parts. Sadly, I cannot find the ATAN documented
I did do a distance and direction calc between 2 GPS waypoints, on an X2, that was consistently accurate to 1 degree, I checked against a map.I've already changed that scaling of /100 to /50, without risk of overflow (just), and got a value that was "352" - one degree closer to 348.7. But the better solution would be to use ATAN. i.e. "opposite" in their example, is 1863 * COS(Lat) and "adjacent" is 6152. The next step, if Picaxe X2 parts support it, is to use COS, instead of my horrible approximation for that. Any new Autopilot developed for the 28X2 would not squeeze into an 08M2, so no harm in us adopting ATAN/COS if they work.
Thats true, when there is lock and up to a certain point in the sentance.That method can present problems if the size of the GPS message varies but it appear yours may have fixed-width fields.
If the GPS has a lock, then the E\W and N\S characters will be present and in a specific place, this should be a more robust check than checking the single A. And if your software has to deal with equator or meridian crossing, you need to read the E\W and N\S anyway.No need for use of the checksum at the end: just testing for things like the decimal point, "." being in the right place, instead of a comma, ",", when the GPS is in it's early stages of "warming up". Similarly, a simple check for the ",A," to say that the GPS is tracking.
No quite. The check was to see that the data coming from the GPS was consistent, I have had a couple of occasions where the sentence received direct from the GPS was corrupted in some way.The checksum would still be good on these cases, so the above checks would still be needed. The value of the NMEA checksum is for handling primitive FSK radio communications, without EDC, where corrupted received transmissions must be rejected. My guess is that is why you used the checksum in your own software
p.p.s. Thanks Martin, for two postings below. Yes, that was understood and you can read my more detailed words on myAll current PICAXE chips have 256 bytes (address 0-255) of EEPROM memory. Use the DATA or EEPROM command
But the manual says:All current PICAXE chips have 256 bytes (address 0-255) of EEPROM memory. Use the DATA or EEPROM command
So use with care.With some PICAXE parts (listed below) the data memory is shared with program memory.
PICAXE- 08M2 / 18M2 (not 18M2+)
Program 1792 up to 2048 is EEPROM 255 to 0
So on 08M2/18M2 all bytes of EEPROM are available for data storage if the program is shorter than 1792 bytes long.
EEPROM, READ and WRITE access data EEPROM rather than program Flash on all PICAXE devices.The base PIC data sheet quotes different minimum figures for Program and EEPROM (10k v 100k) byte / cell write cycles, but it's not obvious which is being used in the PICaxes (particularly in the 08M2).