EmbeddedKitService.py

Hi
I’ve got a few questions about the EmbeddedKitService.py program.

  1. Does this program run in API or AT mode?

  2. Does anybody know how the EmbeddedKitService.py program works (besides from the obvious)? I have 3 temperature sensors and i intend to connect each one to its own seaprate Xbee module and situate them in 3 separate rooms. I want to write a program (or maybe use the same one but alter it) to do the same thing but to read from my own sensors instead of the wall router.

  3. Does anybody know how i can alter the program to do this please?

Running the above program currently works fine with my drop in development kit. So i want to exapand its functions onto my own sensors. Please help!!

If you look at the bottom of the article at this link, you’ll find a link for the source code zip:
http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=3063

Once you have the source, feel free to modify it as you please.

Thanks Admin

But i still have my first question unanswered. Does this program run in API or AT mode?

I’ve tested the program with my sensors and i can receive the data from the sensors but it doesnt appear in its correct format. All i get is what’s attached. Note that this is a hyperterminal shot but i get the same thing when running the program.

Does anybody know how i can alter the program so that it can format my data properly please. Data from sensor is in ASCII format.

Thanks

Could you post the binary return (in ASCII representation)?
Set Hyperterm to 8-bit binary and save the data to a file. Then use a binary viewer to examine to data (several viewers are available free) and post a screen shot.
It look like it could be just the Data Payload but it could be an API frame. Hard to tell as not all 8-bit values can be displayed as ASCII. The format would be a function of the XBee firmware rather then the kit-code.

What XBee module and firmware is in the unit?
If the data packet starts with 0x7E 0x00 then this is an API frame and needs decoding to extract the data. Else its a just the data payload which then needs to be parsed to extract the sensor values (if it is an API the data payload format is the same and still needs parsing).

I can point you to the relevant pages if your using XBee ZB firmware but will wait until I know if this is the firmware you are using. No need to add confusion.

thanks waltr

so i’ve done what you’ve asked … i’ve set hyperterminal to 8 bit binary and saved the data in the first screenshot. The rest of the screenshots are the binary view of the data i saved.

The modules i’m using is Znet 2.5 which all have Znet 2.5 router/end device AT, XBP24-B, version 1241. They all came with the drop in networking professional development kit.

Ok meme,
The data is not APT frames since the modules are using AT firmware (also know as transparent mode). The relevant document is # 90000866_C, ZNet 2.5 OEM modules.
The doc (like the ZB doc) shows most commands in the API frames but has very little on just AT data. But, the AT data is just the ‘data payload’ of an API transfer. So read the API frame examples but ignore the APT frame values (delimiter, frame type, cksum, etc).

First, Could you resend one of the screen shots but expand the Hex display to show the full 16 bytes of data across the row (the ASCII part can be cut of as it has no value). You only show 13 1/2 bytes of 16.

I first looked at the Hex data for a repeating pattern (can be seen in the ASCII dump also). Your bi2.jpg at address 0000500 has:
0500 10 00 B5 00 25 00 3E 00 42 00 46 00 01 0? ?? ??
0510 65 00 AA 00 10 00 B5 00 25 00 3E 00 42 0? ?? ??
0520 01 00 40 00 65 00 AA 00 10 00 B5 00 25 0? ?? ??
0530 42 00 46 00 01 00 40 00 65 00 AA 00 10 0? ?? ??
0540 85 00 3C 00 42 00 46 00 01 00 40 00 F1 0? ?? ??
0550 10 00 B5 00 25 00 3E 00 42 00 46 00 01 0? ?? ??
0560 65 00 AA 00 10 00 CB 00 85 00 3C 00 42 0? ?? ??

I see B5 and AA repeated so there is a repeating pattern of 20 bytes. So first guess is that the data payload is 20 bytes long. Now the hard part, which byte is the beginning of the data?

So lets go the the document.
Starting on page 70 is a table of the AT commands. Most likely the data is a response of AT command ‘IS’ (page 74). But what is the data structure of the data? Well its an IO Data Sample and is shown in an API frame on page 65.
Since your module has AT firmware ignore the API frame parts and only look at the ‘cmdData’ starting at ‘Num Samples (byte 16)’. Its structure is:
1 byte- # of sample sets, this is always 1
2 bytes- digital channel mask
1 byte- analog channel mask
2 bytes- digital data
2 bytes per enabled analog

So assuming that the data is 20 bytes, there would be 7 analog channels enabled. Now the first byte is always a 0x01 and I only see one byte set to 0x01 in 20 bytes so it is fairly safe to assume this is the beginning of the data set. line 0520 starts with 01 so the that data set is:
01
00 40
00
65 00
AA 00
10 00
B5 00
25 0?
?
?

Now the problem is that this does not make sense to me. The doc (page 67) indicates that there can only be 5 (including supply voltage) analog inputs. Also the ADC is only 10 bit so a value of 0x6500 is too big (0x0065 is ok) but maybe its byte reversed (little vs big endian).

I haven’t yet found any errors in the other Digi docs but they never were clear until I figured out how the units worked. Then the doc made sense.

When you collect the data again is there a way you could add something to the data stream so its easy to find the beginning of the data set. I’m guessing that there could be another group of values other than the IO data coming through. How about a little more information on how the two modules are setup. This can be figured out and MAYBE someone from Digi will actually gives us the information you need.

I’d also do what Admin suggests and go through the code for the EmbeddedKitService and try to understand how it gets and parses the data.

Thank you so much for that waltr!!!

Attached is are 2 screen shots of the same data but with the Hex column extended … sorry about that.

I’ve also attached the protocol info and data structure sheet for the sensor. According to that info sheet, it says the data stream is 15 bytes. This data sheet should also help us determine the beginning of the data set. I hope this helps to give a little more info.

I’ve been trying to go through the source code too but since i’m new to python it hasnt been that easy.

The rest of the binary screen shots with Hex expanded

Ok, the Hex data screen shots are better.

But I’m a little confused by the p1, p2 & p1 files. These are for a AeroQual sensors. Are these units sending binary data into the UART of the XBee ZNet module?
The decoding I went through on my last post assumed that you were connecting a temperature sensor to one of the XBee analog inputs and was receiving the XBee IO data samples. This makes a huge difference…
I like decoding challenges so will take a look at the docs for the Aeroqual and see if your hex data fits in.
I did see 0xAA in your data and on p2.jpg in section 2. The 0xAA looks to be the beginning of an OEM sensor regular data report command (sec1.1) but the 15 bytes is a question.

At least your original question has been answered. The ZBee modules have AT firmware therefore any serial data into one module comes out the other UART un-changed.

Hi waltr

yes, sorry, the sensors i’m using are not Digi sensors. They’re gas sensors by Aeroqual. p1, p2 & p3 files are the protocal sheets they gave me. I’m trying to use the Xbee modules to create a wireless network and relay the data from the sensors to a host pc via the xbee modules. My setup looks like this: i have 2 Xbee modules each connected to a sensor, both are a distance apart. I also have a xbee wall router (which i dont think i need but have added that in my network). My gateway (ConnectportX2) is connected via ethernet to my pc.

Actually, when i run the Embedded Kit Gateway viewer application, i initially thought the data looked the same as what i get when i connect the sensor directly to the pc and use hyperterminal. But i’ve just realised after trying again that the data looks different for both. The screenshot i’ve attached is the data i get when i connect the xbee module to the sensor and run the Embedded Kit Gateway viewer application.

The second screenshot is the hyperterminal view of the data. i.e. when i connect the sensor to my serial port and run hyperterminal…similar to one of the first screenshots i’ve posted.

I’m not too sure how i can view the binary form of the data from the Embedded Kit Gateway viewer application.

Yes i can see that 0xAA is the beginning of the data stream … i only assumed it was 15 bytes cos that’s what it said on p1.jpg (section 1.1)

Do you think it would be better if i changed the firmware and use API firmware? or would that complicate things more.

Thanks again for your help! I really appreciate it!!

