Hi Folks. Mostly rain here today, and wife more interested in watching the tennis on TV, so I was able to do things not normally done at the weekend
Mr Postman delivered some bits, including two of the Skylab GPS based on the Mediatek 3329 suggested by SRNET. I've made some good progress, reported here, since you may point out things. First I put a working Picaxe 28X2-Compass-BR355 in my boat 6, all ready to try on Bray Lake this coming week.
Then, using bits delivered today, I made up a second system and checked it worked - and it did.
Then I soldered one of the two Skylab GPS in, to replace the BR355 and that practically works.
i.e. I'm getting the $GPRMC sentence from it, and the good news is that current has dropped from about 60mA to about 35mA.
That's encouraging enough, and makes this GPS well worth pursuing - BUT, there are some problems to overcome...
It did not take long to find changes needed, such as the SERIN changing from SERIN B.3, N4800_16, to SERIN B.3, T9600_16,
but the comments in the code below flag up peculiarities. At this stage, I'm not sure how much is due to the detailed
behaviour of the Skylab GPS, or if it relates to the Picaxe struggling to catch data at 9600 instead of 4800.
It will not be the first GPS from Taiwan/China that I've seen, over the years, that does NOT sent out ,V,
in the $GPRMC sentence to say it is not tracking yet, and only gives ,A, when data follows.
But there are all sorts of things that may be going on here.
I need to find a work-around, if there is one. e.g. change the speed of the GPS from it's default 9600 down to 4800.
e.g. find sufficiently complete documentation for the Skylab implementation of the NMEA $GPRMC sentence.
Here is an extract of code from my test program:
'e.g. $GPRMC,114801.123,A,5129.8944,N,00041.0771,W,3.53,358.23,280608,,*18
waittrack:
setfreq M16 'wait for the Skylab GPS to start tracking
SERIN B.3, T9600_16, ( "$GPRMC," ) 'wait for $GPRMC sentence
SERIN B.3, T9600_16, ( ",A," ),b22,b23,b24,b25,b26,b27,b5 'wait for tracking to start
setfreq M8 'b22 etc should hold 5129.89 the decimal should be in b26
sertxd ( "waiting ",b22,b23,b24,b25,b26,b27,b5,10,13 ) 'output back to PC
if b26 <> "." then goto waittrack
'the Skylab GPS sometimes gives A,3,16,18 - due to GPS or Picaxe speed limitation ?
setfreq M8
sertxd ( "GPS now tracking.",10,13 ) 'output heading value back to PC
SEROUT B.2, T9600_8, ( "S The G P S is now tracking.",10 ) 'test TTS output was _16
PAUSE FOR4SEC
setfreq M16
I've updated the section "New Picaxe computer and Compass working" at bottom of the "Compass" page on
www.gpss.co.uk/rbcompas.htm
Any suggestions or info will be appreciated.
Robin
www.gpss.co.uk
p.s. Thanks SRNET (Posting below). I'm using the 28X2 Module, so would your approach work on it ? Right now, I'm thinking the simplest thing to try next, will be to wire another Picaxe pin, via a 220R, into the Rx line of the Skylab GPS, so I can switch it's speed to 4800 at the start. I found what seems the correct command for that : $PMTK251,4800*14<CR><LF> which looks simple enough. If that works, maybe I can find similar proprietary sentences, to switch off NMEA sentences other than $GPRMC - the only one I use. Looks like weather will be better tomorrow, so this may wait another day or two
p.p.s. Still curious to know if SRNET's approach would work on the 28X2 Module, but I prefer the idea of switching the Skylab GPS from it's default 9600 to 4800. It would seem simple, and the addition of a wire from pin B.7, via 220R, to the GPS RXD pin is simple - I did it today. I like use of the RXD into the GPS, because it opens the door to setting up other GPS for lower power use, and/or suppression of unused NMEA sentences, to reduce load on the PICAXE. e.g. Trickle mode on Globalsat BR355. I wired up this RXD pin today, but have not made much progress: I corrected the *17 checksum to *14 in the SPMTK251 sentence above, after seeing that it must be a mistake in the forum I found it mentioned. I googled and found what might be a more reliable document for the Skylab SKM53 (and Mediatek MTK3329?). I suspect the Skylab GPS may be doing things not expected, rather than speed limitations of the Picaxe. My attempts to switch speed to 4800 don't work. Many reasons possible, including my use of the wrong code, and/or the Skylab recommending different interfacing. e.g. "Pull up 10k" on
serial input and output, compared with Picaxe "Pull down 10k" for input, and serial 330R for output.
If I go back to code I used yesterday (above), waiting for the decimal point after the ",A," it works - but I notice this strange behaviour, particularly when the GPS has poor signals (near the Window, connected to my desktop PC): it may spend several minutes, waiting for the decimal, indicating good lat/lon data (e.g. 5129.89 ), but the rest of the time, it repeatedly sees the same string repeated, for tens of seconds, or minutes, such as "3,24,12" or "3,2412," or "3,12,25" or "3,1225,". I'm sure this is a clue. I can see me wiring up the other Skylab GPS
to a 7 pin D serial connector, so I can do some tests with HyperTerminal on my Laptop PC.