Can we reduce message stream rate to 5hz?

[fnoop]

If we request more streams for more functionality we'll likely start to saturate the link (anyone know how to determine how much of the link bandwidth we're using?).
Can we reduce the stream rate requests to 5hz from current 10hz? Is there logic that currently absolutely depends on 10hz?

[Clooney82]

Don´t know it.

But I don´t think we need informations faster.
10hz = 100ms
5hz = 200ms

Even 5hz should provide enough informations for us.

Currently we send most data every 500ms (2hz):

FrSkySportSensorAcc.h:#define AccX_DATA_PERIOD 500
FrSkySportSensorAcc.h:#define AccY_DATA_PERIOD 500
FrSkySportSensorAcc.h:#define AccZ_DATA_PERIOD 500
FrSkySportSensorAss.h:#define ASS_SPEED_DATA_PERIOD 500
FrSkySportSensorFas.h:#define FAS_CURR_DATA_PERIOD 500
FrSkySportSensorFas.h:#define FAS_VOLT_DATA_PERIOD 500
FrSkySportSensorFlvss.h:#define FLVSS_CELL_DATA_PERIOD 300
FrSkySportSensorFuel.h:#define FUEL_DATA_PERIOD 500
FrSkySportSensorGps.h:#define GPS_LAT_LON_DATA_PERIOD   1000
FrSkySportSensorGps.h:#define GPS_ALT_DATA_PERIOD       500
FrSkySportSensorGps.h:#define GPS_SPEED_DATA_PERIOD     500
FrSkySportSensorGps.h:#define GPS_COG_DATA_PERIOD       500
FrSkySportSensorGps.h:#define GPS_HDOP_DATA_PERIOD      500
FrSkySportSensorRpm.h:#define RPM_T1_DATA_PERIOD  1000
FrSkySportSensorRpm.h:#define RPM_T2_DATA_PERIOD  1000
FrSkySportSensorRpm.h:#define RPM_ROT_DATA_PERIOD 500
FrSkySportSensorSp2uart.h:#define SP2UARTB_ADC3_DATA_PERIOD 500
FrSkySportSensorSp2uart.h:#define SP2UARTB_ADC4_DATA_PERIOD 500
FrSkySportSensorVario.h:#define VARIO_ALT_DATA_PERIOD 200
FrSkySportSensorVario.h:#define VARIO_VSI_DATA_PERIOD 100

Only Vario data is submitted faster to Taranis, but this could also be changed imo to 500ms.

@fnoopdogg next time please push new features to *next branch. We should first get a stable version before implementing new features.

[wolkstein]

is there any way to measure sport bandwidth? i noticed on x8r with eu firmware that my range is better if i disconnect teensy from sport. for me this is an indicator that x8r bandwidth is at an limit.

with the grrrrmph eu firmware under bad conditions i have massive range problems. sometimes after 100 meters distance my x8r go into failsave and i get an rtl. removing sport extend the range here to approx 200 meters.

with non eu firmware i never have range problems also with connected sport.
edit: my old taranis and first x8r are from 2014. the new taranis plus from 2015 is currently used for my gimbal because eu 2015 rules.
/g
wolke

[Clooney82]

@wolkstein didn´t test this till now, maybe I should do it.

Maybe we should also discuss how often we need which data, so we can adjust transferring via telemetry.

[fmckeogh]

If I am understanding correctly, bandwidth will never be an issue for this project. Data is being sent over the FrSky telemetry protocol as miscellaneous values (The "fuel" data stream is used for ArduPilot flight modes) and currently there is no way to add more values or change their frequency. The current settings are nearly the most efficient use of the available data.

I have only been using this for a month or so, but the main benefits of this form of telemetry over 3DR radios or UHF systems that natively support Mavlink is that it is simple to use and utilities something that would otherwise be wasted, the S.Port telemetry.

As a milestone suggestion, we could completely maximize the available bandwidth by developing a system by which every numerical value to the decimal across every sensor type is used to encode mavlink data, instead of directly using the existing voltage data for mavlink voltage. There are also rumors of FrSky making both their standard radio protocols and telemetry protocols publicly available which would open many new doors.

Sorry if my suggestions are not applicable or correct, as I am only just learning. :/

[athertop]

With modification to the teensy code it is possible to access additional telemetry data and send it using smartport as an additional FrSky sensor. As for bandwidth, sorry I have no idea what the limiting factors are. Not entirely understanding your milestone suggestion either sorry. Are you suggesting sending the raw data stream down in its entirety? Even though I don't know the bandwidth limitations, I imagine packaging up the raw data streams and sending them as sensor data could cause bandwidth issues. Even if it could be done (and somehow I don't think there would be enough data capacity even with duplicate sensors defined) surely there would be no point in transmitting data you will never use?

My next adventure is looking into the ULRS system, which does allow a full Mavlink stream to be broadcast over the 433MHz bi-directional RC link. This uses the OrangeRX433MHz Rx units (as both Rx and Tx) Its possible using ULRS to build a ground station which integrates this project's teensy so you can get the same great telemetry display on your Taranis. The way it works is your ground station is basically made up of: the regular Taranis using its XJT 2.4GHz internal module as RC Tx and telemetry Rx. This connects to an X4R Rx for which its Sbus output connects to the SBus input of the ULRS Tx (which transmits to the ULRS Rx in your model). As the ULRS Tx module is receiving mavlink, this can be fed into a teensy, and the Smartport side fed into the ground side X4R - so your Taranis then gets the same telemetry stream as per this project provides. Additionally, you can take the Mavlink stream into your laptop via bluetooth, to be used by Mission planner. Its a beautiful solution - all that data over one RC link to your model and no more loss of range!

[fmckeogh]

That sounds like a great solution! My milestone solution was nearly that, taking as much high resolution Malinke data as necessary, encoding that data in sensor readings across the FrSky telemetry, then decoding back to be displayed on the Taransi screen. Range is decreased with an increase in sensors for S. Port telemetry, and this form of encoding and decoding would not only maximize efficiency, but slow for easier adjustment of data and range, as Mavlink data could be cut down over fewer sensors but still allow th user to decide what data they would like. Other forms of data would be easier to send such as full text error and diagnostic messages.

[athertop]

Your milestone solution sounds interesting - it actually sounds a lot like what's being discussed here: ArduPilot/ardupilot#1587

I think the LRS systems are definitely moving in the right direction, so I'm keen to take a look. If only HK would get the ORX LRS Tx modules back in stock! My flying wing is desperate for a LRS system! :-)

[athertop]

So because most often the teensy shares a telem port with another device, then in many cases we will not connect the Tx line from teensy to the Pixhawk, so the message stream rate code is not effective. For this reason, I have allowed for this code to be disabled, (and updated the wiki) by commenting the line #define AUTO_MAV_STREAM_CFG in MavLink_FrSkySPort.ino

In cases where the telem port is shared and the other device (I.e. not teensy) will be configured to send input to Pixhawk, this other device will have control over the stream rates. For example 3DR radio/Mission planner (which provides its own stream rate config). So need to be aware and configure these rates to support both this and teensy. In cases where teensy shares a port with MinimOSD (or other OSD) then in order to provide for both devices, its easier to not have either devices Tx line connected and configure the stream rates in Ardupilot parameters manually. I would suggest that 5hz is more appropriate in this instance. The wiki has been updated to advise on these config options, so will close this issue.