Well, I had some time to play with my son's S1 today. The good news - conformal coating  is very weak and can  easily be washed out even with acethon.

Now not so good news - I was looking at motion control boards and unless I'm missing something, there's just a single can tranceiver - Maxim MAX3051 (SOT23-8 package on the bottom side of the board marked "AEKF"), which is driving the bus with the black connectors. Now, MAX3051 datasheet says that the tranceiver is not FD and can only go up to 1Mbaud speed. So, since there're reports that black can bus runs @ 2Mbaud, either I'm nuts or DJI is pushing this poor chip beyond its rated specs.


Both orange "M-BUS" and red "M0" connectors seems to be RS485. There're two TI SN65HVD75 RS485 tranceiver chips (SOIC-8 packages marked "HVD75", one next to MAX3051 for "M-BUS", the other on opposite side of the board next to the NXP MIMXRT1021CAF4A MCU for "M0". That might explain the reports of observing 961MBaud speed in Duane's excellent article on hackaday.io: Robomaster S1 hacks


Hit Plate has stm32f042k6 MCU and TI TCAN334 Can bus tranceiver.



I'll hope to get another chance to play with S1 in a few days and try to take a look at an bus closely (need to find some rs485 tranceivers first).


Here're a few hi-res pictures I took:  Pictures

If anyone has any ideas on serial communications used in S1, please share your thoughts.


-albertr

Also, STM32F042K6 datasheet insists that it has can 2.0A & 2.0B, not CAN FD, so max speed is 1MBaud. Interesting...

-albertr

One of several things I find puzzling is the microcontroller used in the hit detectors supports CAN up to 1Mbps yet I measure 2Mbps on the CAN Bus. Another thing which I find puzzling is the use of at least two different bit rates used on the M Bus. The following traces were taken by passing the M Bus differential pair through a RS-485 transceiver.
I've previously shared these images in this post.
https://forum.dji.com/forum.php? ... 8&page=1#pid1949641
Below is an overview of a section of communication I'm investigating.

I assume section A is a request for information. I assume section B is a reply from one of the motors.
I set my logic analyzer to decode the line as an asynchronous UART with a 64-bit data packet (the largest available). I set the expected baud to be 921600 bps.

You can see how nicely the transitions match with the expected baud.  The B section doesn't have such nice alignment.

Here's a close up the 2Mbps trace of the black wire CAN Bus.

I held the cursor over an 8-bit section to show how the logic analyzer timed the 8 bits as 4us.

The the RS485 chips are SOIC-8? They don't look like SOIC to me. My guess is it's a SON-8.

I used a ISL3178EIBZ SOIC-8 to convert the differential signal to one I could feed into my logic analyzer.

No wonder you doubted my baud estimates. 2Mbps doesn't make any sense. I keep looking back at the original logic analyzer file trying to figure out how I read the timing wrong but I keep seeing half microsecond bits.

I'm looking forward to someone else getting good traces on these signals.

I'm trying to figure out what the difference between RS-485 and CAN Bus is. All I can find is RS-485 is a physical layer and CAN Bus is a logical protocol. I'm guessing CAN Bus often uses a RS-485 physical layer.

Sorry about packaging mistake for TI SN65HVD75 chips, my bad.

-albertr

I think signalling characteristics and thus transceivers have many similarities between rs485 and can bus. However why would one use rs485 transceiver if it's the can bus? It doesn't make any sense, the packaging is  different, and can transceivers are less expensive. Since MCU used on the boards do support can bus, the only possible explanation I can think of is that motors lack can-capable MCUs and using some serial UART transmission instead? If that's the case, and rs485 used in fact on M-BUS we cannot assume standard can frames, but need to figure our serial uart protocol they implemented. It sucks.

-albertr

albertr Posted at 9-7 16:42
I think signalling characteristics and thus transceivers have many similarities between rs485 and can bus. However why would one use rs485 transceiver if it's the can bus? It doesn't make any sense, the packaging is  different, and can transceivers are less expensive. Since MCU used on the boards do support can bus, the only possible explanation I can think of is that motors lack can-capable MCUs and using some serial UART transmission instead? If that's the case, and rs485 used in fact on M-BUS we cannot assume standard can frames, but need to figure our serial uart protocol they implemented. It sucks.

-albertr

"f that's the case, and rs485 used in fact on M-BUS we cannot assume standard can frames"
YES!
This makes the data make much more sense.
I used the standard serial protocol of one start bit, one stop bit and an 8-bit data value and the data lined up appropriately with the traces. Start bits and stop bits were all in the correct locations without any framing errors.
Each "packet" starts with a "U" (ASCII 0X55) character which is often used to allow automatic detection of the baud. The character "U" (0X55) is a nice sequence of ones and zeros in binary. This explains why I was seeing different bit rates on the same line. A packet begins with identifying the timing it is using.
I'm pretty sure I can read this sort of data with a Propeller microcontroller.  Adding an auto baud isn't trivial but I've done something like this before with using a Propeller microcontroller to program quadcopter ESCs.

This doesn't help much with the black wire CAN bus but I think this is a big breakthrough on understanding the motor bus.

RS485 differential transceivers are quite common and you should not have any problems finding some, for example at Digi-Key... https://www.digikey.com/catalog/ ... -transceivers/10428

Just FYI here is the data sheet for the S1 quad core ARM CPU:

http://phonedb.net/index.php?m=p ... led_specs#section12

Duane Degn Posted at 9-7 15:29
I'm trying to figure out what the difference between RS-485 and CAN Bus is. All I can find is RS-485 is a physical layer and CAN Bus is a logical protocol. I'm guessing CAN Bus often uses a RS-485 physical layer.

You are right... RS-485 only covers the Physical Layer of the OSI Layer Model. CAN covers both the Data Link and offers several options for the Physical Layer. https://www.can-cia.org/can-knowledge/

MarkusXL Posted at 9-8 14:26
Just FYI here is the data sheet for the S1 quad core ARM CPU:

http://phonedb.net/index.php?m=processor&id=576&c=leadcore_innopower_lc1860c&d=detailed_specs#section12

Are you referring to the processor in the Interface Module, or that in the Intelligent Controller?

The Interface Module does not use a multi core ARM Cortex A7, but a ARM Cortex M7 single core processor...
https://www.nxp.com/part/MIMXRT1021CAF4A

rhoude57 - YUL Posted at 9-8 15:14
Are you referring to the processor in the Interface Module, or that in the Intelligent Controller?

The Interface Module does not use a multi core ARM Cortex A7, but a ARM Cortex M7 single core processor...

He's referring to the Intelligent Controller.
I've added a list of identified components to my Hackaday IO Project Details page.
https://hackaday.io/project/167276/details/
Hopefully clickable link.
I'm hoping people will let me know which components I'm missing. I'd also like to be corrected if there are errors in the list.
I've included some "easier to solder" options in case anyone what's to try experimenting with these parts in their own projects.
I still don't understand why there are so many parts with a 1Mbps limit using a 2Mbps signal. I hope someone verifies my baud readings as a sanity check.

As albertr suggested, the motor bus does NOT use a normal CAN Bus protocol. There are many instances of nine low bits in a row which occurs when the transmitted byte equals zero. Nine low bits occurs when the start bit and the eight data bits combine to form nine low bits in a row. Likewise nine high bits occur when the value 255 if transmitted followed by a stop bit. There are NOT any instances of sequences of more than nine low or high bits other than when the line is idle. As I understand it a CAN bus message shouldn't have more than five sequential identical bits (other than the end of message indicator).
As I previously mentioned, each motor bus message begins with 85 (0X55 hex or the character "U"). This value allows the receiving microcontroller to identify the baud.
I looked at five sequential messages. The first 7 bytes of the "request" message were all identical (listed in hex). 0X55, 0X16, 0X00, 0X9D, 0XA0, 0X00, 0X00. The eighth byte rotated through four values. The four possible values of the eighth bit were 0, 1, 2 and 3. I think it's reasonable to assume the eighth bit is the ID of the motor to which the request is directed. The request is 22 bytes in length. The replies appear to be 32 bytes. There's about a 90us delay between the request and the reply. The reply is made at a slightly different bit rate than the request. There's close to a two millisecond delay between the end of the reply and the next request. The start of each request appears to be spaced apart at 2.5ms intervals (give or take a few microseconds).
The requests are sent using 921.6Kbps. The replies are sent at near 947Kbps. I don't know if all the motors use the same baud but measuring ten bits is somewhere between 10.54 and 10.58us. This range of timings gives a range of bauds from 945.2Kbps to 948.5Kbps. I don't know if this difference is actual or a measurement error. In either case, I think using 947Kbps should be close enough to the actual baud that a microcontroller should be able to cleanly read a 32 bit reply.
I'll likely try using the idle time between messages as an indicator as to which baud to use. If the idle time was over 1ms, I'll use 921.6Kbps, otherwise I'll assume the data should be received at 947Kbps. I'll need to rework the assembly section of a fast UART driver to do this. I think this will be easier than trying to implement an auto baud detection algorithm.
Once I can reliably read the data, I'll need to decipher what the data means. As I mentioned earlier, I'm pretty sure the 8th byte of the request is the ID number. I'm hopeful the rest can be decoded using python programs to change parameters of interest.

Duane Degn Posted at 9-8 17:54
As albertr suggested, the motor bus does NOT use a normal CAN Bus protocol. There are many instances of nine low bits in a row which occurs when the transmitted byte equals zero. Nine low bits occurs when the start bit and the eight data bits combine to form nine low bits in a row. Likewise nine high bits occur when the value 255 if transmitted followed by a stop bit. There are NOT any instances of sequences of more than nine low or high bits other than when the line is idle. As I understand it a CAN bus message shouldn't have more than five sequential identical bits (other than the end of message indicator).
As I previously mentioned, each motor bus message begins with 85 (0X55 hex or the character "U"). This value allows the receiving microcontroller to identify the baud.
I looked at five sequential messages. The first 7 bytes of the "request" message were all identical (listed in hex). 0X55, 0X16, 0X00, 0X9D, 0XA0, 0X00, 0X00. The eighth byte rotated through four values. The four possible values of the eighth bit were 0, 1, 2 and 3. I think it's reasonable to assume the eighth bit is the ID of the motor to which the request is directed. The request is 22 bytes in length. The replies appear to be 32 bytes. There's about a 90us delay between the request and the reply. The reply is made at a slightly different bit rate than the request. There's close to a two millisecond delay between the end of the reply and the next request. The start of each request appears to be spaced apart at 2.5ms intervals (give or take a few microseconds).

All this suggests DJI have their own proprietary protocol (perhaps somewhat loosely) based on the CAN bus protocol.  They just need to change a few bits on all ends of the bus hardware to do what they like, maybe even encrypt.  It would be a daunting task to reverse engineer.


Also, I suspect that if they want to, they could change the protocol with a firmware update.  Even revert it back to a pure CAN protocol if they want to open it up for us.

MarkusXL Posted at 9-8 18:36
All this suggests DJI have their own proprietary protocol (perhaps somewhat loosely) based on the CAN bus protocol.  They just need to change a few bits on all ends of the bus hardware to do what they like, maybe even encrypt.  It would be a daunting task to reverse engineer.

I'd be very surprised if it were encrypted.
As I mentioned earlier, it was pretty easy to pick out the ID values for each motor.
My guess is it's a protocol with similarities to the one used by Dynamixel.
The protocol likely includes an ID, message length, request type, data if applicable, and a checksum. Reverse engineering will likely be a bit tedious but as long as they used a common checksum algorithm, it shouldn't be too hard.

I agree with Duane that encryption is highly unlikely. I think the whole reason DJI went with this weird rs485 setup might be because they are using the cheapest MCUs in these motors which don't support CAN bus in hardware. Variable bit rate is rather weird, as it adds unnecessary complexity without clear benefits?

-albertr

I'll try to task my student son to write a code for autobaud rate detection on STM32 MCU (some of STM32's support autobaud in hardware).

-albertr

Duane Degn Posted at 9-7 15:08
One of several things I find puzzling is the microcontroller used in the hit detectors supports CAN up to 1Mbps yet I measure 2Mbps on the CAN Bus. Another thing which I find puzzling is the use of at least two different bit rates used on the M Bus. The following traces were taken by passing the M Bus differential pair through a RS-485 transceiver.
I've previously shared these images in this post.
https://forum.dji.com/forum.php? ... 8&page=1#pid1949641

you may also look https://bbs.dji.com/thread-227461-1-1.html

Duane Degn Posted at 9-8 17:54
As albertr suggested, the motor bus does NOT use a normal CAN Bus protocol. There are many instances of nine low bits in a row which occurs when the transmitted byte equals zero. Nine low bits occurs when the start bit and the eight data bits combine to form nine low bits in a row. Likewise nine high bits occur when the value 255 if transmitted followed by a stop bit. There are NOT any instances of sequences of more than nine low or high bits other than when the line is idle. As I understand it a CAN bus message shouldn't have more than five sequential identical bits (other than the end of message indicator).
As I previously mentioned, each motor bus message begins with 85 (0X55 hex or the character "U"). This value allows the receiving microcontroller to identify the baud.
I looked at five sequential messages. The first 7 bytes of the "request" message were all identical (listed in hex). 0X55, 0X16, 0X00, 0X9D, 0XA0, 0X00, 0X00. The eighth byte rotated through four values. The four possible values of the eighth bit were 0, 1, 2 and 3. I think it's reasonable to assume the eighth bit is the ID of the motor to which the request is directed. The request is 22 bytes in length. The replies appear to be 32 bytes. There's about a 90us delay between the request and the reply. The reply is made at a slightly different bit rate than the request. There's close to a two millisecond delay between the end of the reply and the next request. The start of each request appears to be spaced apart at 2.5ms intervals (give or take a few microseconds).

you may also look  https://bbs.dji.com/thread-227461-1-1.html

g1107 Posted at 9-9 01:15
you may also look  https://bbs.dji.com/thread-227461-1-1.html

Thank you for the link to the other forum post.
As I mentioned earlier, the motor bus uses one start bit, eight data bits and one stop bit. The start and stop bits line up correctly across an entire message.

Drifting baud rate in responses sent from M3508I motors - maybe MCU used there are not even fast enough to do 961KBaud reliably? That might explain different baud rate weirdness...
It would be interesting if someone can get a hold of extra motor and show us what it has inside.

-albertr

albertr Posted at 9-13 11:51
Drifting baud rate in responses sent from M3508I motors - maybe MCU used there are not even fast enough to do 961KBaud reliably? That might explain different baud rate weirdness...
It would be interesting if someone can get a hold of extra motor and show us what it has inside.

"what it has inside"
I've removed the c-clip from one of the motor's shaft and I still haven't had any luck getting it open.
There are three small fasteners inside the threads on cable side of the motor. These fasteners can rotated using the small hex tool which came with the S1. While the fasteners appear to move, they don't come out.
Removing the c-clip didn't have any noticeable effect on the motor. I can not pull the two parts apart. I'm starting to wonder if they can be opened non-destructively.

albertr Posted at 9-13 11:51
Drifting baud rate in responses sent from M3508I motors - maybe MCU used there are not even fast enough to do 961KBaud reliably? That might explain different baud rate weirdness...
It would be interesting if someone can get a hold of extra motor and show us what it has inside.

"maybe MCU used there are not even fast enough"
What's odd is the motor replies use a faster baud than the requests. The request use 921.6Kbps. The replies are sent at a faster 947Kbps.
I'm not positive, but I'm reasonably sure what I'm calling "requests" come from the Motion Controller. Again the requests use 921.6Kbps.
I need to put my S1 back together so I can resume communication experiments.

Ah, sorry I should have read your posts better. So motor's baud rate is faster than the motion controller's. Could it be some really large error the motor's MCU have when calculating the baud rate based on it's own clock frequency?

-albertr

albertr Posted at 9-13 20:17
Ah, sorry I should have read your posts better. So motor's baud rate is faster than the motion controller's. Could it be some really large error the motor's MCU have when calculating the baud rate based on it's own clock frequency?

-albertr

"error the motor's MCU have when calculating the baud rate based on it's own clock frequency?"
That sure seems reasonable until you think about the MCU receiving the the other signal.
I think it's easier for a microcontroller to precisely send signals than to precisely receive signals.
I've written a few assembly UARTs and sending asynchronous data is always a lot easier than receiving asynchronous data.
I know there are plenty of microcontrollers which have a very limited number of bit rates available for their UARTs. I'd think the limited number of bit rates would apply to both receiving and sending so I'm still confused why the motors' baud is different than the Motion Controller's baud.
I'm hoping to have time to working on communicating with the motors this weekend. I just finished putting my S1 back together enough to test it.
I sure wish I could figure out how to open the motor without damaging it. I've opened many other brushless motors in the past but this has me stumped.
I was prepared to replace the C-clip since those often get mangled when removed. The play in the axle didn't change a perceptible amount after the C-cllip was removed (and mangled). The motor behaved as if the C-clip wasn't even needed.

I got some data from 4 motors on the static.it's Repeated.
motors Tx
ID0
0xAA,0x68,0x00,0xB9,0x05,0x00,0x00,0x00,0x00,0x02,0x00,0x02,0x00,0x02,0x00,0x02,0xFF,0xFF,0xFF,0xFF,0xA1,0x8E
ID2
0xAA,0x68,0x00,0xB9,0x05,0x00,0x00,0x80,0x00,0x02,0x00,0x02,0x00,0x02,0x00,0x02,0xFF,0xFF,0xFF,0xFF,0x14,0x2E
ID1
0xAA,0x68,0x00,0xB9,0x05,0x00,0x00,0x40,0x00,0x02,0x00,0x02,0x00,0x02,0x00,0x02,0xFF,0xFF,0xFF,0xFF,0xFB,0x5E
ID3
0xAA,0x68,0x00,0xB9,0x05,0x00,0x00,0xC0,0x00,0x02,0x00,0x02,0x00,0x02,0x00,0x02,0xFF,0xFF,0xFF,0xFF,0x4E,0xFE

I guess this is the crc16 check, but it has not been tested successfully.

g1107 Posted at 9-14 00:37
I got some data from 4 motors on the static.it's Repeated.
motors Tx
ID0

The data I'm getting looks very different.

I converted my logic analyzer capture to some text and get the messages shown below:

The "Request" and "Reply" headings are assumptions on my part.

Request to motor #0, 22 bytes
0x55, 0x16, 0x00, 0x9D, 0xA0, 0x00, 0x00, 0x00, 0x00, 0x00, 0xB9, 0x3E, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xA0, 0x16

Reply from motor #0, 32 bytes
0x55, 0x20, 0x00, 0x1A, 0xA0, 0x01, 0x00, 0x00, 0x6B, 0x2D, 0xEF, 0xFF, 0x70, 0x01, 0xFE, 0xFF, 0x00, 0x00, 0x1E, 0x01, 0x50, 0x00, 0x44, 0x03, 0xE9, 0x48, 0x00, 0x00, 0x00, 0x00, 0xC2, 0x6C

Request to motor #1, 22 bytes
0x55, 0x16, 0x00, 0x9D, 0xA0, 0x00, 0x00, 0x01, 0x00, 0x00, 0xB9, 0x3E, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0x0D, 0x13

Reply from motor #1, 32 bytes
0x55, 0x20, 0x00, 0x1A, 0xA0, 0x01, 0x01, 0x00, 0xE1, 0x2C, 0xC2, 0x00, 0x67, 0x01, 0xD4, 0xFF, 0xB9, 0xFE, 0x20, 0x01, 0x50, 0x00, 0x3B, 0x06, 0xE9, 0x48, 0x00, 0x00, 0x00, 0x00, 0xA8, 0x59

Request to motor #2, 22 bytes
0x55, 0x16, 0x00, 0x9D, 0xA0, 0x00, 0x00, 0x02, 0x00, 0x00, 0xB9, 0x3E, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFA, 0x1D

Reply from motor #2, 32 bytes
0x55, 0x20, 0x00, 0x1A, 0xA0, 0x01, 0x02, 0x00, 0x69, 0x2D, 0xF3, 0x00, 0x68, 0x01, 0x01, 0x00, 0x00, 0x00, 0x22, 0x01, 0x50, 0x00, 0x42, 0x03, 0xE9, 0x48, 0x00, 0x00, 0x00, 0x00, 0xA1, 0x19

Request to motor #3, 22 bytes
0x55, 0x16, 0x00, 0x9D, 0xA0, 0x00, 0x00, 0x03, 0x00, 0x00, 0xB9, 0x3E, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0x57, 0x18

Reply from motor #3, 32 bytes
0x55, 0x20, 0x00, 0x1A, 0xA0, 0x01, 0x03, 0x00, 0x32, 0x2D, 0x42, 0x00, 0x61, 0x01, 0x03, 0x00, 0x00, 0x00, 0x1C, 0x01, 0x50, 0x00, 0x56, 0x03, 0xE9, 0x48, 0x00, 0x00, 0x00, 0x00, 0x55, 0xCA

The requests all look nearly identical except for the ID and what I assume is the checksum.
There are other requests which change slightly as the command to change one of the motor's speed is sent.

How are you determining if a message is from the Motion Controller vs a motor? Aren't the two data lines a pair of balanced RS-485 signals?

I realize I haven't looked at the motor bus with my oscilloscope to confirm it's RS-485. I've just assumed it was as use a RS-485 chip to convert the signal to 3.3V.

Again, I'm not sure I'm capturing this data correctly. I just thought I'd share what I'm trying to figure out.

I should add, the above data was captured while running the following program: (Sorry, I couldn't see a way to format code.)
variable_motorSpeed = 0
def start():
    global variable_motorSpeed
    robot_ctrl.set_mode(rm_define.robot_mode_free)
    while True:
        variable_motorSpeed = 20
        chassis_ctrl.set_pwm_value(rm_define.pwm1, 8)
        chassis_ctrl.set_wheel_speed(variable_motorSpeed,0,0,0)
        time.sleep(0.5)
        variable_motorSpeed = 40
        chassis_ctrl.set_pwm_value(rm_define.pwm1, 9)
        chassis_ctrl.set_wheel_speed(variable_motorSpeed,0,0,0)
        time.sleep(0.5)
        variable_motorSpeed = 0
        chassis_ctrl.set_pwm_value(rm_define.pwm1, 7.5)
        chassis_ctrl.set_w


I think the data captured was sent during the "variable_motorSpeed = 20" portion of the program but I'm not sure about this.

Duane Degn Posted at 9-14 11:02
I should add, the above data was captured while running the following program: (Sorry, I couldn't see a way to format code.)
variable_motorSpeed = 0
def start():

Thanks for sharing all your discoveries.
I think the following article may answer a lot of your questions regarding the protocol, data exchange and the timing issues you have encountered so far.
https://en.wikipedia.org/wiki/CAN_bus#Nodes

Also, I found the collection of video tutorials from Kvazer interesting. Two of those tutorials focus on CAN Bus. The CAN Protocol Tutorial includes a description of FD CAN.
https://www.kvaser.com/e-learning/

rhoude57 - YUL Posted at 9-14 12:18
Thanks for sharing all your discoveries.
I think the following article may answer a lot of your questions regarding the protocol, data exchange and the timing issues you have encountered so far.
https://en.wikipedia.org/wiki/CAN_bus#Nodes

The black wire CAN Bus likely uses the CAN protocol but the Motor Bus does not.
It's using RS-485 as a physical layer but it's formatting the data is normal serial 8-bit asynchronous serial. Each byte is sent using a total of 10 bits. Each byte has one start bit and one stop bit.
Here's a capture of a small section of data which shows the start and stop bits are very regular intervals.

Duane Degn Posted at 9-14 14:11
The black wire CAN Bus likely uses the CAN protocol but the Motor Bus does not.
It's using RS-485 as a physical layer but it's formatting the data is normal serial 8-bit asynchronous serial. Each byte is sent using a total of 10 bits. Each byte has one start bit and one stop bit.
Here's a capture of a small section of data which shows the start and stop bits are very regular intervals.

It does look like its running of a UART instead of the CAN Bus transceiver. This is a decision DJI might have made for cost reasons.
On the scope, can you pick up the sync frame in front of each message being sent, especially given that the  Motor Controller board and Motors do not seem to be running at the same clock speed?
Also, there has to be some sort of arbitration scheme similar to that used by the CAN Bus Protocol to ensure all Motor Bus nodes don't drown themselves in each other's transmissions.
I had an opportunity to pick up an oscilloscope a little while back, but had no use for it at the time. Looks like it's time I go back and check if it's still up for grabs...

rhoude57 - YUL Posted at 9-14 14:44
It does look like its running of a UART instead of the CAN Bus transceiver. This is a decision DJI might have made for cost reasons.
On the scope, can you pick up the sync frame in front of each message being sent, especially given that the  Motor Controller board and Motors do not seem to be running at the same clock speed?
Also, there has to be some sort of arbitration scheme similar to that used by the CAN Bus Protocol to ensure all Motor Bus nodes don't drown themselves in each other's transmissions.

"there has to be some sort of arbitration scheme"
I'm pretty sure the motors only reply when a requests is initiated by the Motion Controller.
It looks like the Motion Controller cycles through the four motors every 10ms.

Above is an overview of 6 of these full cycles. You can see the relatively long (1.8ms) idle states between each motor's communication. There's a smaller (about 0.1ms) idle state between the request and the motor's reply. You can see a zoomed in exchange in post #3. In post #3 I was treating the message as a CAN packet so the translated data doesn't line up properly with the bytes.

"opportunity to pick up an oscilloscope"
I have a Rigol DS1054Z. I used it to confirm the CAN Bus used differential signals. It was pretty cool the see the signal so clearly on the screen.
While the oscilloscope is useful at times, I use my logic analyzer much more frequently than the oscilloscope. I have a couple Saleae logic analyzers but it's possible to get inexpensive clones for much less money.
The logic analyzer traces I've shared, are taken from the output of a RS-485 chip I had handy from another project.

Duane Degn Posted at 9-14 15:43
"there has to be some sort of arbitration scheme"
I'm pretty sure the motors only reply when a requests is initiated by the Motion Controller.
It looks like the Motion Controller cycles through the four motors every 10ms.

Have you tried to do the "Wheel Addressing" routine with the logic analyzer hooked up? That should be interesting to see happening and analyze.

Duane Degn Posted at 9-14 15:43
"there has to be some sort of arbitration scheme"
I'm pretty sure the motors only reply when a requests is initiated by the Motion Controller.
It looks like the Motion Controller cycles through the four motors every 10ms.

It's interesting to see that the RM S1 development team opted to forgo an arbritation scheme and simply set-up a Command/Response protocol on the Motor Bus. Again, this would simplify the hardware logic needed to pass and pull commands and data from that Bus.
It may also explain the logic as to why the Bus was called M-Bus instead of CAN Bus.

Duane Degn Posted at 9-14 10:55
The data I'm getting looks very different.

I converted my logic analyzer capture to some text and get the messages shown below:

Maybe you ignored the removal of the start and stop bits.

g1107 Posted at 9-14 17:45
Maybe you ignored the removal of the start and stop bits.

"Maybe you ignored the removal of the start and stop bits."
This was a problem with the traces I posted in comment #3 but I think the traces shown in comment #39 treat the start and stop bits correctly.
The IDs are show in the 8th byte of the requests and the 7th byte of the reply. This gives me some confidence the bits are being converted to bytes correctly.

Duane Degn Posted at 9-14 18:45
"Maybe you ignored the removal of the start and stop bits."
This was a problem with the traces I posted in comment #3 but I think the traces shown in comment #39 treat the start and stop bits correctly.
The IDs are show in the 8th byte of the requests and the 7th byte of the reply. This gives me some confidence the bits are being converted to bytes correctly.

I measured the tx and rx of the M3501 using an oscilloscope, not can h and can l。

Duane Degn Posted at 9-14 18:45
"Maybe you ignored the removal of the start and stop bits."
This was a problem with the traces I posted in comment #3 but I think the traces shown in comment #39 treat the start and stop bits correctly.
The IDs are show in the 8th byte of the requests and the 7th byte of the reply. This gives me some confidence the bits are being converted to bytes correctly.

I‘m so sorry. I found that I had an error in extracting data.

Duane Degn Posted at 9-14 10:55
The data I'm getting looks very different.

I converted my logic analyzer capture to some text and get the messages shown below:

You're right!I found that I had an error in extracting data.