0

I have an ATSAMD51 microcontroller integrated in a project-specific board which has also a xbee3 RF module. This xbee3 module is configured for Transparent Mode and the device type is 'router'. I can check this on the XCTU software.

Now, my goal is to install micropython on ATSAMD51 and then send commands to the xbee3 via UART since unfortunately I am not aware of any micropython library that can interact with the xbee. And just out of confusion, I don't want to use the xbee with micropython.

++++++++++++++           ++++++++++++++
++ ATSAMD51 ++ --UART--> ++ XBEE3 RF ++
++++++++++++++           ++++++++++++++
(running                 (transparent
micropython)             mode)

I successfully installed the micropython on the ATSAMD51 and I managed to send commands to the xbee3 via UART. I know this works since when I do uart.write('1234') I can check on the XCTU console that the coordinator node receives this message. However, If I try to send xbee3 AT commands, the uart.read() only gets 2 bytes at most.

Example: screen /dev/tty.usbmodem0000000000001 115200 # enter the python REPL of the ATSAMD51

>>> from machine import UART, Pin
>>> uart = UART(5, rx=Pin('PB02'), tx=Pin('PB03'), baudrate=115200)
>>> uart
UART(5, baudrate=115200, bits=8, parity=None, stop=1, timeout=1, timeout_char=1, rxbuf=256, txbuf=256)
>>> uart.write('1234') # this actually transmits the message to the coordinator node
4
>>> uart.write('+++') # entering in command mode
3
>>> uart.read()
b'OK\r'
>>> uart.write('ATID\r')
5
>>> uart.read()
b'FO\r' # this should be FOO which is the device PAN ID
>>> uart.write('ATXX\r')
5
>>> uart.read()
b'ER\r' # this should be ERROR

Any command I send I always get only 2 characters + the \r (carriage return).

Thank you!

I've tried different baudrates and timeouts. If I try to connect to the xbee directly from the computer via serial this works as expected. So I guess this is somehow related with the micropython UART configuration in the SAMD51?

Carlos Mão de Ferro
  • 21
  • 4
  • It's interesting that you're getting a carriage return (`\r`) as part of your `uart.read()` return values. That seems to indicate that it's dropping the characters after the first two of the response, but still going until it reaches the CR. Also odd that you request a baud rate of 115200 but the object sets the baud rate to 38400. Maybe a maximum? – tomlogic Nov 19 '22 at 01:47
  • Thank you @tomlogic. The baudrate was actually a typo. I just copied-paste the wrong line. As for the `\r` I think that is part of the xbee protocol (at least for [this link](https://www.digi.com/support/forum/4054/xbee-control-through-serial-port-uart): "The XBee expects just a carriage return character to end a command, and will similarly terminate strings it sends with a carriage return.") – Carlos Mão de Ferro Nov 19 '22 at 02:09
  • I was thinking that maybe the fact that the xbee returns a `\r` might mess up with the micropython's UART implementation? Perhaps the xbee sends chunks of two characters? I am just guessing here and run out of solutions.. – Carlos Mão de Ferro Nov 19 '22 at 02:12
  • You could try writing a small function to call `uart.write()` and then repeatedly call `uart.read()` and print whatever it returns. This could give you an indication of what's coming in, and if there's some odd limitation or bug in the `read()` call. – tomlogic Nov 19 '22 at 02:27
  • Thank you @tomlogic! There was a bug in the `read()` call. – Carlos Mão de Ferro Nov 19 '22 at 19:37

1 Answers1

1

The answer for the problem is here. A temporary fix is available here.

Carlos Mão de Ferro
  • 21
  • 4