Trying to comm with Harman Kardon AVR-145????

[cjean]

Dear gents,

I'm really desesperate on this one. I'm trying for a week now to send commands to my Harman Kardon AVR-145 receiver. I tried many things but unsuccessful so far this is why I'm asking the help of professionals.

The AVR-145 is very similar to the AVR-435 & 635 where *.lua file appear on the download page. The protocol document and wire setup I received from HK are exactly the same as the one posted on the download page. Initially I used the downloaded "lua" and found there was a mistake in it. Stop Bit was = to 1 and I changed to 0 since in the document it is written that Stop Bit 1 (in Girder stop bit 1 = 0 in the lua... from what I understand...

Please find below what I have when I trigger "mute" action.

When Girder open:

Loading Harman Kardon Profile
Loaded Harman Kardon Profile
Serial: Harman Kardon Receivers V2.0 : Opened Device: Harman Kardon Receivers V2.0 Port: 5 Settings: 38400 N 0 8 0
Serial: Harman Kardon Receivers V2.0 : Callback Installed 2

When "mute" is triggerred:

Serial: Harman Kardon Receivers V2.0 : Command queued: 50 43 53 45 4E 44 02 04 80 70 C1 3E 41 4E PCSEND..€pÁ>AN at postion 1
Serial: Harman Kardon Receivers V2.0 : Simple Send: 50 43 53 45 4E 44 02 04 80 70 C1 3E 41 4E PCSEND..€pÁ>AN
Serial: Harman Kardon Receivers V2.0 : Simple Receive: Data Code: 16384
Serial: Harman Kardon Receivers V2.0 : ERROR: No response to last command

I think my files are fine but since I have no results... I don't know where to sit...

Please find attached mu lua... gml and protocol sheet from Harman Kardon.

I really need help on this one. I'm working late each night to make it work and I'm starting to be little tired:(

Thanks in advance

Regards

Charles

[Rob H]

You're not specifying a callback type - try adding these two lines at around line 24 of the lua file


CallbackType = serial.CB_FIXEDLENGTH,
ReceiveFixedLength = 512,

The length specified is (hopefully) longer than any response you'll get back from the HK - I've done it this way because the way the protocol works doesn't really fit with any of the other callback types since the length field is at the 8th byte. Accordingly you'll need to write a ReceiveResponse method that checks for an incomplete response e.g.


ReceiveResponse = function(self, data, code)
if math.band(code, serial.INCOMPLETERESPONSETIMEOUT) > 0 then
-- process the data here
code = serial.zerobits (code,serial.INCOMPLETERESPONSETIMEOUT)
end
serial.Classes.Queued.ReceiveResponse(self, data, code)
end,

[cjean]

Hi Rob,

Thanks for your reply,

I'll give it a try and let you know.

The thing I found curious is... back in 2006 there was a similar problem with an HK 635 were you participate in resolving the problem :) I took the successfull script made by "barca0" and I just changed StopBits = 1 to 0 (so it is specified in pc_remocon....pdf )the all the rest is the same. Do you think I shouldn't done that?

This is the link of this past post is here:

http://www.promixis.com/forums/showthread.php?t=11188&page=4&highlight=harman

Anyway I have nothing to loose at this point, I'll try anything you ask me.

I'll get back today!

Thanks

Charles

[cjean]

You're not specifying a callback type - try adding these two lines at around line 24 of the lua file


CallbackType = serial.CB_FIXEDLENGTH,
ReceiveFixedLength = 512,

The length specified is (hopefully) longer than any response you'll get back from the HK - I've done it this way because the way the protocol works doesn't really fit with any of the other callback types since the length field is at the 8th byte. Accordingly you'll need to write a ReceiveResponse method that checks for an incomplete response e.g.


ReceiveResponse = function(self, data, code)
if math.band(code, serial.INCOMPLETERESPONSETIMEOUT) > 0 then
-- process the data here
code = serial.zerobits (code,serial.INCOMPLETERESPONSETIMEOUT)
end
serial.Classes.Queued.ReceiveResponse(self, data, code)
end,

OK...

Done what you asked me,

Here is the result,

Loading Harman Kardon Profile
Loaded Harman Kardon Profile
Loading Sharp Aquos Profile
Loaded Sharp Aquos
Welcome to Promixis Girder 4.0!
Serial: Harman Kardon Receivers V3.0 : Opened Device: Harman Kardon Receivers V3.0 Port: 1 Settings: 38400 N 0 8 0
Serial: Harman Kardon Receivers V3.0 : Callback Installed 1
Serial: Harman Kardon Receivers V3.0 : Command queued: 50 43 53 45 4E 44 02 04 80 70 9F 60 1F 10 PCSEND..€pŸ`.. at postion 1
Serial: Harman Kardon Receivers V3.0 : Simple Send: 50 43 53 45 4E 44 02 04 80 70 9F 60 1F 10 PCSEND..€pŸ`..
Serial: Harman Kardon Receivers V3.0 : Simple Receive: Data Code: 16384
Serial: Harman Kardon Receivers V3.0 : ERROR: No response to last command

The only difference I see from the previous lua is now Callback Installed is 1 instead of 2. Otherwise no reation from HK receiver:sad:

Also I joined the new lua for your troubleshooting pleasure:D

Hope to hear from you soon.

Thanks again,

Charles

[Rob H]

The protocol document doesn't specify the flow control - it may require hardware flow control perhaps. The other thing is the cable - I'd try running Hyperterm and connecting at the same settings. Then make some adjustments on using the reciever's remote and see if you get any status information - if not then it's probably the cable.

[cjean]

The protocol document doesn't specify the flow control - it may require hardware flow control perhaps. The other thing is the cable - I'd try running Hyperterm and connecting at the same settings. Then make some adjustments on using the reciever's remote and see if you get any status information - if not then it's probably the cable.

Hi Rob,

Thanks again for your support.

From what I can understand, we have acheived all we could do on Girder side, Right?

I know my cable is good, I tested it with an ohm meter, and com port is working, the only thing is:

- A dead com port on my receiver.

BTW Before I made my own cable, I bought a "supposed" straight thru cable, I found out after it was a cross one, pin 2 was at 3 at the other end. By your experience with that kid of stuff, Is it possible that I damaged my receiver?

- I've been misleaded on protocol and codes by Harman Kardon.

I'll give it a try in sending codes with HyperTerminal!

Thanks

Charles

[cjean]

[QUOTE=cjean;117551]

Sorry my post was supposed to be like this;)

