deviation s-fhss has narrow servo range.

deviation sfhss has narrow servo range .
I have futaba t6j , xk controller and devo 8s cc2500 mod.
when i bind to xk receiver or original futaba receiver with deviation sfhss ( devo8s ) protocol , servo range is too narrower than other controller ( t6j or xk )

and i can control servo with full range with delta 8 multi receiver by frsky protocol.. but sfhss is not.

what can i do ?

AFAIK S-FHSS protocol implementation (for XK110/XK120 heli) was never tested with S-FHSS Futaba receivers before.
Reason: Lack of sponsored equipment.

So congratulations - you seem to be the first one to actually test the S-FHSS protocol implementation to Futaba genuine receivers.

What you can do? Wait for developer feedback

You guys might find a way to additionally customize the S-FHSS implementation either be it for Futaba receivers or just S-FHSS built in heli receivers. Maybe a popup dialog just like DSM-telemetry on/off or B2/A1 bind option?

You could try increasing the scale in the channel settings. Not familiar with the FHSS implementation so not sure how much affect it might have.

max limit and scale does not effect.
' too narrower than' is exaggerative .... I think s-fhss protocol of devi... has about 80% range of real maximum servo range.
I can solve this problem to controll servo arm length.

Thank you for answer.
I don't understand last sentence for I don't use dms protocol.. or.. may be my poor english.. ^ ^ ;
when i touch sfhss button in set up menu... Popup apears and show me fine and coarse parameter 0 defalt zero. ... but I don,t know what is .

and... Fail safe function of S-FHSS protocol does not work in genuin reciver and others.

I'm sorry, my English is not good.
After a review of an oscilloscope, it was the following results.
Devo7E
　　　 100% scale = 1.52ms + -410us (also no change is set to more than 100%)
50% scale = 1.52ms + -205us

Futaba T8J
　　　　 100% scale = 1.52ms + -410us
140% scale = 1.52ms + -570us　(Max)
50% scale = 1.52ms + -205us

I changed the source, but could not be only up to 120% scale.
FUTABA is a wonder why can to 140%.

Currently SFHSS is not fail-safe support.
I wish to be supported.


I hope to something of help.

Ryou wrote: I'm sorry, my English is not good.

But you've at least got it, which is probably more than I can say about your native language. And your English better than the languages I haven't used in 3 decades now, so don't worry about it.

I changed the source, but could not be only up to 120% scale.
FUTABA is a wonder why can to 140%.

You will need to set scale in the channel menu (the one you get when you select the 1-AIL or whatever button) as well as in the mixer in order to get output values past 125%.

Currently SFHSS is not fail-safe support.
I wish to be supported.

Seems like every manufacturer does fail-safe differently, even if they use the same protocol. Some manufacturers even do it differently for different receivers. So the first step is for you to tell us how you set fail-safe using your licensed transmitter. That may tell us all we need in order to implement it (like the DSM protocols), or that we'll need some SPI captures, or even that it isn't possible.

If you're still wondering about the fine and course parameters, those are RF frequency tuning values for the CC2500. Those can be used to tune the CC2500 to improve signal strength, and the proper setting depends on which CC2500 module you have. Best way to tune it is to connect to your Rx, then adjust it up until the connection fails, then down until ditto, and then set it to the value in the middle of those two.

Thanks for the message.
That I was confirmed. It was confirmed by changing the program.
1: sacale + - a change measure the PWM signal width of the receiver
· Deviation does not change more than 100%.
· FUTABA can be varied up to 140%.
- Both pulse width of 100% the same.
2: confirm the change program (sfhss_cc2500.c)

static u16 convert_channel (u8 num)
{
s32 ch = Channels [num];
/ *
if (ch <CHAN_MIN_VALUE) {
ch = CHAN_MIN_VALUE;
} Else if (ch> CHAN_MAX_VALUE) {
ch = CHAN_MAX_VALUE;
}
* /
if (ch <-12800) {
ch = -12800;
} Else if (ch> 12096) {
ch = 12096;
}
return (u16) (496 - (ch * 410 / CHAN_MAX_VALUE));
}

Change to limit the CHAN_MIN_VALUE and CHAN_MAX_VALUE.
However, until the value of the return value is not less than or equal to zero.
Became to be set in this change up to about 120%, it can not be changed to up to 140%.
More can not understand me.

2: For fail-safe
We found a fail-safe introduction page of FUTABA T8J.


There are two types of fail-safe of the S-FHSS.
Types that you can set to any at the transmitter (T8J)
Types that have been set only CH3 in the transmission module (TM-FH module)
These fail-safe data appears to have been sent to every 5 seconds position.

SPI capture data is there any thing that was acquired at the receiver side. I wanted to know the TX-ID is the data of short time. Try to take the long data to the next opportunity.


Thanks to the efforts of developing member everyone.

As I mentioned in another thread - I coded it according to actual observed values, while I suspect that actual range is limited by 10-bit value - 0-1023 instead of current 86-906.

The correct way is to modify the expression
return (u16) (496 - (ch * 410 / CHAN_MAX_VALUE));
to
return (u16) (511 - (ch * 511 / CHAN_MAX_VALUE));

Not the offset and resolution problems.
The scaling there is a difference.

Up to 120% with the following modifications were able to be able to change the scale.
Up to 140% of the FUTABA can not understand me.

static u16 convert_channel(u8 num)
{
s32 ch = Channels[num];
/*
if (ch < CHAN_MIN_VALUE) {
ch = CHAN_MIN_VALUE;
} else if (ch > CHAN_MAX_VALUE) {
ch = CHAN_MAX_VALUE;
}
*/
if (ch < -12000) {
ch = -12000;
} else if (ch > 11952) {
ch = 11952;
}
return (u16) (498 - (ch * 500 / 12000));

Hello.
Can I use if the source change?
Could you tell me how the source change?

I solved this problem.
It is correct to send CH data with 12 BIT.
Specify the pulse width in us for data.
Example 1520us PWM = 1520.
Here is the change part. (Sfhss_cc2500.c)

static u16 convert_channel(u8 num)
{
s32 ch = ((Channels[num] * 10) / 244) + 1520; //10000=>410=>1520+-410 @10000
if (ch < 970) {
ch = 970; //-14000
} else if (ch > 2070) {
ch = 2070; //+14000
}
return (u16) (ch);
}
static void build_data_packet()
{
//#define spacer1 0x02 //0b10
//#define spacer2 (spacer1 << 4)
unsigned ch_offset = state == SFHSS_DATA1 ? 0 : 4;

u16 ch1 = convert_channel(ch_offset+0);
u16 ch2 = convert_channel(ch_offset+1);
u16 ch3 = convert_channel(ch_offset+2);
u16 ch4 = convert_channel(ch_offset+3);
packet[0] = 0x81; // can be 80, 81, 81 for Orange, only 81 for XK
packet[1] = tx_id[0];
packet[2] = tx_id[1];
packet[3] = 0;
packet[4] = 0;
packet[5] = (rf_chan << 3) | ((ch1 >> 9) & 0x07 );
packet[6] = (ch1 >> 1);
packet[7] = (ch1 << 7) | ((ch2 >> 5) & 0x7F );
packet[8] = (ch2 << 3) | ((ch3 >> 9) & 0x07 );
packet[9] = (ch3 >> 1);
packet[10] = (ch3 << 7) | ((ch4 >> 5) & 0x7F );
packet[11] = (ch4 << 3) | ((fhss_code >> 2) & 0x07 );
packet[12] = (fhss_code << 6) | state;
}

Hello Ryou,

you requested feedback on my experience with the narrow range issue.
I installed a fix provided from Vlad

www.deviationtx.com/forum/6-general-disc...vo-throw-issue#65754

I'm not sure how it connects to this thread that seems to address the programming aspects. May be I am now using a piece of your code. Anyway, the preliminary testing resulted in full servo throw and appropriate S-FHSS functionality.

Regards,
Poldi

Thanks for your tips mate, wish would be here more people like u!! youve really helped me especially now that i have such a hard time concentrating. gotta search for drug reviews because i think it is because of those pills i took.

Thanks to all who figured out and fixed the problem. The fix is now merged and should appear in nightly builds. When I initially implemented S-FHSS I did not have a real Futaba radio - they're kind of expensive, but used XK clone. So what I implemented was XK version of the protocol, and I verified it on third party (Orange) RX - it worked. I had no way to compare it with real Futaba TX, so I'm glad this is fixed now.

I appreciate your wonderful activities.
I think that it is a mistake to post in this place.
The servo range mistake has continued from the past also to frsky1way_cc2500.c.
error
line 251: s32 value = (s32) Channels * 0x600 / CHAN_MAX_VALUE + 0x8c8;
correct
line 251: s32 value = (s32) Channels * 600 / CHAN_MAX_VALUE + 0x8c8;

Add following from line 349
case PROTOCMD_GETOPTIONS:
return frsky_opts;

Who does not use the Frsky-V8 protocol?