New FrSkyX protocol

Thanks for posting your results. After merging the latest deviationtx default changes the protocol no longer fits on the 7e. Not sure where to look to squeeze out 12 bytes.

midelic wrote: @hexfet
I discovered a potential problem which may affect binding.
In binding mode The PA is not activated which may lead(or may not) to binding fail when RF Power level is set really low.

Thanks midelic, I've made this addition.

I'm unable to duplicate the reports of jitter issues. Doesn't mean it's ruled out but it's not productive for me to spend more time on it. Since it's reported on multiple protocols I'm going to focus on finishing FrskyX and leave the jitter discussion for another thread. A summary of what I tried is below.

After pulling in the latest changes from the default branch the protocol does not fit in the 7e. I've not updated the test build so the 7e build is still available there for now.

I tried to replicate the jitter reports with these tests/steps, in all the combinations that made any sense.
- Tested 4 of the posted mixer files. Other than maxing out servos due to mixes that generate 150% travel there were no problems.
- Tested mixes with PPM, DSMX, and Flysky. Tested with servos on DSMX and Flysky; with homemade ppm/pwm monitor and oscilloscope on PPM and Flysky.
- Monitored channel values (mixer outputs) with print statements in dev and emulator builds

I did the earlier tests with no ID set.
I just repeated these tests with ID set to 1, now i have no problems with any leg or jitter with any of my transmitters.

No ID:
Devo 7e: Lots of delay
Devo 8s: All good
Devo 10: All good

ID set to 1:
Devo 7e: All good
Devo 8s: All good
Devo 10: All good

Tom

hexfet wrote: Thanks for posting your results. After merging the latest deviationtx default changes the protocol no longer fits on the 7e. Not sure where to look to squeeze out 12 bytes.

Are you running out of ram or rom? If it's ROM, I'd suggest taking out some of the telemetry values on the 7E. If it's RAM, then it's got to be in the protocol file.

Please don't cripple 7E telemetry any more
I killed multimodule support on mine to get everything I need in.

Now I am craving for more RAM so it could use extended telemetry. As it is right now, it doesn't fit in ram with extended telemetry enabled.

I am oh that close to replacing RBT6 with RET6 I have lying around.

Mr_W wrote: Please don't cripple 7E telemetry any more
I killed multimodule support on mine to get everything I need in.

Now I am craving for more RAM so it could use extended telemetry. As it is right now, it doesn't fit in ram with extended telemetry enabled.

I am oh that close to replacing RBT6 with RET6 I have lying around.

Since you're doing your own builds, you could disable something else and keep extended telemetry even if we lose it in the standard build. Like the standard GUI. Or possibly make the modules you're not using conditional and turn those off (and if you do, please share the code with us).

If the protocol changes for it, it's harder to get back. I'm not sure how to do that.

mwm wrote: Since you're doing your own builds, you could disable something else and keep extended telemetry even if we lose it in the standard build. Like the standard GUI. Or possibly make the modules you're not using conditional and turn those off (and if you do, please share the code with us).

If the protocol changes for it, it's harder to get back. I'm not sure how to do that.

Turning off features would be too easy. Problem here is that with extended telemetry, protocol module is bigger than 4k. It is more than 5000 bytes.
I have tried to make different RAM split, to give 6k for modules, but that didn't work. I have changed .ld files and Makefile MODULAR var, but got only blank screen and couldn't turn Devo off with button, had to unplug battery. What I suspect is that with 14/6 ram split, there is not enough application ram and stack overruns data creating mess in early start process.

Now I do admit I was lazy a bit, and did not try debugging it with jtag or swd. I could maybe try that also to figure out exact problem.

Test build is updated. I was able to build the 7e after moving ifdefs to exclude display code for the telemetry that had already been excluded from the protocol. No new features, just:
- merged with latest deviationtx default
- telemetry value array changed from s16 to s32
- updated frsky2way to use common hub telemetry code
- removed telemetry items from 7e display with HAS_EXTENDED_TELEMETRY define
- removed protocol option for coarse frequency adjustment

Only verified by inspection that the second item doesn't break devo/dsm telemetry display (value array in default is u16). The s.port telemetry values are s32. Something like altitude which is in cm could exceed an s16 max value.

I'd like to update the ADxGAIN protocol option but haven't found much information online. Here's my questions.

1) The frysky2way protocol file has these comments for the AD1/AD2 telemetry values for the D16 protocol. Are these voltage scales correct? What I did find online seemed to indicate the max input is 3.3V for both AD1 and AD2.
2) The frskyx code is below. midelic, do you have any more information on how the pkt[4] value is to be interpreted? Is it that the maximum input voltage on the AD1 pin is 0x36 (5.5V)? I added the 10x factor to fit the existing frsky display code based on Alex's feedback, so pkt[4] seems to be in 1/10 Volts.

Hello,
If it helps.

The AD1 and AD2 has a Hardware Range form 0 to 3.3 V
the AD1 is Hardware Coded with a Divider of 4 -> 1:4 -> 4X3.3V Max Input Volt ( Internal Hardware Coded at RX and only for RX Voltage )
The AD2 has to get Input form External Voltage Divider ( small litte Thing to plug into the External Port ) and here you have to know the Resistor Values to calculate the Divider for your Voltage Range.
This Divider has to stored at the Telemetry Page on Tarains to get the real calculated Voltage on the Display

Greetings Alex

yes but as standard resistors have some % of error, I like to have the ratio setting in few digits, doing that way we can tune accurately the value of volt displayed, to the real value.

hexfet wrote: Test build is updated. I was able to build the 7e after moving ifdefs to exclude display code for the telemetry that had already been excluded from the protocol. No new features, just:
- merged with latest deviationtx default
- telemetry value array changed from s16 to s32
- updated frsky2way to use common hub telemetry code
- removed telemetry items from 7e display with HAS_EXTENDED_TELEMETRY define
- removed protocol option for coarse frequency adjustment

Only verified by inspection that the second item doesn't break devo/dsm telemetry display (value array in default is u16). The s.port telemetry values are s32. Something like altitude which is in cm could exceed an s16 max value.

Thanks, I will give it a try later.

Hello,
done a fast Bench Test on Ver. 1f0.

TX 8s
FrskyX Alt,Dis,Amp looking and counting good. Doing a Flighttest on Weekend and reporting.

TX 7e
waiting for DHL to get a new one for Testing, i think ready on Weekend to Test 7e Build.


Servos looking better on this Build , some Changes ? Compiler working better ?
Doing later some Test with the PWM Counter and Reporting with EDIT

greetings Alex

p.s. Good Work hexfet !

The FrskyX telemetry RX battery data is received in every second telemetry frame.
In one frame pkt[4] is RXBt(rx battery) in the alternating frame pkt[4] is RSSI.
Interesting enough RSSI has much higher values imo to avoid confusion with RXBt.
That magic values 0x36 coming from me and is estimated from a value less than minimum RSSI value on telemetry data ...... to avoid confusions,

For example minimum RSSI is lets say 40(0x28)*2=80(0x50) So the RXBt(8V) should be chosen below this value.This is my interpretation.
It can be tested practically what is the minimum RSSI values sent by RX. and make new calculations.

Normally RX are supplied from BEC around 5V so I chose that magic value.0x36,
Probably there are other better solutions bu that was coming to my mind.

hexfet wrote: I'd like to update the ADxGAIN protocol option but haven't found much information online. Here's my questions.

2) The frskyx code is below. midelic, do you have any more information on how the pkt[4] value is to be interpreted? Is it that the maximum input voltage on the AD1 pin is 0x36 (5.5V)? I added the 10x factor to fit the existing frsky display code based on Alex's feedback, so pkt[4] seems to be in 1/10 Volts.

        if (pkt[4] > 0x36) {  
            Telemetry.value[TELEM_FRSKY_RSSI] = pkt[4] / 2;   // Value in Db
            TELEMETRY_SetUpdated(TELEM_FRSKY_RSSI);
        } else {
            Telemetry.value[TELEM_FRSKY_VOLT1] = pkt[4] * 10;      // In 1/100 of Volts
            TELEMETRY_SetUpdated(TELEM_FRSKY_VOLT1);
        }

Hello,

Test Ver. 1f0

Bind on 7e is working but then the green RX led only doing some flicker and the servos moving only 1 sec then stoping for 4-5 sec then moving again 1 sec.

old version does work normal ( i did a verify with d76 )

greetings Alex

midelic wrote: Normally RX are supplied from BEC around 5V so I chose that magic value.0x36,
Probably there are other better solutions bu that was coming to my mind.

Seems reasonable to me and it seems to be working. I don't know of any other information in the packet that indicates whether the current packet has rssi or ad1.

Alexandro wrote: Hello,
If it helps.

The AD1 and AD2 has a Hardware Range form 0 to 3.3 V
the AD1 is Hardware Coded with a Divider of 4 -> 1:4 -> 4X3.3V Max Input Volt ( Internal Hardware Coded at RX and only for RX Voltage )
The AD2 has to get Input form External Voltage Divider ( small litte Thing to plug into the External Port ) and here you have to know the Resistor Values to calculate the Divider for your Voltage Range.
This Divider has to stored at the Telemetry Page on Tarains to get the real calculated Voltage on the Display

Greetings Alex

Thanks that's helpful. Seems for the D8 protocol A1 and A2 are from an 8-bit adc (3.3V/255 = 12.9mV, which is pretty close to the comment in the frsky2way protocol). Likely the values in frsk2way came from measurements and no reason to change them.

I enabled the AD2GAIN protocol option in frskyx, but am not exactly sure where to apply it! The new test build applies it to the ADC2_ID telemetry value because that telemetry item is in the captured spi data. I'm not sure it's the A2 input on the X receivers. It works the same as in frsky2way - multiplies the telemetry value by <AD2GAIN>/10.

Alexandro wrote: Hello,

Test Ver. 1f0

Bind on 7e is working but then the green RX led only doing some flicker and the servos moving only 1 sec then stoping for 4-5 sec then moving again 1 sec.

old version does work normal ( i did a verify with d76 )

greetings Alex

hmmmm...the only change in frskyx since d764a03 was to enable the PA for binding. Maybe that affects the 7e. I removed that change in a new test build. Please check if the rx light still flickers with th e7e. Thanks!

hexfet wrote:

Alexandro wrote: Hello,
If it helps.

The AD1 and AD2 has a Hardware Range form 0 to 3.3 V
the AD1 is Hardware Coded with a Divider of 4 -> 1:4 -> 4X3.3V Max Input Volt ( Internal Hardware Coded at RX and only for RX Voltage )
The AD2 has to get Input form External Voltage Divider ( small litte Thing to plug into the External Port ) and here you have to know the Resistor Values to calculate the Divider for your Voltage Range.
This Divider has to stored at the Telemetry Page on Tarains to get the real calculated Voltage on the Display

Greetings Alex

Thanks that's helpful. Seems for the D8 protocol A1 and A2 are from an 8-bit adc (3.3V/255 = 12.9mV, which is pretty close to the comment in the frsky2way protocol). Likely the values in frsk2way came from measurements and no reason to change them.

I enabled the AD2GAIN protocol option in frskyx, but am not exactly sure where to apply it! The new test build applies it to the ADC2_ID telemetry value because that telemetry item is in the captured spi data. I'm not sure it's the A2 input on the X receivers. It works the same as in frsky2way - multiplies the telemetry value by <AD2GAIN>/10.

I remember, the "AD2GAIN" was introduced by me to handle the voltage diviser.... If I can remember well, need to be applied to in packet[5]. The 36 value comes from the 12.4 (3S)/3.3 = 3.7. Since no float number are allowsi I used 36 instead, then as you wrote divide by 10 the value