er9x development

[jhsa]

Yeah, I was a bit confused cos Mike quoted my post from another thread he he.

The idea is to let the telemetry values affect mixes, rates, curves, etc, proportionally.

Imagine for example you have a GPS on the model. You could use the speed to control rates for example. the faster the model flies, the more the rates decrease. we would really need a IAS (indicated airspeed) sensor for this to work more accuratelly.
Also another one that just comes to mind, is to deploy flaps automatically according to speed being their angle controlled by how fast the model is flying.
In theory, you could even control the motor channel so the plane would not fly over a certain altitude..

Just a few examples.. I'm sure there are zillion of applications for this feature And it is cool

João

[LTMNO]

Thanks, very cool…. its exactly what the APM does…
But I love the idea of interacting with the Telemetry Inputs… There is an IOBoard that is interfacing now with the APM that is surfacing the Telemetry Values for FrSky Receiver. I am getting some of the APM Tele now that I can start interacting with. Very Cool Stuff...

[jhsa]

if we could have it on the radio it would be cool

[MikeB]

The GPS speed is not that useful if there is any wind, definitely would need airspeed for that. Also I think the GPS speed will lag the 'plane, so a sharp turn, or rapid change of speed could lead to problems.
I'll put it on my "consider" list, but I think I'd like to see some more possible uses before I actually add it.

Mike.

[jhsa]

we would really need a IAS (indicated airspeed) sensor for this to work more accuratelly.

That is why I said this.. But for increasing/decreasing dual rates/expo i think the GPS would be fine

I only pointed it because I saw it on the PDF with the new features that Bertrand posted earlier today.. This was already spoken here on the forums. Also it came in conversation when chatting to some members of this forum

I'm sure I can think of more applications for this feature.. we would certainly find use for it like we did for the voice despite some negative forces from the dark side telling us the opposite


Another idea.. frsky has a fuel sensor for IC powered models.. I don't know if it is progressive or not.. If it is, we could have for example the elevator trim adjusted automatically as the tank becomes empty..

On a glider, you could ajust the rate of climb based ot the vario reading.. etc, etc, etc.. Your imagination is the limit..

João

[jhsa]

Ahh, just remembered one that i mentioned a couple weeks ago..
Decrease the throttle proportionally to keep the voltage below a set value.. that will help us prevent damaging the battery even if we insist on going full throttle. a bit like some (not all) ESC's do.
For example I had my low flight battery alarm set to 10.3V The alarm would sound at full throttle with the battery still quite full. Now I've decreased the alarm to 9.9V I can use now around 80% of the battery. the problem is that if we spend most of the flight at half throttle and then decide to go a bit wild, the alarm will sound but we don't know exactly how much the voltage dropped.. we could be driving the pack too low..
With this feature the tx wouldn't let us go under that value by proportionally decreasing the max throttle..


João

[kaos]

I probably would rather damaging the lipo instead of being limited by the throttle and the plane goes down.
I think the amperage meter is probably more accurate in gauging how much you have left in the lipo then the voltage. some of my motor will chew up voltage when I go full throttle while still have plenty of 'fuel' in it for casual fly.

[jhsa]

your plane won't stop flying or go down because of it. the motor won't cut. it will limit the max throttle just enough to keep the voltage above the preset value.. when that starts happening too much it is time to land anyway.. if your voltage drops that much at the beginning of the flight, that means that either your battery's C rate is too low for that model, or that the battery isn't anymore in good condition.. you continue flying full power with that battery and you're in for an unpleasant surprise
This feature is just to avoid you damage the battery by letting the voltage drop too low when you apply a burst of power..

João

[kaos]

yep, it is the same issue as whether we should limit the Tx lipo when voltage drops to certain level. save the plane or save the Tx. You already have the voltage warning, you can reduce the throttle to keep it down. I do that all the time when voltage is low and starts to sound by preset voltage and start really casual flying or land. But without it you still have the choice to damage the lipo or save the plane in an emergency situation.
Just as an example, your voltage is low but OK, then you come across an obstacle close to your plane, you are close to ground, you need to climb quick, you can save the lipo and crash into it because the voltage is limited or you damage the lipo and get as much power as you can to avoid it.

[jhsa]

