Russound RNet Driver

[ToyMaster458]

Here is a beta version for the Russound RNet Driver that includes User Events upon a Keypad Buttons Press or 12VDC Page Trigger. I also added a CxZxSourceShared field to display if the zones source is in use on another zone as well.

The Driver raises an event of "Button" with the value of "zzsbutton" where "zz" is the zone number from 1-36, "s" is the current source of the zone when the button was pressed and "button" is the name of the button pressed (Previous, Next, Plus, Minus, Stop, Pause, Fav1, Fav2, Play, Source).

The Driver raises an event of "System" with the value of "Page" when the 12VDC Page Input is Triggered

Added Input 1-10 to the Generic Commands.

Added the Following Fields

TextSourceDisplay - Sends a 12 character text message to the indicated Source(s). It is a string field which has legal value of the ASCII Character Set - Note, writing to this field causes data to be sent to the keypad(s)s using the source address, source repeat and flash time values.

TextAddressSource - Source number (0-7, 0 means all sources)

TextSourceRepeat - Has the Driver Keep Repeating the Source Text on the Keypads untill a new source text value is sent

CxZxSourceShared - If True the current used source is also in use on another zone.

SystemOn - True if any of the zones are on and False if they are all off

Fixed ZoneSource on multiple Controllers.
Added Support for the ACA-E5 Controller and Expanders
Fixed Handshaking response for all models

Here is a list of other Driver Enhancements that I will try and add.


None suggested at this time


Posted Version 1.19

[dman000000]

TM,

Just wanted to let you know that the revised driver seems to be working well thus far (tested across a couple zones and controllers). Thanks again for taking the time to do this.

If the revised driver is going to be submitted to Dean for official release, would it be possible for you to add one other change to the file as well? The generic source control list appears to be incomplete in the protocol documentation from Russound, but these controls are listed in the user's manual.

The following should be added to the Enum=GenericCommands section to allow for more robust control of connected equipment:

Input1 : "5A";
Input2 : "5B";
Input3 : "5C";
Input4 : "5D";
Input5 : "5E";
Input6 : "5F";
Input7 : "60";
Input8 : "61";
Input9 : "62";
Input10 : "63";

I changed this in my local version (first time ever playing with a driver) and it appears to be functioning as expected.

Thanks again,
Derrick

[ToyMaster458]

I just uploaded version 1.6 that includes your requested changes. Good job finding those undocumented commands.

[dman000000]

TM,

Overall the user event for the UNO buttons is working smoothly. Now that I am doing some more with it, I have noticed some quirkiness in the value of the event that is generated by the button presses. Specifically, the "Source" portion of the event is not always in sync with the actual source that the keypad is set to.

I confirmed this by viewing the cqceventdump and the applicable cqc driver zone field while toggling through some UNO button presses. Starting with power on everything seems synced when pushing UNO transport buttons. Pushing source on the keypad then some transport buttons often shows a lag in updating the source portion of the event value - despite the fact that the driver shows an immediate update to the source.

an example:
push power on keypad 5 <source=1 on the UNO screen and the cqc driver>
push stop: evdata=051Stop

push source <source=2 on the UNO screen and the cqc driver>
push stop: evdata=051Stop

push stop again: evdata=051Stop

push stop again: evdata=052Stop

Additional testing shows that it is not a consistent 1 or 2 additional button pushes (or dependent on which button is pressed) before it syncs to the correct source. I haven't been able to identify if it is simply a time delay thing but it's not like i am trying to push in extremely rapid succession.

Was hoping you might have a sense of what is going on or could take a quick look.

Thanks!

[ellisr63]

Any chance on getting the all on and all off to actually be read from a widget... ie if all are on the button would show on but if one is off the button would be off? Currently if one is on it displays on for all on.

[ToyMaster458]

TM,

Overall the user event for the UNO buttons is working smoothly. Now that I am doing some more with it, I have noticed some quirkiness in the value of the event that is generated by the button presses. Specifically, the "Source" portion of the event is not always in sync with the actual source that the keypad is set to.

I confirmed this by viewing the cqceventdump and the applicable cqc driver zone field while toggling through some UNO button presses. Starting with power on everything seems synced when pushing UNO transport buttons. Pushing source on the keypad then some transport buttons often shows a lag in updating the source portion of the event value - despite the fact that the driver shows an immediate update to the source.

an example:
push power on keypad 5 <source=1 on the UNO screen and the cqc driver>
push stop: evdata=051Stop

push source <source=2 on the UNO screen and the cqc driver>
push stop: evdata=051Stop

push stop again: evdata=051Stop

push stop again: evdata=052Stop

Additional testing shows that it is not a consistent 1 or 2 additional button pushes (or dependent on which button is pressed) before it syncs to the correct source. I haven't been able to identify if it is simply a time delay thing but it's not like i am trying to push in extremely rapid succession.

Was hoping you might have a sense of what is going on or could take a quick look.

Thanks!
It does sound like a timing issue. I will look into this tomorrow.

[ToyMaster458]

Any chance on getting the all on and all off to actually be read from a widget... ie if all are on the button would show on but if one is off the button would be off? Currently if one is on it displays on for all on.
I add this to the list of feature enhancements

[ToyMaster458]

TM,

Overall the user event for the UNO buttons is working smoothly. Now that I am doing some more with it, I have noticed some quirkiness in the value of the event that is generated by the button presses. Specifically, the "Source" portion of the event is not always in sync with the actual source that the keypad is set to.

I confirmed this by viewing the cqceventdump and the applicable cqc driver zone field while toggling through some UNO button presses. Starting with power on everything seems synced when pushing UNO transport buttons. Pushing source on the keypad then some transport buttons often shows a lag in updating the source portion of the event value - despite the fact that the driver shows an immediate update to the source.

an example:
push power on keypad 5 <source=1 on the UNO screen and the cqc driver>
push stop: evdata=051Stop

push source <source=2 on the UNO screen and the cqc driver>
push stop: evdata=051Stop

push stop again: evdata=051Stop

push stop again: evdata=052Stop

Additional testing shows that it is not a consistent 1 or 2 additional button pushes (or dependent on which button is pressed) before it syncs to the correct source. I haven't been able to identify if it is simply a time delay thing but it's not like i am trying to push in extremely rapid succession.

Was hoping you might have a sense of what is going on or could take a quick look.

Thanks!
Well I figured out what is going on. The Source field is only updated durring polls and not on a Source Button Press so even the Source Field is reading the wrong value untill the next poll. What I will have to do to resolve this issue is listen for the Source Button Press and then either that packet will have thenew source information or poll for an update.

[ToyMaster458]

Ok there is a response that is sent from the controller that includes the new source number. I got part of it decoded and sent an email off to Russound to see if I can get more documentation on that message type since it is not included in thier protocol document.

[ToyMaster458]

I just got another document from Russound that will answer a few questions about their protocol. I will try and get back on this in the next couple of days.

[ellisr63]

I just got another document from Russound that will answer a few questions about their protocol. I will try and get back on this in the next couple of days.
I am glad you are able to get info from Russound... I know others have tried in the past with no luck.

[sic0048]

It probably doesn't hurt that the request came from an integration company and not just some "Joe-blow" off the street.

[ToyMaster458]

Version 1.7 has been uploaded. This should take care of the issue of the correct Source number being sent with the Button User Event. I also added the ability to send text to keypads on all or select sources

[robertmee]

Version 1.7 has been uploaded. This should take care of the issue of the correct Source number being sent with the Button User Event. I also added the ability to send text to keypads on all or select sources

Nice work!

[ToyMaster458]

I am working on the scrolling text and I see how the cav66.exe is doing it and now it is a matter of understanding it.

[ToyMaster458]

Version 1.8 Posted

I got the scrolling text working along with a repeat function that will keep repeating the scrolling text on the keypads until a new source text value is written.

If this functions properly I can add the same abilities to the Keypad text

[ellisr63]

sounds good!

[ToyMaster458]

I just noticed a issue with verion 1.8, it broke what version 1.7 fixed. I am having an issue with the driver capturing all the serial port messages and will work on it more.

[jmwhooper]

Is v1.8 the most recent beta of the RNet driver?

Can I just confirm what people are doing to use the UNO keypads to control CQC. Are you using triggers on the Russound driver fields so when a value changes an action is triggered. E.g. Press play on the UNO to play the CQC Audio player when that source is active?

I noticed yesterday that on some fields I can't select the triggers as the button is disabled. Is this the case or am I missing something?

Thanks

[robertmee]

Is v1.8 the most recent beta of the RNet driver?

Can I just confirm what people are doing to use the UNO keypads to control CQC. Are you using triggers on the Russound driver fields so when a value changes an action is triggered. E.g. Press play on the UNO to play the CQC Audio player when that source is active?

I noticed yesterday that on some fields I can't select the triggers as the button is disabled. Is this the case or am I missing something?

Thanks

No they are using User Action Events which are a specialized trigger not based on a field. The RNET driver generates a user action event called Button. You set up a trigger that monitors this event (it is not a field) and then run your action based on the value sent by the event (which button, zone and source). Follow the example in the other Russound thread that dman posted: http://www.charmedquark.com/vb_forum/showthread.php?t=3984&page=9

[ToyMaster458]

Speaking of v1.8 I am getting mixed results in my testings. Is anyone else using v1.8 and how is it working?

[gacevich]

i have been running v1.6 with no issues. will download v1.8, give a spin and report back.

[jmwhooper]

No they are using User Action Events which are a specialized trigger not based on a field. The RNET driver generates a user action event called Button. You set up a trigger that monitors this event (it is not a field) and then run your action based on the value sent by the event (which button, zone and source). Follow the example in the other Russound thread that dman posted: http://www.charmedquark.com/vb_forum/showthread.php?t=3984&page=9

Thanks for the info. I don't understand enough yet on Action Events, I'll read up the pdf about them?

Before I start though, I just tried to replicate the code in the other thread to capture a user action and nothing appeared in the dump. Is there anything I need to do with the Russound CAV config, or a component on CQC I should have installed to get the User Action Triggers working? --Ignore this, I was still on V1.4, now I'm on 1.8 it's working fine.

[gacevich]

been putting v1.8 thru its paces this evening and it seems to work fine. i have uno-s1's and all i am doing with it is to move to the next preset on tuner. next step is ability to play playlists once itunes issues are resolved.

[ToyMaster458]

Is the Zone Source field updating properly and quickly after the source is changed?

[gacevich]

hmmm...when turning the uno on and changing sources there is a short delay (4 sec?) before the next and previous commands start working. however, once they do for that source, response seems fine. didn't notice the delay when just changing sources and the uno is on.

[jmwhooper]

Now I've got the user events working for the Uno keypads I'm looking at setting trigger events on things like play status or CurItemName of CQSL audio player, so they send text to the uno keypads when playing starts, or the track name changes regardless of whether it was changed on a CQC touchscreen or an Uno.

Is there an easy way to send text to multiple keypads where the src is the same as the one that changed (i.e. to Zone 2 and 3 only) or do I have to create an if statement for each Zone and if the zone source is the same source as the one that changed, set the keypad address, zone etc then update the text, thus updating one by one?

Are other people doing this now? Are there any tips as this could prove quite complicated with plenty of "if" statements to check zones and sources then performing an action?

[robertmee]

Now I've got the user events working for the Uno keypads I'm looking at setting trigger events on things like play status or CurItemName of CQSL audio player, so they send text to the uno keypads when playing starts, or the track name changes regardless of whether it was changed on a CQC touchscreen or an Uno.

Is there an easy way to send text to multiple keypads where the src is the same as the one that changed (i.e. to Zone 2 and 3 only) or do I have to create an if statement for each Zone and if the zone source is the same source as the one that changed, set the keypad address, zone etc then update the text, thus updating one by one?

Are other people doing this now? Are there any tips as this could prove quite complicated with plenty of "if" statements to check zones and sources then performing an action?

From post #13 by TM:

Version 1.7 has been uploaded. This should take care of the issue of the correct Source number being sent with the Button User Event. I also added the ability to send text to keypads on all or select sources

[ToyMaster458]

I just uploaded the new driver documentation to the first post in this thread that includes all the new information.

[jmwhooper]

The updated documentation mentions that text sent to the Uno that is longer than 12 characters will scroll, is this the case as it doesn't seem to.

Also, the field "TextAddressSource", what does it do? If I write to it then send text will it send the text to all zones with that source active?

Finally, what is the status of media repo control via the Uno Keypads?

Thanks

[dman000000]

The updated documentation mentions that text sent to the Uno that is longer than 12 characters will scroll, is this the case as it doesn't seem to.

Also, the field "TextAddressSource", what does it do? If I write to it then send text will it send the text to all zones with that source active?


the text address source command will output text to only those UNOs that are currently powered on and on the source provided in the command. works very well during my testing thus far.

as for scrolling, i am scrolling repeated song title/artist info without any problems. i'm currently using a triggered event off of any change to the curitemname field of the audioplayer driver that sends updated track/artist info with each song change.

[dman000000]

I am having a serious admin issue with this new russound driver. Everytime I reboot the server machine, the driver defaults back to v1.4 (the one included in the 2.2.7 drop). Is there something that I need to do to preserve the use of a beta driver so this doesn't happen?

[robertmee]

I am having a serious admin issue with this new russound driver. Everytime I reboot the server machine, the driver defaults back to v1.4 (the one included in the 2.2.7 drop). Is there something that I need to do to preserve the use of a beta driver so this doesn't happen?

