PICAXE handling GPS for robot boat

srnet

Senior Member
Cant see why you would need to slow the GPS down to 4800baud though.

The 28X2 will cope quite happily with the data coming out of a GPS at up to 115,200 baud.
 

Robin Lovelock

Senior Member
Hi Folks. Even more progress to report: as well as the 10 minute youtube video of the 28X2-Compass working on Bray Lake, I've added a 3 minute video showing progress yesterday, getting the Telit JN3 GPS to work. Today I hope to investigate use of it's hot start capability. These videos are linked from my updated "compass" page on www.gpss.co.uk/rbcompas.htm

Thanks SRNET, as I said in my p.s. above: I found an interesting post #8 on this thread by Hippy, three years ago. He was suggesting the 28X2 then. I remember he got me to switch to the 08M2, which was an easy change. 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.

Robin
www.gpss.co.uk

p.s. thanks srnet (posting below): I looked at your post #429 ... followed the link... lots about your project ... to the code... lots more.
Would it be possible just to point me at the relevant Picaxe documentation ? Guess I could try googling "picaxe HSERIN background receive"...
.. this looks relevant: http://www.picaxe.com/BASIC-Commands/Serial-RS232-Interfacing/hserin/ Many Thanks, I may take a look at it some time soon, but right now, I don't seem to have timing problems. Will soon be trying powering off the Telit JN3 GPS, using the battery backup, and seeing results of a fast startup. Oh yes, that "compass" page above also has a 3 minute video of the JN3 working with the complete autopilot. Check out the antenna :)

p.p.s. I've updated the "compass" page on www.gpss.co.uk/rbcompas.htm with more information, including these words which relate to what was first reported on this forum .....

The following is for those giving detailed technical help to Robin ....
At the time of writing this, the BU355 and JN3 based versions work OK (software programs AUTOPX1.BAS aand AUTOPJN3.BAS respectively).
There is the same undiagnosed problem with both the SkyLab MTK3329 and Ulimate MTK3339 based versions (AUTOSK1.BAS and AUTOULT1.BAS): There is no problem with switching them from default 9600 to 4800 speed, using $PMTK251,4800*14 (to rule out Picaxe timing problems), and the expected Time is received, after the $GPRMC, not long after power on. However, instead of the expected 5123.81 after the ,A, (given many tens of minutes for the GPS to start tracking), we get unexpected data such as repeated "3,1224", with the occasional "5123810" (without the decimal point). For reference, a typical $GPRMC sentence should be:
$GPRMC,064951.000,A,5123.8160,N,00039.1234,W,0.03,165.48 ... etc (the test programs show 7 characters after $GPRMC and ,A, ).

Note that I made a giant leap forward after the above was added: we now have power switching of the Globalsat GPS working well. You will see, if you visit the "compass" page, that we have several things we could work on - including getting these MTK GPS to work.
 
Last edited:

srnet

Senior Member
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.
See my previous post #429.

GPS background receive, sentence parsing etc.
 

srnet

Senior Member
Not really sure what your question is, the use of hserin is well enough documented in the manual.

The obvious advantage is that hersin can get the data from the GPS at high speed, no risk of loosing characters.
 

Robin Lovelock

Senior Member
Thanks SRNET - that's useful, and I see hserin is documented on http://www.picaxe.com/BASIC-Commands/Serial-RS232-Interfacing/hserin/ which I took a quick look at. As you will know from yesterday's changes to the "compass" page on www.gpss.co.uk/rbcompas.htm the progress with BR355-S4 and Telit GPS means that diagnosing that problem with the MTK GPS has a lower priority - unless someone points out something simple to try, based on those symptoms. It seems certain now that these problems are not related to speed of the Picaxe, since all the GPS are being used at 4800, and we have no problems with most. But it's good to know that HSERIN is there, if needed in future. Anyone looking at the "blog" for this stuff is obviously looking in the wrong place :) The Blog is on www.gpss.co.uk/rbblog.htm - boat10 has now been there over 3 weeks ! :)
Robin
www.gpss.co.uk
 
Last edited:

Robin Lovelock

Senior Member
I have another problem to report, after doing something new: trying to switch the servo on and off, as I have with success for the GPS. Before I go into the details of my circuit, a brief mention of what else has been done: the latest experimental AUTOPX1.BAS software, with modifications to things like distance control of compass steering periods, is now in Boat6, ready for test on the water, but with the old BU355 permanently connected to power. Also, I've been trying to program around bad lat/lons (including in Taiwan) which can occur in the first few seconds of GPS startup.

The servo is normally connected permanently to common Picaxe 28X2 5v power, and receives it's signal via a 330R from pin B.1 and is controlled with standard Picaxe SERVO/SERVOPOS lines. The switch for the GPS is a 330R into the base of a BC635 power transistor, connected as "common emitter" with the collector on the 5v rail, and emitter as output pin. This works fine. The same circuit was made for the servo, using pin A.3 as output, and tested with an LED - works fine. The program switches the servo power on and off, as it should, but the servo tends to "hunt" - implying a problem. The program does not restart, but continues as it should, either switching power to the GPS, for a few seconds, until it has data, or to the servo, for the period of a typical compass-based steering loop, lasting 30 seconds. I tried putting a diode across the servo power (anode to +ve) in case it related to back emf from the motor - no change. I looked at the AXE024 Servo Driver circuit, and tried a 33uF tantalum capacitor, first across the servo power, and then - as on the AXE024 - across main power rails. I think the important clue is that the program does not restart, but runs normally. Maybe less than 330R needed into the base. I'll update this p.s. if I find the cause. If not, any ideas are welcome.

As always, any ideas welcome. Don't forget the outstanding strange behaviour of the MTK based GPS, not seen in the others, in my earlier post.
Robin
www.gpss.co.uk

p.s. Update at 5pm. It's a little better with a lower base resistor, and the servo does do roughly what it should, to steer, but sometimes gives a large wrong movement. I started by halving the 330R, which seemed a bit better, then took a chance and made it zero with a short. No black smoke, and I'm expecting the transistor base would not draw more than the Picaxe 20mA pin limit. On a related note, that some of you may know the answer too: I was trying to use my digital multimeter to measure what current is drawn by my "power saving" Picaxe. Maybe I need to try and find one of those old fashioned analogue meters, because the meter in series seems to effect the Picaxe program ? What I could see seemed promising, nearer 30 or 40mA instead of about 60mA. I thought this switching of the servo might be worth trying, but we already have the main benefit, of switching off the GPS - that takes most of the power.

p.p.s thanks SRNET (below) - Easily done, and I'll do that tomorrow..... Done! 5v rail OK, but 1v -ve going pulses on servo power: will try bigger C, or a bigger power transistor. Thanks! :)
The Servo switching is now working perfectly. The solution was a 10uF 50v capacitor across the switched output. The 330R into the Base needed to be a short too. This was after swapping the low power BC635 by a more substantial, medium power 2N3053 transistor - but it was the capacitor that got it to work, without "hunting". I can now experiment with "tighter" switching of the servo, such as when it needs to be moved. Unfortunately, I've not found a reliable means of measuring current drawn, even when using today's purchase of an analogue multimeter (as opposed to digital) because the presence of the meter seems to upset the servo. But we do have important progress: thanks.

I've updated the "compass" page on www.gpss.co.uk/rbcompas.htm
 
Last edited:

srnet

Senior Member
I would put a scope on the PICAXE supply rails and see what it looks like when the servo is moving or misbehaving.
 

Robin Lovelock

Senior Member
Hi Folks ! New videos have been added to "Snoopy's front page" on www.gpss.co.uk/autop.htm showing us having fun with experimental boat 6, with it's new, changing software, including the "race" between the two boats, and "recce" missions, to film boat 10 from boat 6. It's possible boat 10 makes it's Atlantic attempt next weekend, if that "weather window" we've been waiting for, remains open.

The reason for this posting is that I've just added a new "software" page, on www.gpss.co.uk/rbsoft.htm, releasing an extract of code used in my Picaxe software. This code has remained unchanged for years, and is the same in both old 08M2 based, and new experimental 28X2 based autopilots.

It's possible some of you will suggest corrections to this new "software" page, or may even see how I could improve this approximation.

Robin
www.gpss.co.uk

p.s. 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, other than this useful lead on http://picaxe.hobbizine.com/trig.html Their example works on my Editor here, in simulation, so the ATAN call is not thrown out. What I'm seeking is proper documentation, so that I might change that horrible approximation, that does a scaled 45 * DX / DY into a simple use of the ATAN - if it is supported.

in my experimental version, 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.
 
Last edited:

manuka

Senior Member
Down under contribution: We've just had a hardy Scott Donaldson attempt to kayak the 2000 km Australia-NZ Tasman Sea. Soberingly -in spite of a VERY rugged vessel & 3 month solo slog - he was frustratingly thwarted by rough seas as he neared land.

It's -sigh- again worth mentioning that your own quest (of ~twice the distance) WILL face similar conditions. You've little control over the journey, BUT the nasty IoW currents may justify at least launching somewhat offshore, or from more westerly Devon/Cornwall.
 

Attachments

srnet

Senior Member
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
A search of manual 2 on ATAN will find it documented, see page 26, where it clearly says it is supported on X2.

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.
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.

There were some key routines contributed by others on the forum.
 

Robin Lovelock

Senior Member
Hi Folks. Sorry for this late reply, but for some reason I seem to have become "unsubscribed" and not getting these posting emailed to me. Anyway, things have gone very smoothly indeed, after finding out how to use the Picaxe COS and ATAN functions, and I've been updating the "software" page on www.gpss.co.uk/rbsoft.htm. This change, using COS and ATAN worked well on Bray Lake, and I found a minor bug - now corrected - for one direction quadrant. Most of the spot checks "on the desktop PC" show accuracy increased to typically one or two degrees, and I'm looking forward to the next test sail of experimental boat 6, carrying this software, to see how straight the GPS Plots are.

I've not yet put anything on my website yet, but today I started on a "Snoopy Trolley", to wheel Snoopy down to the beach, instead of carrying him. He was already getting heavy last year, at 28kg(?) and now he weighs over 30kg. Maybe it was the paint ? I jest not. www.gpss.co.uk/rbpaint.htm shows my recent interest in this subject.

The Isle of Wight ? This ground has been gone over before, including on my Q&A page, but I like Armp's posting. I have to give my friend Dick some exercise :)

Any idea why my "subscription" seems to stop on this thread ? Too many smileys ? :)
Robin
www.gpss.co.uk

p.s. I've just made a major update to www.gpss.co.uk/autop.htm including the "Q&A" page. e.g. "Why launch from Barton-on-Sea, with those strong tidal currents near the Isle of Wight ?" Had a sail today, and the latest software worked OK.

All is working well, despite some early confusion with documentation. Several sailing tests with wind sensor and tacking logic. Lots of new software ideas being checked out, like slow rudder servo movement to reduce power and servo wear and tear. I've edited out the (poor) documentation links, from this P.S. because nobody interested :)

I've updated my "software" page, with details of recent progress: www.gpss.co.uk/rbsoft.htm

p.p.s. I'm still seeing nice surprises with the 28X2 Module, but today I seemed to have found an undocumented restriction:
HIGH B.0 works just fine, to provide a power switch for my GPS, but HIGH A.1 does not seem to function.
No big problem, since, for my application, GPS and Wind Sensor could probably be powered off the same switch.
I find myself having to google into Picaxe documentation - but at the end of the day, I still need to resort to "suck it and see" :)
 
Last edited:

Robin Lovelock

Senior Member
Hi Folks. Things are going well with the 28X2 based experimental software in boat 6, while boat 10 waits for a launch window.

Maybe one of you will advise me if I've misunderstood Picaxe program slots ?

My experimental software has managed to fill the 28X2 memory, and I've been trying new things but cutting out some of the code.

It seems that each of the 28X2 program slots could be used. It's easy for me to move a great chunk of my autopilot program into slot 1,
with the startup program remaining in the default slot 0. I was hoping that would give me a lot of free program memory.

It looked easy, just putting the code for slot 1 at the end of my program, preceded by #slot 1 and ending with a run 0.
My main program tests a register to decide if to do the normal program startup code, or jump to where the original slot 1 code ended.
BUT, after these simple changes, my total program (slot 0 and slot 1) still has the same limit on program size.

I guess I'm mistaken that this is a way of using more program memory ?

Robin
www.gpss.co.uk/autop.htm
 

rjandsam

Member
Hi Robin
You need to write your slot1 code as a new program and download it to the chip with #slot1 at the top this will then write the code to slot1. Don't forget you need to use run1 to make your program in slot0 goto slot1.
Rich
 

Robin Lovelock

Senior Member
Thanks RJandSam - Yes, after sleeping on it, I realised that the Picaxe editor probably needed each slot to have it's own source code - and that was it. In no time at all, I had split my test program into two parts, AUTOSLOT.BAS and APSLOT1.BAS, with some common subroutines (for speaking text to speech, like name of waypoint) in both programs. Both programs loaded OK, with lots of spare memory in each (AUTOSLOT 3065/4096 and APSLOT1 1539/4096) even after putting some squeezed out code back in. Also - the program, which is my latest experimental autopilot, seems to run exactly as it should. A nice surprise was that I could not see any time for the whole process of "slot switching" and my code in APSLOT1 (seen just by a SERTXD before and after the run).
This version might even get a sail today, after testing on the tea-tray :)
Robin
www.gpss.co.uk/autop.htm

p.s. Whoops! Have been doing the "tea-tray" test, walking near my house, in and out of waypoint boxes - not working correctly.
Maybe the registers such as w1, w2, etc are not shared by the program slots ?
I hope they are shared, and there is some silly bug in my code to find and fix.... yes, it was a bug, and so I needn't have worried.
Now off to meet friends in a pub, before we try this latest experimental software, sailing on Bray Lake :)

p.p.s. thanks RJand Sam (two postings below). Yes, got that the first time, and this has gone well. Did some sailing yesterday with it.
I've updated the "Software" page on www.gpss.co.uk/rbsoft.htm with recent pictures and info. See "Experimental work in progress".
 
Last edited:

rjandsam

Member
remember you cant use gosubs between slots, variables are shared and will only clear if you use reset to start from slot0.
Rich
 

Robin Lovelock

Senior Member
Hi Folks. This posting relates to my intention to start experimenting with "background receiving" of GPS serial data using HSERSETUP/HSERIN, suggested by SRNET. Thanks SRNET for earlier postings, including the recent one of connecting the Ardulog data logger to the terminal output pin and recording SERTXD output to the SD card. That saved me a few minutes, before I used a dedicated pin, to find code needed for future possible use of the Ardulog.

For the big picture, see www.gpss.co.uk/autop.htm - Snoopy's boat 10 has software unchanged for over 18 months, in an 08M based autopilot, and is on 24/7 test on Bray Lake, waiting for a suitable "launch window" for this year's Atlantic attempt. In recent weeks, I've been experimenting with different hardware and software, which we may adopt for next year's boat 11. This experimental work, using boat 6, is going well, and is summarised on my "software" page www.gpss.co.uk/rbsoft.htm

For years, I've used code, similar to that below, on both 08M and now 28X2 hardware, to read the $GPRMC sentence of data from the GPS. This is the only sentence I need, from several others that the GPS outputs every second, including $GPGLL, $GPVTG, etc. I've had to "program around" speed limitations of the Picaxe, with help from Hippy and others, given on this thread, years ago. The solution that has worked reliably includes switching clock rate of the Picaxe to M16 for SERIN calls, then back to M8 for SERVO/SERVOPOS use.

The limitation in our autopilot software due to this approach, is that the "Navigation Check" stage, when the GPS data is read, takes several seconds, because we need to pick up the required data from several $GPRMC sentences, arriving every second. This means the 1 second "steering loop" has an interruption, which we can live with, but if reading GPS data were in the background, we would not need this interruption. Maybe the required code, such as that below, could also be simpler and tidier :)

Here is a typical extract from code that has worked well for years, in both 08M and 28X2:

'e.g. $GPRMC,114801.123,A,5129.8944,N,00041.0771,W,3.53,358.23,280608,,*18
SERIN B.3, N4800_16, ( "$GPRMC," ) 'wait for $GPRMC sentence
'now we are near the latitude - start by reading 5129.89 into bytes when ,A, = GPS tracking
SERIN B.3, N4800_16, ( ",A," ), b22,b23,b24,b25,b26,b26,b27,b5 'first b26 is to skip the decimal point

What follows is code to extract the latitude from the ASCII characters, then goes on, after several other SERIN calls, to extract other data needed.

I've started to look at Picaxe documentation of HSERIN and HSERSETUP, seeing that one can stream the data into the scratchpad area.
The question will be how best to extract just the $GPRMC sentence (terminated by CR LF) from all the other data.
e.g. maybe use both SERIN, to wait for $GPRMC, then HSERIN to buffer all the $GPRMC sentence into the scratchpad ?
Question will be how fast the HSERIN acts. Could wait on just $GPRM to give more time. Any ideas ?

Robin
www.gpss.co.uk

p.s. Maybe HSERIN/HSERSETUP can only be applied to one particular pin ?
See documentation on http://www.picaxe.com/BASIC-Commands/Serial-RS232-Interfacing/hsersetup/
I was hoping I could refer to the same pin B.3 used for all the 08M2 and 28X2 based autopilots. Maybe not ?

Maybe no need to use HSERIN - Just use SERIN with the scratchpad memory, to read the whole $GPRMC line ?
This seems to work:

readgprmc: 'read $GPRMC line into scratchpad memory 0..66
ptr=0
SERIN B.3, N4800_16, ( "$GPRMC," ),@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc
return

Looks messy, but this could help a lot: collecting all the required data from one $GPRMC sentence.
 
Last edited:

hippy

Technical Support
Staff member
Yes, HSERIN only works with a specific pin of the PICAXE. You may be able to simply link your current pin to the pin needed for HSERIN which may minimise hardware changes on any boards you have.

For an example of handling the individual fields of a background received GPS message take a look at Example2.bas in the GPS010 samples -

http://www.picaxe.com/downloads/GPS010.zip

You could be able to use SERIN and @ptrinc. That method can present problems if the size of the GPS message varies but it appear yours may have fixed-width fields.
 

Robin Lovelock

Senior Member
Thanks Hippy. If I need to use HSERIN in future, I see that the 28X2 Module pinout says HSERIN pin is C.7, only recently used experimentally for the data logger, so it would not be a big hardware change, even on my three prototype 28X2 based boards. However, as on the p.s. in my earlier posting, it looks like the simplest solution will be SERIN and the scratchpad. Yes, for a particular GPS product, like that used, the message is a fixed length, when tracking. So tomorrow I expect to continue experimental changes of that code to read the GPS, that you helped me with years ago, near the start of this thread. Just back in after a few hours dodging rain and catching the sun :)
Robin
www.gpss.co.uk
 

srnet

Senior Member
That method can present problems if the size of the GPS message varies but it appear yours may have fixed-width fields.
Thats true, when there is lock and up to a certain point in the sentance.

GPGGA will in those circumstances be fixed width up till the altitude field.

GPRMC will in those circumstances be fixed width up till the speed field.

However, if your method of decoding the GPS sentances relies on these initial fixed field lengths, your not really in a postition to pick up the sentance checksum at the end and thus get an assurance that the position data stands a good chance of being correct.

The PICAXE code I have published for reading a GPS does read the GPS checksum and ignores the sentance if the calculated checksum does not match, this does not happen often, but I have seen the error.
 

srnet

Senior Member
The question will be how best to extract just the $GPRMC sentence (terminated by CR LF) from all the other data.
Configure the GPS so that it only puts out the GPRMC sentance ?
 

Robin Lovelock

Senior Member
Thanks SRNET but, as mentioned in my earlier posting, that simple use of SERIN and the scratchpad, was all that was needed. After my posting, I soon had the whole autopilot program running, with the old SERIN statements replaced by the new code, and working. 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. 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.

Before responding to the above, you may find it worth following some of the links below. Here I will stray "off topic" because your posting, mentioning the NMEA checksum, had me "going down memory lane" this morning, browsing through code I wrote in about 1991 (23 years ago?) to demonstrate use of GPS, (military) radio comms, text-to-speech, and terrain models: checkout the "Barossa video" linked from www.gpss.co.uk/barossa.htm - others may find this "ancient history" fascinating too - all these things are now commonplace - and so cheap ! :) After my browsing this morning, nowhere did I find my use of the checksum, other than to create it when simulating a GPS. I guess I should add mention that writing that "Barossa Operation" software, was "hobby stuff", done at home, on our first PC - a 386 ! My day job certainly did not include writing software - others working for me did that far more professionally ;-)

But you are not the only one to blame for this posting with "ancient history": yesterday, in a few hours relaxation with my wife and youngest daughter, we took a stroll around the grounds of Upton Manor, an old palace surrounded by a moat, on the outskirts of Slough. It was open for the day for charity. As we were leaving, we met a similarly aged chap as myself, who used to work there, when it was the Admiralty compass test place. He had been in the RN, and there just was not time to discuss the many common areas of interest. e.g. he knew the Ferranti FM1600B based Type 21 computer system, supplied to the RN in 1971, for which I'd written the data link comms software, and part of the automatic radar tracking software. That was when I was last employed to write software :) See www.gpss.co.uk/history.htm for mention of this, and the more recent picture at the bottom, of my seeing the Ferranti Pegasus again. Pegasus went into production in 1949, based on Alan Turing's work at Bletchley Park then Manchester Uni. It had very little program memory: less than 300 bytes - but it had a massive drum store - measured in KB ! Despite that, it was less primitive than the Picaxe ! :)

Robin
www.gpss.co.uk

p.s. thanks for your very quick reply below SRNET - no doubt before you followed those links above :)
 
Last edited:

srnet

Senior Member
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.
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.

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
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 position derived from the GPS is then transmitted over the airwaves to be tracked by listening stations who report to a central internet server so the track can be monitored. Not a good idea to be sending GPS updates that could jump to a location many kilometres away from the correct location, all because something has gone wrong with the GPS.
 

srnet

Senior Member
Incidentally, you would expect the serin and @ptrinc approach to work, although it would be interesting to know at which baud rate (from the GPS) it fails.
 

Robin Lovelock

Senior Member
Hi Folks ! I was relieved to see that there were no recent postings here, that I had neglected to respond to, since I don't get reminded automatically.

Lots of updated on Snoopy's front page www.gpss.co.uk/autop.htm including new videos and a page of pictures of his last Atlantic Attempt a week ago.
I've obviously been very busy since then, and the two most relevant pages to this forum are:
the "blog" on www.gpss.co.uk/rbblog.htm - including the need for an autopilot software change - that last was 20 months ago !
the "software" on www.gpss.co.uk/rbsoft.htm - where I've added some words about my "caution" regarding software changes :)

Enjoy the videos ! :)
Robin
www.gpss.co.uk
p.s. there is now an "experimental blog" page on www.gpss.co.uk/rbblogx.htm
p.p,s. Snoopy's best attempt so far, on 30th November 2014, is on his front page above. Enjoy :)
 
Last edited:

Robin Lovelock

Senior Member
Crikey! Nothing here, including from me, since August last year - and three Atlantic Attempts since then :)

Reason for this posting is that something has occurred to me: is it possible for a Picaxe program, in 08M2 or 28X2 based systems, to access any of the program memory ?

For years, our autopilots have lived with the restriction that there is no non-volatile memory available. Here, I'm not speaking about adding extra stuff to the hardware - simply exploiting what may already be there. Our autopilot software has always had to assume that the solar power based supply might shut down at any time, and any location along Snoopy's route, and therefore the location of the next waypoint is calculated from the GPS lat/lon. It would be convenient if at least the current waypoint were "remembered".

The program itself is not lost, when power is lost then restored. So maybe a few bytes of program store might be accessed ?

I must also try and "subscribe" again, since this has never worked reliably for me in the past.

Robin
www.gpss.co.uk
 

JimPerry

Senior Member
All current PICAXE chips have 256 bytes (address 0-255) of EEPROM memory. Use the DATA or EEPROM command :confused:
 

Robin Lovelock

Senior Member
Thanks Jim. I had not heard about this, and soon found http://www.picaxe.com/BASIC-Commands/Variables/eeprom/
But maybe this does not permit writing to these locations during program execution ? It seems to simply be a means of loading data at compile time ?
There are usually a few bytes free in my 08M2 based autopilot (still being used, since the 28X2 based autopilot solutions are still in development here),
so it could hold something like the 6 bytes of current waypoint lat/lon. But little value if this could not be modified after launch.

Good to see your posting below arrived as an email here. My "subscribe" check boxes don't seem to stay ticked.

p.s. Sorry Jim - I should have followed links to read/write - looks good :)
http://www.picaxe.com/BASIC-Commands/Variables/read/

Robin
www.gpss.co.uk

All current PICAXE chips have 256 bytes (address 0-255) of EEPROM memory. Use the DATA or EEPROM command :confused:
p.p.s. Thanks Martin, for two postings below. Yes, that was understood and you can read my more detailed words on my
www.gpss.co.uk/rbblogx.htm - near the end. e.g. I might use the last 6 bytes of program memory for the current waypoint lat/lon.
 
Last edited:

MartinM57

Moderator
Note the:

Applies To: All
See Also:read write table

..at the bottom of the EEPROM page.

EEPROM is fully writeable and readable from your program
 

Armp

Senior Member
All current PICAXE chips have 256 bytes (address 0-255) of EEPROM memory. Use the DATA or EEPROM command :confused:
But the manual says:
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.
So use with care.
 

binary1248

