Telemetry: JETI EXbus

“EXbus” is the third evolutionary stage of JETI telemetry following JETI v1 and JETI EX. EXbus is again not a “bus”.

JETI v1 was pure text, – about every 100ms 16 x 2 characters, then a 1-byte response of the terminal (“box”) to the sensor containing the code of 4 keys. This text mode can therefore be used for interactive applications (as with HoTT text mode as well).

Then came JETI EX: Another type “hidden message” (introduced in v1 for sensor alarms) by means of which the sensor defines its displays, – textually (display name and unit of measurement) and binary (data type). Then data is transmitted binary with reference to the respective display. – EX includes (encapsulates) the text mode which exists independently next to it.

Both protocols work with only 9k6.

Now EXbus was introduced which is also only a point-to-point connection, no bus. Only several ports on a REX receiver connected to EXbus will result in a virtual “bus”. – By the way, a REX integrates an expander via several “ports” assigned to “JETIbox” which previously did not really work for multiplex between EX-speaking sensors connected to a dedicated device “EX Expander”, – with a REX it works.

EXbus impresses with 125 or 250kBd, whereby so far only devices can be seen which speak 125kBd. The master (REX) dictates the speed, a sensor must react adaptively.

Now you could think: Great speed! Far from it, the update rate of sensor data on the EXbus is even significantly lower than on EX. The reason is JETI’s only partially acceptable “hoarding”, – 80% packaging, 20% payload. If you put 3 pots into each other there is not much space left for the soup. V1 in EX, and EX in EXbus. However, since channel data are transmitted in the opposite direction which have priority (sensor data only after every second channel packet, and only upon request) there is now a large sausage in the inner mini-pot – the soup can only fill the remaining space.

The interactive part of the text mode (the acknowledgment byte) has always been unfavorably implemented. It came with the different generations of receivers again and again to “zombie ACKs”, simulating nonexistent key press, so also with the introduction of the REX receivers. – (With the REX which contain ARM processors, JETI got the bill for their sin: 9 instead of 8 data bits, parity bit for this, which could still do an ATmega, an ARM nevermore, so they had necessarily by themselves to go on a software UART, asynchronous-serial by bit banging instead of leaving it to the hardware, … as JETI did not hit the 9600 baud but, as if they were clairvoyant, they had always defined 9600 to 9800 baud . Also S32 operates JETI v1 and EX using a software UART.)

EXbus now introduced further latency which makes the interactive use of the text mode so slowly a drama. Unfortunately, they never have stored a button press in the box to send it to the sensor at the (getting rare) appropriate time. Instead, the user’s finger on the box must hit it at process time what is getting hard to do. (HoTT text mode seems to save the keycode, what they had to do from the start because text is sent every 800ms.)

Quintessence and advice are:  If sensor data is a priority, use EX and not EXbus whenever you can. Be glad if you do not have to use interactive text mode via EXbus. Unfortunately, navigating through text pages is also an interactive application.