PDA

View Full Version : GPS VPN1513 extended Firmware V 2.1



msrobots
03-16-2012, 03:45 AM
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

91764

enjoy!
Mike

Publison
03-16-2012, 05:35 PM
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
03-16-2012, 09:03 PM
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
03-19-2012, 02:09 AM
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
03-19-2012, 08:44 PM
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
03-19-2012, 10:19 PM
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
03-20-2012, 12:03 AM
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
03-20-2012, 12:54 AM
... 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
03-21-2012, 04:16 PM
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
03-22-2012, 12:15 AM
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
03-22-2012, 01:08 AM
Great thanks for looking into this.

dflynn5656
03-22-2012, 08:47 PM
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
03-23-2012, 09:47 AM
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
03-23-2012, 11:03 AM
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 | myspeed ' watchdog ... sort of
dira[_led]:=1 ' LED output

dira[1]:=0 ' pin 1 input
dira[2]:=1 ' pin 2 output
outa[2]:=0 ' your pin 2 LOW

repeat
if longValidDbg ' true ok ? no need for lock ?
outa[_led]:=1 ' solid on

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

' !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
03-23-2012, 10:05 PM
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.....



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 | myspeed ' watchdog ... sort of
dira[_led]:=1 ' LED output

dira[1]:=0 ' pin 1 input
dira[2]:=1 ' pin 2 output
outa[2]:=0 ' your pin 2 LOW

repeat
if longValidDbg ' true ok ? no need for lock ?
outa[_led]:=1 ' solid on

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

' !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
03-23-2012, 10:29 PM
hm. not using my own public methods. so




repeat while(LOCKSET(NEMAsemID - 1)) ' wait for lock (until set returns false) '
myspeed:=longSpeedOgR
LOCKCLR(NEMAsemID-1)



can be replaced by



myspeed:=Long_Speed


enjoy!

Mike

dflynn5656
03-24-2012, 04:14 AM
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!



hm. not using my own public methods. so




repeat while(LOCKSET(NEMAsemID - 1)) ' wait for lock (until set returns false) '
myspeed:=longSpeedOgR
LOCKCLR(NEMAsemID-1)



can be replaced by



myspeed:=Long_Speed


enjoy!

Mike

dflynn5656
03-25-2012, 07:11 AM
Hey Mike - got it working! This is great! Thanks!!!!!!

David

msrobots
03-26-2012, 02:29 AM
Hi David - good to hear - what was the problem ?

keep us informed about the progress

enjoy!

Mike

dflynn5656
03-26-2012, 08:48 PM
Mike - where did you get the list !GPS3, !GPS8 ? Are they an NMEA standard feature?




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

keep us informed about the progress

enjoy!

Mike

msrobots
03-28-2012, 02:15 AM
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
04-03-2012, 05:53 PM
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
04-08-2012, 04:47 AM
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
04-08-2012, 09:49 AM
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
04-08-2012, 07:11 PM
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
04-16-2012, 11:46 PM
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
04-20-2012, 01:22 AM
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
04-20-2012, 01:52 AM
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
10-26-2012, 03:40 AM
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
10-27-2012, 07:18 AM
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
10-29-2012, 11:58 PM
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.

dflynn5656
10-30-2012, 01:10 AM
Ok Mike - I gave it a try as follows:

TERM.str(string("HBcount = "))
TERM.dec(HBcount)

It just keeps failing on the first line as follows -

Expected ",".

I suppose it's looking for a "," which may be another parameter of String. And yes, my background is "C" as you guessed, from Grad school.....

msrobots
10-30-2012, 06:14 AM
Hi David,

I send you a mail so you can send me some code to look thru.

I think you may still miss some concepts of Propeller and SPIN. But I am pretty sure we will get you there. The Propeller is a fascinating thing. BECAUSE it is different. Once understood a lot of things fall into place. You will see.

Enjoy!

Mike

sidecar-racer
10-30-2013, 12:46 AM
Mike, been out of loop for awhile, when I brought system after it's been working for months, it would catch a few seconds of GPS data then stop.
Was using 2.1 version. In troubleshooting I noticed that the raw output of GPS unit was eratic, not every second like I figured. By puttting back original code (1.0) problem goes away. Put back in 2.1 code problem comes back. Kinda strange.
Rick

msrobots
10-30-2013, 02:40 AM
Hm.

So you had V. 2.1 working for a while and now it is not working again?

I haven't used my GPS stuff for a while since my rover project got delayed by other stuff and - well - is just sitting there.

My GPS Firmware uses 4portserial from Tracy Allen. There is a newer Version out by now correcting some glitches there.

Yet - this is 'Kinda strange' since it was working before as far as I understood. Maybe stupid stuff like Dust and or minimal corrosion? stray voltages?

Had this stuff with my 3d-printer sitting too long in the shed ... unplugged all plugs sprayed contact-cleaner on them an reconnected a couple of times... now fine again.

Question:

I noticed that the raw output of GPS unit was eratic, not every second like I figured

Do you mean output of Firmware 2.1 or output of RAW data of GPS when switching out of SMART mode by pulling that pin down on the vpn1513 ?

Enjoy!

Mike

sidecar-racer
10-30-2013, 07:24 PM
2.1 worked great for quite awhile.
Possible cold solder connection but going back to 1.0 working and back to 2.1 not working doesn't seem like electical.
Doing testing on benchm not in vehicle, knowing that will open another can of worms. :)
I will look at newer serial code.
Erratic from RAW not SMART.
Rick

msrobots
10-31-2013, 11:26 PM
Hi Rick

well - the vpn1513 has two sides and on each side one processor.
The propeller runs the firmware and reads the RAW pin of the other one, if in smart mode.
if not in smart mode prop does not have access to the RAW pin of the GPS chip (some ARM with own firmware)

if you have already erratic in RAW mode then this might be a hint where to look.

How about that connector for the antenna? Mine was sort of sitting quite lose when plugged in from the beginning. So I took some pliers and carefully pressed and dented the connector to sit tight.

But still no explanation why V.1.0 of firmware works and V.2.1 does not. Besides using different serial objects. Or maybe it is.

The original firmware had a bug in calculating the checksum, thus was ignoring checksum errors, processing the data anyways and then writing complete BS into the Data Fields.

I corrected that behavior early on and never had any issues with communication between propeller and GPS. But if the RAW serial stream is erratic / noisy then MAYBE V.2.1 chokes on that?

I am pretty busy with other stuff but will look(dig?) for rover setup in the shed coming weekend. Its there. I am sure to have it seen there lately, VPN1513, Main control prop and sensor prop. even the remote control unit.

Enjoy!

Mike
.