RX Receiver should be enabled to prioritize EX Sensor signals

not sure how it works for e.g. sm-sensors (unilog/unisens)
when reading a new sensor in the TX it is the same as in PWs image
the last column offers a YES/NO option

now I am unsure if it is send down anyway but not logged or if it is no sent down at all
I think it is the later, anything else wouldn't make sense to me
as by now I always enable everthing in the sm-software programm on PC
and the in the sensor menu in the TX I chose only the ones I need for the specific model and had so far no problems till now

Instead of a Yes/No Option a selection of the update priority would be great, like:
- High: update period < 100 ms
- Medium: update period < 1 s
- Low: update period < 10 s
- Off: Value is disabled

It would be great if this is implemented in the sensors at least.

Regards
Lukas

skyfreak wrote: not sure how it works for e.g. sm-sensors (unilog/unisens)
when reading a new sensor in the TX it is the same as in PWs image
the last column offers a YES/NO option

now I am unsure if it is send down anyway but not logged or if it is no sent down at all
I think it is the later, anything else wouldn't make sense to me
as by now I always enable everthing in the sm-software programm on PC
and the in the sensor menu in the TX I chose only the ones I need for the specific model and had so far no problems till now

PWs picture shows the DeviceManager Settings for a MVario2. There someone can set if or if not a value is transmittet.

In the Senssors Menue a user can choose if a value is logged. This doesn't affect the transmission to the TX.

The priorisation of values should and can be done in the sensor.

The priorisation of whole Sensors could be done in expanders. This applies also to CBs and REX RX.

And on top it would be nice if the Spec would be enhenced with a static value that is only transmitted from the sensor a few times and kept in telemetry windows and the log and that is not counted for the telemetry value limit.

gecko

… i guess, best would be in the Rx. he‘s in the role of a concentrator, knowing all sensors. so this could be the dispatching point for sensor data following frequency that can be set directly here for every sensor parameter. not that complicated and very effective…

No,

the RX just transmitts Pakets from the Sensors. It is not his Job to look into a paket and rearrange it according some user-rules.

His Job is to feed the servos with signals.

routing rules are typically managed by routers, not senders of packets... that‘s at least how big data networks are managing traffic. the problem here is quite similar. the Rx is much more in the role of a communication gateway in modern systems, not only feeding servos...