My objective is to write a program for my X4 that sends and receives serial data from a bunch of custom devices. I thought I would start with the XBeeSerialTerminal device. Using the serial test board that came with the devkit. I plugged the serial port of the board into my serial port on my computer. I then wrote a quick VB.net application to monitor the serial port and post new data to it as well. I am hoping that I can send data over the serial port and get it at the X4 and then send data from the X4 and see it on the serial port.
It almost works. When I send data from the X4 I get it on the serial port. However, when I send data from the serial port I don’t get the print that I received it from the X4. If, however, when I receive data on the serial port I immediately echo something back out I do get that on the X4.
My real problem here is that the DIA is black magic to me. I don’t understand what is triggering the read event. I can only imagine that the read routine isn’t getting called accept right after the write routine. Any help would be great!
Also I just noticed that I get an error message on the terminal. I don’t understand it at the moment, but maybe it is related. When my vb routine is immediately responding with the word Received I get the following output.
XBeeSerialTerminal: Write Data: taco
XBeeSerialTerminal: Read Data: Received
XBeeDeviceManager(xbee_device_manager):
Exception during rx callback for addr = (‘[00:13:a2:00:40:62:55:15]!’, 232, 49413, 17, 1, 0)
Traceback (most recent call last):
File “C:\Program Files\Digi\DigiPython\Dia\Dia_1.3.8\src\devices\xbee\xbee_device_manager\xbee_device_manager.
py”, line 334, in __select_rx_cbs_for
File “C:\Program Files\Digi\DigiPython\Dia\Dia_1.3.8\src\devices\xbee\xbee_devices\xbee_serial.py”, line 720,
in _read_callback
File “C:\Program Files\Digi\DigiPython\Dia\Dia_1.3.8\src\devices\xbee\common\io_sample.py”, line 99, in parse
is
error: unpack str size does not match format
Commenting out those lines is fine because it eliminates whatever that parsing low battery operation was, and thus the error message. However it still leaves me with my original problem. When I send data over the serial port of the devkit board I only am able to get it at the X4 immediately after I send data from the X4. If I send without having just received I get no response at the X4.
Also, when do we expect the next version of the DIA?
That sounds more like an association problem. Which firmware is running on the dev board? Router or End-Device? Try using an AT router firmware with no sleep-mode.
I am just guessing, but if a child/end-device has work, then is ‘rejected’ by the parent and needs to rejoin, often the message which triggered the rejoin is lost. This might mean the SN/SP of the X4’s XBee is too low. Using AT Router in the dev board eliminates this issue - again, just guessing.
Use telnet into the X4, then enter:
set trace state=on mask=xbee:*
This will dump all of the Xbee messages seen by the X4 - even if Dia is discarding them. You may find that one of the end-point settings in the dev board is causing the packets to have no home (think of sending UDP/IP to dst port 503 when the host is waiting only on 502).
Sorry if this is lots of jargon, but if you see your data under the trace, post the text here and we can decode the end-point info included.
You are correct. I switched the firmware from end device to router and it sends the data and receives it every time now.
This makes me wonder how it is supposed to work. If an end device goes to sleep and then doesn’t send data that I put on the serial port because it is asleep how am I supposed to wake it up?
The problem’s not in the end-device, but the ‘parent’ - the X4.
Look at the Sn/Sp setting under the web ui (see the PDF XBee manual for the meaning). They default to something like 320ms, so in about 1 second the ‘parent’ has abandoned the sleeping end-device, which frees up the memory resource for a new device.
So your device wakes in say 5 minutes, tries to do a fast ‘push’ of your data up to the parent, and it is rejected with a ‘who are you?’ error. The child rejoins, but unless some logic says ‘retry the first message’, it isn’t retried. Your data is lost.
So common Sn/Sp values I use in the X4 is to set SP to 0x07D0, which is 20 seconds and then set SN to some multiple, so:
0x03 = 1 minute
0x0F = 5 minutes
0xB4 = 1 hour
The down-side of too long a parent setting is it takes 3 times this for the parent to free up the resources. So if you have 8 end-devices and the X4 waits 24 hours for them, then if you box those 8 up and power up 8 more, then only 1 or 2 of the new devices can parent under the X4 for a few DAYS. The X4 holds out hope that the original 8 will wake up.
The other thing to watch, say your end-device only wakes and talks if the temperature drops below freezing, the for months it says nothing. There is no way for the X4 to distinguish between a ‘dead child’ and one just happy and silent. So the logic needs to be more like: report every 12 hours if okay, else report faster if the temperature drops below freezing.