how to center USO output positions in game play

[berksglh]

Question about actuator center position.

I am using the mini ssc2 USO serial device and testing things on the work bench with just standard R/C servos to get an understanding of this software and the profile setup all works. (my actual sim char isnt built yet)

I created a simple profile and set up my USO initiation strings to output a center position command (127) to the servos at start and stop, and this is working good.

When i hit the start button, the servos go to about a value of 55 (full range command = 0-254) then when i hit stop, they center at my 127 value.

Even with no math, why do they get commanded to 55? Even if I add an offset in the output section (value = (value/1*1)+72) they still go to about 55? In my mind the assembled chair will jump from the center or home position, to this odd value when you hit start.

With a simple math input, the servos seem to operate corectly in game play, but they jump to this 55 position and work around that position..

How do i fix this?

[sirnoname]

You can tell us your online profile number, then we can load this profile.
You can see this with the 3.0.0.1 beta and a press on the cloud button in the lower middle.
The profile number is the first in the list.

[berksglh]

My test profile is in the cloud * #67.

Notes:
#1 I wasnt at 3.0.0.1 ...So I just upgraded to the 3.0.0.1 now and uploaded my new profile to the cloud.

#2 I was running extractor/converter in compatability mode for XP. I now have the 3.0.0.1 running in regular windows 7 as administrator.

#3 all the math is removed from this profille for this test till i get the centering error fixed.

#4 I also noticed that I cant reverse the output direction setup as the USO dialog shows. I need one output reversed, and it seems to have no affect.

I need to retest now that i upgraded to 3.0.0.1 and am not in xp compatability mode. So it may be resolved already?

Here are screen shots of the USO output setup. Also is a shot of my table top test rig. Its just a scaled down ugly version of my proposed project to get things working.

[sirnoname]

You are the first one who uses hex values.
As far as I can see this section of code has some knowlege from X-Sim 1.x and is not really good.
Questions:
1.) is 55 in hex?
2.) what is the decimal output compared to the hex output

If it differs please open a bug report!
There you will get a new converter which is rewritten in this section.

[berksglh]

The # 55 is the aproximate decimal comand position from X-sim with no math or calibration offset. Doesnt matter what i seem to do to the output offset formula (a01 = (value / 1 * n) + y where n and Y can be any value at all, it seems to have no affect on position or direction.

If i use the stop and start command strings to change the commanded neutral positions of my neutral positions (decimal 127 in above example images) at start and stop strings to = 55, then there is no movement when going into run mode anymore, or back to stop. Therefore I assume the command from x-sim is around decimal 55 (or around hex 37)

I will set up an RS-232 terminal tonight to recieve the actual serial string commands from x-sim and then do a bug report as you say with my results.

I am amazed at the fast responce. Thank You....

Dave.

[berksglh]

Is it a bug, or am I messing up.

The datapacket with axis informations that is sent out the serial port, as captured by a terminal emulator, is as follows:

ff 00 37 46 ff 01 37 46 ff 02 37 46 ff 03 37 46

the info sent that belongs to a01 axis is the first 4 hex bytes of that string:

ff 00 37 46

The mini sscii card only needs 3 hex bytes. 1= sync, next byte= port#, next byte = comand position (0-254) it ignores all remaining info untill it sees another sync byte

FF is the sync byte, 00 is the port address (0-7) on the sscII card, 37 is the the odd hex byte position command (the decimal 55 i refered to earlier) to the servo. I dont know what the 46 is for or why its there, and its ignored by the mini sscii. hex 3746 = decimal 14150 Im confused as to where its comming from

It appears that x-sim is sending out 2 bytes ( xx xx )per axis.

I dont know where to see the value in the x-sim software to know if its my mistake, or a bug?

[berksglh]

Its not a timming issue. The pictured sim chair above works with my crude math in place and moves in game play with my #68 profile in the cloud.

So the setup does work, but it runs around the odd hex 37 (decimal 55) as a neutral position. I want to center the axis at decimal 127 (hex 7f)

[sirnoname]

Checked your downloaded config and it is sending constant 127 in all options on my serial port.

Changing the +XX value will not change like assumed, a zero should work.

OK found the thinking problem of the +4 problem and here comes the explanation:
The math line is working with 2^32 values = 0 to 4294967295. X-Sim has a 32bit math engine.
A +4 does nearly nothing, instead if you are using 8 bit you must multiply the +4 with 16777216 (256*16777216=2^32). +67108864 will do the job.
divider and multiplier must work.

So in the end there is all working like it should work.

[berksglh]

Setting the output on the USO setup screen from Hex to Binary, seems to have goten rid of the extra charachters, and now I get proper output string. Axis phicically centers perfectly at 127 *

Then I inverted the axis 2 output by using the USO output setup screen so Value = (value / 1 * -1) + 4298769224
This worked great, direction is as expected. I then moved the calibration slider and the outpout moved as assumed, but just a few times. Things got strange at that point.

The output value seemed to pump to one side, up or have memmory to one direction when moving the slider, and then I couldnt get the output to move from one side unless I slid the calibration slider all the way negative on that axis. But then I could only get 0-127 output, and couldnt gat any higher then 127 no matter what i did, unless I removed the -1 and went back to a +1.

At this point I am convinced there is an issue in the inverse math that gets hung up somehow. (math overflow error or divide by zero?). Once it got messed up, its like it doesnt care what the +x at the end is. If the * value is a negative its hosed up.

It did work as expected for a moment, and moving the calibration slider screwed it up. Doing reg cleans and rebooting and loading did nothing.

I have decided to not use the negative value and just mechanically reverse the actuator and move on with my development.
If someone wants to do a bug report and further look into this issue that would be nice, but I am moving on without it.

Thanks for the help and advice.

[sirnoname]

Can you make a step by step instruction for this error?