Thanks for working thru this with me!
you’re welcome Henry, really glad we sorted this out!
yep…there is something definitely wrong with the OpenTX code surrounding the use of that external Sport pin…two FRsky based models have the script working fine, havent been modified in over a year, would not work if I enabled the ext module and turned off their internal RF…reverting back to internal only and everything working again…
FYI mystery solved…as I was creating new models, I discovered that the non working models had a unique characteristic…they all had pre-discovered sensors…
one had all the Yaapu sensors discovered…the other was using the telemetry RSSI as an input, a hold over from when I was using analog rssi and transmitting back to the plane in a channel for the OSD to display…when I removed those items, the model configs started working…what really tipped me off was that the input with RSSI as its source had changed to TELEM2:HDG!..must have happened in the 2.1 to 2.2 upgrade…
I went into panic mode. All the arduino shops here are out of MAX2323 boards, banggood is sold out and I gave my last unit to a friend.
Are Teensies an option, 'cause I still have three or four laying around ?
I dont know what part of the world you reside in, but if you are ordering from Banggood, Aliexpress is as fast and has many listings…also Amazon, if you are in the US
Hi,
you might use a recent 3.x Teensy with @Eric_Stockenstrom firmware to convert mavlink to passthrough while you wait for the “slow boat from china” to arrive 
Hi all,
I released version 1.8.0 for Taranis X9D, QX7 and X-Lite, only minor changes from the release candidate
- new hud layout, speed on left, alt on right VSI on bottom
- added support for up to 6 frsky sensors on dedicated second screen
- added script reset support (no need to power cycle the radio between packs)
- added haptic feedback support
- added total distance (calculated from speed)
- added PX4 flight modes support
- added support for mavlinkToPassthru firmware Plus version
- added vocal playback of selected mavlink messages
- added support fot serial and independent battery configurations with individual cell count override
- added support for battery voltage > 51.1V
- added new message alert silencing options
- fix for quick flight mode switch
- fix for rover modes vocal playback
feedback is welcome,
cheers,
Alex
Alex, I can’t wait to try the new Plus version…a screen layout guide in the wiki would be helpful…
I had an idea for a new feature that occurred to me a few nights ago while night flying my , now deceased, MiniTalon. I had an aileron servo fail (melted actually) and it spun in. Since I had QGC running on my phone via DL TX, in parallel with this script, the last GPS location was displayed, so I found the wreckage in the dark fairly quickly. But if I had been running only this script (like on one of my Frsky RX planes), I would have been hosed for sure.
Perhaps, the current gps position could be periodically stored in the model config file so that the crash location could be easily found…even if the GPS location was being recorded over video( I never clutter the screen with that however), the RC link would be the last to go. I dont know how often it could be stored without interfering with normal operation, but more often is better of course. I personally would take a little slower update rate to have this info stored more often. It would be nice if it was shown in the config menu in Goggle map coordinate style also for quick entry into your phone.
Just a thought.
Yeah, losing a bird with just the FrSky telemetry and no google-earth-capable device connected alongside is a prospect I’d like to avoid. Three times I’ve had to search for a lost craft, and I’ve always had the laptop on and connected. That black rectangle with “no telemetry data” obscuring 1/3 of my RC screen would add to the stress, as well. Can it be changed to something like screen fading to black with text for one second every 5 seconds ? And in those 5 seconds of “normal” screen, to be able to navigate between the screens, to be able to asess the state the bird was in before it lost comms ?
One other issue. If i stretch my missions, I run outside R/C range for periods of time. As I regain connection, I see battery consumption update in big steps. Consumption is a current/time equation which is computed locally on the remote, I believe. How is the consumption estimate being computed for the out-of-range time ? Using the last valid current sensor reading and time elapsed ?
Hi,
this is how the version I just released works, no more big “no telemetry data” on lost connection, only at startup while waiting for the first link, after that you get a blinking border instead
the script relies on ArduPilot for battery consumption, I do not do any calculation locally, all voltage/current and consumed mAh information is in real time from the flight controller
Thanks for setting me straight, Alex. I’m still using plain FrSky sensors, like FAS-100 on some builds, that’s why I thought consumption is computed on the remote. I’ll install the new version tomorrow.
yeah I know, docs are a bit behind, this should help you
GPS info is not processed by the script, it’s a real frsky sensor sent by ardupilot so as such it’s value is retained also after a link loss, and you can log it to the SD card at up to 10Hz with standard OpenTX functionality.
What I usually do is define an extra telemetry screen and add GPS there, do you think this would be enough?
yes…if it persists after link loss, it will be perfect…I will add it…thanks for the screen info…
you’re welcone Henry, looking forward to have some feedback on the “Plus” version!
you’re welcome. but I still cannot understand why you see “updates in big steps” after regaining your link, you should see an instant jump to the current status, I’ll try to simulate, just curious
Sorry for my frenglish. It’s one increment for each re-establishment of radio connection.
ahn ok, this makes sense, it’s the expected behaviour 
to use on the F405-STD and the same connection system as px4 2.8?