wCK at 921.6K
wCK at 921.6K
by i-Bot
Sun May 15, 2011 3:42 pm
I just changed all my wCK servos and FTDI controller to 921.6K baud rate under linux.
I now get about 10% of commands fail. Previously at 115.2K I never noticed any failure.
Did anyone else try 921.6K before I get the testgear out ?
Robotis wCK programmer software does not appear to support over 115.2K so I never tried before
I now get about 10% of commands fail. Previously at 115.2K I never noticed any failure.
Did anyone else try 921.6K before I get the testgear out ?
Robotis wCK programmer software does not appear to support over 115.2K so I never tried before
by PedroR
Mon May 16, 2011 12:02 pm
Hi i-Bot
Just found an email dated back to July 2008 (right after we began selling them) where the speed of the servos is discussed with Robobuilder. Limor sent them a few pertinent questions and they give some explanation as to why they chose to use these speeds:
"1) why is the controller's Atmega CPU clock rate set to 14.7456 MHz and not
to the standard 16Mhz which would allow the servo bus to run at 1Mhz with 0%
error ?
=> We not only paid attention to the servo bus speed but also to the
environment where users can control RoboBuilder directly from PC, which is
important for educational purpose. For example, when you use MotionBuilder
to build a motion, wCK is controlled directly by PC.
As the max speed that PC usually supports is 115200bps, we chose 14.7456MHz
in order to meet Error 0%. The usual default speed 115200bps support various
CPU types and it can communicate with wCK without any special device.
Due to this arrangement, the max speed is not 1Mbps but we think the
0.921Mbps doesn't make much difference from 1Mbps.
2) Why is the servo bus running at 115200 and not at maximum speed ?
Refer to the answer to the question 1)
3) So I assume the servos CPU also running at 14.7Mhz and they are by
default set to 115200 baud ?
User's CPU clock doesn't necessarily need to be 14.7Mhz. For example, if you
use Atmega128, use 16Mhz clock and set 115200bps without problem(Error
-3.5%)."
I am not sure if this was posted at the time but in any case this is the information we have at this point.
If you'd like I can get in touch with them and ask more about this. Just let me know if this is your only question or if you'd like us to ask for any additional information.
Also, as a final note, I know that at 115.2K and using the RBC protocol (communicating with the controller, not the servos), we were told by one other customer that he got packet losses 1 out of 5 000 times. Not nearly as bad as what you're seeing, but we did get reports of this happening at 115ks too.
I hope this helps.
Regards
Pedro.
Just found an email dated back to July 2008 (right after we began selling them) where the speed of the servos is discussed with Robobuilder. Limor sent them a few pertinent questions and they give some explanation as to why they chose to use these speeds:
"1) why is the controller's Atmega CPU clock rate set to 14.7456 MHz and not
to the standard 16Mhz which would allow the servo bus to run at 1Mhz with 0%
error ?
=> We not only paid attention to the servo bus speed but also to the
environment where users can control RoboBuilder directly from PC, which is
important for educational purpose. For example, when you use MotionBuilder
to build a motion, wCK is controlled directly by PC.
As the max speed that PC usually supports is 115200bps, we chose 14.7456MHz
in order to meet Error 0%. The usual default speed 115200bps support various
CPU types and it can communicate with wCK without any special device.
Due to this arrangement, the max speed is not 1Mbps but we think the
0.921Mbps doesn't make much difference from 1Mbps.
2) Why is the servo bus running at 115200 and not at maximum speed ?
Refer to the answer to the question 1)
3) So I assume the servos CPU also running at 14.7Mhz and they are by
default set to 115200 baud ?
User's CPU clock doesn't necessarily need to be 14.7Mhz. For example, if you
use Atmega128, use 16Mhz clock and set 115200bps without problem(Error
-3.5%)."
I am not sure if this was posted at the time but in any case this is the information we have at this point.
If you'd like I can get in touch with them and ask more about this. Just let me know if this is your only question or if you'd like us to ask for any additional information.
Also, as a final note, I know that at 115.2K and using the RBC protocol (communicating with the controller, not the servos), we were told by one other customer that he got packet losses 1 out of 5 000 times. Not nearly as bad as what you're seeing, but we did get reports of this happening at 115ks too.
I hope this helps.
Regards
Pedro.
by PedroR
Mon May 16, 2011 12:13 pm
Hi i-Bot
You may also want to check page 62 of the wCK Manual here http://robosavvy.com/RoboSavvyPages/Rob ... manual.pdf
There's probably a more up to date version of the manual by now on the Robobuilder website but in any case, page 62 of that PDF explains the error rate at different clock speeds.
In particular see the AVR series where you read that at 921.6 you should be getting 0% error rate.
I am not sure what is the clock speed on the servos but from the email I posted above they hint it may be at the mentioned 14.7456.
Anyway just giving you some more information which I hope can be help.
Regards
Pedro.
You may also want to check page 62 of the wCK Manual here http://robosavvy.com/RoboSavvyPages/Rob ... manual.pdf
There's probably a more up to date version of the manual by now on the Robobuilder website but in any case, page 62 of that PDF explains the error rate at different clock speeds.
In particular see the AVR series where you read that at 921.6 you should be getting 0% error rate.
I am not sure what is the clock speed on the servos but from the email I posted above they hint it may be at the mentioned 14.7456.
Anyway just giving you some more information which I hope can be help.
Regards
Pedro.
by i-Bot
Mon May 16, 2011 1:18 pm
Thx. Pedro
That error is how close to the required baud rate you are.
If 921.6K on the wCK is exact, then I have a rate from the FTDI under linux of 24000000/26 = 923.08. An error of .16% which is well close enough.
The errors I get are no response from the wCK, increasing the time out makes no difference.
I will put an oscilloscope on the data lines.
That error is how close to the required baud rate you are.
If 921.6K on the wCK is exact, then I have a rate from the FTDI under linux of 24000000/26 = 923.08. An error of .16% which is well close enough.
The errors I get are no response from the wCK, increasing the time out makes no difference.
I will put an oscilloscope on the data lines.
by PedroR
Tue May 17, 2011 9:35 am
Hi i-Bot
With the information you posted I sent an email to Robobuilder and already got a reply.
I believe it may be enlightening to your issue:
In wCK module manual, it is the theoretical value for MCU source of clock, without considering the "noise, crystal error and other facts".
Actual (Real) error ratio is higher than theoretical error value because of circuit noise, crystal error and etc...
You have two options.
1) We recommend you test in 460800 bps or lower bps if you want to use our official wCK cable,
2) We ask you to use "Shield Cable" if you need to use in higher bps than 460800 bps.
Hope that this helps.
Regards,
I'm not sure how important the 921.6K is to porting the DARwIn code but in any case this is their information.
In point 2) they mention shielded cables; I am not sure if they sell them though. I can ask if you're interested although I trust you'll probably have the resources to build your own version of the cables
If you need spare wCK cables to reuse the connectors or for experimenting, please let us know as we have quite a few here at the office and can supply a few to you.
(the same goes for head cables)
Regards
Pedro
With the information you posted I sent an email to Robobuilder and already got a reply.
I believe it may be enlightening to your issue:
In wCK module manual, it is the theoretical value for MCU source of clock, without considering the "noise, crystal error and other facts".
Actual (Real) error ratio is higher than theoretical error value because of circuit noise, crystal error and etc...
You have two options.
1) We recommend you test in 460800 bps or lower bps if you want to use our official wCK cable,
2) We ask you to use "Shield Cable" if you need to use in higher bps than 460800 bps.
Hope that this helps.
Regards,
I'm not sure how important the 921.6K is to porting the DARwIn code but in any case this is their information.
In point 2) they mention shielded cables; I am not sure if they sell them though. I can ask if you're interested although I trust you'll probably have the resources to build your own version of the cables
If you need spare wCK cables to reuse the connectors or for experimenting, please let us know as we have quite a few here at the office and can supply a few to you.
(the same goes for head cables)
Regards
Pedro