Open davidjsherman opened 8 years ago
Can you try with a USB extension cable?
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?
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
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:
() -
() -
() -
() -
() -
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:
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.
Did you try with dtoverlay=pi3-disable-bt
in case it is the problem with the floating UART1 speed?
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?
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
I face same issue with Pi 3 in multiple situation:
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 ?
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:
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:This test may be performed by running
where
shell.txt
simply asks for the node description