ERSKY9X Coding

[Daedalus66]

Agree.. I already have a lot of c**p on my daily life, just don't need more at the moment

João

If someone needs to read a manual 50 pages long just to set up a timer on the Tx, there is something wrong with it.

If the manual is properly structured, you should be able find "Timers" in the contents page and just go there (it will be a little over one page). Take a look at the Er9x manual for example.

That's why Mike's restructuring of the menus was so important. We can now find our way around the firmware much more easily and this really helps with the manual too.

Of course, reading the Timer section doesn't help much if you haven't been able to set up your model, so in the end people will have to read more than that.

The manual currently under way is intended to be comprehensive and therefore it works its way through all the menus systematically. It's essentially a reference document, and that means most people won't read from beginning to end (there are a few of us who do! ).

When this basic resource is finished, I would like to produce a quite different one aimed directly at newcomers to the firmware. It will tell you the minimum you need to know to get one of these transmitters up and running with some typical types of model. A sort of "quick start for ErSky9x." But first things first.


Sent from my iPad using Tapatalk

[jhsa]

If the manual is properly structured, you should be able find "Timers" in the contents page and just go there (it will be a little over one page). Take a look at the Er9x manual for example.

Nigel, I just did that as a test, and took my time. from opening the manual file and navigating to the "Timers" chapter, took me no more than 10 seconds.. Probably less.
An eternity really
João

[Daedalus66]

Regarding "stable".

The stable releases are simply the ones that are not changing, like R218 now. This doesn't imply that the test versions are "unstable" in the sense that they have dangerous bugs. Rather they are changing by definition because they are trying things out. Use with your eyes open. Most users should stick to stable releases.

Stability in the sense of trustworthiness is a non-issue as far as I'm concerned. Mike has been very careful about this point all along and I don't recall any significant (I.e., risky) bugs in the various releases.

