Sign in

username or email:

password:



Not a member?
Forgot your Password?

Search basicx



Search tips

Subscribe to basicx



Discussion Groups

See Also

DSPFPGA

Discussion Groups | BasicX | Non standard GPS

Discussion forum for the BasicX family of microcontroller chips.


So far in May, you have voted 0 times ou of a total of 20 votes by the community.
Please help us clean the archives from unuseful discussion threads by using the voting system! Details here.


Is this thread worth a thumbs up?

0

Non standard GPS - psyclopedia - Mar 27 22:48:00 2003

Has anyone tried interfacing a Sirf format GPS unit to a BX-24 yet?
NMEA is pretty straight foward. The GPS unit I have is a Ublox OEM
board. This thing is soooo small, it's great. The problem is I need
to talk to it in Sirf format in order to change the mode to NMEA wich
my code is already set up to deal with.

-Hawk




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Re: Non standard GPS - Doug Sutherland - Mar 27 16:32:00 2003

Hi Hawk,

I've been playing with a Laipac TF30, which is also a Sirf,
and I have it connected to BX24. I decided to just use the
NMEA mode for now because it was so easy. I have in the
past programmed the BX24 to work with the Motorola binary
GPS protocol. I think programming for Sirf will be similar.
You need to compute and send checksums after the commands,
and the data received is binary, so you need to do some
calculations to convert those incoming values. It is quite
a bit of work.

However, one thing you can do is just have the BX24 send
the binary data to COM1 and then have a program on a PC
(or embedded board) do the massaging of the data. I have
done that in the past with embedded boards with very good
results. You can even hook up multiple devices to BX24
and wrap some escape sequences around the data, so the
host knows what data is what.

I am right now reading the Sirf GPS (NMEA) and working
on the Vector 2x compass, and I have humidity, barometer,
and temp sensors going. I chose NMEA because I want to
read all of these with one BX24, and it would be quite
a bit more code to deal with the binary output. I am
also planning to try using a bunch of extra emprom to
log positions and sensor data, that shold be fun.

Back to your problem, just read the Sirf protocol spec,
it tells you what to send (there are many commands),
and look in particular at the checksum information.

Here's some info on the Sirf Protocol. This is from
the Laipac guide for TF30 GPS, but I think that the
protocol should be the same ...

http://www.commlinx.com.au/GPS_Manual/page0051.htm

My understanding is this ... with binary protocol
you get more info and more command possibilities,
but it's more specific/proprietary. There are still
many reasons to stick with NMEA depending on what
you want to do. I am reading the NMEA data from
this Sirf-based receiver and I get all of the
following data captured in the BX24: time, date,
latitude, longitude, altitude, ground speed,
course (heading), number of satellites in view,
number of satellites used, info on all of the
satellites, position fix type, horizontal degrees
of precision. Looking the the Sirf Binary stuff
there is nothing there I really need so I think
I will stick with NMEA format.

I used a sort of tokenizer method to parse the NMEA
data, where I search for delimiters (commas) and
count the field number. Each NMEA record starts with
a $ and ends with carriage return, so if you look
for $ and then look for commas, you can append each
char to a variable length string, then when you find
another comma you are ready to load that field into
a variable. It wasn't as nice as I had hoped because
BX24 cannot use strings in if statements.

-- Doug Hawk wrote:

>Has anyone tried interfacing a Sirf format GPS unit to a BX-24 yet?
>NMEA is pretty straight foward. The GPS unit I have is a Ublox OEM
>board. This thing is soooo small, it's great. The problem is I need
>to talk to it in Sirf format in order to change the mode to NMEA wich
>my code is already set up to deal with.






(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Non standard GPS - psyclopedia - Mar 28 10:12:00 2003

I guess the problem I can't fiure out is in the Sirf data sentence,
there's 2 15 bit pieces. How do I generate those? The default
speed for the Ublox GPS board is 19,200 Baud so I dont think I can do
the timing manually. I only need to send the command string to
switch to NMEA mode (command 129 I think) because I already have that
code written from another project. I'm only looking for the VTG and
GLL data anyway and the NMEA code for this is fairly light, and would
be even lighter if I send the NMEA commands to disable the
information I don't want. I can do what I need to do in about 6 or 7
lines of code

Laipac makes the GPS-10RS232 that I could use as well, and it already
outputs in NMEA format, but I'd rather use Com3 instead of Com1.

On a somewhat related topic, is it possible to have more than 2
queues open at one time or is there a limit? In my code I have to
talk to a few different devices (GPS, 2 temperature sensors, humidity
sensor, and an RF transciever) so I am switching Com3 from 1 set of
pins to another then to another. If I define more than 1 queue the
program hangs. Thanks again for your ideas.

-Hawk



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Non standard GPS - psyclopedia - Mar 28 10:14:00 2003

I guess the problem I can't fiure out is in the Sirf data sentence,
there's 2 15 bit pieces. How do I generate those? The default
speed for the Ublox GPS board is 19,200 Baud so I dont think I can do
the timing manually. I only need to send the command string to
switch to NMEA mode (command 129 I think) because I already have that
code written from another project. I'm only looking for the VTG and
GLL data anyway and the NMEA code for this is fairly light, and would
be even lighter if I send the NMEA commands to disable the
information I don't want. I can do what I need to do in about 6 or 7
lines of code

Laipac makes the GPS-10RS232 that I could use as well, and it already
outputs in NMEA format, but I'd rather use Com3 instead of Com1.

On a somewhat related topic, is it possible to have more than 2
queues open at one time or is there a limit? In my code I have to
talk to a few different devices (GPS, 2 temperature sensors, humidity
sensor, and an RF transciever) so I am switching Com3 from 1 set of
pins to another then to another. If I define more than 1 queue the
program hangs. Thanks again for your ideas.

-Hawk




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Re: Non standard GPS - Doug Sutherland - Mar 28 8:38:00 2003

Haek wrote:

> I guess the problem I can't fiure out is in the Sirf data
> sentence, there's 2 15 bit pieces. How do I generate those?

It looks like the Sirf Binary protocol doesn't really use
sentences. What it does is return two bytes representing
the 'payload' size and two bytes of checksum. The payload
is a length indicator, it tells you how much data is in
the following incoming data. So it appears that the Sirf
protocol uses variable length binary records, hence the
need for a payload length header. It also uses big endian
checksums to validate data integrity, the checksum is a
15-bit checksum on the bytes in the payload data. There
is a psuedocode example of the checksum here:

http://www.commlinx.com.au/GPS_Manual/page0052.htm

As I mentioned before, dealing with the binary GPS data
is a bit tedious, are you sure you need to use it?

> The default speed for the Ublox GPS board is 19,200
> Baud so I dont think I can do the timing manually.

The Laipac receivers, which are also Sirf architecture,
default to 4800 baud NMEA. I actually didn't have to do
anything at all to receive data, just set the port to
4800 8 N 1 and watch the bytes arrive. But with Laipac
you can tweak the baud rate for both the NMEA and Sirf
binary modes.

> I'm only looking for the VTG and GLL data anyway and
> the NMEA code for this is fairly light, and would be
> even lighter if I send the NMEA commands to disable
> the information I don't want.

Can't you just ignore the record types that you don't
need? That's what I am doing. I did need to add a few
lines of code to check the record type, but if it's
not the types I want I just don't process the data.
You can empty a queue without doing anything with the
data ...

> Laipac makes the GPS-10RS232 that I could use as well,
> and it already outputs in NMEA format, but I'd rather
> use Com3 instead of Com1.

So what's the problem (RS232 levels?). You could use
a MAX232 or DS275 if you need to convert back to TTL
level. How about the Laipac TF30? This is what I am
using. It's tiny too (30x40x7 mm), not quite as small
as the uBlox, but then it doesn't need a PLCC socket
either.

http://www.laipac.com/gps_tf30_eng.htm

I played with the uBlox receivers a while ago, and
I found the PLCC format a bit of a detriment. For the
TF30 they have a little connector that plugs into the
header on the back, I was able to solder wires right
onto that header. I'm using their P1 active antenna
with a MMCX connector (although I want to shorten
the cable). And I'm using a 3V lithium coin cell
for battery backup so the SRAM contents is retained.
I'm very pleased with this TF30! It's tiny compared
to the Motorola Oncore GPS that I was using before,
and it's fairly low power. I don't think it's as
"good" as the uBlox but everything is a trade-off.
There is a price you pay for that tiny size ...

> On a somewhat related topic, is it possible to have
> more than 2 queues open at one time or is there a
> limit? In my code I have to talk to a few different
> devices (GPS, 2 temperature sensors, humidity sensor,
> and an RF transciever)

Are we building the same thing? :) I have the TF30
GPS, Vector2x compass, humidity, barometer, and temp
sensors connected (also will be adding the ADXL202
accelerometer).

