er9x development

[MikeB]

New version released:

Protect telemetry data reading, the 16-bit access is proteced from interrupts causing possible odd readings.
Vario parameters stored in EEPROM.
Rotary LONG exits popup.
No delete on popup for current model.
Disable stick scroll on mode change - this prevents unexpected scrolling when the "scrolling stick" changes to the throttle stick.

Mike.

[MikeB]

I've just discovered that FrSky telemetry user data packets have extra bits set in the 'count' field. I just monitored the data out from the back of my DJT module. The FrSky version has therefore just had a fix applied and a new commit has happened!.

Mike.

[jhsa]

And what will that change?

Thanks,

João

[MikeB]

Hopefully, some unexpected telemetry values won't happen any more, and the user telemetry processing will be faster.
For example, I have seen the count field contain the value 0xC4 (decimal 196). This really means 4 bytes to process, but the code was processing 196 bytes. Should the code find a byte of 0x5E, it would take the next 3 bytes as telemetry data.
I don't know when FrSly changed the protocol from the receiver, log files I made some time ago only ever had values from 1 to 6 in there, now we seem to get F1, E2, E3, C4, C5 and C6.

Mike.

[Iksbob]

Speaking of telemetry, I have a few suggestions / feature requests (if you want a break from bug-hunting):

A method of scaling and otherwise formatting (offset, smoothing?) the telemetry data so it can be used as a global variable.
- The TX could automatically trim a model as battery voltage, fuel level or other variables change.
- Alarms could be set for other telemetry data (altitude, decent rate, current draw, over-temperature, etc.)

Additional alarm tones, and possibly a dedicated screen for alarms, rather than relying on a mix.

Proportional alarms. An alarm that changes in rate, pitch, duty cycle and/or haptic level depending on a GV, channel value or similar proportional value.

Let the graphed variable and time-base on the stats screen be changed to other available proportional sources. An integral function could be useful there too.

Thanks, and keep up the good work.

[MikeB]

I have some ideas in mind for the scaling of telemetry.
I'm not sure we need more alarm setting capability. You can already set an alarm by using a custom switch and then a safety/voice switch, either as voice or as alarm.

There will be limits on how much can be added to er9x stock due to the M64 limit. We might manage more on a M128/M2561 version. I have just bought a M2561 chip. My main problem will be test setups. I don't have enough 9Xs to test all different versions of er9x/ersky9x, and have one available for actual flying!

Mike.

[Iksbob]

You can already set an alarm by using a custom switch

True. What I'm looking for is more options for non-visual feedback from the TX. The 3 stages of beeping work ok for "check the display", "there's a problem" and "your plane is on fire". I would like a bit more granularity - Different beeps/chirps/buzzes so you know what the issue is, and potentially its magnitude without taking your eyes off the model.
The proportional feedback is an extension on the magnitude concept. I could see a glider pilot tying it to vario telemetry, sending out an audio tick for every 10cm gained or lost... A geiger counter for lift if you like.

There will be limits on how much can be added to er9x stock due to the M64 limit.

Of course. I'm hoping some of this stuff would be simple enough to add by tweaking existing code (such as the stat graph).

[gohsthb]

Have you tried the pispkr mode? I think I saw other sound options available with that. Of course I can't remember exactly without looking at my TX right now.
-Gohst

Sent from my LG-P999 using Tapatalk 2

[Iksbob]

Have you tried the pispkr mode?

Yes, I've been on PiSpkr all along. I thought I remembered seeing other alert options as well, but can't find anything now.

[jhsa]

another option would be voice. It would just tell you that your plane is on fire, and no need to think what the beeps mean.

[MikeB]

Alarm tones are available in the SAFETY switches menu. Each SAFETY switch has a type field, by default it is 'S' for safety. Other options are 'A' for Audio and 'V' for Voice. If you set it to 'A', then you may select a switch and an audio sample. When the switch turns ON, the audio sample is played. While the switch remains ON, the audio sample is repeated every 8 (I think) seconds.

Vario output has very recently been added, settings in the Telemetry2 menu.

Mike.

[Iksbob]

Alarm tones are available in the SAFETY switches menu.

Ah, I see. So we really just need those existing alarm tones to be made available on the telemetry page and mix options. Making the tone/haptic parings adjustable might be nice.
(Never satisfied)

[MikeB]

In what way? I'd actually like to remove all the specific telemetry alarms. They were implemented first, but since then the custom/safety switch method has been added. All the hard coded alarms are really just taking up flash space, and can all be replaced using the custom/safety switch methods.