Hi Rob,

Thanks again for your support.

From what I can understand, we have acheived all we could do on Girder side, Right?

I know my cable is good, I tested it with an ohm meter, and com port is working. The remanings to look after are:

- A dead com port on my receiver?

BTW Before I made my own cable, I bought a "supposed" straight thru cable, I found out after it was a cross one, pin 2 was at 3 at the other end. By your experience with that kid of stuff, Is it possible that I damaged my receiver?

- I've been misleaded on protocol and codes by Harman Kardon?

I'll give it a try in sending codes with HyperTerminal!

Thanks

Charles

[Rob H]

It's possible that the com port is dead - or alternatively, perhaps you need to enable serial comms in the HK's setup somehow?

[cjean]

It's possible that the com port is dead - or alternatively, perhaps you need to enable serial comms in the HK's setup somehow?

Thank you Rob,

I wish my com port is not dead... speaking for my self, I've never seen a such case so far... Unfortunatly, nothing in the AVR menu is showing com parameter.

I'll pray god that it is not dead!

Thanks for your support,

Regards,

Charles

[Rob H]

Any response when using Hyperterm and changing e.g. the volume from the remote?

[cjean]

Any response when using Hyperterm and changing e.g. the volume from the remote?

Hi Rob,

Do you mean that I should get in the Hyperterminal window a response from the receiver when I'm using the remote? If so that's cool.

Should I see someting like OK or whatever?

You're a smart guy, let my try that!

Charles

[cjean]

Any response when using Hyperterm and changing e.g. the volume from the remote?

Nothing, nada, completly dead. Nothing in the hyperterminal window, unless I did not configure it properly to receive data. From what I can understand, from the manual, it is not a bidirectional com port like the big brothers AVR 245, 425. It seems that only data can be send. The big questions is how, Harman send me the same protocol sheet as AVR 425, I'm very confuse...

Is there a way to know that com port on the receiver is not dead?

Thanks

Charles

[Rob H]

Ah, that's a bit strange - I wonder why they wouldn't make it bidirectional. It kind of limits its usefulness - it also means that they would have had to do extra work to disable that feature rather than just reusing the existing firmware.

Still, that would explain why you get no response.

I'd have a word with HK support to confirm that for sure though.

[cjean]

Ah, that's a bit strange - I wonder why they wouldn't make it bidirectional. It kind of limits its usefulness - it also means that they would have had to do extra work to disable that feature rather than just reusing the existing firmware.

Still, that would explain why you get no response.

I'd have a word with HK support to confirm that for sure though.

Thank Rob, you're the men!

Just to give you a little more details, in the manual they specify that the port on the AVR 145 is for sending data for futur upgrades only. Sending remote code is an unsupported feature. Before I made my purchase, I talked with the guys at Erickson, here in Canada, and they told me that yes it is supposed to work with remote command but its's a unsupported feature. They were kid enough to send me the protocol sheet (attached) but cannot offer any further help. The sheet I received is the same as for the AVR 245, 425, 625. I also push it a little further, I tried to send codes for an older model of AVR, 525 for instance, no go either.

So far my conclusion is:

- The com port is dead because I burn it ( as stated previously, I bought a cable that was supposed straight thru and found out later it was a cross ) I made my own and test it but still no joy.

- Or there protocol sheet does not apply for this model.

I really hope you'll get answers from HK.

I would like to thank you sincerely for your great support. I do my very best to support other users were I can.

Great day

Charles

[Rob H]

Using a crossed cable really shouldn't cause a problem, only if you've shorted pins 2 or 3 to a power connection (or possibly ground), but even then I wouldn't expect it to cause a problem.

HK may have a test utility that you can try - mail them back (or call them) to see if there's a way of testing the comm port.

[cjean]

Using a crossed cable really shouldn't cause a problem, only if you've shorted pins 2 or 3 to a power connection (or possibly ground), but even then I wouldn't expect it to cause a problem.

HK may have a test utility that you can try - mail them back (or call them) to see if there's a way of testing the comm port.

From what I can see, on a cross cable pin #5 GROUND is going to pin # 3 TX on the other side. From what I understand from them, They are using these 2 pin to communicate... Ouch :(

Charles

[cjean]

Using a crossed cable really shouldn't cause a problem, only if you've shorted pins 2 or 3 to a power connection (or possibly ground), but even then I wouldn't expect it to cause a problem.

HK may have a test utility that you can try - mail them back (or call them) to see if there's a way of testing the comm port.

I will have a talk with them today. Since Erikson is the Canada distributor for HK I'm thinking that they might not know this product in deep. When I talked to them, they were not very familiar with RS232 communication.

If you have a word with HK US, I think you'll have better answers than I.

Thanks for the extra step you're doing for me.

Regards,

Charles

[Rob H]

Unfortunately I'm in the United Kingdom.

Pin 5 should not be connected to anything but pin 5! On a crossed cable only pins 2&3 should be swapped!!!

[cjean]

Unfortunately I'm in the United Kingdom.

Pin 5 should not be connected to anything but pin 5! On a crossed cable only pins 2&3 should be swapped!!!

I agree with you. I returned the faulty cable to the local shop so I can't confirm that pin 5 was to 3. I rarely seen such cables but might be possible.

BTW have you contacted HK too see if we can send command to AVR 145,245... ?

Thank you

Charles

[Rob H]

I've just taken a look at the rear view of the 145. It shows two buttons next to the RS232 port. Can you check that the blue button is not pressed in? And also try pressing the reset button.

[cjean]

Hi Rob,

The blue one is for firmware upgrade. When poped out, port is in operating mode and when in its for upgrade. I made sure it was poped out. Anyway when in, I can't turn on the receiver. The other one is to reset the AV after system upgrade. Must be a master reset. Tried it but did nothing while it was OFF. Did not try it when it was in Stanby mode. I found out that Harman new 2007 lineup are almost all like that. They offer system upgrade thru RS232 but without "supported" remote RS232 command... Strange.

Thanks

Charles

[Rob H]

It's a surprisingly common thing really.

When talking to manufacturers the key thing to ask is whether the device can be controlled by AMX or Crestron serial controllers. This is what I've done with HK - let's see what they have to say.

[Rob H]

HK replied and sent me a PDF which I've attached to this message.

Clearly the RS232 connection is unidirectional on the 145 so you won't get any responses back.

Try doing a search and replace in your Lua to change serial.Classes.Queued to serial.Classes.Simple so that it won't require any responses.

It might be worth trying a reset of the receiver

[cjean]

Rob,

I can't believe it? You have a lot of power! This is the most complete sheet I ever seen from HK!

OK If I read carefully this sheet, the AVR is waithing for specific sequence & data type like this:

PCSEND 02 04 80 70 c1 3e 41 4e (last two bytes is check sum)
(ASCII) (Hex ----------------Hex)

From what I can see in our lua we are sending an action in full Hex like this:

50 43 53 45 4e 44 02 04 80 70 c1 3e 41 4e

Is this OK?

I'm a little confuse in there data structure.

For troubleshoothing purpose I used Hyperterminal and other software. I will change Command queued to simple when I'm done with all the test. I always tried to send 50 43 53 45 4e 44 02 04 80 70 c1 3e 41 4e but never got any results. Is is possible that the data structure we are sending is not correct?

Thank you so much for you help another step forward.

Hope to hear from you soon :cool:

Charles

[cjean]

Hi Rob,

Please find below what I'm refering to. You have built this a portion of the script about a year ago. If you see, PCSEND is not translated to hex it is send like it is. On the other side the checksum is send into decimal not in hex. I tried this script and it didn't work maybe because of the wrong checksum.

Command = function(self, words, asHex)
local data
if asHex then
data = serial.hextobyte(words)
else
data = words
end
local csodd = 0
local cseven = 0
for i = 1, string.len(data) - 1, 2 do
csodd = math.bxor(csodd, string.byte(data, i))
csevent = math.bxor(cseven, string.byte(data, i + 1))
end
self:SendCommand('PCSEND'..serial.hextobyte('0204' )..data..csodd..cseven)
end,

This is what I have right now. The PCSEND instruction is send into hex and the checksum also. I'm thinking that PCSEND in hex is wrong while the checksum in hex is fine.

Command = function(self, words, asHex)
local data
if asHex then
data = serial.hextobyte(words)
else
data = words
end
local csodd = 0
local cseven = 0
for i = 1, string.len(data) - 1, 2 do
csodd = math.bxor(csodd, string.byte(data, i))
cseven = math.bxor(cseven, string.byte(data, i + 1))
end
csodd = serial.decimaltohex(csodd)
cseven = serial.decimaltohex(cseven)

self:SendCommand(serial.hextobyte('504353454e44020 4')..data..serial.hextobyte(csodd)..serial.hextoby te(cseven))
end,


I might be wrong since I'm still learning how lua programming works, but you can confirm what I'm writting.

Thanks for you outstanding support Rob, this is extremely appreciated.

Regards,

Charles

[Rob H]

PCSEND is directly equivalent to 50 43 53 45 4e 44

It looks to me as though the correct data is being sent.

Although, having said that I've just looked more closely at section 4.4.1.1 of that PDF file. The bit order shown in the figure is actually the reverse of what they're trying to send. ie rather than sending 80 70 C1 3E they seem to be sending 01 0E 83 7C !!!!

[cjean]

Hi Rob,

Following what I sent you earlier here is the results of the 2 different version of the script. The first result is the above 1st script, 2 second result the second script.

This one show 3 bytes at the end while I see 2 beign processed in the script.

Serial: Harman Kardon Receivers V5.0 : Command queued: 50 43 53 45 4E 44 02 04 80 70 C1 3E 36 35 30 PCSEND..€pÁ>650 at postion 1
Serial: Harman Kardon Receivers V5.0 : Simple Send: 50 43 53 45 4E 44 02 04 80 70 C1 3E 36 35 30 PCSEND..€pÁ>650
Serial: Harman Kardon Receivers V5.0 : Simple Receive: Data Code: 16384
Serial: Harman Kardon Receivers V5.0 : ERROR: No response to last
command

