er9x development

er9x is the best known firmware. It has a superb range of features and is well supported by the community. Well worth trying out.
User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Fri Jan 13, 2012 8:10 pm

Sorry guys,

I totally missed this thread. (don't know how).

I just added Bertrand's suggestions to eePe. Should be in the next update.
I'm also finishing the .Deb packages so Linux guys won't have to compile. (Mac is also in the works but further up the road).

I think my next project will be trying to get the PXX (Frsky) protocol up and running. Right now it's a very heavy protocol but I know Mike had some ideas.
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!


User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: er9x development

Post by Rob Thomson » Fri Jan 13, 2012 8:24 pm

Looking forward to it PXX!

Now.. here is a thought. Mike is doing some magic with PPM16.

Now I imagine this may be possible to do PXX16 if we use the ersky9x board? I doubt it is possible on the stock board?
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Fri Jan 13, 2012 10:22 pm

What's PPM16?
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

User avatar
cre8tiveleo
Posts: 1434
Joined: Tue Dec 27, 2011 6:13 pm
Country: -
Location: Ontario,(GTA North)
Contact:

Re: er9x development

Post by cre8tiveleo » Fri Jan 13, 2012 10:30 pm

ppm16 is a 16 channel thingy for er9x stuff... using the two ppm signals.. first 8 on ppm1 second 8 on ppm2.. add em up.. pp16..

that's what I understand it to be... or it could be a secret code word to take over the world.

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Fri Jan 13, 2012 10:32 pm

Oh, I geddit.

The PXX protocol goes way beyond that. You can tell each rx to what channels to listen. That way you could have up to 256 different receivers.... Why you'd want that many is beyond me but you can!

Anyway, it's like modelmatch and expandable channels all in one. Super super smart. Also, you'd be able to set failsafe from the tx.
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!


User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

er9x development

Post by Rob Thomson » Fri Jan 13, 2012 11:19 pm

Now where talking!

Time to get coding :)


Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: er9x development

Post by Rob Thomson » Wed Jan 18, 2012 8:26 pm

Right Mike,

This one is for you..

You know you have added in the protocol - PPM16.

What is the chance of you putting in another slight variation. This would require a yes/no type option.

Call the option: PPM OUT : PRIMARY/SECONDARY/BOTH

What this does is to push all PPM output that would normally go to the module - out the trainer port, or out the regular module.

This would provide a rather neat way of allowing two modules to be installed at the same time - with the model setting allowing the choice of which one is used.

Needless to say this would also need to switch the DSM2 across. Maybe the PPM OUT name needs to be better worked out!

The end result is that it is an "easy solution" to run two modules at the same time.

I was looking at doing a switch for this off PIN 35, however I think this output option may be a more versatile solution.

Let me know your thoughts

Rob
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

User avatar
MikeB
9x Developer
Posts: 16559
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Wed Jan 18, 2012 10:40 pm

This could be quite tricky. For DSM and PXX, the interrput routines thet drive the signals have to be kept very small and fast. As a result, they need to be tied to a specific output pin, I don't think they will really be fast enough if we have an option of which output they drive. So PXX and DSM both need to be kept on the main output to the normal tx module. They could be turned off however, simply be not enabling the interrupt in the first place.
I am planning to try to allow an option where the standard PPM output is sent to the trainer jack. I planned this to allow for SIM use, so the PPM to the SIM did not go to the standard module. This would solve the problem of an unpowered module loading the PPM signal and causing the SIM to fail. It would also allow the PPM output to the trainer jack when the 9x is used as a buddy box, as the trainee, again the standard module would receive no PPM signal, and would not load outgoing PPM signal.
I thought I would add another protocol, say PPMT (for trainer jack). If this is selected, then the normal PPM output would be off, and the second PPM signal (upper 8 channels for PPM16 on trainer jack) would be enabled, sending channels 1 to 8 (or whatever you select ibn the numch field) to the trainer jack. This would automatically be selected if use as a trainee is detected.
I reckon this is all possible, needs some time to sort it out though.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: er9x development

Post by Rob Thomson » Thu Jan 19, 2012 6:44 am

Ok... that all makes sense.

Does not help with my DSM thoughts. Maybe the route for that will still need to be a switch-able option on pin 35

Rob
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

paul_rautenbach
Posts: 1
Joined: Thu Jan 19, 2012 9:23 pm
Country: -

Re: er9x development

Post by paul_rautenbach » Thu Jan 19, 2012 10:18 pm

MikeB wrote:This could be quite tricky. For DSM and PXX, the interrput routines thet drive the signals have to be kept very small and fast. As a result, they need to be tied to a specific output pin, I don't think they will really be fast enough if we have an option of which output they drive. So PXX and DSM both need to be kept on the main output to the normal tx module...
Mike.
Hello, this is my first post and I'm not sure I have followed this correctly. If not sorry for interrupting.

If I understand right, Rob is wanting an option to select which output (ie, pin) to send the PPM out on - the normal module or the trainer port - and for this to be selected automatically when the model is selected. The problem is there is not time in the interrupt routine to check the option and choose the required pin.

Would it be possible to have more than one copy of the interrupt routine - one hard-coded to use the normal module output pin and another hard-coded to use the trainer output pin. The choice of model would then change the interrupt routine to jump to when an interrupt occurs by altering the interrupt vector. In this way the time to execute the interrupt routine would not increase but the pin to output PPM to could be chosen per model.

Have I understood the problem correctly? Sorry if I have not.

Paul
PS This is very interesting work.

User avatar
MikeB
9x Developer
Posts: 16559
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Fri Jan 20, 2012 9:41 am

Good idea, unfortunately the vectors are in the flash, and therefore it is not possible to change which address they go to. I've achieved this (sort of) by using different timers and compare registers to provide different interrupts. The problem comes down to there are not enough if them to handle 2 pins and three different protocols. PPM we can do on either pin, but DSM and PXX have to be on the main pin. (DSM and PXX interrupt at 8uS intervals worst case).
By adding another protocol for PPM on the 'other' pin, this will be selectable on a per model basis.

You have pretty well understood the general problem. All ideas are always welcome, sometimes thay work, sometimes they don't, sometimes they trigger thoughts to solve a problem another way.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

Re: er9x development

Post by bertrand35 » Thu Feb 02, 2012 4:53 pm

Hi Erazz,
Would it be possible you modify the er9x Makefile to have "er9x-r670" in SVN_VERS instead of "trunk-r670". The purpose is not to save one byte of flash, but to allow companion9x to do automatic EEPROM backup/restore (with appropriate conversions) during a firmware flash operation.
It will then be possible for everybodybody to switch from any firmware to another without loosing anything and even to return to a previous version of a firmware without an Bad EEPROM message!
Thanks,
Bertrand.

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Thu Feb 02, 2012 7:42 pm

I think that's a good idea. I'll implement it.
aaaand done. Or will be done on the next compile tonight.
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Thu Feb 02, 2012 7:50 pm

Oh yeah, how do you do the conversions between versions and between platforms?
Sounds like really complex procedures. Ugh.... :)
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

sterby
Posts: 4
Joined: Sun Jan 29, 2012 9:07 am
Country: -

Re: er9x development

Post by sterby » Thu Feb 02, 2012 11:08 pm

I'd like to indtroduce a suggestion. How about making a fork of the FrSky mod for fixed wing users only? That way there's no need for the heli mixes and ditching the templates would give plenty of space to implement more complex telemetry options, like different tones for lift and sink etc...

User avatar
MikeB
9x Developer
Posts: 16559
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Thu Feb 02, 2012 11:18 pm

That's what ER9X-FRSKY-NOHT.HEX is - no heli and no templates.
I think Erazz has in fact ditched the templates from the standard FRSKY build to save space.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
jhsa
Posts: 18915
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: er9x development

Post by jhsa » Thu Feb 02, 2012 11:26 pm

Mike, sometime ago and if I'm not mistaken you said That you had a PCM audio module that you would try? did you manage to do it?
If I misunderstood it, I do apologise..

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

User avatar
cre8tiveleo
Posts: 1434
Joined: Tue Dec 27, 2011 6:13 pm
Country: -
Location: Ontario,(GTA North)
Contact:

er9x development

Post by cre8tiveleo » Thu Feb 02, 2012 11:29 pm

Ditch the templates all together, even in the er9x standard version. :)

User avatar
MikeB
9x Developer
Posts: 16559
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Thu Feb 02, 2012 11:41 pm

jhsa wrote:Mike, sometime ago and if I'm not mistaken you said That you had a PCM audio module that you would try? did you manage to do it?
João
I do have such a module, but it needs a SD card and I don't have a suitable one (yet). I may be getting one shortly however. I did get a microSD card, but it doesn't have an adapter to allow it to fit the PCM module, and I also understand the microSD card might not work in an adapter in the module anyway.

I haven't forgotten about this, but it needs some time, and I now have 'real' customers needing work done as well.

I was wondering whether, rather than do a major mod to the board, we could use the serial i/f that goes to the FrSky module. Since FrSky needs to see a special byte to start a frame, we could define a different protocol that avoids that byte, then the FrSky module will ignore other things we send. We would probably need to add another small processor to interpret this protocol, and send the correct data to the PCM module, but this might also allow different PCM modules to be used, with a common output from er9x. The extra small processor could handle the different PCM modules.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Thu Feb 02, 2012 11:56 pm

I'd like to ditch the templates but it seems that some are still using it!

Also, since the FrSky version is the biggest it had to loose weight. The others can definitely have the templates in place without any penalty.


The heli mixes do not take any room or cpu power if you don't turn them on.
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

User avatar
MikeB
9x Developer
Posts: 16559
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Fri Feb 03, 2012 12:07 am

I do have the code on another diet! I've just done a svn update, and with my changes in and with templates the FrSky version is 63274 bytyes of flash. I'll be interested to see the size of the next build when you do it.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

memeruiz
Posts: 6
Joined: Fri Feb 03, 2012 12:01 am
Country: -

Re: er9x development

Post by memeruiz » Fri Feb 03, 2012 12:25 am

Hi Guys!

Here is my first contribution to the project. A patch for the new frsky sensor FLVS-01 and some other things.
I'm new in the multicopter community, and I bought a turnigy 9x, made frsky, backlight, programming port mods and installed er9x. Awesome!! Thanks. I bought a multiwiicopter scarab Y6 and works awesome with the turnigy 9x and er9x.

The details of my patch are here:
Because for me the most important thing are the battery cell voltages, I bought a FLVS-01 from frsky. Unfortunately er9x doesn't show this information. Therefore I decided to take some time to make it work and here it is. I just made a patch giving support to display the individual cells of lipos. Also I added the status display for the accelerometer sensor. In the second telemetry setup screen I added two new items to configure an alarm in case the voltage of any cell drops below some threshold voltage. The frsky hub must be upgraded to firmware version2 in order to support the voltage sensor.

http://code.google.com/p/er9x/issues/detail?id=353

Also I sent another patch for a little thing with the Makefile:

http://code.google.com/p/er9x/issues/detail?id=358

This applies against r698 (today).
Let me know if I need to modify anything to get it applied in the trunk.

All the best,
Federico.

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Fri Feb 03, 2012 1:17 am

Code compiled and up. It did seem smaller to me. How do you do it?
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Fri Feb 03, 2012 1:20 am

Hi Fredrico,

Could you post your patched files insted of the patch itself? I know it's not standard practise but it makes it a whole lot easier to see what you have done and evaluate it.
Also, please note that changing the structures in myeeprom.h is not something we do lightly. These have big reprecussions. The way it's done now would break the structure. It's not a big deal, we can fix that.

Oh yeah, since we still don't know you, a detailed description of the changes will help us a lot!

Mike, you want to take a look as well? You have more experience in FrSky stuff anyway.
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

er9x development

Post by Rob Thomson » Fri Feb 03, 2012 3:04 am

erazz wrote:Code compiled and up. It did seem smaller to me. How do you do it?
Any chance that was the new audio mods? They have saved a fair bit!


Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Fri Feb 03, 2012 3:29 am

I don't know. Between you and Mike I am having a hard time just reading the new code, let alone deciphering it :)

(just kidding, I actually do read through and look for bugs before compiling)
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

User avatar
MikeB
9x Developer
Posts: 16559
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Fri Feb 03, 2012 11:23 am

Here is my first contribution to the project. A patch for the new frsky sensor FLVS-01 and some other things.
Federico.
Thanks for that, I'm looking through it. All contribution are welcome. I started by suggesting a couple of changes to save some flash, and now do a lot of changes and enhancements.

As Erazz says, if we change myeeprom.h, it can upset ALL existing models stored by ALL users, so we have to be very careful to maintain compatibility.
Also, we have space limitations, both on the flash and the RAM. You have added at least 34 words of RAM (68 bytes). This needs to be carefully monitored as the total RAM used by the stack is not fully defined and we don't want to have the stack run into the allocated RAM!
I think, rather than have a separate bit and option for an alarm, we might as well be consistent with the other FrSky alarms where if the alarm value is zero, then the alarm is disabled. This will save EEPROM and flash.
I reckon we can use a single byte to store each cell voltage 0-210 to represent 0-4.2V. This will provide a resolution of 0.02V, this should be more than accurate enough and will save RAM.
I need to do a review of the whole FrSky code and storage.
I know I keep mentioning sapce saving, but by keeping everything as small as possible, we get more functions in. We will have far more space in ersky9x for all this.
I frequently come along after others have done some changes and slim them down :mrgreen:

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

Re: er9x development

Post by bertrand35 » Fri Feb 03, 2012 11:46 am

erazz wrote:Oh yeah, how do you do the conversions between versions and between platforms?
Sounds like really complex procedures. Ugh.... :)
Hi Erazz,
Thanks for the "er9x" string inside the firmware. In the next companion9x version it should be possible to flash a new firmware and the EEPROM data will be automatically backuped / converted to the good format / restored. Should work on er9x / gruvin9x / open9x. I have to ask the same to Thomas from th9x.
I will try to find time to open a new topic about this process as soon as possible. Now it's done I am sure it's feasible ;)
Cheers,
Bertrand.

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: er9x development

Post by erazz » Fri Feb 03, 2012 12:21 pm

Thanks Bertrand. Looking forward to it.

Guys, we have to comend Mike. He does deserve it. He's absolutely right, the changes he made to save space allowed us to have much more space for new fetures. I'm constantly amazed at how I still have space to implement stuff.

Thanks Mike!
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

User avatar
MikeB
9x Developer
Posts: 16559
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: er9x development

Post by MikeB » Fri Feb 03, 2012 5:12 pm

memeruiz wrote:Here is my first contribution to the project. A patch for the new frsky sensor FLVS-01 and some other things.
Federico.
I've been looking at this, have you loaded the code and run it?
I ask because where you extract the cell number and the cell voltage from the 16 bit value, it does not pick the cell number from the top 4 bits, as specified in the FrSky protocol document. You get it from bits 4 through 7 (0 is least significant bit), not 12 through 15.
FrSky send the bytes with the low byte first, but these are assembled to give a correct 16 bit value. I don't have the cell voltage sensor, so I can't test it.

As a minor coding note (we don't have a formal coding layout), most of the time #defines are in UPPERCASE. It makes them stand out. So where you have:
#define telemetry_views 6
we would generally put
#define TELEMETRY_VIEWS 6

I personally hate the layout:
if(...) {
....
}
I always like to see the { } under each other, I find it helps following the coding flow:
if(...)
{
....
}

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!


Post Reply

Return to “er9x”