Sure, you can have as many queues as you want, but
you may not need different queues for each device.
I use a generic DeviceSend buffer and DeviceReceive
buffer. You only "talk" to each device one at a time
right? So you can definitely switch Com3 to point
to different pins (devices). Just clear out the
queue before switching devices, and you can use the
same queue for many devices. I have tried using some
separate queues in the past, but I have found that
I didn't need to. My reason for doing so was a bit
of paranoia hee hee that data would be messed up.
Another thing I tried is wrapping the data for
different devices in escape sequences. For example
I would precede GPS data with CTL-ESC-G and temp
data with CTL-ESC-T. Then on the host side, which
was an embedded PC, the program there could just
examine the escape sequence and immediately know
what kind of data is following it. Works well ...

> If I define more than 1 queue the program hangs.
> Thanks again for your ideas.

It shouldn't hang. Check you opening of queues
and your OpenCom3 statements ... the OpenCom3
refers to the queues ... and you need OpenQueue
before you can use a queue ...

-- Doug




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Re: Non standard GPS - psyclopedia - Mar 28 17:01:00 2003

Doug,

I would much rather use the NMEA format, the problem is that the
Ublox unit defaults to Sirf format when it boots. So all I really
need to do is tell it to switch over to NMEA when mt program boots
up. After that, I disable all of the NMEA messages and put it in
polled mode. Then, when I want to get the data, I send a simple NMEA
command and it respondes with the requested information. That way I
don't have to sift through all of it. As for the PLCC format of the
Ublox, the unit I have is an OEM board with a rather non standard
conector it. I simply unsoldered the factory connector and soldered
on my own. BTW, it's a GPS-PS1E.

What are you building if I may ask? Mine is just a toy at the
moment, but it's getting more and more involved as it progresses. A
little while ago I bought a wireless pinhole camera from Ebay( About
$25+s/h). It's about the size of a quarter. Immediately I strapped
it to a remote controlled car and went out to the back yard. 2
months later, It's evolved into a tank like thing with a Laipac
RF900DV, 2 BX-24's, a GPS (soon), 3 different Digital temp sensors, a
humidity sensor and a great little video overlay module from Decade
Engineering. All of the data from the onboard sensors gets formatted
by the BX-24 and sent off to the radio unit. On the other end of the
radio is another BX-24 wich decodes the data and formats it for the
video overlay module (connected to the video receiver and a 7 inch
color LCD). The controls work the same way but in reverse. The BX-
24 senses the state of its' i/o lines (connected to a few pushbuttons)
and sends that data in a 2 byte string back to the remote BX-24 wich
decodes that and activates the approprate output pin. The onscreen
display gives me ambient temp, humidity, dew point, motor temp,
internal temp (inside the 'tank'), GPS information (Lat, Lon, Alt,
Speed, Heading), and the status of the motor controller and nightime
illuminator(LED). It's probably a little bit on the slow side as far
as computing power is concerned, but then again, I'm not building a
search and rescue robot...or am I?






