openrcforums

Here are some files for the folks with the Emartee voice module..

English female

João

Is this the one to use with the new release that has the renumbered files?

Do you know the situation with the sound packs given here -----> http://85.18.253.250/voices/opentx-stock128/en/ and here ----> http://85.18.253.250/voices/opentx-stock/en/

Yes, there's no point of creating a voice pack with the old numbering..
About the others I don't know as I always used my own packs..

I hope the files work well for you guys..

João

Downloaded and tested them on r2252.
Seems all to work.

Only thing that I recognized, but probably is not file dependent, the breaks between two consecutive files are much longer than on ER9X. With OpenTx I have about one second between two files, while with ER9X its, maybe 1/10 of a second. (Old good Emartee module)

Reinhard

I don't remember how it was with the old emartee module.. I still have one old and one newer here.. but not in the radio anymore

ReSt wrote:Only thing that I recognized, but probably is not file dependent, the breaks between two consecutive files are much longer than on ER9X. With OpenTx I have about one second between two files, while with ER9X its, maybe 1/10 of a second. (Old good Emartee module)

I don't find that when playing files for switches. Yes there is a second or so delay when I played two values (A1 voltage and Altitude from the vario) so I wonder where you found the delays occuring?

I'm using a sequence of files with the GPS in the NMEA versions to say e.g. "Altitude" "300" "28" "meters" or
"Distance" "200" "25" "meters" (It takes about seven seconds to say this information).
This sequence is called with only two procedure calls, one for altitude or distance and the other gives the value and the units.
And the delay occurs between every two files.

Reinhard

I wrote some code, right? Did you check the sound files themselves, perhaps there is a silence at the start and at the end? The code of the VOICE mod comes from Mike on er9x. Exactly the same code!

Just a possibility, but as the voice interface uses the LCD data lines, there is a control that holds off the clocking out of a voice command if the LCD is being updated. I wonder if there is a problem, such as phasing where more often than not the clocking out routine is held off. On er9x, it tries to output a voice clock edge every 128uS, and needs to output 32 edges.
Putting a scope on the voice clock and busy signals on the interface might help locate this problem. You should see busy come on, then go off (not sure which way up it is), then the next voice file should be clocked out. It should take at least 4mS to clock this out, but it should happen quite soon after busy goes away (10mS?).

Mike.

These voice files are called from procedure menuProcNMEA2 in file telemetry_nmea.cpp (a newer verion than what is on the repository) where the GPS data screen is updated.

I checked several of the voice files and did not find excessive space around the data. So, I think the files are ok (btw. I used the files that João provided in his post above).


I will solder some wires to the busy and the clock line and have a look and check the delay from the trailing edge of busy to the next clock pulses and see what I find.


Something else that I recognized.
At first I tried to play the "Altitude" file by calling

pushCustomPrompt(V_ALTITUDE)

with V_ALTITUDE defined as 170
But instead of file 170, file 44 was played.

Did not understand why, so I found another solution by calling

pushPrompt(V_ALTITUDE)

and that did it.


Reinhard

I think that your SVN is not up to date. playCustomPromt(170) should play prompt 170 in last release!

That was the r2252 version download.

In the meantime, I have taken some pictures showing the relation of the busy signal with speaker output.
The busy signal always has about the same length, so there should be no problem.
The delay always is the busy time until the voice is played

But what I found:
I have used two different memory cards (a 1GB card and a 2GB card), one for the ER9X voices and one for the OpenTx voices.
To compare ER9X timings and OpenTx timings, I copied the full voice sets onto both cards.
And that already seems to have shortened the long delay of the Open9x.

I used each card with the ER9X voice set as well as with the OpenTx voice set.

What I clearly could see is, that on Open9x, the 2GB card was around 1 second slower than the 1GB card while on ER9X both cards were nearly as fast as the 1GB card on ER9x.

The pictures are made with 1sec/division and the upper trace shows the speaker output while the lower trace is the busy signal of the module.

Reinhard

easy fix, swap cards

But what to do with the other radio?

At some time, I will prepare a card where I rename the files of the fast card to the names of the slower card to check if there is a difference in the voice files.

Another idea, as OpenTx uses higher filenumbers for the numbers (0 - 100 - 1000 ...), could it be, that it takes (that much) more time to find/play a file with a higher filenumber ?

Reinhard

That is possible.

If it is doing a file sorted / directory listing... It may well!

Sent from my GT-I9300 using Tapatalk 2

I remember Mike doing something to reduce the time in er9x, but can't precisae what it was.. Maybe I'm confused..
Actually he increased the time for the new module I think.. but did something for the higher files to be accessed at the same time than the others.. something also with not loading all of them in the memory. But that might have been for the new module..
Geee, not enough coffee this morning..

The Sound pack was updated.. Future releases of OpenTX require some changes to the file numbering.
these files won't work with older versions of OpenTX
For the ones that want to know what changed here it is:

http://openrcforums.com/forum/viewtopic ... 863#p53863

João