ERSKY9X Coding

[jhsa]

2. Press and hold encoder button for fast editing
For this, you need to select editing first, short press of button, then press and hold the button while rotating the encoder changes items in steps of 20.

Mike, I still didn't flash the radio, but I try to rotate my 9x radio's encoder while pressing the button, and it seems to be impossible
Does it work also by holding the menu button instead of the encoder button? I think it did in the past??
Is the double click also available with the menu button??

Thanks

João

[MikeB]

Holding the MENU button does still work.
Assuming you are using a "7-way switch encoder", I find if you press the button with your thumb, you can then rotate the encoder wheel just by rotating your thumb. In this mode, you don't need many clicks on the wheel to change a value a lot (20 steps per click).
Using other styles of encoder (X7, X9E, Horus and the type I have on my SKY board) may be easier.

No, I don't have double click on the menu button, I've added it to the encoder mainly for use when you don't have a MENU button!

Mike

[jhsa]

Holding the MENU button does still work.
Assuming you are using a "7-way switch encoder", I find if you press the button with your thumb, you can then rotate the encoder wheel just by rotating your thumb. In this mode, you don't need many clicks on the wheel to change a value a lot (20 steps per click).

Yeah, we already had that by holding the menu button as well. I can't really press and rotate the wheel with my thumb. At some point the button stops making contact and i mess everything On my 9XT is quite ok because the wheel rotates easily, but on both my Ar9x radios it doesn't, so I really have to use the menu button.

Using other styles of encoder (X7, X9E, Horus and the type I have on my SKY board) may be easier.

My 9XR-PRO also has one of those encoders that look like a pot.. This one is OK.

No, I don't have double click on the menu button, I've added it to the encoder mainly for use when you don't have a MENU button!

I understand, but perhaps better keep the way the radio operates consistent?? For example, you can change between GVARS and numbers with a double click of the encoder button, but also with pressing the menu button long? Hmmmm, wouldn't it be better if it used the same input type (double click) for for the encoder button, as well as the menu button? I find that logical and less confusing..
Just my 2 cents of course..

João

[MikeB]

Looks like I can add in a MENU double click and still keep the MENU very long, so anyone already used to using the very long MENU press will find it still works.

Mike

[jhsa]

Thank you.. That's great.. I didn't have time tonight, but will flash the radios tomorrow

João

[MikeB]

In response to a question asking how two telemetry values could be multiplied (to get watts I believe), I'm enhancing scalers. They will have two extra items, a second source and a function. The second source will be combined with the first source by the function that may be Add, Subtract, Multiply, Divide or Mod. The processing sequence is:

Get first source value.
Add offset if "Offset at First".
Multiply
Divide
Mod
Get second source value
Use the Function to combine the second source with the result so far.
Add offset if "Offset at Last".

Mike

[jhsa]

ersky9x is getting better and better. Thank you.
So, if the second source is left at "---", then the multiply, add, divide, etc, applies only to the first source value, as it has been until now?
I guess that scalers will also be in the sources, so all these calculations can also be applied between scalers??

Sorry if I am saying nonsense here Just trying to understand..

João

[MikeB]

Yes, leave the second source at "---" and scalers behave as now.
Scalers are allowed to be sources, so you may use one to scale a value, then use another scaler to scale another value, and combine the two together.

Mike

[jhsa]

Huge enhancement. Thanks Mike

João

[ozphoenix]

Thanks, Mike - your efforts are always appreciated.

Regards,
ozphoenix

Yes, leave the second source at "---" and scalers behave as now.
Scalers are allowed to be sources, so you may use one to scale a value, then use another scaler to scale another value, and combine the two together.

Mike

[MikeB]

On most radios using a STM processor, I'm adding a display of the clock (RTC) battery voltage on the Date-Time menu. This voltage is now read at power up. As the measurement uses a resistor divider, which is a load on the backup battery, the voltage is not read all the time.
This will allow you to monitor the battery, and so change it out before it goes flat.
I've tested it on a Taranis, Taranis plus, QX7, 9Xtreme and a Jumper T12 so far.
The backup battery voltage is not available for measurement, by the processor, on Atmel based boards.
Whether it is worth having an alarm at power up if the voltage is low is another question.

