(re)enable mute for TX16S based on RM feedback

[3djc]

Based on feedback received from Radiomaster customers, they would prefer to re-enable mute for TX16S.

I'll do later a user configurable version, but for 2.10

Would be nice if this one could be part of 2.9

[mha1]

I lost most of the touch audio feedback (beep on touch)

[3djc]

Previous 'reference test' was trim, trim works fine, I guess we need to fine tune for touch then.

Is that on first touch or rapidly repeating ? Video would be welcomed, I'm probably no doing the right stuff to replicate

[mha1]

Here's my Sound settings and in addition I have Volume on S2 (knob in center position). After that just touch your way around the UI, e.g. carousel. In most cases there is no touch feedback sound.

[3djc]

I guess I'm not doing the right test

IMG_1293.MOV

IMG_1294.MOV

[3djc]

Anyhow I guess the best fix is to bribe @pfeerick for an early merge of #3703

[mha1]

Is this the tonight's nightly? I'll try again

[3djc]

Yeah downloaded for gh release pages (d85218b)

[mha1]

hit the EdgeTX logo, select model settings (does it beep?), then touch the icons on the top bar one after the other

[3djc]

Cannot link the video for some reason, but works fines here

I guess your audio circuit might be a little off spec and would require slightly different mute/unmute values? But as said above, best fix is to have it optionnal, just didn't want to squeeze in a new feature for 2.9

[mha1]

as far as I understand it you changed the unmute delay for the TX16s from 120ms to 150ms. What was the problem?

[3djc]

Not at all. Mute was completely disabled as a result of first tx16s production units as no buzzing noise was found with what we had ( #undef AUDIO_MUTE_GPIO_PIN). But since, people with several watts module have noticed a buzzing noise, many reporded the issue to Radiomaster. This simply re-enable mutes at values they where before been removed

[mha1]

Another symptom: the EdgeTX startup message "welcome to EdgeTX" is truncated to "elcome to EdgeTX". The "W" is inaudible.

[mha1]

Playing with the numbers doesn't seem to make a difference. Reverting your PR brings back the full welcome message and all touch beeps. I don't think I have a "special" out of spec TX16s (not MKII). That's why I think this PR should not be in 2.9 unless your 2.10 UI change goes with it.

[3djc]

We have to understand better since nearly all radio use the feature, I will try to find if one of my tx16s behaves like yours and ask Radiomaster to conduct further tests

[mha1]

I'll continue tomorrow with a scratch built SD card, radio.yml and a minimal model.yml to exclude config side effects. If still persistent I'll upload a video demonstrating the chopped welcome message and missing touch beeps.

[3djc]

Beginning of 'welcome ' cut means you need to raise unmute delay. Try 170 maybe instead of 150

[pfeerick]

I've tried three different TX16S - a early TX16S from when non-touch was an option, and two later ones that are somewhere between the MK1 and MK2, and for all three I get the beeps on touch when sound set to all, and I don't think the welcome of hello.wav is being trimmed on mine. Sorry, I can't help with a reproducible case there! I have no issue merging #3703 once we've added the companion side support, but would still like to know what's different here.

[3djc]

Same here, tested all 3 I have, cannot reproduce, and 150ms is already quite a margin above chip specification (100ms)

[mha1]

170ms didn't change it so I cleared the SD card, just put 2.8 release sounds on it and let the radio with tonight's nightly flashed create virgin radio.yml and model01.yml files. No more truncated welcome message. I blame my home brew sounds. But touch feedback is still the same. I noticed leaving gaps between successive touches don't have beeps, fast successive touches have beeps, most likely omitting the beep for the first one, see video https://www.youtube.com/watch?v=KxXazxZTPpU

If you want to recreated the exact condition of my test scenario flash tx16s-009b638.bin.txt and put this on your SD card RADIO.zip

[3djc]

IMG_1299.MOV

Absolutely cannot reproduce (that with your sd content installed (why mode 2!!! :D)). I seem to remenber some people near launch did mod their audio because they thought sound wasn't loud enough for them, did you do any of that ?

The way mute work is dead simple. It ways no sound for AUDIO_MUTE_DELAY duration. When there has been no sound for that long, audio chip is muted. When next sound comes, it unmutes audio chip, wait AUDIO_UNMUTE_DELAY, then play the sound.

If you don't hear the 'first beep', it means despite waiting AUDIO_UNMUTE_DELAY, the audio circuit is still not ready. Keep increasing AUDIO_UNMUTE_DELAY, so that we understand what is the value for your chip

[mha1]

Nope, no HW mod whatsoever.

PS: Firefox won't show your video

[mha1]

Are you sure beeps are queued and not played instantly?

[3djc]

Thats the whole purpose

Nope, no HW mod whatsoever.

PS: Firefox won't show your video

Edge and chrome will tho

[3djc]

See for yourself...

Thats actually the whole issue around mute, and why it is such an annoyance, it introduces a lag of AUDIO_UNMUTE_DELAY ms

[mha1]

ok, we're getting there. 500ms makes all touches beep and as expected with a very noticeable latency. I'll do some builds to find the threshold.

[3djc]

Those values are used by default in nearly all otx/edgetx radio but tx16s that was no muted by default, because RM has done an amazing job at shielding audio circuit on that radio, so it is really something that those values dont work on your radio (and as I said, already include de 50% safety margin vs chip specification)

[mha1]

Result: 250ms works reliable, 240ms works but you can hear a tiny first part of the beep missing

What do we do with this? My radio sure seems not representative but it shows there are radios out there which haven't studied the specs (at least as far as the audio chip is concerned). If you want to stick with 150ms the UI options seems mandatory.

[3djc]

Such a high value has me wonder if your 5v regulator hasn't blown up and audio is powered by vbat. Anyhow, I think we want the UI choice, agreed @pfeerick ?

[mha1]

Does the 5V regulator also supply AUX1 and AUX2?

[mha1]

Answered myself, no, Audio has its own 5V regulator. From Risto's blog:

[mha1]

Where did you find the IDChip 8002A data sheet? I only found chinese versions of the datasheet.

[mha1]

Put my scope to good use and checked the audio voltage regulator. Rock steady and noise free 5V. But my radio has a 8002D chip not a 8002A as described in Risto's TX16s HW blog. Dunno if that makes the difference.

[3djc]

I have asked RM about it, but they have some kind of dragon festival or something like that, may be a couple of days before I get an answer

[mha1]

Can you take a look at one of your working radios which version of the 8002 it has exactly?

[mha1]

I have extended CPN with PR #3710 as counterpart to your PR #3703. It adds a checkbox to CPN's Edit Radio Settings page.

resulting radio.yml:
Box unchecked -> audioMuteEnable: 0
Box checked -> audioMuteEnable: 1

[3djc]

Thanks a lot Neil

[mha1]

Michael

[3djc]

Michael

Boy, usually elecpower jumps in like that, did not even look at the author, my apologies (to both of you!)

[mha1]

No problemo, I should have formally introduced myself :-)

It'll still take a while to finish the check builds. I'd appreciate you trying this. And there is one thing I didn't know off hand. Currently the checkbox will be available for all radios. Are there any rules to follow, i.e. exclude specific radios or radio categories?

[3djc]

Radio side it is based on hall defines, currently that's all non frsky bw radio, and all colorlcd but x12

[pfeerick]

The UI option will be a good mitigation for this, as we can then wait for reports that the sound is being clipped, and then just tell people to use the option to restore the old behaviour. If we get enough reports that it's a problem, we can change things... i.e. maybe will have to bring in a configurable option and just pre-load it with the current values. Then it will be end of the issue, period 😆

[mha1]

@3djc Yes, I saw your UI implementation is tied to AUDIO_MUTE_GPIO being defined. Look at the hal.h files I'd say the UI option should be visible for:

• all Color LCD radios (including NV14 and the likes) except Horus X12S
• TX12, TX12MK2, ZORRO, BOXER, T8, TLITE, TPRO, LR3PRO

Correct?

I'll update the CPN PR to reflect this.

[3djc]

Looks correct. Ins't brand defined anywhere in Companion (did not look), that would be easier than de radio list.

As a side note, we should know for sure on monday the wake up time for chip used by RM

[mha1]

I forgot Commando8. That has AUDIO_MUTE_GPIO defined.

No, but it has a family "T12 board" defined:

inline bool IS_FAMILY_T12(Board::Type board)
{
  return board == Board::BOARD_JUMPER_T12 ||
         board == Board::BOARD_RADIOMASTER_TX12 ||
         board == Board::BOARD_RADIOMASTER_TX12_MK2 ||
         board == Board::BOARD_RADIOMASTER_ZORRO ||
         board == Board::BOARD_RADIOMASTER_BOXER ||
         board == Board::BOARD_RADIOMASTER_T8 ||
         board == Board::BOARD_JUMPER_TLITE ||
         board == Board::BOARD_JUMPER_TLITE_F4 ||
         board == Board::BOARD_JUMPER_TPRO ||
         board == Board::BOARD_BETAFPV_LR3PRO ||
         board == Board::BOARD_IFLIGHT_COMMANDO8;
}

The only difference is it lists TLITE_F4 which isn't listed in taranis/hal.h. I suppose it is treated as TLITE in radio code, i.e. has a audio mute GPIO too. Correct?

This would be the resulting term for CPN:

    case HasAudioMuteGPIO:
      // All color lcd (including NV14) except Horus X12S
      // TX12, TX12MK2, ZORRO, BOXER, T8, TLITE, TPRO, LR3PRO, COMMANDO8
      return (IS_FAMILY_HORUS_OR_T16(board) && !IS_HORUS_X12S(board)) || IS_FAMILY_T12(board);

[pfeerick]

TLITE_F4 is basically identical to the TLITE, it's just a different processor, so that looks about right.