Hi Alex,
No I haven’t come up with a solution yet, it’s still doing it. I haven’t had a chance to look deeper into whats causing it.
Doug
That isn’t necessarily true. There are some boards, as Pete has mentioned, that this is not working on. Tridge thought at one point that maybe some of the boards don’t have a pullup on them, but that fix didn’t get me going for the CUAVv5Nano and apparently also not for Pete running the Cube Orange.
The extra weird bit is, I had it working once on a CUAVv5Nano for a short period of time and then it stopped and I could never restore it. On the other 7 we have going, it has never worked.
@JoshW @cglusky right now the options related to sounds and alarms are:
- for each sound also play haptic
- disable all sounds
- disable message beep: don’t, do it for info messages, do it for all messages.
What kind of options would the silence when disarmed menu item have? looking for ideas
I hope to get back out flying tomorrow as weather in afternoon looks OK finally. I will pay a bit more attention. I do know that the current setup has caused me to turn volume down which is not what we want to be doing.
Overall, just a lot of messages coming in when initializing. Some of them are bad AHRS/gryo/GPS health which are technically true but not helpful at that point.
I think I would just keep it simple and allow for
disable sounds when not armed
disable sounds and haptic when not armed
Bonus would be if we could shut them off during initialization. I might be OK getting audio alerts that mean something when it’s not armed.
Disable sounds when not armed would also disable flight mode notify, it might be better to only silence incoming status text messages.
Silence alerts only or all incoming message beeps?
Personally I like to hear the incoming message beeps at boot, they give me feedback of board initialization, so it might be better to treat alerts as regular messages and play a normal beep instead when not armed? By combing this with current option one would get:
Disable all sounds
Disable incoming message: no, info only, all
Ignore alerts when not armed: no, yes
Play haptic: yes, no
1 Like
I also like to hear the beeps during the initialization. I’d be ok with the option of playing the beep for the warning while not arming but, want to make sure that when an arming attempt is in progress, those arming errors are coming across as errors and not beeps. That part is key because technically at that point in time, we are not yet armed.
Very good point Josh!
I’m afraid this rules out the “silencing” alerts in the prearm state option, from a telemetry point of view there’s no easy way to tell that an arming attempt is in progress!
1 Like
Sounds like we may just have to leave this all as-is then. Dang! 
Bummer but all good points. I have been building and testing three different copters in several different configs. So all the beeps started to make me crazier than i am. Probably not a big deal for normal ops. Would be nice to have more context with alerts coming from arducopter though.
With a new Setup, we have the same problem as before, the horus x12 always says after a couple of minutes flight time “telemetry lost”.
So far the Setup is the same:
Ardupilot passthrough
R9M Slim
Update on the latest flex Firmware and 100mw
Latest Open TX Firmware 2.35 on a Horus X12
, but I didn´t save the parameter, are they any settings under SR, that I need to change?
best regards
christian
just got round to having a attempt at this, no idea about the protocol so I just tested a couple of possible places for this pading. No idea what I’m doing really, any better places I should try? (i did not try both padding at once, one then the other)
Hey Alex,
I was wondering if you had submitted this PR for ArduPilot? If not, I may attempt my very first cherry pick, but wanted to check in with you first.
Thanks so much!
Josh
edit: I’ve just realized you also have the 1.8.1-dev version of the telemetry script to support this. I guess I’d need to install that as well for the Horus, assuming it is out there somewhere? Happy to do some work along the way here and learn while I go if you think there is an opportunity, but right now I don’t even know how you are compiling the widgets for the Horus haha
Hello, thanks for the share. I wonder if it will work on X9D+ 2019 SE or not. Only OpenTX 2.3 has the SD content for this radio. Could I use the SD content of X9D+ and OpenTX 2.2 for my radio? Is the script compatible?
Thanks!
Hi Josh,
no, I’m trying to add custom frsky telemetry via scripting but there are a couple PR waiting to get in in order to make it work
Hi,
yes, it should work just fine on SE 2019, just do not use OpenTX 2.3.5 for it has a bug in handling button presses from lua scripts.
Thanks for the reply. Does it work well for OpenTX 2.3.4 or the script is only compatible to the OpenTX 2.2?
yes, just stay away from 2.3.5.
OpenTX 2.3.4 works just fine but please read OpenTX 2.3.5 release notes to see if it fixes any issues you might have.
Thanks for the heads up @LuisVale, what required an early 2.3.5 release was the fix for the critical bug on Horus radios:
Fix Horus temporary loss of control when an XJT module is used at the same time as an R9M
which I believe is not a common use case, but anyway the question was about a Taranis using 2.3.4 which should be fine.
So to recap:
- Lua key event handling is buggy on OpenTX 2.3.5 for Taranis radios, OpenTx 2.3.4 should be safe to use
- on Horus radios everyone should use OpenTX 2.3.5 as indicated by the official release notes