Trouble sending GPS Data through Xbee
RoboTuna
Posts: 25
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
And the receiving unit is using
Sorry for the sloppy code. I am very new to Spin.
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
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.
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.
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
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.
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
Tracy I do not get the IDX part of this. 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.
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?
Thanks for the help Tracy.
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.
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?
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)
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
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.
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.
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.
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.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.