Rotel serial users: question

[Agonostis]

Hi,

I am controlling my RSX 1057 via serial with G4Pro, but I have a weird issue that i'm trying to solve:

If the receiver receives a command that doesn't yield a result, it stops responding to serial commands.

e.g. - if the receiver is on, and i send it on, it won't respond the any further commands. if the receiver is on video1, and i send it the video1 command, it stops responding.

i can't tell if the problem is with Girder or with the receiver.

After the receiver stops responding, i can send it something from the IR remote, and all the backlogged commands will go through. that is, if it's on, and i send it on, then i send off, the receiver stays on. then if i send volume down on the remote, the volume goes down one notch, then the receiver turns off!

has anyone experience/solved something similar?

[Francois]

Agonostis,

I haven't seen this with my RSX-1055, which is a close relative to your receiver.

Are you using one of the serial scripts posted here, or did you develop your own lua code to interface with the receiver?

[Rob H]

This is a bit of a limitation of the serial code in Girder 4 - if you use a queued serial class then it expects a response for every command.

You could try using serial.Classes.Simple rather than serial.Classes.Queued as a parent class.

[Agonostis]

Thanks for the response guys. I used one of the queued serial classes here, and just changed the name and the prefix byte (or whatever it's called).

Will it be better/easier to make a class that inherits from the simple serial base, or to add some kind of logic that checks the current state of the receiver before sending the requested command?

If this is something in the G queued serial classes, i'm surprised none of the other users have seen this.

[Rob H]

One other alternative if you know that a command won't return a response is to set self.ResponsePending to false after sending that command.

[Francois]

A simple solution (albeit a bit crude) is to use the SendCommand function for any command sent to the receiver, as in the following code (for a RSX-1055):



SendKey = function(self,key) -- Sends commands to the receiver. Key is a numeric value (RMC_VOL_UP = 0, etc...)
self:SendCommand(string.char(key,math.mod(214+key, 256))) -- second char sent does the checksum calculation
end,


Yes, in theory, some commands could be lost in the process, but, if need be, you could catch the response from the receiver, or use the refresh (#255) command to elicit a response from the receiver after each command.

Eiffel

[Agonostis]

Francois,

Your solution is working so far. I made two slight modifications to work with the 1057 (changed the checksum base, and added the extra 10h byte):



SendKey = function(self,key) -- Sends commands to the receiver. Key is a numeric value (RMC_VOL_UP = 0, etc...)
self:SendCommand(string.char(16,key,math.mod(218+k ey,256))) -- second char sent does the checksum calculation
end,


Thanks very much for your help!