Digi XBee 3, DigiMesh - problem with sending messages by xbee.transmit () ENOTCONN

XBee & XBee Gateway XBee - DigiMesh
, ,
1

Hi everyone, I have a problem with sending messages from Digi XBee 3 modules, DigiMesh protocol, firmware version 3012. The program sending messages in BROADCAST or UNICAST mode:

    retries = 200
    address = xbee.ADDR_BROADCAST
    time_delay = 15
    error_count = 0
    error_message = ""
    message = "1234567890"  # message = "123456789"
    for _ in range(retries):
        try:
            xbee.transmit(address, message)
            utime.sleep_ms(time_delay)
        except OSError as e:
            error_count += 1
            error_message = str(e)
            utime.sleep_ms(time_delay)

coordinator => router: program as above, up to 9 characters message is sent correctly, above it ends with error “[Errno 7107] ENOTCONN” for all xbee.transmit (200 times). After running the module (before calling the xbee.discover() function), the code executes correctly (also for messages longer than 10 characters).

router => coordinator: same program, up to messages of 9 characters end with an error, while longer messages send correctly
Have you encountered such a problem? Is it the fault of the configuration?
I am kindly very much asking for help.

2

Try adding a delay from your receive to before you try to send data if about 4 seconds.

3

Thank you for your reply. The short message sent from the coordinator reaches the router without any problem.
The router after receiving the message, delay 4 seconds sending a 4 character message to the coordinator which ends with ENOTCONN error.

4

Please submit a case for this issue by going to https://my.digi.com/ and logging in or sending an email to tech.support@digi.com

5

Thank you for the information, I have reported the error

6

thank you for the help

7

Hi, 3012 is a bust for uPython. Use 300D. N.B. even with 300D, transmitting a broadcast will return an error, but the broadcast works, the error is meaningless!
When you say "coordinator? I presume you mean “sleep coordinator”??
Be aware that Xbee3 Digimesh is prone to lock-ups. Often the receiver will lock up, and the only way to recover is to xbee. atcmd(“FR”), i.e. a forced reset. I periodically send broadcasts just for the purpose of a kind of watch dog function. All modules in the network monitor xbee.atcmd(“GD”) , and if it stops incrementing this indicates their receiver has jammed and they force reset. Another tactic is to wdt.feed() within a receive_callback.
Also be aware that on rare occasions, modules will lock up entirely and the only way to recover them is to Power On Reset (P.O.R). I have a network of 44 modules that I deployed a year ago, and after ten months four modules locked up entirely. If you try to connect to them with XCTU, it says no bootloader present, but if you P.O.R they work again. So In my future design I have included a watch dog IC, TPL5010, that cycles power to the Xbee3 if it stops handshaking.

Have fun! Don’t expect tech support to fix these problems. They have known about them for years and years. Xbee3 was released 6 years ago. If it still doesn’t work, it probably never will.

8

@Matthew_Findlow that is incorrect. I would urge you to reach out to Digi Support about this issue. I would also suggest making sure that you are using the Micro Python Garbage collection as well as the watchdog timer functions in your code.

9

G’day mvut. Yes, I use the watch dog function in uPython. No need for garbage collection. If it were to run out of memory it will throw an exception, and watch dog will trip. Lock-ups are unrelated issues, over which I have been in constant discourse with tech support for three years. Nothing has been done. May as well spit!

As for uPython not working in firmware 3012, well that speaks for itself! Tech support claims extensive testing is done before a firmware release, but it literally took me less than 60 seconds to realize that uPython didn’t work with 3012… I let them know within days of its release, and yet here we are a year later and no new firmware issued. Doesn’t inspire confidence!

10

Hi, I just wanted to clarify that the issue of receivers locking-up was with firmware 300D, and transmit is problematic from uPython with 3012.
I recently received the alfa for the upcoming firmware update 3014, and it works seamlessly… at least for me. I feel bad for dissing xbee3 Digimesh, even though it probably deserved it! All is now forgiven.

11

how do i get 3014 firmware im having the same issues

12

3014 was an alpha that I was sent for testing.

It fixed the 3012 problem of Tx/Rx not working in uPython, but I spoke too soon in saying that it worked flawlessly.

I use SM6 (micropython sleep), and with 3014 the module will lock up (appears not to wake from sleep) every few days or so. The only way to recover the module is a P.O.R.

I’m still using 300D. It used to give me a lot of grief (receiver locking up) when I was using SM8 (synch-sleep). But since I changed to using SM6, It works much better. (fewer lock-ups, if any).