Is there a GPS Tutorial for the 28X1 ?

[MFB]

Whilst doing a search for GPS data logging I came across this post from Technical...

"The GPS tutorial has been delayed as, as you suggest, we felt the 28X1 is better suited than the 18X due to the background serial receive into the scratchpad. That said, many people have used the 18X, but it's more difficult."

Is the delayed tutorial been finished yet?

 

[jmumby]

To get you started the script on this page http://www.picaxeforum.co.uk/showpost.php?p=74562&postcount=16 is the quickest nastiest gps logger I could come with for 28x1. At 16Mhz it will log a GLL string every second.

 

[MFB]

To Technical

Thanks for the example code jmumby but I was really aiming my question at Technical, who said Rev-Ed was in the process of producing a GPS tutorial. From the number of questions on the forum about the relative merits of using serin or hserin, and how to use the scratch pad feature on the later, it certainly seems such a document would be well received.

I am not sure that microcontrollers benefit from having a ‘killer application’ in the same way as personal computers (e.g. spreadsheets for the Apple II and colour graphics for the Spectrum (games)), but I would have thought that a well-documented GPS/28X1/LCD evaluation board would prove a popular product and might even result in lots more magazine articles featuring the PICAXE.

 

[atharvai]

ok i've only read through he datasheet once but, the GPS001 outputs the longest string of 13 data sets. and the PICAXE has 13 variables. can this not be used?

I'm considering a GPS001 project. just not sure about the application.

also whats the diff in performance for 18X and 28X1 otherthan the background serin for 28X1? thanks

 

[MFB]

Example of good marketing

Here how kronosrobotics support the DiosPro microcontroller.


www.kronosrobotics.com/Projects/GPS.shtml

 

[Jeremy Leach]

Having dabbled with GPS and picaxes over the past year, I'd say it might be difficult to write an all-embracing document about the use of GPS since it all depends on your particular application, the type of GPS string you are intending to receive and the manufacturer of the particular GPS module and how they actually interpret the standards (and some offer custom output). However there is still lots of scope to offer tips and various approaches, and I guess Rev-Ed might have a particular module in mind.

 

[MFB]

DIY

No response yet from Technical to my question about the promised GPS tutorial. I suppose this means we will have to wait for Hippy, or someone else, to produce support material for Rev-Ed.

 

[Texy]

No response yet from Technical to my question about the promised GPS tutorial. I suppose this means we will have to wait for Hippy, or someone else, to produce support material for Rev-Ed.

....I,d rather they concentrate their efforts on the forthcoming X2 product release


Texy

 

[MFB]

I thought it was best not to mention the X2. After all, there are still a few weeks of summer left.

 

[BrendanP]

It's like the war, don't mention it......

 

[jmumby]

There is a GPS tutorial it is called serin,serout,hserin. As jeremy says each manufactuer has different interpretations of what you would expect to get out of a GPS.

The tutorial could include information that is not relevant to your GPS. The best thing to do is just to get a GPS read the datasheet and go for it.

The most complicated thing I found was how to format the PSRF sentences and as per usual I was just making it more complicated than it needed to be.

 

[oldjoe]

GPS Tutorial Standardization

All the GPS that I have worked with have both Custom Data Formats and NEMA Formats, all the GPS are susposed to have the full set of NEMA Formats and most do.

The NEMA formats are standardized and are common across all GPS. So the NEMA GPS Formats could be added to the PICAXE Tutorial.

If I were doing a GPS project with a PICAXE, I think I would use hser and pick the NEMA format that contained the data I wanted to use and the parse the string for the data I was interested in.

The downside is some on the NEMA sentencies are long.

The way I would do it is to dump everything to the scratch pad then parse the header, the NEMA ID is the first 3 bytes, ASC II characters in the string. A simple compare would determain if it was the string you want; if not then reset the pointer to discard this message and standby to capture the next. BTW, the setup write to the GPS determains which messages the GPS will output. All the GPS that I used would only output the messages that you told it to during the set-up.

For every message that you told the GPS to output, they will come in a burst every second, there is a small gap between messages so you have time to parse the header and reset the pointer. Then a big gap in time before the next burst comes out, so you have time to parse the ASC II string and get the data you are interested in into a variable before the next burst starts.

I used to use this GPS data for Robotics for guidance and I needed only 2 message: GDA and ZRM. GDA is a long one and has all kinds of data in it, I only needed to parse out LAT and LON. The GDA Format goes: header;time in seconds;lat;long; and a lot more data;CR;LF. ZRM is fairly short and I only needed it for the month, day, minute and second for my recorder time tag. I have several interesting code fragments: 1) a conversion from LAT or LON to feet that worked well; 2) a software program called: "the yellow brick road" for land surface vehicles and 3) a software program called: "sea anchor" for water surface vehicles.

