The PPM pin in the JR module bay operates at VBat. On my Horus X12S, that’s as much as 11.1VDC to signal a logic-high level. Is there any concern with using such a high voltage on the HM30 RC port’s UART?
@Risto,
How did you select “HM30” on your transmitter’s MULTI selection menu? In the 2.3.14 source, there is no such selection (nor “SIYI”).
I clicked on Multi with Enter and HM30 appeared.
The string “HM30” is sent in ASCII via S.PORT as part of S.PORT Status message. The HM30 ground unit firmware fills the protocolName field with “HM30” (here the code line that parses it in OpenTX: opentx/radio/src/telemetry/multi.cpp at 801b28958045d683b8c8058db5c167ae0c39da65 · opentx/opentx · GitHub ). See for reference my Saleae traces above. The S.PORT status message telegram starts with ASCII M, followed by ASCII P (for Multi-Protocol-Module), followed by hex 0x01 (for S.PORT status).
As the HM30 string gets sent from the SIYI ground unit, this explains why OpenTX source code does not include “HM30” string - the firmware just displays the field that it receives via S.PORT status protocol.
P.S. The only other type of message in the traces is the MP 0x02, which is a telemetry packet. ID 0xF101 is for RSSI: opentx/radio/src/telemetry/frsky.h at 801b28958045d683b8c8058db5c167ae0c39da65 · opentx/opentx · GitHub and the value is encoded in 32-bit in little-endian.
@Risto, perfect, thank you. I hadn’t fully digested the data you sent. I did notice that it looks like you’re triggering against a 3v3 source, and I’m still assuming that I probably shouldn’t apply VBat logic levels to the HM30 port unless @SIYI recommends otherwise.
TX16S uses +3.3V levels for S.PORT line and +5V levels for PPM/SBUS line (See Sec. 2.11: Blog #17: RadioMaster TX16S schematic diagram - RC Groups )
Excellent…the X12S uses VBat for sure on the PPM pin. Confirmed via oscilloscope. It’s quite odd that FrSky does that.
EDIT:
Minor success. Got “HM30” to show up in the menu. Then says no serial input. Probably need a proper level shifter to get RC control on the PPM pin. Will update later when I have a level shifter capable of 12V-3v3.
HM30 in “UART” RC signal mode uses the cPPM (PPM/S.BUS) pin of JR-bay as input to HM30/FM30 from radio with 100.000 baud 8E2 non-inverted. The S.PORT pin of JR-bay is used for HM30/FM30 output towards radio direction, with 100.000 baud 8E2 inverted.
In the S.PORT line trace, I was able to see two types of telegrams - the S.PORT status telegrams and the S.PORT telemetry messages.
Here an example of the S.PORT status message (bottom row):
First two bytes are always ASCII M and ASCII P to denote Multi-Protocol-Module.
Third byte is 0x01, which means S.PORT status message.
The status message is further parsed in processMultiStatusPacket() in https://github.com/opentx/opentx/blob/801b28958045d683b8c8058db5c167ae0c39da65/radio/src/telemetry/multi.cpp#L199-L239
Fourth byte is payload length, here 0x18 → 24 (bytes)
Fifth byte is status flags, here 0x27 (in OpenTX only the highest bit is ever checked, which means buffer full https://github.com/opentx/opentx/blob/801b28958045d683b8c8058db5c167ae0c39da65/radio/src/pulses/multi.cpp#L187 )
Sixth byte is major version number, here 60
Seventh byte is minor version number, here 0
Eight byte is revision number, here 1
Ninth byte is patch level, here 7
10th byte is channel order, here 0xE4 → b11100100 → decomposed into 2 bit values as 3,2,1 and 0, which results in AETR (see https://github.com/opentx/opentx/blob/801b28958045d683b8c8058db5c167ae0c39da65/radio/src/telemetry/multi.cpp#L510-L521 )
11th byte is next protocol type, here 0x7F
12th byte is previous protocol type, here 0x7F
beginning from 13th byte, the 7 bytes are the protocol name in ASCII, here “HM30” and three 0x00 fill bytes
20th byte combines option and sub-protocol number, here the value transmitted is 0x50. High nibble 5 is option and low nibble 0 is sub-protocol number. Option 5 means telemetry: https://github.com/opentx/opentx/blob/801b28958045d683b8c8058db5c167ae0c39da65/radio/src/gui/gui_common.cpp#L1022-L1034
beginning from 21st byte, the 8 bytes define the sub-protocol name in ASCII, here all 8 bytes are 0x00, thus the sub-protocol string emitted from HM30 is empty.
The status telegram is sent once every 500ms (2 Hz).
Here S.PORT telemetry telegram example (bottom row):
Again, the message starts with ASCII M (0x4D) and ASCII P (0x50).
3rd byte is type, this time 0x02, which equals to FrSkySportTelemetry ( https://github.com/opentx/opentx/blob/801b28958045d683b8c8058db5c167ae0c39da65/radio/src/telemetry/multi.cpp#L29-L47 )
4th byte is length, here 9 [bytes]
Last byte (13th) is the checksum and the validity is checked here: https://github.com/opentx/opentx/blob/801b28958045d683b8c8058db5c167ae0c39da65/radio/src/telemetry/frsky_sport.cpp#L114-L124
If checksum was valid, further processing happens in sportProcessTelemetryPacketWithoutCrc() https://github.com/opentx/opentx/blob/801b28958045d683b8c8058db5c167ae0c39da65/radio/src/telemetry/frsky_sport.cpp#L171-L375
5th byte denotes physicalId (only lower 5 bits are considered), here the value transmitted is 0x98, results in 0x18
6th byte is primId, here 0x10 → DATA_FRAME https://github.com/opentx/opentx/blob/801b28958045d683b8c8058db5c167ae0c39da65/radio/src/telemetry/frsky.h#L60
7th and 8th byte form in little endian the dataId in uint16_t → 0x01 and 0xF1 → 0xF101 → RSSI https://github.com/opentx/opentx/blob/801b28958045d683b8c8058db5c167ae0c39da65/radio/src/telemetry/frsky.h#L200
beginning from the 9th byte, the 4 bytes are data in little endian signed 32-bit int, here 0x60 0x00 0x00 0x00 → 0x00000060 → 96 (thus here - RSSI is 96).
The RSSI telegram is sent once every second (1 Hz).
I hope the above clarifies the data HM30 sends towards the radio.
Here an exemplary message from OpenTX/EdgeTX radio towards HM30 ground unit (could be interesting for someone wanting to interact with HM30 ground unit with custom electronics e.g.):
Such telegram is sent every 7.0 ms (ca. 143 Hz) from the radio.
The triggering for sending the pulses in OpenTX is via mixerTask → sendSynchronousPulses() → setupPulsesExternalModule() → setupPulsesExternalModule(PROTOCOL_CHANNELS_MULTIMODULE) → setupPulsesMultiExternalModule() → setupPulsesMulti(EXTERNAL_MODULE)
Here the telegram decoding:
Do note that whereas original Futaba S.BUS, in addition to 16 11-bit resolution proportional channels also includes 2 digital/binary channels (17 and 18), this is NOT the case with Multi-Protocol-Module telegram, where only 16 proportional channels are transmitted.
Can you explain, why you make this so tricky.
I connected two wires from the training port Connector at the back of the FrSky 9XDA Taranis to the PPM Input of the HM30 Ground Unit. And disabled the internal HF Unit.
OK, its clear now. Thanks.
I have the siyi hm30 system , it says 11 to 14v to powere but i have powered it with just 8v , Do youThink this will affect its performance
Underpowering the components does not work well. Stick with the recommended power supply values.
Thank you for your response
The reason for Yuri’s response is that the device pulls the same power no matter the voltage. Since power is current x voltage if you lower the voltage the current has to go up to supply the same power. This means the components that are not rated for the higher current will be stressed and might fail.
Oh ok good to know , have you tested this system yet? I got a couple of videos on my youtube page , about to do some more testing soon as possible
Then you can just connect the RX TX signal wires and GND.
I still haven’t got the SiYi Assistant to work. Any tricks? Run the program then plug in the cable? Change to a special channel? I assume the icon that looks like a green light at the bottom, left lights up when a connection is made?
The program does not run or it does not recognize your HM30 ground unit or air unit as a device? Please confirm.
Make sure you do not have USB-C as the default connection type for telemetry. If I recall correctly, that will prevent firmware updates.
I got the light to go green!!!
SiYi tech support sent me a driver (but it didn’t work) but inspired me to try other driver fixes like Zadig, etc.
Finally got lucky w/ the UsbDriverTool and changing the driver to a simple USB driver.
Now, to figure out which file is the latest version … 
