GPS VPN1513 extended Firmware V 2.1

msrobots · 2012-03-15 19:45

This is a offspin of some other project i am working on.

So i needed a GPS-unit. And had some issues with the existing firmware.

After looking thru the source i decided for a major rewrite. So i cannabalized the existing firmware and reorganized it and rewrote some parts completely.

major changes are
- fixed stack-issue of original firmware
- fixed checksum-issue ... chksum now used
- changed use of LOCKS to PARALLAX Standard

- use Tim Moores/Duane Designs/Tracy Allens fullDuplexSerial4port for GPS (port 0) 4800 baud pin 18
and up to 3 serial cmd-connections (2 used)
(port 1) serial one-pin 9600 baud pin 17 like original firmware
(port 2) serial fullduplex 115200 baud pin 31,30 (easy testing in PST)
(port 3) commented out - unused

- added cmd Speed_DegKm ($0B) (format like old FW)
- added cmd Geoid_Height_Deg ($0C) (format like old FW)

- added all cmds in prop-format (RAW numbers LONG) ($20-$2D) (easy use with prop)
- added all cmds in string-format (RAW strings) ("0"-"D") (easy testing in PST)

and i put some documentation in to describethe public methods and values

here now the newer Version 2.1

VPN1513-V-2-1.zip

enjoy!
Mike

Publison · 2012-03-16 09:35

Mike,

Thanks for the great re-write! Great job!

I hope to get the new VPN1513 after I have deployed my two old Parallax units.

Jim

msrobots · 2012-03-16 13:03

Thanks Jim. This GPS--Unit is super.
even inside of the house I get perfect readings,

I am not sure yet but I think I am able to SEND commands to the unit, to switch the baudrate between Propeller and GPS higher then 4800.

That would speed up things even more. Still playing around witth it ....

Mike

dflynn5656 · 2012-03-18 18:09

Mike - this looks impressive. I am new to the propeller and to the VPN1513. Is there native code in the GPS outta the box that i might over write adding your better code? Or is it just a choice of their code or your IMPROVED code. Also - All I seek to do is get my cars speed off this unit. I assume the knots over ground is Speed_Deg? I'd love to discuss your creation code wise here...if you have more time.

David

Martin_H · 2012-03-19 12:44

This GPS looks interesting. Although it includes an external antenna, does it also have a patch antenna? I'm asking because the antenna cable is long which would makes it awkward in tight spots and add weight to small robots. I'm thinking of adding a GPS to my new 4x4 to try some outdoors navigation challenges, but it is not a big robot. Some GPS's will tell you the current time, can it do that sort of thing?

My crazy idea is adding an I2C compass to this and updating the firmware for a combination compass/GPS/Navigation planner. Basically a robot version of a Garmin.

msrobots · 2012-03-19 14:19

Hi David,

yes - there is a existing code preinstalled in that GPS. I took that code apart and put it together again. First to understand it and second because it had some issues needed to adress. (you can download the original firmware on the shop-page of the gps at parallax store)

Speed_deg is speed over ground in 1/10 knots and speed_degKM speed over ground in 1/10 KM/h.

This are the original versions so they are basically build for a BASIC-Stamp. so the values are clipped to fit into 2-Byte words in MSB frornat, not like in the propeller where the lower byte comes first.

Long_Speed is in propeller long format (4-bytes LSB first) and more precise since not clipped. it is in 1/100 of knots aka nautic miles/h
Long_SpeedKM is also in Propellerformat but still 1/10 km/h - that is the RAW value of the gps-unit.

and yes my code is a replacement for the original firmware- doing all it does but delivering the values not just in BASIC-Stamp format but also as string and as longs direct usable by Propellers.

the gps has the pin-holes for a prop-plug just solder headers in and you can program the propeller-chip on it. on the same pins you can communicate wit the gps.

the original works with 9600 baud on pin 13 open collector bi-directional like BASIC-Stamps do
the improved version is doing that too - but also on pin 31/30 (propplug) there with 115200 baud fullduplex serial.

and Hi Martin_H.

Yes the gps also has a realtime-clock delivering date and time - alas it is UTC date and time so you have to add/subtract the timedifference to your local time

And as far as I see there is just this one antenna and that wire is LONG (still never unrolled but i guess 6 foot or so) .

The propeller on the gps has still lots of space/pins/cogs so you can add compass,accellerometer and such - i am planning to do that also for use with my groundbasesd rover/wheelchair project.

this gps is kind of funny - geek wise - a ARM7 with 4-Mbit flash contolling the gps delivers serial data to a Propeller-chip (32kbit) to be delivert to a BASIC-Stamp or another propeller... what a concept.

Mike

msrobots · 2012-03-19 16:03

The VPN1513 GPS module is a bummer. You get a lot for the money.
First the looks. Small, square, doublesided(!) full with chips and holes to solder for all propeller-pins. All with pinnumber,not like the quickstart. Beautifull.
Then the works. Even inside the building perfect connection and readings. Hm. As stated above the wire to the antenna is long.
the ARM7 on the bord talks to the Satelites and shares 1 pin with the prop to transfer NEMA-Data serial.
another pin is used to switch the output to RAW-data, then the prop onbord is unemployed and free.
but in smart-mode (standard) the prop has still all other pins free to use by yourself.

Now a little about the code.

In the original firmware is a object called "GPS_Str_NMEA_Lite_lawKmH" some stripped-down version of something else as marked by "Lite" in the name. I had some issues with that.
It took me a while to understand the intention of the programmer why he/she was "missusing" the LOCKS. Basically the names did it "semID_Refresh" as name for the LOCK and "Wait_For_New_Data_Decoded " in front of all access-methods.
The old firmware uses LOCKS to ensure that every READ will WAIT UNTIL NEW DATA COMES FROM THE GPS.
That slows things down.
The firmware talks to the gps arm over a serial 1 wire connection at 4800 baud.
In the comments FullDuplexSerial as object is mentioned but SimpleSerial used. To save a cog. And to loose any buffering.
because buffering did not work since the calculated checksum on the nema-sentences was not working so the checksum gets ignored and even a faulty nema-sentence gets written to the string-output-fields.
and then the command-loop in the main firmware...

PRI GetCommand:order  |chr,head[4],headaddr  headaddr:=@head
  repeat  until ((chr:=trans.RX)=="!") 
  
  repeat 3
    byte[headaddr++]:=trans.RX
  byte[headaddr]~
  
  if strcomp(@head,@strhead)
     order:=trans.rx
  else
     GetCommand

you NEVER do that. THIS WILL KILL YOUR STACK

That where the issues to start with.

I need some coffee and will continue soon ....

msrobots · 2012-03-19 16:54

... here we go. So I decided on rewriting this. With some goals to archive besides just fixing my issues.
Like a lot products of PARALLAX this one is build to connect to a BASIC-Stamp. Hence that 5 Volt Onewire thing like a servo.
and the unusual byteorder, and 16-bit values anyways.
This is fine with me but its a PROPELLER so I need my PST and pin 30/31 etc.

So the archived goals are:
- fixing above issues
- keeping all 'old' commands, thus full compatible with old firmware
- adding a second serial interface at 31/30 at 115200 baud
- adding all command as longs in propeller-format
- adding all commands as strings (easy interface to PST for testing - just type !GPS0 for version or !GPS3 for time etc)
on the list but not archieved
- switching communication to arm/gps to higher baudrate as 4800

I put everytthing in one file (ex. pcFullDuplexSerial4FC) to have direct access to the raw-values.
The main gps_loop decodes the nema-sentences and writes them (using LOCKS in normal fashion) into the DAT section.
In 3 Versions... as string ... as long for propeller ... coded like before for BASIC-Stamp.
The CMD_loop accepts cmds on both ports and delivers the values out of the DAT section (using LOCKS in normal fashion)
All cmds are also available as public Methods and reading also the DAT section (using LOCKS in normal fashion)

If you do not need the serial interfaces you can easy comment that part out.
If you do not need the public Methods you can easy comment that part out.

enjoy!

Mike

Martin_H · 2012-03-21 08:16

A thought just occurred to me I have a Propeller Backpack. With some tweaks could I get this firmware to run on it and use this Parallax GPS?

If I http://www.parallax.com/StoreSearchResults/tabid/768/txtSearch/gps/List/0/SortField/4/ProductID/644/Default.aspx

That way I won't have to deal with that cable which would likely take up too much space.

msrobots · 2012-03-21 16:15

Hi Martin,

I looked at it and I am pretty sure it will work perfect. It is the same Module as on the VPN1513. So the code will work..

enjoy!

Mike

Martin_H · 2012-03-21 17:08

Great thanks for looking into this.

dflynn5656 · 2012-03-22 12:47

Mike (MSRobots),

I called Parallax tech support yesterday and spoke to Kevin, who is also working with the VPN1513. I suggested he check out your code - which he did with interest.

I have a project that just needs the VPN1513 to be standalone - w/o basic stamp 2. And....Why would you want a stamp - when you have a propeller????

