THEMA:

The expander is the router in this case, not the RX.

If the expander is integrated in a RX - then and only then you are right.

But even a network router doesn't look into the paket contents.He looks into the header for destination and requested priority from the sender....

Read the Spec to understand how Jeti-Telemetry works.

I think there are different points of view:
Theory:
- If you design a perfect system; I completely agree that the sensor is the right place to define when what should be transmitted.
- The next question is: do you have a relaiable system? So when the sensor won't get an acknowledge from the tx, it should transmit the signal again ?
- Yes basicly the rx should act only as a router and should not filter any package and also has enough bandwidth to transmitt all packages to the tx.

So far so good the theory.

Real world:
- Most sensors do not offer any configuration. Some sensors offer an option to enable or disable some signals. Only a handfull might offer a priority.
=> find a point in your system, where you can control what is going on!

- The bandwidth between rx and tx is limited and as far as I know there is no resend, if a package gets lost.
=> that mean indirect the limited bandwidth is a filter, because the ex bandwidth is higher than the bandwidth is over the air.

So my proposal to jeti is make your system smart and somehow relaiable, that means
- the first imcomming point of sensor signals is the receiver, make it smart to use the bandwidth efficently
- the tx could request (addreess) specific information from the receiver.
(If the sensor would support that even better - but nowadays addressing is not part of the public specification - so no third party could implement that.)
- the tx could request a hight priority sensor information again, because the tx knows what it got. so make it relaiable!

And the nice thing is there are unused bits in the ex protocol, which could be used to address things.
In total my idea I probposed to jeti is a bit more complext but not complicated.

So the basic story is:
- tx has a config menu for 4 groups, every group would have a specific priority (repetition period).
- the user can assign sid/pid to a group, this is transmitted once to the rx like the rx setting menu
- the rx can filter incoming traffic and route the sid/pid info to a group package
- the tx is requesting telemetry info according to the group priority (today only address 0) maybe tomorrow 0-4
- if the rx sees a new sensor id (sid) it will be transmitted on group 0 to the tx

I integrated in my sensor project (exbus sensor eigenbau auf basis 328pb) a kind of priority and the system feels much more resposive compared to other products.

Regards
Andre

even more if you start addressing and find a good solution - it could be the starting point to make a real bussystem out of the exbus

andreobi schrieb:

- Most sensors do not offer any configuration. Some sensors offer an option to enable or disable some signals. Only a handfull might offer a priority.
=> find a point in your system, where you can control what is going on!

To me this really seems the major issue from the user perspective. If all sensor manufacturers did like SM Modellbau where you can chose which data is transmitted directly in the sensor, things were nice and easy. But it seems most companies aren´t really interested in that. Think of an electric glider with YGE telemetry ESC and Jeti Central Box. There´s not too much bandwidth left for your vario and you got no chance to put it on priority. On the other hand, I get numerous telemetry measures I just don´t need.

From this perspective it might make most sense to filter in the RX (or its integrated expander). The sad thing is why should Jeti facilitate that instead of implementing such feature in their sensors directly? Speaking in other words, why should one manufacturer make it more attractive to use 3rd party devices with his RC equipment instead of sensors from the very own portfolio...

I fully agree but as long as the return channel sends with heavy reduced power, we will never get a perfect telemetry system.

Regards, Walter

I thing there are some good reason why jeti should do that

- keep your sytem open to other sensor, because one manufacture never can satisfy all. A closed systen will loose attraction and even more worse, you have to spend a lot of money to keep it closed. (i.e. jeti has no ESC which will controll more than 200 A at 14s or do they?)
- have a better product than other manufactors - if jeti won't do it, maybe opensource might drive the market? And how much effort must be spend to get an unsatisfied custumer back?
- there are theads where users are complaining about missing packages, unnecessary values and no real bus system
- ...
- and at the end: the enemy of a good product is a better one!