Up to now, sensor data could only be sent to a TM1000 via the X-Bus (I²C). The TM1000 also acquires data from its own sensors, – Voltage, RPM, Temperature.
The new receiver series ARnnnnT, e.g. AR9030T, has integrated the TM1000 so to speak, the receiver as an assembly itself has an X-Bus interface, and it also has its own sensor interfaces as the TM1000 has.
On the X-bus, a device can not receive servo channel data. These go “over the air” to PWM ports of the receiver. The X-Bus is therefore, so to speak, one-way, only for sensor data sent to the transmitter in addressed displays.
Addressing: Immediately after power-up, TM1000 or ARnnnnT scans the X-bus, queries every possible address (3-125). Anyone who had respond at this time will be queried in the further process in order to transfer its data. Addresses of sensors representing TM1000 or ARnnnnT themselves are not asked (126, 127). So you can not fill Vbatt/RPM/Temp in the display “Telemetry” as a device on the X-Bus. This can only be done by TM1000/ARnnnT itself with data from its own sensor interfaces. (Be careful with the ground wire at such interfaces! Their connection is ideally suited to build a ground loop, ie pull a voltage offset onto the signal ground.)
So far (Feb 2017) there is only one receiver which speaks it: SPM4649T. This is called “Quad Race Serial Receiver”, presumably because it is so small and light. Small because it has only one interface, SRXL, which a connected flight controller (or “FBL”) must be able to understand, – a single line or sum signal. The housing is actually none in the conventional sense, – once again saved space/weight. Satellite receivers are not connectable. The 4649T has however two antennas, makes diversity. Disadvantage in larger models could be the highest that the bases of both antennas are in the same place (at the 4649T). You can not distribute the antennas spatially in the model but you can align them so that two polarization planes are covered. The 4649T also has a 2-wire connection “Laps/Vbatt”, apparently alternatively for voltage measurement or pulse counting. The manual does not say anything about it. For me it wanted partout not work. The currently available 4649T have a hardware problem: The operating voltage is specified as 4-8.4V but it’s said that the receiver is killed by more than 7.4V. The specification says the transmitter should use 11ms frame rate. (The Rx could also be bound with 22ms.) 4649T supports 11ms 2048 DMSX or DSM2. It is explicitly pointed out, however, that DSM2 is to be sent with 11ms frame rate. “2048″ is the resolution of servo channel data, 2048 steps. That sends the 4649T, and only 2048.
SRXL is a bidirectional asynchronous serial protocol (1-wire). It’s not finished yet. Specs cultivate some confusion with misinformation, paper and practice differ.
Bus master is the receiver (4649T). It sends servo channel data. After each so-called “phase zero packet” a device can send sensor data, ie after every second channel packet. The protocol, the media arbitration thereby, is not suitable to be able to operate SRXL as a bus, at least not without problems to be expected. SRXL is essentially a 2-device protocol.
Data sent from the 4649T: This is currently very simple the well-known “Remote Receiver” protocol which sends a “Sat”. (I could not see any effect in “re-dressing” it in the further development of SRXL.) New/different is only the added opposite direction of data (sensor’s) and of course the involved problem for currently existing “SAT implementations” in FBLs that something is different when one use it: Bidirectionality on the medium and protocol, necessity of separating channel data from sensor data.
In the downlink direction you pack complete X-Bus packets into SRXL frames. Unlike the X-bus, you are not scanned, you can theoretically always enter and send addressed data. In practice, however, it does not look quite so.. I was already able to determine problems with the X-bus as I wanted to use sensors setup-dependent on/off, – sensors the S32 represents on the X-bus (currently up to 6). This works only partly. Firmwares of the transmitters seem to blame for it. Certain combinations, or the later “extinction” of certain sensors, lead to illogical behavior of even not involved displays. – So with SRXL, even more extreme. The received data will look to the transmitter like from the X-Bus, from TM1000 or ARnnnnT. In any case, it would take a long time to research until you know which sensor you may let “die” without the transmitter reacting strangely. Therefore, S32 on SRXL always transmits all 6 sensors (displays) that it potentially uses. It also sends speed when no speed sensor is in the setup (on X-bus it can turn off as a speed sensor), same in the case of the two displays for CVS16 data.
New: You MUST send two more sensor data packets before the actual ones, “QOS” and “RPM”. In QOS S32 sends its operating voltage. The 4649T does not seem to send its operating voltage. “RPM” are the local sensors on a TM1000 or ARnnnnT, Voltage/RPM/Temp, which the 4649T has only partially, if they would work. Here, in contrast to the X-bus, you can overwrite the values for the overview display “Telemetry”, and S32 does this: “Voltage”==Ubat, “RPM”==rpmMotor, “Temp”==tFET:
Minimal RPM is 900. Zero can not be output. But you can make it appear as “—–”. We do this, “—–” until the speed exceeds 900. Another reason to take rpmMotor and not rpmRotor. The ratio for rpmRotor is applicable in the transmitter. “Temp”: If the transmitter saw zero briefly, what can not be avoided at the startup of the whole, we see “-17″ as the minimum temperature. These are F (Fahrenheit), therefore.
All in all a good thing: A very small full-range receiver, a lot of telemetry.
Unfortunately, there is still something: I wanted to remote control. How do I get the channel data in my FBL especially when S32 sends data on the line which possibly confuse my FBL? Then also: I heard that my FBL can not understand the 4649T currently because of…
There is also a solution for this:
S32 uses the transmissions of the 4649T (channel data) not only for synchronization with the bus master, it also reads them completely and records them in the log as it does with data on JETI EXbus and Futaba S.Bus2. The user now also has the option to have his S32 appear as a “Serial Remote Receiver” which the FBL currently probably will much more like:
If the existing FBL should want to see a certain “System ID” in the packets of a “Sat” (remote receiver) then you can choose in S32′s setup as which “Sat” (frame type) it appears. Only one is currently not supported, 1024 resolution.
“22MS 2048 DSMS” are not really 22ms but also 11ms – unless you bind the 4649T unlawfully with 22ms. S32 simply follows the cadence of the receiver.
So it looks like this:
Sensor Data Rate:
First of all, you have to take note: These “22ms” or “11ms” are not the actual data rate but simply the temporal distance between two data packets. Since it takes two channel data packets (therefore phase 0 and 1) it is actually 44 or 22ms. With this cadence, namely after each phase zero packet, a sensor can send data to SRXL, – per transmission for a “sensor”==display address. One is forced to send two on top, originally not wanted, – “QOS” and “RPM/Volt/Temp” what should be receiver-internal data.
S32 uses 6 displays. That makes then a total of 8, thus it needs 8*22ms=176ms once to update all displays. This sounds a lot but is very fast compared to other systems. HoTT for example has only 5 types of sensors (displays) and it takes 5*200ms=1000ms to update them all once.
Availability from version: S32 app 1.35, S32Terminal 2.1.1.32
If an FBL understands the Remote Receiver protocol in SRXL – but at the same time is also able to distinguish channel data from sensor data – then the FBL can also be connected parallel to the SRXL port of the receiver. – What could lead to problems is if the FBL also wants to send sensor data. As I said, SRXL is actually a 2-device protocol. One thing is, of course, as well as on “real” buses (e.g. HoTT, S.Bus2), – only one device can send per display address. – Unfortunately, the media arbitration in the protocol (no operation of the bus master, in the protocol only “idle line”) is only poorly suited to coordinate several transmitters of sensor data. If sending from an FBL really should be useful, S32 could be the “flow heater” in the future, thus ensuring coordination.
Single line protocol (sum signal), confusion possible
SRXL.org, where Walter Meyer from Freakware is involved, describes a protocol framework that makes it possible to recognize the vendor of a transmission and to interpret the data contained correctly. Each vendor, such as Multiplex, Freakware (Beast), JR (X-Bus B), Graupner (HoTT SUMD), Horizon (SPEKTRUM), has one or more if there are multiple data format variants. (SRXL is the digital alternative to the known sum signal PPM.)
The protocol is unidirectional (one-way), only broadcasting channel data. SPEKTRUM, however, so far not using SRXL but its own “Remote Receiver” (aka “Sat” protocol), now invented its “Bidirectional SRXL”. The first receiver that speaks it is the SPM4649T. However, this is not only an expanded SRXL, it is simultaneously NO SRXL at the same time: Channel data are still sent in the Remote Receiver (Sat) protocol, not as SRXL! It is said that SRXL would also be on the radar for this direction in the “Bidirectional SRXL”, deployed by an updater for the 4649T.
Now one can only hope that this SRXL for the actual purpose, channel data, then also really SRXL-compliant will be. There are already SPEKTRUM receivers who speak pure SRXL (one-way), but not conform, with the checksum (CRC16) made mistakes. The SRXL portion in the “Bidirectional SRXL” of the 4649T is also not SRXL-compliant with regard to the checksum: CRC only over the payload (channel data), the two bytes of the CRC16 in the wrong order with respect to SRXL.org.
Now should be clearer why a device should be able to read the 4649T as “Sat”. Question about this device is then only in each case whether it will be able to handle it when sensors send in the opposite direction in SRXL. After all, such a device can not have been originally prepared for it. So it could happen that sensor data are interpreted as channel data! This is the reason why an S32 in the setup for telemetry “SPEKTRUM SRXL” optionally offers to send out the contained channel data on another port as a Remote Receiver (“Sat”).
SRXL.org is probably the only standard ever developed in RC, a delicate little plant. Even on the other end of the pond it was noted. It was used. I say deliberately “used” because it were not respected. Now I have asked Horizon because of “Bidirectional SRXL” which will also contain the actual SRXL, Rx->FBL. I asked them to keep to the standard regarding CRC: “PLEASE put the CRC (s – both directions) SRXL.org conform.” The answer: “The CRC will not change order or content.”
The minimum delay stick to FBL is 22ms in a 11ms system because channel data is sent in two packets. S32 received Remote Receiver data contained in a SPEKTRUM “SRXL” packet, afterwards sent it out through another port, free of “SRXL bidirectional”. This adds some extra latency, about 1.4ms.
Now (from app 1.39) S32 is transmitting pure Remote Receiver simultaneously to receiving it. The extra delay reduces to 95 microseconds by that:
