Thymio-RF on Raspberry Pi 3 drops messages

[davidjsherman]

Aseba 1.5.3 528bcb2199ff0235c20488655a2c26695ab8c98f compiled for armv7l on a Raspberry Pi 3 drops many messages when using the Thymio-RF dongle, but works reliably when using a USB cable.

The serial port parameters are the same. The Pi 3 is producing 5V.

The following simple program produces a stream of events:

var tick = 0

onevent temperature
    emit ping([0xdead,0xbeef,tick])
    tick += 1
    call leds.temperature(6 * ((tick%5)-2), 5 * (((tick+1)%5)-2))

Watching the serial port with od -ax < /dev/ttyACM0 works sporadically. Sometimes no output is received from the dongle at all.

Aseba Studio never receives a complete node description.

Running asebaswitch with asebashell shows that the latter has received the node description header but not all of the description messages. For example, in the output of ls thymio-II one may see:

native functions:
  _system.reboot() - Reboot the microcontroller
  _system.settings.read(address[1], value[1]) - Read a setting
  () - 
  () - 
  () - 
  () - 
  () - 
  () - 

This test may be performed by running

asebaswitch -d -v ser:name=/dev/ttyACM0 > switch.log & apid=$! ; sleep 10 ; expect shell.txt  | tee shell.log ; kill $apid

where shell.txt simply asks for the node description

spawn asebashell "tcp:;port=33333"
sleep 7
expect -re "^>" { send "ls thymio-II\n" }
expect -re "^>" { send "quit\n" }

[mbonani]

Can you try with a USB extension cable?

[davidjsherman]

I see the same problems with a USB 2.0 hub. Does the dongle need more than 500 mA, would the hub need to be powered?

[mbonani]

I already see hubs totaly cut the radio communication... Trying another one was succesfull. I think there could be a problem how the GND is routed in the hub, rasberry etc... Using a simple extension cable make normally thing work. In your case power the hub could help

[davidjsherman]

Same problem, using a 1-meter shielded extension cable and with the dongle sitting next to the robot.

  prox.comm - Data received on the proximity communication
  tap - A tap is detected
  acc - Accelerometer values updated
  mic - Fired when microphone intensity is above threshold
   - 
   - 
   - 
   - 
   - 
   - 
native functions:
  () - 
  () - 
  () - 
  () - 
  () - 

[davidjsherman]

Need to test this with Bluetooth disabled, since on the Raspberry Pi 3 UART0 is mapped to Bluetooth and UART1 is a software UART whose bps rate may change with CPU load and temperature. If this is the problem, disabling Bluetooth is better that throttling the core CPU frequency.

Should be enough to use dtoverlay=pi3-disable-bt

Some references:

1. Overlay to remap Pi 3 UART
2. Raspberry Pi 3 compatibility
3. How do I make serial work on the Raspberry Pi3.

[mbonani]

I just test with a PI3 and get same behavior. The description is blocking at "_system.settings.read(address[1], value[1]) - Read a setting". It blocks every time on that one. Same result as with extension cable. I have the feelling that the radio has no problem as I was thinking. Perhaps is appear when description are big and sent is smaller messages and the rebuilding of it bugs on Rasperry and not over bigger systems... No time to go deeper now.

[davidjsherman]

Did you try with dtoverlay=pi3-disable-bt in case it is the problem with the floating UART1 speed?

[mbonani]

yes I try it just now. No change on the behaviors. Also I am not sure why you think it can impact UART on USB, I understood problems was for physical UART?

[mbonani]

I get same behavior on a Pi2 (I used same SD card as for 3) stop at _system.seetings.read (if you use it trough a switch using -d option

[ymartin59]

I face same issue with Pi 3 in multiple situation:

• connecting USB dongle with a powered USB 2.0 hub
• having bluebooth powered off and kernel modules unloaded

Read operation with poll syscall fails on timeout. I am looking for a simple command line test code to understand/diagnose communication through wireless dongle. Does such code already exist ?