reading API addresses

XBee & XBee Gateway XBee - DigiMesh
1

We’re trying to implement some GPS tracking devices with the DigiMesh modules. We have a small GPS module feeding UART data (ASCII NEMA data) to the Xbee radio. The radios are all set up to send to the radio attached to the PC. This works fine with one radio active. We can see the live NEMA data streaming through with no problem.

The problem is, we can not differentiate the devices. We have the receiving module set to API mode, the GPS modules are set in the default AT mode. With this, we see a “header” in terminal, but it’s garbled data with special characters. We did try reading in a Hex terminal, but it still does not mean anything, and the “header” info seems to change constantly.

Is there something obvious that we have missed here? What do we need to read the address of the sending radio? Once we can figure that out, then we’ll write some code that buffers the data and bundles the individual radios’ data separately.

Thanks in advance,
-Michael

2

I’m not sure I understand the problem here, so bear with me.

Is the question one of how to decode API frames? If that’s what you’re seeing, each frame will start with a 0x7e byte and carry on from there with two bytes of packet length information, followed by the packet type (single byte). After that, what you see depends on the packet type.

API frames are documented in the product manual, and they can also be decoded by my packet-check program (see pinned posts in the 802.15.4 forum).

If I’ve completely misunderstood the question, perhaps you could try to supply a bit more information. One thing that may well help in any case would be if you could capture some output in a binary file and attach that to a post. A couple of kilobytes, say.

3

Yes, that was indeed the issue. But yesterday after some more help from Digi’s tech support, we were able to finally see the hex data being sent from the modem. Now we can see the packet header, address of the radios, and the data.

But thank you for your reply. We’re now trying to implement a program in Java to receive the data and sort it accordingly (still learning our way around those libraries). Let me ask you this–from the manual, we know that bytes 2 and 3 are MSB and LSB, indicating the packet length. But what we calculate by hand does not seem correct. Here is one of our typical packets (NEMA GPS data is the payload):

Header:
7e 01 0c 90 00 7d 33 a2 00 40 78 3f d9 ff fe 01
Data:
24 47 50 52 4d 43 2c 32 30 33 38 31 32 2e 30 30
2c 41 2c 33 35 30 35 2e 32 37 30 35 34 2c 4e 2c
30 38 30 35 37 2e 35 39 37 38 34 2c 57 2c 30 2e
30 31 33 2c 2c 31 35 30 36 31 31 2c 2c 2c 41 2a
36 32 0d 0a 24 47 50 56 54 47 2c 2c 54 2c 2c 4d
2c 30 2e 30 31 33 2c 4e 2c 30 2e 30 32 35 2c 4b
2c 41 2a 32 36 0d 0a 24 47 50 47 47 41 2c 32 30
33 38 31 32 2e 30 30 2c 33 35 30 35 2e 32 37 30
35 34 2c 4e 2c 30 38 30 35 37 2e 35 39 37 38 34
2c 57 2c 31 2c 30 37 2c 31 2e 35 38 2c 31 39 34
2e 38 2c 4d 2c 2d 33 32 2e 37 2c 4d 2c 2c 2a 36
41 0d 0a 24 47 50 47 53 41 2c 41 2c 33 2c 32 33
2c 30 33 2c 31 39 2c 30 36 2c 30 37 2c 31 33 2c
31 36 2c 2c 2c 2c 2c 2c 34 2e 33 34 2c 31 2e 35
38 2c 34
Checksum: 2e

01 and 0c are MSB and LSB, but that would only be a length of 12? That can’t be correct.

4

You must be slightly off on your calculation to get a length of 12 out of 01 0C, because it actually corresponds to a length of 268.

(0x01) * 256+ (0x0C) = 268 decimal.

Chris

5

Ah, I see now… thank you! I’m not a software engineer, which I’m sure is very apparent! Had not converted to decimal.

Thank you very much!

6

cpopp is quite right about the length field, but that’s still not a happy packet because there aren’t 268 bytes there. I would have expected a much shorter packet, due to the limited buffer size in the XBee.

Your data decodes as
$GPRMC,203812.00,A,3505.27054,N,08057.59784,W,0.013,150611,A62
$GPVTG,T,M,0.013,N,0.025,K,A26
$GPGGA,203812.00,3505.27054,N,08057.59784,W,1,07,1.58,194.8,M,-32.7,M,*6A
$GPGSA,A,3,23,03,19,06,07,13,16,4.34,1.58,4

which looks to me like three complete sentences and one incomplete one. I suspect that the 2e value you’re interpreting as the checksum is actually a “.” that is part of the data.

So I think something strange is happening somewhere, although I can’t see exactly what.

Incidentally, I think there’s also an error in the Digimesh product manual. For frame type 90, it says there’s a frame id before the 64-bit address and then lists only 7 bytes for the address. I think there’s no frame id, and that byte is the first byte of the address.

Finally, I see from the packet that you’re using API mode 2. Unless you’ve got a specific reason to use mode 2, you’ll find mode 1 is easier to work with.

7

Hmm, I don’t know why it would be shorter. Here are 2 complete packets, from 7e to 7e. This is indicative of what we’re getting for most packets. The one I posted before may have been incomplete, sometimes a few get through. We’re still in the testing stages with these Zigbee radios and GPS modules.

7e 01 0c 90 00 7d 33 a2 00 40
78 3f d9 ff fe 01 24 47 50 52 4d 43 2c 32 30 33
38 31 31 2e 30 30 2c 41 2c 33 35 30 35 2e 32 37
30 35 35 2c 4e 2c 30 38 30 35 37 2e 35 39 37 38
32 2c 57 2c 30 2e 30 32 33 2c 2c 31 35 30 36 31
31 2c 2c 2c 41 2a 36 35 0d 0a 24 47 50 56 54 47
2c 2c 54 2c 2c 4d 2c 30 2e 30 32 33 2c 4e 2c 30
2e 30 34 33 2c 4b 2c 41 2a 32 35 0d 0a 24 47 50
47 47 41 2c 32 30 33 38 31 31 2e 30 30 2c 33 35
30 35 2e 32 37 30 35 35 2c 4e 2c 30 38 30 35 37
2e 35 39 37 38 32 2c 57 2c 31 2c 30 37 2c 31 2e
35 38 2c 31 39 34 2e 38 2c 4d 2c 2d 33 32 2e 37
2c 4d 2c 2c 2a 36 45 0d 0a 24 47 50 47 53 41 2c
41 2c 33 2c 32 33 2c 30 33 2c 31 39 2c 30 36 2c
30 37 2c 31 33 2c 31 36 2c 2c 2c 2c 2c 2c 34 2e
33 34 2c 31 2e 35 38 2c 34 2e 30 35 2a 30 32 0d
0a 24 47 50 47 53 56 2c 33 2c 31 2c 31 32 2c 30
33 2c 36 35 2c 30 8d

$GPRMC,203811.00,A,3505.27055,N,08057.59782,W,0.023,150611,A65
$GPVTG,T,M,0.023,N,0.043,K,A25
$GPGGA,203811.00,3505.27055,N,08057.59782,W,1,07,1.58,194.8,M,-32.7,M,6E
$GPGSA,A,3,23,03,19,06,07,13,16,4.34,1.58,4.0502
$GPGSV,3,1,12,03,65,0

7e 00 f7 90 00 7d 33 a2 00
40 61 57 f7 ff fe 01 37 36 2c 34 36 2c 30 36 2c
35 30 2c 30 36 31 2c 34 38 2c 30 37 2c 33 31 2c
33 31 31 2c 34 32 2c 30 38 2c 30 36 2c 33 30 31
2c 2a 37 46 0d 0a 24 47 50 47 53 56 2c 33 2c 32
2c 31 32 2c 31 30 2c 30 36 2c 32 38 39 2c 2c 31
31 2c 30 36 2c 31 37 33 2c 32 35 2c 31 33 2c 36
34 2c 32 36 38 2c 34 34 2c 31 36 2c 33 38 2c 30
34 36 2c 34 30 2a 37 44 0d 0a 24 47 50 47 53 56
2c 33 2c 33 2c 31 32 2c 31 39 2c 35 39 2c 31 35
33 2c 34 33 2c 32 31 2c 30 30 2c 30 34 31 2c 2c
32 33 2c 35 33 2c 31 39 38 2c 33 39 2c 33 30 2c
31 35 2c 30 36 30 2c 33 30 2a 37 37 0d 0a 24 47
50 47 4c 4c 2c 33 35 30 35 2e 32 37 30 37 33 2c
4e 2c 30 38 30 35 37 2e 35 39 38 30 30 2c 57 2c
32 30 33 38 31 31 2e 30 30 2c 41 2c 41 2a 37 45
0d 0a e0

76,46,06,50,061,48,07,31,311,42,08,06,301,7F
$GPGSV,3,2,12,10,06,289,11,06,173,25,13,64,268,44,16,38,046,407D
$GPGSV,3,3,12,19,59,153,43,21,00,041,23,53,198,39,30,15,060,3077
$GPGLL,3505.27073,N,08057.59800,W,203811.00,A,A7E

Oh yeah, I noticed that mistake in the manual as well. On page 57, under the packet chart, it says the address is"0x0013…" and the 00 is the frame ID, not part of the address.

Yes, we are using API mode 2, I read that for the Java this was necessary? Currently we’ve got a proof-of-concept program in VB6, and we’re just toying around with Java. But if we can use API 1 and eliminate that escapes, that would be fine.

8

Ok, those are good packets. Looks like things are going well.

If you’re using a Java library that insists on API=2, then that counts as a good reason to use mode 2 :slight_smile: The other good reason to use it is if you want end-to-end XON/XOFF flow control. Or if you’re expecting noise to affect the serial line and want to be able to resync reliably to the start of the next packet. But unless the serial line is very long, noise isn’t usually a problem. Failing any of these reasons, there’s really no need (IMHO) for mode 2.

Oh, and thank you for educating me - I really thought packets that long were impossible. You’ve proved me wrong :slight_smile:

9

I was looking at one of the Java libraries from Google, but honestly I’m not seeing much of a reason to use that. We’re not sending commands to the radios, we just need to receive the data and go. Since we have it functioning in VB right now, I just have to play around some more with Java to get it working the same way.

Basically all we’re doing is reading the serial data, finding the 7e start and end of a packet, reading the address and reading the data. Then those two pieces of info go out a port to the GPS software. I’m sure it’s trivial for someone with programming experience… I’m still trying to remember half the Java commands lol

10

Well, I hope it all goes well. I’ll leave you with a free tip: watch out for modem status packets. They can be sent by the XBee under certain conditions such as a power interruption, so they may arrive at any time. That means you always need to check the type of any packet you receive, so that if it’s modem status you can either discard it or react appropriately.