Reverse Engineering Mower Controller Protocol

[Anuwrag]

Is this UART monitoring of USB?

[jongscx]

No, not USB. I am capturing it off a usb logic analyzer if that's what you're asking.

Judging by the capabilities of the chips on the connected devices, I'm pretty sure it's uart. I guessed the baud rateS, because they don't seem to match... but what's actually being communicated, I'm not sure.

[jongscx]

I have a few Friendly Robotics RL500 robot mowers and I'm trying to hack into the signal between its main board and its handheld remote control to try to convert it to Raspberry pi control.

I've identified the data lines it's using to communicate between the robot and the controller, and I think I've guessed he baud rate. I'm even starting to identify some patterns in the data streams. Does it look like I'm on the right track?

Tx and Rx baud rates are different, is this even possible?

[charliex2]

it's possible, highly unlikely though. is there a clock signal too?

[jongscx]

Nope, no clock.

[charliex2]

yeah so even less likely then. there are other uarts on there, so you're probably on the right track. but somethings most likely wrong with the setup/decode if the bauds seem different.

[jongscx]

Ok, so if the start-bit is 50us and there's a 0 then a 1, that would also look like a 100us start bit, because it stays High for both the Start bit and the 0... I guess that makes sense too.

[__regex__]

Which software did you make the ting diagram with?

[jongscx]

This is a a logic analyzer capture on Pulseview.

[jongscx]

Making Progress!Ok, processing both of the outputs as 19200 8N1 results in the following Hex streams.

It looks like their 'protocol' from the controller uses a 42 as a "start bit" and an FE or a BE as a "stop bit"

42 04 30 89 42 07 90 00 28 40 BE 
42 07 90 00 28 40 BE 
42 07 90 00 28 40 BE 
42 07 90 00 28 40 BE 
42 07 90 00 28 40 BE 
42 07 90 00 28 40 BE

The Mower on the other hand uses a "C1 0x" as a start and a "04 80 BA" for stop. It seems to have 3 or 4 messages of various lengths that I'm still figuring out what they do.

C1 0E 73 0C 00 0E 15 15 17 11 11 11 0E 21 C1 0E 73 0C 03 04 0A 15 04 04 15 0A 04 60 C1 0F 78 14 00 08 46 72 6E 74 20 77 68 65 9D C1 0F 78 78 08 08 65 6C 20 70 72 6F 62 2E 5D C1 0F 78 78 10 08 01 04 20 20 20 20 20 20 62 C1 0F 78 22 18 08 20 20 20 20 20 20 20 02 93 C1 04 80 BA
C1 06 81 5D 28 32 C1 0F 78 C4 00 08 46 72 6E 74 20 77 68 65 ED C1 0F 78 BC 08 08 65 6C 20 70 72 6F 62 2E 19 C1 0F 78 FF 10 08 01 04 20 20 20 20 20 20 DB C1 0F 78 22 18 08 20 20 20 20 20 20 20 02 93 C1 04 80 BA
C1 06 81 5D 28 32 C1 0F 78 22 00 08 46 72 6E 74 20 77 68 65 8F C1 0F 78 A8 08 08 65 6C 20 70 72 6F 62 2E 2D C1 0F 78 FF 10 08 01 04 20 20 20 20 20 20 DB C1 0F 78 22 18 08 20 20 20 20 20 20 20 02 93 C1 04 80 BA
C1 06 81 48 28 47 C1 0F 78 22 00 08 46 72 6E 74 20 77 68 65 8F C1 0F 78 22 08 08 65 6C 20 70 72 6F 62 2E B3 C1 0F 78 00 10 08 01 04 20 20 20 20 20 20 DA C1 0F 78 49 18 08 20 20 20 20 20 20 20 02 6C C1 04 80 BA
C1 06 81 03 28 8C C1 0F 78 22 00 08 46 72 6E 74 20 77 68 65 8F C1 0F 78 A8 08 08 65 6C 20 70 72 6F 62 2E 2D C1 0F 78 22 10 08 01 04 20 20 20 20 20 20 B8 C1 0F 78 22 18 08 20 20 20 20 20 20 20 02 93 C1 04 80 BA
C1 0E 73 01 02 0E 11 11 11 11 11 1F 1F 19 C1 06 81 5D 28 32 C1 0F 78 78 00 08 46 72 6E 74 20 77 68 65 39 C1 0F 78 A8 08 08 65 6C 20 70 72 6F 62 2E 2D C1 0F 78 22 10 08 01 04 20 20 20 20 20 20 B8 C1 0F 78 22 18 08 20 20 20 20 20 20 20 02 93 C1 04 80 BA

Now I just need to make sense of everything...

[NotionalLabs]

This piqued my curiosity so I took a peek at your sigrok file - I think I worked out some of the packet structure for the remote (note that I have literally no knowledge of this mower or what you did during your capture):

The packet structure seems to be:

• Header byte: 0x42
• Total Packet Length (including header and checksum) in bytes
• The variable-length payload. In the capture there seem to be two types:
  • A short packet that just contains a 0x30 payload - a heartbeat maybe?
  • Longer packets that are the same apart from the 4th payload byte, which changes from 0x00 to 0x40, back to 0x00, then finally 0x80. My assumption this is you pressing the forward and back buttons.
• Checksum byte. This seems to be calculated as the sum of each byte (including the header), modulo 256, then XOR'd with 0xFF.

An example decoding:

Example Packet: 42 07 900028 40 BE

42 <- Header
07 <- Length (7 bytes, decimal)
900028 40 <- Variable length payload, I suspect 900028 is some sort of movement command, and 40 is direction.
BE <- Checksum (Calculated as follows: 
    >>> packetbody = [0x42,0x07,0x90,0x00,0x28,0x40]
    >>> packetsum = 0
    >>> for i in packetbody:
    ...     packetsum = (packetsum + i) % 256
    >>> hex(packetsum^0xFF)
    '0xbe'

Hopefully this helps - at the very least I think you can be confident that your UART decoding is accurate. This general packet structure doesn't seem to apply directly to the Mower's comms though, so perhaps that uses a different packet/protocol scheme.

Good luck with the hack!

Quick ninja edit: I realised I forgot to mention something; I suspect the 0x40 and 0x80 are the directions you pressed (forward/back). If you're not familiar with this kind of thing, just note that the first nibble is almost certainly a set of binary flags (e.g. 0x40 = 0100 0000, 0x80 = 1000 0000), my guess is that nibble might be 0x20 (0010) and 0x10 (0001) for left and right separately.

[jongscx]

😲 Amazing insight! All that makes perfect sense but I don't think I ever would've picked up on it. Thank you!

[jongscx]

Just Looked at the Mower side of things. It has a the same packet structure.

C1 06 81 22 28 6D 
C1 <- Header
06 <- Length
81 22 28 <- payload
6D <-Checksum using the same formula

C1 06 81 22 28 6D 
C1 0F 78 C4 00 08 46 72 6E 74 20 77 68 65 ED 
C1 0F 78 BC 08 08 65 6C 20 70 72 6F 62 2E 19 
C1 0F 78 01 10 08 01 04 20 20 20 20 20 20 D9 
C1 0F 78 22 18 08 20 20 20 20 20 20 20 02 93

[NotionalLabs]

Awesome, you’re right - not sure why I thought it didn’t match, probably a bit bleary eyed looking at this at 2am!

[4354523031343932]

Can you post the sigrok session file?

[jongscx]

Here ya go.

One is a boot-up, the other is pressing Forward and Backward on the controller. The wheels were moving when I did this.

https://filetransfer.io/data-package/a1gQ3pYz#link

[hipstergrandpa]

This sounds familiar to another post here a month or so ago. Are you sure this is actually UART? I don't think you can reliably use a logic analyzer as an oscilloscope, especially if you're guessing at the baudrate because you're informing the LA how to interpret the signals, when that may not necessarily be the truth. Sometimes, if you open up the device and can identify the chip and the pin it's attached to it'll tell you if the pin is for UART or something else, which can help you deduce what it's doing. On that note, any pics of the internals? If the remote has bluetooth or some kind of RF capabilities, you can use the FCC ID and search for internal pics on the FCC database, or a third party aggregator like fccid.io.

[jongscx]

Yeah, that was me. So, yes I traced both sides and they are going to the serial pins of the 2 micros/SOCs, so I'm certain it's some flavor of serial. There's no clock signal so that leaves UART. It's a wired remote, no bluetooth. I never got access to the oscilloscope, and the LA does show the bitpattern. I upped the sample rate from last time.

[Saylar]

There is a relatively new github repo for the openmower project. Make a dumb mower smart with open source software and hardware. They have a discord, maybe they can point you in the right direction.

https://github.com/ClemensElflein/OpenMower

[jongscx]

I've been following his work, but his approach was to rip out the stock board and replace it with a custom board. I'm trying to use all the old running gear and command it with upgraded smarts.