openrcforums

Hey guys,

I'm using the er9x Version seen on the photo because this one is the best for me!
The latest had some issues on the safety Switch page where the lines are bended, so I can't read the voice names anymore.
However...

Since the 81x Version I've got some strange Cursor blinkings on the upper left side on every Screen.
Not always but sometimes when I press a key or Change something.

Don't know if someone else got this but it's a Little bit annoying.
What could that be?

Greetings
Kilo

It's an indication that a write to the EEPROM is pending, because you have changed a setting somewhere. If you switch off while that is present and flashing, then the change you have just made will NOT be written to the EEPROM. Changes are not written immediately as the EEPROM does have a "life". If you write to it too many times it eventually stops working. Writes are therefore delayed so if you make another change the EEPROM is only written once, not several times.

Mike

Ha...
Thx Mike... that makes sense. And I thought it would be an issue. sorry...

But...does it also write the actual mainscreen to the EEPROM? I think, everytime I change the mainscreen and turn off the TX immediately the screen before appears when I turn on.
If I wait a time the latest screen appears. Without making changes.
Isn't it good for the EEPROM to write so many times?

It does, but with a much longer timeout. I think there is a 2 second delay after editing a setting, but a 20 second delay after changing the main screen. You may see this as the flashing line in the top corner is longer when you change the main screen, and the EEPROM is not written until the line disappears.

The EEPROM is rated for 100 000 erase/write cycles. This is for each byte. Not all bytes are written every time a setting is saved.

Mike

Ah okay...
Thx Mike!

Does it includes in the 2015s manual? Or did I miss it?

Btw: did you get the issue from my first post about the safety switch page in r821? The gap between the switch and the sound/voice is too big so that I can't read the voice name. It vanish out of the lcd screen and appears on the next line..

I'll fix that and post a test version soon.
Unless you have used all the "Voice Alerts", I recommend using them rather than using a safety switch in "A" mode.

Mike

Ok, I can fix the name missing, but there is a bigger problem with Safety switches in 'A' and 'V' modes and also with voice switches in general. Both of these were added when voice output first became available, but other things have been added since, like allowing 2-pos switches to be replaced by 3-pos switches.
Safety switches only have 6 bits available for storing the switch and voice switches only have 5 bits. Allowing for switches to be both ON and OFF, and all the possible extra switch positions with many 3-pos switches and some push buttons needs over 88 different values. This many needs 7 bits to store the switch.

I'm thinking about what is the "best" solution.

Mike

Mike, shouldn't audio and voice only be dealt by the Voice alarms, which are in my opinion a much better implementation? I thought you had removed the audio and voice in safety switches, as it doesn't make any sense having them at all?.. This would even mean flash savings on the m64 version?
Or is there a problem in the safety switches in general?

Thanks

João

There are only 8 voice alerts (er9x V1), and this may not be enough for all voice outputs required, so I have left audio and voice in safety switches.
Proposal:
Safety switches changed to be just that, either ordinary safety of sticky safety, so remove the "A" and "V" options. This will leave 7-bits for the switch.
Voice switches, of which there are 8 or more if you convert some safety switches.
Currently these have 7 options:
ON
OFF
BOTH
15 Secs
30 Secs
60 Secs
Variable (i.e. a telemetry value).

Reduce these to 4 options:
ON
OFF
BOTH
Variable.
and reduce the switch values to only the "positive" values (i.e. !ELE is not available). This should be OK as using something like:
VS16 !ELE ON ....
is the same as:
VS16 ELE OFF ....

Allow the "Variable" that may be selected to also be one of the built in audio tones (as currently allowed in the safety switch "A" option).

The 15, 30 and 60 Secs may be achieved by using a logical switch in timer mode (timer mode wasn't available when voice switches were first added!).

These changes will mean you may need to reconfigure models, but currently, if you have at least one 2-pos switch converted to a 3-pos switch it all goes wrong when editing the switch!

As you say, use Voice Alerts first anyway.

For information, each safety switch or voice switch only uses 2 bytes of EEPROM/RAM. A Voice Alert uses 7 bytes. If the voice switches were removed completely, and the EEPROM/RAM used for voice alerts, you would only get 2 more voice alerts.

Mike

MikeB wrote: ↑Fri Apr 12, 2019 6:02 pm

For information, each safety switch or voice switch only uses 2 bytes of EEPROM/RAM. A Voice Alert uses 7 bytes. If the voice switches were removed completely, and the EEPROM/RAM used for voice alerts, you would only get 2 more voice alerts.

Mike

That is only on the m64, right?
The m128 could have more? And the m2561 has even the double of the RAM..

João

No, the '128 has less spare RAM than the '64. Also, the EEPROM structure needs to be common to all three processors. Since this is loaded into RAM, any additions to the EEPROM affect all processors RAM usage.

Mike

MikeB wrote: ↑Fri Apr 12, 2019 9:30 pm No, the '128 has less spare RAM than the '64. Also, the EEPROM structure needs to be common to all three processors. Since this is loaded into RAM, any additions to the EEPROM affect all processors RAM usage.

Mike

Hmm, so what is the advantage of replacing the processor with a m2561??

João

I've got the code changes done for the proposal above, all seems to be working. Currently it is conditionally compiled so I can turn the change off if necessary.

Using the extra RAM of the '2561 needs some thought. One possibility I'm considering is to add an extra file on the EEPROM that contains some extended radio settings. This would allow something to be added to the '2561 that doesn't affect the '128 or '64 versions.
My first thought is this could contain some Global Voice Alerts.
This would require a change to eepe at the same time or this extra file would be lost when reading then writing the EEPROM from eepe.
Adding this, if I do, will take some time, and I have some other things I need to finish first.
Note the EEPROM structure is unable to support more than one or two extra files, so we can't add a file for each model.

Mike

I've come up with a way of having more items in the radio setup EEPROM for the '2561 that still allows new items to be added for the '64 and '128 as well, but without needing the '2561 items declared or loaded into the '64 and '128.
With some quick cut and paste operations on the source files, from ersky9x, I think I have 8 global voice alerts added to the '2561 code. It seems to work OK, but I need to do some more testing.

Mike

Woow, thank you.. Please let us know when you've posted it..

João

Just posted!
Access the Global Voice Alerts from the RADIO|AudioHaptc menu.

Mike

Oh, they are global?? Missed that part of your post..
Wouldn't be more useful to add them to the mode setup? Or is there too much for the m2561 as well??

Thanks

João

The '2561 doesn't have any more EEPROM than the '128. If I added them to each model, this could add 56 bytes to each model on the EEPROM. So with 16 models, this could be 896 bytes or a quarter of the EEPROM!

Mike

Perhaps 2 per model? Or is it still too much? And then perhaps some 4 global? Or 2 per model and none as global?
In my opinion, I think they are more useful in the model setup..
What about the possibility of an external eeprom? Is it worth it?

João

I doubt it is worth adding an external EEPROM. If you have a serial voice module you do have the backup and restore options.

I think the global voice alerts could prove quite useful. If you set one up controlled by a logical switch, you may then configure models to use it or not by defining the logical switch.

When I get time, I may be able to use the same technique to add things to each model, just for the '2561. I need to get the new FrSky ACCESS protocol working.

Mike

Thanks Mike..

João

Sent from my BLN-L21 using Tapatalk