This one should be correct but not sure if the checksum is ok

Serial: Harman Kardon Receivers V2.0 : Command queued: 50 43 53 45 4E 44 02 04 80 70 C1 3E 41 4E PCSEND..€pÁ>AN at postion 1
Serial: Harman Kardon Receivers V2.0 : Simple Send: 50 43 53 45 4E 44 02 04 80 70 C1 3E 41 4E PCSEND..€pÁ>AN
Serial: Harman Kardon Receivers V2.0 : Simple Receive: Data Code: 16384
Serial: Harman Kardon Receivers V2.0 : ERROR: No response to last
command


In both case I don't see the PCSEND beign send in ASCII everything is Hex. Also I'm still not sure witch one process the checksum correctly.

If everything is fine then, I have to look somewhere else.

Please confirm my observation.

Regards,

Charles

[Rob H]

As you can see on the right hand side, both of them are sending PCSEND

The second one looks correct to me and the checksum looks fine, but lets check

Byte 0: 80 = 1000 0000
Byte 1: 70 = 0111 0000
Byte 2: C1 = 1100 0001
Byte 3: 3E = 0011 1110

High byte of the checksum is Byte0 xor Byte 2 ie 0100 0001 = 41
Low byte of the checksum is Byte1 xor Byte 3 ie 0100 1110 = 4E

So the checksum looks okay to me.

[cjean]

Hi Rob,

Here is the e-mail I just got from HK Canada


Hello Charles,
Here are the official facts on the unsupported RS-232 functionality. I had a discussion today with a key HK support contact and confirmed the following. The only AVR's that feature RS-232 IR controllability is the
445 and up (AVR 645 and AVR 745) of this year's crop of models. The AVR 145, AVR 245, including this years x47 series which are equipped with an
RS-232 connection are for software upgrades only. The IR function is not enabled on the lower end models via RS-232.

Here is the option to enable IR controllability from your PC other than the obvious of switching for an AVR 445:
Acquire an RS-232 DB9 to IR converter (a small box with a DB9 connector on one end and a 3.5mm output that an IR emitter can be connected to.
This way the IR emitter can be attached to the front of your AVR145.
This is less may be deemed less attractive, though fully capable of repeater IR commands.

To sum it up, your AVR 145 is functioning properly it is simply unable to communicate with your PC in its current state without IR emitters and a RS-232 module.

Rob, we have two different version of facts, who is right? The first page of the document you send me tells me that all receivers can receive command, what HK tells is not.:confused:

My english is far from prefect but I would like to have your input on how you see it

Are we working on something that will never work... sounds like it...

Charles

[Rob H]

Hard to tell really - the reply I got from HK US specifically confirms that the AVR 145 can be controlled through the RS232 port!

Unless the Canadian version has this disabled?

Although, to be honest the protocol has so many limitations as to render it fairly worthless e.g. you can't directly set the volume level. In fact I don't think that it offers anything that you can't do with the remote (or with a USB-UIRT).

[cjean]

You are probably right,

I'm already using USB-UIRT and I'm having a serious time lag when sending multiple volume increase/decrease and the volume slider in windows is out of sync with the receiver. The volume stream is not reliable with UIRT that's why I want to move with serial.

Unless you have a clue for this!

Really appreciate your help.

Regards,

Charles

[Rob H]

How are you triggering the action? If you're using an IR remote control then that will interfere with the signal from the USB-UIRT

[cjean]

How are you triggering the action? If you're using an IR remote control then that will interfere with the signal from the USB-UIRT

No I'm using it only as an emitter so only actions are triggered. It's only the time it take to emit all the pulse. When triggering multiple volume change, the receiver is missing a couple of them. I don't see how I can change that. It's more a nature of the hardware I think

Charles

[cjean]

Hi Rob,

I think we should close that thread now. Called HK Canada engineers and confirmed to me that lower end HK models have not enabled remote RS232 commands into the Cirrus logic chipset. This is unfortunate but I think all the work we put without sucess just proof that. They offered to me a good deal on a AVR-445 that fully support what I want to do and trade in my actual receiver.

Again, I would like to thank you very much for your help. All I can say is Girder is a very very powerful tool built by and for automation addict.

Best regards,

Charles:)

[Rob H]

Are you going for the trade-in?

[cjean]

Are you going for the trade-in?

Looks like it.

I'll post you an update somwhere in two weeks when I'm going to get it.

Charles

[cjean]

Hello Rob... or anybody that can answer this!

I just got my new Harman Kardon AVR 445 that is capable or receiving command thru his RS232 port. So far so good.

It is working but part time... What I mean is the receiver is sending so much stream data thru the port that 1 time on 6 it will catch the command I'm sending in to it.

I don't know what to do to ask Girder to ignore them but it seems that Girder is overloaded treating them or the receiver just don't read them.

He is my serial lua and also a capture of the logger.

Thanks in advance,

Charles

[cjean]

Hello Rob... or anybody that can answer this!

I just got my new Harman Kardon AVR 445 that is capable or receiving command thru his RS232 port. So far so good.

It is working but part time... What I mean is the receiver is sending so much stream data thru the port that 1 time on 6 it will catch the command I'm sending in to it.

I don't know what to do to ask Girder to ignore them but it seems that Girder is overloaded treating them or the receiver just don't read them.

He is my serial lua and also a capture of the logger.

Thanks in advance,

Charles


Hi All,

I made some little improvement but still not reliable 100%. In my serial plugin I put Loglevel = false. This has improved a lot but the receiver is still missing some commands I'm sending to it.

