Procedure Call Problem

Earl Foster

I have been using Stamps in my high altitudes balloon projects for a while and now I am planning to move to the Propeller for my next flight.· I procrastinated my move to Spin long enough for there to be some really good objects in the object exchange library.· Thanks all.
·
Several primary procedures must be ported over to Spin.· One of those is the GPS procedure.· I am using Perry’s GPS_IO_mini.spin object for that purpose.· It appears that I can not get my code to recognize when the GPS has acquired using the “valid” procedure call.· So I have tried modifications to that procedure to look for other variables in other NMEA sentences.· My last attempt used the number of satellites in GGA NMEA sentence.· So I figure I am not using his object correctly or calling it correctly and since I have only been writing in Spin for 3 days now it is not surprising.· I have changed the “mode bit” to all possible combinations in the FullDeplexSerial.spin object and returned it back to 0.· I have verified that I have the correct input pin assigned to receive the GPS data.· I have tried changing my condition statement to look for $2 instead of the string “2” just in case it returned a number.· I have changed the operator in the condition statement to “<>”.· I also talked to Paul H earlier today concerning my understanding of what should be happening between the procedure calls and objects and we seem to be on the same page.·I have run out of things to try.
·
I have run out of ideas to try.· Suggestions would be greatly appreciated.· I have shown a sniplet of the code and posted the full version.
·
obj
· LCD:········· "Serial_Lcd"·········· 'LCD object
· GPS:········· "GPS_IO_mini"·······'GPS object
·
pub Init_GPS
· GPS.start
· repeat
···· i:=0
···· repeat while i<4
······· lcd.cls
······· lcd.gotoxy(0,i)
······· lcd.str(string(" Seeking Satellites"))
······· waitcnt(clkfreq/2 + cnt)
······· i++
··while byte[noparse][[/noparse]gps.valid] < "2"·· ' Need at least 3 satellites
· lcd.cls
· lcd.str(string("Satellites Acquired"))
· lcd.gotoxy(0,1)
· lcd.str(gps.GPSaltitude)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman

StefanL38

Hello Earl,

from the file HAPB4.spin i cannot see what might be wrong.

As you already made some global tests - I think a good way is to analyse the problem by elimination of reasons.

This means checking everything from the basic up.
Maybe you have done something like this but there's no info about that in your posting.

First thing: can you make the GPS-module send serial data to a terminalsoftware of a PC ?

Check what does the PC-Software receive ? With what kind of parameters (baudrate, databits, paritybits)

I did not find the GPS_IO_mini-object and the FullDuplexSerial_mini-object quickly.
Here it would be nice when you attach ALL SPIN-files that are nescessary to compile the project.

One idea i have is: if FullDuplexSerial_mini has a receivebuffer of only 16 bytes like the standard
FullDuplexSerial but the GPS-module sends characters all the time the buffer gets full and the oldest byte
gets overwritten by the newest byte. And then there is no longer valid data.

So it is important what does the GPS-module send out
does this fit to the specification that the GPS_IO_mini expects ?

Make a testprogram that echos every single byte received by the GPS_IO_mini-object to ANOTHER
serial port or maybe to the tv_text-object to be able to analyse what does the propeller receive

Depending on the results of this tests you will get information which is the direction to go on searching
for the fault.


best regards

Stefan

Earl Foster

I have run a number of additional tests and still can not communicate properly with the GPS.·

The GPS is working properly.· I can watch the NMEA sentences on my PC.· I tried StefanL38's suggestion of echoing what is recieved but I do not think I am passing the data properly to the debug terminal.· Under the current code I am getting garbage updates to the debug terminal.

con
  _clkmode = xtal1 + pll8x      'must be used for the Spin stamp
  _xinfreq = 10_000_000         'must be used with the Spin stamp
obj
  debug[noparse][[/noparse]2]:        "FullDuplexSerialPlus"           'Debug object
  
pub main
    Debug[noparse][[/noparse]0].start(31, 30, 0, 9600)        'Start the debug terminal
    debug[noparse][[/noparse]0].str(string("Starting", 13))
    waitcnt(clkfreq + cnt)
    debug[noparse][[/noparse]1].start(8,1,0,4800)             'Start comm to gps
                                           'I have tried all bit modes
    repeat
       debug[noparse][[/noparse]0].str(debug[noparse][[/noparse]1].rx)           'Receive btye from GPS and display
       debug[noparse][[/noparse]0].str(13)                    'new line
       waitcnt(clkfreq + cnt)

·
Am coding this correctly or am I all screwed up?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman

Mike Green

The ".str" routine is intended to display strings, not individual characters. You pass it the address of a zero-terminated string to transmit.

What you need to use here is ".tx" which takes a character value and transmits that. For example: debug[noparse][[/noparse] 0 ].tx(13)

Earl Foster

I changed the call to .tx but it is still sending garbage to the screen and if I understand the procedure call correctly then "debug[noparse][[/noparse]0].tx(debug.rx)" should be getting a byte from the gps and displaing that byte to the screen.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman

Timmoore

Also the following line - sending 13 should use tx
You might want to remove the waitcnt as well. The rx buffer from the gps will overflow since chars will be arriving faster than you can process them

Earl Foster

I changed both to tx. I now understand why I should use tx verse str but that is not making a difference in the output and the waitcnt is purely to slow down the screen display for my old eyes. There is a fundamental principle I must be missing here.

I want to pass the serial text string from the gps directly to the screen which is what I thought my code was doing. But it is only sending garbage so therefore I am still missing something. Perhaps I am trying to simplify it too much. I don’ t know

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman

Timmoore

These are the things I would look at
Do you see "Starting" on the debug before you get garbage?
Since GPS is working with the PC what do you change to connect the GPS to propeller? i.e. remove level-shifter since PC is rs232 and propeller is 3.3V
Check the baud rate the PC terminal app uses for the GPS - make sure its 4800
Are you sure you have the TX pin on the GPS to pin 8 rather than the GPS RX

Earl Foster

I get the "Starting" to the screen, then garbage after that.· The GPS is powered by the same source as the propeller and·I am tapping off the TX, RX and GND pins to connect to the PC through a USB-Serial-Null modem adapter.· I am not changing any wire connections.· The PC·displays the NMEA strings fine.· I have also disconnected from the PC to ensure I was not·picking up noise from the computer.· And I am sure about the which lead from the GPS is the TX.· I have been using this GPS with the STAMP for the past several years in my high altitude projects.

Latest Code

con
  _clkmode = xtal1 + pll8x      'must be used for the Spin stamp
  _xinfreq = 10_000_000         'must be used with the Spin stamp
obj
  debug[noparse][[/noparse]2]:        "FullDuplexSerialPlus"           'Debug object
  
pub main
    Debug[noparse][[/noparse]0].start(31, 30, 0, 9600)        'Start the debug terminal
    debug[noparse][[/noparse]0].str(string("Starting"))
    waitcnt(clkfreq + cnt)
    debug[noparse][[/noparse]1].start(8,1,0,4800)             'Start comm to gps
                                           'I have tried all bit modes
    repeat
       debug[noparse][[/noparse]0].tx(debug[noparse][[/noparse]1].rx)           'Receive btye from GPS and display
       waitcnt(clkfreq + cnt)

Still getting garbage.· Latest debug attached.




▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman

Timmoore

I assume you are using the garmin gps18 mentioned on your web page. One issue is that it outputs 5V which was ok with the stamp but not with the propeller which wants a max of 3.3V. You should put a 1K resistor between the GPS and the propeller (there is a thread at the top of the forum about hardware interfacing). I dont know whether that would have damaged the pin, it might have so after you put a 1K resistor in and read the thread to make sure I didnt' forget something, you may want to try a different IO pin.

Earl Foster

I had read that Parallax had done some testing and found the Propeller to be 5V tolerant, however, I should have installed a 1K resistor between Pin8 and the GPS anyway. Fundamental problem! Thanks Timmoore, at least now I know I am getting the NMEA strings now. One step closer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman

Earl Foster

I worked through a number of scenarios this past weekend and started capturing GPS sentences.· I could not get the GPS-to-VGA object in the exchange library to work.· I decided to write my own that would capture, evaluate, and then store the data.· This was also the best way to do it with the Stamp 2px and it works well with the Propeller too.
·
A·curious thing is happening with the two GPS units and that is the inconsistency of capturing GPRMC NMEA sentences.· Both the GPS 18 and GPS 15 Garmin units transmit GPRMC, GPGGA, GPGSA, and GPGSV sentences by default, plus some others.· I have also verified this through their configuration program that the sentences are being transmitted.· My capture and display program works consistently with all sentences except GPRMC. By consistently I mean it will capture the data within a few passes (1 to 3 seconds) and inconsistently meaning anything from 1 second to minutes.· I can even capture multiple sentences as long as GPRMC is not being captured.· At first I thought it might be the GPS-18 since it has been on several high altitude flights already but the GPS-15 does the same thing.
·
Whenever I try to capture RMC the program appeared to hang so I have the program displaying a “period” until it captures the correct data.· Each period represents the program looking for the start of a sentence.· A full line of dots means ~1 second has passed.· I attached one output for reference.
·
For my purposes I do not need RMC anyway so I do not plan to spend too much time on the issue.· If I want bearing and course I can use GPVTG which is captured just fine with my program.
·
I noticed there was not much GPS code available so I have posted the code if you want to use it.· There are 2 versions.· One passes variables to the procedure and the other does not.· You still need to do something with the data besides display but at least you will know if you are capturing the data.

test.spin is my first version that I used for testing
DisplayGPSData.spin passes the sentence that you are looking for to the procedure

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman

StefanL38

Hello Earl,

i don't now how these different sentences look like.

What is the difference between them ?

Could you post properly received sentences of all types ?

regards

Stefan

Earl Foster

The best thing here is to not recreate the wheel and give out the URL for detailed NMEA information.·