Sounds like a conflict in the driver name. The new one that TM has been issuing should have something like "Russound - Dev" to differentiate it from the official drop driver. When you import it, does it show up as a separate listing or do you still only have one driver listed for Russound?

[jmwhooper]

the text address source command will output text to only those UNOs that are currently powered on and on the source provided in the command. works very well during my testing thus far.

as for scrolling, i am scrolling repeated song title/artist info without any problems. i'm currently using a triggered event off of any change to the curitemname field of the audioplayer driver that sends updated track/artist info with each song change.

The text address sounds perfect.

What are you doing for scrolling text. I've set up triggers too but it won't scroll. Could you add your code snippet. Thanks.

[dman000000]

Sounds like a conflict in the driver name. The new one that TM has been issuing should have something like "Russound - Dev" to differentiate it from the official drop driver. When you import it, does it show up as a separate listing or do you still only have one driver listed for Russound?

To be clear, I am adding the driver and selecting the -Dev. Everything works with the new functionality so I am sure that I am actually installing 1.8 correctly. After rebooting the server machine, I get errors associated with any commands that involve new fields added in the beta driver. Checking the driver info in the admin interface shows that I am somehow back at 1.4.

[dman000000]

The text address sounds perfect.

What are you doing for scrolling text. I've set up triggers too but it won't scroll. Could you add your code snippet. Thanks.

I have a triggered event setup for the CurItemName field of the player via the Field Browser of the Admin Interface (Send an event on any value change is selected)

Triggered event info:
Is Field Change For
Field: AudioPlayer1.CurItemName

OnTrigger Action:

Devices::FieldWrite
P1=CAV66.TextAddressSource
P2=1

Devices::FieldWrite
P1=CAV66.TextSourceRepeat
P2=True

Devices::FieldWrite
P1=CAV66.TextSourceDisplay
P2=$(AudioPlayer1.CurItemName) - $(AudioPlayer1.CurItemArtist)

[jmwhooper]

Yes that is it, I was using TextDisplay instead. Excellent work thank you.

[gacevich]

To be clear, I am adding the driver and selecting the -Dev. Everything works with the new functionality so I am sure that I am actually installing 1.8 correctly. After rebooting the server machine, I get errors associated with any commands that involve new fields added in the beta driver. Checking the driver info in the admin interface shows that I am somehow back at 1.4.


my system just rebooted and admin interface says i am also back a v1.4...and it ain't working right. will try to import package with v1.8 and see if it gets all better.

edit: it didn't get better

[Dean Roddey]

The development driver probably was not correctly marked as a development driver, so it probably has the same make/model as the official driver and is being overridden by it perhaps.

[ToyMaster458]

Dean

I have the following changes in the Manifest
CQCCfg:LibName="MEng.User.CQC.Drivers.Russound.RNET.DriverImpl"
CQCCfg:DisplayName="Russound RNet Serial-DEV"
CQCCfg:Version="1.8"

Do I also have to append -DEV to the Model?
CQCCfg:Model="RNET=Serial-DEV" ??

[Dean Roddey]

That looks reasonable. Is there really an = sign in the model? I'd get rid of that if so. You should stick to alpha numeric, underscore and hyphen generally.

[ToyMaster458]

The equal sign was done by the original developer :-D

[Dean Roddey]

Oh well, I guess it can't be changed now, since that would break everyone who has the driver loaded.

[dman000000]

Dean

I have the following changes in the Manifest
CQCCfg:LibName="MEng.User.CQC.Drivers.Russound.RNET.DriverImpl"
CQCCfg:DisplayName="Russound RNet Serial-DEV"
CQCCfg:Version="1.8"

Do I also have to append -DEV to the Model?
CQCCfg:Model="RNET=Serial-DEV" ??

I made the Model change to my manifest file for this driver and it seems to have addressed the overwriting issue upon reinstall.

[ToyMaster458]

I would like to get this release to Dean to be included in the next drop. Is anyone having any issues with the Beta? Also Mark asked me to remove the equal sign from the manifest to prevent any future issues that it may cause, this would break the current loaded driver as Dean mentioned.

[gacevich]

yep, having problem when master server reboots. it automatically reloads the non-development driver (v1.4) and i have to go back and change it the development driver (v1.8). fixing this issue would be greatly appreciated.

[dman000000]

Aside from the one needed change to the manifest file, it appears to be working great!

[Dean Roddey]

Remove the manifest from the DataServer\Manifests\User directory and restart the master server.

[Mark Stega]

Remove the manifest from the DataServer\Manifests\User directory and restart the master server. Don't do that - You'll revert to having only the shipped (1.4) driver. Instead, edit the manifest file in that directory and get rid of the "=" in the model and make certain that the model is different than the released version...

[Dean Roddey]

Oh, I read his post backwards for some reason. Sorry about that.

[ToyMaster458]

I uploaded a new version with the included manifest changes. I did not change the version number.

[ToyMaster458]

Uploaded version 1.9 to include Source Events

[gacevich]

just tried intstalling v1.9. install was unsucessful. here is what the log said.

http://i225.photobucket.com/albums/dd95/withmere/rnet19errorlog.jpg

is this an error on my part?

[Dean Roddey]

The CML couldn't be parsed, so something is awry with the driver code.

[ToyMaster458]

My Bad!!! Try downloading it again.

[jmwhooper]

Can you tell me what the 1.9 version has over 1.8, what are the Source Events? Is it just to capture pressing the source button on an Uno keypad?

[ToyMaster458]

Is it just to capture pressing the source button on an Uno keypad?
Yes, that is correct.

[gacevich]

with the updated version of v1.9 i am able to get the uno-s1 to recognize the source button. thanks. i had a lag condition that i could not get rid of via a pause condition. for example, in the code below, source 1 is actually the Radio. but is seems that the source that gets sent is not the new "Source" but rather the existing "Source" when Source is pressed. not a big deal.

// This routine changes the source display on the keypad as source button is pressed
If System::Equals(%(LVar:UNObutton), Source)
If System::Equals(%(LVar:UNOsource), 6)
Devices::FieldWrite(RussoundRNet.TextDisplay, Radio)
End


my bigger deal is that i still cannot figure out how to send the text for new "Source" to the keypad that was actually used. i reviewed the driver description and it says that text can be sent to an individual keypad. but when i try to program it to send text to an individual keypad i don't see a place to insert the keypad number. an example of how someone else has coded to send text to an individual keypad would be appreciated. thanks.

[Mark Stega]

my bigger deal is that i still cannot figure out how to send the text for new "Source" to the keypad that was actually used. i reviewed the driver description and it says that text can be sent to an individual keypad. but when i try to program it to send text to an individual keypad i don't see a place to insert the keypad number. an example of how someone else has coded to send text to an individual keypad would be appreciated. thanks.
Set the fields "TextAddressController", "TextAdressZone", and "TextAdressKeypad" to send text to an individual keypad.

[gacevich]

mark, thanks for the nudge but i looked a those fields too and i didn't see where the controller number was input. for fieldwrite commands the only options i see are for field and value. how do i adjust field to address only one controller? i know which keypad it is, just can't figure out the syntax to get it into the field. appreciate the help.

[robertmee]

mark, thanks for the nudge but i looked a those fields too and i didn't see where the controller number was input. for fieldwrite commands the only options i see are for field and value. how do i adjust field to address only one controller? i know which keypad it is, just can't figure out the syntax to get it into the field. appreciate the help.

As Mark said, you need to populate the fields that define your keypad. I don't have a Russound, but I assume something like this:

Devices::FieldWrite(RussoundRNet.TextAddressContro ller, 1)
Devices::FieldWrite(RussoundRNet.TextAddressZone, 1)
Devices::FieldWrite(RussoundRNet.TextAddressKeypad , 1)
Devices::FieldWrite(RussoundRNet.TextDisplay, Radio)

That'd be controller 1, Zone 1 and Keypad 1.

[gacevich]

As Mark said, you need to populate the fields that define your keypad. I don't have a Russound, but I assume something like this:

Devices::FieldWrite(RussoundRNet.TextAddressContro ller, 1)
Devices::FieldWrite(RussoundRNet.TextAddressZone, 1)
Devices::FieldWrite(RussoundRNet.TextAddressKeypad , 1)
Devices::FieldWrite(RussoundRNet.TextDisplay, Radio)

That'd be controller 1, Zone 1 and Keypad 1.

hmmm...interesting. not what i was expecting (and likely why i am confused). is it the case that if u say
Devices::FieldWrite(RussoundRNet.TextAddressKeypad , 1)
Devices::FieldWrite(RussoundRNet.TextDisplay, Radio)
cqc knows that you have identified keypad 1 to display the next textdisplay message?

well, i tried this:
If System::Equals(%(LVar:UNObutton), Source)
If System::Equals(%(LVar:UNOsource), 6)
Devices::FieldWrite(RussoundRNet.TextAddressKeypad , %(LVar:UNOkeypad))
Devices::FieldWrite(RussoundRNet.TextDisplay, Radio)
End

and the text showed up on all the keypads. i checked via the field browser and my UNOkeypad variable is the correct keypad that was pressed. did i format my code wrong? i tried both %(LVar:UNOkeypad) and (LVar:UNOkeypad).

[ToyMaster458]

Give this a try


If System::Equals(%(LVar:UNObutton), Source)
If System::Equals(%(LVar:UNOsource), 6)
Devices::FieldWrite(RussoundRNet.TextAddressContro ller, 1)
Devices::FieldWrite(RussoundRNet.TextAddressKeypad , 0)
Devices::FieldWrite(RussoundRNet.TextAddressZone, (LVar:UNOkeypad))
Devices::FieldWrite(RussoundRNet.TextDisplay, Radio)
End

[gacevich]

i tried this with both %(LVar:UNOkeypad) and (LVar:UNOkeypad) in the fieldwrite command

If System::Equals(%(LVar:UNObutton), Source)
If System::Equals(%(LVar:UNOsource), 6)
Devices::FieldWrite(RussoundRNet.TextAddressContr. .., 1)
Devices::FieldWrite(RussoundRNet.TextAddressKeypad , 0)
Devices::FieldWrite(RussoundRNet.TextAddressZone, LVar:UNOkeypad)
Devices::FieldWrite(RussoundRNet.TextDisplay, Radio)
End

i went backwards. nothing shows up on the keypad with this.

[ToyMaster458]

Can you post the rest of your code? What are you using to populate %(LVar:UNOkeypad) ?

[ToyMaster458]

Version 1.10 is uploaded with a User Event of 'System' and a value of 'Page' when the 12VDC Input on the controller is activated.

[ToyMaster458]

This driver has be checked for proper Driver Initialization for use in CQC Beta 2.3.4

[gacevich]

Can you post the rest of your code? What are you using to populate %(LVar:UNOkeypad) ?

here is the full code thru this routine. when i check KensVariables.UNOkeypad in the field browser it updates correctly based on the keypad used.
TrigEvent::GetEvField(/cqsl.actinfo/evdata, LVar:UNOevent)
LocalVars::GetLength(LVar:UNOevent, LVar:UNOeventlength)
LocalVars::GetSubString(LVar:UNOevent, 1, 1, LVar:UNOkeypad)
LocalVars::GetSubString(LVar:UNOevent, 2, 1, LVar:UNOsource)
LocalVars::Subtract(LVar:UNOeventlength, 3)
LocalVars::GetSubString(LVar:UNOevent, 3, %(LVar:UNOeventlength), LVar:UNObutton)
// The follwing three lines are for diagnostics
Devices::FieldWrite(KensVariables.UNObutton, %(LVar:UNObutton))
Devices::FieldWrite(KensVariables.UNOsource, %(LVar:UNOsource))
Devices::FieldWrite(KensVariables.UNOkeypad, %(LVar:UNOkeypad))
// This routine changes the source display on the keypad as source button is pressed
If System::Equals(%(LVar:UNObutton), Source)
If System::Equals(%(LVar:UNOsource), 6)
Devices::FieldWrite(RussoundRNet.TextDisplay, Radio)
End
If System::Equals(%(LVar:UNOsource), 1)
Devices::FieldWrite(RussoundRNet.TextDisplay, Study PC)
End
If System::Equals(%(LVar:UNOsource), 2)
Devices::FieldWrite(RussoundRNet.TextDisplay, iTunes)
End
If System::Equals(%(LVar:UNOsource), 3)
Devices::FieldWrite(RussoundRNet.TextDisplay, XM Radio)
End
End

[gacevich]

Version 1.7 has been uploaded. This should take care of the issue of the correct Source number being sent with the Button User Event. I also added the ability to send text to keypads on all or select sources
Toymaster, i have been working on v1.10 of the RussoundRNet driver and built some User Variables so that i can see the raw button event data. I noticed two things that i think are problems as i try to add functionality to my system.

First, when i push the Source button all the data seems to show up correctly except that the source readout "lags" by one source...go from Source 4 to Source 5 and it says Source 4. Did some more playing around and found that if i change Source and then press a button other than Source as quickly as my fingers will move, the Source updates to the correct Source. Question: is this the functionality that i should experience in v1.10?

Second, i have two CAV6.6's connected via cat5 cable running btwn RNet ports. when i load the RussoundRNet driver it asks how many zones i am using and i tell it 12. The driver then creates twelve zones labeled c1z1...c1z6, c2z1...to c2z6. i can see all zones in the field browser and program command buttons to control them as i desire...no issues, yet. however, when i look at button event raw data from an UNO connected to CAV #2, the button name comes thru (e.g., Stop, Next, etc.) but the Source and Zone do not update. Reading thru the html faq posted in the first post on this thread, it says zones can go from 1-32. First question: should this be 1-36? Second question: what zone should i expect the driver to return for zone, say, c2z1...7? Finally, should i be able to read the source for zones attached to CAV #2?

My programming seems to work fine for zones attached to CAV#1, but in the event that the issue is my programming, attached below is the Triggered Event programming i am using.

// UNO Button event data is in the format of
// Event Data: <zz><s><ButtonName>
// <zz>: zone num, from 01 to 32
// <s>: Source num, from 1 to 7
// <ButtonName>: Any of the following: Previous, Next, Plus, Minus, Stop, Pause, F1, F2, Play, Source
TrigEvent::GetEvField(/cqsl.actinfo/evdata, LVar:UNOevent)
LocalVars::GetLength(LVar:UNOevent, LVar:UNOeventlength)
// get the first two characters in UNOevent
LocalVars::GetSubString(LVar:UNOevent, 0, 2, LVar:UNOzone)
// Get the third character in UNOevent
LocalVars::GetSubString(LVar:UNOevent, 2, 1, LVar:UNOsource)
// Remove the first three characters from UNOevent
LocalVars::Subtract(LVar:UNOeventlength, 3)
// Get the uno button pressed
LocalVars::GetSubString(LVar:UNOevent, 3, %(LVar:UNOeventlength), LVar:UNObutton)
// The follwing five lines are for diagnostics
Devices::FieldWrite(KensVariables.UNOeventlength, %(LVar:UNOeventlength))
Devices::FieldWrite(KensVariables.UNObutton, %(LVar:UNObutton))
Devices::FieldWrite(KensVariables.UNOzone, %(LVar:UNOzone))
Devices::FieldWrite(KensVariables.UNOsource, %(LVar:UNOsource))
Devices::FieldWrite(KensVariables.UNOevdata, %(LVar:UNOevent))

[ToyMaster458]

I noticed some issues with the source properly showing but I thought those where resolved. I will have to look into it again and see. You are correct that Controller 2 Zone 1 should respond as Zone but I did not have a stack to test it on. I will also look into to that as well.

Finally, should i be able to read the source for zones attached to CAV #2?
Do you mean the CxZxSource field?? Or are you just repeating that the User Event from a zone on the second controller does not include the Source Number.

[ToyMaster458]

Also if you can put logging on high and do you test again then post the results.

[gacevich]

You are correct that Controller 2 Zone 1 should respond as Zone but I did not have a stack to test it on.
did u mean to say respond as Zone 7?

Or are you just repeating that the User Event from a zone on the second controller does not include the Source Number. yes, that the user event does not include source number or zone number.

[gacevich]

Also if you can put logging on high and do you test again then post the results.
to be clear (because i often suffer self-inflicted HA wounds) you are asking to set the RussoundRNet driver verbosity to High and post the log results here? will do unless i hear differently. thanks for your efforts.

[ToyMaster458]

Sorry I was responding half a sleep last night so my post where half written but you got the point! Looking at the driver can you make sure that the CxZxSource fields are displaying properly? The User Event Source pulls the source information from that field as the button event from the keypad does not include that information. So if the button is pressed before the driver has the new source setting the old source would be included.

[gacevich]

Looking at the driver can you make sure that the CxZxSource fields are displaying properly?
these fields display properly in the driver and they respond to commands.

[gacevich]

tm: arggg...frustration level running high and i don't have the patience to troubleshoot right now. none of the button events are showing up in my diagnostic user variables. high verbosity log attached, but i fear that it has no good info because the triggered event doesn't seem to be registering. i haven't changed anything since last night.

maybe tomorrow will be a better day. the log recorded a Source button, F1 and Stop button push. curious to know if the log says anything useful.

[kayemsi]

I have started experiencing some strange behaviour from my CAV6.6. If I use the driver to turn on some or all of the zones, it plays for several minutes, but then one by one, all the zones will turn off.

This doesn't happen if I turn on a zone from its keypad. I am having an issue with the keypad for zone 1, which shows something like CNTL:1 PORT:1 when it is powered on manually and it does not turn the zone on or control the CAV.

But if I use CQC to turn on zone 1, then the keypad will turn on and respond and show expected info on the display. Then a few minutes later every zone will turn off. If I use CQC to turn on a different zone, I still have issues with it turning all zones off. I especially tried an action for a "party scene" that sets all on, with the party mode and the master zone set to zone 4, and all zones some on as expected, but then all turn off on their own.

I am on CQC 2.3.3 and a beta version of this driver. I don't remember which, but it is not the latest, but I will check. I don't think I updated to the version with the change to sense the trigger on page event.

Should I start another thread for this in another section? I don't know if this is a problem with the driver or my CAV6.6 hardware or setup. But manual use of single zones (other that zone 1) stays on OK.

[ToyMaster458]

I have found some issues with the driver thay may resolve you issues. I am hoping to have a new release soon!

[ToyMaster458]

I have started experiencing some strange behaviour from my CAV6.6. If I use the driver to turn on some or all of the zones, it plays for several minutes, but then one by one, all the zones will turn off.

This doesn't happen if I turn on a zone from its keypad. I am having an issue with the keypad for zone 1, which shows something like CNTL:1 PORT:1 when it is powered on manually and it does not turn the zone on or control the CAV.

But if I use CQC to turn on zone 1, then the keypad will turn on and respond and show expected info on the display. Then a few minutes later every zone will turn off. If I use CQC to turn on a different zone, I still have issues with it turning all zones off. I especially tried an action for a "party scene" that sets all on, with the party mode and the master zone set to zone 4, and all zones some on as expected, but then all turn off on their own.

I am on CQC 2.3.3 and a beta version of this driver. I don't remember which, but it is not the latest, but I will check. I don't think I updated to the version with the change to sense the trigger on page event.

Should I start another thread for this in another section? I don't know if this is a problem with the driver or my CAV6.6 hardware or setup. But manual use of single zones (other that zone 1) stays on OK.

I am looking in the driver and testing it in two different locations and I can not replicate your issues. What gets me is your issue with Zone 1 controlling it from a Keypad. I am thinking you may have a Hardware/Programming issue.

[jchurley]

Small snag using the events from button presses.....

It looks like F1 and F2 automatically switch that zone to a "favorite" source, which makes it hard to use these keys with other sources - the Russound gets the keypress and switches sources, then CQC sees the keypress and invokes my action. By then the source has changed and source specific actions don't get invoked.

Has anyone else experienced this? Is there a way to stop the Russound from switching sources when F1 or F2 is pressed?

Thanks

Joe

[ToyMaster458]

Small snag using the events from button presses.....

It looks like F1 and F2 automatically switch that zone to a "favorite" source, which makes it hard to use these keys with other sources
I looked at the Russound PC Power Tool and there is no way to disable the functions the F1 and F2 key do.

- the Russound gets the keypress and switches sources, then CQC sees the keypress and invokes my action. By then the source has changed and source specific actions don't get invoked.

It seems the RNet is transmitting the keypad event before it transmits the source change so when the driver sends out the source button event it still thinks it is on the current source. What I could do is if it is the source button that was press to take the current source value and increase it by one.

[gacevich]

I looked at the Russound PC Power Tool and there is no way to disable the functions the F1 and F2 key do.


Hmmm...this is not something i expected to hear. i was hoping to use the F1 and F2 keys to implement some functionality that i have seen IVB talk about. To wit, a press of, say, the F1 key, by a user early in the morning as they are getting ready for school or work would shift the local zone source to the source (Front A/V in my case) where a weather forecast TTS could be directly played only in that zone, and only in that zone, then shift back to whatever that zone was previously playing. I could possibly tolerate the F1 key "doing its thing" then provide weather forcast, but that seems clunky.

[ToyMaster458]

I am building another version with that will have the Source value in the Source Button Event increased by one but I also need to know if users want the Event format changed.

Currently it is "zzsbutton" where "zz" is the zone number from 1-36, "s" is the current source of the zone when the button was pressed and "button" is the name of the button pressed (Previous, Next, Plus, Minus, Stop, Pause, Fav1, Fav2, Play, Source).

Some have asked for it to be

"czsbutton" where "c" is the controller number from 1-6 and "z" is the zone number on the controller from 1-6, "s" is the current source of the zone when the button was pressed and "button" is the name of the button pressed (Previous, Next, Plus, Minus, Stop, Pause, Fav1, Fav2, Play, Source).

Before I make these changes that will break some of the current users events that are based on the current format I need to see if the majority of users what this change! So PLEASE respond either way!

[jchurley]

I looked at the Russound PC Power Tool and there is no way to disable the functions the F1 and F2 key do.


That's what I was afraid of - I have Power Tool also and for the life of me couldn't figure out how to stop source selection. Oh well, I'll just have to change my approach and limit F1 to Audio Player 1 and F2 to Audio Player 2 - at least that way when they switch zones they'll just be switching to the same zone.

There is one annoyance here - since the CAV is technically setting the source, even though it's setting the original source, the source name flashes on the keypad, which kind of messes with the messages I'm sending. I don't suppose you know a way to suppress that message from the CAV?

Also, I think you may have a typo in the docs - all the docs refer to "Fav1" and "Fav2" as the button name in the event, but to me it looks like they are "F1" and "F2". Am I missing something here?

Thanks

Joe

[ToyMaster458]

There is one annoyance here - since the CAV is technically setting the source, even though it's setting the original source, the source name flashes on the keypad, which kind of messes with the messages I'm sending. I don't suppose you know a way to suppress that message from the CAV?
One thing off the top of my head is to try nd set you message after the Russound sets theirs so you write over theirs.

Also, I think you may have a typo in the docs - all the docs refer to "Fav1" and "Fav2" as the button name in the event, but to me it looks like they are "F1" and "F2". Am I missing something here?

Opps, My Bad! I will update the docs, thanks!

[gacevich]

I am building another version with that will have the Source value in the Source Button Event increased by one but I also need to know if users want the Event format changed.
getting the source to cycle through the options and being able to correctly capture it into a local variable would be oustanding.


Some have asked for it to be

"czsbutton" where "c" is the controller number from 1-6 and "z" is the zone number on the controller from 1-6, "s" is the current source of the zone when the button was pressed and "button" is the name of the button pressed (Previous, Next, Plus, Minus, Stop, Pause, Fav1, Fav2, Play, Source).


count me stongly in this camp. i am looking to capture the czsbutton info in the same format that i would use to do fieldwrites and fieldreads. if is comes as, say, zone 12, i have to convert that via programming logic to c2z6 in order to do fieldwrites or fieldreads. while i am only begining do this programmnig, i am, of course, implicitly assuming that it easy to capture cxzx data and use it to do fieldreads and writes. this may not be the case and if it is not i hope that more experienced programmers will chime in.

for context, my prior post gives an overview what i am trying to do. easiest format to complete that goal is my objective.

just my $0.02

[jchurley]

One thing off the top of my head is to try nd set you message after the Russound sets theirs so you write over theirs.


That's what is happening, BUT......

I was hoping to use the F1 and F2 keys to browse artists/albums/playlists and then play them on my audio player. The problem is two-fold -

First when the CAV sets the source, that source name gets sent to the keypad, which displays and is then overwritten by my message. So if you are browing artists, instead of seeing:

Black Sabbath
Blue Oyster Cult
Boston

You see:

CD Jukebox1
Black Sabbath
CD Jukebox1
Blue Oyster Cult
CD Jukebox1
Boston

Not the end of the world and something I have to live with - it just makes the browsing kind of funky.

The bigger problem is that since the F1/F2 keys change the source, I need to either change it back (which will then make the browsing even funkier, since there will be more messages sent to the keypad) or devote F1 to CD Jukebox1 and F2 to CD Jukebox2.

I think I'll pick option 2 and try to get something to work.


Before I make these changes that will break some of the current users events that are based on the current format I need to see if the majority of users what this change! So PLEASE respond either way!


FWIW this is the first event I set up, so I can easily change the action to handle the new event format. I think it makes sense to have the event format mirror the driver fields format. So my vote is change it.

What I could do is if it is the source button that was press to take the current source value and increase it by one.


Not sure what you mean by this.



Also, if you are looking at updating the driver, is it possible to add a Main/System/Master power field? Right now I've created my own variable for this that gets updated based on triggers off of the six zone power fields, but it would be nice if the driver could handle this by itself.

Thanks

Joe

[gacevich]

Also, if you are looking at updating the driver, is it possible to add a Main/System/Master power field? Right now I've created my own variable for this that gets updated based on triggers off of the six zone power fields, but it would be nice if the driver could handle this by itself.

Joe, what do you use this for?

[jchurley]

Joe, what do you use this for?

I have several sources that are shared between the CAV and 2 AVRs. Since they're shared, I can't just power off the sources when 1 particular amp is shut off, since the source may be selected by another amp.

The CAV allows you to integrate 1 AVR via a 12V signal to account for this, but I haven't figured out how to integrate 2, so I'm using CQC.

Basically I set up one triggered event that runs when any CAV zone amp is powered on/off and sets the status of the master CAV power variable to on/off.

A second triggered event runs when either one of the AVRs is powered on/off OR the master CAV power variable changes.

If that second event determines that all 3 amps are turned off, it then powers off the shared sources.

Hope this makes sense.

Joe

[gacevich]

here's a noob question--what's an AVR?

the cav has ability to take 7 sources. do you have more than 7 sources?

[jchurley]

AVR = Audio/Video Receiver.

No, I don't have more than 7 sources, but that's not the issue - the issue is that some sources are connected to the CAV and the 2 AVRs.

For example, my SlimServer player is connected to the CAV with the analog outputs and the 2 AVRs with the digital outputs.

In theory, my wife and I could be listening to the same music selection - me in the Family Room via the AVR and my wife in the Master Bathroom via the CAV.

If I decide to turn off the AVR, I can't also just turn off the SlimServer player, since my wife is still using it.

Hence the need to track the power state.

Joe

[gacevich]

well...if i understand correctly, u r using the two avrs as additional zones. just get another cav, link them together and your issue is solved (except, of course, for the cost of the extra cav :-)

[sic0048]

He may also be using the receivers because he wants surround sound in some zones. If this is the case, the CAV won't work since it only supplies stereo audio.

The other options is to simply keep the source devices on all the time. Or at least turn them on at a preset time early in the morning and turn them off late at night. Of course that is a waste of power too.

I like the idea of using the triggers to keep track of usage. I may have to look at this solution because I have a similar situation where I have a whole house audio amp as well as several receivers sharing sources. At this point, I simply keep the devices on and not worry about if they are actually being used.

[jchurley]

He may also be using the receivers because he wants surround sound in some zones.

That's exactly the reason why - I have 2 rooms that have 5.1 and 7.1 surround setups, so why use up the zones on the CAV. Now I get the 6 CAV zones and the 2 AVR zones.

Brian - I'd highly suggest the use of triggered events to turn off shared equipment. I started off going down the path of turning off all equipment "late at night", which with a kid in grade school can actually be kind of early. Of course the first time my stepson (who is 23) stayed over and had the HD DVD player turn off halfway through the movie, just because it was midnight, I had to come up with another solution.

Joe

[gacevich]

TM, i am finally getting around to building a russound template that will control my 2 cavs. During my testing of the interface as i walked around the house, i noticed something odd. Its probably easier to show in IV screenshots.

here is the staring point.
http://i225.photobucket.com/albums/dd95/withmere/rnet1.png

then i change the source in my daughters room and the soure changes in the Master Bedroom
http://i225.photobucket.com/albums/dd95/withmere/rnet2.png

Then after 30 to 60 seconds the master bedroom source reverts.
http://i225.photobucket.com/albums/dd95/withmere/rnet3.png

Now i know what u r thinking...is there a programming error in my templates. Well...i won't dismiss that but i have double and triple checked the programming.

here are some other oddities about what i am experiencing:

everthing seems to work find on the cav#1. that is, the proper source shows up on both the IV and the uno keypad. and even better, the audio from the speakers matches the displayed source. :-)
the linkage bwtn my daughters room and the master bedroom seems to be tied to the zone. the master bed room is c1z5, my daughter's room is c2z5. the same linkage happens bwtn c1z1 & c2z1, c1z2 & c2z2....you get the idea.
if i stand in my daughter's room and change the source from the IV, the actual audio from the speakers will change as it should, but not the displayed source on the uno (same for other cav#2 rooms)
however, if i am in a cav#2 room and i hit the source button on the uno, the proper source is indicated on the IV...but the corresponding zone on cav#1 does not exhibit the same linked behavior.

maybe its the cavs...i'm just perplexed.

has anybody else set up 2 cavs and tried to build an IV template like mine and experienced the same oddity? better yet, does anyone have an IV template that works just fine using 2 cavs and the russound driver?:confused:

[Dean Roddey]

That could only happen by something changing in the driver, most likely. The button would not change state unless the associated field did as well.

[ToyMaster458]

If I remember correctly when Mark and I where developing this, there was a issue with Keypad colors not changing on the second CAV. I will take a peek and maybe the same thing we did to fix that will work for this.

[ToyMaster458]

I uploaded a new driver that includes a field for CxZxSourceShared field that displays if the selected source is in use on another zone as well.

[gacevich]

I uploaded a new driver that includes a field for CxZxSourceShared field that displays if the selected source is in use on another zone as well.
great. might this address the problem i am having getting the driver to work properly with two cav's?

[ToyMaster458]

great. might this address the problem i am having getting the driver to work properly with two cav's?
What version are you currently running?

[gacevich]

What version are you currently running?
v1.13. i see u have posted v.15. i'll upgrade to v.15 and see if it addressed the issue i was experiencing.

[ToyMaster458]

v. 1.14 fixes an issue with the source and multiple CAV's. Where you having any other issues?

[gacevich]

biggest issue is multi-cav control. the one nit-picky issue i experience from time to time is related to volume adjustment using inc/dec widget. decrease seems to work fine (since button press = dec in volume) however increase usually take multple button presses to make volume increase...single press flashes higher volume number but it reverts back. two presses shows double increase but settles out at single button press increase. not a big deal, but would be nice if inc worked as well as dec.

[Dean Roddey]

As a rule, I generally tend towards sliders and volume knobs for volume setting instead of inc/dec buttons. If a device has a start/stop volume ramp type function, that works well with up/down command buttons. But unless a device responds very quickly, inc/dec buttons can be kind of unwieldy.

[gacevich]

As a rule, I generally tend towards sliders and volume knobs for volume setting instead of inc/dec buttons. If a device has a start/stop volume ramp type function, that works well with up/down command buttons. But unless a device responds very quickly, inc/dec buttons can be kind of unwieldy.
yeah...i orginally had sliders when i only had one cav. but with 12 zones my fingers were better able to hit inc/dec buttons on a Q1 screen. besides, i'm not so good at generating good looking sliders for my IV screens and the buttons looked better.

[Dean Roddey]

You can always just put the volume setting on a popup or something.

[gacevich]

hmmmm...just downloaded and installed v.15, kinda. all went well until i actually installed the driver. "Driver State" is hung at "Wait for Initalizaton".

checked the logs and the admin interface doesn't like this driver. messages saying: an unrecoverable error occured while parsing; a c++exeption occured during macro parsing; a macro parse event occured.

from the first page of this thread it looked like i was first to download this driver. anybody else having these issues?

i am running cqc v.4.8.

[Dean Roddey]

It may use recently implemented CML functionality, in which case you'd have to upgrade to the latest beta.

[ToyMaster458]

hmmmm...just downloaded and installed v.15, kinda. all went well until i actually installed the driver. "Driver State" is hung at "Wait for Initalizaton".

checked the logs and the admin interface doesn't like this driver. messages saying: an unrecoverable error occured while parsing; a c++exeption occured during macro parsing; a macro parse event occured.

from the first page of this thread it looked like i was first to download this driver. anybody else having these issues?

i am running cqc v.4.8.
I think I found the issue. Re-download it and try again.

[gacevich]

good news & bad news. downloaded the lastest version and it will load...thanks TM. however, control over the second cav is still not what it should be. via the IV i can turn a zone on or off sucessfully as well as control its volume. however, i cannot change the source via the IV. if you you look a previoius post where i show a screenshot, the new source will momentarily show as being selected (button changes color) then it will quickly flash back to the pre-existing source. all the while the actual source will not change in zone nor will any indication that the source has been changed be displayed on the uno keypad.

[ToyMaster458]

good news & bad news. downloaded the lastest version and it will load...thanks TM. however, control over the second cav is still not what it should be. via the IV i can turn a zone on or off sucessfully as well as control its volume. however, i cannot change the source via the IV. if you you look a previoius post where i show a screenshot, the new source will momentarily show as being selected (button changes color) then it will quickly flash back to the pre-existing source. all the while the actual source will not change in zone nor will any indication that the source has been changed be displayed on the uno keypad.
Lets give this one a try.

[gacevich]

haven't had chance to fully test the driver, but inital testing indicates that the source selection issue has been resolved. gotta run and will test more thoroughly and report back. TM...u rock!

[gacevich]

good news. i tried every permutation i have programmed into my IV and everyone of them worked with this driver on both cavs. thanks again TM!

[ToyMaster458]

I repackaged the driver as 1.16 and updated the first post. If I can get some more feedback on this latest version, I will get it to Dean.

[ToyMaster458]

I just posted version 1.18 in the first post of this thread and it has some major changes that need to be well tested as I added support for the ACA-E5 controller and revised the message handling based on the latest Protocol Document that clarified a lot of guess word we did on the original message handling and handshaking.

PLEASE TEST THIS VERSION WELL!

I also added one new field for SystemOn. If any zone is on this will be True.

[ToyMaster458]

If you are running version 1.18 with a CAV PLEASE upgrade to version 1.19 in the first post. Some issues with the new protocol and the CAV have been fixed with this version.

[lpott6]

Kirk,

Is 1.19 okay to try with my ACA-E5 in it's own mode, or do I still need to run it in CAV mode?

I can give it a whirl tonight and let you know how it goes.

PS: Still no work from Russound about the next firmware update.

[lpott6]

I loaded 1.19 and selected ACA-E5. It connected at first and then began cycling between "Wait for Connect" and Waiting for Com Resource". This is the same behavior we saw in an earlier version.

I re-loaded 1.19 and selected CAV6.6. It connected and appears to be working the same as v1.17i.

Is there anything specific you want me to test?

[ToyMaster458]

We will take another look at this over the weekend.

[gacevich]

We will take another look at this over the weekend.
has any progress been made on the lastest version? i am now have connection problems. the log says: A macro parse error occured, An unrecoverable error occured while parsing, A C++exeption occured during macro parsing. i get this error with v.19 and with v.15 which used to work. maybe its my system?

[Sacedog]

I am trying to set up control for the built in tuner in the CAM 6.6T, and am having problems getting it working. Is the SxSourceST2Frequency field something I should see in the driver fields if I am using v1.19?

Also, I am assuming that I should just use the transport keys to change presets, switch between AM and FM, and to increment the tuner.

If so, maybe it has something to do with how I am set up. I have a CAV and a CAM. The CAV is device 1, and the CAM is device 2, and I am connecting to the serial port on the CAV for control.

Thanks for any help...I am still very green in CQC. :oops:

[Mark Stega]

Sacedog,

I am about to post a driver for the Russound that has many modifications from what has been publicly availabel to date. I think you should try again with the new driver and then post here with issues.

[Mark Stega]

Sergio (from Vidabox) has done some extensive rework of the Russound RNET driver. The changes are shown below. Note that there is a breaking change - The zone naming convention was changed to be more consistent with the Nuvo and ADA multiroom drivers. I will also send the driver on to Dean for inclusion in the next drop.

// 2.0 31MAR09 Changed zone naming convention to simply list zones by zone number (Vidabox-SD)
//
// 2.1 29APR09 Fixed issue in method "CalculateControllerZone", it wasn't calculating the
// controller number correctly when there was a zone expander (Vidabox-SD)
//
// 2.2 17JUN09 Fixed various issues related to the ACA-E5 and zone expanders. Added more async support for
// for power, and volume change. Changed method for reader the serial buffer to use GetTermedMsg.
// This significantly enhanced the responsiveness of the driver. Added logic to remove sources
// that are set to "none" in the driver config. i.e if sources 1,11,12 are setup, the CQC source
// numbers would be 1,2,3. Setting CQC source to 2 would set the russound source to 11. (Vidabox-SD)
//
// 2.3 17JUN09 Added async processing for DND, Source Shared, System On, and Party Mode. Fixed GetAllZoneInfo
// for zones on the zone expander. (Vidabox-SD)

1857
1858

[Mark Stega]

I am trying to set up control for the built in tuner in the CAM 6.6T, and am having problems getting it working. Is the SxSourceST2Frequency field something I should see in the driver fields if I am using v1.19? Yes you should for any source that was indicated to be ST2.

Also, I am assuming that I should just use the transport keys to change presets, switch between AM and FM, and to increment the tuner. You should be writing to the SxSourceST2Command field. Take a look at the online documentation for the Russound to see alowable commands.

If so, maybe it has something to do with how I am set up. I have a CAV and a CAM. The CAV is device 1, and the CAM is device 2, and I am connecting to the serial port on the CAV for control.
I am far from an expert on the Russound connectivity issues. You could temporarily disconnect the two and connect CQC to the CAV and reconfigure the driver for that setup.

[Dean Roddey]

I've put this version into the release for the next drop.

[zpollock]

Sergio (from Vidabox) has done some extensive rework of the Russound RNET driver. The changes are shown below. Note that there is a breaking change - The zone naming convention was changed to be more consistent with the Nuvo and ADA multiroom drivers. I will also send the driver on to Dean for inclusion in the next drop.

// 2.0 31MAR09 Changed zone naming convention to simply list zones by zone number (Vidabox-SD)
//
// 2.1 29APR09 Fixed issue in method "CalculateControllerZone", it wasn't calculating the
// controller number correctly when there was a zone expander (Vidabox-SD)
//
// 2.2 17JUN09 Fixed vario[FONT=Courier New]us issues related to the ACA-E5 and zone expanders. Added more async support for
// for power, and volume change. Changed method for reader the serial buffer to use GetTermedMsg.
// This significantly enhanced the responsiveness of the driver. Added logic to remove sources
// that are set to "none" in the driver config. i.e if sources 1,11,12 are setup, the CQC source
// numbers would be 1,2,3. Setting CQC source to 2 would set the russound source to 11. (Vidabox-SD)
//
// 2.3 17JUN09 Added async processing for DND, Source Shared, System On, and Party Mode. Fixed GetAllZoneInfo
// for zones on the zone expander. (Vidabox-SD)


Mark,

I don't see the changes that I added and discussed with Sergio in this (http://www.charmedquark.com/vb_forum/showpost.php?p=111373&postcount=40) thread listed above. Did they get incorporated too?

[VidaBox LLC]

Mark,

I don't see the changes that I added and discussed with Sergio in this (http://www.charmedquark.com/vb_forum/showpost.php?p=111325&postcount=34) thread listed above. Did they get incorporated too?

Sorry! I totally forgot to make the change. I just spoke to Mark and he will be adding your changes.

[Mark Stega]

Mark,

I don't see the changes that I added and discussed with Sergio in this (http://www.charmedquark.com/vb_forum/showpost.php?p=111325&postcount=34) thread listed above. Did they get incorporated too?

No, they were missed. I've attached an updated driver (2.5) and its documentation. I'll send it on to Dean.

[zpollock]

Excellent, thanks!

[standon]

This works well with my MCA-C5, allows all 8 zones. Thanks! I selected the install as the E5 series so I could get all the sources.

One thing is that for some reason my ST2S seems to pull the composer data (I think because it's more often showing "-----" than anything else) instead of the actual "S1ST2Arist". A

[gacevich]

cross posting from the beta thread.

just upgraded to v13, primarily to get the new russound driver. went through the monkey work of reassigning zones...painful, but done. and let me first say that the speed of this new driver is amazing. click the button and you action both happens and cqc IV updates quickly. clearly huge improvement over the prior driver. i think it was vidabox who did the driver upgrade...kudos to vidabox.

however, i'm left with a two issues.

1) i'm getting the blinking russound fields thing. this means the driver is disconnecting then reconnecting, right? remind me how i fix it?

2) i used to use the Field Text widget to display what's playing on XM. the specific fields are: S01_ST2Title, Artist, Genre, ChannelNumber and ChannelName. i can't use these fields with the new driver...that is, when i configure the field text widget to use these fields they are blank in the IV. went to the field browser to see what values i should see and the fields are blank in the field browser. i set up the st2-xm as source 1 and the tuner as source 2. what else am i missing?

[gacevich]

well this driver took another turn for the worse. now it won't even connect. tried going back to older version. older version of driver installs fine and stays rock steady. i'll try emailing vidabox support to see if they have any ideas.

[VidaBox LLC]

well this driver took another turn for the worse. now it won't even connect. tried going back to older version. older version of driver installs fine and stays rock steady. i'll try emailing vidabox support to see if they have any ideas.

We only answer support questions for VidaBox authorized dealers and customers. You can send an email but you most likely will not get an answer.

I'm not quite sure what is happening on your setup but we have used this driver in many different installs without any issues. I would start by setting the driver to high verbosity and posting the log here making sure that the error is displayed in the logs when it disconnects. That would help to explain what is happening and myself and others will be able to comment at that point.

[Mark Stega]

well this driver took another turn for the worse. now it won't even connect. tried going back to older version. older version of driver installs fine and stays rock steady. i'll try emailing vidabox support to see if they have any ideas.
They wiull request that you put the driver in verbose mode and post a section of the log file that covers the preiod of non-connecting/connection drop/reestablish. Clearly someting i sbeing sent from the Russound that is not being handled.

[gacevich]

They wiull request that you put the driver in verbose mode and post a section of the log file that covers the preiod of non-connecting/connection drop/reestablish. Clearly someting i sbeing sent from the Russound that is not being handled.
attached is a log file with the russound driver in high verbosity. my layman's read is that something is going wrong with the polling. hopefully someone with more knowledge of how the driver works can decern more info. thanks.

[Dean Roddey]

It looks like two issues are compounding. It looks like the driver gets a bad message. Then it tries to update a field which causes another error because it's being accessed as the wrong type:

Exception in Poll(), ErrorText=Field $BadMsg was accessed as a type different from its defined type

So that causes an even bigger error. I'm not sure how the above could actually happen in a CML driver unless the driver is trying to read the field. Normally those stats fields are updated by way of helper methods which would inherently know how to do the right thing.

[Dean Roddey]

There's only one call to increment the bad message counter, which is when it gets a bad CRC from the device. But I cannot see any possible way that the above error could be caused short of some really pathlogical corruption issue or something. I don't have access to one of these so I can't try it, but someone who can may want to purposefuly put in a little test code to whack the CRC after some number of messages and see if they can reproduce this issue.

Lots of drivers increment this counter, so there can't be anything actually fundamentally wrong in terms of the underlying driver stuff. It's got to be something going awry up at the CML level it would seem.

[Dean Roddey]

Oh, wait, one way you could cause that error is to use a field id that's not been initialized, so it's still zeroed out. So I bet that is what is happening. The driver isn't initializing some field id, so when the device sends a response that requires that field to be set, it accesses the field using the zero'd id, gets the $BadMsg field instead, and gets that error because the type that the driver expects the field to be isn't what the $BadMsg field actually is.

I always initialize all of my field ids to kMaxValue in the driver's constructor for this reason. This catches any use of an unitialized field id in a way that makes it fairly obvious what went wrong.

[gacevich]

dean, if i understand your comments correctly it sounds like the issue is with the driver, not my equipment, right?

[Mark Stega]

You are going to have to run the driver in the driver test harness.

Put a break at line 1961 (Switch( m-SourceType[Source]) and tell me what the values are for TextMessage, Source, BroadcastMsgType, and FieldID.

By hand I decode them as:

TextMessage - "Chevy.com/Traver"
Source - 0
BroadcastMessageType - 20
FieldID - 2

As I read the code if you follow it after the break it should just be an unhandled message. If you don't pop to line 1961, set you break at line 1883 (right after logging the "data message from a peripheral" message) and let me know where you go in the code.

[gacevich]

oh boy! mark, you might as well have written that with cyrillic characters.

i've never knowingly stumbled across the driver test harness much less written any code in a driver.

let's start with step 1. where do i find the driver test harness?

[Dean Roddey]

Another scheme would just be to turn on the break on exception option. When it hits the bad field id, it'll break. Then a quick trace back up to the call point will show which field id it's trying to store that never got set.

[sic0048]

let's start with step 1. where do i find the driver test harness?

It is an optional part of CQC that must be installed. If you did a "full installation" then you should see it listed under Start - Programs - CQC. If it isn't there, then you need to rerun the CQC installer and make sure you check the box to install the Driver Test Harness.

Then start it up using the program icon and load the driver into it. (Similar to loading a template into the interface editor).

[Dean Roddey]

If you are that unsure about how it works, you may be better off setting up the remote port server and letting Mark connect remotely and debug it himself.

[gacevich]

well i completed step 1 this morning. found the test harness and loaded what i believe to be the correct driver--RussoundRNetSerial.Manifest. the screen looked like this after i opened the new session.
http://i225.photobucket.com/albums/dd95/withmere/testharnes.jpg
but i scrolled thru and did not see line 1961 as mark mentioned nor did i see how to insert a break.

so now that i have the driver loaded, what is step 2?

[Mark Stega]

What do you mean when you say that you couldn't see line 1961?

You do Ctrl-G and enter 1961 as the line to jump to as the easiest way to get there. You double click on the grey area to the left of the desired line for a breakpoint. Then you right click on the source and pick Debug->Go twice.

[gacevich]

What do you mean when you say that you couldn't see line 1961?

You do Ctrl-G and enter 1961 as the line to jump to as the easiest way to get there. You double click on the grey area to the left of the desired line for a breakpoint. Then you right click on the source and pick Debug->Go twice.
Today 05:49 AM
well, all of above was new to me. did what you said and got to line 1961. it looked like this.
http://i225.photobucket.com/albums/dd95/withmere/testharness1.jpg
right clicked Debug->Go and got this
http://i225.photobucket.com/albums/dd95/withmere/testharness2.jpg

then i tried to follow your directions here

You are going to have to run the driver in the driver test harness.

Put a break at line 1961 (Switch( m-SourceType[Source]) and tell me what the values are for TextMessage, Source, BroadcastMsgType, and FieldID.

By hand I decode them as:

TextMessage - "Chevy.com/Traver"
Source - 0
BroadcastMessageType - 20
FieldID - 2

As I read the code if you follow it after the break it should just be an unhandled message. If you don't pop to line 1961, set you break at line 1883 (right after logging the "data message from a peripheral" message) and let me know where you go in the code.
and looked for the values you reference in this, which kinda looked like the field browser.
http://i225.photobucket.com/albums/dd95/withmere/testharness3.jpg
however, i didn't find the fields you asked about.

this is my first time using the test harness so i'm sure its my lack of knowledge that is the problem. if you can point me in the right direction i'll try to get the data you are looking for.

thanks for your patience.

[Dean Roddey]

You have to do the Go thing twice. The first one gets you to the constructor of the class. Then the next one continues on and runs it.

[gacevich]

clearly i'm doing something wrong. i go to line 1961 via ctrl-g. double click to get magnifying glass. then right click and do Go thing. it takes me to where the green triangle points at constructor. i do the Go thing again and code does not move in screen. if i try to do the Go thing again, i can't because its greyed out...so this means i've successully done the Go thing twice?

thinking this is the case, i go to the field monitor to find the values of the fields that mark is asking for. and this is the part where i feel really inept. i don't even see those fields in field monitor. not that i can't see their values, its that i can't find the fields to find the values.

for example, i'm looking for the the TextMessage field, right? well, look at my third screen shot in post 147. it shows all the Text* fields and none of them are TextMessage. what am i doing wrong?

[gacevich]

bump.

my driver is still flakey. would like to use the newer faster version. looking for assistance.

[Mark Stega]

clearly i'm doing something wrong. i go to line 1961 via ctrl-g. double click to get magnifying glass. then right click and do Go thing. it takes me to where the green triangle points at constructor. i do the Go thing again and code does not move in screen. if i try to do the Go thing again, i can't because its greyed out...so this means i've successully done the Go thing twice?

thinking this is the case, i go to the field monitor to find the values of the fields that mark is asking for. and this is the part where i feel really inept. i don't even see those fields in field monitor. not that i can't see their values, its that i can't find the fields to find the values.

for example, i'm looking for the the TextMessage field, right? well, look at my third screen shot in post 147. it shows all the Text* fields and none of them are TextMessage. what am i doing wrong?

The second "Go" brings the driver into a running state. If you really have a breakpoint set at the "Switch" statement (about line 1961) then the debugger will stop at that breakpoint. You'd look at the values requested in the window named "Method locals", not the field monitor as they are not fields.

[gacevich]

so i followed all the steps that i did before and then checked to make sure that i did indeed have a breakpoint set at line 1961. This seems to indicate that the breakpoint is in place.
http://i225.photobucket.com/albums/dd95/withmere/testharness4.jpg
so then i went to the "Method Locals" window to look for the values. Nothing visible in the Method Locals window.
http://i225.photobucket.com/albums/dd95/withmere/testharness5.jpg
There must be a step i am missing. I bring up the driver, install breakpoint at 1961, then Debug>Go, then Debug>Go. Am I missing some other step?

[Mark Stega]

You have to hit the breakpoint for the locals to make sense. Since you didn't, put a break at line 1877 (If ( m_ReceiveBuffer.GetCard1At(kProtocol_SourceZoneOfs ) = kProtocol_Peripheral)) and step through the code when the If is true.

[gacevich]

mark, i appreciate your trying to diagnose the driver. but i don't know how to determine if the code is true. i can get to line 1877, but then what? F12 (step into)? no Debug>Go? no setting of a breakpoint? i need more guidance in order to use the test harness. using the test harness is not something i have experience using. here's to hoping you have the patience to walk me thru this.

ken

edit: i went to technical documentation and skimmed thru the CML Developers Guide and the Driver Development Guide to try and read about the test harness. the test harness writeup i saw was about the PDL test harness and the screen shots looked different there than for the one i'm pulling up. once again i'm stumped.

[Mark Stega]

mark, i appreciate your trying to diagnose the driver. but i don't know how to determine if the code is true. i can get to line 1877, but then what? F12 (step into)? no Debug>Go? no setting of a breakpoint? i need more guidance in order to use the test harness. using the test harness is not something i have experience using. here's to hoping you have the patience to walk me thru this.

ken

edit: i went to technical documentation and skimmed thru the CML Developers Guide and the Driver Development Guide to try and read about the test harness. the test harness writeup i saw was about the PDL test harness and the screen shots looked different there than for the one i'm pulling up. once again i'm stumped.
You must have gone to the driver development guide because that shows the PDL harness and refers you to the CML development guide which definitely shows the CML test harness,

In any case, you want to F12 (step over) the code, keep track of the lines executed, and as soon as the before mentioned variables are set, look at the 'locals' window to get their vailues.

[gacevich]

mark, just so i don't mess up, please confirm that this is what i do:

load driver in harness
go to line 1877
F12
note the line that i jump to
after jump, look at locals window to see if the values for the variables have been set (i'll know that they have been set because the value will show up in the locals window?)
record values
do i stop after the first time they are set or keep going?

i'll review documentation again.

thanks

[Mark Stega]

It will be multiple F12's...

[gacevich]

It will be multiple F12's...

loaded the russound driver
ctrl-g to line 1877
then began using the F12 key.
first time pressed i jumped to line 3507
each successive press moved forward 1 line of code
proceeded to line 4123
when i got to 4123, the "Break" indicator in lower right hand corner would flash to "Run" then back to "Break"
additional F12 would not allow me to advance in the code...stayed on 4123 and toggled btwn Break & Run



checked the Method Locals window at various times during the F12 presses, nothing ever populated in the Method Locals window. it just stayed blank.

does this help identify a problem?

if not, next steps?

[Mark Stega]

Debuggin in this fashion isn't going to work. Can you set up the remote port server and make the device accessible?

[gacevich]

Debugging in this fashion isn't going to work. Can you set up the remote port server and make the device accessible?
would be happy to if you tell me what settings i should enter. pm'd u with my email address. thanks for persevering.

[gacevich]

dean, i don't have the know-how to debug the new driver. i'm going to go back to using the old russound driver. will the old russound driver be maintained as a driver option in future releases?

[Dean Roddey]

I doubt it will. The info on how to set up the remote port server is in one of the FAQ entries. If you go to the Support -> FAQ section of the web site, there's a section called Remote Access. The first FAQ entry under that section contains the info on setting it up.

You'll have to remove the driver first of course, so that the port can be gotten to. PM Mark after you have it set up to remind him about this. There are a lot of threads to watch so it's easy to forget one has some ongoing conversation to return to.

[Mark Stega]

dean, i don't have the know-how to debug the new driver. i'm going to go back to using the old russound driver. will the old russound driver be maintained as a driver option in future releases? Did you not get my e-mail on setting upo the remote port server?

You can always snag a copy of the old driver and maintain it as your own personal copy, but I'd rather see this through and get the released driver debugged.

[gacevich]

Did you not get my e-mail on setting upo the remote port server?

You can always snag a copy of the old driver and maintain it as your own personal copy, but I'd rather see this through and get the released driver debugged.
mark, i'd prefer to see this through also. i found your email in my spam folder...reply is in your inbox. let me know next steps. thanks.

[Mark Stega]

10 minutes in the test harness and the problem is solved. I'll send the updated driver on to Dean for inclusion in the next drop. Meanwhile, here is a driver pack with the repaired driver...

[gacevich]

downloaded and installed v2.5. been testing for about 30 min and the driver seems stable...no losing connection like last time and the st2-xm and st2 currently playing data is coming thru...kinda. when i first installed the driver is did not display the correct FM frequency for the st2. once i changed the frequency it picked up the changed freq and displayed the freq in the iv.

another oddity had to do with my second cav 6.6. i have two and for the first one the driver upon intialization read the correct power, zone and volume status of each field. however, for the second cav all these values were blank until i changed them, then the driver seems to follow them accurately. for example, the volume was 0 for all zones until i tried to change a zone's volume then the driver read the actual volume level. also, the source input was blank until i change a zone's source afterwhich it was tracked fine.

mark, let me know if you want to remote in again to poke around on this issue.

[unclevt]

Thanks for seeing this through. I am not getting any lost comms either with the updated driver. I also have 2 Cav6.6's and the st2s. Same deal for me as far as the second Cav not showing info in the driver until changed.

[gacevich]

i found another issue with the new driver. from the IV i select source 3 or higher for any zone except 7,8,9 or 11 and the cav will change the source for that zone just like you would expect. but the source value in the driver for that zone will flash to the new source number when the cav changes the source, but the value in the driver will flip back to source 2. when the value in the driver flips back to 2, the actual source playing in that zone will not change. i watched this phenomenon occur in the field browser after i saw the IV flash the correct source but then settle on zone 2. anybody else seeing this?

[gacevich]

i found another issue with the new driver. from the IV i select source 3 or higher for any zone except 7,8,9 or 11 and the cav will change the source for that zone just like you would expect. but the source value in the driver for that zone will flash to the new source number when the cav changes the source, but the value in the driver will flip back to source 2. when the value in the driver flips back to 2, the actual source playing in that zone will not change. i watched this phenomenon occur in the field browser after i saw the IV flash the correct source but then settle on zone 2. anybody else seeing this?
zoinks, am i the only one whose zone does not show properly with this driver? the zone reporting issue i described above is not static. that is, sometimes it is the zones listed above that always display source 2 as the selected source (despite actually using a source other than 2), but most often its the first cav (zones 1-6) that has this problem. hoping this is the driver and not my equipment. did not have this problem with the prior driver.

[mheinrich]

I'm hoping this is the correct thread to post this small bug with the 3.0.30 version of the Russound RNET driver.

I currently have 5 sources. I'm guessing these are referenced 0-4 within the driver/serial interface. When I browse the Z0X_Source field for this driver and switch to source 5, I see the field change to source 5, my CAV6.6 changes correctly to source 5, but then immediately the Z0X_Source field goes back to 4. It doesn't change the physical source to 4, it does remain at 5. However, the Z0X_Source is holding the wrong value as it should be 5 at this point, but is showing 4.

Also, the SourceCount field is showing 4 when I have 5 sources. So, I'm guessing that the driver is counting from source 1 instead of starting to count from 0 and there is some logic to say you can't have a source number larger than the count of sources.

[gacevich]

However, the Z0X_Source is holding the wrong value as it should be 5 at this point, but is showing 4.

Also, the SourceCount field is showing 4 when I have 5 sources. So, I'm guessing that the driver is counting from source 1 instead of starting to count from 0 and there is some logic to say you can't have a source number larger than the count of sources.
never thought to check the SourceCount field before. checked it this morning and i'm having same issue, except mine is stopping at 2. i can select any source i want from 1-6, but the indicated source never goes above 2

[jmwhooper]

I'm having problems with the Button Events. I had it set up with the old driver to move through tracks, play, pause etc.

However with the new driver v2.5 sometimes it takes 45 secs for a keypress to be recoginsed by the Triggered Events, it's recognised instantly by the cqceventdump from the CQC command prompt.

Anyone else seeing this?

[Dean Roddey]

That wouldn't be possible. They are broadcast, so they will either be seen immediately or not at all. So if you are seeing that kind of delay, something may be funky with your triggered event. Is it getting blocked for a long time or something? If the event runs at all, then it had to have seen the outgoing trigger at the time it was sent.

You can set it to log when it starts and ends, so you can bring up the log monitor and watch it while you invoke a button. See if it actually starts when you press the button, but doesn't actually end for the 45 seconds or something like that.

[Sacedog]

10 minutes in the test harness and the problem is solved. I'll send the updated driver on to Dean for inclusion in the next drop. Meanwhile, here is a driver pack with the repaired driver...

I just installed 3.1, and went to check the RNet driver to make sure it was updated. My driver info shows 1.19, but when I click Add Driver, the RNet driver listed shows 2.5.

Do I need to reinstall my RNet driver to use the 2.5 version?

[gacevich]

i found another issue with the new driver. from the IV i select source 3 or higher for any zone except 7,8,9 or 11 and the cav will change the source for that zone just like you would expect. but the source value in the driver for that zone will flash to the new source number when the cav changes the source, but the value in the driver will flip back to source 2. when the value in the driver flips back to 2, the actual source playing in that zone will not change. i watched this phenomenon occur in the field browser after i saw the IV flash the correct source but then settle on zone 2. anybody else seeing this?
i discovered the issue here. when i installed the driver i assigned source 1 to st2-xm and source 2 to st2...all others were none. thus source count was 2. whenever a keypad was "ON" the IV would not recognize a source >2. if the keypad was "OFF" the IV would recognizes sources >2. so if a keypad was on, i could change source via IV but the driver would immediately revert the source to 2 if a source >2 was selected. to cure this i reinstalled the driver putting "Generic" for all non-russound sources. source count is now 7 (as it should be) and my issue has been resolved.

[gacevich]

now that my source display has been solved i've moved on to the next step which is to write the artist and song to the keypad. i have written the following triggered event. using my diagnostic variables i can confirm that the if statements should be allowing me to do a fieldwrite for RussoundRNet.TextAddressZone and .TextDisplay. However, the test is not displaying. Reading thru the driver write-up in the Support section, i cannot figure out where i'm going wring with my fieldwrite commands. any thoughts?

/ UNO Button event data is in the format of
// Event Data: <zz><s><ButtonName>
// <zz>: zone num, from 01 to 32
// <s>: Source num, from 1 to 7
// <ButtonName>: Any of the following: Previous, Next, Plus, Minus, Stop, Pause, F1, F2, Play, Source
TrigEvent::GetEvField(/cqsl.actinfo/evdata, LVar:UNOevent)
LocalVars::GetLength(LVar:UNOevent, LVar:UNOeventlength)
// get the first two characters in UNOevent
LocalVars::GetSubString(LVar:UNOevent, 0, 2, LVar:UNOzone)
// Get the third character in UNOevent
LocalVars::GetSubString(LVar:UNOevent, 2, 1, LVar:UNOsource)
// Remove the first three characters from UNOevent
LocalVars::Subtract(LVar:UNOeventlength, 3)
// Get the uno button pressed
LocalVars::GetSubString(LVar:UNOevent, 3, %(LVar:UNOeventlength), LVar:UNObutton)
// The follwing five lines are for diagnostics
Devices::FieldWrite(KensVariables.UNOeventlength, %(LVar:UNOeventlength), True)
Devices::FieldWrite(KensVariables.UNObutton, %(LVar:UNObutton), True)
Devices::FieldWrite(KensVariables.UNOzone, %(LVar:UNOzone), True)
Devices::FieldWrite(KensVariables.UNOsource, %(LVar:UNOsource), True)
Devices::FieldWrite(KensVariables.UNOevdata, %(LVar:UNOevent), True)
// The below writes the artist and title to a keypad is source 3 is selected
If System::Equals(%(LVar:UNObutton), Source)
If System::Equals($(KensVariables.UNOsource), 3)
Devices::FieldWrite(RussoundRNet.TextAddressZone, $(KensVariables.UNOzone), True)
Devices::FieldWrite(RussoundRNet.TextDisplay, $(Audio1.CurItemArtist)-$(Aud..., True)
End

[kayemsi]

I think it would work better to build the display text in a local variable and then write it to the TextSourceDisplay. Here is some of my code:

LocalVars::SetVariable
P1=LVar:SongText
P2=$(CQC-AudioPlayer-1.CurItemArtist)

LocalVars::Append
P1=LVar:SongText
P2= -

LocalVars::Append
P1=LVar:SongText
P2=$(CQC-AudioPlayer-1.CurItemName)

Devices::FieldWrite
P1=sample-Russound-CAV.TextAddressController
P2=0
P3=True

Devices::FieldWrite
P1=sample-Russound-CAV.TextAddressSource
P2=3
P3=True

Devices::FieldWrite
P1=sample-Russound-CAV.TextSourceRepeat
P2=True
P3=True

Devices::FieldWrite
P1=sample-Russound-CAV.TextFlashTime
P2=0
P3=True

Devices::FieldWrite
P1=VarDrv.SongText
P2=%(LVar:SongText)
P3=True

Devices::FieldWrite
P1=sample-Russound-CAV.TextSourceDisplay
P2=%(LVar:SongText)
P3=True

[gacevich]

I think it would work better to build the display text in a local variable and then write it to the TextSourceDisplay. Here is some of my code:
kaysemi, i thought about using a local variable but didn't see the value in taking the information from a field and converting it into a LVar. why not just use the driver's field value directly?

as for the commands to write to the keypad, is it the case that you specify the controller address as opposed to the textaddresszone? i have 12 keypads (textaddresscontroller only goes to 6) and thought i should specify zone since i only want to display the info in the zone where the squeezebox is playing.

as for the textaddressource and textaddressrepeat commands, i did not see them in the driver documentation. am i going blind or are u using and undoumented feature?

[Dean Roddey]

If you don't need to maniuplate the value before writing it back out somewhere else, you can do it directly from the field value. If you need to parse something out or change it in some way, you'll want to get it to a local variable first.

[sic0048]

If it is just for formating the string in a certain way, you could also use the logic driver for that now. I suspect kayemsi wrote that action prior to the logic driver being released. You could set a field in the logic driver that would be made up of several other driver fields. Basically you could end up with something like this:

"Artist Name - Name of Album - Name of Song" and have it all stored in a single logic driver field. Then you would only need to write the single logic driver field into the Russound display field.

[kayemsi]

I am using RNet-serial develoment driver version 1.19. I have not updated to the new released driver, I am on CQC 3.1.

[gacevich]

I am using RNet-serial develoment driver version 1.19. I have not updated to the new released driver, I am on CQC 3.1.
Dean, I was previously using the new driver developed by mark and sergio posted in post#165 of this thread. mark's version is unnumbered and he said in the post that he was forwarding to you for inclusion in the next beta. i downloaded and installed v1.19 from the beginning of this thread thinking that not using the most recent version was my issue. upon installation of v1.19 i realized that it uses the old zone naming convention instituted by toymaster...mark and sergio changed to a different zone naming convention and i converted to their zone naming convention when i shifted over to their new driver. my question for you is what version of the russound driver ships with v3.1 of cqc?

if it is v1.19 and that includes mark's and sergio's upgrade to the driver, then i'll bite the bullet and redo my templates with the old zone naming convention. if doesn't, will you be serving up their driver (and its new zone naming convention) in the future as the standard russound driver? just trying to minimize the monkey work of redoing my templates zoning convention. thanks.

edit: this answers the question of why i could not find commands in the documentation. all the comments of people citing commands that could not find were using the v1.19 html in post 1. i was going to the support section of the cqc website and looking up the russound driver. if v1.19 is the lastest version, fwiw, i recommend updating the support section with the writeup on the v1.19 russound driver.

[Dean Roddey]

It should be the most recent version, which includes those changes. The manifest in 3.1 shows version 2.5.

[gacevich]

// 2.0 31MAR09 Changed zone naming convention to simply list zones by zone number (Vidabox-SD)

Dean, thanks for clearing up the most recent version question. And I hate to be a pain on this but I installed v2.5 of the Russound driver that shipped with my 3.1 beta and found that it uses the old zone naming convention. Per Mark's post, this driver should have the new zone naming convention. Can you reconcile?:confused:

[Dean Roddey]

We'll have to get Mark or Sergio to comment. Both the manifest and the driver code indicate it's version 2.5, so it would appear I have the latest versions in the 3.1 release. We'll have to ask them how this could have happened.

[Mark Stega]

I just loaded the 'included in the release' Russound driver on my 3.1 system and it has the 2.5 code and naming convention. Are you certain that you don't have a user driver that you are selecting? The Russound version is 2.5 and that is what is shown in the manifest and the source file.

[gacevich]

Mark, after all the back and forth about v1.19, I opened my v3.1 cqc and loaded the v2.5 Russound driver option. Previously i had been using the version of the "new" russound driver embbeded in one of your posts from earlier in this thread. I was surprised to find that the naming convention had changed, hence my post. When get home tonight I'll test the driver Mark posted in the thread vs. 2.5 that shipped with v3.1.

[gacevich]

so i got home to look at the russound driver options in v3.1. there are three listed:

Russound RNet v2.5
Russound RNet Serial-DEV v1.19
Russound RNet-Dev v2.5

during my install yesterday i started at the bottom and selected the Russound RNet-Dev driver. it was listed as v2.5 and had mark, sergio and kirk as authors. seemed good to me. well, my above post talks about the naming convention issue i ran into. when i looked at the Russound RNet driver it says v2.5 but does not list the authors. not listing authors is why i did not select this one since i knew i wanted the one that mark and sergio worked on.

is there a good reason to have both v2.5 drivers? or is the bottom one that is just showing up in my system from old beta testing? if so, how might i remove the unwanted driver from my list of possible drivers?

sorry for the confusion. the confusion was all mine.

[Dean Roddey]

The ones with -DEV are not shipped versions of the driver. They are other development versions you have loaded over time. You should really delete the manifests for those two. THe first one would be the official shipped one and have all the latest changes.

[Dean Roddey]

If someone has an MCA-C5, what would be the best options to select for the controller type and the zone 1 source?

[standon]

If someone has an MCA-C5, what would be the best options to select for the controller type and the zone 1 source?

Hey Dean, I have this system... and just recently redid the tuner source so I could make an interface for it. I ran into a wall when I tried to define the radio tuner on my ST2S (Sirius) as an ST2S (if that makes sense - The ST2S has 2 sources, one Sirius tuner and one AM/FM tuner).

Source 1 with the Sirius tuner is Sirius (ST2S), but Source 2 on mine is ST2, which gives me full control of tuning radio stations. I'd assume that even if you use the built in radio as your source 1, the commands it sends under ST2 will not differ and will be a better fit.

[Dean Roddey]

Anyone have any issue with the driver cycling if you use the DoNotDisturb field? It seems to try to write to an unset field id (which is set to 0 and therefore it getting mapped to the $BadMsgs field.) I'm setting up a system for someone and ran into this. It cycles any time I write to this field.

[Mark Stega]

Just reading the code looks OK. If you want a place to start go to line 3226 (Approximately) where the field ID's are looked up from tthe name and stored in the field id arrays. Then look at what happens when you write t the field at 4185 or so. If you have remote connectivity to a system I could help.

It appears that the shipped driver (2.5) matches my source code version.

[Dean Roddey]

I'll pause the driver on his system and bring it up in the IDE and see what I can figure out. If I find it I'll update the shipped driver with the fixes.

[standon]

Any way you could take a look at the ST2S (Sirius tuner) portion while you're in there? For some reason it flashes the Artist for a split second when I turn it on then shows the Comment in the metadata for the rest of the time.

[Dean Roddey]

He only currently has an AM/FM tuner, so I can't really exercise that functionality at the moment. He has plans later to update them.

[Dean Roddey]

It looks like what is happening is that some field writes, and possibly changes on the Russound itself, cause it to send out messages for zones not defined by the driver. Writing to the DoNotDisturb appears to cause it to send the do not disturb value for all zones out.

The message handler method doesn't limit handling of messages to zones that it has set up fields for, so when one of those comes in, the zone index is beyond the set fields and it gets a zero. So it looks like it just needs to ignore messages for zones beyond what it is set up for. I'll make that change and see how it does. If it fixes the issues, I'll make that change in the shipped version.

[Mark Stega]

It looks like what is happening is that some field writes, and possibly changes on the Russound itself, cause it to send out messages for zones not defined by the driver. Writing to the DoNotDisturb appears to cause it to send the do not disturb value for all zones out.

The message handler method doesn't limit handling of messages to zones that it has set up fields for, so when one of those comes in, the zone index is beyond the set fields and it gets a zero. So it looks like it just needs to ignore messages for zones beyond what it is set up for. I'll make that change and see how it does. If it fixes the issues, I'll make that change in the shipped version.

I don't understand that because we define the fields based upon the number of zones (at 6 per CAM, CAV, CAS). I think the only way what you describe could happen would be in a multi unit install with an incorrect number of zones entered while processing the manifest.

I think I found another three:

In the manifest the maximum number of zones id 38. With the CAM, CAV, CAS series you can gang 6 units for a maximum of 36 z0nes. For the ACA-E5 it is 6 controllers also, but with 8-16 zones per controller so 48-96 zones total.

On about line 2169 in HandleMessages() the RNetControllerID and RNetZoneID are extracted from the received message and then ZoneNum is calculated from that zone and controller. However, if you look at CalculateControllerZone() there is special handling for the ACA-E5 which supports eight base controller zones and optional eight expander zones. Since the calculation doesn't take into account expander zones it is calculating the same zonenum in several cases (say there are two controllers, each with an expander, controller id = 0, zone id = 8 is zonenum of 8, controller id = 1, zone id = 0 is zonenum of 8 also).

What is worse is that I think CalculateControllerZone is also flawed in handling the ACA-E5 in two ways. First the calculation of zone and controller are wrong presuming that all base units have a single expander. Second, nothing would prevent some base units from having expanders, others not. Reading what little is available on the web I think that this series is defunct. Fortunately, the E series was a "dealers only" product line so we aren't likely to see one except for an IP so we would have the chance to work through the issues.

[Dean Roddey]

Oh, OK, in this case, the user has only 15 zones in use, so the zone count was set to 15. Maybe the actual physical zone count is 16, so that might explain it. But it's nice to not have to define zones you don't use, since it can lower the number of fields significantly. The change I made would allow for that.

[Mark Stega]

Oh, OK, in this case, the user has only 15 zones in use, so the zone count was set to 15. Maybe the actual physical zone count is 16, so that might explain it. But it's nice to not have to define zones you don't use, since it can lower the number of fields significantly. The change I made would allow for that.

So I'd recommend changing the documentation to state that the ACA-E5 support does not include expanders and to set the number of expanders to zero in IntializeCommon() for the ACA-E5 (And why was this 6? The number of expansion channels is 4 or 8 as far as I can tell).

[Dean Roddey]

OK, I made that change. You meant m_RNetZonesPerExpander being set to zero, right?

[daddyd]

Is anyone else running this on .913? I'm having a lot of disconnects and need to confirm if it's just me. I am running the shipped version of the driver (v2.6) and 2 CAA6's (for a total of 12 zones).

[Dean Roddey]

Give this one a try. Not sure if it will make a difference, but check it and see. You'll have to unload the driver, import this guy, then reload it. If it works, I'll remove it from here and put it in the first post.

[daddyd]

I removed the original driver, imported te new driver, then add new device - still see just the original driver (V2.6) in the list, not the new one.

[Dean Roddey]

Did you import the one above, not the one on the first post?

[Dean Roddey]

OK, I updated the package linked to above, so give it another shot.

[daddyd]

Dean, it appears that the link is missing.

[Dean Roddey]

Oops, it was a long day. Here it is...

[daddyd]

That did it - thanks Dean! I appreciate all the patience on this one. It really sucked having to get up and use the wall mounted keypad.......

[Dean Roddey]

Okey dokey. That change will be in the subsequent releases.

[daddyd]

Dean, with time I'm still seeing drop outs on this driver. Trying to catch something in the logs to go by though.

[Dean Roddey]

We may still be on the hairy edge or something. Ultimately I think the whole thing needs to be readdressed at some point here. It's definitely one of those devices where far too little thought was put into the integration interface provided, so the driver is more complex than it would otherwise have to be I think. And it's been around a while, and through a number of hands.

[standon]

Yesterday I updated to .921 and my Russound MCA-C5 worked for a short bit - but it's not connecting any more. Is anyone else having a problem with the C5 and v2.7 of the driver?

Here's my high verbosity log:

{
CQCKit, CQCDriver_DriverBase.cpp.3496, Status/App Status
Driver 'RussoundCSeries' is trying to get its comm resource
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCKit, CQCDriver_DriverBase.cpp.3535, Status/App Status
Driver 'RussoundCSeries' has its comm resource
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCKit, CQCDriver_DriverBase.cpp.3553, Status/App Status
Driver 'RussoundCSeries' is trying to connect to its device
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:1
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 00 7F 00 00 71 01 04 02 00 00 07 00 00 7D F7
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:2
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 01 7F 00 01 71 01 04 02 00 01 07 00 00 00 F7
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:3
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 02 7F 00 02 71 01 04 02 00 02 07 00 00 03 F7
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Invalid msg: 00 00 71 00 00 7F 00 00 04 02 00 00 07 00 00 01 00 0C 00 00 00 0D 0A 0A 00 0A 01 01 00 00 00 47
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:4
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 03 7F 00 03 71 01 04 02 00 03 07 00 00 06 F7
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:5
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 04 7F 00 04 71 01 04 02 00 04 07 00 00 09 F7
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:6
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 05 7F 00 05 71 01 04 02 00 05 07 00 00 0C F7
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Invalid msg: 00 01 71 00 00 7F 00 00 04 02 00 01 07 00 00 01 00 0C 00 00 00 0E 0A 0A 00 0A 01 00 00 00 00 49
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:7
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 06 7F 00 06 71 01 04 02 00 06 07 00 00 0F F7
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:8
}
04/18 13:28:00-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 07 7F 00 07 71 01 04 02 00 07 07 00 00 12 F7
}
04/18 13:28:30-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCKit, CQCDriver_DriverBase.cpp.6909, Status/Lost Connection
Driver 'RussoundCSeries' has lost its communcations resource
}

I did see this invalid message at one point but it doesn't always come up:
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:4
}
04/18 13:28:35-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 03 7F 00 03 71 01 04 02 00 03 07 00 00 06 F7
}
04/18 13:28:35-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Invalid msg: 00 00 71 00 00 7F 00 00 04 02 00 00 07 00 00 01 00 0C 00 00 00 0D 0A 0A 00 0A 01 01 00 00 00 47
}
04/18 13:28:35-QuadCore, CQCServer, CQCDrv_RussoundCSeriesThread1203
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:5
}