Senior Member
Oh how I wish I had not found this thread. I have spent hours and hours reading Robin's various discussions while I should be out in my shop finishing many unfinished projects (none which are PicAxe related, thus are really no fun).
 
Last edited:

AllyCat

Senior Member
Hi Robin,

Beware that the EEPROM / Program Memory can "wear out" after much re-writing. 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).

So you should probably not write every incoming block of data to the NV memory, but perhaps only every minute or hour, depending on the operating conditions of your hardware/software (temperature, voltage / data validity checking, etc). This has been discussed quite recently at some length on the forum.

Cheers, Alan.
 

hippy

Technical Support
Staff member
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).
EEPROM, READ and WRITE access data EEPROM rather than program Flash on all PICAXE devices.
 

Robin Lovelock

Senior Member
Thanks all - and sorry for my earlier p.p.s when I did not credit Armp. But particular thanks for that warning from Allycat.

I had already decided that this EEPROM capability, despite the temptation, would not be exploited in the boat expected to be launched in February or March, and now - probably not in any boat launched before late this year. After Boat10, the next will be Boat11, probably with a Picaxe 28X2 + Compass based autopilot.

Every component I've used over the years has tended to be adopted after it's been used for many months, and typically years, with very few failures. i.e. I'm looking for MTBF of every component in the 12 month + ballpark, since the total boat system needs to have a good chance of surviving typically 6 months or more.

Good to hear from you again Hippy: I'm not clear in significance of your reply: if I use the last few bytes of program memory, on 08M2 or 28X2 systems, do I need to worry about this memory "wearing out" ? The simplest logic would involve regular updates to this memory on each time around the 7 second control loop cycle.

With adoption of the 28X2, without the tight memory restrictions, it's less important to exploit this new (for me) capability, since I have space to program in the same approach of "big boxes", used for most of the mission, for that last bit near the USA.

Robin
www.gpss.co.uk/autop.htm
 

Technical

Technical Support
Staff member
To save data you should use the data eeprom, not the program memory, using read/write as hippy suggests. That applies to any size chip.

1 year / 7 secs = 4505142 writes, which is well over 100k, so definitely not recommended. Reduce the write frequency.
 

AllyCat

Senior Member
Hi,

Thanks for that clarification hippy.

There should be no issues with 99% of PICaxe applications, but for anyone who is really "pushing" the NV memory, I found the following paragraph from the base PIC manuals of interest:

"11.2 Using the Data EEPROM

The data EEPROM is a high-endurance, byte addressable array that has been optimized for the storage of frequently changing information (e.g., program variables or other data that are updated often). When variables in one section change frequently, while variables in another section do not change, it is possible to exceed the total number of write cycles to the EEPROM without exceeding the total number of write cycles to a single byte. Refer to Section 30.0 “Electrical Specifications”. If this is the case, then a refresh of the array must be performed. For this reason, variables that change infrequently (such as constants, IDs, calibration, etc.) should be stored in Flash program memory."


That seems to suggest that calibration and IDs, etc. are better stored as Symbol declarations within the PICaxe Program? And those symbols not used in the last 256 bytes of the 08M2/18M2 Program space?

BTW to save struggling though almost 40 pages of "section 30", it's actually section 30.5 "Memory Programming Requirements" (which interestingly refers back to 11.2 as a footnote in my 14/20-pin datasheet but not the 8-pin).

Cheers, Alan.
 

Technical

Technical Support
Staff member
Correct - any command (including symbol) that is not eeprom/read/write will be part of the user's BASIC program, normally stored in program memory.
So you can use symbol, but that gives you a fixed value that can never be changed as the program runs.

For larger arrays you can use table/readtable, but again these values can't be changed.

For a changing value that you want to maintain between power cycles, read/write into the data eeprom is exactly what you should use, that is what it is for!


Don't get confused by the 08M2 last few bytes in a very long program. What this means is that if the BASIC code is longer than the available program memory the user's program then starts to overflow into the eeprom data memory (ie the eeprom space is 'borrowed' to enable the program to get a bit longer, it's a special trick to allow you a longer program on the smaller program memory size parts (only 08M2 and the obsolete older 18M2). So a really long 08M2 program uses both program + eeprom memory to store the long program. A shorter program just uses program memory and so the entire eeprom is then available for use by the read/write commands.

This doesn't apply to the 14M2, 18M2+, 20M2 as they have much larger internal memory to start with, so the data eeprom is always completely separate.
 
Last edited:
Top