Smart front-end interface for GPS?

Two topics that appeared regularly on this forum are how to interface low power/cost wireless modules and how to extract data from the serial output of GPS receivers. The introduction of the NKM2401 chip, and the new rfin/out commands, has made the former task much easer but GPS parsing continues to be a challenge for some applications. For example, if a PICAXE was continuously sampling analog inputs, at tens of Hz, whilst also accepting serial GPS data at a much lower rate.

The current thread about using GPS to steer a boat generated a number of suggestions about off-loading the parsing and serial buffering tasks to a second PICAXE, possibly the new 08M2. Although I have used a 08M writing data to the scratchpad of a 28X2 (that was busy logging analog measurements) this task was relatively easy, because the 28X2 could request data from the 08M. However, handshaking for the GPS application would be more complex because the two systems are not synchronised.

Would it be possible/worthwhile developing code for a smart front-end that could do for GPS interfacing what the NKM2401 has already done for low-power wireless applications and what would be the specification ?

The parsing etc, I could see would be easily handled by an 08M2, outputing the static information as cut down strings to a serial (or I2C) connection. You could deal with autobaud, programming the output frequency of the various strings etc.

However I see the real benfit of a front-end as the ability to be able to calculate, at the most basic, the distance and heading between two sets of Latitude and Longtitude, as this opens up all sorts of tracking, guidance, autonomous control of robots (even boats!) distance travelled and similar applications. Easily handled by a native PIC, circa 16K flash maybe, either in a compiled language or there are open source floating point libraries for PIC out there.

Once you start getting into real-time calculations for guidance it might be better to look at using an Ardunio, which now seems to be something of a standard for DIY drone work. I was really thinking along the lines of the front-end selecting sentences and parameters from the GPS output and transmitting packets of data when requested by the master PICAXE. Which would reduce the serial coms load and overcome the lack of sync between the incoming GPS data and the operation of the master PICAXE. Thses basic tasks would be common to a wide range of instrumentation and control applications.

I've seen a uM-FPU floating point chip used to interface a GPS. It included distance and angle computations from the current location to a specified lat/long and used an interrupt on a PICAXE to initiate a request the next lat/long along a route or to get a reading from a digital compass (except for the GPS data, all comms are via I2C).

I can't give more info because of an NDA.

John

I would have thought this was quite easy for a good PIC writer.

Dippy said:

I would have thought this was quite easy for a good PIC writer.

Click to expand...

Something like this?

MPep said:

Something like this?

Click to expand...

Thats the home page, what in particular are you referring to ?

srnet said:

The parsing etc, I could see would be easily handled by an 08M2, outputing the static information as cut down strings to a serial (or I2C) connection. You could deal with autobaud, programming the output frequency of the various strings etc.

However I see the real benfit of a front-end as the ability to be able to calculate, at the most basic, the distance and heading between two sets of Latitude and Longtitude, as this opens up all sorts of tracking, guidance, autonomous control of robots (even boats!) distance travelled and similar applications.

Click to expand...

I think this is key; defining what any "GPS Engine" will do. Parsing NMEA sentences seems a given but what does it need to deliver as output data or need to calculate, what control and settings must it accept. On top of that there's the means and format of data output and input to consider.

There will be a range of functionality from necessary and mandatory to advanced ( would like or nice to have ) but having a specification would normally precede the how to actually do it discussion.

The main reason co-processor engines ( GPS or anything else ) don't exist is probably that no one agrees on what they must do. There's no specification or agreement, so no engine appears and people end up implementing their own versions as needed. Of course, even where co-processing engines exist ( such as uM-FPU, NKM2401, FRM010 ), people may still choose to do it themselves with their main processor because the engine is perceived as too costly or an undesired extra component.

I totally agree on the difficulty of arriving at a useful specification but thought it worth trying to at least to get the ball rolling. However, it may well be that "no one agrees on what they must do".

Maybe the follow attempt by Parallax could act as a starting point for arriving at a specification for a PICAXE version? http://www.parallax.com/StoreSearchR...6/Default.aspx

