GPS SIM33EAU PN 28504

pilot0315

Help please.
I have the new gps module and want to bump the baudrate. I need to send this string preferably in PropC.
Page 12 of the manual:

Example: $PMTK250,1,3,9600*14<CR><LF>

Appears that fdserial does not allow me to send the string:
// fdserial_txChar(str("$PMTK250,1,3,115200*14,13,10"));

VonSzarvas

I'd successfully used dprint and dscan. Here's a snip:

#include "fdserial.h"
fdserial *gps;
gps = fdserial_open(8,9,0,9600);
dprint(gps, "%s%c%c", "$PMTK435*30", 13, 10);
dscan(gps, "%s", rtcValue);

BTW... the baud rate is 9600 by default. As your example included that baud, I figure that's worth a mention in-case you thought the module was 4800 or something, and were trying to send your command at the wrong baud.

pilot0315

Thanks for the help I have to bump the rate to 115200 and send the gps:
// fdserial_txChar(str("$PMTK250,1,3,115200*14,13,10"));
the 115200 is supposed to change the rate permanently to 115200.
Martin

pilot0315

@VonSzarvas

Please see above post.
Thanks

VonSzarvas

pilot0315 wrote: »

Thanks for the help I have to bump the rate to 115200 and send the gps:
// fdserial_txChar(str("$PMTK250,1,3,115200*14,13,10"));
the 115200 is supposed to change the rate permanently to 115200.
Martin

might not keep the baud change after a powercycle... I don't think that option was enabled by the module supplier.

Either way, no harm to send the baud command at 9600 during your code init, then switch to 115200.

As for the txChar method, I'm not familiar with that. I only ever used dprint, and stuck with it as it worked first time. Does txChar accept a string ?

iseries

fdserial_txChar only sends on character at a time. So it will only send the '$'.

Mike

pilot0315

I will attempt with the code you sent me and
also one char at a time and see what happens.

Thanks to both
@iseries
@VonSzarvas

David B

I don't know anything about fdserial, but I think you'll need to calculate a new checksum to go along with your changed baud rate.

From the pdf, "The checksum is computed as the exclusive OR of all characters between the $ and * characters."

It looks to me like it should be $1C, which should be sent as the two values 31 43.

Also, the 13,10 are not part of the comma-separated string, but should follow the checksum as $0D$0A.

So your data to send would look like $PMTK250,1,3,115200*1C<CR><LF>

24 50 4D 54 4B 32 35 30 2C 31 2C 33 2C 31 31 35 32 30 30 2A 31 43 0D 0A

David

pilot0315

@"David Betz"

I need to send a string like in fullduplexserial but to the device.

PUB Str(stringPtr)
{{
Transmit a string of bytes

Parameters: stringPtr = the pointer address of the null-terminated string to be sent
return: none

example usage: serial.Str(@test_string)

expected outcome of example usage call: Transmits each byte of a string at the address some_string.
}}

repeat strsize(stringPtr)
Tx(byte[stringPtr++])

but to the device not the screen. Any ideas??

David B

I'm not David Betz; I'm a different David B.

In spin, I've used FullDuplexSerial4port to talk with GPS, something like this:

VAR

p : "FullDuplexSerial4port"

p.init
p.AddPort(0, RXPIN, TXPIN, -1,-1,0,0,115200)
p.AddPort(1, SIRF_TX_OUT_PIN, SIRF_RX_IN_PIN, -1,-1,0,0,4800)
p.Start

sending to the terminal:

p.s(0, String("Hello world! "))

sending to GPS:

repeat strsize(stringPtr)
p.tx(1, byte[stringPtr++])

Don't forget that if your reconfiguration takes then you'll have to restart the GPS comms also as 115200.

David

pilot0315

@"David B"

Thanks I will try that.

pilot0315

David B wrote: »

I'm not David Betz; I'm a different David B.

In spin, I've used FullDuplexSerial4port to talk with GPS, something like this:

VAR

p : "FullDuplexSerial4port"

p.init
p.AddPort(0, RXPIN, TXPIN, -1,-1,0,0,115200)
p.AddPort(1, SIRF_TX_OUT_PIN, SIRF_RX_IN_PIN, -1,-1,0,0,4800)
p.Start

sending to the terminal:

p.s(0, String("Hello world! "))

sending to GPS:

repeat strsize(stringPtr)
p.tx(1, byte[stringPtr++])

Don't forget that if your reconfiguration takes then you'll have to restart the GPS comms also as 115200.

David

@david b
Thanks for the help. This is the first time for me to work with fullduplexserial4port.

Please see attached and tell me did I get it correct. I am playing with fds4p right now and am a little confused.

The question is, since I have not sent strings like this, is how to setup the string. Plus I am learning fds4p.

Thanks

kwinn

The add port looks fine. Sending strings, numbers, and individual characters is almost identical to full duplex serial. IIRC the only difference is having to specify the port number.

pilot0315

@kwinn
@"David B"

I ran the code and got these errors.

What am I missing?

Thanks

pilot0315

@"Peter Jakacki"

Peter,
Would you please take a look at this. I am attempting to change the baud rate so I can use this with the P2.
Thanks

Ltech

5cent.
In you constant part, you try to put a string.
You have to use data and build a byte array
You forgot to declare CR an LF

CON 'Crystal settings
  _clkmode = xtal1+PLL16X
  _xinfreq = 5_000_000

  CR            = $0D  '== asci char nr 13 ..... you can use 13 or *0D
  LF            = $0A
  
  rxpin = 0
  txpin = 1
   SIRF_TX_OUT_PIN = 2
    SIRF_RX_IN_PIN = 3