I haven't tried it yet, but I suspect that if you did a Google on NEMA you would get you their official web site and you should be able to find their GPS Standards.

oldjoe

 

[Jeremy Leach]

The thing I'd like to point out though is that some manufacturers deliver fixed length sentences for NMEA output (when the data is valid), which actually makes it much easier to decode with a picaxe because you don't need to parse taking into account comma delimeters. For instance, Trimble do this on their Lasseniq module.

From what I've seen of the NMEA standard it's fairly loose and allows variable decimal places in certain fields, but I think it's sensible when manufacturers choose a fixed length interpretation because it makes decoding by microcontrollers a lot easier. If you actually start to try to write code to extract values between commas, where there could be decimal places, and each field slightly different, you'll find out how tricky and code-hungry this can be on a picaxe. At least when you know fields are always fixed length, you can get the data into the scratchpad then know immediately which position the bytes are that you want to look at.

To do proper parsing using the commas needs a lot of scanning of the received data to locate the position of commas, then scanning within the comma boundaries to locate decimal places etc, then finally comnverting the bytes to values and storing them. Not a simple process ! And to write 'generic' code that could cope with the output from any manufacturer's interpretation of the NMEA standard even more complex ! I know it's definitely do-able on a picaxe, but not simple.

So ...personally I think the standard should change to a fixed length format

I've attached a bit of info on the standard for some NMEA fields as example of how the standard is quite loose - and there are a number of other loosely defined field types. For instance Numeric fields:

Variable length integer or floating numeric field. Optional
leading and trailing zeros. The decimal point and associated
decimal-fraction are optional if full resolution is not required
(example: 73.10=73.1=073.1=73).

 

[MFB]

Jumumby, your definition of a tutorial raises some interesting possibilities. Rather than continuing to publish all those programming books and technical magazine articles, why not just give people a list of commands? It would save a lot of trees.

Anyway, I don't think you really think that's a good approach because you have recently posted many extreemly detailed and useful contributions (rather than just commands).

Thanks to Jeremy and Oldjoe for their helpful advice. However, I am disappointed that Technical has not yet responded to my original question regarding progress with the promised Rev-Ed tutorial.

 

[Technical]

The datasheet we prepared was based upon a GPS unit that has unfortunately been discontinued. As, already highlighted, there are subtle differences between GPS units we wish to publish a sheet that also has a 'plug and play' available GPS unit associated to it. We are looking at alternate GPS units at present, any suggestions/recommendations are also welcome.

 

[jmumby]

I can recommend one not to use. I cut my teeth on the em-406a. Well maybe that is a bit harsh, It has taken a bit of a beating, you know wired in back to front numerouse gravity trips to the floor and it still works.

The problem with this module is that it has no battery back-up as well as no facilty for an external aerial. Also a peeve is the variable length strings, this is a pain.

One benifit is that it has a lead that you can easily wire into something not like these surface mount jobbys that seem to be the in thing.

For every message that you told the GPS to output, they will come in a burst every second, there is a small gap between messages so you have time to parse the header and reset the pointer. Then a big gap in time before the next burst comes out, so you have time to parse the ASC II string and get the data you are interested in into a variable before the next burst starts.

&#65284;PSRF103,<msg>,<mode>,<rate>,<cksumEnable>*CKSUM<CR><LF>

If you set mode to 1 and leave rate as zero (assuming you have all sentences turned off) then this will send you the string immediately after this command. So you need not wait for the GPS to send a string. Just demand it when you want it.

 

[MFB]

Thanks

Technical, thanks for the update. SparkFun Electronics sell a wide range of GPS receivers, and as this company is also a PICAXE distributor, it would make sense to base your tutorial on one of their offerings. I am sure SparkFun would be places to include it on their web site. An integral antenna and a fixed length sentence option would seem to be desirable features but I can't yet recommend a receiver type.

 

[Jeremy Leach]

Just to throw in experience that myself and RexLan have had using Trimble Lasseniq module (sold via Sparkfun) ....

Works well, and does have fixed length sentence for NMEA RMC (not sure about the other NMEA), even though the datasheet doesn't suggest this!, but getting after-sales technical expertise proved very difficult, and the connector is VERY small and difficult for PCB design.

I'd be interested in other people's suggestions too.

Oh, and just to give example of fixed length, here's a snippet of RMC output I recorded ..

