Sony RS232 Protocol

[barrygordon]

The Sony protocol is a "Bitch" to deal with if you want to handle it
correctly for all cases and error syndromes, that is, all possible
ways that a message can be dstroyed or mangled when coming over RS232
from a Sony component and being changed to TCP/IP by a GC-100, iTach
Xeta Server or something similar.

Th first real problem is that there is no EOM (End of message) byte.
Ergo, to know you have a proper valid message have to do a bit of
work. You must detect the start of a message, isolate the message's
byte count which is always the 2nd byte of the message, assemble the
correct number of bytes, and finally validate that the checksum is
correct. Even then there is a small probablility that the message is
still mangled.Think of the case where the byte count itslef is mangled
by line noise.

A message can contain arbitrary bytes (0-225) so things like STX can
appear in the middle of a message.
When a full message has been taken off the line (using the byte count)
you must validate the checksum to ensure you really have a proper
message. This is especially true for long messages such as status
from Blu ray changers where large amounts of data can be pulled.

To complicate matters the message may not come into the iPad in one
chunk, but rathher a few bytes at a time with arbitrary timing between
chunks. After all it (RS232) is an asynchronous protocol which means
that the timing between bytes is arbitrary and not fixed. Also wi-Fi
issues contribute to the timing problem.

The only way to find the byte count in a message is that it is always
preceeded by a STX, however not all bytes that follow a STX bytes are
message byte counts, since an STX can appear at any position in a
message as part of the data. This implies that you must time the
receipt of a message so that some mangled byte count doesn't cause you
to wait for more bytes when none are forthcoming.

To really complicate things, a device like the global cache may not
end up delivering the full message in a single chunk. Lots of things
can cause delays in The GC device between the bytes coming in on the
serial side and leaving on the TCP side. And then there is Wi-fi to
contend with which can add additional delays and noise.

You can use a fairly complicated regex to grab just what you need from
a message in the simple case, especially when it is a response to a
specific command and not an unsolicited broadcast. My approach is to
use the simplest regex I know of (^*) which just delivers everything
from the line into the feedback processing function. My feedback
processing function is a Javascript function which handles all of the
delays, intermittent delivery, noise, etc and produces a validated
message for processing. Pulling the needed data out of a validated
method is driven by the command byte in the message which can then be
used in a switch statement to breakdown the validated message.

The trick is to be able to get a guaranteed valid message at all
times. Yes I know that TCP/IP is a guaranteed delivery protocol
but . . .

I implemented a feedback processor in Javascript using a finite state
machine with three states.
State 1- looking for a new message (STX) \x02 or a NAK \xFE or an ACK
\xFE. The ACK and NAK are valid single byte messages.
State 2- Pulling the message byte count. Always the byte after an STX
byte
State 3- Absorbing bytes until the message byte count has been
satisfied at which time a checksum computation must be perfomed to
validate the message.

I should be done with a complete demo program in a few days. The
program will be extensible, table driven for the most part and include
discovery of Global Cache devices. It will be heavily documented
since I am releasing it as both a teaching tool and a demo of "a way"
of doing things. It is HEAVILY Javascript oriented, but has enough
commentary to allow a beginner to follow it (I hope) The only
restriction is that no part may be used for monetary gain with out my
prior permission.

[Jarrod Bell]

Barry, excellent wrap up. You always impress :)

For the regex, you could just use . (not even requiring a capture group
I believe) and it will still fire the event back to JS on incoming data.

Jarrod

[Waldy,,,, Liverpool Uk]

Hi Guys,

I read this with interest as I am having similar problems to ND with
the sony.

What I cannot grasp is why I am not having any success at all.

I send a command to the sony to get the current volume. monitor it in
hercules and it shows correct every time so I know this part of it is
right. rs232 output, cabling, command etc. If the information is being
sent correctly why then can I not capture it in iviewer. I have tried
every scenario that ND has tried but I do not get anything, not even
an error. I believe I am missing something in my gui to tell it to do
so. being an end user and not a programmer and having limited
technical knowledge on how this all works I am now at a loss.

here is my example

I turn up the volume knob manually on my amp and the following shows
in hercules. I also do the same with the volume up button in my gui
and get the same so the command is right etc

{02}{06}{A8}{92}{00}{01}{ED}{80}{52}
{02}{06}{A8}{92}{00}{01}{EE}{00}{D1}
{02}{06}{A8}{92}{00}{01}{EE}{80}{51}
{02}{06}{A8}{92}{00}{01}{F1}{00}{CE}
{02}{06}{A8}{92}{00}{01}{F3}{00}{CC}
{02}{06}{A8}{92}{00}{01}{F5}{00}{CA}

I have added a button on my page called Get Volume (with no joins)
which calls the command get_vol to request current volume setting
\x02\x04\xa0\x92\x00\x01\xc9

I have a feedback control added to my system file which is called
Current Vol

The regex is \x02\x06\xa8\x92\x00\x01([\x00-\xff]) which as expalined
by Jarrod, will capture the "7th" set of bytes (I have tried with ".."
at the end of the string as well)

capture index 1
data Type Analog
target Type serial
Join 25
Token Type value
Transform
Min Value,
Max Value
Hex Data HexByte

This then has a join to a text box on serial join 25 which should
show the value of this (which it doesn't and at present is showing
"0")

I have another feedback control added which is called prove feedback

The regex is \x02\x06\xa0\x92\x00\x01(\xee)\x00\xd1 which should
capture again the 7th set of bytes when that string is matched
(herules shows that as a valid string as above)

I then use an onmatch

target Type Serial
Join 26
Assign Token false
Value, True
send command
send macro

This then has join to a text box join serial join 26 which should show
TRUE which it doesn't

I know that I have got 2 way communication whether this makes any
difference or not as when I use the xbmc module written by the CF
team, the slider bar moves showing the movie playing time.. What is
really frustrating is in the thread between myself,ND and Jarrod we
worked out all the commands,regex's etc and now ND has his working
fine and mine is not.

I am of the opinion that I am missing something simple that no one has
thought to mention. Is the regex case sensitive or something else that
stupid. I know Barry does not like Sony but it does seem with some
perseverence you can get some feedback working as shown by ND

Thanks Guys

[Nahshon Williams]

Try swapping gui files with ND ;-)

[nouveau depart]

Waldy,

Sent me an email, I will send you my GUI on monday when I m back fom weekend.

nouveaud...@gmail.com

Regards

--
You received this message because you are subscribed to the Google Groups "CommandFusion" group.
To post to this group, send email to comman...@googlegroups.com.
To unsubscribe from this group, send email to commandfusio...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commandfusion?hl=en.

[nouveau depart]

Waldy,

Sent me an email, I will send you my GUI on monday when I m back fom weekend.

Nouveaudepartsprl@ gm

Le samedi 18 février 2012, Nahshon Williams a écrit :