I DID solder in the 4 pins and apply a prop plug, loaded your code, and will now try to get your better firmware to work in my project - that should get my cars speed and trigger a pin 2 high (for 15 seconds) anytime you exceed 30 knots, if pin 1 is already high. Looks like I need to write a custom Method.

Trouble is, I haven't yet figured out how to echo Propeller variable out to the Parallax serial terminal. In fact - with the serial terminal running, I see no life from the GPS - even the the ready light shows it clearly working. Since it now appears that you are the GURU on everything VPN1513 - may I ask - how can I see what the GPS is doing - w/o a basic stamp?

Thanks in advance - David

msrobots · 2012-03-23 01:47

Hi David,

If you put my new firmware on the vpn1513 module then you have te serial interface on the buildin header like iin the description (pdf).
You also have a cmd-serial teminal on the pins of the propplug.

So connect propplug and load my new firmware and then start the Parallax Serial Terminal Program.- no stamp needed ...

115200 baud.

then you can type in some commands and see the answer in the terminalprogram.

so just type !GPS3 and you will get the time !GPS4 will give you date and !GPS5 gives lattitude !GPS6 longitude !GPS8 speed over ground.

Simple to test function. ( hm. the cmds ... UPPERCASE is it lowercase will not work)

for your own projekt - just include my object and run your own program on the prop onboard the gps - you have still 28+ pins unused on the gps-module and half of the cogs are free also - still lots of space there.

I hope this helps -

enjoy!

Mike

msrobots · 2012-03-23 03:03

Hi David ... again ...

the changes you need for your projekt migt be simple. In my source-code pretty much in the beginning you find this

PRI LED_Cog_Loop             ' watchdog ... sort of
    dira[_led]:=1            ' LED output
     
    repeat
      if longValidDbg           ' true ok ? no need for lock ?
        outa[_led]:=1        ' solid on
       ' !outa[_led]          ' blink slow
       ' waitcnt(clkfreq+cnt) ' save energie
       ' waitcnt(clkfreq+cnt) ' save energie
        waitcnt(clkfreq+cnt) ' save energie
        waitcnt(clkfreq+cnt) ' save energie
      else  
        !outa[_led]          ' false no valid gps data
        waitcnt(clkfreq/2+cnt)  ' blink faster

this runs in an own (SPIN) cog and basically takes care about the blinking and nonblinking red LED.
put something there like this ... (not tested but does about what you said)

