openrcforums

You are wrong. This is current state of opentx repository: And special characters are used in those files for example from cz.h.txt:

You are right, I'm wrong.
The txt file contains the special national characters that are translated to the \200 ... strings when they are in the .h file

Reinhard

openTX 2.0.3 (companion) overwrites settings made in Tx Custom Scripts menu when writing EEPROM from companion to Tx (see posting from Bob in RCgroups which I was able to verify: http://www.rcgroups.com/forums/showpost ... count=1797).

Btw. do I need to create a seperate login in case I want to create a new issue directly here: https://github.com/opentx/opentx/issues ... state=open
(my openRC login doesn't work here)

Github has nothing to do with openrcforums indeed, separate accout needed.

There's already an issue open for that problem though:
https://github.com/opentx/opentx/issues/1334

I could use some help figuring out how to use this FAS offset to fine tune the MAH.

I'm using the FAS 150amp sensor between the battery and the ESC - so it's record should closely match the amount my charger puts back into the battery.

Case and point. I had a flight today that recorded 3150 mah used. charging up the batteries (they were fresh charged before the flight) they accepted 3477 mah. Cells averaged 3.75v after flight - but I don't think that's even relevant. The flight was 9 minutes 38 seconds.

Is there some formula I can use to figure out what value to use in the FAS offset so my mah report is (more) correct?(granted there will be some slop because this is not a closed system and the battery looses energy to heat...etc.)

bertrand35 wrote:That's said, I would be really happy if it was possible to reduce the memory footprint, any idea is welcome

I found this link today...
http://www.eluaproject.net/doc/v0.8/en_arch_ltr.html
They're talking about eLua, but perhaps there is an equivalent patch for regular Lua.

Scott Page wrote:

6-21-2014 8-21-40 PM.jpg

I could use some help figuring out how to use this FAS offset to fine tune the MAH.

I'm using the FAS 150amp sensor between the battery and the ESC - so it's record should closely match the amount my charger puts back into the battery.

Case and point. I had a flight today that recorded 3150 mah used. charging up the batteries (they were fresh charged before the flight) they accepted 3477 mah. Cells averaged 3.75v after flight - but I don't think that's even relevant. The flight was 9 minutes 38 seconds.

Is there some formula I can use to figure out what value to use in the FAS offset so my mah report is (more) correct?(granted there will be some slop because this is not a closed system and the battery looses energy to heat...etc.)

Scott, you got there 10% error. I would say it is in expected range. Remember there is also the charger error that can skew your results.

Nonetheless, you should be able to improve accuracy with ofset. I don't know from the top of my head if ofset is added or substracted from the measured value. But you can figure that by experiment.

The idea behind ofset setting was introduced because some sensors report little current even when no current is passing through them. It is not a scaler.

Scott Page wrote: Case and point. I had a flight today that recorded 3150 mah used. charging up the batteries (they were fresh charged before the flight) they accepted 3477 mah. Cells averaged 3.75v after flight - but I don't think that's even relevant. The flight was 9 minutes 38 seconds.

Hi,

Bear in mind that batteries are not a tank, they are chemistry !
You can't expect exact values, even between batteries of the same spec.
Then the charge process causes losses (heat...) as in any electrical application so, as dinamich wrote, what you get is already good

Tchao

I have this problem in 2.0.3. When timer2 Countdown is set to 'beeps' and 'minute call' is set. Taranis announces the 1 min, 30 sec and 10 sec by voice, but the last 10 secs is continually repeated (10 secs) instead of 'beeping' it down. This happens whether its programmed from Companion or from Taranis itself.
Is this a minor bug?

In "Beeps" mode the files timer30.wav, timer20.wav and timer10.wav are played if present for 30 secs, 20 secs and each of the last 10 seconds respectively. If you want jsut beeps, delete those files from your sound pack.

I do not understand why this error is not fixed yet?
This audio file to be the Timer1, then why can delete this?
No logical operation.

The new voice packs do not have those files anymore by default. But if people didn't update their voice packs, they'll still have them.

Is it not possible to count the seconds down from ten with voice?? I don't really understand why it can't do that
Or am I missing something? as usual..
João

Of course, with the "Voice" setting. But the OP has it set on "Beeps", so I suppose he actually didn't want a countdown.

so, if he wants voice in the future, he will have to put the files back on the card i guess..
Can't that be fixed in software instead of people having to delete files?

João

No, voice is a choice in its own... do your homework

dinamich wrote:

Scott Page wrote:

6-21-2014 8-21-40 PM.jpg

I could use some help figuring out how to use this FAS offset to fine tune the MAH.

Is there some formula I can use to figure out what value to use in the FAS offset so my mah report is (more) correct?(granted there will be some slop because this is not a closed system and the battery looses energy to heat...etc.)

Scott, you got there 10% error. I would say it is in expected range. Remember there is also the charger error that can skew your results.

.

I agree that 10% is not a huge error. and it's difficult to say whether the difference is in the sensor OR the charger -- most likely both. One things' for sure - it's closer to actual consumption that numbers I'm getting from my Castle ICE ESC. The Castle is reporting consumption numbers approx. half of the actual . Perhaps the ESC is needing a firmware update.. I'll have to look into that.

It seems to me that I should be able to adjust the offset to bring my reported consumption into closer alignment with the charger - I guess I'll work on this experimentally. At least now I know I want to start thinking landing when I get a verbal cue that I've hit 3500mah rather than 4000mah.

Another idea that would be interesting would be to put both the 40 amp sensor and the 150 amp sensor in the same aircraft and alternate between them (using <40 amps) to see how they compare on their consumption reports as compared with the charger.

People tell me I'm OCD. Perhaps they are correct.

Kilrah wrote:No, voice is a choice in its own... do your homework

What does that have to do with homework? Normally you can choose between beeps and voice, right?
I don't understand why to have only beeps you have to remove voice files form the card.. that should not be necessary

Scott:
The 150 Amp sensor is the clamp type. An interesting test you can do is as follows.
You probably have a test meter that can read amps, but only up to around 10. Put this in the power wire to the ESC, along with the 150Amp sensor, BUT, wrap more than one turn of the wire through the 150 Amp sensor, say 5 if they will fit. Now if you run up to 10 Amps, which you can see on the test meter, the 150 Amp sensor should read 50 Amps (10 * number of turns). A useful test of it's accuracy.

Mike.

MikeB wrote:Scott:
The 150 Amp sensor is the clamp type. An interesting test you can do is as follows.
You probably have a test meter that can read amps, but only up to around 10. Put this in the power wire to the ESC, along with the 150Amp sensor, BUT, wrap more than one turn of the wire through the 150 Amp sensor, say 5 if they will fit. Now if you run up to 10 Amps, which you can see on the test meter, the 150 Amp sensor should read 50 Amps (10 * number of turns). A useful test of it's accuracy.

Mike.

Nice! You have a wealth of knowledge.

I converted to 2.03 from 1.52 and now get a strange audio warning "Mix Warning 1". I looked at the mixes, which seem OK. The model behaves exactly as I would expect. Can anyone tell me what I'm being warned about?

Another question. Prior to migrating to V2.03 I had my vario read out in metric units. It worked fine. When I set up Companion on V2.03 I chose Imperial units for a change. Now Rate-of-climb is announced in meters/second and altitude in feet. The Taranis was delivered at the end of December and the RF firmware has not been updated. The vario was updated to the latest firmware as was the receiver (X8R). Is this a known issue? Do I need to update the RF firmware?

Which radio? Do you have the latest sound pack installed?

After update my Taranis radio with OpenTX 2.0.3
Servo page shoes now -512.0 --- 512.0 instead of -100.0 ---100.0.
Anyone noticed it?

You likely selected the ppmus option, where settings are displayed in microseconds instead of %.

I have a Taranis with the latest Amber sound pack that I know of.

The Amber pack has not been updated for 2.0 yet AFAIK.

Ah Ha
ppmus means ppm micro second.
Thanks Kilrah.

That's it. As the tooltip says

Hi
A member of my Forum has upgraded to OpenTx 2.0.5
Update procedure is completed regulary
when he choose "Exit" from boot menu Display show the splah screen , after turn off and message of shitch warning are played.Display remains Off
Only with a FW 2.0.2 or lower radio works ok
What do you suggest?

EDIT:
Solved
Wrong profile of radio (Taranis Plus instead of Taranis) was selected

In this case is possible, during the upgrade process, boot loader understand if the bin file is the right firmware for current radio type?