Anything else I should try?

Thank you,

Charles

[Rob H]

I'd recommend changing to use serial.Classes.Queued as the base class (ie do a search and replace from Simple to Queued). That should help.

[cjean]

I'd recommend changing to use serial.Classes.Queued as the base class (ie do a search and replace from Simple to Queued). That should help.

Hi Rob,

Thanks for your reply,

Unfortunatly, it did not help! I still have to press 3 to 5 times before the receiver react to my input. I can see in the logger that command are sent but again it really look like an overflow somewhere. I'm not a Girder specialist and I don't want to mislead you.

I'm clueless on this one. I really don't know why HK make simple things complicated.... Hi tech but unrealiable, German way! :(

I will try with their own software to see how it goes

I'll let you know.

Charles

[Rob H]

Do you get continuous status reports from the HK? As far as I can tell it's sending back the data from the 3 lines of the VFD so if that is continually changing I'd expect lots of updates.

[cjean]

Do you get continuous status reports from the HK? As far as I can tell it's sending back the data from the 3 lines of the VFD so if that is continually changing I'd expect lots of updates.

Not sure if I'm following you 100% but if I understand, Yes the receiver continuously sending data from the VFD status. No matter command I'm sending, it's blasting all the time data. Even if the status is not changing, it blast all the way. The PDF file I joined is just a little sample of what the receiver is sending and as soon the receiver is ON it's never ending until OFF.

Something I found interresting, even if the receiver is OFF (not blasting data from VFD) it takes 4-5 ON command trigger to turn it ON! I was suspecting that incoming data was taking all the bandwith and preventing to get sent command but when its OFF and want to turn it ON, nothing should prevent that?

I don't know if this helps you?

I'm starting to suspect something with the receiver?

Thank you,

Charles

[Rob H]

It's probably worth asking HK about this - seems very strange to me

[cjean]

It's probably worth asking HK about this - seems very strange to me

Rob,

This is what they replied to me:

Hello Charles,
I am glad to hear that the RS-232 is receiving commands from your PC as this indicates all is working fine. Sounds like a timing or carrier frequency issue with the PC that causes you to have to repeatedly press the command.

There is not a way for us to helps you further on this subject, as
RS-232 with any 3rd party integration provider is supported by that company (ex. Crestron, AMX, Lutron, etc) that provides that connectivity. Harman/Kardon provides the platform to integrate, though that is it as the 3rd party automation companies write all the code based on the documents related to HK RS-232 that you currently possess and to ensure you have all the documents I attached them to this email.

Perhaps the people (users) you have been communicating in the forums can help you further as this is outside our realm of expertise.

Good luck with your PC integration project and enjoy the awesome AVR445.



Rob, all the documents they send me, you have them already. I have joined the FAQ but most likely, the command & computed checksum sended are fine.

I really stuck now.

Can it be on the hardware side? is there any other settings on the com port that can affect the communication?

Thanks

Charles

[Rob H]

One think I noticed in the log is the fourth block of data sent starts with APSEND rather than MPSEND which is not valid data.

After that APSEND the remainder of the received data is mostly gibberish as far as I can tell. Certainly the large blocks of nulls don't look right. And the null at the start of the first MPSEND looks dodgy too.

Is this a 'real' serial port or a USB-serial converter? Can you try another cable? It's possible that you're getting interference from something else or you may have a bad/unshielded cable.

One possibility is to change the ReceivedFixedLength parameter to 58, which should cover all situations when the AVR is sending to the PC.

[cjean]

One think I noticed in the log is the fourth block of data sent starts with APSEND rather than MPSEND which is not valid data.

After that APSEND the remainder of the received data is mostly gibberish as far as I can tell. Certainly the large blocks of nulls don't look right. And the null at the start of the first MPSEND looks dodgy too.

Is this a 'real' serial port or a USB-serial converter? Can you try another cable? It's possible that you're getting interference from something else or you may have a bad/unshielded cable.

One possibility is to change the ReceivedFixedLength parameter to 58, which should cover all situations when the AVR is sending to the PC.

Rob,

This is a thru serial port I'm using, also I bought a my cable from Office depot. My cable look flimsy compare to the one I built. You might be right, my cable is roughly 1/8 dia and shield might be poor.

I will change my cable and change the ReceivedFixedLength to 58 and will post back my results.

I think you may point in the right direction since I tried HK software utility and I'm having the same issue... I looks to be hardware related then.

I its the case then I have my lesson... don't buy cheap stuff!

Thanks for all, I will post back. What a nightmare...

Charles

[cjean]

Hi Rob,

Thing has improved a bit but still no go.

I think I got rid of the corrupted data by changing my cable or by changing the ReceivedFixedLength to 58.

The only thing that is working fine now is the Power On. Everytime I click on it, it works. As for the Power Off and mute, I still need to click about 5-10 times before it works.

Please have a look to my latest log.

Any ideas?

Thanks Ron

[Rob H]

Okay, I see that you've queued lots of power off commands - after the first has been sent, the response from the HK is


82 06 00 00 00 00 Code: 0

Presumably that code was originally serial.INCOMPLETERESPONSETIMEOUT, but the ReceiveResponse method clears that.

This response doesn't seem to be documented.

A bit later you receive a couple of NULs, then two no responses, a couple more NULs and a


00 FE 00 00

Then it descends into gibberish.

As far as I can tell the checksum looks fine. Why so many power off commands? Can you try just sending the one and logging that. Or maybe try mute.

[cjean]

Hello Rob,

I made a lot of test and also progress in that issue. Still not working reliably but I think the attached documents will help.

First I can state that the cable is not the problem now. I made my own witch is an aluminum shielded and soldered to ground on both ends. All pins were tested one by one.

I can state also that I have inconsistant results from one test to another. It looks like if I turn OFF the receiver for few minutes and back On I get better results but codes are getting deteriorated rapidly.

I tried to use an USB to Serial adapter with a Prolific chip and communication was a lot better. All the command sent were working at 95% but all the received data were gribbish. I think this is normal for that type of device.

In this test I put back the onboard serial adapter. The attached file is showing clearly that something is going wrong. In the PDF, you are going to see "Receivers V3.0 : ERROR: Serial communcation error and also series nulls that I can't explain on page 37. Results are self talking on page 38. On this page I switched OFF the receiver and back ON. At the beggining code received are fine but deteriorating after a couple received.

He is my conclusion so far.

- Its not the receiver since it works well with the USB to Serial adapter.
- Its not the cable since I used the same cable with the USB adapter.
- Codes are deteriorating not long after the receiver ON
- I have a response back from the receiver when to code sent sucessfuly.
- I have straighten received code before thinking to send some. " Shit in, Shit out"

I'm starting to think that something is wrong within the computer. Is it possible that my SPDIF adapter is causing interference to my serial ribbon cable? SPDIF connector is right on to the serial connector. Is there anything else I should look for?

I'm really confuse

Thanks a lot Ron

Desesperated Charles

[Rob H]

Can you try it on another computer temporarily? It does sound as if either your serial port is damaged or being interfered with in some way. I guess it's possible that it's the SPDIF. Can you disable the SPDIF? Perhaps there's a problem with the serial ribbon cable?

[cjean]

Well I did change my ribbon cable and move it away from SPDIF signal. By looking at my log you will see that it is almost perfect... but I still need your input to agree or not. For sure, results are more consistant. You will see that most a the sent command were sucessful but some did not operate correctly???

You will see that I sent many Mute code and most have responded correctly and some didn't. For the one that worked, you will see "MUTE" in the incomming string just after my sent code, the receiver responded with a code that I can't identify. For the ones that did not respond correctly to my sent code, the receiver did not change the incoming string. It looks like Girder will stop the queued code on whatever will be the response from the receiver

Is there a way that Girder is will keep in queue the code I'm sending until he gets back the right response from the receiver?

Do I still have a communication problems in your opinion? What can I do to make it work 100% reliable. I imagine that I'm not the only one that use this receiver and are able to communicate with it trouble free?

Also, do you know a good source on where I could get a trustable USB to Serial adapter? Since I can't put my serial connector to the back panel bracket, I don't know where to put it. I don't have other opening where I can put it far from interference. My only real solution is to find a USB to multiple serial adapter. The el cheapo one I have is not trustable 100%.

Best regards Ron,

Optimitic Charles!

[Rob H]

Clearly there is still a problem - I've had some success with USB-serial adaptors in the past, but at slower speeds. It may be worth looking for a PCI serial IO card e.g. something like this http://www.newegg.com/Product/Product.aspx?Item=N82E16815124017

Oh, and it's Rob, not Ron :)

[cjean]

Sorry about that Rob!

Rob,

I don't have any other PCI slot available. Both are fill with TV tuners. Would you trust this one?

Edgeport USB to 4 DB9

I heard good things about it, unless you know something else.

Thank you

Charles

[Rob H]

I've not heard anything bad about the Edgeport.

[cjean]

Hi Rob,

I'll give a try to the Edgeport and will post back my results.

BTW I would like to share my working serial plugins with other potential users. We have put so much work in them! Do you think!

Please find attached:

Serial plugin for Sharp Aquos series with RS232 port

& Harman Kardon receivers

Cheers

Charles

[cjean]

Hi gents,

I'm near suicide guys... really.

I'm trying to make that d... thing work and I'm struggling... I'm clueless.

Just to wrap up briefly, I'm trying to talk to my Harmon Kardon AVR 445 bi-directional RS232 for over a month now. Every time I have the same issue. I can talk to it briefly at the beginning and then no longer after start, I'm getting garbage, errors and there is no way to send command to it after, it just not responds.

Here is what I tried:

- Getting support from Harman. They told me that if my data is getting corrupted, my port settings are wrong, cable is dead, my com port is damaged and my software is misconfigured. It looks to them a lost of synchronization. They can't help me more since the receiver is sending those data from hardware and there is no way it can be modified by the software at the other end. Also their unit is working beautifully with Creston and or AMX automation. They just can't help me more.

- Changed my cable 3 times, 2 from stores and 1 I made by my own. all of them were shielded.

- I disabled the onboard COM port and added a quality dual RS232 PCI card.

- I tried a single USB to RS232 adapter with a Prolific chip.

- I tried an Edgeport/4 USB to RS232 adapter

- Tried to play around with my com port settings in my lua. Stop bits, Flow control....

None of the above worked at it is supposed to. I always get the same result. Data received is good at the beginning but start to going crazy not longer after the receiver is started. Also sending codes to it is out of question in that condition. I would say that I have more consistent results with the Edgeport adapter and worked sometime even if data was bad, but still... Important note, Edgeport has a configuration utility were I can see the status of the communication. I can see there a lots of errors in the received data. If needed I can send this log file too.

Here is my latest LUA and log file (attached).

If you have any questions feel free to ask or if you want to tell me how I'm stupid because I haven't seen an obvious mistake, good ahead I'm already down.

Sincerely thank you in advance

Charles

[cjean]

Should I prepare the rope then?

[theguywiththefunnyhair]

dude,

I dont really think i can help you with this but i looked at your log.pdf and i noticed that everytime you get an error, the code for the line before is 129. The previous line also appears to have '00' the Hex value for 0 or null inserted into the data. If you use the 'DH' or 'dh' in the ascii representation of the data as a reference point you will see it aligned in the good transmission but moves to the right in the bad (code 129) this suggests characters are being added.

Maybe this will mean something to you.

Dan

[cjean]

dude,

I dont really think i can help you with this but i looked at your log.pdf and i noticed that everytime you get an error, the code for the line before is 129. The previous line also appears to have '00' the Hex value for 0 or null inserted into the data. If you use the 'DH' or 'dh' in the ascii representation of the data as a reference point you will see it aligned in the good transmission but moves to the right in the bad (code 129) this suggests characters are being added.

Maybe this will mean something to you.

Dan

You are right, I can see that. I just don't understand why it's doing that. The stream i sent from the receiver, no from a PC. Unless the receiver is defective, I would suspect that Girder is not able to keep up with the incomming stream or a bug within the serial plugin itself. It reaaly looks like a timing or something like that. I'm wating for an answer from the pro's at Girder. Unless somebody else, a communication pro, can answer that.

I really clueless on this one.

Charles

[Rob H]

It might be a buffer overrun or framing error I guess. We'll have to wait for Ron to give a canonical answer on what the error code might mean - it just translates to serial.ERR

[cjean]

It might be a buffer overrun or framing error I guess. We'll have to wait for Ron to give a canonical answer on what the error code might mean - it just translates to serial.ERR

I'll run my config utility from my Edgeport. From there I will post back the log file. I just don't see why I have the same results with a physical COM port. Maybe my log from Edgeport will give you a direction.

Thanks Rob!

Sincerely

Charles

[cjean]

Hi Gents,

Here is the log file of my Edgeport config utility. Also a screen shot of the Com port status. Hope this helps! Please note that I triggered a couple of MUTE command in here.

If you want me to do some test, feel free to ask!

Thanks to all,

Charles

[Rob H]

Lots of framing errors in there, this usually means either a mismatch in the serial settings or that the clocks are out of sync between the two ends.

Interestingly, every framing error is accompanied by a BREAK and TX CPS increasing from 0 in multiples of 14 cps.

I'm not entirely sure what this means. One possibility is that there's a problem with the receiver itself, alternatively one of the serial settings is wrong and perhaps the manual is lying about the correct settings.

I can't remember whether I'd asked you previously, do HK have any test programs that you can run on a PC to check that the receiver can communicate correctly?

[cjean]

Lots of framing errors in there, this usually means either a mismatch in the serial settings or that the clocks are out of sync between the two ends.

Interestingly, every framing error is accompanied by a BREAK and TX CPS increasing from 0 in multiples of 14 cps.

I'm not entirely sure what this means. One possibility is that there's a problem with the receiver itself, alternatively one of the serial settings is wrong and perhaps the manual is lying about the correct settings.

I can't remember whether I'd asked you previously, do HK have any test programs that you can run on a PC to check that the receiver can communicate correctly?

Hi Rob,

I have 2 different version of Harman Flash utility were you can operate the receiver from their graphical desk. Both of them crash when the software tries to talk to the receiver or if not crashing, I just have “WAIT FOR DATA “ These software’s have not been specifically written for my receiver but from their spec sheet they are sharing all the same protocols.

It looks like the receiver is the culprit. Rob on your side, if you can confirm that Girder, serial plugin or whatsoever regarding Girder is not in fault? Please let me know because it’s the second receiver I'm returning and if they find the receiver is fine, they will charge me. Harman have not been very helpful in this matter for something that I paid 10 times the price of your software?

As a side note “Interestingly, every framing error is accompanied by a BREAK and TX CPS increasing from 0 in multiples of 14 cps. " this might come from the MUTE command triggered but I can't explain why.

Thank you,

Charles

[Rob H]

Just to make sure, are you overclocking your PC or anything like that? Although the UARTs should have their own clocks so that shouldn't have any bearing on the matter. The fact that the Edgeport's own log shows the error would indicate to me that the problem is with the receiver. I'd recommend asking HK whether they have any test software that they could send you to run on your PC to communicate with the receiver. Also if you have another PC (or can borrow one) then it would be worth trying on that.

The Harman Flash utility crashing would probably also indicate a fault in the receiver and would specifically IMO rule out Girder as a cause (but not any hardware in your PC).

[cjean]

Just to make sure, are you overclocking your PC or anything like that? Although the UARTs should have their own clocks so that shouldn't have any bearing on the matter. The fact that the Edgeport's own log shows the error would indicate to me that the problem is with the receiver. I'd recommend asking HK whether they have any test software that they could send you to run on your PC to communicate with the receiver. Also if you have another PC (or can borrow one) then it would be worth trying on that.

The Harman Flash utility crashing would probably also indicate a fault in the receiver and would specifically IMO rule out Girder as a cause (but not any hardware in your PC).

Rob,

No I'm not a big overclocking fan. Since I want to keep things cool, overclocking is out of the question. I agree with you in regards of the receiver. As soon I turn ON the main switch of it, I'm able to sync both device correctly since I'm able to send code and receive them in good shape but it seems to deteriorate over the time ( within 5 min of operation ) and this would indicate that baud rate of the receiver might be slightly off. I dough that all the hardware I tried is defective…

As for the Edgeport, I got it cheap from Ebay and looks to be more trustable than onboard COM port. I highly recommend it; I was able to narrow down my problem with it.

The only software I can get from HK is Harman's Operating Console that is built to test functions like an IR remote and also to flash their eprom. I tied this software from my laptop and computer and still unsuccessful communication.

I asked to have my receiver to be RMA'd and the guy from Harman his pissed off.

What a story, all the planets of the solar system were aligned to this happen to me!

Charles

[cjean]

Lots of framing errors in there, this usually means either a mismatch in the serial settings or that the clocks are out of sync between the two ends.

Interestingly, every framing error is accompanied by a BREAK and TX CPS increasing from 0 in multiples of 14 cps.

I'm not entirely sure what this means. One possibility is that there's a problem with the receiver itself, alternatively one of the serial settings is wrong and perhaps the manual is lying about the correct settings.

I can't remember whether I'd asked you previously, do HK have any test programs that you can run on a PC to check that the receiver can communicate correctly?

Rob,

I didn't receive any answers yet from Harman to replace my unit but I might have found something interesting. Those 14 caracter set found in the TX CPS are the 14 characters for the MUTE command (PCSEND,02,04,80,70,C1,3E,checksum 2 bytes) I sent to the receiver. Since the Edgeport logger was set to log at 1 sec interval, at one moment in my test, I triggered many of those consecutively and this might be the numbers we see increasing from 14 to 28 and 42 and going back to 0.

This still doesn't explain the break & framing error. After these observations do you still think that the receiver is defective or it might be more related to bad settings?

Here I have joined Harman console utility. Maybe in there you can find the proper COM settings?

Thank you,

Regards,

Charles

[Rob H]

You could try PortMon (http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/Portmon.mspx) to see what settings are being used for the COM port with the HK config software. Then try with Girder and post both here.

The settings you have in your Lua file look as though they match the documentation to me.

I note that barca0 who posted the HK Lua file has ditched his AVR435 anyway.

[cjean]

Hi Rob,

I just did a test with Hyperterminal using a physical com port and the conclusion is... the receiver start to go crazy after about 5 min of operation. That exclude Girder!

I will post back my result when I'll get the new receiver.

Thank again for you great help, another reason why we should all pay the software we are using!!!

Regards,

Charles

[cjean]

You could try PortMon (http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/Portmon.mspx) to see what settings are being used for the COM port with the HK config software. Then try with Girder and post both here.

The settings you have in your Lua file look as though they match the documentation to me.

I note that barca0 who posted the HK Lua file has ditched his AVR435 anyway.

Yeah I've seen that barca0 threw away his receiver... just don't know why, maybe we have something in common :???:

Thanks for the link, I'll try portmon.

Thanks again

Charles

[cjean]

Hi Rob,

End of story here, after months :) Ended with a Denon 2308CI and couldn't be more happy.