Mike.

[Iksbob]

I'd actually like to remove all the specific telemetry alarms.

That would make sense. The FrSky module has its own alarm function that might need code. But honestly, I never found the module alarm particularly useful over the TX's. I suppose it could be useful to folks that haven't upgraded to a Piezo, magnetic speaker or voice module.
The first telemetry page could become strictly data scaling (raw data -> display value as well as raw -> GV), if such a page is needed.

[msl272]

BAG in ER9X and EEPE.

For equipment with mode2 on screen "modes" is mixed up trimmer E and T.
Installation made for "E" work for channel "T".

[Kilrah]

Have you set mode correctly in the radio settings?
Maybe you've set "CrossTrim" on?

[msl272]

it is adjusted

FM0 RETA
FM1 ID1 R0TA
FM2 ID2 R0TA
FM3 --- 0000
FM4 --- 0000

Channel "R" has 3 trimmers
Channel "E" has 3 trimmers ???
Channel "T" has 1 trimmers ???
Channel "A" has 3 trimmers

[MikeB]

Please post a copy of your EEPROM, as saved by eepe.
I just did a quick test in eepe and it seems OK.

Mike.

Edit: I think I can see the problem, I'l investigate.

[MikeB]

This is related to a general problem regarding the stick mode, and changing modes. I need to either change the flight modes display, thus changing RETA into RTEA for mode 2, or I need to do a major change to sort the stick modes problem.
The latter change involves an EEPROM change so I need to think very carefully before doing it.

Mike.

[MikeB]

It may be that now is the time to consider a major change. What I'm thinking is to stop building er9x and start building er9xV2, something Erazz and I started before Erazz drifted away. This will make controlling changing the EEPROM change easier to do, and makes it more obvious to users there is a major change.

Basically er9xV2 will likely use a new format EEPROM, and be a new start. I'll put something in eepe that will allow some automatic upgrading of the old EEPROM.

Mike.

[jhsa]

you realize that will be a big task for a one man Band but I think at the end the result will be a cleaner firmware.. I remember you saying many times that you must find a workaround for many of the features.. You know I'm in for testing

João

[Rob Thomson]

Good idea

Sent from my GT-I9300 using Tapatalk 2

[msl272]

Transition on new version it is necessary to combine with transition on new processor mega128 or better.
Then effect will be maximum.
As soon as force the producers to release the new charge?

[MikeB]

The Mega128 is already supported. There is only me doing the changes so I don't know how long it will take.

I might try a quick change to re-label the flight mode trims.

Mike.

[Iksbob]

Could you put a version tag in the eeprom to indicate the new (fixed) version? Have eepe check for the tag and convert/fix the eeprom if needed.

[MikeB]

There is a version number in there already, in the general settings, and I just see it is put into the eepe and eepm files as well.
The main problem with this mode change is I have no way of knowing (as far as I can tell so far), on an eepm file, which mode the Tx was in when it was saved. Therefore I don't know what changes are needed.
I'm still finding out what the actual problems are!

In the short term I have a fix for the flight mode labeling, both eepe and er9x, that makes it correct (until you change modes!).

Mike.

[MikeB]

Eepe will need quite a lot of changes to handle an updated EEPROM structure, while remaining compatible with older structures and being able to convert between them.

In general, I just want to do a single structure change, fixing a number of things, and perhaps expanding/extending some others. These extras may make individual models take some extra EEPROM, so you may end up with fewer models actually fitting in the EEPROM.
Maybe this won't be a real problem for most users!

I'll also look to making the structure different/larger for the M128/M2561, more work for eepe!
(I have just bought a M2561 but I'm not sure which board to put it in. I have 3 9Xs, 1 with the sky board and 2 with M64s, not enough to have test systems for all the different processors!).

Comments/suggestions welcome, but remember most users are still on the M64.

Mike.

[Flaps 30]

Maybe some kind soul might wish to donate a 9X to you Mike.

[msl272]

In the "modes" screen of the logician of work remains correct. It isn't necessary to remake memory structure.
It is enough to change only letters:
RETA for mode1
RTEA for mode2

[msl272]

The main stage of control of model is installation of limits and the central point.
At change of the central point always it is necessary to recalculate values of limits for the size of a subtrimmer.
This procedure has to be carried out automatically. It is in many known transmitters.
For example we have:
CH1 00 - 80 +80 ---.
we change the central point on +12. It has to turn out:
CH1 +12 - 68 +92 ---.