PDA

View Full Version : How to start to control a Rotel from a PC?



fabiospark
March 12th, 2006, 01:48 PM
I read some posts but most of them are quite old and talking about something else.
I'm would like to have feedback from my Rotel RSP1068 and to control it with an ATI remote.
Questions:

1 - what app do I need? Is Girder alone enough?
2 - which plugins do I need?
3 - is still around a Rotel plugin?

Thanks.

Promixis
March 12th, 2006, 04:19 PM
You need G4 Pro.

There might be Rotel serial setup around - I think I help someone write one. If not, it shouldn't be too difficult.

fabiospark
March 13th, 2006, 02:02 AM
...mmmm... No way with Girder 3.3?

Francois
March 13th, 2006, 06:43 AM
Girder 3 will do fine...

You should be able to adapt the RSX-1055 file which can be found at http://www.promixis.com/downloads.php to work with your device (the serial protocol is described on the rotel website and shouldn't be too bad to convert to your processor)

I'm in the process of updating this file to work with Girder4, which I've found to be more reliable... but Girder3 is already quite good ;)

fabiospark
March 13th, 2006, 07:41 AM
Thank you but the link points to the trials download page.
Do you mind giving me some other link to the file?
Thanks.

Rob H
March 13th, 2006, 08:09 AM
http://www.promixis.com/download.php?ID=330

fabiospark
March 13th, 2006, 09:56 AM
Thanks.
I see it's a .ini file: what am I supposed to do with it?

(Sorry but I'm a newbie with serial etc).

Promixis
March 13th, 2006, 10:05 AM
Thanks.
I see it's a .ini file: what am I supposed to do with it?

(Sorry but I'm a newbie with serial etc).

have a look at the readme included with the serial plugin download.

Francois
March 13th, 2006, 12:05 PM
Sorry, there should have been a readme file... :oops:

Go into Girder / Settings/ Plugins / Generic Serial / [Settings Button] / [Import] , and import the .ini file

I hope this helps!

fabiospark
March 13th, 2006, 02:50 PM
OK, thanks.
I imported the ini file and set it to COM1. Now, when I push a button on the Rotel I can see the Girder light blink.

I tried learning an eventstring and all I got is "RMX 1055" in the learnig display. I quickly set up a simple OSD and it shows whichever button I press.

I downloaded the Rotel RS232 info about both RMX 1055 and RSP 1068 to cross check and see the differences.

The first thing I see is that display data string patterns are different.

1055: 0xfe 0x17 0xc3 0x20 char1...char13 flag1...flag8 xx

1068: 0xfe 0x31 0xa1 0x20 char1...char42 flag1...flag5 xx

So I think the first thing I have to do is to change something somewhere. Looking around I saw there are many scrips: are they all summed up into that ini file?
Does that means that I can just edit that file?

I can't see the hex strings in the file or in the scripts: are they automatically translated into bin values? Is there an easy way to use the hex as in Rotel docs and end up with the correct values to be processed?

Was that file you gave me just for getting status info from tthe 1055 and not to drive it from the PC?

I'm asking this because in the file I could only see the display data flags processing.

As you can guess from all that above, I'm really an absolute beginner on the matter so expect some more questions in the near future. Just let me know when it's time to shut up.

Mark F
March 13th, 2006, 03:23 PM
You cannot edit that file directly.

To change values in that .ini file, go into Girder / File / Settings/ Plugins / Generic Serial / [Settings Button]. Make sure the RSX-1055 is the current value in the dropdown list and press Choose. This opens the main setting page for the RSX-1055 serial device.

The LUA code you want to change is attached to three different serial plugin events: The enable event (this runs every time the serial plugin is loaded), the transmit event (this runs before any data is sent to the Rotel) and the receive event (this runs after data is received from the Rotel). Use the define button in the enable event to open the script editor and change the LUA code to match your protocol. The transmit and receive event scripts definition buttons are on the transmit and receive message definition dialogs.

I know you are a noob and have ventured into the deep end of the pool. I hope you don't drown. :D

fabiospark
March 13th, 2006, 04:37 PM
I found this script in the transmit section:

SERIAL_SendData("RSX-1055","FE03C310"..SerialValue..format("%02X",mod(214+tonumber(SerialValue,16),256)))

I changed the proper section to ......"RSP-1068","FE03A110"...........
then I created a dummy command, went to the "plugins" tab, and in the settings I tried "00B4", closed it and then, magically, when I F5 on the dummy I can see my Rotel step up the volume!

The volume up is in the "Type 10" commands list.

Now, what should I change to be able to choose also among the other types of commands (14,15,16 etc)? Yes, I know I could change the last two digits in the string above but I would like to be able to choose the type without having to change the script each time.
I mean: now, to configure a command I want to use, I have to insert 4 digits in the "plugin" tab settings. I want to go having to insert 6 digits instead, the first two being the command type.
Do you mind clearing a bit the many sections of the script above?

Thank again.

(there are some good snorkels here, around the forums....)

Francois
March 13th, 2006, 05:43 PM
Ok,

I see you've taken the brute solution of sending codes such as 00B4 (the orginal code calculated the 'B4' checksum number based on the first two hex digits.. and would not work with your processor, as the 214 constant would then have to be replaced by 180, if I calculate it right), this will make the adaptation much easier :wink:

You just need change the SendData to:

SERIAL_SendData("RSX-1055","FE03A1"..SerialValue)

where serial value would then be something like 1000B4 (RMC Vol+) or 1502BB (Record CD)

Simple, isn't it :D


To interpret the RSP->PC messages, the script will require some adaptation (It should not be too had to adapt, as the protocols are similar... in fact, you won't need the 'expand' adjustments to add punctuation signs where they belong, as your processor handles this in a much simpler way).

I suggest you look at the flags for your device and compare them to the ones on a RSX-1055 to see what changes.

The receive code I wrote way back when needs just a small tweak: replace the 26 literal number by 52 (You could also change the name of the events generated, but that's not required)



if SerialValue == "FE" -- 0xFE starts a new message (using serial value as integer results in problems when value is 0)
then
if RSX.string ~= nil then
if (strlen(RSX.string)>2) and (strlen(RSX.string) - 3 == strbyte(RSX.string,2))
then -- a command was just sent
local i
RSX.tohex = ""
for i = 1,strlen(RSX.string) do
RSX.tohex = RSX.tohex..format("%02x",strbyte(RSX.string,i))
end
TriggerEvent("RSX-1055 - ACK",18,RSX.tohex)
else -- There is an incomplete message waiting
TriggerEvent("RSX-1055 - Truncated",18,strsub(RSX.string,5,-1))
end
RSX.last_string = RSX.string
end
RSX.string = strchar(tonumber(SerialValue,16))

else
if RSX.string == nil
then TriggerEvent("RSX-1055 Unknown",18,'Byte '..SerialValue)
else RSX.string = RSX.string..strchar(tonumber(SerialValue,16))
end
end

if RSX.string ~= nil and strlen(RSX.string) >= 52
then
RSX.last_string = RSX.string
TriggerEvent("RSX-1055",18,RSX_expand(RSX.string), RSX_input(RSX.string), RSX_output(RSX.string), RSX_radio(RSX.string), RSX_processing(RSX.string), RSX_status(RSX.string))
RSX.string = nil
end


I hope this helps

Eiffel

fabiospark
March 14th, 2006, 02:58 PM
You just need change the SendData to:

SERIAL_SendData("RSX-1055","FE03A1"..SerialValue)

where serial value would then be something like 1000B4 (RMC Vol+) or 1502BB (Record CD)

Simple, isn't it



Yes, it is. Not properly understanding the details of the transmit string, I thought I had to change the part inside the parenthesis if I changed the length of the part outside (constant "FE03A110").
I tried cutting away the final "10" and adding it to the string I put in the text box and it works.

Thanks one.


The receive code I wrote way back when needs just a small tweak: replace the 26 literal number by 52 (You could also change the name of the events generated, but that's not required)

Is that due to the fact that 1055 string format has 13 chars and 8 flags plus the control 5 (total 26) and the 1068 has 42 chars and just 5 flags plus the control 5 (total 52)?
Once again, my little (almost null...) understanding of the script made me guess that I had to make many more changes to adapt the thing to the new string length.

Thank two.


To interpret the RSP->PC messages, the script will require some adaptation (It should not be too had to adapt, as the protocols are similar... in fact, you won't need the 'expand' adjustments to add punctuation signs where they belong, as your processor handles this in a much simpler way).

I suggest you look at the flags for your device and compare them to the ones on a RSX-1055 to see what changes.


I printed both 1055 and 1068 Rotel commands list and protocols.
I think I understand how to change the command codes and their decription in the enable event script inside the RSX_input etc functions but I wonder if I have to change something else due to the different length and lay-out of the display data string. I mean, for 1055, flag 1 comes after char 13; for 1068, flag 1 comes after char 42: is the receiving script that does all the interpreting according to the position, or I have to change some function here in the enable event script (I mean apart from command codes and descriptions)?

Once I'll be tuned completely to the 1068, how will I use the receiving codes to trigger events? Will I have to learn all of them? Will I be able to pass the event description strings coming from the 1068 directly to an OSD, for instance? Or maybe through a variable?

Thanks three.

Francois
March 14th, 2006, 05:00 PM
Hi, glad that my last post was well understood :P

The interpreting of position is done in the flag1 = strbyte(RSX_str,18 ) and related commands.

With a RSX-1055, the first flag starts at position 18 (position 1 always contain 0xFE, position two is 0x17 - with corresponds to the length of each message in base 16: 1*16+7=23), ..., positions 5 to 17 correspond to char1 to char 13).

The same principles apply to your processor, and you indicated that you understood how to adapt the existing scripts

In terms of events generated, I suggest you enable the logger plugin to see the major event ("RSX-1055") and the associated payloads each time something changes on your processor. pld1 contains the text shown on the display and could go straight to a VFD, pld2, pld3, etc. contain some more information in a text format which could also go to a VFD if you'd like.

Alternatively, some of the messages could be converted into variables (for instance a variable containing the volume level, etc.). If you're interested in this, and got to the point where messages are generated correctly, I'd be glad to show you a working example...

... one last note. You should consider yourself lucky to be using Girder 3, as my revised version of these scripts is written in a elegant -my view!- but harder to understand way)

Good luck

Eiffel

fabiospark
March 15th, 2006, 03:41 PM
OK. I'm getting strings from the 1068.

Now what?

Mostly, I would like to get:

- some feedback from the RSP about the action I've just sent ("ok, I raised the volume a bit after you sent me the command "vol +")

- the status of the machine (the sources of main zone, zone 2 and rec out; the volume level; the output setting etc) when asked with a sort of an "how are you?" command.

I tried changing a bit in the lists where you get the values of the flags but I got some error on the logger. . (Is it correct thinking to change the numbers in the strbyte function to mach the different string pattern of the 1068? (i.e. 47 for flag 1 and so on).

I'm not sure I completely understand the script in the "receive" tab. As usual, I have the doubt that changing something in the last TriggerEvent command I would have to change something somewhere else.

You talked about punctuation; in the strings I'm receiving I can see wrong dots and commas...

For now I'm not interested in sending anything to a VFD but only to an OSD.

Thanks again in advance.

Francois
March 15th, 2006, 04:43 PM
You're making good progress... to try to speed things up for you, try replacing all the define code with the following text (which implements some, if not all the flags, as I don't know what they indicate on your display)


RSP = {}

function querybit(flag, bit)
return( band(flag,shiftl(1,bit)) ~= 0)
end

function insert_text(receiving_string,to_be_added, position)
return(strsub(receiving_string,1,position)..to_be_ added..strsub(receiving_string,position+1))
end

function RSP_input(RSP_str)
local RSP_input_txt
local flag1
RSP_input_txt = ""
flag1 = strbyte(RSP_str,47)
if querybit(flag1,0) then RSP_input_txt = RSP_input_txt.."[A] " end
if querybit(flag1,7) then RSP_input_txt = RSP_input_txt.."Optical " end
if querybit(flag1,6) then RSP_input_txt = RSP_input_txt.."Coax " end
if querybit(flag1,5) then RSP_input_txt = RSP_input_txt.."1" end
if querybit(flag1,4) then RSP_input_txt = RSP_input_txt.."2" end
if querybit(flag1,3) then RSP_input_txt = RSP_input_txt.."3" end
if querybit(flag1,2) then RSP_input_txt = RSP_input_txt.."4" end
if querybit(flag1,1) then RSP_input_txt = RSP_input_txt.."5" end
return(RSP_input_txt)
end

function RSP_output(RSP_str)
local RSP_output_txt
local flag4
local flag5
flag7 = strbyte(RSP_str,50)
flag8 = strbyte(RSP_str,51)
RSP_output_txt = 0
if querybit(flag5,6) then RSP_output_txt = RSP_output_txt+1 end
if querybit(flag5,7) then RSP_output_txt = RSP_output_txt+1 end
if querybit(flag5,5) then RSP_output_txt = RSP_output_txt+1 end
if querybit(flag5,4) then RSP_output_txt = RSP_output_txt+1 end
if querybit(flag5,3) then RSP_output_txt = RSP_output_txt+1 end
if querybit(flag5,2) then RSP_output_txt = RSP_output_txt+.1 end
if querybit(flag5,1) then RSP_output_txt = RSP_output_txt+1 end
if querybit(flag5,0) then RSP_output_txt = RSP_output_txt+1 end
if querybit(flag4,0) then RSP_output_txt = RSP_output_txt+1 end
return(RSP_output_txt)
end

function RSP_processing(RSP_str)
local flag2
local RSP_processing_txt
flag2 = strbyte(RSP_str,48)
RSP_processing_txt = ""
if querybit(flag2,7) then RSP_processing_txt = RSP_processing_txt.."DD" end
if querybit(flag2,6) then RSP_processing_txt = RSP_processing_txt.."DPL" end
if querybit(flag2,5) then RSP_processing_txt = RSP_processing_txt.."dts" end
if querybit(flag2,4) then RSP_processing_txt = RSP_processing_txt.." THX" end
if querybit(flag2,3) then RSP_processing_txt = RSP_processing_txt.." EX" end
if querybit(flag2,2) then RSP_processing_txt = RSP_processing_txt.."DSP" end
return(RSP_processing_txt)
end

function RSP_status(RSP_str)
local flag3
local flag4
local RSP_status_txt
flag3 = strbyte(RSP_str,49)
flag4 = strbyte(RSP_str,48)
RSP_status_txt = ""
if querybit(flag3,3) then RSP_status_txt = RSP_status_txt.."Standby " end
if querybit(flag3,1) then RSP_status_txt = RSP_status_txt.."Display Off " end --not sure this is correct
if querybit(flag4,0) then RSP_status_txt = RSP_status_txt.."Zone " end
return(RSP_status_txt)
end


Now, in the receive section, put this:


if SerialValue == "FE" -- 0xFE starts a new message (using serial value as integer results in problems when value is 0)
then
if RSP.string ~= nil then
if (strlen(RSP.string)>2) and (strlen(RSP.string) - 3 == strbyte(RSP.string,2))
then -- a command was just sent
local i
RSP.tohex = ""
for i = 1,strlen(RSP.string) do
RSP.tohex = RSP.tohex..format("%02x",strbyte(RSP.string,i))
end
TriggerEvent("RSP-1068 - ACK",18,RSP.tohex)
else -- There is an incomplete message waiting
TriggerEvent("RSP-1068 - Truncated",18,strsub(RSP.string,5,-1))
end
RSP.last_string = RSP.string
end
RSP.string = strchar(tonumber(SerialValue,16))

else
if RSP.string == nil
then TriggerEvent("RSP-1068 Unknown",18,'Byte '..SerialValue)
else RSP.string = RSP.string..strchar(tonumber(SerialValue,16))
end
end

if RSP.string ~= nil and strlen(RSP.string) >= 26
then
RSP.last_string = RSP.string
TriggerEvent("RSP-1068",18,strsub(RSP.string,5,46), RSP_input(RSP.string), RSP_output(RSP.string), RSP_processing(RSP.string), RSP_status(RSP.string))
RSP.string = nil
end


In theory, this should be all you need (assuming I haven't made any calculation or typing mistake, which is bound to happen).

Each time something changes on your processor display, you should see a RSP-1068 event, with pld1 equal to the text shown on the display...

Now it is just a matter of displaying this on the OSD. for this, you could use the Simple OSD command of Girder, associate it with the RSP-1068 event, and put in the icon/device field something such as

[pld1]
[pld2]
[pld3]
[pld4]
[pld5]

This wouldn't be too elegant, but would work

Good luck with the above... let me know how it goes!

fabiospark
March 16th, 2006, 07:25 AM
if SerialValue == "FE" -- 0xFE starts a new message (using serial value as integer results in problems when value is 0)
then
if RSP.string ~= nil then
if (strlen(RSP.string)>2) and (strlen(RSP.string) - 3 == strbyte(RSP.string,2))
then -- a command was just sent
local i
RSP.tohex = ""
for i = 1,strlen(RSP.string) do
RSP.tohex = RSP.tohex..format("%02x",strbyte(RSP.string,i))
end
TriggerEvent("RSP-1068 - ACK",18,RSP.tohex)
else -- There is an incomplete message waiting
TriggerEvent("RSP-1068 - Truncated",18,strsub(RSP.string,5,-1))
end
RSP.last_string = RSP.string
end
RSP.string = strchar(tonumber(SerialValue,16))

else
if RSP.string == nil
then TriggerEvent("RSP-1068 Unknown",18,'Byte '..SerialValue)
else RSP.string = RSP.string..strchar(tonumber(SerialValue,16))
end
end

if RSP.string ~= nil and strlen(RSP.string) >= 26
then
RSP.last_string = RSP.string
TriggerEvent("RSP-1068",18,strsub(RSP.string,5,46), RSP_input(RSP.string), RSP_output(RSP.string), RSP_processing(RSP.string), RSP_status(RSP.string))
RSP.string = nil
end

1 - Are you sure the parenthesys in line 4 are correct?

2 - Is it just cosmetics or else changing from RSP_string to RSP.string?

3 - After making the adjustments I'm getting this error: "Attempt to index global 'RSP' (a nil value) - stack trackback: 1: main of string "?" at line 20"

Of course the script is not working.

By the way: is there a way to have copy and paste functionalities in the script editor (or elsewhere with the ability to paste into the script editor itself)?

And find/substitute?

Thanks.

fabiospark
March 16th, 2006, 02:47 PM
Sorry, I completely missed the RSP={} header in the define script. Of course, without that, the RSP was not defined so...

Now I'm still getting strings instead of errors so, I go back testing.

Francois
March 16th, 2006, 03:48 PM
I'm not sure I understand where you're having some difficuties, or what questions you still have.

If you're getting errors instead of strings (rather than the other way around ;) )... what is the error message?

I believe that the syntax is correct, as I edited my working script (which may be more recent than the one on the promixis website... but should be functionally identical)... everything balanced and compiled ok when I tried it...

You should be able to copy and paste with Ctrl+C and Ctrl+V. Insert and replace will be harder to achieve (You'll have to upgrade to G4!)

Let me know where you're having problems and I'll try to give you a hand!

Eiffel

fabiospark
March 16th, 2006, 04:09 PM
OK. Everything is working now! I'm showing my little OSD with the feedback I get from the 1068.
Now I have also understood a bit more of your scripts and I've been able to break the string into three lines as the 1068 display has 2 lines of 21 chars but works as they were 3 or 4.
I wonder if I can get which are the sources of the three way outs: main zone, zone 2 and rec out.
Yes, I'm getting them when I go and push their buttons but I was hoping to get them as part of the general status of the ampli.
An annoying little thing is that when I mute the ampli my OSD stays out forever because the mute word keeps blinking on the FL display.
I thought (was hoping) that the feedback was not just the display feedback but the machine feedback.

Anyway, thanks a thousand for your kind and skilled help and for the time you spent for me.

I promise that sooner or later I'll post a GML file with all the most commonly used Rotel RSP 1068 commands ready to be associated to some remote control. And an exported .ini for the serial plugin too.

Thanks again.

Francois
March 16th, 2006, 04:40 PM
Great news and very happy to read that you got it working (remote debugging is not a pleasant occupation!)

I don't know how the 1068 display works, but on my machine, when adjusting say, Zone 2, the display will show something such as 'ZONE VOL xx' or 'ZONE TUNER' for a while before reverting to the normal dispaly... if this is the case, it's possible to keep in a Girder variable what the corresponding volume or source is:

if the text is in pld1, you could for instance have some code such as

if strfind(pld1,"ZONE TUNER") > 0 then zonesource = "Tuner" end
if strfind(pld1,"ZONE VID 1") > 0 then zonesource = "Video1" end

One of the issues with this approach is that, upon starting girder, zonesource may not have the right value... you thus have to make the processor display this type of information to initialise it...

The mute thing can be a mix blessing... on my VFD it's great because it make it blink. with a little bit of creativity, you could prevent girder from updating the OSD when the string 'MUTE' is contained in the text...

On your last comment, the way Rotel gear behaves (basically sending a message each time the display is updated) makes it very easy to mirror its display (more or less) on a VFD or OSD, but getting the status of each parameter (volume, sound processing mode, source by output, etc) is harder.

Some other devices require that you poll each parameter and return a response, one parameter at a time... oftentimes they won't let you know if anything has changed... so to monitor volume, you have to poll for it repeatedly -say every 1s- or put the gear in a closet, in which case you can assume that the computer is the only way to change a parameter... so there is no perfect solution

Enjoy your processor and the benefits of integration with Girder!