You need the SPMA 9580 harness from Horizon for connecting the SPEKTRUM TM1000 to S32!
Configure the “sensors” in your transmitter which are named “displays” in S32terminal:
“Rx Pack” is used only when a CVS16 is in the setup but should be always configured in the transmitter. “Air Speed” is used if a speed sensor is in the setup of S32.
“Configure” means: Enable sensor and configure alarm thresholds (also rpm ratio) for you needs.
Port 8 is currently considered as dedicated to Horizon SPEKTRUM. It always works, even if one has not chosen SPEKTRUM as telemetry. As a passionate gigantomaniac, three telemetry systems can be used simultaneously, e.g. SPEKTRUM + Futaba or FrSky + DisplayBox==”JETIbox” for JETI EX. An ESC fits parallel into the setup.
Example:
In the example, we have even a fourth telemetry in the game, Multiplex (SM GPS-Logger), except that S32 is the “receiver” (busmaster). Telemetry #5 is the interface to JIVE Pro, S32 as “TelMe”.
Horizon has just released a lot of new receivers. These are receivers with the designation AR<number>T. They are certainly a merge of a SPEKTRUM receiver with a TM1000. In addition, they have an SRXL connector. But this is only unidirectional, in the form as it propagates srxl.org. Telemetry data is not transferable but the receiver has the usual X-Bus (I²C). The single-line receiver SPM4649T (“SPEKTRUM Quad Race”) is the only receiver with the SRXL modified by SPEKTRUM, – bi-directional, sensor data on the way back. This receiver does not have an X-Bus. Unfortunately, one has to find currently (Jan 2017) that the unidirectional SRXL implementations in the receivers of the “T” series are only usable by FBL systems if workarounds are implemented to cure bugs. (There is a problem with the checksum. Now, however, it seems to turn out that the correct output is by the new receivers, – previous receivers made it wrong.)
S32 will soon support the bidirectional SRXL as an alternative telemetry connection to SPEKTRUM. However, it must be supposed that e.g. helicopter pilots will hardly use the 4649T.
S32 had now enough effort with the X-Bus of the “T” receivers… If you want to use such a receiver in the usual way as with the TM1000, namely, if both devices start simultaneously (Rx gets voltage, supplies S32 through X-Bus ), then S32 needs a modified bootloader version 1.8 (or later possibly higher). If you do not perform the update, continue using bootloader version 1.6 or 1.7, then you can only help by giving S32 its operating voltage about 10 seconds BEFORE the receiver. Otherwise the sensor scan of the Rx can not find anything. – For JLog 2.x one must apply this workaround generally, modification of its bootloader is impossible.
Modeling … actually a disqualifying word in terms of the quality of design and manufacturing of some offered devices.., unfortunately. Documentation or storyboard, that seems to the developers generally an unanswered. How else can the developers at JETI for many years not even agree on whether their terminals (transmitter, Profibox) accept uppercase, lowercase or both letters as alarm code? Small teams do not automatically need only small organization. In the software development it does not work without.
At Horizon in the SPEKTRUM receiver development it seems to be no different. Although Andy Kunz, developer in the transmitter department, was forwarding several times since 2011 how senseless the sensor scan of the TM1000 is designed, that it presents a multisensor like JLog (5 sensors (bus addresses) in one) a special task, – everything in the wind. We make everything new, only much worse:
TM1000: The sensor scan starts immediately after the TM1000 powerup. A more complex device with a bootloader and some todo (or waiting, namely on an SD card) at the startup, like JLog, gets thereby trouble. Finally, the scan expects complete data packets as a response .. and if that does not fit into the memory area of the bootloader? (JLog2.x) – JLog2.x, to this day also S32 (JLog3), maintained that by stopping the bus until ready to answer in the premature scan. This is simple and following the bus protocol by pulling the SCL line low. – The absurdity of the scan is: a) performed unnecessarily early on powerup, b) quickly asking the essential addresses assigned to today’s sensors and displays, namely, as first ones. If you do not answer, the data is not requested, the display remains inactive. With the TM1000 the drops is sucked after 3.6 seconds – if one does not find the brake pedal.
TM1000
Up to the start of the scan after powerup it takes only 60ms:
then each sensor address is retrieved twice, in ascending order, the important (allocated) addresses first, these of future nominal members later:
(Top: You can see JLog answering a query. Bottom: Asked twice.)
.
But the developers of the “T”, freshly imported or previously “flashed” (Men in Black ), understood it perfectly, third party ignoring, to put a very thick egg on top. “What does <bad> mean, its going to get worse.”
To stop the bus via SCL: This still works by hand but not by a microcontroller as a bus partner, at least not if it is not a toy. Reason: Two devices are awakened at the same time by providing operating voltage, – from zombie to a “conscious being”. It is perfectly normal that at least one spike appears on a line before it is ready for operation. With ATMEL, Microchip &Co. of the old form one could possibly be lucky, or suppressed it by fumbling. With today’s usual ARM architectures of microcontrollers this is never going to happen. A complex clock center must start, consisting of x PLLs (Phase Locked Loop) and dividers, power domains must be activated, then initialize the components of the pin functions. The SPEKTRUM developer should know this because in the “T” receivers is a STM32F0. Actually, this is not worth mentioning if the bus partner is correctly implemented. If.., it is not. As soon as it sees a tiny spike on SDA while pulling SCL down as a scan brake, the receiver’s service handler screws up, bringing SCL to low for all eternity, blocking the bus, Amen:
AR9030T
(We are in luck w/ CVS16 w/ the “SPEKTRUM direct” firmware although it’s also an ARM.)
Im not hurtful but I’m looking forward to the next sensor from SPEKTRUM. It will have an ARM as MCU, for sure. There will be then self-crafted joy among the developers – like at JETI, by using 9 data bits, plus parity, plus 2 stop bits, for which a UART in an ARM shows the whistle. Bingo, software UART greets (REX receiver), so fast the flight forward, fine good with 8 data bits: EX “Bus”.
Ok.., here helps only to immediately to be in service for the buggy receiver. Actually, this is unintentionally because at start we have more important things to do. Fortunately it fits into the bootloader of JLog3 (S32), but in the bootloader memory of JLog2.x is no space for. There we have the receiver’s scan, 5x responded by S32:
Hey, 75ms for everything, after 35ms all existing sensors are queried. As said, the receiver “suffers” itself from being an ARM. It does not start its work after 60ms like the TM1000 but needs even >320ms:
Pity that it no longer needs.. Between the “interrogations” of different sensor addresses are not 13ms as with the TM1000 but it is only about 0.4ms:This is already the hardness because JLog is a multisensor, has to re-initialize in between to answer to further addresses: about 14 microseconds, rather much less concerning I²C:
You have to ask: Is that necessary? Rhetorical question.. – Each address is asked only once:
Ok, when it finally works (thanks to Horizon for the stress), one looks enchanted at a functioning system:
In front the scan, with which one has it so very urgent, then as a reward of the anxiety the queries.
Since no time is left to read out our setup at first, we put a leg in the door during the scan, respond for all 5 sensors potentially to be used. Later, however, we only respond to data queries to sensors in the setup really, whereby another sensor on the bus has the chance to use the then freed sensor. In the following screenshot you see it (the thinner line), – but actually it should show something different:
The sensor addresses seen in the scan are queried in turn, 64ms in between. Means for e.g. 5 sensor addresses (JLog standard): 5x 64ms = 320ms for updating a data set. Already funny.., first you have it so nonsensically hurry, then dawdle? Or is it just the fact, initially assumed, that you did not have a clear storyboard? – Anyway, the TM1000 can make it faster: every 64ms a record to the query, 20ms between the queries of the sensors belonging to the set (according to scan result). Ergo with 5 sensors: 64ms + 4x 20ms = 144ms:
So far FYI. Nothing human is alien to us – in modeling certainly not. :)
–> Bootloader 1.8
Only by updating to this bootloader S32 can be powered up parallel with
one of these new SPEKTRUM receivers with X-Bus, and the
sensors of the S32 are found by the receiver’s scan.
(With an older bootloader of the S32 the scan by such a receiver works only
only when S32 gets its operating voltage about 10 seconds BEFORE the receiver!
The TM1000 is not affected, it also works with an older bootloader.)
–> Bootloader 1.9
For SPEKTRUM X-Bus: S32 represents a sixth sensor now: 14S LiPo if CVS16 is in the configuration.
This had required a modification to the bootloader.
Corresponding app minimum version: 1.33
(Contained previous update: 1.8)
S32 as sensor 14S LiPo
Minimum displayable value: 2.56V, maximum: 5.10V. Cell 2 to 14: A cell display and that of all following disappeares if the voltage of the corresponding cell falls below 2.56V.
CVS16 in the so-called “pack mode”: Only successive cells are shown.
CVS16 not in pack mode, as 16-pin voltmeter: All 16 pin voltages shown, “2.56V” if below a certain value, “5.10V” if above: Pins 1..8: 2.56 to 5.10V, pins 9..14: 25.6 to 51.1V, displayed as “2.56V to 5.10V”
“Rx Pack” is used only when a CVS16 is in the setup but should be always configured in the transmitter. “Air Speed” is used if a speed sensor is in the setup of S32.
———————————-
(JLog2.x) – JLog2.x, to this day also S32 (JLog3), maintained that by stopping the bus until ready to answer in the premature scan. This is simple and following the bus protocol by pulling the SCL line low. – The absurdity of the scan is: a) performed unnecessarily early on powerup, b) quickly asking the essential addresses assigned to today’s sensors and displays, namely, as first ones. If you do not answer, the data is not requested, the display remains inactive. With the TM1000 the drops is sucked after 3.6 seconds – if one does not find the brake pedal.