Mike

[MikeB]

Hi Mike,
Telemetry question:
Using 9XRPro, Ersky v222rb9, FrSky S6R, FrSky SmartPort mini Lipo Monitor (without LED), 3S batteries (various capacities).
If I set up a Custom Telemetry Display Page to show 'Ctot' on the display, the radio - for the most part - shows the correct 3S voltage (as measured with a DVM, after adjusting Cell Calibration on the Telemetry Set Up Screen).
I say 'for the most part' because, every 5-10 seconds, I will get one display of (variously) either a single cell voltage or a two cell voltage and then the (expected) 3S voltage returns -- it is not consistent which erroneous one shows up, but it is consistent that I get this random 'appearance' regardless of which battery (of the various capacities) I am monitoring. . .
ozphoenix

When I added support for the Jumper T12, I also disabled SPort telemetry for the T12. I just noticed I made a small mistake, which results in some SPort packets getting "lost" on other radios. This problem was introduced on r222 b8, and I have now fixed it on r222 c9.

Mike

[ozphoenix]

Ok, great - thanks, Mike - I diminished the erroneous reports by extending the sampling time, as you originally suggested, though I still (occasionally) got a bad reading - this now clarifies why that still occurred. I'll update both my radios to 'c9' in the coming days.

Regards,
ozphoenix

When I added support for the Jumper T12, I also disabled SPort telemetry for the T12. I just noticed I made a small mistake, which results in some SPort packets getting "lost" on other radios. This problem was introduced on r222 b8, and I have now fixed it on r222 c9.

Mike

[jhsa]

On most radios using a STM processor, I'm adding a display of the clock (RTC) battery voltage on the Date-Time menu.

Nice addition Mike, thank you.

João

[ozphoenix]

Had the weekend away from flying have now updated both radios - will have a morning of flying tomorrow, using (only) the 9XRPro (QX7 is updated but will not be using it tomorrow) - will give feedback once I return from flying, if I get the chance.

Thanks and regards,
ozphoenix

Ok, great - thanks, Mike - I diminished the erroneous reports by extending the sampling time, as you originally suggested, though I still (occasionally) got a bad reading - this now clarifies why that still occurred. I'll update both my radios to 'c9' in the coming days.

Regards,
ozphoenix

When I added support for the Jumper T12, I also disabled SPort telemetry for the T12. I just noticed I made a small mistake, which results in some SPort packets getting "lost" on other radios. This problem was introduced on r222 b8, and I have now fixed it on r222 c9.

Mike

[ozphoenix]

Flying yesterday was a non-event -- too windy and gusty, by far, to bother even getting the planes out of the vehicle. Next chance is tomorrow (Sunday) - forecast looks better than yesterday.

[MikeB]

I've posted r222d1 test version.
Changes:
Add RTC battery voltage display for STM based radios
Fix bug where trims didn't work when used as mix sources unless they were also used with the sticks
Fix bug where trim switches used as logical switch inputs didn't follow the stick mode setting
Horus supports writing a bootloader from maintenance mode. The openTx bootloader may be used until I get one written XJT(PXX) bind options are stored with the model
Scripts may use alert() to pop up an alert or a message
Script subroutines (gosubs) may return a value as in "return x". This may be retrieved by the function "returnvalue()"

alert( "string" ) displays an Alert and the "string".
alert( "string", 1) displays a Message with the "string".

subroutine:
return 17

gosub subroutine
x = returnvalue()

results in x containing the value 17

Mike

[jhsa]

Mike, Thank You so much..

João

[ozphoenix]

A good morning for flying - 5 of the planes I flew use telemetry reporting of Lipo voltage - did not have a single 'mis-report' of the voltage from any of the flights - hopefully, this latest update has resolved the 'dropped' telemetry values.

Thanks Mike, much appreciated.

Regards,
ozphoenix

Flying yesterday was a non-event -- too windy and gusty, by far, to bother even getting the planes out of the vehicle. Next chance is tomorrow (Sunday) - forecast looks better than yesterday.

