FETTEC S2M Protocol

[PhilippMolitor]

I would really like to see the new S2M protocol by FETTEC, which is a good bit faster and more efficient (comparable to dshot1200) and seems to handle telemetry in a very clean way. The protocol could be a firmware choice as PWM frequency currently is, as the flash is quite limited already.

This feature could lead FC firmware devs to finally look into this protocol, which i think would be a leap forward in comparison to DShot.

This is what FETTEC writes on their Discord server:

S2M is a new ESC protocol form FETtec, its made to send fast digital throttle signals to ESCs and receive the complete telemetry over the same line.
On the FC side it uses the same hardware resources as DShot, but in a different way to generate true inverted serial bytes at 2.000.000 baud, not PWM pulses like Dshot does. Because of this, the ESCs can read it much faster and does not need to read PWM pulses to get bits out of them. With S2M the ESCs read three 8-bit bytes using its hardware serial to receive a 12-bit throttle signal. After that the ESCs can simply replay the telemetry also with its hardware serial.

To secure the throttle signal against signal failures the actual 12-bit throttle value is send twice, once with normal bit configuration and a second time with inverted bit configuration. The ESC only accepts signals where both values are equal. Like that the chance to have a ESC read a wrong signal is close to zero.
The telemetry answer uses a 8 bit CRC for the 4 byte payload which is a very strong CRC to payload relation.

Because the fact that S2M uses the signal line to each ESC for throttle signal and telemetry, the FETtec FC FW can do Onewire in addition to have two digital, bidirectional ESC signals at the same time, making it redundant. Without any extra wiring.

Speed wise S2M with a baud rate of 2.000.000 can be compared to Dshot 1200. But as it takes much less time for the ESC to read the signal value, the absolute time between a sent and used signal might be even less then with Dshot 2400.

Here is a capture of S2M on the FETtec FC G4 running FETtec FC firmware and octo configuration:

Technical:

The FC sends three bytes (24-bit) to the ESC which contains the 12-bit throttle signal resulting in 11-bit (possible 2048 steps) positive and negative (inverted) throttle.
To decode the throttle signal simple bit operations are used. 
If we take the idle throttle signal of 1000us (2000 as it is 2000-4000 positive and 2000-0 negative). 
The serial bytes sent are: 125, 130, 15. As the signal is sent twice, once with not inverted bytes and once with inverted byte, the ESC first need to put this two signals together.
The non inverted signal = byte1<<4 | ((byte3>>4)&0xFF) with the values placed 125<<4 | ((15>>4)&0xFF) results in 2000.
The one with inverted bytes = (~(byte2<<4 | byte3&0xF)))&0xFFF with the values placed (~(130<<4 | 15&0xF)))&0xFFF results also in 2000.

The ESC answers each received signal with a 5 byte telemetry string which contains the motors RPM (in each frame), the type of one additional telemetry value and the additional telemetry value itself. Like that the FC gets all RPMs in every loop and the ESC can switch through 8 possible additional telemetry values like current, voltage, temperature, consumption and such. 
The first first two bytes contain the ERPM and the additional telemetry type, the third and fourth byte the additional telemetry value a the fifth the CRC for all four bytes.
Its done like:
ERPM = ((byte1&0x1F)<<8) | byte2;
Additional telemetry type =  (byte1>>5)&0x07;
Additional telemetry value = (byte3<<8) | byte4; 

the last byte is the CRC-8 generated with this function:
uint8_t CRC8(uint8_t crc, uint8_t crc_seed){
    uint8_t crc_u, i;
    crc_u = crc;
    crc_u ^= crc_seed;
    for ( i=0; i<8; i++) crc_u = ( crc_u & 0x80 ) ? 0x7 ^ ( crc_u << 1 ) : ( crc_u << 1 );
    return (crc_u);
}

The additional telemetry type numbers are:
0 : Temperature 
1  : Voltage 
2 : Current
3 : Consumption
4, 5, 6, and 7 are unused for now.

[UpMostBeast]

I 2nd this but I am not sure if S2M will be open sourced by fettec or not. Also it would be cool if the secondary telemetry was configurable. I would like the ability to have real time current measurements for implementing a current(torque) feedback control to control motor torque directly for yaw axis actuation instead of having to actuate the yaw axis through the motor throttle which doesn't have a linear relationship with the motor torque output.

[TerribleKraal]

I also would like to see this implemented.
Regarding open source, according to OP Fettec gave all the innards details on Discord, so it will be hard to consider it closed, no ?

[UpMostBeast]

Yeah you are right. I meant it more specifically about the fact that they mention it uses the same hardware resources as Dshot, but dshot has different implementations (timer based and gpio bit banging) depending on the available hardware resources. So it's not made explicitly clear how they generate the digital serial signal and read it on the other side but I guess that just something we have to figure out ourselves.