In my hexapod project I need to query servo movement status of each servo independently (something like Q ). But it’s seems to be impossible in current SSC-32 firmware version (1.06).
I can implement this command in firmware by myself (i.e. create custom firmware version) but may be you consider this feature as useful for other users and will implement this command in future versions of the firmware?
Another question: Is the source codes of version 1.06 available? I found only sources of version 1.03.
There are 2 commands you can use
Q this will return a “.” if the move is complete or a “+” if its in progress.
Q where arg is the number of the servo you wish to interogate.
This will return binary number represented the current pulse/10 e.g
150(binary) which indicates 1500uS
I believe it is possible to do multiple, Q1Q2Q3 should return 3 bytes.
If I understand it correctly, this is not the actual position of the servo but the current value the SSC is sending to the servo. To interrogate the servo requires modification of the servo and the SSC to retrieve the information.
Thanks for reply, Paul!
Do you mean QP command instead of Q?
Actually I need only movement status of servo (’+’ if servo still moving and ‘.’ if servo movement completed). As I understand, QP returns current pulse width.
I can use QP command and compare it’s result with target servo pulse width with stored somewhere in my program but SSC-32 can do this more accurately (without division of pulse width by 10). Also I’m trying to avoid storing target pulse width in my program because this information already stored in servo controler.
Sorry yes its QP
It does say in the handbook though that there can be a delay of between 5uS and 5mS befire the reply will be sent.
Depending on your baud rate this could cause a delay that you may not be comfortable with. Also you have to consider the delays introduced by your UART on your computer which may not seem significant but on a fast, short move it could have an effect.
I was sending command from a PDA to my robot and had trouble using it as the PDA comms is terrible.
I found the best way was to record which servo time was highest when you sent the command and used a simple wait for that time before sending the next command.
It works quite effectively. If the servo doesnt complete in the expected time then there is a hardware failure anyway.
My onboard computer is PDA (HP hx4700) and I have no problem with it’s COM port so far. Current implementation of my software works exactly as you describe (I’m waiting for a while and then start next moving of the leg). But I want to be more precise 
. I intend to implement complex sequencer supporting most of the hexapod gaits and I’m afraid that “Sleep()” approach will be too inaccurate with complex gaits.
Yesterday I tried to create my own version of firmware with new command (Q which return) this works fine (There is no noticeable delays) but it based on previous version of original firmware 
Ive got one of the HP Jornada 568 series and thats quite good on comms but it has no wireless connections.
My new one is an XDA(Jasjar) with bluetooth and it really suffers at times on timing.
I think my problem was compounded by other delays such as the turn-round time in the SSC which is minimal, The bluetooth Latency which is unpredictable and Windows Mobile 5 which does what it wants when it wants. There again it never was supposed to be for mission-critical applications.
I’ve decided to move the brains to an onboard processor and use the XDA just for minimal control
(Well that was the plan last week. This week, who knows?)