Need a little help revers engineering a kinda unknown protocol

[rantwhy]

Hello everyone,

I'm trying to listen and talk to some Panasonic equipment that uses RS485.

The transmitter is a AW-RP400 pan/tilt control panel and the receiver is a AW-PH360N Pan tilt head.

The PH360N is just a pan/tilt head without a camera. My goal is to attach a new Sony or Panasonic 4K camera to this mount and control the camera by Lanc control.

I would like to make a device that connects between the controller and the Pan/ tilt head. That listens for the zoom and focus commands that are normally sent to a attached camera.

                                         
Inside the controller is a (Step Technica MKY40) chip (Im assuming its the controller)   that is connected to a (ADM148) chip (this is the output driver ) so I know the output is a RS485.

The MKY40 brochure talks about having a  CUnet communication that runs at (Communication rate   3/6/12 Mbps (half duplex)) The ADM148 can talk at a maximum rate of 30 Mbps.

So I know the communication rate is somewhere between 3 and 12Mbps.

On the receiving end. The (AW-PH360N) Pan/tilt head has a (MAX1482) chip this has a max data rate of 250kbps


what Iv done so far, I have connected a (MAX485) in line between the 2 devices and then connected to my logic analyzer (dream source lab 16 channel )

I have just the controller connected at the moment otherwise there is a lot of chatter on the line.

What I see with just the controller connected is what Im assuming is a "ARE U THERE?" message  that is 128μs long. And has a 18.365ms gap between the messages.

The shortest pulse is 1μs with a 2μs period. Just after the beginning there is a 3μs pulse with a 7μs period as the largest pulse and at the end a 5μs pulse with a 6μs period.

First I am trying to find that data rate.
From what Iv read online. And I could be wrong you measure the smallest pulse width which is 1μs and multiply it with 10 to the power of 6 = 1,000,000.

so would that mean the data rate is 1Mbps?

My questions for everyone is.

Is there a way of determining if this is a common used protocol? And how would I go about using a Arduino to decode and make use of the chit chat on the line?

Basically I would like to convert whatever the AW-RP400 is talking to Lanc or use servos to control a camera.

Below is a screen shot of the logic analyzer receiving the AW-RP400 data.

Thanks!

[PA0PBZ]

This should help: https://eww.pass.panasonic.co.jp/pro-av/support/content/guide/DEF/HE50_120_SERIAL/ConvertibleProtocol.pdf

[robca]

Might also find something useful here https://na.panasonic.com/ns/268725_Summary_of_PRO_PTZ_Camera_Control_Protocols.pdf

I used to have an old Panasonic PTZ camera (CS854), and it was not hard to find the Panasonic protocol documentation. You might also want to phone the closest authorized Panasonic service center, they usually have all the manuals (in my case, they sold me the repair manual for the CS854 at a nominal price)

[rantwhy]

Thank you for this information.  I have tried to use my logic decoder to look at the signal. However the 9600 baud listed in the links seems to be too slow of a bit rate. Here is a picture of what I see in my logic software. 

[PA0PBZ]

Can you measure the precise duration of the smallest pulses that looks like 1uS?

[rantwhy]

yes its 1uS

[PA0PBZ]

yes its 1uS

Then the bit rate is 1Mbps, not sure how that works with the MAX1482 though. Can you try to decode on 1Mbps 8 bits 1 stop bit?

[Berni]

Yep measuring the width of the shortest pulse and dividing 1 with it gives you the baud rate so  indeed 1Mbit.

Next you just play around with the settings of your UART until you get something that looks right. Start with the classic 1 stop bit no parity and work your way up to 2 stop bits with or without parity, 9 bit mode etc... This is the easiest to do on a scope with serial decode since the decoder will tell you if the signal does not make sense (it detects missing stop bits, false pairity etc..) But you can just do it by trial and error if you have some idea what to expect in there.

[rantwhy]

I think we are on the right track.

We still have some errors but I'm wondering if this is normal and acceptable ?

[Berni]

Does it say what is wrong with it?

It happens during a low period so it is probably something and it might have shifted all of the data that comes after it over.

[PA0PBZ]

Can you invert the input?

[brucehoult]

RS-485 only specifies the physical layer, not the communications protocol. It does look though that that camera control stuff uses a standard asynchronous format for individual bytes.

An AVR-based Arduino would have great difficulty to decode a 1 Mbps signal by bit-banging (I'd like to say impossible). So you'll need a UART set for the appropriate bit rate and protocol. Once it's done that, no problem for an interrupt handler to grab a byte from the UART buffer and stuff it into a larger RAM buffer. You can use standard Arduino code to deal with it after that.

[rantwhy]

My logic software dose not give me any further detail what is wrong is just said frame error and UART warning. Berni

I have flipped my probes coming out of the MAX485 I'm using to capture the signal. PA0PBZ 

So would this mean I need to use a Pi to handle the incoming signal? Also when you say standard asynchronous format, are you saying It is something that has good documentation on how its working and what all the values and timings are? brucehoult

If that is the case I mind doing this in python.   

Thanks.

[Berni]

You just need to look at it for long enough to find patterns.

Fine here it is:

This is what a full UART frame looks like. You can't start if you don't even know what you are looking for

Now since all this stuff is optional on UART we first must find how long a frame is. This is easily done by overlaying the beginings of two frames with different data because the start and stop bits must always be the same:

Notice where they match up for a low and then a high. marked these off with a green and yellow marker so i can find them later

Now we need to count the bits between them, so we use this rapidly toggling area to easily see where the bit transitions are:

So we can see that the stop bit is only high for 1 cycle and looking at the diagram above we can see that means its using 1 stop bit.
Then we can count out how many bits are inside the frame and we end up with 10 so this can only mean that it is using 9bit data with parity.

No electronics knowledge required. Just googling what UART looks like and then pattern matching that with the waveform. It could be done on paper, but i like to do it with photoediting software because its faster.

[brucehoult]

Also when you say standard asynchronous format, are you saying It is something that has good documentation on how its working and what all the values and timings are? brucehoult

By "standard asynchronous format" I mean that each byte of data is sent as:

- a start bit
- 7 or 8 data bits
- possibly an even or odd parity bit
- one or more stop bits

i.e. something that can be described by the familiar (well for those who were awake in the 80s and 90s) "8N1", "7E1" etc notation for asynchronous serial communications. You can buy a UART chip, program those values into its configuration registers, and it will decode the bits and present your Arduino with 7 or 8 bits of data on some digital IO pins (and trigger an interrupt when it has one, if you want).

This says nothing at all about what the bytes of data will contain.

[rantwhy]

Thank you for the information everyone unfortunately I have some bad news the controller has given up the ghost. The power supply has a problem with the 7 and 5 volt rails now so I will try to get it back up and running but for now I cant move forward with this current part of the project. Thanks again for the help thus far.   

[rantwhy]

So im back I have bought a new controller YAY...  I have looked around and found a pdf talking about the chip and I think the controller and Pan/Tilt head are using memory share mode. below is a link to the pdf. From what I read it seams like the documentation just talks about how to talk to the chip from the cpu side but not about the protocol. I dose mention that it is indeed RS485 based.

 Is it possible that this chip dose not use standard 1 start bit 1 stop bit, parity and data bits, Like in a normal serial communication? 

[rantwhy]

https://www.steptechnica.com/en/products/04_ic/mky40/download/STD-CU40-V2.5E.pdf

[Berni]

Just did a bit of googling of what that protocol is and among the first results is this
https://www.sentronic.com/frontend/scripts/download.php?localname=CUnet-InstallationGuide-V1.0-EN.pdf&netname=..%2F..%2Febusiness%2Ffilesharing%2Fwysiwyg_download%2FAutomation%2FKommunikation-Netzwerk%2FCUnet-InstallationGuide-V1.0-EN.pdf

So on Page 10 Section 4.1 it explains its using Manchester encoding.