http://www.gpsinformation.org/dale/nmea.htm



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman

Cluso99

Have you tried inverting the bits. The NMEA is sort of equivalent to RS232 so it is inverted at TTL into the Propeller.

If you want, I have an opto isolator circuit for keeping the items sepaerate. Uses 6N138/6N139, NMEA inout via 1K series to pin 2, pin3 to GND of NMEA. Pin 8 to +3V3, Pin 7 o/c, Pin 6 out to propeller with 1K pullup to Pin 8 (+3v3), Pin 5 to GND of Propeller. This will invert the signal and works well at 4800 baud. For non-inversion, NMEA output to Pin3 via 1K series and Pin 2 to +5V NMEA.

Hopes this may help

Earl Foster

If I am not mistaken isn't that what the serial object does with the mode bits when you call the procedure?· If the bit is not set correctly you will not receive the sentences.·

If I use the opti isolator circuit you describe it seems to me that I will have to change the mode bit to get it to work properly, therefore, I am doing a double invert and adding additional electronics for something that is being done in software. I am only making a logical guess here that·could be based·on a faulty assumption and lack of knowledge.

From the FullDuplexSerialPlus object:

PUB start(rxpin, txpin, mode, baudrate) : okay
  {{
  Starts serial driver in a new cog
    rxpin - input receives signals from peripheral's TX pin
    txpin - output sends signals to peripheral's RX pin
    mode  - bits in this variable configure signaling
               bit 0 inverts rx
               bit 1 inverts tx
               bit 2 open drain/source tx
               bit 3 ignor tx echo on rx
    baudrate - bits per second
            
    okay - returns false if no cog is available.
  }}
  stop
  longfill(@rx_head, 0, 4)
  longmove(@rx_pin, @rxpin, 3)
  bit_ticks := clkfreq / baudrate
  buffer_ptr := @rx_buffer
  okay := cog := cognew(@entry, @rx_head) + 1

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman

StefanL38

Hello Earl,

that's ok to read the specifications.

But is it really sure that THIS type of GPS-receiver creates NMEA-Data that's exactly like the specification ?
Is it really sure that the pub-method fits to the specification ?

this websites says something about
Garmin g12 sentences for version 4.57
to me that sounds like the specs change from version to version

regards

Stefan

Earl Foster

The website does an excellent job of describing the differences between sentences. It also provides detailed information regarding different manufacturers, their models, transmit times, and transmitted sentence. The GPS manufacturers website is the best place to look for specific information concerning the model in question.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman

Post Edited (Earl Foster) : 6/11/2008 9:43:51 PM GMT

Cluso99

Back to basics...

Have you ensured that the propeller is talking to the PC? By that I mean using the FullDuplexSerial ?

It could be something simple like I noticed above your clock parameters specified a 10MHz xtal.

The NMEA (0183?) is 4800 baud 8,N,1. Some GPS's can output at greater speeds.

Have you tried the FullDuplexSerial and just do FDX.tx("A") followed by a small delay? OH, just thought about it, I had to put a small delay between blocks of characters when I transmit them - I think the tx buffer was getting overwritten. Make sure you can talk to the FDX first. If you need I can post a simple test program I have used for this.

StefanL38

hello Earl,

to me this asking and answering is not systematically enough.
I logout of this thread.

bye

Stefan

Post Edited (StefanL38) : 6/12/2008 12:52:52 PM GMT

rjo_

Hello Earl,

I am a near idiot when it comes to GPS stuff. I went the parsing route and failed. My solution was to buy a Parallax unit and put it in smart mode...it works just fine and is really simple. I modified the standard object on to the extent of reading out to 4D's Prop-96 monitor. Requires one resistor on the signal line[noparse]:D[/noparse]


Rich

Earl Foster

The clocking parameters of pll8x and 10MHz are required for the SPIN stamp. I have to change the settings to pll16x and 5MHz when I test the code against my 40-pin propeller. This makes the clocking between the units the same.

It would be nice to be able to detect which propeller I am using with CASE statements like that used on the Stamps. Then I would not have to concern myself with changing the code.

The Parallax GPS looks like it is a good solution if you do not have units already. I reviewed the manual and Parallax has made it very easier to interface with and use.

I have found, with the GPS 15 & GPS 18 units that I am using, capturing then parsing the sentences works best. The GPS-18, by default, is setup to transmit more sentences then can be transmitted in one second (4800 baud) and that is why it takes 1-3 seconds to capture my data. With the GPS-15 it takes 1-2 seconds to capture the data because it transmits the sentences every second. Both units can be adjusted to 9600 baud rates but I have chosen to eliminate the proprietary Garmin sentences which allow the unit to transmit within the 1 second interval at 4800.

Capturing that data every 1-3 seconds is more then I need for this project. Twenty second intervals are more appropriate since I transmit the data via APRS on frequency 144.39 MHz during the flight.

I appreciate all the suggestions and ideas everyone has posted but I think I am good with the code that I came up with for this project. Its time to move on to the next stage and that is sending the data to a file using the Parallax Memory Stick.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman