Help decoding unique protocol of a toy robot

An area for more general discussion by the user community for topics not covered elsewhere
dunderMethod
Posts: 8
Joined: Sun Mar 13, 2022 12:15 am

Re: Help decoding unique protocol of a toy robot

Post by dunderMethod »

Assuming the above interpretation is correct, I wrote this Jupyter Notebook that accepts an AnalysIR session history and parses all of the bursts into HEX values. It seems like I'm getting believable results. I'll explore further tomorrow.
Decoding_Botley_IR.zip
Thanks again for your help!
You do not have the required permissions to view the files attached to this post.

User avatar
AnalysIR
Site Admin
Posts: 742
Joined: Sat Aug 31, 2013 3:51 pm
Location: Dublin, Ireland
Contact:

Re: Help decoding unique protocol of a toy robot

Post by AnalysIR »

looks like you have it sorted OK

Additional comments:
- to be on the safe side you can use +/-200uSecs on any value to determine if it matches a particular value. This accounts for the specs of IR receivers (up to +/-200uSecs on a mark or space)
- Without having the original specs it is not possible to know the bit order (MSB,LSB,LSB8). So a value of 03 A4 could be CF 25 (or 25 CF). Knowing this may help in reverse engineering the bit fields). Support for this is included in AnalysIR, but would be messed up in your case with the missing bit.
- It is also possible that a 1 could be 0 and vice-versa

dunderMethod
Posts: 8
Joined: Sun Mar 13, 2022 12:15 am

Re: Help decoding unique protocol of a toy robot

Post by dunderMethod »

Thanks for the tips, I'll deff keep those in mind.
I'm going to drop some notes here from my analysis today, for posterity.

Here are my notes on decoding Botley's raw IR signals so far:

Code: Select all

Anatomy of a single burst of data:
SS MMMMMMM S M SS M SS M SS M SS M SS M SS M SS M S M S M S M S M S M S M S M S M SSSSS
__|-------|_|-|__|-|__|-|__|-|__|-|__|-|__|-|__|-|_|-|_|-|_|-|_|-|_|-|_|-|_|-|_|-|_____
  [HEADER][0    1    1    1    1    1    1    1 ][0   0   0   0   0   0   0   0  ]
Decoded HEX:          byte_1: [7F]                          byte_2: [00]

rules = {'header': 4150, 'mark': 642, 'space0': 1284, 'space1': 642, 'bits': 16, 'delta': 200, 'quiet': 5000, 'carrier': 38000}
A message is any transmission sent from the remote to the robot.
A message is composed of bursts with long silence between: Message = [burst_1]......[burst_2]......[burst_n]......
A burst is composed of [M]arks and [S]paces which make up: [header, byte_1, byte_2]
for a total of 16 bits of data per burst, not including the header.
A Burst begins with a header which is just a long Mark (~ Mark * 6.5)
Each bit, following the header, is composed of some space followed by a constant-width Mark.
The length of the space determines the binary value.
The marks are basically just delimiters, we don't really care about them.
The length of a space can either be Mark*1 = binary 0, Mark*2 = binary 1, > Mark*3 = end of burst
In reality, we have a +/- 200us tolerance on the length of marks and spaces. 
So when I use my decoder I am able to spot some patterns:

Code: Select all

In most cases, the first 3 bytes in a message are the same value repeated
and across most messages the first 8 bytes are the same, Is this the preamble?
-----
0: send_L4_F_R4_L9_B_R9 | 1: clear | 2: light
Byte  0     1     2 |    3     4     5     6     7 |    8     9    10    11    12    13
0  BF00  BF00  BF00 | 82B1  82B2  82B3  82B4  82B5 | 8501  8102  8603  8304  8205  8406
1  BF00  BF00  BF00 | 82B1  82B2  82B3  82B4  82B5 | 9601  9601
2  BF00  BF00  BF00 | 82B1  82B2  82B3  82B4  82B5 | 9901  9901
Looking back at the data I extracted from the EEPROM I notice more patterns:

Code: Select all

Extracting the data we care about:
-----
When I dumped the remote's EEPROM I found the DEC values which correspond with the direction buttons
Looking at the IR HEX packets I find the same values in the 18th bit. I've found the direction commands in IR!

Direction button to EEPROM val:  Direction sequence sent over IR:
Command    Normal      OD_on  |  0: send_L4_F_R4_L9_B_R9
FWD        1           9      |  Byte   ...6     7 |  L4  8    F  9   R4 10   L9 11    B 12   R9 13
BCK        2           10     |  0   ...82B4  82B5 | 8>5<01  8>1<02  8>6<03  8>3<04  8>2<05  8>4<06
L9         3           11     |
R9         4           12     |  So it also looks like the "8" could mean "this is a direction command"
L4         5           13     |  and the numbers following seem like a simple index
R4         6           14     |
I'm open to any thoughts or tips from anyone!

User avatar
AnalysIR
Site Admin
Posts: 742
Joined: Sat Aug 31, 2013 3:51 pm
Location: Dublin, Ireland
Contact:

Re: Help decoding unique protocol of a toy robot

Post by AnalysIR »

Thanks for posting the details & hopefully it will benefit others in future. :)

Post Reply