When I configure the driver, I select "ACA-E5" as the controller, 8 zones to be controlled, ST2S for Source 1, ST2 for source 2, "generic" for sources 3-8 and "none" for sources 9-12. It keeps losing connection after GetState Zone:8

[daddyd]

Yeah, I have 2 CAA6.6's and it drops quite frequently with the same sort of invalid message error (but that doesn’t seem to be the trigger for the disconnect). I bet if you give it time, it will eventually connect.

[Mark Stega]

I just looked at the driver and the "Connect" method does a poll of each zone and tries to process returned messages via "HandleMessage". It requires that at least one valid message appear during the polling of all zones. Based on your logs you never get a valid message.

So you have to try the usual suspects, i.e., did the RS-232 interface get turned off in the upgrade, did the serial characteristics change (baud rate, etc.) can you communicate via a console ASCII emulator, etc. ?

[Mark Stega]

Yeah, I have 2 CAA6.6's and it drops quite frequently with the same sort of invalid message error (but that doesn’t seem to be the trigger for the disconnect). I bet if you give it time, it will eventually connect.
If you get a chance see if you can capture that event in the logs. It should log an invalid message but not exit (unless we get past the timeout period for declaring the device as "dead" (60 seconds) without getting a valid message).

[kfly]

I just had some strange behavior after the 4.3 upgrade and my CAA66. After upgrade Driver was offline and could not get it to reconnect to device. I re-downloaded 2.7 driver still no good. I back revd CQC to .921 beta checked all serial ports and after 4 hours of power cycling everything, checking and re-checking still no connection to driver. I could run a RNet backup on the CAA66 so I know the serial port was good, but the driver would not show it online.

Odd thing was after letting sit overnight the CAA66 finally came online at some point in the night. Very strange and makes no technical sense. I will wait a few more weeks before attempting the 4.3 upgrade again.

This is what was in the log and I assume the driver had issues with the data that was being returned by the CAA66.

}
04/27 19:18:29-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 01 7F 00 01 70 01 04 02 00 01 07 00 00 7F F7
}
04/27 19:18:29-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Invalid msg: 00 00 70 00 00 7F 00 00 04 02 00 00 07 00 00 01 00 0C 00 00 00 21 0A 0A 00 0A 00 00 00 00 00 58
}

[Dean Roddey]

Looking at the driver, it logs that msg if the first character isn't STX, or it's zero length which isn't the case here.

One thing that is puzzling is that, if the msgs are STX/ETX bracketed, why it doesn't use the GetStartStopMsg helper, which would insure that bogus characters between msgs are ignored easily. It may be because when this driver was written there was an issue with that method, and I think that was the case, but it's been fixed for some time and this driver could probably be updated to use that and it might help.

Currently it's just looking for anything ending with ETX, which could pick up any bogus non-msg bytes that the device sees, or partial msgs if it times out.

Just for funzies, unload the driver, import the attached driver pack, and re-load it and see if this does any better. I had to do this by eye, so it could just be an epic fail, but you can always just put the other one back if so. This one bumps up the 'slop factor' for message reading, so that if a msg starts coming in just as the timeout period ends, it'll give it longer to get the msg read. And it uses the StartStop type msg reader which hopefully will be more tolerant, perhaps.

