Shop OBEX P1 Docs P2 Docs Learn Events
Trouble sending GPS Data through Xbee — Parallax Forums

Trouble sending GPS Data through Xbee

RoboTunaRoboTuna Posts: 25
edited 2013-02-23 09:36 in Accessories
I am trying to send a Latitude and Longitude location received from VPN1513 GPS and from one xbee to another both are on Prop BOE. I can get the Lat and Long on the Board that has the GPS attached to it and lets say it reads Lat 41.XXX and Long -71.XXX when i send it from one board to the other it shows up as a different number. Any help with this would be great. I know it comes in as a Float number for the GPS using the smart mode object and to get the actual deg you have to convert it to string. This is one of the major issues that is holding my project back.

The sending unit is using this Code
OBJ  
  PST  : "FullDuplexSerialPlus"
  XB   : "FullDuplexSerialPlus"
  FS   : "FloatString"
  GPS  : "GPS_SmartMode"
  F    : "FloatMath"
CON


  _clkmode        = xtal1 + pll16x
  _xinfreq        = 5_000_000
PUB start
  PST.start(31,30,0,9600)
  GPS.start(GPS#EASTERN_TIME, TRUE)
  XB.start(5,4,0,9600)                                 
  repeat
    PST.str(String("It Works!"))
    PST.tx(13)
    WriteLatitude  
    WriteLongitude    
    waitcnt(clkfreq / 2 + cnt)
     
PRI WriteLatitude | Lat 
  Lat := GPS.GetLatitude
  XB.tx(FS.FloatToString(Lat))
  PST.str(Lat)
  PST.tx(13)
  
PRI WriteLongitude | Lon
  lon := GPS.GetLongitude
  XB.tx(FS.FloatToString(Lon))
  PST.str(Lon)
  PST.tx(13)

And the receiving unit is using
OBJ  
  PC : "FullDuplexSerialPlus"
  XB : "FullDuplexSerialPlus"
  FS : "FloatString"
  F  : "FloatMath"
CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000


  XB_Rx = 3
  XB_Tx = 2
  Baud = 9600


  PC_Rx = 31
  PC_Tx = 30


PUB Go | A, B


  PC.start (PC_Rx, PC_Tx, 0, Baud)
  XB.start (XB_Rx, XB_TX, 0, Baud)
  
  PC.rxFlush
  repeat
    PC.tx(1)
    XB.rxFlush
    A := XB.RX
    B := XB.RX
    PC.str(A)
    PC.tx(13)
    PC.str(B)

Sorry for the sloppy code. I am very new to Spin.

Comments

  • SRLMSRLM Posts: 5,045
    edited 2013-02-11 23:39
    Can you post your full code, including FloatMath, FloatString, and GPS_SmartMode?

    Anyway, one thing that I see is that you TX (a single byte) the return of FS.FloatToString(Lat/Long). That's unlikely to be what you want.

    Second, you probably don't want to flush the buffer in your receive loop. Why? Because then you'll probably throw away data that you need.

    Third, you'll need some sort of sync character over the XBEE link that tells your receiver that the following bytes are worth listening to. Otherwise, your receiver may start listening in the wrong place (and misinterpret it).

    Finally, you should read up on how strings are stored at a low level. There's some misunderstanding that I see. A tutorial on "C String" would be a good place to start.
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2013-02-12 01:07
    Here is a thread on GPS_smartMode. Might have some insights.

    Is the VPN1513 GPS mounted on a module together with a propeller chip and there is are separate propellers on the two BOEs? Just getting this straight.

    Lat := GPS.GetLatitude
    XB.tx(FS.FloatToString(Lat))
    PST.str(Lat)

    The number returned by FS.FloatToString(Lat) will be a pointer to a null terminated string, so the XB command should be XB.str() not XB.tx. Similarly, the value Lat remains a long, so the next instruction too should be PST.str(FS.FloatToString(Lat)). Just guessing so.
  • RoboTunaRoboTuna Posts: 25
    edited 2013-02-12 18:31
    Is the VPN1513 GPS mounted on a module together with a propeller chip and there is are separate propellers on the two BOEs? Just getting this straight.

    You are correct. The GPS has a prop chip on it. Hind sight is 20/20 if I had realized it before I probably would have just used the module as a stand alone. But I like the Xbee socket on the BOE and the ease of Prototyping changeovers.

    So if I use the XB.str() to send the string to the other Xbee how would I go about receiving it. Would I use A := XB.getstr() to get and store it.

    One more question if I just wanted to send the float number that the Get_Lat returns over what would I use to transmit it XB.dec() or something else.

    Thanks again
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2013-02-12 20:27
    The XBee sends one byte at a time. Larger chunks, such as the long that holds the float value, have to be broken up into pieces. 4 pieces for a long.
    repeat idx from 0 to 3
      xb.tx(lat.byte[idx])
    

    That sends the bytes of the long, most least significant first. To receive on the other end, you have to receive those 4 bytes and piece them back together into a float.

    The receiver has to know where the transmission of a new value starts and stops. This can be done by having certain dead times between the transmissions, or by careful use of the packet process of the XBee, especially in API mode. If the values are sent as strings, a unique -start or -stop character that is not otherwise in the string can bracket the actual data.
  • max72max72 Posts: 1,155
    edited 2013-02-13 03:24
    I did something similar to read data from an anemometer.
    I simply parsed it, made calculations, converted it to an NMEA style string to be sent via XBEE. I then parsed it back with a modified GPS_IO_mini on the other side.

    Massimo
  • RoboTunaRoboTuna Posts: 25
    edited 2013-02-16 11:41
    I am still having trouble understanding this. I have tried the sending part I just do not understand the receiving part so I don't know if it is actually getting there. This is for a school project so I am kinda under the gun for a dead line.

    Tracy I do not get the IDX part of this.
    repeat idx from 0 to 3 
      xb.tx(lat.byte[idx])
    
    Also would you be able to post the receiving part of this line. I am sending two Long values would that mean I need to send 8 bytes 4 for 1 and 4 for the other. Then split them apart of the other side.
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2013-02-18 08:41
    It's been a couple of days. Have you made progress on this? If you don't have it already, Martin Hebel's text, Getting Started with XBee RF modules is a great reference. The text is available for download or for sale in print. Also, there is an XBee_Object written by Martin. It provides a lot of XBee support routines wrapped around fullDuplexSerial.

    In your code, you are sending data in transparent mode directly to a preconfigured XBee and that is fine too. Have you done any special configuration using XCTU, or are you using the default configuration? In particular, have you been able to receive plain text as sent by say,

    XB.str(String("It Works!"))

    There are quite a few ways that you could send and receive the GPS data. To start out I'd recommend sending it as a plain text string, so that you can see the plain text on a terminal screen at the receiving end without an intervening math. What will you need to do with the data once you have it on the other BOE?


  • RoboTunaRoboTuna Posts: 25
    edited 2013-02-18 19:34
    I played around with the tutorial a little bit I have dont fully understand it but I am going to try a few things. I have not been able to get plain text to work. As of right now I have been only able to send and receive one digit dec like 1 or 2. I need the Degrees to use in a math equation to take lat and long from two GPS locations and find distance and direction. I know I will probably have to do this in Float and I have the equations so I just need to get the float number over or send the string and convert it back to float. I think it would be easier to send the float number that the GPS gives me then convert it to string send it and then convert it back to float to do the equations.
  • RoboTunaRoboTuna Posts: 25
    edited 2013-02-18 20:03
    NVM I just got it to work. I used a ! to start it looking and then sent the first number then a , then the Second number then a CR and it works perfect.

    Thanks for the help Tracy.
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2013-02-20 09:51
    Congratulations, working is good!

    Sometimes the characters "!" and "a" will occur in the binary data, so I hope you have some kind of timing mechanism to allow the receiver to distinguish one packet from the next. Watch out for the ATRO parameter (packetization timeout) The default is 3 milliseconds. You want each packet to be sent as one complete unit.

    If you want to get into this more, do dig into the API mode.
  • RoboTunaRoboTuna Posts: 25
    edited 2013-02-20 14:11
    Okay Ill look into the API mode.

    I am using the Program that was in the tutorial for the XBee "Multi decimal receiver" and I spliced it into my program. Sorry about the typo its an "," not an "a" but I will keep an eye on it. There is a timer on the XB.RXDECTime(3000) I do believe. I was using the 2 X-ctu terminals and watching both the sending xbee and the recieving xbee and the numbers were always the same. So it seems that the way I am receiving the data is pretty accurate. Because the last number being left off is kinda big when talking Latitude and Longitude.

    I don't know if this question can be asked in this thread but if I was looking at storing these two data points in a table for looking up later is that something I can do fairly easily after receiving the data from the other Xbee?
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2013-02-20 18:56
    Storing data in a table for looking up later? You now have the data in variables, so maybe you mean storing it in the eeprom so that it sticks even if power is cycled? You could set up that location as named data.
    DAT
    latStore long 0
    then with the basic_i2c_driver
    i2c.WriteLong(i2c#BOOTPIN, i2c#EEPROM, @latStore, lat)
    That puts the value in the eeprom image. If reset occurs and the hub is reloaded from eeprom, the new value will magically be found at that location.
    lat := i2c.ReadLong(i2c#BOOTPIN, i2c#EEPROM, @latStore)
  • RoboTunaRoboTuna Posts: 25
    edited 2013-02-20 19:05
    I was more thinking like a table so you could store multiple locations and the bot can read them one after another. kinda like dropping bread crumbs. Bot gets first location and as it is moving to it it gets second and possibly third and so on.

    Okay to explain my project a little it is going to be a bot that follows a user thru GPS coordinates. I would like it to us the bread crumb method of point to point navigation. Also later I was thinking of having it stay while the User walked a path and when needed call for the bot. So I would need some sort of storage table to save the values so the bot can follow at a later time.

    I like the idea of putting it in the eeprom just in case it resets randomly so all the data would not be lost. Like I said before this is very new to me and I might have bit off more of a senior project then I can chew in the time a lotted. I am going for Mechanical Engineering so not a whole lot of programming was taught. haha
  • garyggaryg Posts: 420
    edited 2013-02-20 21:19
    "am going for Mechanical Engineering so not a whole lot of programming was taught. haha "

    The Mechanical Engineering aspect of building things is very important.
    I've read in several locations on the internet that:
    If you build a Poorly designed platform, you will have a not so good robot.
    If you build a Poorly designed platform with very good electronics you will still have a not so good robot.

    I have also read on the internet that:
    If you want to go boating, Buy a boat
    If you want to build a boat, then build a boat.

    I'm thinking that in some way, these are words of wisdom.
  • SRLMSRLM Posts: 5,045
    edited 2013-02-20 21:31
    garyg wrote: »
    "am going for Mechanical Engineering so not a whole lot of programming was taught. haha "

    The Mechanical Engineering aspect of building things is very important.
    I've read in several locations on the internet that:
    If you build a Poorly designed platform, you will have a not so good robot.
    If you build a Poorly designed platform with very good electronics you will still have a not so good robot.

    I remember going to the senior design presentations for the ME class at my university, and being stunned by a group that made a "stair climbing robot". They had a very nice CAD model that clearly showed the steps. Their physical prototype was a piece of metal with 4 wheels on fixed axles, and an Arduino resting on top (no wires connected). As it turns out, you need both the mechanical design and the electrical design.

    And I disagree with your quote: you can have a very good robot with a poor mechanical system. The electronics and software compensate for the deficiencies in the underlying hardware. Case in point: the Kiva automated warehouse robot was designed with that philosophy. The reliability and robustness of their system stems from the software side of the robot, not the hardware.
  • garyggaryg Posts: 420
    edited 2013-02-21 22:19
    Hi
    I went to the KIVA site and looked at their information.
    The KIVA 1815, at least from the cover housing does not appear to be a poorly designed platform.
    Proof of concept type of platforms do not need to be particularly robust.
    It would appear to me at least, that the KIVA people exploited the necessary software to get a basic platform to prove the concept.
    I'm thinking that the Mechanical design of their system received the appropriate attention.
    I still think that Robust software cannot make up for a mechanical nightmare.

    I'm sorry to a point, I really did not realize that I had made this discussion go Way Off it's original path.
    I'm very interested in XBee wireless communications.
    I'll try not to let it happen in the future.
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2013-02-23 09:36
    RoboTuna wrote: »
    I was more thinking like a table so you could store multiple locations and the bot can read them one after another. kinda like dropping bread crumbs. Bot gets first location and as it is moving to it it gets second and possibly third and so on.

    You can set up a table in the hub ram either as VAR or DAT, and also an index to point into the table. From what you say, it may need two pointers, one for crumbs in, one for crumbs out.
    [SIZE=1][FONT=courier new]VAR
           long crumbs[30]   ' set aside 120 bytes for 15 latitudes and 15 longitudes
           byte crumbin, crumbout    ' pointers
    [/FONT][/SIZE]
    
    Then each time a new waypoint comes in via the XBee, put it in the table at location crumbin:
    [SIZE=1][FONT=courier new]      crumbs[crumbin++] := lat
          crumbs[crumbin++] := lon
          crumbin /= 30   '  the pointer moves in a circle.
    [/FONT][/SIZE]
    
    Same thing when taking crumbs out as the bot follows.
    [SIZE=1][FONT=courier new]      lat := crumbs[crumbout++] 
          lon := crumbs[crumbout++]
          crumbout /= 30   '  this pointer follows the crumbs
    [/FONT][/SIZE]
    
    There's a bit more to it--Be sure the pointers don't overrun one another and be sure the bot doesn't head for timbuktu instead of kalamazoo--But that is the basic idea. The hub data can be copied over into the eeprom too, if you want the memory retention.
  • Can somebody please post their codes to get gps data to transmit from one xbee to another (one which is fixed to the pc)
    Im very new to this and i have to finsh my project in a week. Please help
    (Also if you have gps and also alttiude transmission pls post it )
  • sarahlove wrote: »
    Can somebody please post their codes to get gps data to transmit from one xbee to another (one which is fixed to the pc)
    Im very new to this and i have to finsh my project in a week. Please help
    (Also if you have gps and also alttiude transmission pls post it )

    Welcome to the Forums!

    Do you just want to transmit data from a GPS through the remote XBEE to the PC with another XBEE? Should be simple just using a terminal program on the PC side.

Sign In or Register to comment.