Sony Protocol over wireless 562.500 baud (9bit)

[Wiljan]

Hi

I'm involved in a project where we need to control a Sony cam over a wireless RF link the video and audio does work fine but to be able
to control the camera the system does have a RS422 wireless link to allow the RCP using Sony protocol System 700

Witt a Sony RCP and the wireless link from VISLINK and a SONY cam it does work as expected

But the case here are we do use RCP from Telemerics due to some robotic cams and here it does work with the SONY cam (When on cable)

When using the Telemetric RCP over the wireless the control does not work and using a scope to see the protocol it's look like it constant try to reconnect properly due to different latency in the wireless system.

The Sony protocol clear tells that the baudrate are 562.500 bit/s and that the header does use ODD Parity and the Body use Even parity.

So right now the idea are to try to use like the moxa W2250A (a dual rs422 link which can work ad-hod so it will provide a clean wireless RS422 link (sure the will still be some latency).

The problem are it's not possible to set it for 9 bit data to send the "parity" transparent as the "9" bit.

I have an idea whee I could use a FPGA and receive the RS422 9 bit and the split it to 2 x RS422 8 bit and in the other end do the reverse 2 x RS422 8 bit to 1 x RS422 9bit ... sure there will be a little extra latency but I guess it might  work.

I'm open for suggestions??

Thank you

[ejeffrey]

That is certainly possible.  Even a small CPLD should be able to do that.  An ordinary microcontroller could do it too if you can find one that allows 9 data bits.  A really fast microcontroller might be able to keep up with that using bit-banging.

You will want to think carefully about the encoding in order to get a protocol that is self synchronizing.

Do you need dual links?  That is a lot of extra complication.  Is the issue that the wireless links don't have high enough bit rate?  What throughput do you need?   The 562 kb/s bit rate is pretty high, but when I think "control link" I assume low utilization factor.

[agehall]

Just get a half-decent CPLD and learn some basic VHDL (or Verilog - doesn't matter much for this application tbh). I did a similar thing when I reverse-engineered the CD-exchanger protocol in my car to replace it with a bluetooth device and still retain control over it from the head unit. You don't need a super big CPLD for this sort of thing.

[Wiljan]

Thank you for your feedback

Correct if using 2 channels it might create some sync issue between the channels special if one has to re transmit due to bad signal.
If I put 2 bytes after each other (one for 9 bit and  one for 1 bit) it will need the double bitrate, that will for sure work in the FPGA / CLPD, but when you have to send it as UDP there will needed to be added further bytes to that.

I just did some small test on a MAX10 and could easily get the 9 bit with the 562500 baudrate and send out serial data, but I guess I have to think the transport over again before doing more FPGA work

The timing from byte to byte are less than 1 byte in distance so optimal will be to "understand" the SONY protocol and pack the numbers of bytes for a "message" and send them as 1 packet and unpack then and transmit with the right timing in between, and the same way in the other direction.

I have also been looking a bit into using the nFR24L01 which can do 2Mbps but that's the packet data will need a lot of extra bytes

Preamble 1byte, Address 3-5bytes, Packet control 9 bytes, Payload 0-32 bytes, crc 1-2 bytes
It will pretty slow if you do not send a "message" instead of 2 bytes per tx session

Funny thing is I have just found a company in Germany who have  a ready solution for the SONY protocol
https://www.wireless-rcp.com/wireless-rcp-bridge.html
Guess the do parse the protocol and just send the "message" needed