Harman is just plain junk for automation with it's RS232 port.

Hope this will help others.

Charles

[Rob H]

Denon is generally pretty good :)

[tres_1tc]

Don't let the guys at Harmon tell you that there RS232 port works with Crestron beautifly, cause it does not. 4 years later and this AVR-445 is still in production with the same issues as all the threads describe. Had one working with a Crestron processor today, then the AVR just stopped working. Get nothing but garbage back from the AVR's rs232 port. Tried every trick i knew and i am really familiar with controling devices RS232 being that I am a Crestron programmer of 6 years. Never have i come across such a lame protocol since the JVC DVD recorder SR series. Manufacturers act as if their product could never be the problem... Never had a problem controlling a Denon, Marantz, etc.. for the same price as this big silver door stop.
I can't believe you stuck with the AVR for as long as you did to try and get it to work. I determined after an hour that the AVR was to blame and didn't waste my time any further.

[cjean]

Don't let the guys at Harmon tell you that there RS232 port works with Crestron beautifly, cause it does not. 4 years later and this AVR-445 is still in production with the same issues as all the threads describe. Had one working with a Crestron processor today, then the AVR just stopped working. Get nothing but garbage back from the AVR's rs232 port. Tried every trick i knew and i am really familiar with controling devices RS232 being that I am a Crestron programmer of 6 years. Never have i come across such a lame protocol since the JVC DVD recorder SR series. Manufacturers act as if their product could never be the problem... Never had a problem controlling a Denon, Marantz, etc.. for the same price as this big silver door stop.
I can't believe you stuck with the AVR for as long as you did to try and get it to work. I determined after an hour that the AVR was to blame and didn't waste my time any further.


Good for you! You are smarter than me or you just have more experience since it was my first RS232 integration without any knowledge about it.

Now I think you understand why I spent so much time trying to make it work....:cool:

Charles

[tres_1tc]

Definitely not smarter - maybe a little more experience with RS232... but not smarter :)

I just hate hearing stories like yours when there are so many products out there that work beautify.
glad to hear you got the 2308CI - great piece. HDMI is a little sketchy at times but really really great piece of gear.

cheers

[ghaun]

Does anybody know if the girder AVR435 plugin can handle more than one receiver. I have 3 of the AVR435 receivers that I would like to control.

[ghaun]

...........

[cjean]

I don't think you have limitations as far as the number of device you can use. Just assing them to different COM ports.

Charles

[ghaun]

All,

It's odd that you could never get this too work. I have 5 AVR435 working with girder through the serial port using an Edgeport 8. The only difference that I can see if that I have StopBits = 1. I do have a problem though. Everything works except for volume from the serial port.

Any ideas?

Thanks,

Greg