meme,
Trying to look at binary data with an ASCII display is almost useless. Its best to convert the binary (hex) into two ASCII characters like is displayed in the hex viewer.
The difference between the two displays is most likely from what their code does with ‘extended’ (8bit)ASCII and the binary values may be exactly the same.

What I do is add some lines of code into the software to convert and print the ASCII representation. There are several examples around on how to do this in Python. Then find the line in the Embedded Kit code where it outputs the data and replace (comment out) the original code.

Look back at the Areoqual docs. There are several output formats and you need to look at the correct one to decode the binary data. The one that says its 15 bytes long starts with 0x55 0xAA whereas the output you are getting seems to start with 0xAA 0x00 which better fits the data in the next sub-section.

An important thing to realize is that the Embedded Kit Gateway Viewer application was designed with a very specific purpose in mind: to loopback data on a Digi RS232 XBee adapter, and to receive a Temperature reading from the Digi XBee 1-Wire Sensor adapter with Watchport/T 1-Wire Temperature sensor attached to it. These two XBee adapters come with the Drop-In Networking Starter Kit, for which the app was designed as a bundle with.

The following link is to our python mediawiki, where you might find python code examples which would be more relevant for use with your Aeroqual gas sensors:

http://www.digi.com/wiki/developer/index.php/Python_Wiki

Ok meme I think I have your data decoded.

Raw from your screen shot:
0510 65 00 AA 00 10 00 B5 00 25 00 3E 00 42 00 46 00
0520 01 00 40 00 65 00 AA 00 10 00 B5 00 25 00 3E 00
0530 42 00 46 00 01 00 40 00 65 00 AA 00 10 00 CB 00

Breaks down into this:
with the converted values after =>

SENSOR 00 AA
DATA_REPORT 00 10
DATA1 00 B5 00 25 =>1.662227665263959e-38
DATA2 00 3E =>6.2
RESERVED 00 46 =>7.0
STATUS1 00 01 => sensor failure
STATUS2 00 40 => sensor zero
CHECKSUM 00 65

And the Cksum works.
Sum of
[00 AA 00 10 00 B5 00 25 00 3E 00 42 00 46 00 01 00 40]
= 29B

FF - 9B + 1 = 65, the Cksum

So the Sum of
[00 AA 00 10 00 B5 00 25 00 3E 00 42 00 46 00 01 00 40 65]
= 300 or in 8-bits = 00

Yep, it is actually 20 bytes but this isn’t the first time I’ve seen data sheets not match what the unit does send out. This always makes for a lot of fun getting things to work.

I think you should be able to correlate the above to Areoqual’s data sheet. Just make every place they say 1 byte = 2 bytes.

Here is a link to an IEEE-754 calculator:
http://babbage.cs.qc.cuny.edu/IEEE-754/32bit.html

Wow thanks heaps waltr! This has really helped me understand a lot.

From your break down, i think you missed out DATA3? I think it’s meant to be:

SENSOR 00 AA
DATA_REPORT 00 10
DATA1 00 B5 00 25 =>1.662227665263959e-38
DATA2 00 3E =>6.2
DATA3 00 42
RESERVED 00 46 =>7.0
STATUS1 00 01 => sensor failure
STATUS2 00 40 => sensor zero
CHECKSUM 00 65

So, now that the data has been decoded, correct me if i’m wrong, all i need to do now is find some code on how to decode this in python, and use it in the EmbeddedKitPCApp.py source code so that it can decode the sensor data as it arrives in the Xbee module?

Thanks so much for your help Waltr! I’m so new to this and your help has really taken me far!

Yep, I missed DATA3 (just testing you, lol).

In Python there are several ways to decode this. Looking at some of the code we have mentioned in earlier posts, like to decode an API packet, should give you ideas on how to go about it. There is also some other Python code for XBee’s on the web that’s easily found.

I did try to walk you through the process so you understand the decode and how to go about it the next time.

An additional note: The Aeroqual data sheet is correct in that there are 15 bytes of data. What it didn’t say is that the bytes are on word (16-bit) boundaries.

Good luck