Problems with Propeller USB Servo Controller (#28830)
matt.stevenson
Posts: 1
I have been testing some Propeller USB Servo Controllers (#28830), and I ran into a couple
problems. Other than these two problems, everything has worked fine.
The first is a minor issue with reading position. If a servo is sent
to a position with the low byte 85:
85 0, 85
341 1, 85
597 2, 85
853 3, 85
1109 4, 85
reading the position will return 4 bytes instead of the expected 3.
The 4th byte is the low byte repeated.
reply: <channel> <high> 85 85
The second problem is more serious. If I send a servo to a position
where the low byte is 33:
33 0, 33
289 1, 33
545 2, 33
801 3, 33
1057 4, 33
the servo appears to be disabled, and ignores further move commands
until I reconnect. All the lights blink when I send a new position,
but it is ignored and reading the position shows no change.
These bugs happen everytime I send a servo to one of those positions.
I have replicated it on multiple boards, with and without servos
connected, and on multiple channels. I am running firmware version 1.0.
Has anyone else experienced these, and is there an available fix?
I've attached some Java code which demonstrates the bugs. There are 3 folders:
SimpleBug
PropellerBug
rxtx
SimpleBug and PropellerBug are both netbeans projects. The SimpleBug source is a single
file which connects to the port, then writes a few commands to demonstrate the bugs.
The PropellerBug source is a little more high level, and it demonstrates the bugs on all
channels, baud rates, and values of high bytes.
Rxtx is an open-source java library for serial port communication which both projects
depend on.
My main platform is Ubuntu 10.10 which uses the RXTXComm.jar and librxtxSerial.so in the
root of the rxtx/ folder.
I have also tested this on Windows7 64-professional, which require the .jar and .dll in
the rxtx/win64/ folder.
(In win64, PropellerBug breaks when testing BaudRate 38.4k, but the bug is still
demonstrated.)
problems. Other than these two problems, everything has worked fine.
The first is a minor issue with reading position. If a servo is sent
to a position with the low byte 85:
85 0, 85
341 1, 85
597 2, 85
853 3, 85
1109 4, 85
reading the position will return 4 bytes instead of the expected 3.
The 4th byte is the low byte repeated.
reply: <channel> <high> 85 85
The second problem is more serious. If I send a servo to a position
where the low byte is 33:
33 0, 33
289 1, 33
545 2, 33
801 3, 33
1057 4, 33
the servo appears to be disabled, and ignores further move commands
until I reconnect. All the lights blink when I send a new position,
but it is ignored and reading the position shows no change.
These bugs happen everytime I send a servo to one of those positions.
I have replicated it on multiple boards, with and without servos
connected, and on multiple channels. I am running firmware version 1.0.
Has anyone else experienced these, and is there an available fix?
I've attached some Java code which demonstrates the bugs. There are 3 folders:
SimpleBug
PropellerBug
rxtx
SimpleBug and PropellerBug are both netbeans projects. The SimpleBug source is a single
file which connects to the port, then writes a few commands to demonstrate the bugs.
The PropellerBug source is a little more high level, and it demonstrates the bugs on all
channels, baud rates, and values of high bytes.
Rxtx is an open-source java library for serial port communication which both projects
depend on.
My main platform is Ubuntu 10.10 which uses the RXTXComm.jar and librxtxSerial.so in the
root of the rxtx/ folder.
I have also tested this on Windows7 64-professional, which require the .jar and .dll in
the rxtx/win64/ folder.
(In win64, PropellerBug breaks when testing BaudRate 38.4k, but the bug is still
demonstrated.)