Dat

 stringPTR byte "$PMTK250,1,3,9600*14",CR,LF,0

Zero @end is for terminating the string block

And I think use

repeat strsize(@stringPtr)

pilot0315

Tried that change but no joy. Tried to fix it but each error correction begats another error.

Also tried to do it one at a time and got this error. See second code.

Thanks for the assist.
Martin

Ltech

I mean ;

P.str(1, @stringPtr)

This build, but I can' test it

Ltech

Or if you only have to flash the GPS one time.

p.str(1,string("$PMTK250,1,3,9600*14",CR,LF))

Will do the trick
On the first post you print

p.str(1,str("$PMTK250,1,3,115200*14,13,10"))

You have put the LF an CR inside the string part, so it sent asci 13 and 10.

=> On the end, you send $31; $33;$31;$30 and not $0D;$0A

And you can do the same with other serial.spin tools

Ltech

At the "one at a time spin" file you try to send one byte contenting two asci characters.

p.tx(1, byte["14"] )

and then you have to send carriage return and linefeed to tell the GPS "this is the end of the message!".
Those are asci code 13 and 10 or hex 0D and 0A

p.tx(1, byte["*"] )
              p.tx(1, byte["1"] )
                p.tx(1, byte["4"] )
              
               p.tx(1, $0D)   ' OR p.tx(1, 13) is the same as  p.tx(1, $0D)
                 
                 p.tx(1, $0A ) ' OR p.tx(1, 10 ) is the same as p.tx(1, $0A )

You have to learn Asci, HEX string Binary to understand wat you try to do.

David B

Pilot0315, sorry for the delay responding; I was out of town for a few days.

Here's a sample program that works for me; it repeatedly switches my SIRF GPS receiver between 4800 and 9600 baud.

This code is not necessarily the best programming style, but it does work with my GPS receiver. You'll have to change the GPS port pins and change the configuration strings to what your receiver needs, but with that done, this code should calculate the checksum, send the data, reset the serial port to the changed rate, then display a few lines of the GPS messages to demonstrate correct operation.

There's a few seconds of my results in a comment at the end of the file.

David

pilot0315

Thanks I will look at it.

pilot0315

@"David B"

I ran the code and it is asking for a subroutine.

I looked in fullduplexserial4port and do not see "r".
Which one is it looking for?

Thanks.

I generally only do code on the weekends. Studying your code now.

pilot0315

@"David B"

Tried it alas nojoy.

I will keep working on it.

David B

I probably added a little helper procedure "r" to my copy of the library to send a carriage return:

PUB r(port)
tx(port,13)

Don't you need to send the configuration string PMTK250 that's specific to your device? PSRF100 is probably only used for my SIRF GPS receiver.

pilot0315

I fixed the mistake, was not thinking. Thanks.
Tried it again with and without cr/lf in the string. Still not working.
I will keep trying.

You also mentioned that the code would display a couple of the strings. I don't see that in the code.
This is the first time for me to use fullduplexserial4port.


On line 68: repeat i from 1 to msgsize-2 ' checksum from after the "$" to before the "*"
referring to this:
sirf4800 byte "$PSRF100,1,4800,8,1,0*",0

Since my device is different:

sirf115200 byte "$PMTK250,1,3,115200,*14 " ,0

' sirf115200 byte "$PMTK250,1,3,115200,*14,13,10 " ,0

would I have to change that?

David B

I'm assuming that your gps receiver will start sending a steady stream of messages as soon as it is powered up and connected to correctly.

If you're not seeing messages when you first connect then that's the first thing to fix. Check your serial input pin, baud rate, whether the data should be inverted by the serial receiver library, there are many things that can go wrong.

You really should get the receiving working before trying to reset the sending baud rate because until you're receiving properly you won't know if you've reset the baud rate properly.

David B

Here's an example of just about the simplest program to display GPS messages. It sets the GPS out port as unused, and just echoes the GPS messages to the terminal.

My GPS receiver doesn't need to have the input data inverted, but some might, so I've shown where that option would be set.

I've included some example input in the file, both before the receiver locked onto the satellites and afterwards.

I'm guessing that something like this should display messages from your receiver, if the input pin and the serial parameters are set properly. If your input pin is set properly and your receiver is powered, you'll likely see some characters on the terminal, even if the baud or invert state isn't right.

pilot0315

@"David B"


BTW I have been using GPS modules for a while. This snag is bugging me because I am using the P2 now and the serial program will not work at
9600 baud. My Prop C code works great at 9600. I purchased two of these so I can bump up the baud rate to use with the P2. BTW the P2 is great but
a big learning curve.
I don't understand why this device does not respond. I will try the next code, Thanks.
I used your first code and tested it with my PropC code. Great stuff at 9600, oh well.
Again thanks
Martin

Publison

David B wrote: »

Here's an example of just about the simplest program to display GPS messages. It sets the GPS out port as unused, and just echoes the GPS messages to the terminal.

My GPS receiver doesn't need to have the input data inverted, but some might, so I've shown where that option would be set.

I've included some example input in the file, both before the receiver locked onto the satellites and afterwards.

I'm guessing that something like this should display messages from your receiver, if the input pin and the serial parameters are set properly. If your input pin is set properly and your receiver is powered, you'll likely see some characters on the terminal, even if the baud or invert state isn't right.

This works just fine with a stock GPS at 9600 set on port 1. I can't get a screen shot right now. Currently using a FLIP.

Publison

Here's the screen shot.