Router/Coordinator test code not working in some FW versions

Setup is one router and one coordinator from a digi-Mesh Kit with XB3-24 modules compatible with pre-100D FW in transparent mode to simply transmit data from router to coordinator and used TeraTerm on a PC to view incoming data. The code below executes as expected with FW versions 1006, 1007 and 1008 being 3 ‘Hello World’ followed by streaming ‘10.0’ in the infinite loop. FW version 1009 and higher only the first ‘Hello World’ comes thru and the red RSII leds are then off and the association leds are blinking indicating the modules are still associated. The ‘AI’ error code in the router is 0x21 when checked with XCTU and ‘AI’ in the coordinator is zero. I’ve tried a number of things with no success and am truly stumped. The reason as to why this problem occurs is key to my actual larger project. Thank you all or any for help.

Code below


Router - CE=0,ID=2019,JV=1,SP=0x1f4,AP=0,SM=0; other fields at default

import xbee, time

def network_status():
# If the value of AI is non zero, the module is not connected to a network
return xbee.atcmd(“AI”)

while network_status() != 0: # establish network connection
time.sleep(0.1)

time.sleep(5)

test_data = ‘Hello World!’
xbee.transmit(xbee.ADDR_COORDINATOR,test_data)
time.sleep(1)

xbee.transmit(xbee.ADDR_COORDINATOR,test_data)
time.sleep(1)

xbee.transmit(xbee.ADDR_COORDINATOR,test_data)
time.sleep(1)

while True:
x = 10.0
temp = “ch1:%.2f\n” % x
xbee.transmit(xbee.ADDR_COORDINATOR, temp)
time.sleep(1)


Coordinator - CE=1,ID=2019,JV=0,SP=0x1f4,AP=0,SM=0; other fields at default

import xbee, time

def network_status():
# If the value of AI is non zero, the module is not connected to a network
return xbee.atcmd(“AI”)

time.sleep(1)
while network_status() != 0:
time.sleep(0.5)

node_list =
while len(node_list) == 0:
node_list = list(xbee.discover())

while True:
x=1

p = xbee.receive()

The AI of 21 indicates no PAN’s found within range. Do you have antennas connected?

Have you issued a Network Reset on your Router? That is the ATNR0 command.

Please note that the firmware you are using is the Zigbee versions. I would suggest making sure that you are using the Zigbee manuals for this.
https://www.digi.com/resources/documentation/digidocs/90001539

Yes I am using the antenna’s from the digi mesh kit and they are connected to the modules on the Grove board the kit comes with. The physical distance apart on these are handful of inches to a foot in front of me on my work bench next to my PC. The coordinator is connected to the PC with your micoUSB to USB cable. The Router is powered with a rechargable 1000 ma Lithium battery pack thru the 2 pin PH connector on the Grove board. This is the physical setup when I start-up the modules hence running the micopython code I flashed into them. Yes I am using the ZigBee manuals.

Here’s a clearer picture how I do things.

I use XCTU to do all configuration settings and it’s internal MicroPython terminal to flash the code into a module (at the >>> I import os and then os.format() before every micropython code flash of ctrl f followed by ctrl d). I only have one module at a time connected to XCTU thru the microUSB to USB cable to the PC when I do settings and flash a module. From here I connect things as I described above. First I connect the Coordinator to the PC via the cable (network discovery time is 0xFE, 254 seconds, so I have plenty of time to power up the Router with the Lithium battery) then I run and setup TeraTerm (or the serial console in XCTU optionally) so a terminal is ready when I plug the battery into the grove Router board to view the data the coordinator received from the router. I can also use the reset button on the router too if within the network discovery time.

Where in my micropython code for the router and/or coordinator or both would you like me to put the AT command NR0 to be executed?

Notes: The ‘AI’ = 0x21 I see on the router is when after I powered down the setup and connect the router to XCTU and look at the configuration settings is where I saw that. I think that got set because powering down is literally unplug the modules hence losing power and I usual unplug the coordinator first I noticed of myself.

The coordinator can be flashed with any FW version (1006,1007,1008,100A,100B,100D for example) and if the router is flashed only with a working FW version (1006,1007 or 1008) the code runs as expected ie ‘Hello World’ 3 times and then streaming ‘10.0’. If the router is flashed with a FW version not 1006, 1007 or 1008, the code only does ‘Hello World’ the one time with any FW versions that are in the Coordinator.

I noticed the paste above in my original post that appropriate indentations in the micropython code are not there. I can assure they are in the actual code.

Do you have any code you can share that I can program the coordinator and router with that runs in transparent mode similar to mine that is known to work with FW versions 100D and higher. The XB3-24 modules that can be purchased nowadays can only use FW version 100D and higher. I did purchase a new digi Mesh kit that has the newer modules and they came with FW 100D. I also programmed them with my code and the code only executes one ‘Hello World’ just like my older digi Mesh kit. Also I have been to and am aware of digidotcom website for code snippets as a resource and within the ZigBee manuals and actually my code uses some of them.

My large project actually is more suited to run in transparent mode as it’s more like a laboratory setup that I need to stream live near real time data from 6 to 10 independent sensors into one coordinator each at a rate of about 4 samples per second and get that data into a PC for analysis by a custom program I wrote in Python and QT. This code I flash into the xbee3zigbee3 modules is much more complex than the test code and it works fine as long as the FW versions are 1006,1007,1008. But new modules that will be used can only be FW versions 100D and higher and my actual code does not run. I narrowed down the problem to the test code I pasted; seems transmit() works only once and on the first encounter and won’t allow another or following transmit() successfully.

I actually have built custom PCB with modules and other electronics components on them and been running my large project successfully for months. I recently upgraded the FW and at the same time noticed new modules only work with FW 100D and higher and for me out of the blue this problem happened. I really have put many hours into finding the problem that I can’t solve before posting here.

Again I honestly thank you for helping and hope you will continue to help.

I implemented ATRN0 inside the flashed micropython code on the router a couple different ways (including resetting and re-discovering the coordinator) and also thru XCTU console and it made no difference ie the problem still persists. Since FW version 1009 is the earliest showing my problem, is there some change in that version from the priors that may help me as a clue? I have read the releases notes but maybe Digi has something with more detail. Is there a library I may need to include (import) that wasn’t required earlier? I also hard coded the coordinator address instead of the xbee.ADDR_COORDINATOR constant in transmit() and no difference. Also set ID to zero so should connect to any network and no difference. I’m happy to try any settings or ideas. Thanks for the ATRN0 idea to test.

May I suggest you use the 802.15.4 firmware options. I would also suggest using the latest versions on ALL of the modules (200D or above).

In your application, I would suggest testing by simply setting up to use an ADC line on the remote radios and place the Central collector in API mode. Then set the Sample rate on the remote so that it sends the packet periodically.

That’s a wonderful idea and thank you very much. I get where you going here. For the near future I probably do not need the features of meshing (for me it’s to hop very long distances ie repeater like set-up and some large structures of high interference to be able to hop around). It’ll be next week until I can update my findings with this new idea.

As a sidebar, I reworked the test code to instead from sending data from router to coordinator to do the opposite ie send data from coordinator to router. No changes in the results that matter. It still would be nice if can figure out why zigbee version I have this problem in case some addition ideas pop up for you. Thanks, thanks,thanks.

What is the NJ value set to on the Coordinator and parent routers?

What is the ID and II values set on all of the radios?

what is the SC value on all of the radios?

mvut, I’ll get those settings for you in a follow-up response later today as I’d like to tell you about some test results. Issue centers on using ADDR_COORDINATOR or alternately retrieving DH,DL within the endpoints micropython code to get coordinator address. There is either something in settings I am not doing right or there is a bug in the firmware.

First I completely converted to 802.15.4. Second these results are from my large project.

Set-up: Transparent mode, 2 endpoints (these are I2C sensors streaming data to coordinator) and 1 coordinator, My PC software is like an oscilloscope graphing the data from each endpoint(sensor) and this time I am running them at 20 samples/sec. I also can power-up and power-down at will to start/stop data flow for each channel once the coordinator establishes the network (data either scrolling across screen or pauses like a frozen picture and separate graphs per channel).

Results (using transmit with ADDR_COORDINATOR): Fire up PC software, power-up coordinator to establish a network, Power-up only endpoint ‘1’. Data graphing as expected (20 samples/sec). Now power-up endpoint ‘2’. Endpoint ‘1’ now slows down to about 6 samples/sec and endpoint ‘2’ graphing as it should at 20 samples/sec. If I power-down endpoint ‘2’, endpoint ‘1’ now graphs correctly back to 20 samples/sec. If instead I power-down endpoint ‘1’, endpoint ‘2’ still streaming correctly and the same 20 samples/sec. If I reverse the start-up sequence (‘2’ first then ‘1’) same thing just flipped around. I suspect transmit() in endpoint ‘1’ got slowed because generating a lot of exception errors but some transmissions get thru to the coordinator. So now I decided to get rid of ADDR_COORDINATOR and switch to retrieving the coordinator address via AT commands for DH and DL on the endpoints within the endpoint micropython code.

Results (DH/DL): Initially much to my surprise EXACTLY the same outcome as ADDR_COORDINATOR results. But micropython likely retrieving ADDR_COORDINATOR data from reading DH/DL anyways so this does make sense. Now I literally hard code the coordinator address (b’\x00\x13\xa2\x00\x41\x98\x1b\x59’) in transmit().

Results (hard code coordinator address): Everything runs beautifully, 20 samples/sec for each channel (endpoints). Yes using latest firmware everywhere, bauds 115,200 and no not overloading baud data rate with too much data; can’t be a collisions issue either. I can run 6 channels (endpoints) at 20 samples/sec with no problems.

So I’m either doing something wrong with settings but I do think it is a bug issue. I hope if my error you have some ideas. Since back when I was doing ZigBee version, ADDR_COORDINATOR arose there as well and likely there is some similarity between ZigBee firmware and 802.15.4 firmware (similar lower layers), I suspect once figured out that the ZigBee version will work as well. Thank you so much.

Added: I do need to retrieve coordinator address within endpoint micropython code instead of hard coding for my application. Hard coding isn’t a possible solution for me.
Thanks

802.15.4 offers both 64 bit and a user defined 16 bit address function. You can even mix the two. So in your case, you can set your coordinator (master) to a user defined 16 bit address such as 1 or 20. Then your code on your end device can simply send data to this known 16 bit address. On the master side, you can do a Node Discovery to obtain the 64 bit address of the remotes or you can use API mode and read the 64 bit address of the remote radios when the data comes in.

mvut, Yes I did the ‘MY’ thing as well like you describing besides 64 bit (which is the test I described) and data transfers as expected. In the more end-product versions, situations are going to arise where a single ‘system’ consists of say 1 master and 6 slaves and in this application a few systems in the same proximity need to function. In addition each system needs to be able to expand the number of slaves and in that instant and say the owner of that particular system adds channels (slaves) it will be unknown to code the slave for that specific master address and that owner will likely not be capable of operating XCTU nor OTA updates. To confuse things more, the amount of data per packet (transparent mode) or frame (API mode) may increase such that at 115,200 baud, for example, limit is 10 channels because of data load hence a second system or more is needed. Yes can up the baud rate but that might be an interface problem with the GUI software limitations on a PC. Slowing sample rate to reduce data load (hence more channels/slaves per system) causes issues with accuracy on how this system works (I either need precise slave timing to start all A/D’s on I2C sensor within a few milliseconds of each other or sample fast enough free running that the timing jitter or alignment meets the timing required. ZigBee really is what fits my application as I am finding out your ZigBee network self-healing is awesome as I am have issues how long in real time 802.15.4 runs before losing connection or locking up requiring power reset on the slave (the master so far I have yet to need to power reset) and get about 1/2 hour typically before this happens. The ZigBee setup I had ran without fault for many many hours; it’s great. This project (product) is of test instrument type where its application is a temporary set-up in varying environments and situations and needs to run say 1 hour and other times many hours to collect the data needed and just like a test instrument, disconnect and put away until next time. I understand I may need better coding or schemes and work arounds as the project progresses and I learn more. I can only develop so much per day. As a whole, the wireless part of the project is say 10%, the rest is developing the unrelated science and that is still in the works being improved and refined.

As a question though, shouldn’t ADDR_COORDINATOR or DH/DL work just as well (the same) as hard coding or is there something imbedded in the headers or handshaking schemes that differs or you think a bug? Thanks again.

R_D3, This is probably not the best place to discuses your full needs. May I suggest you go to https://my.digi.com/s and log in. Then create a Case. When doing so, make sure you provide the Profiles of the radios and exactly what it is you are trying to do.

Gotcha and thanks. Update: I found the majority of my problem. When I’m test working, ends and coord are within 6 inches to couple feet (need my hands to operate certain things) apart. An end signal strength can say ‘swamp out’ others and the coord being preferential to an end in closer proximity, antenna orientation, ambient rf interference, etc … to such a point that other ends seem as if lost communication or association. I need to rethink settings, configurations, collisions, etc. Thank you so so much helping.