EM-408 GPS Interface (Sparkfun)

[meenbombs]

I am working on interfacing the EM-408 GPS module with the ZX-328n. I have connected the TX pin of the GPS to pin 6 of the ZX through the transistor level converter circuit shown in the applications files.

I get a constant stream of nulls and gibberish and what appears to be an NMEA string fragment every 30 seconds or so. The GPS is setup at 4800, no flow control, 8 data bits, no parity, and one stop bit. I have verified its operation and proper output using both the SiRF Demo program and the X-CTU (Digi) terminal. When I used the terminal I went through the ZX-28 adaptor board on pin 3. I have spent nearly 40 hours on this issue and am no farther than I was when I started. Any help would be appreciated. Thanks.

Code: Select all

Sub Main()
  Const qsize as Byte = 400
  Dim oq(1 to qsize) as Byte 
  Dim iq(1 to qsize) as Byte 
  dim NMEA as string

  Call DefineCom(3, 6, 5, &H08, 01) 
  Call OpenQueue(iq, SizeOf(iq)) 
  Call OpenQueue(oq, SizeOf(oq)) 
  Call OpenCom(3, 4800, iq, oq)

  do
    Call getqueue(iq,NMEA,75)
    debug.print (NMEA)
    call delay(0.1)
  loop
End Sub

I was going to paste a representative sample of the gibberish that shows up but when I cut and paste these are the only characters that show up both here and in notepad or Word.
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ

[admin edit: added code tags to the code]

[dkinzer]

I get a constant stream of nulls and gibberish and what appears to be an NMEA string fragment every 30 seconds or so.

Based on the code you've shown, that's what I would expect. The fifth paragraph in the Discussion section of the description of GetQueue() explains why.

Although I understand the inclination to read the NMEA data into a String data type, it is probably better to read the characters from the queue into a Byte array. You can do this as the characters appear in the queue or wait until the queue contains a full sentence (terminated by a CR, for example). Once you have the sentence in the Byte array, you can process it and extract parts of it as Strings, if that is useful, or extract the values to numeric types.

[meenbombs]

I am on the way out the door but tried the GetQueueStr function and it works. I will go back and try to understand paragraph 5 a little better tonight. However, I have a solution I can work with now. Thanks again.

[dkinzer]

I [...] tried the GetQueueStr function and it works.

That is probably not a good general solution due to the stated limitations of GetQueueStr(). In particular, the returned string may contain one or more partial sentences, (rarely) exactly one complete sentence, or one or more complete sentences plus one or more partial sentences. Moreover, parsing strings and extracting sub-strings from them are both inefficient compared to the alternative of using a Byte array as I suggested.

[mikep]

Moreover, parsing strings and extracting sub-strings from them are both inefficient compared to the alternative of using a Byte array as I suggested.

Don is correct as I have also said in other appends about your application code; parsing strings is inefficient in ZBasic and for that matter every other embedded system.

Another concern is because of the partial sentence problem and the need to verify a checksum, you really should have a separate task just receives and parses NEMA messages. Then you can have the main task receive only complete messages and process them. Structures could be used to return each message.

An example of how to do this is in the AN218 application note which receives Rs485 messages in one task while processing them in another. I have also used this (common) pattern for other communication applications such as RF.