[ys11]

Hello Mike.
I have some question about SNR and RSSI.
My devices are Turnigy 9x, ersky9x r222 d2, AVR 4in1 with ver1.2.1.22
Receiver is Flysky i6b, and I have Cus1 = 0, Cus2 = 44, Cus3 = 104, RSSI = 75.
SNR should be Cus3 (NOISE) - RSSI = 29. But it shows 44.
Using same RX and Taranis Q7 with Open TX 222 shows RSSI 60 and SNR 44.
So I assume RSSI in ersky shows low shift value 75 instead of 60?

[MikeB]

Cus1 is the error rate.
Cus2 = SNR.
Cus3 = Noise.
The RSSI value display is 135 - the received value.
I do this because the RSSI value sent using AFHDS2A telemetry is low if good and high if bad. Using 135-RSSIvalue, gives a number this drop as the RSSI becomes less good, and allows you to set values for the warning and critical levels in the telemetry menu.

Mike

[ys11]

Mike.
Thank you for reply.
I understood how and why you calculate that way.
There is versatility with Frsky receivers, so I think you modify RSSI value.

My environments, NOISE level is around -104dBm.
When close to TX, AFHDS2A receiver gives -60dBm, so SNR is 44dB.
When your calculated RSSI 45 gives me SNR of around 15.
So alarm level 45 will be reasonable.
Alarm level 15 and critical level 9 are reasonable?
When environments changed to NOISE level of -94dBm, RSSI still shows 45.
But SNR value goes to 5 and this value means receiver not working properly.
I think it’s better to use SNR for alarm and critical level.
I’m not good at these thing, but I think that way.
How do you think ?
ys11

[MikeB]

You may disable the RSSI warnings by removing the ticks beside the values in the telemetry menu, then you may add a voice alarms that monitor the SNR value and report if it becomes too low.

Mike

[interestingfellow]

....On FrSky transmitters, the XJT heartbeat signal is built in, so these use it already....
....The protocol menu is also getting a "double rate" option for sending all 16 channels within 9mS.
These two options together guarantee reducing the maximum latency you may get by 18mS.

I am soo sorry to keep asking questions with seemingly simple answers, but I just want to be sure...
It's safe and preferred to select double rate on any radio that is running ER9x/Sky9x for XJT?
I ask because I have an X7.

Thanks!

[MikeB]

Yes, no reason not to use it. Almost it is only in as an option so I could switch it on and off while testing and measuring latency.
I did notice a problem when binding with it enabled, but I fixed that by automatically turning it off when binding, so quite safe to use and improves latency.

Mike

[MikeB]

The next test version will include the ability to set a (4-character) name for each of the 6 custom telemetry values (Cus1-Cus6). This name will then be displayed instead of CUs1-Cus6 on custom telemetry screens.

Mike

[jhsa]

Mike, I am not very familiar with those custom telemetry fields.. Are they any useful with D8 telemetry and openXsensor?

Thanks

João

[ys11]

Hi Mike
Adding Cus 1 - 6 sounds very nice and thank you.

I did set voice alarms and they works.
When SNR value came to 20, RSSI shows 50 and “telemetry lost” was call out.
Then telemetry screen shows all value 0.
So I assumed value 125 through 120 is good to calculate RSSI.

And I set voice alarm, Cus 1 value 20 with fs-ia6 receiver.
After voice alarm sounds and then another voice call out “ 19 “ was happened.

Is this manage to do that ?
ys11

[MikeB]

Mike, I am not very familiar with those custom telemetry fields.. Are they any useful with D8 telemetry and openXsensor?

Thanks

João

Not really, although you may put the result of a Scaler into one of them.
I possibly need to add picking up unknown 'D' sensor IDs and add them to the unknown list.

Mike

[jhsa]

Thanks.
So, the HUB protocol does not use IDs then..
Not possible for example to use 2 oXs at the same time connected to the same receiver??

Sorry if it is a stupid question.. Been doing real work for quite a while now, so I start to forget stuff. I am also getting older, which is nevertheless a good sign. Many don't

João