S32 receives its operating voltage basically and exclusively via the telemetry connection. Although S32terminal selects and displays the port, the possible ports as operating voltage inputs are, of course, usable at any time: port 3, port 4 and port 8.
In another respect it is not the case that is does not matter whether you are connected to the port marked by the terminal or just by one of the other two: On all 3 ports, S32 constantly measures the input voltage, logs it and displays it in the text mode of JETI and HoTT (and at startup in the log file header). But it always takes the voltage of the marked port as a replacement for “Ubec” (log, telemetry, alarm evaluation) automatically if the ESC used does not provide a data value “Ubec”.
Regarding port 4, please note that this port can also be used as an output for a supply voltage of approx. 3.2 to 3.3V. It is the internal, stabilized voltage of the S32. This voltage is used for active external sensors of the “sensor fusion”, – temperatures, RPM, SM speed sensor, SM GPS-Logger. If the telemetry is Futaba or FrSky, the S32 is supplied by the corresponding receiver. If the receiver is disconnected from its supply voltage but S32 is still supplied from another source (e.g., USB) then the supply path will turn, the receiver and all devices connected to it (servos?!) will be fed from the 3.3V of the S32. This, of course, is not within the meaning of the invention.
In principle, you should basically disconnect all other connections from S32 before connecting it to a host (PC) via USB. If one overloaded the port of the USB host (max.500mA) by the aforementioned misapplication, then this is not bad, – it simply switches off. However, it is dangerous in principle if you connect two mains-operated devices whose different protective contact potential could land on the USB! Usually, the model is not line-powered, but on the bench you could have a power supply connected.
You can still use S32 operating voltage if you want to connect it to USB even though USB would supply it. The software of the S32 does not require that it is de-energized before USB is connected. The above will, of course, persist: as long as the device connected to port 4 does not itself have supply voltage from outside the S32, it will not supply S32, but allow itself to be supplied from S32.
Because of the expected current in such “misuse”, an information: the voltage regulator in the S32 is not a linear than a so-called “buck”, a switching regulator. Thus, if e.g. the original source of 5V (USB) can drive 500mA then max. approx. 760mA will be driven on the 3.3V output side. The buck does not hurt it so much but purely theoretically, the decoupling diodes in the supply paths in S32 are specified for max. 1A.
The 3 voltage inputs are decoupled from each other with diodes, ie, a voltage entering port 4 can not power devices on port 3 or port 8. Even USB does not see anything as a beneficiary, so you can not feed your PC via S32.
Devices on the data bus of the S32 are fed via the S32. The input voltage (raw voltage) appears on the data bus as it could be fed to port 3, 4 or 8. Which voltage is mainly loaded by devices on the data bus, determines the level of the respective voltage: The strongest gets the job.
If RC operating voltage is also present on a servo line, e.g. from the data port of an ESC, then you should basically cut the corresponding wire. In general this is the red wire, only with JIVE/HeliJIVE the yellow. There are two reasons for this: A) This voltage can be up to 8.4V. The pin of the S32 on which it appears is actually for max. 3.3V level as with all these devices in RC. In practice, S32 is not going to be damaged by that but you should make it to the principle not to do something like that. – B) In the S32 is an ARM processor which would already run with 1.8V. As long as the processor does not have supply voltage in the S32 itself it is simply an undefined, non-linear resistor, through which voltages at the pins of the S32 ultimately end up on the capacitors at the output of the voltage regulator. This could now prevent a clean POR (Power On Reset) if S32 gets supply voltage anytime later.