$GPRMC,084741.00,A,5223.6878,N,00214.0117,W,020.1,346.1,200708,06.2,W,A*06
$GPRMC,084742.00,A,5223.6934,N,00214.0133,W,019.3,355.0,200708,06.2,W,A*01
$GPRMC,084743.00,A,5223.6989,N,00214.0136,W,019.3,001.1,200708,06.2,W,A*00
$GPRMC,084744.00,A,5223.7043,N,00214.0133,W,018.4,003.3,200708,06.2,W,A*0A
$GPRMC,084745.00,A,5223.7094,N,00214.0131,W,017.4,359.5,200708,06.2,W,A*06
$GPRMC,084746.00,A,5223.7144,N,00214.0143,W,018.2,347.0,200708,06.2,W,A*0F

So you can see how useful it is to have the start of every data field in a fixed position and not have to worry about searching for commas.

 

[jmumby]

Cool, I just got one of those, haven't had time to play with it yet. Glad to hear it is fixed length!

 

[oldjoe]

NEMA GPS Message for the GPS Tutorial

Hi jmumby, technical and Jeremy

All the NEMA Messages are fixed length data/format and all NEMA Message are ASC II Characters rathere than number values, so conversions are needed.

I Googled NEMA and things sure have changed since I last used them!!! I could not locate their GPS Navigation Message Format Specification although I know there is one. I have used it before.

I have attached the format spec for GGA (the one I used the most), GLL and RMC (the smallest of the 3).

When I used GPS for guidance on Robots, I used GGA and only the LAT and LON part of the Message plus some of the flags.

Also the Heading and Speed in these GPS messages is no good for guiding Robots!!! Use a KVH Flux Gate Compass for heading and calculate speed from change in LAT and LONG, you will have better results with your Robot.

For LAT and LONG to feet, one minute of position at the equator is about 6 thousand feet. One second of position is roughly about 100 feet.

Also you are going to need to keep the degrees values so you can operate more different places.

First after initalizing the UART, I would send the RS-232 command to the GPS to "shut up" (or all messages off), then I would command the GPS to send GGA once per second and ZDS once every 10 seconds.

Next I would define 4 double length word variables; like: lat, oldlat, long, oldlong.

Next I started parsing the NEMA Message, since it is fixed length one can jump over characters, the numbers are zero filled if necessary and are all ASC. The time is in seconds into the week and is no good for much, so skip time and skip the header (other to check that it is the right message), next about the 15 and 16 character is degrees, multiply them by 60, and add them to the lat variable. Next get the next 6 characters, 17 to 23 and add them to the lat variable. Now multiply the lat variable by 2 raised to the 14 power (multiplying by 2 raised to a power is always fastest) this is 14 shifts of the number to the left. Now subtract lat from oldlat, the difference should be a number much less than a word variable.

Do the same thing with long.

Now call the subroutine to get minutes into feet. lat and long will be needed for this calculation.

After returning from subroutine, set oldlat equal to lat and oldlong equal to long.

Now these calculations are done every second and feet per second is speed!!!

If you are running my: "Yellow Brick Road" program, you have the Lat and Long of a new waypoint given every second. The distance in feet from where you are now to the waypoint is the commanded speed of the robot. Form a ratio of the vector in the direction of the waypoint to the cross-axis vector to the waypoint and the is the heading the robot should go. There is even a subroutine that can change this ratio into the duty cycle for a 50msec RC Servo to control steering. BTW an automotive cruse-control from the automotive store makes the best speed control.

Anyway loop until the Robot has finished doing its thing.

Anyway, with differential correction, it should be possible to get a GPS Solution to within 8 feet of where you actually are, with the carrier phase tracking that the Canadian Marconi GPS uses you should be able to get within 5 feet and with RTK differential correctrion it is possible to get a solution down to an inch ( 3 cm).

Also I hope the files I uploaded stay attached, I tried to send .jpg of some of the NEMA formats.

oldjoe

 

[MPep]

@OldJoe,

Please be careful when referring to NMEA (|National Marine Electronics Association, National being the USA), and NEMA (National Electrical Manufacturers Association).

In Marine Electronics circles, 'everybody' says "NEMA" when in actual fact they mean NMEA.


As far as it goes though, I have used a Navman Jupiter 20 module, now superseded by the Jupiter 30. This has a variable length data sentence which caused a few headaches when trying to parse data.

I am guessing that there will be no one single unit that will suit everybody.
The only recommendation would be to purchase a unit you like the look of, and be prepared for long periods of sitting at the computer looking at Hyperterminal, or whatever you use.
And yes, battery back-up is a must! Once the initial acquisition has been made, subsequent acquisitions should take only a few seconds usually.

 