[kfly]

Dean,
re-upgraded to 4.3 and is stuck at offline again. I imported your experimental driver and then did a "remove driver" and "Add driver" and Driver is still sitting at wait for connect after 15 minutes. Power cycled CAA66 just in case but still offline.
I will let it sit overnight in hopes of a visit from the driver fairy to magically make it go back online.

04/29 21:03:20-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.6909, Status/Lost Connection
Driver 'Russound' has lost its communcations resource
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3496, Status/App Status
Driver 'Russound' is trying to get its comm resource
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3535, Status/App Status
Driver 'Russound' has its comm resource
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3553, Status/App Status
Driver 'Russound' is trying to connect to its device
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:1
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 00 7F 00 00 70 01 04 02 00 00 07 00 00 7C F7
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:2
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 01 7F 00 01 70 01 04 02 00 01 07 00 00 7F F7
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:3
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 02 7F 00 02 70 01 04 02 00 02 07 00 00 02 F7
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:4
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 03 7F 00 03 70 01 04 02 00 03 07 00 00 05 F7
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:5
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 04 7F 00 04 70 01 04 02 00 04 07 00 00 08 F7
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:6
}
04/29 21:03:25-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 05 7F 00 05 70 01 04 02 00 05 07 00 00 0B F7
}
04/29 21:03:55-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.6909, Status/Lost Connection
Driver 'Russound' has lost its communcations resource
}
04/29 21:04:00-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3496, Status/App Status
Driver 'Russound' is trying to get its comm resource
}

[Dean Roddey]

Is it by any chance always only getting to Zone 6 and then croaking? Or is it pretty random how far it gets?

[kfly]

Is it by any chance always only getting to Zone 6 and then croaking? Or is it pretty random how far it gets?

Zone 1 to 6 over and over again.
Thanks
Kevin


04/29 22:59:59-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 05 7F 00 05 70 01 04 02 00 05 07 00 00 0B F7
}
04/29 23:00:29-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.6909, Status/Lost Connection
Driver 'Russound' has lost its communcations resource
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3496, Status/App Status
Driver 'Russound' is trying to get its comm resource
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3535, Status/App Status
Driver 'Russound' has its comm resource
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3553, Status/App Status
Driver 'Russound' is trying to connect to its device
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:1
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 00 7F 00 00 70 01 04 02 00 00 07 00 00 7C F7
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:2
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 01 7F 00 01 70 01 04 02 00 01 07 00 00 7F F7
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:3
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 02 7F 00 02 70 01 04 02 00 02 07 00 00 02 F7
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:4
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 03 7F 00 03 70 01 04 02 00 03 07 00 00 05 F7
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:5
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 04 7F 00 04 70 01 04 02 00 04 07 00 00 08 F7
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:6
}
04/29 23:00:34-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 05 7F 00 05 70 01 04 02 00 05 07 00 00 0B F7
}
04/29 23:01:04-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.6909, Status/Lost Connection
Driver 'Russound' has lost its communcations resource
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3496, Status/App Status
Driver 'Russound' is trying to get its comm resource
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3535, Status/App Status
Driver 'Russound' has its comm resource
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3553, Status/App Status
Driver 'Russound' is trying to connect to its device
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:1
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 00 7F 00 00 70 01 04 02 00 00 07 00 00 7C F7
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:2
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 01 7F 00 01 70 01 04 02 00 01 07 00 00 7F F7
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:3
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 02 7F 00 02 70 01 04 02 00 02 07 00 00 02 F7
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:4
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 03 7F 00 03 70 01 04 02 00 03 07 00 00 05 F7
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:5
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 04 7F 00 04 70 01 04 02 00 04 07 00 00 08 F7
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:6
}
04/29 23:01:10-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 05 7F 00 05 70 01 04 02 00 05 07 00 00 0B F7
}
04/29 23:01:40-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.6909, Status/Lost Connection
Driver 'Russound' has lost its communcations resource
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3496, Status/App Status
Driver 'Russound' is trying to get its comm resource
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3535, Status/App Status
Driver 'Russound' has its comm resource
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.3553, Status/App Status
Driver 'Russound' is trying to connect to its device
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:1
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 00 7F 00 00 70 01 04 02 00 00 07 00 00 7C F7
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:2
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 01 7F 00 01 70 01 04 02 00 01 07 00 00 7F F7
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:3
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 02 7F 00 02 70 01 04 02 00 02 07 00 00 02 F7
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:4
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 03 7F 00 03 70 01 04 02 00 03 07 00 00 05 F7
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:5
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 04 7F 00 04 70 01 04 02 00 04 07 00 00 08 F7
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:6
}
04/29 23:01:45-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 05 7F 00 05 70 01 04 02 00 05 07 00 00 0B F7
}
04/29 23:02:15-CQC1, CQCServer, CQCDrv_RussoundThread21
{
CQCKit, CQCDriver_DriverBase.cpp.6909, Status/Lost Connection
Driver 'Russound' has lost its communcations resource
}

[Dean Roddey]

Well, that's got to be a clue, though I'm not sure what. How many zones does this guy have? Are they in groups of 6 or 8?

[kfly]

Well, that's got to be a clue, though I'm not sure what. How many zones does this guy have? Are they in groups of 6 or 8?

One caa66 unit has a total of 6 zones with 6 zones configured.

[Dean Roddey]

I can't remember if you said you had more than one or not? Do you just have one, so there are only 6 zones in total? If so, then likely it has nothing to do with 6 and it's gone on to do some other thing after getting the initial zone status and it's failing at that point.

If you have more than one, then it can't be a coincidence that it's failing when it goes to the zones on the second one, or it seems unlikely anyway.

[Mark Stega]

If there are 6 zones then the attempt to connect runs through those and then does a failure return if no messages are returned. Looking at the logs the 6 queries go out and there are no well formed replies.

[kfly]

Yes one physical CAA66 unit... with 6 zones.

With the Hercules serial terminal I can open comm port and turn the zone 1 off and on with:
This command will turn zone 1 ON:
F0 00 00 7F 00 00 70 05 02 02 00 00 F1 23 00 01 00 00 00 01 12 F7

This command will turn zone 1 OFF:
F0 00 00 7F 00 00 70 05 02 02 00 00 F1 23 00 00 00 00 00 01 11 F7

So pretty sure it is a driver issue.

Driver didn't connect on experimental driver overnight. went back to RNET 2.7 and still getting below and driver is off-line.

{
CQCKit, CQCDriver_DriverBase.cpp.6909, Status/Lost Connection
Driver 'Russound' has lost its communcations resource
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCKit, CQCDriver_DriverBase.cpp.3496, Status/App Status
Driver 'Russound' is trying to get its comm resource
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCKit, CQCDriver_DriverBase.cpp.3535, Status/App Status
Driver 'Russound' has its comm resource
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCKit, CQCDriver_DriverBase.cpp.3553, Status/App Status
Driver 'Russound' is trying to connect to its device
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:1
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 00 7F 00 00 70 01 04 02 00 00 07 00 00 7C F7
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:2
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 01 7F 00 01 70 01 04 02 00 01 07 00 00 7F F7
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Invalid msg: 00 00 70 00 00 7F 00 00 04 02 00 00 07 00 00 01 00 0C 00 00 00 21 0A 0A 00 0A 00 00 00 00 00 58
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:3
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 02 7F 00 02 70 01 04 02 00 02 07 00 00 02 F7
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:4
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 03 7F 00 03 70 01 04 02 00 03 07 00 00 05 F7
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Invalid msg: 00 01 70 00 00 7F 00 00 04 02 00 01 07 00 00 01 00 0C 00 00 00 1F 0A 0A 00 0A 00 00 00 00 00 58
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:5
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 04 7F 00 04 70 01 04 02 00 04 07 00 00 08 F7
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 77, Status/App Status
Sending: GetState Zone:6
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Sending: F0 00 05 7F 00 05 70 01 04 02 00 05 07 00 00 0B F7
}
04/30 09:37:28-CQC1, CQCServer, CQCDrv_RussoundThread6
{
CQCGenDrvS, MEng.System.CQC.Drivers.Russound.RNET.DriverImpl.7 50, Status/App Status
Invalid msg: 00 02 70 00 00 7F 00 00 04 02 00 02 07 00 00 01 00 0C 00 00 00 19 0A 0A 00 0A 00 00 00 00 00 54
}

[Dean Roddey]

The issue isn't control, but response apparently. The driver isn't getting anything back from the zone state queries. Can you send the zone state query messages that you see in the logs above, and see what you get back?

I think my newer one is doing better, you just don't see all the invalid message errors because they aren't even accepted as messages anymore with mine because it's doing the start/stop character checking and these messages being returned aren't right for some reason.

[kfly]

The issue isn't control, but response apparently. The driver isn't getting anything back from the zone state queries. Can you send the zone state query messages that you see in the logs above, and see what you get back?

I think my newer one is doing better, you just don't see all the invalid message errors because they aren't even accepted as messages anymore with mine because it's doing the start/stop character checking and these messages being returned aren't right for some reason.

This is what I sent
{F0}{00}{00}{7F}{00}{00}{70}{01}{04}{02}{00}{00}{0 7}{00}{00}{7C}{F7}


This is the response
{F0}{00}{00}{70}{00}{00}{7F}{00}{00}{04}{02}{00}{0 0}{07}{00}{00}{01}{00}{0C}{00}{01}{00}{21}{0A}{0A} {00}{0A}{01}{00}{00}{00}{00}{5A}{F7}

Thanks
Kevin

[kfly]

If I send the zone 2 one that was returning Invalid message in the logs before:

{F0}{00}{01}{7F}{00}{01}{70}{01}{04}{02}{00}{01}{0 7}{00}{00}{7F}{F7}

It returned
{F0}{00}{01}{70}{00}{00}{7F}{00}{00}{04}{02}{00}{0 1}{07}{00}{00}{01}{00}{0C}{00}{00}{00}{1F}{0A}{0A} {00}{0A}{01}{00}{00}{00}{00}{59}{F7}

41 seconds later this came back
{F0}{7E}{01}{70}{00}{00}{7F}{05}{02}{01}{00}{02}{0 1}{00}{F1}{37}{00}{00}{00}{01}{00}{01}{29}{F7}

Not sure why it would send data unrequested.
all three look like valid formed packets.( from my novice eyes)

I ordered a new remote for the caa66 so I can try an do a factory reset. I couldn't figure out how to do that with just the buttons. I think you need a remote to do that. I don't have any Keypads just use cqc to control.

Kevin

[Dean Roddey]

The original driver is clearly complaining because there is no F0 start byte. Otherwise the messages look basically correct. It expects there to be no F7 at the end, since that's the terminator character and the msg reader removes it. But it does expect the F0 and it's not there in any of those messages, and that's the only way that Invalid msg: error can be getting logged.

And, presumably in mine experimental one since it's looking for the STX and ETX in the msg reader, it's not getting any responses at all because the message reader is not seeing the STX, so the reader never even reports back that it got a message.

So that raises the question of how on earth it could not be getting the F0 but getting everything else. How could it be just dropping the first character but not the rest. Given that it appears to be happening on two different msg reader methods, it's not too likely that they both have the same issue.

Can you set up the remote port server and forward is so that I can connect to it and poke around?

[kfly]

The original driver is clearly complaining because there is no F0 start byte. Otherwise the messages look basically correct. It expects there to be no F7 at the end, since that's the terminator character and the msg reader removes it. But it does expect the F0 and it's not there in any of those messages, and that's the only way that Invalid msg: error can be getting logged.

And, presumably in mine experimental one since it's looking for the STX and ETX in the msg reader, it's not getting any responses at all because the message reader is not seeing the STX, so the reader never even reports back that it got a message.

So that raises the question of how on earth it could not be getting the F0 but getting everything else. How could it be just dropping the first character but not the rest. Given that it appears to be happening on two different msg reader methods, it's not too likely that they both have the same issue.

Can you set up the remote port server and forward is so that I can connect to it and poke around?
ok I have setup the remote port server running. will PM you with details.

[Dean Roddey]

OK, I see what is wrong. Drivers have an 'extension' value for the timeout. No matter how long or short the driver waits for a msg, it could always start coming in just as the timeout is about to end. So, if some bytes have started coming in when the timeout hits, it will extend the timeout.

During the recent changes in the driver architecture, to deal with changes in how locking is done, the msg reading helpers lock and get a copy of the verbosity and the timeout (the only values they need to get from the driver object's members.) They use those local copies during the reading of the message.

But, I somehow did this:

m_enctExtend = m_enctExtend;

I.e. i just put the member value back into itself, instead of into the local copy, so the local copy was zero., therefore there was no extension being done. I didn't do that in all of the helpers, but a number of them.

Any driver that has to deal with async msgs will, in their poll callback, do a check using a very short timeout, so as to only get msgs that are waiting already, not blocking to wait for one to arrive. These were failing because the total timeout would have only been that very short timeout. So as soon as the device delayed at all in sending a msg, it wouldn't get it all.

I'll get a new build with this fix in it up for you to use and is should fix this issue. I left my start/stop msg reader change in place since it works and is safer in that it'll catch bad msgs better.

[Dean Roddey]

OK, 4.3.901 should fix that problem. It could have affected other drivers as well, though it would have likely been very sporadic in most drivers since the devices are fast enough that it would seldom ever happen, and of course I didn't make the mistake in all of the msg reader methods.

[kfly]

Thanks for the quick fix!. Russound driver back online now.
Kevin