Results 1 to 7 of 7

Thread: Rotel serial users: question

  1. #1
    Join Date
    Aug 2002
    Location
    New York, NY
    Posts
    253

    Default Rotel serial users: question

    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?

  2. #2
    Join Date
    Sep 2001
    Location
    London
    Posts
    312

    Default

    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?

  3. #3
    Join Date
    May 2004
    Location
    Cardigan, UK
    Posts
    9,278

    Default

    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.
    --Rob

  4. #4
    Join Date
    Aug 2002
    Location
    New York, NY
    Posts
    253

    Default

    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.

  5. #5
    Join Date
    May 2004
    Location
    Cardigan, UK
    Posts
    9,278

    Default

    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.
    --Rob

  6. #6
    Join Date
    Sep 2001
    Location
    London
    Posts
    312

    Default

    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):

    Code:
        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

  7. #7
    Join Date
    Aug 2002
    Location
    New York, NY
    Posts
    253

    Default

    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):

    Code:
    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+key,256))) -- second char sent does the checksum calculation	
        end,
    Thanks very much for your help!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •