openTx-r2152

[bertrand35]

Release r2152 is the first openTx release. It's only a maintenance release compared to last open9x release. Don't expect any new features, just bug fixes!

Here is the changelog:

[stock]
- Around 450bytes flash saving (just reordering the Makefile!)

[ATmel 128]
- Bug on the 6th flight phase (Mixes and Expos)

[gruvin9x]
- Bug on the 6th flight phase (Mixes and Expos)

[sky9x]
- Bug in Custom Switches fixed

[FrSky Taranis]
- Very first release!

---

Previous announcement: open9x-r2129

Bertrand.

[Rob Thomson]

Great stuff.

Silly question. How do I enable the extra 3pos?

Should there be a companion option for this? Or is it a custom compile?

Rob

[Helle]

Hy,

nice work now
normaly I work under windows
but th9x stock in DE for Simu under ubuntu12.10

1.
how can I simulate taranis under ubuntu 12.10
what does I need again
my th9x stock simu under ubuntu 12.10 is running

companion9x under win and ubuntu is running but I want to simu taranis in DE

2. how can I help to translate language in DE for Taranis
think it must be separate languages files for taranis because of more space for char


Helle

[Rob Thomson]

Setup a new firmware profile in preferences.

Select it.

Simulate it.

Sent from my GT-I9300 using Tapatalk 2

[Kilrah]

Silly question. How do I enable the extra 3pos?

It's not finished yet!

[Rob Thomson]

Aha!



Sent from my GT-I9300 using Tapatalk 2

[Kilrah]

how can I simulate taranis under ubuntu 12.10

Same as the other boards, but with PCB=TARANIS in the make command line.

E.g.

Code: Select all

make simu PCB=TARANIS REV=REV4 HELI=YES GVARS=YES AUTOSWITCH=YES PPM_LIMITS_SYMETRICAL=YES PPM_CENTER_ADJUSTABLE=YES TRANSLATIONS=DE TEMPLATES=YES

how can I help to translate language in DE for Taranis
think it must be separate languages files for taranis because of more space for char

