Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

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 )

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 )

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 )

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 )

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 )

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 )

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 )