gc100 and rs232 control

[mikeybs]

I am trying to control a yamaha YSP5100BL soundbar/receiver via rs232 with the gc100.  I have found the rs232 protocol sheet for the receiver on the yahama website.

I am running lmce1004.  The gc100 was autodetected and setup.  I am using the IR transmitters without an issue.  The serial port was created on the core as /dev/ttyS_38_0 and I have selected that in the receiver device data as the value of "COM Port on PC".  

I went to the gc100 web admin and set up the serial port as described in the yahama protocol sheet:
baud rate: 9600
flow control: hardware
parity: no

The cable I am using to connect the gc100 serial port to the receiver serial port is described as a "DB9 RS232 Serial Null Modem Cable".  Perhaps the cable is my issue?  

I initially chose the "Yahama RX Receivers RS232" as the "Group/Codeset", but it doesn't appear that those codes match up well with my receiver.  I have been attempting to replace the rs232 codes in the template with the ones in the protocol sheet I have.  I am not having any success with this though.  I have yet to successfully send any sort of command to the receiver.

Can anyone suggest what I should attempt next?

Is there any other information I can provide?

[tschak909]

I would suggest grabbing an RS-232 in line tester, it's a device with LEDs on each pin, so you can see what's actually happening.

You can use the TestSerialPort command in /usr/pluto/bin to try sending commands to the device, run it without parameters to see what parameters it uses. You'll need to set the port to one of the ports that are exposed by the GC100 driver.

-Thom

[mikeybs]

yeah I've been trying to use the TestSerialPort utility to see if I can get a successful send that way.  I don't think I am writing my commands properly though, I'm not that familiar with serial port stuff...  I am not sure how to generate the correct transmit string.

I tried:

/usr/pluto/bin/TestSerialPort -p /dev/ttyS_38_0 -t 0787F -b 9800


I'm guessing that 0787F needs to be rewritten, can anyone assist in how to do that?

[tschak909]

If that is hexadecimal, then you need to use the hex notation, \xNN\xNNx\xNN, where NN is a hexadecimal number:

01050F would be written as:

\x01\x05\x0F

-Thom

[mikeybs]

so I'm thinking this is the correct command:

/usr/pluto/bin/TestSerialPort -p /dev/ttyS_38_0 -t "\x00\x78\x7F" -b 9600 -P N81

but the receiver does nothing when I send it...

I am still wondering if maybe I have the wrong type of cable.  I am rs232 newbie, so not quite sure.  Here is the cable I am using...  I tried putting in an actual link, but the forum will not let me.

"amazon.com/gp/product/B00006B8BJ/ref=oh_details_o07_s00_i00?ie=UTF8&psc=1"

[mikeybs]

I'm trying to use the globalcache itest.exe application to see if I can get it working that way...

still no luck

I am not sure I am doing the hex translation correctly.  The "Yahama RX Receivers RS232" "Group/Codeset" has IR commands that look like the following in it's A/V Properties:

SendIrCommand("07A15")

The codes in my protocol sheet appear to be very similar... I am attempting to send what is listed in my protocol sheet as: "0787F"

The itest.exe application will accept either string literals or hex input, so I am trying to use the hex input...

I used a hex code translator to turn "0787F" into "30 37 38 37 46" and then I entered that into the hex input of itest.exe and the receiver does nothing.  I also tried these for the hex codes:

00 78 7F
00 07 08 07 0F

neither of those worked either

itest.exe does seem to successfully connect to the serial port of the gc100 though.

I am back to wondering if the cable is my problem, or if I am screwing up the hex format in some way....

[tschak909]

Again, I would recommend inserting an RS-232 tester, and get a straight through cable, to test. Some devices need a null modem cable, some devices want a straight through cable.

-Thom

[mikeybs]

ok, I'll get a straight through cable and try that, if I still have issues I'll get the tester too, thanks for the advice

[mikeybs]

I am pretty sure the cable I need is a null modem cable   So I guess I just ordered a cable for nothing.  Looking at this PDF:

"www.customcodecrafters.com/pdfs/C3%20Yamaha%20YSP-4100%20+%20YSP-5100%20sound%20projector%20help.pdf"

it appears my receiver/soundbar requires a null modem cable.  The cable I am using is brand new, the link for it is in one of my previous posts in this thread.  So looks like I am back to the drawing board.  I guess I'll have to buy a tester to see if the signals are going through...

[mikeybs]

here is a link to the protocol sheet for my receiver/soundbar as well if it is of any help

http://www.awe-europe.com/documents/Control%20Docs/Yamaha/YSP_4100_RS232Full.zip

[mikeybs]

well I now have both an inline tester as well as a straight through serial cable and I am still unable to get things working.  According to the tester the signals are coming across the wire.

I am thinking that I am simply not generating the correct codes to send using the protocol sheet.  I am not sure what I am doing wrong.  In my previous post there is a link to the protocol sheet for my receiver.  I would really appreciate it if anyone could help me generate the correct commands for TestSerialPort, or the correct hex codes so that I can use the globalcache iTest.exe application to test.

The core groups of commands I am interested in are:

Power On
Stand By
Volume Up
Volume Down
HDMI 1
HDMI 2
HDMI 3
HDMI 4


If anyone could help me determine the correct TestSerialPort command for any one of those receiver commands it would be fantastic.

[tschak909]

From my glances of the protocol sheet, I've gathered:

* A crossover (null modem) cable is required, as RXD/TXD are swapped on both ends of the cable.
* fairly standard RS232 settings, 9600 BPS, N, 8, 1, which is what the generic serial device does by default.
* the protocol is a mash of binary and ASCII, and very compact.

DC1/DC2/ETX are ASCII control characters (which have their roots in Teletype communication, but I digress), look at an ASCII chart for their equivalents, like:

http://www.asciitable.com/index/asciifull.gif

As you see, 0x11 (hex) is DC1, which translates to \11 in TestSerialCommand or \x11 within a GSD string.

The values to use for timeout are specified there in the protocol sheet, but I will just for example say timeout is 0, so, TOUT 1 2 and 3 would all be 0.
so for the ready command (which according to the specification must be sent at the start of any communication), you would do for TestSerialPort:

Code Select Expand


\11\00\00\00\03


This should spit back a long string of data. Let's see if this does anything, first.

-Thom

[mikeybs]

I attempted to run this as root:

/usr/pluto/bin/TestSerialPort -P N81 -t \11\00\00\00\03 -b 9600 -p /dev/ttyS_38_0

it hung for a few seconds and then completed, there was no output

On the gc-100 web interface, what should the serial port settings for "Flow Control" be?  "Hardware" or "None" are the options...  I tried it with both settings, neither produced any output

[tschak909]

it should be hardware. You're not seeing any blinking happening with the serial port breakout? I would suggest testing with a USB to serial converter while you build the protocol, it'll be one less thing to worry about.

-Thom

[mikeybs]

I was able to get feedback using the iTest.exe application from globalcache.

I used the application to connect to the Serial Port and then sent the Hex command string:  \11\00\00\00\03

I received a very long response just as you suggested I would

That is the first feedback I've gotten from the receiver via RS232 so thank you for helping me achieve that. 

Perhaps I messed something up in the TestSerialPort command?

should the output for it come right through on STDOUT, or do I have to specify a "-s Search String" or "-m message to log" to see some output?

Could this mean the issue is with the virtual serial port on the linuxmce core.... /dev/ttyS_38_0?