Please don't compare this with the TX voltage. they are completely different things.. the tx cut-off thing is a complete different subject. I don't understand what you mean by "limit the Tx lipo when voltage drops to certain level" though
the way this would work is to have the normal voice alarm and then this option at a much lower voltage.. something like 9.6V for example..
Normally you shouldn't be flying anyway, but just in case you are, this will keep the voltage above that level and won't damage the lipo. It would also avoid the ESC to really cut the power completely when you need it and then yes, maybe you destroy your model
Besides, as with everything else, you only use it if you want to. So, this discussion is pointless
I, and probably some others, find it useful. Others might not.. Anyway, this is just an example of what could be done by using telemetry as proportional inputs

João

[MikeB]

Still busy on some other things, but I think I'll look into my "scalers" idea again. This was to take a telemetry value and allow it to have offset and scaling applied, possibly with some units added, and allow the result to be output on voice.
I think this just needs extending to allow almost any input (sticks, pots, channels, telemetry) and allow the output to be used as channel inputs, custom switch inputs and voice.
How many you get will depend on how much EEPROM they might take up. Also with a '128 or '2561 (or ersky9x) we might have some extra facilities (EXPO?).

Mike.

[Iksbob]

Sounds good.
As another example of possible telemetry mix uses, I had a fixed-pitch blade 120 SR heli (not that telemetry would be an option in this case - i'm using it as a functional example) that needed yaw (rudder) trim as the battery ran down. While that's probably an engineering issue with the heli, it's also something that could be corrected with a telemetry battery voltage mix.

[jhsa]

Now, we're talkin'.. Who said that the 9x is dead?

Thanks Mike

João

[Iksbob]

Who said that the 9x is dead?

It's been turned into an open-source project. It will never truly die.

[kaos]

I think this just needs extending to allow almost any input (sticks, pots, channels, telemetry) and allow the output to be used as channel inputs, custom switch inputs and voice.

That's the idea. Packs as much as hardware allows, M64,M128, ARMS... - FLEXIBILITY!

[ReSt]

I would like to add one more wish.
Have channel/channel% as input for the timer trigger.

That would finally allow to count the real motor run time (battery usage), when the throttle stick is used for different functions in one model, eg motor, camber and spoiler, flaps.

Reinhard

[jhsa]

yeah, I subscribe that..

[kaos]

On that % issue. I think we never had the problem corrected with heli usage on TH% for timer. using channel% would solve the problem.

[MikeB]

I've got some code around to use CH% from something I tried in July 2011! I may well be able to add that in. Some other things have changed but I'll look into it. (Edit: Oh yes, CH% is in ersky9x, although that doesn't have RU% etc).

If I add these 'scalers' I need a name for them, something that abbreviates well. Scaler might abbreviate to SC, but this is too much like CS for custom switch so could lead to confusion.
There may be some limitation when using a 'scaler' as in input to a custom switch in v>ofs types as the ofs field is a number from -125 to +125 so thats what you compare against.

Mike.

[kaos]

How about 'SR' - ScaleR. SW and SR does not seem to be confusing.

[jhsa]

SL??

[kaos]

SR- senior
SL - senile

sorry, can't help it.

[MikeB]

I think I have the CH% working, uses up 192 bytes of flash. (Edit 182 now!)

Scalers:
Input Scalers - IS
Value Modifiers - VM

Mike.

Edit: These are just suggestions for a name, only need one of them!

[jhsa]

sorted then

[kaos]

Great news for ch% working. That is more practical than many other things. After all, ch output is what really matters. It applies across the board, not only for THR.

I like that IS.

[MikeB]

I've moved the channel order menu option from the templates menu to the main radio setup menu. It probably ought to have been there anyway, but if you have "no templates" (also as in the frsky version) you didn't have any way to set it on the radio.

I seem to have saved a few bytes of flash elsewhere , so only 144 more bytes of flash are now used than before this and the ch% change.

[Technical]
The abs(x) operation on an 8 bit integer uses a lot of flash, due to sign extension to 16 bits, then a 16 bit negate.
The following is MUCH shorter and faster:
int8_t tm ;
......
uint8_t abstm = tm ;
if (tm<0)
{
abstm = -tm ;
}

then use abstm instead of abs(tm)
[/Technical]

Mike.

[LTMNO]

Very cool, although I will not use it, very cool nonetheless...

[jhsa]

you never know, never say never

[msl272]

Correct a bug please.
At installation:
CH3 (100%)Thr
CF1 ON Safety CH03 - 100 ON
CS1 CH03 > -75

Always there will be CH3 =-100, and the CS1 switch continues to work from stick THR.

[MikeB]

Which revision of ER9X are you using?
You appear to refer to "CF1" which is "CUSTOM FUNCTION 1".
Er9x does not have custom functions, they are in openTx.

Mike.