I believe the earlier releases did not have the extended deadband. But I can assure you all that the narrow deadband is a thing of the past for the 1425CR.
Probably need to update the 1425CR data sheet. That being said, the DIY continous servo types will still need to deal with the narrow deadband.
I’ve contacted Hitec, it’s their data sheet not mine.
Hi, just want to ask if your firmware also work on ssc32-v2 (armega 168)? since when i try to use your firmware it say it is for ssc32 v-1.
Because i am working on a project which require the servo moving in a very slow speed (below 3deg/sec, which i believe is the minimum speed of original firmware can go)
Hi, yes the firmware as been built for the atmega168. i didnt stick to the way lynxterm indentify the firmware, so thats why its seen as a v1 firmware
to update the firmware you have to press “begin update” with the power off on the ssc32
lynxterm will then tell you that he is unable to update the firmware with the software method.
press yes, this will pop up the jumper method window
install the jumper as per the image, turn on the ssc32 and press the begin update button
it should work fine that way
new release available
v0.1
this version as new features, several bug fix and some new commands
the most interesting feature is without any doubt the 10 bits input resolution
i really love this one…
really wish the multiplexer support could do 10bit res also but changing the buffer to 16bit to store the 10 bit data would cost 64 bytes of memory which is pretty much out of question
i could however try to store the data in their native format which would requier 20 byte of data per multiplexer… but that will be a pita to implement 
ive also implemented extended time unit, however there are some limitation to that as the speed achitecture for the outputs are implemented as 24bit data
which is 16bit.8bit
the 8 bit fraction part is not enough to use full time.
so when using cs, ds, sec unit. if the time is too high, the fraction will be too small for the available resolution and the servo wont move…
but this still allow to do move far longer than the actual limit of 65sec from the official firmware
ive added support for 8ch multiplexer, i dont have one here to test so ive tested it with the 16ch mux… but that should work
if someone own a 8ch multiplexer and would like to test… i would be happy to hear how it work.
implemented a new command (set_output_pwm) that do not have limit like the set_servo_pwm command
with the scope ive checked the signal and i could generate a pwm signal up to 4442us
after 4442 the signal goes back to 1, not exactly what i expected but anyways…
anything lower than 10 did look more like a spike than a square pulse
other command are a dedicated output command for logic (set_output_logic) for intensive logic, which is more efficient than using set_output_pwm/set_servo_pwm
and a command to stop the outputs
for all the details check the release.txt and protocol.txt
Hi,
I got some problem and might need your help here, after i install the firmware by jumper method and i try to run the ssc32 with some C++ code, i found that the led on board is not working, and the servo has no response ass well. I’m just wonder is there any specific requirement to use your firmware? like i have to use your terminal or there is some maximum number of servo supported?
thanks/
Hi Xueys,
there are no real requirement to use the firmware other than using the protocol described in the second post or the protocol.txt
you dont have to use my terminal and there are no maximum servo supported, all the 32 output work just like the official firmware
after flashing the firmware did you try the terminal to test and setup the basic config?
have you been able to retrive the firmware version with the button get_device_info?
about the led not working, this is probaly because the led state is set to OFF, use the terminal to set it up to ON or the other modes
check if the servos can be controlled from the terminal.
to set the servos from your program, make sure you build the command data properly, you need the header byte + encode 4 byte at the binary level to give the index of the servo(s) to be moved
- the position data(s)
Hi Dark,
thanks for your help first.
I try devterm to control the servo, they are working good. However when i’m using LynxTerm, they are not working again. Regarding to the command data you mentioned, i got no idea what that is ( forgive my poor programing skill),
When i’m using the original firmware to control the servo from C++, i will transfer the command like this,
char szBuff[500];
std::string deg;
deg = sprintf(szBuff, "#0 P%f #16 P%f #2 P%f #19 P%f #4 P%f #5 P%f #6 P%f T%d \n\r",JointAngle[0],
JointAngle[1],JointAngle[2],JointAngle[3],JointAngle[4],JointAngle[5],JointAngle[6],TimeStep);
int n = sizeof(szBuff);
DWORD dwBytesRead = sizeof(szBuff) + 1;
if(!WriteFile(hComm, szBuff,n , &dwBytesRead, NULL)){ //WriteFile for writing
errorDetail();
}So, if i want to do the exactly same thing as here, how am i suppose to programming in your firmware?
thanks.
Hi Xueys,
yea, you cant use lynxterm/lynxmotion ascii protocol with this firmware.
thats why the servo didnt work
to accomplish the same as your actual code… the simplest code i could think of would be something like that
[code]unsigned char ServoIndex[4] = {0x75, 0x00, 0x09, 0x00};
unsigned char Data[256];
unsigned short pTimeData = (unsigned short)&Data[5];
Data[0] = CMD_SET_SERVO_PWM;
Data[0] = Data[0] ^ 1 << 7; // set the time flag;
memcpy(&Data[1], &ServoIndex, 4);
*pTimeData = TimeStep;
memcpy(&Data[7], &JointAngle, 12);
DWORD dwBytesRead = 0;
if(!WriteFile(hComm, szBuff, 19, &dwBytesRead, NULL)){ //WriteFile for writing
errorDetail();
}
[/code]
assuming you have included the header definition ive posted in protocol info post, and the jointangle are word data
if you want more flexibility, you may need to implement some functions to set the index information and a funtion to prepare the command and send the data
if you keep your ascii protocol, you may want to check the line: int n = sizeof(szBuff);
as this cause your program to send 500 bytes for a command that is much more smaller, + the buffer is not zeroed, so you could end up throwing alot of garbage to the ssc-32
i would change that line for int n = strlen(szbuff);
hope this help, lets me know if you need more information
edit: my bad… handled the time as 8bit
ive fixed the code
well… ive just realized the code doesnt work… sorry about that.
you have to make sure you send the servo position in the right order(index order)
a more appropriate code could be something like that
[code]unsigned char ServoIndex[4] = {0x75, 0x00, 0x09, 0x00};
unsigned char Data[256];
unsigned short pData = (unsigned short)&Data[5];
Data[0] = CMD_SET_SERVO_PWM;
Data[0] = Data[0] ^ 1 << 7; // set the time flag;
memcpy(&Data[1], &ServoIndex, 4);
*pData++ = StepTime;
for(int i=0;i<7;i++)
*pData++ = JointAngle[JointAngleOrder[i]];
DWORD dwBytesRead = 0;
if(!WriteFile(NULL, &Data, 21, &dwBytesRead, NULL)){ //WriteFile for writing
errorDetail();
}
[/code]
Hi dark,
would you might to explain this to me one by one, cause i really don’t understand the code.
so, first line.
ServoIndex[4] = {0x75, 0x00, 0x09, 0x00};
is this the location to store the information defining which servo we are controlling to?
unsigned short pData = (unsigned short)&Data[5]; // so the position data will be storing in Data from position [5]?
Data[0] = CMD_SET_SERVO_PWM; //i guess this one use for calling header to control servo position?
Data[0] = Data[0] ^ 1 << 7; // so we turn on time flag here? what if i want to turn on speed flag also?
memcpy(&Data[1], &ServoIndex, 4); so we copy what we define in servo index into the data],
*pData++ = StepTime;
for(int i=0;i<7;i++)
*pData++ = JointAngle[JointAngleOrder[i]];
// and then we write time step and joint information into Data].
You said i will need to send the servo position in right order, i suppose the order is define as the servo index. So is that means the first servo position i define will always assign to the servo connect to pin 0, second to pin 1 and so on?
Thanks
Hi Xueys, sure
yes, this is the 32 bits information that tell which servo will be moved
[00000000][00000000][00000000][00000000]
|7 0 15 8 23 16 31 24
yes, just after the header and the servo index datas
yes, the header byte is split into a command(6 bits) and 2 option flag(2 bits)
the speed flag is the bit index 6
so to set the speed flag on
Data[0] = Data[0] ^ 1 << 6;
if you set the speed flag, you must give speed data for each servo moved
no, not exactly… they have to be sent in the index order, but you send only the datas for the specified bits that you turned on in the ServoIndex datas
if we want to set the servo connected to pin 4 , 8, and 29
the ServoIndex data would be
[00001000][00000001][00000000][00100000]
the position data that should be send(in order) should be data for pin 4, 8, 29
[00001000][00000001][00000000][00100000][1500][1500][1500]
the first position data will be used to set the pin 4, the second pos data will be used to set pin 8 and the last pos data will set the pin 29
so the whole command would be
[header][00001000][00000001][00000000][00100000][1500][1500][1500]
or
[0x15][0x08][0x01][0x00][0x20][0x05DC][0x05DC][0x05DC]
lets me know if it help(or not), im not very good to explain stuff
Hi,
this help explain a lot of thing, i will try it out, thanks
Hi, it’s me again…
Want to say thanks first, because your firmware is working good in my project, but i got one more question.
For some reason when i send the first command to ssc32, some time all the servo or most of them do not go to where i want it be until i unplug the power cable and reconnect them, do you have any idea what might causing this problem?
thanks.
Hi Xueys,
glad the firmware is working well in your project. ive also had my hex running on the firmware for couple of weeks now and ive seen the problem your talking about. infact i wasnt even sure yet if it was a bug or if i had made something wrong when it happened.
that only happened 1 time… so i wasnt sure.
does that happend often to you?
are you able to reproduce the bug?
not sure whats going on there, i feel like this bug will be hard to track down
this as never happened on my dev board and 1 time on my hexapod…
thank you for reporting the problem, now that im sure this is an actual bug… ill check whats up with that.
Hi Dark,
It’s almost happen every time when i first run my machine, and after i send p0 to each servo to turn them off and then restart them without restart ssc32.
Sometime even after i unplug the power cable and plug them in again, the servo will move to end position like p2600 instead of where i ask it to, but after that it would work fine.
Hi Xueys,
humm, i see… that seem to happen quite often
did you check if you had anything odd in the firmware config
after flashing the firmware the config is sometime messed up which can cause weird behaviour
even tough ive never seen this… ive seen alot of weird things going on when the setup was messed up
i work on a tighter init procedure and some other things in the firmware but currently my hex is down for leg modification… and my second project is not yet ready to use the ssc-32 so i wont be able to do tests in real situation for a while…
and as i said… this problem as never happened on my dev board even if ive literaly power cycled that thing several hundred times
lets me know if you would like to try my lastest release and ill pm you the details
Hi Dark,
do you have a modified version of Xan’s phoenix code for your firmware?
Greetings
Daniel
Hi Chaosman,
sorry i dont use the phoenix code, i use my own IK engine/editor that mainly target win32 and winCE platform