[MFB]

Grand Idea Studio developed a neat GPS receiver board for Parallax that uses a dedicated SX micro to interface with the Basic Stamp serial port. When the board is operating in ‘smart mode' the Stamp is able to request that only selected information be sent from the receiver. Thus taking the parsing and formatting workload load away from the Stamp.

Of course, the background serial feature should make this unnecessary for PICAXE X1 chips, not to mention the X2 versions (is it the end of summer yet?).

 

[Jeremy Leach]

Interesting. I was thinking along these lines too ... that some clever person needs to develop a small, generic, 'picaxe GPS board' with a dedicated 'clever' chip that translates the GPS standard outputs into a format that picaxes can understand. Maybe with two types of messages serially output each second ( or faster). One a 'short' format, with the essentials that can easily be read by even an 08M ...

"Short"
SpeedLSB
SpeedMSB
DirectionLSB
DirectionMSB
LatitudeLSB
LatitudeMSB
LongitudeLSB
LongitudeMSB

Then a longer format message with more detail.

Each message is always fixed length, with the "short" or "Long" header that could be picked out with Serin qualifiers. The data has already been pre-processed into easy to use values that even a novice can make use of straight away, using even an 08M.

Or maybe there's a way of serially requesting the values.
Or maybe there's some i2c solution where you could interrogate the values.

Could even have a picaxe as the 'clever chip'. I don't think an 08M would be up to it, but maybe an 18X. It would just receive from GPS module, crunch data into 'picaxe format', output the short and long messages and repeat.

 

[MFB]

Its certainly true that the cost of a PICAXE for dedicated pre-processing of sentences would be an acceptable overhead, compared with the cost of a GPS receiver, but a 28X1 running at 16 MHz would probably be required. Would it be worth Rev-Ed introducing a product based on this approach?

 

[oldjoe]

Use NMEA GPS Messages for PICAXE/GPS Tutorial

Thanks MPep. That explains why I could not find the formats I was Googling for. I should have said NMEA and not NEMA!!!

So my advice to all that are interested in GPS is to Google on NMEA and you will get a lot of choices, pick: NMEA Data, and you will see all the GPS NMEA formats.


HI technical, I strongly recommend that the GPS NMEA format RMB be used for any PICAXE/GPS Tutorial.

1. All the GPS I have ever tested support the NMEA Messages and I have tested all the Manufacturere and Models that advertize in GPS World.

2. Not all Brands and Models support all NMEA sentences, but most support most NMEA sentences.

3. All NMEA sentences are fixed format starting with a $ and ending with a CR/LF. The MNEA sentence are ONLY in ASC II Characters.

4. All the GPS that I tested, which have 2 or more serial ports, had the ability to change baud rate and turn their messages OFF and ON on their port 1.

5. Since I was interested in sending Differential Correction into the GPS's port 2 and getting Nav solutions out of the GPS port1, I spent most of my time on the GPS that had 2 or more ports and advertized good accuracy numbers.

6. For Self Propelled Robotics to work well I need Nav solutions down to a foot. I found plenty of GPS that would give me accuract to 8 feet and a few that would give me accuracy to an inch.

7. To deal with this I had to create 4 variables the were 32 bits long as part of my software program, to get the accuracy I needed. I had to convert everything into MINUTES of position. This ment that I had to multiply, to get the fractions of minutes to intergers. Multiplying by a power of 2 is the same as a left shift of the number in a register, that is an important trick that makes the processing possible.

8. Next, do the subtraction of current minutes from the minutes of a second ago, the results is delta_lat and delta_lon which are a small number and can be a byte variable.

9. Now, convert minutes into feet, this should be a word variable just to be safe. Minutes to feet conversion factor changes a lot with Longitude and a little with Latitude.

10. Also DO NOT use GPS Heading nor Speed, they are not good enough for Robotics. Calculate Speed from feet moved in last second. Feet per second is speed. Also calculate heading by forming vectors using delta_lat and delta_lon. Also for steering, calculate the delta_lat and delta_lon to next waypoint and form the vector. There is a trick that will convert delts_lat and delta_lon directly to PWM commands for RC Servos. Make an exception handler for when speed is zero.

11. Don't use trig functions. They either take too much memory or use too much time. If you are interested ask me how to do it.


Anyway use the NMEA format RMB and a PICAXE/GPS Tutorial is possibe that will fit just about any GPS. For the PICAXE it is just a RS-232 serial stream that is not too big nor too fast and the rest is in PICAXE software.

oldjoe