(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Vector 2x Compass Code - Doug Sutherland - Mar 30 10:08:00 2003

Here is some working BX24 code for the Precision Navigation
Vector 2x Compass. This code uses general purpose pins on
the BX24 (not the SPI port). The PC and SS signals on the
Vector 2X share the same pin on the BX24 to reduce the pin
count to 4 pins used on the BX24. The connections are also
listed in the comments below. Hopefully this will help
someone else avoid days of headscratching (the Vector 2x
manual is hard to understand! The code was based on code I
got from Jeff Sampson (thanks!) who apparently based his
on code from Victor Fraenckel. I stuffed the end result
(degrees) into an integer type and added some code to show
the direction (N,NE,etc). I also tweaked the delays a bit
and streamlined the code a bit. This code simply loops and
reads the compass and sends each reading to the host over
the COM1 serial port. '----------------------------------
' Precision Navigation - Vector 2x Compass - Pin Connections
'----------------------------------
'
' Pin 11 (XFLIP) -> +5V Pin 16 (GND) -> GND
' Pin 10 (YFLIP) -> GND Pin 15 (VCC) -> +5V
' Pin 9 (BCD/BIN) -> GND
' Pin 17 (RESET) -> N/C Pin 6 (CAL) -> +5V
' Pin 8 (M/S) -> N/C Pin 5 (P/C) -> BX24 Pin 10
' Pin 4 (SS) -> BX24 Pin 10 Pin 7 (RES) -> GND
' Pin 12 (CI) -> N/C Pin 3 (SDI) -> N/C
' Pin 13 (EOC) -> BX24 Pin 9 Pin 2 (SDO) -> BX24 Pin 7
' Pin 14 (RAW) -> +5V Pin 1 (SCLK) -> BX24 Pin 8
'
'----------------------------------
' This code uses general purpose pins on the BX24
' Vector2x SS and P/C pins share the same BX24 pin to reduce pin count
'----------------------------------

Option Explicit

Private HostRecvBuf(1 to 2) As Byte
Private HostSendBuf(1 to 20) As Byte

'Vector2x Pin Mapping
Const SDO As Byte = 7 'Vector2x Pin 2 (Serial Data Out)
Const SCLK As Byte = 8 'Vector2x Pin 1 (Serial Clock)
Const EOC As Byte = 9 'Vector2x Pin 13 (End Of Convert)
Const SS As Byte = 10 'Vector2x Pin 4 (Slave Select)
Const PC As Byte = 10 'Vector2x Pin 5 (Poll Continuous)

Sub Main()

Dim Degrees As Integer
Dim Direction As String * 3
Dim MSB As Integer
Dim LSB As Integer
Dim ClockCnt as Byte

'Open Host Communications Port
Call OpenQueue(HostRecvBuf, 2)
Call OpenQueue(HostSendBuf, 20)
Call OpenCom(1, 19200, HostRecvBuf, HostSendBuf)

'Define Vector2x Pin States
Call Putpin(PC,1)
Call PutPin(EOC, bxInputPullup)
Call PutPin(SDO, bxInputPullup)

Do
'Set Poll Continuous Mode
Call Putpin(PC, 0)
Delay(0.012)
Call Putpin(PC, 1)

'Wait for End Of Conversion
Do While(Getpin(EOC) = 0)
Loop
Delay(0.012)

'Set Slave Select Low
Call Putpin(SS,0)
Delay(0.012)

'Read MSB from SDO
MSB=0
For ClockCnt = 1 to 8
Call Putpin(SCLK,0)
Call Putpin(SCLK,1)
MSB = MSB * 2 + CInt(Getpin(SDO))
Next

'Read LSB from SDO
LSB=0
For ClockCnt = 1 to 8
Call Putpin(SCLK,0)
Call Putpin(SCLK,1)
LSB=LSB * 2 + CInt(Getpin(SDO))
Next

'Set Slave Select High
Call Putpin(SS,1)

'Calculate Compass Degrees
Degrees = ((CInt(MSB) And 15)*100) + ((LSB\16)*10) + (CInt(LSB) And 15)

'Send Reading to Host
If Degrees < 360 Then 'Ignore out of range readings
Call PutQueueStr(HostSendBuf, CStr(Degrees) & " ")
Direction = ""
If Degrees < 12 Then
Direction = "N"
ElseIF Degrees < 34 Then
Direction = "NNE"
ElseIF Degrees < 57 Then
Direction = "NE"
ElseIF Degrees < 79 Then
Direction = "ENE"
ElseIF Degrees < 102 Then
Direction = "E"
ElseIF Degrees < 124 Then
Direction = "ESE"
ElseIF Degrees < 147 Then
Direction = "SE"
ElseIF Degrees < 169 Then
Direction = "SSE"
ElseIF Degrees < 192 Then
Direction = "S"
ElseIF Degrees < 214 Then
Direction = "SSW"
ElseIF Degrees < 237 Then
Direction = "SW"
ElseIF Degrees < 259 Then
Direction = "WSW"
ElseIF Degrees < 282 Then
Direction = "W"
ElseIF Degrees < 304 Then
Direction = "WNW"
ElseIF Degrees < 326 Then
Direction = "NW"
ElseIF Degrees < 349 Then
Direction = "NNW"
ElseIF Degrees < 360 Then
Direction = "N"
End If
Call PutQueueStr(HostSendBuf, Direction & Chr(13))
End If
Loop

End Sub



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )