thanks for double checking!
I made some changes to how the telemetry rates are adjusted based on rfmode:
rf mode 2:
- custom CRSF passthrough 30Hz (everything but GPS and status text)
- custom CRSF status text 2Hz
- native CRSF GPS 3Hz
- native CRSF battery 0.5Hz
- native CRSF flight mode 0.5Hz
- native CRSF heartbeat 0.2Hz
- native CRSF attitude 0.2Hz
rf mode 1:
- custom CRSF passthrough 8Hz (everything but GPS and status text)
- custom CRSF status text 0.5Hz (messages with severity info, debug and notice are dropped)
- native CRSF GPS 0.5Hz
- native CRSF battery disabled
- native CRSF flight mode disabled
- native CRSF heartbeat disabled
- native CRSF attitude disabled
arduplane_OmnibusNanoV6.apj.zip (604.6 KB)
And this is the Taranis X9D version with rssi layout fixed
https://drive.google.com/file/d/1jw8XRQPtpH5UBUSNwbUR1UisjWhUZHXS/view?usp=sharing
thanks a lot again!
tried to free some mem on the taranis and reinstalled the script, but noticed itās actually not just the script freezing. i get the gps / status messages ok, just the passthrough part seems to stall. when that happens i do see the crossfire lua script showing issues too, so it might still be an issue on my transmitter.
will get some sleep, then do a little dayjob stuff and go back to testing your updates asap.
1 Like
Are you running another lua script in parallel with mine?
On X9D radios lua memory is so tight that multiple scripts would probably interfere or crash each otherā¦
If itās true that you never sleep and therefore could upload updates for F405-WING and QX7, I could also do some indoor/outdoor testing here. Also on the same plane by the way. 
Hi,
did some basic bench testing.
Tested on Jumper T16 with OpenTX 2.3.5 (db7d2413)
tried with TBS MicroTX V2 with FW 2.4.2
and big TBS TX module on FW 2.4.2 and FW 4.0.5
got the odd T16 radio freezing as wel even without running the widget.
One side effect was found: connected to MissionPlanner I saw flooding on the messages screen:
I also tried make it work on Frsky xLite OpenTX 2.2.4 (66bb9c3a)
Here I got the āno telemetryā screen.
In the telemetry screen (11/12) after a sensor discovery the radio found 21 sensors.
In the past I have used the telemetry script (1.8) on this radio with Frsky-D16-RX successfully.
Side note: with the xLite no āmessage floodingā in MP was found.
For further testing I still have a question: what FW do you run on the radio and the TBS module?
Thanks.
PS: You may guess my test vehicle is a āmini-ARā as wel. Still on 2.4GHz.
Edit: The āmessage floodingā is unrelated to the issue. I found the āmission resetā switch of the T16 got stuck.
Sorry for the inconvenience.
Hi, I just tested ver 0.6 on an omnibusf4 v3 and here no problem at all both on my horus and my X9D,
I have a microTX V2
good morning!
iām sorry, LUA and respective memory handling on OTX is something iām not that familiar with yet. iāve got your script setup on a telemetry screen. from the audio responses i get the impression that itās constantly running, no matter if the screen is active or not. when i launch the crossfire script to adjust some setting, it occasionally crashes with an error screen, but that is a very obvious situation.
however, i can see the PT-type telemetry stalling after acquiring sat fix regardless of any script running on the transmitter.
on a sidenote, iāve been testing with crsf fw 3.78., 4.03 and 4.05. the latter is supposed to fix the wifi moduleās MavEmu issues, but as it seems it doesnāt. it adds a set of messages to the emulated MAVLink stream, but i canāt see the respective values being filled from CRSF tlm.
if i may ask: iāve seen the PT msg rate set to 30 Hz in the codeās comments. this, at first glance, seems like a very high rate for a telemetry message set. is this the actual rate the PT msgs are sent down the RF pipe?
hope iāll be testing on a radiomaster tonightā¦
oh I see, you were running a setup script, thatās OK, when you run a Tools script all other lua scripts will be put on hold, the sat freeze thing does not make sense but once you test ver 0.6 and the new X9D lua weāll have more info to debug it
on a sidenote, iāve been testing with crsf fw 3.78., 4.03 and 4.05. the latter is supposed to fix the wifi moduleās MavEmu issues, but as it seems it doesnāt. it adds a set of messages to the emulated MAVLink stream, but i canāt see the respective values being filled from CRSF tlm.
When passthrough custom telemetry is enabled regular CRSF messages are slowed down, so you should experience a lower update rate for emulated mavlink, to check if the new firmware works all right in emulated mavlink you should probably disable custom CRSF telem.
If emulated mavlink is a big priority it is not going to be easy to make it work in rf mode 1 along custom CRSF tele.
if i may ask: iāve seen the PT msg rate set to 30 Hz in the codeās comments. this, at first glance, seems like a very high rate for a telemetry message set. is this the actual rate the PT msgs are sent down the RF pipe?
That should not be a problem, itāa polling type telemetry no way for ardupilot to push data above the rate allowed by the RX, i.e. those rates are the MAX rates, the actual ones depend on link quality.
The scheduler we use a WFQ (weighted fair queuing) with embedded shaper, so packet rate does dynamically adapt to the link data rate
Oooh there is a v4.x FW version - I will have to try it!
I quite like the MAVEmu stuff - if it worked reliably - it would be nice if they played nice together.
Would it not be better to get as much as you can from the native telemetry and only use passthrough for things you donāt have - that would surely solve the problem?
Yes, this is plan B, but not sure which is the best approach, could also ditch passthrough and extend CRSF telemetry with custom frames
What Iād need for full functionality:
Home Status Frame
- relative altitude (above home)
- home distance
- home direction
Battery 2 Frame
- copy of BatteryFrame (with different ID to allow passing to lua)
AP Status Frame
- flight mode number
- frame type
- ekf failsafe bit
- bat failsafe bit
- is flying bit
- arming status bit
- simple/supersimple 2 bits
and finally
- gps hdop
- vertical speed
- airspeed
- throttle
i expected that and tried without RC_OPTIONS bit 8 set. i just thought it might help to locate the actual pinhole iām seeing with PT over CRSF on GPS fix. it donāt work as expected though.
i donāt see MAV emu working correctly on microTx / wifi with fw 4.05 yet. the expected mavlink messages are added in contrast to 4.03, but i donāt see actual data populated from CRSF telemetry. do you?
Iām pretty positive that in mode 2 they can work together no problem, rf mode 1 is an issue for any solution Iād come up with 
I had some problems with basic functionality using 4.x and went back, so it would be great if this could be kept 3.7.8 compatible. Attention, to successfully roll back to 3.7.8 you might have to keep an old version of the TBS Agent handy.
Have no idea, youāll have to do the testing for us 
What features were introduced with ver 4.x? Do you have the release notes at hand?
Yeah there are quite a few bits missing I guess. I can see how just doing passthrough is more attractive. One thing to bear in mind is that other devices interpret the telemetry - for instance the Evo VTX turns the telemetry into OSD data - so I think we really need to avoid losing the regular telemetry messages. I think your breakdown above is probably about right - if we did this right we could propose to TBS some additional frames. Will the missing pieces fit in a single frame, just wondering if you could essentially do passthrough of all the missing pieces.
The only thing I see is the HUD moving correctly - so something is working
so you do have attitude values other than 0, thatās more than i get. just to be sure, what Crossfire hardware are you using (fullsize or micro, wifi or bluetooth)?
Fullsize + bluetooth