Same language file, but use the TR() macro to differentiate strings where applicable (see en.h and fr.h where it's already been done)

[Flaps 30]

Big problems with this release. This is with the stock board fiited with the M128

(1) In combination with Companion Version 1.20 it erases all the models in Eeprom.

(2) All main controls frozen on old models after reloading them from a computer file. Models work okay with Companion and you can make new models on the transmitter without this issue.

(3) As mentioned before. In combination with Companion. The play value locations like A1 and Alt (no doubt all others) do not tie up in the TX and companion.

I cannot go back to the old 2129 as it doesn't seem to be compatible with Companion 1.20 as it wipes the Eeprom and will not allow you to load in the model Eeprom file from the computer into the TX. You just end up with a model file display showing you Model 01.

[nsf]

Had the same problem. Reinstall the firmware three times and everything seems to be working fine now.

[Kilrah]

Hmm, more details needed there.
Can you post your options list, and the files you're having problems with?

I tested yesterday with my m128 radio beofore the release, no problem.

And I just tested again to confirm, with c9x v1.20:
- Go through the upgrade process from a radio with a 212 version eeprom (r1947) to r2152
- Go through the upgrade process from a radio with a 213 version eeprom (r2129) to r2152
- Create a new document, open a couple of random old eeproms, drag models from them into the new document, copy the general settings from one, write eeprom to TX.

No problem, every model is correct in all 3 cases.

[0n370uch]

Hello Betrand,

The version r2129 is great. Jeti works perfectly again. With Firmware r2152 there is an error in the Makefile. When I select Jeti I can not perform a download.

Best regards from Germany...
Fabi

[Flaps 30]

That's interesting Kilrah.

My options are: M128 stock board. Frsky, Templates, Audio, Voice, Haptic, Dblkeys,Pgbar,Imperial

Simple file attached that shows the problem with frozen sticks. This problem applies to all of my models that are on file.

[Kilrah]

Did you create this out of a fresh document on C9x, or on the radio? What settings did you enter (trying to understand what has been entered by you, and what's caused by the problem)?

I see an offset of -245% on all mixers, so of course the sticks won't respond.

[Flaps 30]

In Companion 1.20 I created a new document. Then the Simulate model was transferred into it from the old document that holds all of my models that are in current use. After that the new document was written to the TX.

Umm.. What do you mean by settings?

As for the offset... Where are you seeing that? Is it visible on Companion? ... It wasn't me that put the offset in.

Edit - Yes I see the offset you are talking about when looking at the mix in Companion. On the transmitter it is showing an offset of zero on the mixes.

[0n370uch]

I have found the JETI compilation error. In "open9x.h" on line 1135. There is a label named "jeti.h" but it should read "telemetry_jeti.h".

[Kilrah]

In Companion 1.20 I created a new document. Then the Simulate model was transferred into it from the old document that holds all of my models that are in current use. After that the new document was written to the TX.

OK. But now was the simulate.eepe file saved just after transferring from the old document, or after writing and re-reading from the radio?

Well. Let me explain how C9X works, it will be easier to make you understand what I need.

For each eeprom version and variant C9X has both an Import and an Export function.
If you open an old document (say eeprom version 211), C9X uses the Import function for version 211. If you now look at this document within C9x and the data is correct, then Import for 211 is fine. If it's not, then that function is buggy. But this needs to be looked at in C9X, because if you save the eepe file to post it to us here then the data will have also gone through the Export function for the current version, 214 here with v1.20. So from the eePe you posted, we can't know directly which of the 2 functions is buggy.
Now, if you've opened the old file, copied to a new document, written that to the radio and read back, then the data will have gone through 211 Import, 214 Export, then 214 Import, so 3 functions. Then if you save that it goes through 214 Export again, so 4 functions. And to make things worse if the 214 Export function happens to be buggy the data might have been corrupted twice.

You now probably understand why it quickly can become a nightmare if we don't know the exact actions a file that's posted for us to look at has gone through.

And as I said there are different functions not only for each eeprom version but also for each variant, which depends on the options. So depending on the options set in preferences, the export function used isn't the same.

So that's why when a problem is reported it's important that we have:

• The original file you opened (that would be the old file you copied the model from) so that we can look at it in C9X itself after only the initial import (= only one function used)
• The C9X version (to know to which eeprom version it will save/write by default)
• The firmware and options selected in the preferences dialog (so that we know which variant it is, and which Export function is causing trouble if that's what the problem is).

[Flaps 30]

Fehh... My head is being done in by all of this.

Yes I can just about understand what you are going on about Kilrah. To me much of it shows how weak the whole system is at present if people have to jump through a whole set of hoops in a certain order just to get a working updated system. Not doing so has the potential to leave people with at best model files that need tweaking in the transmitter to get them to work correctly, and to add more pain to it all to have to go through the process of having to remember what is broken in Companion or what Companion will modify such that writing files back to the TX that will need to be changed at that stage. Isn't all of this showing the dangers of unjoined up thinking that is leading to what I see as fundemental fatal errors/faults that leads to a system that ends up having to be dumped, or requiring a major change in the way that things are developed.? Maybe you could do with someone like myself you isn't too close to the project to test things out, who will do things that might break the system, and in doing so show where work is needed before getting into a mess that requires you to tell users a whole bunch of procedures they must go through to get things to work. Rant over.

I will go away and get the original files and mess around with that and the rest of this stuff. Hopefully I will end up with something that will be workable.

Sorry guys.. This should have been an easy one to resolve.. I should have stopped at the last version of Companion and OpenTX at least that had problems I could just about cope with.

[Rob Thomson]

Lol...

All Kilrah is saying is that if you report a problem - he needs to know specifics to help him narrow down what the problem is.

So..

The original file you opened (that would be the old file you copied the model from) so that we can look at it in C9X itself after only the initial import (= only one function used)
The C9X version (to know to which eeprom version it will save/write by default)
The firmware and options selected in the preferences dialog (so that we know which variant it is, and which Export function is causing trouble if that's what the problem is).

Without this is is very difficult to debug the problem.

Now.... as for helping test? I am sure they would love your help

[Kilrah]

if people have to jump through a whole set of hoops in a certain order just to get a working updated system.

They don't! Open, save, flash,... should work in all directions without any special considerations, everything is made to take care of all the required conversions and operations in the background transparently.

But IF there is a bug, THEN to solve it WE need those details I clearly listed at the end.

As I had trouble getting info that would help us fis the problem, I hoped explaining the reasons why we needed those infos would help you understand why we ask you for them - it obviously didn't work.

[Flaps 30]

Yeah I do understand Rob.. We are allowed a rant.. My rant came out of frustration and the fact that it was so simple for me to make the whole thing fall over. If I can do that without doing any silly or complex things. Then you can bet that anyone else can do it and end up in the same boat as me. So the whole thing as it stands should have been held back from release until all the normal types of operations concerning the interactions between Companion, OpenTX and the transfers of files have been thoroughly tested and debugged.

Attached is an original file built some while back. It hasn't been altered by this version of Companion. Pick any model you like. You should find that the mixes have the -245 offset (as added by this version of Companion. Yet it works in simulation.. When it is transferred directly to the TX without forming another document and doing model transfers the sticks are stuck, and no offsets are shown in the mixers. Making a new blank document, then copying over the models gives the same result.

I think I have given all the information you required Kilrah.. Is there anything else you need?

Original file from the 5th of March that hasn't been altered is attached.

[Kilrah]

OK thanks!

So the whole thing as it stands should have been held back from release until all the normal types of operations concerning the interactions between Companion, OpenTX and the transfers of files have been thoroughly tested and debugged.

The problem is that there are only a couple of people doing testing, all on their free time. There are 6 different supported boards including some that just one will have and some that none of the testers have, some with 3 eeprom variants, and testing should at least cover the 3 last eeprom versions - we're hitting hundreds if not thousands of combinations already.
While we try to test the main combinations, there are always some that will only be picked up when a larger pool of users get to it.

We had been talking about a "beta" release channel at some point, might probably be worth considering that again. Until then, you have 2 choices:
- Make a backup when you upgrade, report any problems, restore the backup if it screwed up
- Wait a week or 2 before you upgrade, and hopefully someone else will have caught the issue you would have had. Still do a backup though

But as you can see, here we only got 3 reports of errors out of 500 downloads of c9x 1-18-1.20...

[Rob Thomson]

If any help....

My time is slowly freeing up again. I should be able to dig in a bit more within the next few weeks.



But agreed. More testers are needed!

Sent from my GT-I9300 using Tapatalk 2

[jhsa]

Companion seems not to be compiling the rotary encoder even if I select it.. After flashing the fw the encoder doesn't work.

[Flaps 30]

Yes the idea of a Beta release could be of value.

I think I have worked out how that offset came about that gave the 'stuck sticks' on the TX.. It's that nasty GVARS stuff that I played with at some point in the past. I loaded up the firmware with the GVARS option ticked and the files were saved when that option was active. This time as I had no need for or want to be bothered with GVARS I unticked the box before downloading the new firmware. So where the offset on Companion with GVARS installed said GV1 it now said -245.. Why it had zero on the TX I don't know..

Downloading the firmware with GVARS ticked has corrected the situation. Bit sad that I now seem to be stuck with GVARS though. If I get time I will take out all of the offsets and then all will be well with going back to a GVAR free zone.

(3) As mentioned before. In combination with Companion. The play value locations like A1 and Alt (no doubt all others) do not tie up in the TX and companion.

Looks like this has been resolved. Running version 2154 now.

[jhsa]

But you have the m128.. You can have them but not use them.. Who knows if in future we all don't get visited by some aliens that will do some brain surgery on us and we start understanding and using the GVARS?

I did use them some weeks ago but needed to invoke some spirits using the round table and cup method so they could point me in the right direction..

[Rob Thomson]

Agreed!

They are very useful links once you get your head round them

Sent from my GT-I9300 using Tapatalk 2

[jhsa]

Companion seems not to be compiling the rotary encoder even if I select it.. After flashing the fw the encoder doesn't work.

Before it gets lost in the middle of this conversation

[tedbmoss]

What happened to r2154? I downloaded it and companion9x 1.20 which gave me some errors because of asking for global vars. I got it working in the tx but not in the simulator, which still has offset error.
Maybe two wrongs make a right since I loaded it several times.
There appears to be an extra byte on the eeprom files in companion9x.

[Flaps 30]

Ooooo... It's them naughty GVARS again. I will give them such a slap one day.

What happened to r2154? I downloaded it and companion9x 1.20 which gave me some errors because of asking for global vars. I got it working in the tx but not in the simulator, which still has offset error..

Is that something like what I had mentioned in my last post? What is the offset value?

[Helle]

Hy,

Testing r2133M with 9XD Taranis

Setup Menü Konfiguration
Internal RX Modul seams ok
.
.
.
Menü for
External RX Modul missing:
Modul Power Off/On and Signal Off/On togehter !!
Modul Type or
Protokoll OFF, PXX, PPM, DSM, open Seriell
PPM Chanel Protokoll 8ch 22,5ms 300us +

What will you do?

Translation for good de.h with TR(....) at work
must also work with STD as before

Helle