After a bit more searching here is a detailed description of the Parallax GPS board. It seems it's the Smart Mode that uses the 'engine'.

http://www.parallax.com/Portals/0/Downloads/docs/prod/acc/GPSManualV2.0.pdf

Looks like an 08M2 should be able to offer much the same features.

I think hippy has hit the nail on the head.

Any decent PIC codester could write a lump to do anything you would want to do.
Writing firmware to respond to commands and do calcs is easy - albeit long-winded.

I think the best way is to do what Parallax have done; commit a micro to a specific GPS unit.
That would be my preferred route if I had a choice.
Whilst the code is , other than time, no real hardship, I can foresee the possibility of issues when a firmware chip is bought to use with ANYOTHER brand GPS unit.
The slightest timing/format problem could throw it all out resulting in megawhinging.

Obviously if there is any serious math/speed requirements then that may be tricky with PICAXE, but as I've never wrestled with GPS I leave that to more experienced noggins.

And, as hippy implies (I think), how many here would pay a fiver or more for such a firmware chip?
Most people would sooner spend 3 weeks and £x in bits and postage developing their own.

Dippy said:

Most people would sooner spend 3 weeks and £x in bits and postage developing their own.

Click to expand...

Now aint that the truth.

Oh well, I think the consensus is that this idea is a non-starter but no harm in asking. Maybe its time for the long overdue GPS tutorial from Rev-Ed, that will help us develop our own interface code.

Its a good idea, perhaps it just needs an individual to do it and present it as is, sure people would find workarounds for perceived limitations.

The issue of differances between GPS modules is real however, especially as the firmware added to the native GPS chipset varies.

I have 3 GPS modules;

A SRFIII, that defaults to 4800Baud, and can fairly easily be changed.

A EagleTree GPS (core chipset is Mediatek 3329) that defaults to 38400 and needs a utility to change it, but the only other speed it runs at is 19200.

A Mediatek 3329 from DIYDrones, thats supposed to have "custom and exclusive "DIYDrones" firmware that allows the unit to output an efficient and very compressed binary protocol" well it may have but it powers up at 9600baud in NMEA mode and took a fair bit of persuasion to switch to 2400baud. You have to send a null CR\LF, wait a bit and then send the MTK command. All this because this module does not have the backup battery.

MFB said:

Oh well, I think the consensus is that this idea is a non-starter but no harm in asking.

Click to expand...

I actually thought we were heading in the right direction, the 'Smart Mode' giving a good basis of where to start from. I'd suggest something which reads NMEA sentences, parses them into separate data entities and allows a PICAXE to extract that data - perhaps even regenerate NMEA sentences in a fixed format, or invent 'additional NMEA sentences' with just the data which would be useful.

That gives a common foundation to build on and add to. Whether it could be a viable or saleable product doesn't prevent a specification being formed, identifying what's useful and what's less so, even producing proof of concept code.

I've never used GPS, have no idea what would be useful for GPS users and it really needs a 'champion' to move any specification / design forward, much like nick12ab is doing with graphic LCD control, westaust55 for 1-wire interfacing, kranenborg‎ for serial power networks, slimplynth‎ with UAV's - and apologies to anyone doing similar in fields which haven't immediately leapt to mind.

MFB said:

Maybe its time for the long overdue GPS tutorial from Rev-Ed, that will help us develop our own interface code.

Click to expand...

I'm not sure a GPS tutorial would give much more than people already know; NMEA sentences come out, they can be parsed and data pulled from them. IMO it's really experts in the field, or people enthused and willing to head that way, who turn 'here's a simple example' into something which is more 'here's an application which puts that into practice' and makes what can be done practical and useful.

Rather than a non-starter I think it's a good idea; similar to using a PICAXE or NKM2401 to process RF to make life easier for the main program at the very least.

I'll have a go at being a GPS co-processor (or whatever we decide to call it) champion in order to progress towards a specification / development. The most suitable PICAXE would probably be the be 08M2 and these will ordered ASAP. In the mean time I will look out some proven 08M code that was used to parse GPS data for display on a PC, together with code from a separate project that used a slave 08M to send analog measurements to the scratchpad of a rather busy 28X2. Hopefully, posting a combination of these techniques will lead to some useful suggestions/contributions.

Excellent, start the ball rolling.

Rather than wait for the 08M2 chips, I thought it better to get things moving on the ‘GPS slave’ front with the following 18M2 code. In this simple example the slave response to a request from the ‘master’ by serially transmitting latitude, longitude and altitude data from the GPGGA sentence. The master will receive this packet of data within 8mS of issuing a request and is then be free for other processing tasks. However, even this distraction time can be further reduced if the master uses its scratchpad to receive data packets in the background. The inherent lack of synchronisation between the raw GPS input to the slave limits the request rate from the master to less than that the GPS update rate (typically 1.5 seconds request rate for 1 second update). Alternative code could be used that allowed the slave to free-run and the master to be interrupted by the slave busy output.

Everything is really up for discussion at this stage. For example, would I2C offer advantages over asynchronous serial communication between the slave and master? Is there any way that a library of proven masks (e.g. patterns of ‘dummy b0’ writes to mask out unwanted data from a selected GPS sentence) could be assembled for different versions of receivers?


‘Example 18M2 GPS Slave code.

symbol busy_out= C.7
symbol request_in= pinC.0
symbol GPS_in= pinC.1

setfreq m32
high busy_out

trigger:
if request_in = 1 then trigger 'Wait for data request from Master
low busy_out 'Inform Master that Slave is busy.
Sertxd (b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13,b14,b15,b16,b17,b18,b19,b20,b21,cr)
'Send data to master at 38400bps.

serin GPS_in, N4800_32,("$GPGGA,"),b0,b0,b0,b0,b0,b0,b0,b1,b2,b0,b3,b4,b5,b6,b0,b7,
b8,b9,b0,b0,b0,b10,b11,b12,b13,b14,b0,b15,b16,b17,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b0,b18,b19,b20,b0,b21
'Mask out unwanted characters from 'GPGGA sentence using 'dummy bo' writes.

high busy_out 'Inform Master that Slave is not busy.
goto trigger 'Get ready for next data request

Hi MFB
How did you go with your "GPS slave" project?
I'd like to do something similar - I want to grab latitude/longitude/speed/date/time from a GPS and then send it and some ADC measurements out the serial port.
I want to send the data out at the GPS rate of 5Hz, so whenever the GPS slave has read the data, then read the ADC's + do some calculations, the transmit the ADC + GPS data out via serial.
Does that sound feasible?

I have not done any more work on this project since posting the above demo code, which could form the basis for your application. However, at a 5Hz update rate the master may not have much time left for "+ do some calculations" before transmission. Could these calculations be left to the PC end of the link?

I will look again at the GPS slave again soon, probably using I2C to replace the UART link to the master.

Similar solution to same challenge

At a risk of being seen to promote an alternative product, here is a link to how it can be done using MaxiMite.
This code may assist in working out how to handle some of the GPS strings
http://www.thebackshed.com/forum/forum_posts.asp?TID=4435&PN=1
Enjoy

Thanks - the calcs are to convert the raw ADC values to meaningful units - I prefer to do them in the PICAXE, but yes, they could be done in the PC afterward.
My exisiting project uses a 40X2 at 8MHz to read 7 ADC's, convert them to useful units then write them to EEPROM. It can do that at a bit more than 5Hz.
When I want to get the data out, I read it from EEPROM and then send it to the serial port at 115kbaud, but it takes about as long to send the data as it does to collect it, so its a bit slow.
For this next project idea, I want to dispense with the EEPROM and just send the data straight to the serial port and have a PC or pocketPC collect the data - that means I have to do the calcs and then transmit before the next GPS reading comes in....

I just stumbled across this thread.

I've done some work on moving code that I had written a long time ago from 68HC11 to PICAXE - specifically the 20M2 as an exercise to see if it can be done! This is 'Go Home' for RC plane/tricopter/quad camera platforms so that on loss of signal it'll come back (wonder if the CIA would be interested for their drones )

The routines so far are Parse Sentences, Calculate Distance and Bearing from start (no fpu involved) and interact with the RC receiver and servos. Speed is not a significant issue for me as the onboard gyros and accs maintain stability between updates.

I'd be interested in any cooperative effort to implement PICAXE/GPS support.

Well I would certainly be interested in PICAXE code that would calculate direction and distance.

I have the telemetry on the HOPE RF modules working on my lost model locator and a portable telemetry receiver being built.

So I dont expect it to be difficult to get data back from a model in flight, information such as GPS location and altitude.
The intention is to add a GPS to the LML and have it transmit the last known GPS position (and current altitude).

Displaying the models current distance, direction and altitude on the OLED would be kind of useful.

srnet said:

Well I would certainly be interested in PICAXE code that would calculate direction and distance.

Click to expand...

Can you define your requirements?

The code was originally written to provide enhanced features to my 1998 vintage Garmin.

To conserve resources my current routines are limited to distances of 32.7 Km, accuracy about 0.2% close in, degrades somewhat beyond 15Km or so, bearing is good to about 0.5 degree.
I also limit myself to north / west coordinates since I'm at 42N, 71W.

I'm not sure I'm going to be able to do much on this for the next couple of weeks - missus has other plans!

Distance, say 200M to 5kM.

Bearing, to about half a degree, it difficult to land navigate with a compass more accuratly than this.

Northern hemisphere.

As we have the 0deg meridian in the UK, it would need to cope with W\E.

As I have mentioned before, I have it working in Mikrobasic (my 18F26K22 beacon is in the picture) but its beyond my limited maths to work it out in PICAXE basic.

Sorry, duplicate

srnet said:

As I have mentioned before, I have it working in Mikrobasic (my 18F26K22 beacon is in the picture) but its beyond my limited maths to work it out in PICAXE basic.

Click to expand...

The maths really not bad
The real difficulty is the limited number of variables and keeping track of them!

Armp said:

The real difficulty is the limited number of variables and keeping track of them!

Click to expand...

Sure.

Whilst I have use meaningful variable names to make the code easier to understand, in the application there are only about 10 bytes worth of variables that must survive across all routines, that number could likely be reduced further.

So whilst I currently keep them seperate, there is considerable scope for sharing variables amongst the various routines.

How many variables are needed ?

srnet said:

Whilst I have use meaningful variable names to make the code easier to understand, in the application there are only about 10 bytes worth of variables that must survive across all routines, that number could likely be reduced further.

So whilst I currently keep them separate, there is considerable scope for sharing variables amongst the various routines.

Click to expand...

I'm used to writing 'potted' routines - ie pass them parameters when called, return the answer, use only local variables.
ie Dist = CalcDist (Lat1,Lon1,Lat2,Lon2)

It's not a problem, just a layer of organization I've not had to handle in the last 30yrs!

Not knocking the PICAXE, but it is 'different' and I'm still learning what works best for me.

srnet said:

How many variables are needed ?

Click to expand...

Not many for these routines.

For bearing and distance I get lat1, lon1, lat2, lon2 from GPS. Each can require 2 words to resolve 1/1000 of a minute, which is my basic unit. This corresponds to 1.853 metres. I also often need altitude and heading.

I store all these as static variables in RAM, and swap them in and out of w0 - w19 as needed.

I think you're using the 28X2 so you have more wx variables to play with, and the scratchpad?

I'll tidy up my code, add comments(!!) and post it when I can... This won't necessarily be finished code, rather algorithms and techniques, but I'm sure you'll be able to determine if any of this is of use to you, and hopefully provide some feedback.

BTW I do heading and bearing relative to true north. Mag declination here is about 14 degrees!

Armp said:

BTW I do heading and bearing relative to true north. Mag declination here is about 14 degrees!

Click to expand...

Well I know about Magnetic Declination, although you need to refer to magnaetic variation mostly othewise people dont know what you are on about it.

Its around 2.75degrees West at the moment where I am, so still important if you are going to find what you are looking for.

I teach mountain navigation to Scouts and leaders, and I tell you if mention magnetic declination, the blank looks you get.

Its not hleped by the Scouts own resources, see here;

http://www.scoutingresources.org.uk/compass/compass_magvar.html

srnet said:

As we have the 0deg meridian in the UK, it would need to cope with W\E.

As I have mentioned before, I have it working in Mikrobasic (my 18F26K22 beacon is in the picture) but its beyond my limited maths to work it out in PICAXE basic.

Click to expand...

Since there doesn't seem to be any general interest in a joint effort to develop routines at this time, the easiest solution may be just to let me look at the relevant section of your code and suggest how to do the maths? You can then write the PICAXE code if you choose, as you have far more experience than I do.

BTW - Did you implement the ATAN2 bearing equation in mikrobasic?

Working on the telemetry part of the project at the moment, I have the 18f26K22\Mikrobasic version able to send text messages to the just built 28X2 telemetry receiver. Just about to change it to allow the the numbers for Altitude, direction and distance to be sent to the receiver so that I can do some range tests. I will fly my plane away and high until the messages stop. Not tried the ATAN2 as yet, but I do have a note to test it.

At the moment the GPS equiped LML is the 18f26K22\Mikrobasic version, I need to build another PCB for a PICAXE 28X2 version with a header to plug the GPS into. That will take another 2 weeks or so. I have the PICAXE code for the LML working, but have yet to work on the GPS parsing routines.

I've finished transferring the code to 20M2, and now looking to replace my ancient Garmin GPS12 'brick' (260gms) with a modestly price module. I'd like low weight, preferably 3.3v as that's what everything else runs on, 4800 baud and not much else.

I see many modules on Sparkfun and other sites, but would appreciate any input to narrow the choice. Is there a preferred solution?

The GPS parsing code (in Mikrobasic) I have will run for a SIRFIII and a Mediatek MTK3329, without modification. Both operate on 3V without a problem. Both these modules are available as a single unit with integrated antenna.

The SRFIII is fairly common and cheap, but a fair bit bigger than the Mediatek. The Mediatek is the module used in the Eagle Tree logger which you may have seen. I have used my Eagle tree GPS, the GPS strings parse OK, but the firmware on the Eagle tree GPS does not allow the baud rate to be changed below 19200, its used in the Eagle tree system at 38400.

You can get a Mediatek Module from DIYdrones and others;

https://store.diydrones.com/ProductDetails.asp?ProductCode=MT3329-02

The module has no battery, so no hot start, and it powers up at 38400 baud, but the code I have sends out a command at power up to change it down to 4800 baud. I slowed it down like that so that the Mikrobasic code could read in a character at a time and still detect timeouts etc if the GPS became detached. I guess I could have written some interrupt driven code to achieve the same thing. PICAXE basic would not have the same issue I believe with bacjkground receive, although I have not tried it.

srnet said:

The GPS parsing code (in Mikrobasic) I have will run for a SIRFIII and a Mediatek MTK3329, without modification. Both operate on 3V without a problem. Both these modules are available as a single unit with integrated antenna.

The SRFIII is fairly common and cheap, but a fair bit bigger than the Mediatek. The Mediatek is the module used in the Eagle Tree logger which you may have seen. I have used my Eagle tree GPS, the GPS strings parse OK, but the firmware on the Eagle tree GPS does not allow the baud rate to be changed below 19200, its used in the Eagle tree system at 38400.

You can get a Mediatek Module from DIYdrones and others;

https://store.diydrones.com/ProductDetails.asp?ProductCode=MT3329-02

The module has no battery, so no hot start, and it powers up at 38400 baud, but the code I have sends out a command at power up to change it down to 4800 baud. I slowed it down like that so that the Mikrobasic code could read in a character at a time and still detect timeouts etc if the GPS became detached. I guess I could have written some interrupt driven code to achieve the same thing. PICAXE basic would not have the same issue I believe with bacjkground receive, although I have not tried it.

Click to expand...

For me size is an issue (!) so the Mediatek is what I prefer to use.

Thanks for the input - that looks like a very good candidate, especially as you're available to advise when I get stuck