ERSKY9X Coding

[jhsa]

Mike, I was just playing with the scalers and some idea came up.
In addition to the current settings, would it be possible to implement a "Scale" option where we could take an input and change the "Scale" value until we were getting the desired scaling?? That would make it a quicker and easier way for the people that are not very good with mathematics, like myself

Obviously when using such an option, multiplying and dividing would have to be disabled?
Offset would have to be used as well in some cases, of course

Thanks

João

[MikeB]

What sort of values would you see the "scale" value taking?

On ersky9x, the multiplier and divider are allowed to go to over 2000 now, not just to 256.
So, if the divider is set to 10, you can scale from 0.1 to 200.0 in steps of 0.1.
If the divider is set to 100, you can scale from 0.01 to 20.0 in steps of 0.01.
If the divider is set to 1000, you can scale from 0.001 to 2.0 in steps of 0.001.

I can easily extend the multiplier and divider to 50000 if needed.

Mike.

[jhsa]

That is very nice indeed. Please note that I'm not suggesting to remove the Multiply and divider options, that would be stupid, as we for sure need it for more complex calculations..
But if the "Scale" option was used, those could be disabled..

I was thinking just a scale factor number. greater than 0 if scaling up, and smaller than zero (with decimal point) is scaling down the value.
Alternatively you could use positive numbers for scaling up, and negative numbers for scaling down, but I don't think this is the conventional way of doing scaling..

In other words the multiply and divide operations would be done internally by ersky9x depending on the scale value set..
We would then need the offset field of course.

It's a bit difficult for me to explain, and I do apologize for that

Thank you

João

[MikeB]

So what would the scale value look like? How much resolution is needed?
If the multiplier is allowed to go to 50000, then with a divider of 1000, you can scale up to times 50 in steps of 0.001.
So you can have 0.376 if you want, or 47.234.
I'm also thinking how would the scale value be entered?

Mike.

[jhsa]

The idea is to get rid of the multiplier and divider, as they are hard to use.. About the resolution, I'm not sure. The idea is to increase or decrease the "Scale" value until you have the desired scaler range for the full input range. My idea is a very superficial vision of the results. I don't know how the scaling works mathematically
So, I imagine an input with certain range, and I would like the scaler to have a range within certain values.
I thought using "only one" scaling factor and an offset we could have the desired range at the output (scaler), without messing with multipliers and dividers..
This way, this could even be adjusted by trial and error. Just watching the values change while we change just one setting.

João

[Daedalus66]

Hi Mike

A little help with a minor irritation in flashing ErSky9x on my Taranis X9D, please. The transmitter is from the very first batch sold by Aloft Hobbies in 2013. The firmware is the latest test version as of a few days ago (but the issue has been there on all versions since I replaced OpenTX about six months ago).

The problem is with the boot loader only (v. 2.2 now but has been the same in previous versions). It's that the buttons don't work as they do in the firmware.

Top right is up, middle right is down, bottom right is Menu, bottom left is Exit. Top and middle left don't seem to do anything (Left/Right?).

Not hard to figure out but it would be nice to have it work as in firmware to avoid confusion for other people.

This doesn't happen with my Taranis X7 of course. And the buttons work normally in Maintenance Mode.

No rush.

Nigel

[MikeB]

The idea is to get rid of the multiplier and divider, as they are hard to use. . .I don't know how the scaling works mathematically
This way, this could even be adjusted by trial and error. Just watching the values change while we change just one setting.

That's my point about setting the divider to 1000, the multiplier then acts about like the scale factor you are referring to.
Mathematically, the scaling will work as "multiply by the multiplier" then "divide by the divider".
So, since the scaled result is shown on the top line while editing, just set the divider to 1000 (or 100), then adjust the multiplier as though it is the scale factor you describe, until the scaled result is what you want.
It may, in time, be possible to present this differently.

Mike.

[MikeB]

The problem is with the boot loader only (v. 2.2 now but has been the same in previous versions). It's that the buttons don't work as they do in the firmware.

That was deliberate because the bootloader doesn't display the images beside the buttons to show their changed function, so I use the finction shown on the case. I think I have saved some space in the bootloader, so I can look to change the functions and display the images.

Mike.

