Help Figuring Out Undocumented RS-485 Half-Duplex Protocol

[K1JOS]

I am a old 'newbie' and hope I am not providing too much info so apologies in advance.

 I have a motor control PCB for a 12vdc 8A antenna rotor.  Two momentary switches control motor power and direction, clockwise (+12vdc) and counterclockwise (-12vdc) switching via two HEXFET Power MOSFET's.  I dont know the details but the control PCB has a PIC18F and is designed to also sense motor current draw and if it exceeds a certain threshold (like motor lockup) it shuts off power to motor.

There is a hardwired hand remote on 20' unshielded cable (4 wire: 5v, GND, A, B) which has the two momentary switches.  It also has a PIC18F and MAX483 on a small PCB.  The main control PCB also uses a MAX483 to communicate with the hand remote. My goal is to replace the hardwired hand remote with a Moteino (Arduino + RF xcvr) wireless transceiver being controlled from a distant site.  I need to understand the RS485 packet and handshaking protocol being used in order to replicate it with my Moteino hardware.

I have scoped and decoded (with a borrowed differential probe) the packets between the remote and the control PCB.  My key findings are:
1) control PCB unattached from remote sends out a 'heartbeat' packet to the RS485 bus every  4.8msec (4800 baud), 8 bit, No parity, no XON/OFF code found
2) the packet (hex) is: 02 88 31 00 04
3) the remote alone (powered by 5vdc) will not put anything on the RS485 unless the control PCB heartbeat is on the bus
4) when control PCB and remote are both on bus and no switches being pressed, the control packet (decode same) transmission rate appears to jump to 9600 and following each heartbeat packet it seems the remote replies with the same packet about 16 msecs after control packet.  With both on the bus they are both sending packets at 9600 (screen shots attached below).
5) When the motor switches are pressed on the remote the packets remain identical except the 00 is replaced by either 06 (clockwise switch) or 08 (counterclockwise switch).  BOTH control packet and remote packet now have either the 06 or 08  until switch is released and then it goes back to 00

My take on this is the handshaking protocol is the packet content itself.  The control PCB listens for short time after it sends heartbeat.  If remote is on line the remote sends back same packet unless one of switches is pressed in which case it changes one of the packet bytes to send. The control PCB accepts that one of these two new bytes is acceptable and sends that new packet back to the remote.  The remote double checks to verify that the control PCB received it's last packet correctly.

My skepticism is that this seems like a lot of overdesign for a simple two switch motor hand remote controller.
Nevertheless, does this seem like the most reasonable interpretation of my findings?  Should I be checking anything else out or should I go straight to trying to replicate the remote with my own Arduino/MAX483.  Can I do any harm to the control PCB if my assumptions are wrong?

[fcb]

I'd be very surprised if the inventor changes the baud rate as you appear to have found. Use the scope to determine either the smallest bit of data or time the length of a byte to determine the data rate - if you find a slight anomaly in the speed, check the xtal speed and reverse engineer the baud rate from the PIC datasheet.

Also, I'd probe the data on the uC side of the MAX483, it won't require a diff. probe then.

[K1JOS]

thank you FCB, you are 100% correct !!  The narrowest bit width for all circumstances remains around 100usec so 9600 baud in all cases.  I must have messed up my scope box counting... the packet (not sure if I'm using the correct term) frequency of the controller PCB is about about 9 packet/sec.  The remote packet frequency is exactly the same but delayed by 16 msec.

Does that make sense??

[fcb]

The exact make-up of the protocol is up to you to figure out, however it is likely to be a pretty basic sort of thing:

slave only speaks when spoken to..
slave always responds with current keypress data..

If this is the case, all the 485 bus is doing is extending the buttons, however it might be more complex (does the master embed rotation posistion, motor current, etc... in the data for a more advanced version with a display?)

[KK]

Wire up your arduino through a max 483 and connect it to the master. Sniff the data through the arduino and let the max483 handle the bus protocol. Switch it around and connect to the slave and have your arduino put out the heartbeat then sniff the responses.

[K1JOS]

I have been checking this out on the worknbench.  I should hook the motor load up and see if the packet decode changes

many thanks to all.

[fcb]

Wire up your arduino through a max 483 and connect it to the master. Sniff the data through the arduino and let the max483 handle the bus protocol. Switch it around and connect to the slave and have your arduino put out the heartbeat then sniff the responses.

MAX483 is purely handles the electrical side of the bus, not protocol.

[KK]

Wire up your arduino through a max 483 and connect it to the master. Sniff the data through the arduino and let the max483 handle the bus protocol. Switch it around and connect to the slave and have your arduino put out the heartbeat then sniff the responses.

MAX483 is purely handles the electrical side of the bus, not protocol.

Yes, I was suggesting to use it instead of a differential probe looking at signalling to just look at the bytes coming out of the MAX483 with time stamping to see the protocol. You can then write a slave or master emulator on the arduino and tweak until you get it reliable.

[fcb]

Also, I'd probe the data on the uC side of the MAX483, it won't require a diff. probe then.