PRI LED_Cog_Loop[COLOR=#0000FF] | myspeed            [/COLOR]' watchdog ... sort of
    dira[_led]:=1            ' LED output
   
[COLOR=#0000FF]    dira[1]:=0    ' pin 1 input
[/COLOR]    [COLOR=#0000FF]dira[2]:=1   ' pin 2 output
[/COLOR]  [COLOR=#0000FF]  outa[2]:=0                     ' your pin 2 LOW
[/COLOR]     
    repeat
      if longValidDbg           ' true ok ? no need for lock ?
        outa[_led]:=1        ' solid on

[COLOR=#0000FF]        if ina[1]==1         '  your pin1 high
          repeat while(LOCKSET(NEMAsemID - 1))      ' wait for lock (until set returns false)                      '
          myspeed:=longSpeedOgR
          LOCKCLR(NEMAsemID-1)                      ' unlock  
          if myspeed>3000              '  raw-speed is in 1/100 of knots
            outa[2]:=1                     ' your pin 2 HIGH
            repeat 15
               waitcnt(clkfreq+cnt) ' wait
           outa[2]:=0                     ' your pin 2 LOW

[/COLOR]       ' !outa[_led]          ' blink slow
       ' waitcnt(clkfreq+cnt) ' save energie
       ' waitcnt(clkfreq+cnt) ' save energie
        waitcnt(clkfreq+cnt) ' save energie
        waitcnt(clkfreq+cnt) ' save energie
      else  
        !outa[_led]          ' false no valid gps data
        waitcnt(clkfreq/2+cnt)  ' blink faster

enjoy!

Mike

dflynn5656 · 2012-03-23 14:05

Thanks Mike - I will read this over this weekend. Too bad you're not local to the east coast (Laurel, Md). You'd LOVE my lab.....

msrobots wrote: »

Hi David ... again ...

the changes you need for your projekt migt be simple. In my source-code pretty much in the beginning you find this

PRI LED_Cog_Loop             ' watchdog ... sort of
    dira[_led]:=1            ' LED output
     
    repeat
      if longValidDbg           ' true ok ? no need for lock ?
        outa[_led]:=1        ' solid on
       ' !outa[_led]          ' blink slow
       ' waitcnt(clkfreq+cnt) ' save energie
       ' waitcnt(clkfreq+cnt) ' save energie
        waitcnt(clkfreq+cnt) ' save energie
        waitcnt(clkfreq+cnt) ' save energie
      else  
        !outa[_led]          ' false no valid gps data
        waitcnt(clkfreq/2+cnt)  ' blink faster

this runs in an own (SPIN) cog and basically takes care about the blinking and nonblinking red LED.
put something there like this ... (not tested but does about what you said)

PRI LED_Cog_Loop[COLOR=#020FC0] | myspeed            [/COLOR]' watchdog ... sort of
    dira[_led]:=1            ' LED output
   
[COLOR=#020FC0]    dira[1]:=0    ' pin 1 input
[/COLOR]    [COLOR=#020FC0]dira[2]:=1   ' pin 2 output
[/COLOR]  [COLOR=#020FC0]  outa[2]:=0                     ' your pin 2 LOW
[/COLOR]     
    repeat
      if longValidDbg           ' true ok ? no need for lock ?
        outa[_led]:=1        ' solid on

[COLOR=#020FC0]        if ina[1]==1         '  your pin1 high
          repeat while(LOCKSET(NEMAsemID - 1))      ' wait for lock (until set returns false)                      '
          myspeed:=longSpeedOgR
          LOCKCLR(NEMAsemID-1)                      ' unlock  
          if myspeed>3000              '  raw-speed is in 1/100 of knots
            outa[2]:=1                     ' your pin 2 HIGH
            repeat 15
               waitcnt(clkfreq+cnt) ' wait
           outa[2]:=0                     ' your pin 2 LOW

[/COLOR]       ' !outa[_led]          ' blink slow
       ' waitcnt(clkfreq+cnt) ' save energie
       ' waitcnt(clkfreq+cnt) ' save energie
        waitcnt(clkfreq+cnt) ' save energie
        waitcnt(clkfreq+cnt) ' save energie
      else  
        !outa[_led]          ' false no valid gps data
        waitcnt(clkfreq/2+cnt)  ' blink faster

enjoy!

Mike

msrobots · 2012-03-23 14:29

hm. not using my own public methods. so

          [COLOR=#020fc0]repeat while(LOCKSET(NEMAsemID - 1))      ' wait for lock (until set returns false)                      '
          myspeed:=longSpeedOgR
          LOCKCLR(NEMAsemID-1)  [/COLOR]

can be replaced by

          [COLOR=#020fc0]myspeed:=[/COLOR][COLOR=#020fc0]Long_Speed[/COLOR]

enjoy!

Mike

dflynn5656 · 2012-03-23 20:14

OK Mike - inserted the additional code snippet you recomended. Loaded the whole thing (your complete program) into eprom and got a red light on the GPS. I did use the prop plug attached to the 4 pins I soldered into the serial port of the VPN1513 - since my prop clip doesn't seem to fit.

Plugged the other 4 pins into my pro development board to get power to the VPN1513, but DID NOT use the SIO lead to the stamp. I want this to be a pure propeller deal.

Pulled up the parallax serial terminal that comes with the standard propeller tool V1.3 and typed in !GPS3 on the command line - after enabling the terminal as COM5.

Baud rate 115200 as specified. But - no joy....

Well - the propeller DID like your code....and so did I. But the VPN1513 seems to defy every attempt to do useful service.
Love it's little red light though.....

I will keep hammering away at this, and I am re-reading your code and deltaing it from the Parallax stuff. I want to see in detail what changes you made and why.
I DO like the 1/10 knot resolution...Nice work. You have been an impressive instructor - the failure here is mine.

Thanks!

msrobots wrote: »

hm. not using my own public methods. so

          [COLOR=#020fc0]repeat while(LOCKSET(NEMAsemID - 1))      ' wait for lock (until set returns false)                      '
          myspeed:=longSpeedOgR
          LOCKCLR(NEMAsemID-1)  [/COLOR]

can be replaced by

          [COLOR=#020fc0]myspeed:=[/COLOR][COLOR=#020fc0]Long_Speed[/COLOR]

enjoy!

Mike

dflynn5656 · 2012-03-24 23:11

Hey Mike - got it working! This is great! Thanks!!!!!!

David

msrobots · 2012-03-25 18:29

Hi David - good to hear - what was the problem ?

keep us informed about the progress

enjoy!

Mike

dflynn5656 · 2012-03-26 12:48

Mike - where did you get the list !GPS3, !GPS8 ? Are they an NMEA standard feature?

msrobots wrote: »

Hi David - good to hear - what was the problem ?

keep us informed about the progress

enjoy!

Mike

msrobots · 2012-03-27 18:15

sorry for the delay ... it is !GPS0 - !GPSD ... see CMD-Cog-Loop in source or parallax pdf for CMDs

that is what the GPS is delivering ... reformatted thru the prop as string output ... so the output of my new firmware.

did you see that in those blue lines in PRI LED_Cog_Loop PIN 2 will get set depending on speed>30 knots and PIN1 high ? Did you tryed it ?

enjoy!

Mike

dflynn5656 · 2012-04-03 09:53

Hey Mike - I will run an automobile test with it shortly. I made all the changes you suggested....it appears to work fine.

sidecar-racer · 2012-04-07 20:47

HI Mike,

I have a datalogger about 90% complete using VPN1513 and other Parallax pieces. Using one Object in own Cog on Propboard to gather data from VPN1513 and place in Propboard global memory. Works fine with original VPN1513 firmware. With your firmware data is updated for about 1 minute and then stops updating. Power cycle system and runs again for about 1 minute. I did try slowing Aquisition Object to 1 second, no change.
Where should I be looking?
I'm reading Sat count, date, Time, Speed, Heading, Altitude, Lat and Long.ray
Rick Mur

msrobots · 2012-04-08 01:49

Hi Rick,

yes - I stumbled over that by myself.

I was searching in my sd-server projekt, assuming the error was there... wrong. It is the buffering in 4portserial I guess.

kind of barking at the wrong tree since 2 weeks - it is the gps.

I look into this hopefully tommorrow

enjoy!

Mike

sidecar-racer · 2012-04-08 11:11

Mike,
Sounds good. If there's anything I can check to help, let me know.
I have noticed intermittant startup of original code as well. I'm thinking that it's in my fetch object, using simple serial and I can see where the object could hang if 1513 didn't respond.

msrobots · 2012-04-16 15:46

Hi sidercar-racer,

I switched the 4-port-serial driver from Tim Moore aganst a newer Version from Tracy Allen and Duane Design.

They did some work Tims drive. one point was detecting framing errors. so I gave it a try.

I also upped the stacks used - just in case.

BUT I could not find any reason why the system may hang as you descibe.

Even with removing connection and reconnecting while running - I cant break it - it runs/recovers transmission.

Maybe it was a stack issue - give it a try with the newer Version 2.1 and keep me informed ...

I updated the top post with version 2.1

enjoy!

Mike

sidecar-racer · 2012-04-19 17:22

Well, whatever the changes were, it now works. I even went back to original 2.0 version and still had the one minute lock. The 2.1 has been running for 2 hours now and still working. Also your code syncs to GPS much faster.
Thanks, Rick

msrobots · 2012-04-19 17:52

Hi Rick,

good to hear - we need to thank Tracy Allen and Duane Design for the changes in the 4-port-driver...
I am back hunting in my sd-clinet/server thing. this one still hangs using sd-client in the nema-loop of vpn1513.
sometimes - after a couple of hours - it just stops.

But now the sd-server provides a log-file for me. Debugging with sd-logfile... something new.

enjoy!

Mike

dflynn5656 · 2012-10-25 19:40

Mike (MSrobots) I am trying w/o success to get data out to the TERM you created to see internal variables.

I'm oddly fascinated with your work...and still on it after months.

I've tried things like TERM.str (String("HBcount = ", HBcount)) to print out variable HBcount.

I'd love to talk to you about this whole program by phone some time - and share what I'm doing on the radar project with you

David (my email is dflynn5656 at gmail dot com)

msrobots · 2012-10-26 23:18

Hi David,

I am not sure what you try do do.

But do not confuse SPINS string() with printf of C. It is not. It is just producing strings at COMPILETIME.

So TERM.str (String("HBcount = ", HBcount)) will NOT give you the value of HBcount. Assuming HBcount is a long you would need to do:

TERM.str (String("HBcount = ")) followed by
TERM.dec(HBcount)

Hope this helps a little

Enjoy!

Mike

dflynn5656 · 2012-10-29 15:58

Thanks Mike. I will give that a try. Email me at your leisure (see previous msg) and I'll share my project direction with you - if you're curious. It also appears the you are using the 5 MHZ crystal for accurate timing.....

_CLKMODE = XTAL1 + PLL16x
_XINFREQ = 5_000_000

I kinda feel like I'm communicating with my Grad school teacher in an online micro controller course. Frankly Mike - you should consider making some instructional Youtubes for your fans.

GPS VPN1513 extended Firmware V 2.1

Comments