[jhsa]

That's my point about setting the divider to 1000, the multiplier then acts about like the scale factor you are referring to.
Mathematically, the scaling will work as "multiply by the multiplier" then "divide by the divider".
So, since the scaled result is shown on the top line while editing, just set the divider to 1000 (or 100), then adjust the multiplier as though it is the scale factor you describe, until the scaled result is what you want.
It may, in time, be possible to present this differently.

Mike.

Thanks Mike, I will try later what you are suggestion, It looks quite easy setting the divider that way.
The problem is, in a couple days/weeks this information will be lost in this thread Therefore it would be nice if it was possible to implement something easier in Ersky9x. I think people are a bit scared about touching the scalers. I remember when I bought a new radio years ago, I wouldn't touch the settings I didn't know because I was afraid of causing some catastrophic event when flying my models

Thanks

João

[bob195558]

That's my point about setting the divider to 1000, the multiplier then acts about like the scale factor you are referring to.
Mathematically, the scaling will work as "multiply by the multiplier" then "divide by the divider".
So, since the scaled result is shown on the top line while editing, just set the divider to 1000 (or 100), then adjust the multiplier as though it is the scale factor you describe, until the scaled result is what you want.
It may, in time, be possible to present this differently.
Mike.

Thanks Mike, I will try later what you are suggestion, It looks quite easy setting the divider that way.
The problem is, in a couple days/weeks this information will be lost in this thread Therefore it would be nice if it was possible to implement something easier in Ersky9x. I think people are a bit scared about touching the scalers. I remember when I bought a new radio years ago, I wouldn't touch the settings I didn't know because I was afraid of causing some catastrophic event when flying my models
Thanks João

João,
Could there be an update to the er9x (/ erSky9x) Manual to give the info needed and maybe reference back to this post for more info ?

Bob B.

[jhsa]

I will try to do that. I am also currently working on a Ersky9x video manual.

Mike, I'm having here a little problem with the telemetry.
I am sending 2 voltages on oXs using the fields A3 and A4, Volt_1 and Volt_3. The problem is that I am not getting anything on the custom display, I can see the FasV voltage which is Volt_2 on the oXs.

The A3 and A4 fields blink meaning that nothing is received?

I am using the DHT and a DiY receiver. Telemetry is obviously working as I have the other voltage on screen.
Here is my oXs config file. Don't know what is happening..

Thanks

João

[Daedalus66]

I have recently revived my work on an updated ErSky9x Guide, a project that grew out of the Er9x manual that João and I did in 2015. I was well advanced with it last spring when medical issues intervened.
I'm now well launched again and determined to get the main text out quickly, rather than finishing all parts of it before releasing anything.
Of course I'll be looking to João to make sure I get things right and ultimately to Mike for necessary guidance.
I was keeping it under wraps, but now's a good time to make it known.

[MikeB]

I am sending 2 voltages on oXs using the fields A3 and A4, Volt_1 and Volt_3. The problem is that I am not getting anything on the custom display, I can see the FasV voltage which is Volt_2 on the oXs.

The A3 and A4 fields blink meaning that nothing is received?

I am using the DHT and a DiY receiver.

FrSky 'D' telemetry doesn't support A3 and A4, only SPort does. If the oXs is sending something for A3 and A4, it must be using IDs I don't know about. Can you find out what IDs it is using?

On another item, I've just realised I can't auto-detect the serial receive polarity from the bootloader in the multi module as the main code may be using a different polarity to the bootloader. I'm adding an option so you may set this instead.
Since I added some code to allow COM2 to be used inverted for flashing the multi module, I'm trying to get this added to the main firmware. There will be a limitation that you will only be able to invert one of COM1 or COM2 as I can't handle two, bit-bashed serial ports at 100K baud at the same time. Lots of things will need testing with this change as I've needed to make some significant changes to get this to work. The bit-bashed code is also used by the trainer input when in SBUS mode, although this has a timer to do the capture, so may be able to operate at the same time as one of the COM ports.

Mike.

[Daedalus66]

The problem is with the boot loader only (v. 2.2 now but has been the same in previous versions). It's that the buttons don't work as they do in the firmware.

That was deliberate because the bootloader doesn't display the images beside the buttons to show their changed function, so I use the finction shown on the case. I think I have saved some space in the bootloader, so I can look to change the functions and display the images.

Mike.

That makes sense and had never occurred to me. I've had it this way for a few months and have stickers on the screen to indicate the new functions, so had forgotten how the buttons worked in OpenTX. It was thinking about writing on how to use ERSky9x on the X9D (see previous post) that made it seem anomalous.

So that raises the question of whether it would be more intuitive to have the boot loader buttons work as they do once you've got ERSky9x installed:
Up Menu
Left Right
Down Exit
As shown in the picture:

Or as they do now:
Blank Up
Blank Down
Exit Menu
Which is more familiar to someone coming from OpenTX.

I'll give the whole thing some thought. Opinions welcome.

[jhsa]

Mike, I had an answer about A3 and A4.
Here is the link in case you didn't see it.

viewtopic.php?f=86&t=6080&p=126712#p126711

Is it not possible to assign ID's to those fields for the HUB protocol? Or are they all being already used?

Thanks

João

[MikeB]

We could probably add some more IDs, but that means changing ersky9x to handle them. If you use the ACCX/Y/Z fields, you should be able to get it working with the firmware as it is.

Mike.

[jhsa]

Thanks Mike, I will do that, although the idea of having more fields available is very attractive.

Thank you

João

[MikeB]

So that raises the question of whether it would be more intuitive to have the boot loader buttons work as they do once you've got ERSky9x installed

I do notice I press the wrong buttons in the bootloader at times.
The next test version will have the on screen labels visible and the buttons changed to match ersky9x operation.

Mike.

[jhsa]

I believe that is a good idea Mike. People that use Ersky9x might already be used to the new key assignment. So even if you didn't put the labels on the bootloader screen, it would already be a great help if the keys worked as in the firmware..

João

[jhsa]

We could probably add some more IDs, but that means changing ersky9x to handle them. If you use the ACCX/Y/Z fields, you should be able to get it working with the firmware as it is.

Mike.

I think I have it working Mike. It's like this.
I wanted to detect when the glow plug on my plane goes bad, so I have the oXs measuring the voltage of the glow battery (1 cell LiPo), and also measuring the voltage at the glow plug (other side of the mosfets). The voltage at the glow plug is about 0.45 volts when it is ON. So, if this voltage goes up to around the battery voltage it means the glow plug is open, or there is some other problem with its connection. Maybe a good idea inserting a resettable fuse in line with the plug, to protect the Mosfets against possible shorts? I could possible do it by software as well, something like, if the voltage drops to under a threshold near 0V it should turn the driver off. This could have a little delay to avoid preventing the plug from turning ON as the initial voltage before it turns on is about 0V?
Shame that the logical switches do not have a "Delay" option I believe it would make sense in some cases I think.

My Scaler settings for the ACC fields are:

Multiplier 1
Divider 10
Offset -88 (around this value)
Decimals 2
Units - Volts (it would be nice to have also mV for detecting small voltages more accurately. I know I can still do it but the mV would be a nice touch ).

Another problem, I gave a name to the scalers, but when I select them in the custom telemetry screen, they are still displayed as SC1 and SC2. I thought the name we gave would be displayed instead? That would make sense, or am I doing something wrong?

Thanks

João

[jhsa]

Another problem, I gave a name to the scalers, but when I select them in the custom telemetry screen, they are still displayed as SC1 and SC2. I thought the name we gave would be displayed instead? That would make sense, or am I doing something wrong?

Thanks

João

I have just made a video of this setup working and noticed that the Scalers's names I programmed are now showing.. I don't understand why they didn't show before
As i said, here is the video. i still have to sort the great number of voice alarms when I turn the power off.

https://www.youtube.com/watch?v=hmNHB02mrBI

João

[bob195558]

João,
The youtube-video address did not work, as it went to youtube home address.

Bob B.

[jhsa]

I see the problem. Will edit when I get home.. At the field now

[jhsa]

Video Link above hopefully fixed

João

[jhsa]

Mike, I may have a little request that I believe would enhance the logical switches even further. Two options that for sure will be very useful as one would probably eliminate the need for using a channel to trigger the switches, and the other would also simplify the use of the logical switches by allowing just one to do the job of a combination of logical switches.
1 - A "Delay" option on every switch. This would avoid a combination of switches or the use of a channel.. Sometimes a delay is necessary..
2 - A "Range" function. Many times we need to detect a certain portion of for example a channel's range. It would also be useful for telemetry values..

I know that this brings another problem. Space on display, as at least another field per line is needed. I think for the range function, 2 other fields would be needed. It would have to be something like:

L1 Range Ch3 -15 +85 (AND) THR

If including a delay:

L1 Range Ch3 -15 +85 (AND) THR (Delay) 0.5

I know that display space is a problem, but there must be a way of solving this problem? otherwise it would be preventing some good enhancements of the the Logical Switches, and perhaps other settings. So this affects the overall improvement of Ersky9x in my opinion.

Maybe possible an "edit" menu like in the mixer? And then display some LS key info on the switch line? Just like the mixer or the scalers, or the voice menus??
This would allow the logical switches much more room for further development..

Thanks

João
João

[elral]

Hello Mike, hello all,

sorry for jumping in with another topic.
Yesterday I tried to change the input source within the mixer menu. I choosed a mixer from the main mixer menu, the next window pops up. There I tried to change the input source with the encoder, which didn't worked (or I couldn't find out how to do it). Short press on the encoder switch opens the next window to adjust DR/Expo, a long press brought me back to the main mixer menu. Only pressing the left or right button worked to change the input source. And in the moment I have no idea how to handle this with just the encoder.

Regards

Ralf

[MikeB]

What radio? If you have a MENU button, then a short press enables editing mode (option highlight flashing), then the encoder changes the value.
This problem occurs because of the "shortcut" to the DR/EXPO screen for the case the source is a stick. If the source isn't a stick, the the encoder button works to allow editing. I'll see if I can improve this operation.

Mike.

[MikeB]

1 - A "Delay" option on every switch. This would avoid a combination of switches or the use of a channel.. Sometimes a delay is necessary.

Aside from the fact this doesn't fit in with the way logical switches are generally processed, to what would the delay apply?
Is it the function becoming true, or the function becoming false, or both. Should it include the AND switch?
What about when a switch depends on another switch, e.g. the AND and OR functions. Should this switch only respond after the delay on the others have been taken into account, then add its own delay on?

Mike.

[jhsa]

Aside from the fact this doesn't fit in with the way logical switches are generally processed, to what would the delay apply?
Is it the function becoming true, or the function becoming false, or both.
Should it include the AND switch?

My opinion is The delay would be applied after all conditions are met to turn the switch ON, including the AND switch of course.
Just the normal way the switch works, plus the delay.
I didn't think about applying the delay when turning OFF or BOTH. It might be a good addition though if you could implement it. More possibilities. I can imagine people requesting it in the future

What about when a switch depends on another switch, e.g. the AND and OR functions. Should this switch only respond after the delay on the others have been taken into account, then add its own delay on?

Mike.

Yes sure, the delay is part of the other switch's behavior. It makes sense. If for some reason you don't want to use the other switch with the delay, then you should create a new one without delay, but with the same conditions of the other, simple.. Then you can use the condition with delay for something, and the same condition without delay for something else..

I didn't think about it but cascading some Logical switches with delay should allow for some interesting programming. One thing that comes to mind (without thinking of what is involved to do it) is light effects..

Thanks for looking into it

João

[MikeB]

Currently, the logical switches are (mainly) only evaluated when needed, e.g. when set as a switch in a mix.
To handle a delay, they will all need to be evaluated on a regular basis, e.g. every 0.1 seconds. In addition, if one switch depends on another, the other one will need to be evaluated before the current one. This may be a "forward reference" if L2 depends on L3. Then having evaluated L3 to be able to do L2, we don't want to do L3 again. We also then need to cover the possibility that L2 depends on L3 and L3 depends on L2, or even L2 depends on itself!
Then there are the latch, f-flop, timers and monostables. Should these include the delay option? Is it meaningful if they do?

Perhaps we just need a new logical switch function of "Delay". This would take a switch and a time as parameters and so provide the delay when needed.

Voice alerts do include a delay option.

Mike.