This is a better record than some commercial firmware. (But let's not go there!)



Sent from my iPad using Tapatalk

[Daedalus66]

If the manual is properly structured, you should be able find "Timers" in the contents page and just go there (it will be a little over one page). Take a look at the Er9x manual for example.

Nigel, I just did that as a test, and took my time. from opening the manual file and navigating to the "Timers" chapter, took me no more than 10 seconds.. Probably less.
An eternity really
João

Of course the real test is how easily someone can figure out how to set a timer and get the desired beeps, voice announcements, etc. working.

We still have some work to do to make that as clear as possible.

One of the problems a manual should help overcome is that information old and new is scattered across the forums and other sources. (You well know this from your efforts to ensure that people can find a good, up to date set of voice files.) The manual should be a single go-to source for the basic information including links to resources.


Sent from my iPad using Tapatalk

[OctavioS]

Currently we have the r218 release. This is the present "stable" version. I'm not clear on what extra stability issues there are.
Yes, there are additions/updates, but I thought the user interface hasn't changed significantly since I added the index menus.

The following are the changes I have since r218. I don't think any of these affect to 'core' functionality or the user interface.
H8_3D MULTI supported
Correct direction of P2 on Taranis
Add P4 and P4 as sources for GVARS
Add Encoder switch to DIAG_SWITCH display
Re-label delay up/down to match slow up/down directions
Fix missing haptic output when using model specific countdown beeps
Add SD Card present data on SD STAT display
Force Ar9x option off on 'PRO
Add one second watchdog disable at start up
Improve SD card disable in bootloader
Further MULTI improvements
Fix bugs in DSM-9XR support for 9Xtreme
GVARs for RGB backlight on 9Xtreme
Start to MAVLINK support
Add Q242 sub-protocol on MULTI
Attempt RTC calibration on Taranis

Mike.

Well i have to recognize that they are not major bugs, but im not the best user to talk about that. My models are simple and use just few of the vast options the the software offers.

[jhsa]

Of course there aren't any major bugs nor any stability problems with ersky9x.. Now, can we all drop it please?
Just for the record, I WILL continue to make suggestions, and discuss them if Mike decides they are worth it.
I have ALWAYS had a thing about ersky9x being very user friendly because of the difficulties I did find, and still find sometimes when using it. So, most of my suggestions and ideas, apart from new features, are based on that idea.
It is up to Mike whether to implement them or not..
I do believe that since a couple years ago ersky9x and er9x gave a HUGE JUMP towards being much easier to use. menus are much more clearer now, even if I believe they can get even better.
Features that are an absolute dream. Excellent hardware support.

And it's free

João

[OctavioS]

I think a wizard would the cherry on top of the cake...or not. But would make things easier for the novice.

[jhsa]

It could be helpful yes. There is one in eepskye so people could use that one. A wizard on the radio it would be also nice as it is another tool. But if you use it always you won't learn to use your radio.

That uses LUA right? I think Mike decided not to support it some time ago.. The 9extreme and the taranis can handle it, but the other platforms might not be able to..

João

[kaos]

Mike:
Don't get me wrong. All I am trying to say is looking at this 85 pages thread. A bunch of things items are not needed for a powerful FW like ersky9x, too many small changes are really not necessary and all coming from one person's input. But all those wasted a bunch of your time and energy for better things to happen. Those little pity thing does not affecting anything or any flyer, just made the whole FW changing faces all the time.
Just look at how many variables we can choose for each item input, yes it is flexible, but it is just scare people away. I am not sure Asseembly has so many syntax as a whole. One day there are x number of things, next day there is another thing. How much are being used for real flying purpose.
You have such good knowledge, talent and willingness to work on this wonderful FW, I just can't understand why we can't put this to every one's hand just because these little things is bogging down the true nature of this FW. If one new user has a problem using eepskye which is the front end of the FW, everything break loose for new user. It is the question of 'Can I trust my 2000.00 build on something with potential bugs since this is not working completely?"
The most important things and the true power and ability of er9x has like DSM2, PXX, SBuS, Mavlink, simulation..............
those little pity thing like how many sec I can play the warning, I want it vibrate then stop vibrating, counting up or counting down timers....... are not a concern to sincere rc modeler. May be they are fun to play with. Where or whatever is in the menu of Tx is not that significant as long as they are kept the same way. If one person wants to use a new system, they are prepared to adapt to it. But not have to find the same thing at a different place with different name after a while. Tx is a very important part of rc modeler, but there are more things to do than fiddling the tx programming all the time. People want a powerful transmitter but also they know next time after the upgrade they still get the same menu they learn to use it to program their next build with new feature and start programming and feel 'safe' everything will work. Instead of oh, I need to read the manual again after you have read previous manual 100 times to get used to how to use the Tx.
I am really interested in to know how many function/programming in ersky9x are really used to program a serious true flying model, not just for fun to toy with tx programming and toy around with toy models that crashes and no body care, just get another one. There are members in my club that has flown rc for 40 yrs, ham radio instructor. When I introduced er9x to them, they went home and read the forum, come back, tell me it is not for them. Too many changes. They would rather have one Tx they can turn on and use it like they always can instead of following the thread all the time. These are the people flying models took them hrs or hundreds of hrs to build cost hundreds or thousands of dollars. And they are not green hands, they know what they are doing.
I started using er9x since Erazz time. Knowing how good this thing can become. When Erazz has to back out and you took over, made this great FW to continue and even greater. But these little pitty thing is keeping this great FW becomes truely great. People want to use a powerful Tx, but they also don't want to read 2 hrs a day on PC to know how to use it and keep track of changes of little pity thing. They would rather spend those two hrs to build and program their models.
I switched to er9x and never looked back and then take it on like my own baby. I just feel angry these pity thing keeps this baby from being great.
I used to see really knowledgeable people around here putting up great ideas (major ideas), there still are just not as many, I wonder if they are thinking the same way as I am: what those changes are for?

[jhsa]

Well, picking up where I was about the little change I have suggested to the Model setup general menu, as my thinking was interrupted.
Users that still use numbered files for their model names could still use the same files. Numbered files are still named files, right? So, no change in there.
I just tried it again and it is not very clear what that little arrow does, which is to change between names and numbers. I remember always having a little fight with it when I wanted to set the model voice file.
Having only names and selecting them from the list whether they are numbers or names is much more straight forward in my opinion.
If there wasn't any file loaded, "NONE" could be displayed..

João

[Daedalus66]

Kaos
The answer is that the people you are worrying about simply don't read this thread (unless they stumble in here looking for help on something, which they generally get). They are almost never aware of the "little petty things" we talk about.

I do quite a bit of helping of people from rank beginners to modelers experienced with more traditional radios and the issues we discuss are always in the realm of "stable" features. Just about the only areas in which I have to point out that things have changed are: (1) the menu structure which is different (and better) than the one in the stock R204 firmware, and (2) such additional features as being able to use any switch as a mix source which weren't there in R204 (and in most cases the old ways still work).

So there are really three groups to think about
1. Those with a stock 9XR Pro on R204 (and people with a Sky board and older firmware). The existing manuals serve them pretty well.
2. People who upgrade to stable R218 or above -- when it comes -- whichever of the five hardware platforms they use. They should be well served by the new manual.
3. People who mod their transmitters and mess around with test versions and read this thread. They should be able to look after themselves (or at least pose specific questions).

In my view, Mike has managed very successfully to tread the line between maintaining stability and backward compatibility on the one hand and developing the firmware on the other. He's also pretty good at fending off "petty" requests.

That's not where the problem lies. What's needed is better documentation in written and other forms. I'm working on the manual with Joao's help. I would really like to see someone do a video series on using the new ErSky9x (don't look at me!) to complement the manual. I like written material myself but lots prefer video.

Sent from my iPad using Tapatalk

[Satome]

Has there been some kind of update on how the speaker is handled? After updating to R218 from something ancient (cannot remember the version number) and clearing eeprom, the 9XR Pro speaker is making constant low level static (changing volume to 0 helps a bit, but it is still audible), seems like the speaker is "on" all the time.
Other quirk seems to be that the minute beeps are not working?. They are set on from the radio menu and model menu. Haptic seems to be working tho.

[jhsa]

Has there been some kind of update on how the speaker is handled? After updating to R218 from something ancient (cannot remember the version number) and clearing eeprom, the 9XR Pro speaker is making constant low level static (changing volume to 0 helps a bit, but it is still audible), seems like the speaker is "on" all the time.

Please hold the left horizontal trim to the left while turning the radio ON, and for only a second or so.. This will enable the hardware menu.

Now go to Radio Setup/Hardware, and check that the option "Software Vol." is set to OFF.

João

[MikeB]

I've been sorting ersky9x for the X9E. There were a few problems due to changing which switches and pots mapped where, and I hadn't sorted the bootloader, but these are now fixed.
I have posted a test version on the usual test versions page. OK, back to MavLink now.

Mike.

[Satome]

Please hold the left horizontal trim to the left while turning the radio ON, and for only a second or so.. This will enable the hardware menu.

Now go to Radio Setup/Hardware, and check that the option "Software Vol." is set to OFF.

João

Checked that, it was turned off. Tried to turn it on and off again, no effect.
I'm going to check the output with a scope tomorrow to see if it is driven low at all.

[jhsa]

Are you sure you updated with the correct version for the 9XR-PRO?
There is a file called "ersky9x_rom" and another called "ersky9xr_rom". It is very easy to get confused.. I did a couple times..

I would download the firmware again and flash it,making sure it is the correct file..

João

[Satome]

Thanks for the help João, but that was the first thing I tried, no change .

[jhsa]

Today I came across an Interesting behavior:

CH05 100% FULL Switch ()PB1)
R 100% sTHR

THR switch can be ON or OFF, the first mix has no effect at all


CH05 100% FULL Switch ()PB1)
R 100% FULL switch (THR)

First mix works, and the second overrides it when the switch is ON

CH05 100% sTHR
R 100% FULL Switch ()PB1)

This also works similar to the example above.

Question, why doesn't the first example work the same as the other two?
Is it because the switch is used as source and therefore the mix is always ON replacing the other all the time? That would explain why the other does nothing..
If this is true, then a mix with a switch as source should always be the first in the channel?

Thanks

João

[MikeB]

Yes, with the switch as source it is always ON, so as a Replace mix it cancels the first mix.
There is nothing to stop you using a switch as the source and the same, or another switch, as the controlling switch!

Mike.

[jhsa]

True..
I was just playing with the sim, and needed to control CH5 with a momentary switch on one model, and with a 2 way switch on another model. The I just found this situation and decided to describe it here so others don't think it is a bug At least now it is explained why it works as it does.. And it makes sense

Thanks

João

[jhsa]

Mike, a couple little problems, protocol menu, PPM2, ersky9x on Ar9x with latest test version.
1 - PPM1 protocol set to PPM, PPM2 is OFF:
Whenever I change the state (OFF/ON) of the PPM1 module, PPM2 module will turn ON, and stay ON even if turned OFF.
After rebooting the TX or turning PPM2 ON and OFF again, the module turns OFF as it should and resumes correct operation.

2 - PPM1 set to PPM, PPM2 set to OFF:
When turning the radio ON, PPM2 Turns ON for a couple seconds (the time set on the Attiny's code) when the splash screen goes away, and then and turns OFF again as set in protocol.. That means the radio is sending at least one pulse at power up, right after the splash screen. Turning the splash screen OFF fixes this problem, but not the one in point 1..
But, if PPM1 is set to something else, PPM2 stays OFF at power up as it should, whether splash screen is ON or not. This is correct I guess.
Only with PPM1 set as PPM this happens..

Thank you

João

[MikeB]

I'll investigate and see what I can find. I can see a single, 1mS or so, pulse after the splash screen on PPM2.

Mike.

[jhsa]

Yes, that is one of the problems.. But that pulse is there only if:

1 - the splash screen is enabled
2- PPM1 is set to PPM. If set to something different, there is no pulse on PPM2

Thank you Mike

João

[MikeB]

Actually the pulse is there, but is very early after power up if the splash screen is disabled.
Could all be fixed in the specific test version I've just posted.

Mike.

[jhsa]

Thank you Mike.. I will test a bit later and let you know..

João

[jhsa]

Mike, it seems to be working now.. Only the first time I turned the radio ON after flashing the test version, and with both modules set to OFF, The internal module (PPM2) turned also ON. But after turning it OFF and ON again it is working as it should..
Thank you

João

[jhsa]

Mike, just been testing the new "Slave" option in the trainer menu on my Ar9x radio. It works great.. I can just turn the modules OFF on my simulator model and leave the radio ON.
There is only one little thing. I have to go to the trainer menu and change the source whenever I need to fly the sim.
It would be very useful to be able to select the source per profile.

I know a user that converted other radio to the Ar9x board and he is not using the Trainer Power connection. The slave will give him the ability to still send PPM while the radio is powered by the main switch, and that is great.

A very wild idea that just crossed my mind would be setting the trainer setup on a per model basis. I guess this would mean a complete rewrite of the trainer section?

A good alternative to this would be being able to set the trainer source on each trainer profile, and then add an option on every model to select a certain profile (0 to 3). So you could have different trainer profiles programmed, One using BT, other as slave sending PPM to a sim, Other receiving trainer signal on the jack plug), and select on the model which one to use for that particular model..
I think this would be a great feature and make the trainer even more flexible..

João

[Daedalus66]

Thanks. That helps to clarify this feature -- I was just trying to figure out what to say about it in the guide.

I can see the argument for putting the Source setting in the Model Setup menu. Suppose I have two models for use with my Phoenix sim, one for typical models and the other for some special setup -- say tilt wing. Then I have a BT link with a transmitter that I use as the buddy box for training. Finally, I have a DSM receiver that feeds the trainer jack so I can use a little DX4e as the buddy box for kids to fly several models. I could simply chose the appropriate model and have the source set correspondingly. So there would be an item under Model Setup - General called "Trainer/Simulator"?

As things are now I would have to take two steps -- chose the model, then go into the Trainer menu and choose Source. Then when I go to a different model I might have to go into Trainer again.

On the other hand, it seems a bit drastic if we had to set up the whole trainer menu each time for every model that's involved.

By the way, this whole trainer/sim issue is fairly confusing to people and requires not just a brief explanation of what various menu items mean, but a real step by step how-to do it. Accordingly, I have simplified the menu explanation Trainer section and created a separate annex on Trainer and Simulator Setup.

[jhsa]

I can see the argument for putting the Source setting in the Model Setup menu. Suppose I have two models for use with my Phoenix sim, one for typical models and the other for some special setup -- say tilt wing. Then I have a BT link with a transmitter that I use as the buddy box for training. Finally, I have a DSM receiver that feeds the trainer jack so I can use a little DX4e as the buddy box for kids to fly several models. I could simply chose the appropriate model and have the source set correspondingly. So there would be an item under Model Setup - General called "Trainer/Simulator"?

As things are now I would have to take two steps -- chose the model, then go into the Trainer menu and choose Source. Then when I go to a different model I might have to go into Trainer again.

On the other hand, it seems a bit drastic if we had to set up the whole trainer menu each time for every model that's involved.

No, you wouldn't have to. It would be very easy and flexible. I explain why. You already have 4 profiles. If you could set them with different sources and configurations, you wouldn't set it up for each model, I mean, you wouldn't have to go to the trainer menu every the time you need a different setup..
How? You would program for example 4 different profiles with different sources, and then just select the trainer profile number you want to use with that particular model in the Model setup menu. Maybe in "General" (for now) where you already set if trainer is ON or OFF for that model..


João

[jhsa]

Mike, sometimes when changing from one model to the other, I still see that little pulse on PPM2. Well, I don't see it but the internal module turns ON.. The thing is this time I still didn't find out why it does.. It looks quite random, but I'm sure there is some logic behind it..

Thanks

João