New PDL Driver for Nuvo Concerto

[robertmee]

Working on a new driver for the Nuvo Concerto line of whole house audio distribution systems. The protocol is pretty clean and it actually lent itself to doing a PDL driver vs my original intent of doing CML. Right now, I have it set up to control upto three Nuvos tied together (zones 1 through 20) and controlling the volume, power, source, and mute of each zone. Plus, you'll have the ability to send text to each keypad briefly or permanently (until the next event). Kindof cool for maybe displaying the temperature periodically or CID events.

Anyway, one thing I need some help for from the PDL gurus is how to do a conditional Reply. There is a Zone status query that I use to get the current state of each zone (using a replacement variable for each zone name). Easy enough I think. But the query that comes back can be of two forms whether that zone is a regular zone, or if it is slaved to another zone. If it is a regular zone, it sends back:

#ZzzPWRonoff,SRCs,VOLvvvMT

If it is a Slave, it sends back:

#ZzzSLAVETOzmPWRonoff,SRCs,VOLvvvMT

The obvious difference is that SLAVETOzm is inserted if it is a slaved zone. The other stickler is that the "MT" at the end may or may not be there. If the zone is muted, it is, otherwise, nothing is sent. Lastly, how do I interepret the zz (zone) into the field store:

I guess what I need is something to the effect (Dynamically interpreting zz)

Store=
ZzzPower = (Find PWR in the string, look at the 2nd character after PWR,
if n set to True)
ZzzSource = (Find SRC in the string, store the value of 1st character s)
ZzzVolume = (Find VOL in the string, store the value of 1-3 characters vvv)
ZzzMute = (Does the string MT exist)
EndStore;

Is it possible to do the above conditions as well as dynamically create the fieldname based on the value of zz? I guess I could create two replies and use message matching to pick the right one, but I was wondering if it could be done in one reply. As for the zz interpretation, I know you can do Indirect stores, so would I do something like this:

Store=
ZonePowerFld = "Z" + Extract(&reply,1,2) + "Power"; (Not sure of the format to concatenate strings)
*ZonePowerFld = (etc.)

[Dean Roddey]

That's one of those limitations of PDL. It doesn't deal easily with such things. It only takes one or two inconsistencies in the protocol to make it not doable in PDL. It's purely declarative except for the special case of the state machine, so there's no logic available. Well, the BoolSel() thing is a very simple kind of logic.

[robertmee]

Yes, But....

If I can't do logic within the reply itself, could I not do it in the messagematch area and just have two replies that store into the same fields?

For example,

Case
StatusReplywSLAVE
IfAny(Equals(ExactStr(&reply,3,1),'S'));

StatusReplywoSLAVE
IfAny(Equals(ExactStr(&reply,3,1),'P'));
EndCase;

Then StatusReplywSLAVE and StatusReplywoSLAVE would store into the same fields but parse different parts of the string to get the value.

That should work shouldn't it?

If so, then all that remains is the other part I asked about which I think could be done with a store of the field name into a variable and then use the *variable as the store field.

[Dean Roddey]

That's a possibility. Some other drivers do something similar.

[Dean Roddey]

I don't remember right off hand, I'd have to look it up. Going through the current PDL drivers, it doesn't look like any of them uses this functionality. I'll have to dig into the code and I can't do it right at the moment.

[robertmee]

If I do an ExtractStr at an offset longer than the string length will it generate an exception or ignore it?

For example, the status could be xxxxxxxxxxMT or xxxxxxxxxxxx the only difference being the presence of MT at the end of the string which indicates Mute. If I do

Reply
Store=
Z1Mute=ExtractStr(&Reply, 10, 2)
EndStore

What happens in the second case where the string is only 10 characters long? Will Z1Mute = False, or will an exception be thrown?

[Dean Roddey]

If you attempt to start beyond the buffer length, you'll get an empty string.

[robertmee]

If you attempt to start beyond the buffer length, you'll get an empty string.

Cool...That'll work

[robertmee]

Last TWO questions on this I think...I've got the state machine, replies, etc. all setup.

QUESTION 1:

Is there a way to do Indirect write commands? For each field type (Power, Mute, Volume, Source, etc.) I have 20 fields for the upto 20 zones that three Nuvo controllers can occupy. So, for example:

Z01Power
Z02Power
...
Z20Power

I can cut/paste and create 100 writecmds easy enough, but if there is a way to do it indirectly by passing the zone #, then that would be better. And, if there is not, is there any overhead/processing problem with declaring 100 writecmds in a PDL driver?

QUESTION2:

I ran into a problem with the send/reply pairs. I had created four different reply types depending on the info that came back in order to extract the right information from the right position within the string. What I neglected to think ahead on, was how to do pairs with this. For example, if I poll GetStatus, the reply could be one of four different strings, not just one set string. How do you reconcile that a particular message can get one of four valid responses? I thought about creating four identical GetStatus(1to4), but given that each one could still get four different responses, that didn't seem to help.

[Dean Roddey]

For #1, that's covered in the driver development guide. If you look at the section on msg matching and state machine, it discusses indirect stores there.

For #2, that might be a fatal problem. It assumes that a particular query returns a particular response.

It's starting to sound like it might be best to punt and go with CML.

[robertmee]

For #1, that's covered in the driver development guide. If you look at the section on msg matching and state machine, it discusses indirect stores there.

For #2, that might be a fatal problem. It assumes that a particular query returns a particular response.

It's starting to sound like it might be best to punt and go with CML.

#1....Yes, I use them for that. But I'm talking about for the writecmd, as that particular block seems to insist on a Fieldname.

#2....That's what I was afraid of. It's a shame, because the PDL driver is finished and looks straightforward for that one caveat. Here's the code for the different types of replies. As you see, it's the exact same except that the offsets change to find the values in the string, depending on whether the zone is on or off, or if it is a Slave or regular zone.


Replies=

Reply=ZoneStatusPowerOnReply
Store=
ZonePowerFld =CatStr("Z",ExtractStr(&Reply,2,2), "Power");
ZoneSourceFld =CatStr("Z",ExtractStr(&Reply,2,2), "Source");
ZoneVolumeFld =CatStr("Z",ExtractStr(&Reply,2,2), "Volume");
ZoneMuteFld =CatStr("Z",ExtractStr(&Reply,2,2), "Mute");

*ZonePowerFld =Equals(Extract(&Reply,Card1,8),$ASCIIn);
*ZoneSourceFld =Extract(&Reply, Card1, 12);
*ZoneVolumeFld =ExtractASCIIInt(&Reply, 17, 3, 10);
*ZoneMuteFld =Equals(ExtractStr(&Reply, 20, 2), $MuteMT);
EndStore;
EndReply;

Reply=ZoneStatusPowerOffReply
Store=
ZonePowerFld =CatStr("Z",ExtractStr(&Reply,2,2), "Power");
ZoneSourceFld =CatStr("Z",ExtractStr(&Reply,2,2), "Source");
ZoneVolumeFld =CatStr("Z",ExtractStr(&Reply,2,2), "Volume");
ZoneMuteFld =CatStr("Z",ExtractStr(&Reply,2,2), "Mute");

*ZonePowerFld =Equals(Extract(&Reply, Card1, 8), $ASCIIn);
*ZoneSourceFld =Extract(&Reply, Card1, 13);
*ZoneVolumeFld =ExtractASCIIInt(&Reply, 18, 3, 10);
*ZoneMuteFld =Equals(ExtractStr(&Reply, 21, 2), $MuteMT);
EndStore;
EndReply;

Reply=ZoneStatusPowerOnSlaveReply
Store=
ZonePowerFld =CatStr("Z",ExtractStr(&Reply,2,2), "Power");
ZoneSourceFld =CatStr("Z",ExtractStr(&Reply,2,2), "Source");
ZoneVolumeFld =CatStr("Z",ExtractStr(&Reply,2,2), "Volume");
ZoneMuteFld =CatStr("Z",ExtractStr(&Reply,2,2), "Mute");

*ZonePowerFld =Equals(Extract(&Reply, Card1, 17), $ASCIIn);
*ZoneSourceFld =Extract(&Reply, Card1, 21);
*ZoneVolumeFld =ExtractASCIIInt(&Reply, 26, 3, 10);
*ZoneMuteFld =Equals(ExtractStr(&Reply, 29, 2), $MuteMT);
EndStore;
EndReply;

Reply=ZoneStatusPowerOffSlaveReply
Store=
ZonePowerFld =CatStr("Z",ExtractStr(&Reply,2,2), "Power");
ZoneSourceFld =CatStr("Z",ExtractStr(&Reply,2,2), "Source");
ZoneVolumeFld =CatStr("Z",ExtractStr(&Reply,2,2), "Volume");
ZoneMuteFld =CatStr("Z",ExtractStr(&Reply,2,2), "Mute");

*ZonePowerFld =Equals(Extract(&Reply, Card1, 17), $ASCIIn);
*ZoneSourceFld =Extract(&Reply, Card1, 22);
*ZoneVolumeFld =ExtractASCIIInt(&Reply, 27, 3, 10);
*ZoneMuteFld =Equals(ExtractStr(&Reply, 30, 2), $MuteMT);
EndStore;
EndReply;


All I would need is a way to intelligently determine the offsets and stick them into variables. But how to do that within the limited framework of PDL escapes me. Guess it's back to ye ol CML :-(

[Brightan]

thank you to Robertmee for creating the Nuvo driver, my house is sounding good! I do have a quick question. about 10-25% of the time, when adjusting the volume, all the Nuvo widgets disappear for about 5-10 seconds. This doesn't seem to happen when using any of the other widgets for selecting source, muting, power etc. I was wondering if anybody has run into this or whether it might be a problem with my setup. (Added)Looking at the driver state, when the widgets disappear, the driver state shows "Wait for comm resource" and the "Lost Comm Res" gets incremented
Also, one dumb question, how do I reverse the value going out because the driver wants 0 (loudest) to 73 (quietest) and the up/down slider is highest value at the top.
I am using the Nuvo driver from the 2.0 release
Thanks,
Steve

[robertmee]

thank you to Robertmee for creating the Nuvo driver, my house is sounding good! I do have a quick question. about 10-25% of the time, when adjusting the volume, all the Nuvo widgets disappear for about 5-10 seconds. This doesn't seem to happen when using any of the other widgets for selecting source, muting, power etc. I was wondering if anybody has run into this or whether it might be a problem with my setup. (Added)Looking at the driver state, when the widgets disappear, the driver state shows "Wait for comm resource" and the "Lost Comm Res" gets incremented
Also, one dumb question, how do I reverse the value going out because the driver wants 0 (loudest) to 73 (quietest) and the up/down slider is highest value at the top.
I am using the Nuvo driver from the 2.0 release
Thanks,
Steve

Are you using the OnRelease Action of the slider? You don't want to be sending repeated volume changes while sliding as the driver simply can't keep up.

[Brightan]

Are you using the OnRelease Action of the slider? You don't want to be sending repeated volume changes while sliding as the driver simply can't keep up.

nope, I don't have any actions set.
S

[Dean Roddey]

It sounds like the driver or device isn't happy with the volume value written or something, and it's knocking the driver offline.

[robertmee]

It sounds like the driver or device isn't happy with the volume value written or something, and it's knocking the driver offline.

Could be, however, the field is limited to the acceptable range and it works for me seemingly all the time (or at least I haven't experienced the behavior noted). The field is an integer, range 0 to 73...Is it possible for the slider to throw some value in there outside the field's range?

[Dean Roddey]

That wouldn't happen, no. Are there any volume range differences based on firmware version or something?

[robertmee]

That wouldn't happen, no. Are there any volume range differences based on firmware version or something?

Never say never, but not that I'm aware of....I'm getting my multiport serial card setup (I've been shuffling between ports testing various equipments and tired of it). Once I do, i'll take a closer look to see if something is causing it and if I can replicate it.

[Dean Roddey]

You can always get him to set up the remote port server and see what's happening directly.

[Brightan]

the error occurs no matter what value I am sending... I can change it back and forth between two middle of the road values and the error will happen. If this is only occuring for me than I will dig into the diagnostics and see if I can pin-point the issue, I just wanted to make sure this wasn't a known issue before proceeding.
S

[robertmee]

The good news is I'm able to replicate the behavior...Never saw it before because I rarely used the slider. Bad news, right now I have no rhyme or reason as to why. I'll have to dig into it further.

[Brightan]

what do you use instead of the slider? Sorry I found a bug, let me know what I can do to help fix it.

I captured the data running back and forth and found that normally the system sends and receives the following data (I know you are familiar with this but I am posting it for completeness)

*Z01STATUS<CR>
#Z01PWRON, SRC4, VOL-38<CR>

and repeats for zones 1-8
When the error occurs it always ends off with zone 8
*Z08STATUS<CR>
#Z08PWRON, SRC1, VOL-60<CR>

and after the delay, when the driver comes back, it starts off with
*VER<CR>
#MPU-I8_FWv1.71_HWv00<CR>

which is what the driver does when first starting (right?). I don't know if this is relevant or not but maybe it means something to you :-D

[robertmee]

Well, it's very helpful that you have a serial capture ability....I don't and always have to use the CML test harness which sometimes makes it difficult to trap a sporadic error such as this.

(oh, for volume, I've been using Inc/Dec, but I have found now that I can also sometimes get the same error result if I quickly Inc/Dec many times in a row).

Would it be possible to post a capture of everything (use the code/ /code to condense it with scroll bars) starting from slightly before you make a volume change to where you see the reconnect (the prompting for the version)?

[Dean Roddey]

The fast sequence of Inc/Dec operations is a pretty common way to knock a driver offline. The device gets backed up because of the rapid sequence of incoming commands and sometimes either doesn't respond to responds slowly enough that the driver times out.

It's seldom worth even using the Inc/Dec buttons on most devices, because they are either too slow to cope or because of problems like this. It's find to have standard command buttons that do maybe 3 notches up/down to use as rough up/down adjustments, since you have to press them for each up/down and that limits the speed that they can be sent out.

But the volume knob, as long as there's no OnDrag action trying to write out values, shouldn't be a problem.

[robertmee]

HMMM......

I see now why I think I never saw the error before. Let me ask you, do you have a source that is sending radio info automatically to the keypad...From say a T2 tuner? When I tested the driver before, I did not yet have the tuner. I'm seeing something funky and want to see if that's a common thread between our systems.

Update: I did find a problem with an undocumented asynchronous message that was throwing the disconnect. When a source that uses NuvoNet (like the T2 Tuner) sends info globally to all keypads like when a song changes on a radio station, the Nuvo sends a #S2STR"This radio station, this song" message. I didn't expect to receive this, so I was trying to write the "2S" as a card value which threw an exception. So, I put a trap around that to stop that nonsense. I also discovered that I had errored in ranging the volume from 0 to 73 instead of 0 to 78. So, if you ever manually put a zone into a low volume of 74 or above it would also throw the driver for a loop.

I fixed these two problems and the driver doesn't seem to go offline anymore. Instead of 10% of the time with the slider, I've seen twice in a hundred or so tries. Still not acceptable so before I release the update to Dean, I'm going to look at it more, but tomorrow.

Dean....Question for you. The slider control doesn't let you set a scale, right? So in the case of the Nuvo which operates off of -dB for volume (the internal vc control is 0 to -78 with 0 being the loudest) there's no way to compensate. In the existing driver that you have, I changed the scale to 0 to 78 to get rid of the negative sign as I didn't want to see that in the UIs, but as Brightan noted, it causes the slider to work in reverse (up is the lowest volume, down is the highest). Should I rescale the volume internal to the driver to give something like 0 to -78 = 100% to 0% to make sliders make sense?

[Brightan]

Would it be possible to post a capture of everything (use the code/ /code to condense it with scroll bars) starting from slightly before you make a volume change to where you see the reconnect (the prompting for the version)?
I downloaded a monitor program that doesn't allow me to datalog unless I purchase it so I can't post anything right now. Here are a few more things I've noticed
- I can tell you that your driver polls for all 8 zone status' and then sends the volume command after that. When the volume command fails, it is not being sent by the driver out the serial port, something goes wrong before that point.
- I just noticed that there is an extra character in the volume command when it does go out correctly, it looks like this *Z01VOL52o<cr> with the letter 'o' appearing after the volume value. I am not fluent in CQC but looking at the following code in zone volume method
m_SendBuf.ImportStringAt(Val, 3, Count);
Count := Count + 3;
is the last line supposed to be +2? Is the 3 within (Val, 3, Count) also supposed to be 2?
- I am not running any other equipment, such as a tuner so there is no other information on the system
- The error can occur even when the slider is moved once, it is not occuring due to too many commands in rapid fire.
- If you do try and click on a widget while the error is occuring, you get a popup CQC error that says "Driver 'Nuvo' is not currently connected to it's device"
S

[bph]

I downloaded a monitor program that doesn't allow me to datalog unless I purchase it so I can't post anything right now. Here are a few more things I've noticed
- I can tell you that your driver polls for all 8 zone status' and then sends the volume command after that. When the volume command fails, it is not being sent by the driver out the serial port, something goes wrong before that point.
- I just noticed that there is an extra character in the volume command when it does go out correctly, it looks like this *Z01VOL52o<cr> with the letter 'o' appearing after the volume value. I am not fluent in CQC but looking at the following code in zone volume method
m_SendBuf.ImportStringAt(Val, 3, Count);
Count := Count + 3;
is the last line supposed to be +2? Is the 3 within (Val, 3, Count) also supposed to be 2?
- I am not running any other equipment, such as a tuner so there is no other information on the system
- The error can occur even when the slider is moved once, it is not occuring due to too many commands in rapid fire.
- If you do try and click on a widget while the error is occuring, you get a popup CQC error that says "Driver 'Nuvo' is not currently connected to it's device"
S

Just a thought.... you could always use the free one from Sysinternals (now a part of Microsoft): http://www.microsoft.com/technet/sysinternals/utilities/portmon.mspx

[robertmee]

- I can tell you that your driver polls for all 8 zone status' and then sends the volume command after that. When the volume command fails, it is not being sent by the driver out the serial port, something goes wrong before that point.

That's normal. The polling is an incremental loop and CQC sets an internal flag on any field value change that is processed after the polling method completes.

- I just noticed that there is an extra character in the volume command when it does go out correctly, it looks like this *Z01VOL52o<cr> with the letter 'o' appearing after the volume value. I am not fluent in CQC but looking at the following code in zone volume method
m_SendBuf.ImportStringAt(Val, 3, Count);
Count := Count + 3;
is the last line supposed to be +2? Is the 3 within (Val, 3, Count) also supposed to be 2?


Yeah, it's supposed to be...Good catch. That was left over from early creation when I thought the volume command had to be like the status received which has a '-' sign in it. The protocol is weird in that it takes a positive volume value but returns a negative volume value as its response.


- I am not running any other equipment, such as a tuner so there is no other information on the system

No matter...There was an undocumented response due to a Tuner or other NuvoNet aware device on the line so it's good I found it anyway. Could have caused others problems down the road.


- The error can occur even when the slider is moved once, it is not occuring due to too many commands in rapid fire.

Right, I had seen that.


- If you do try and click on a widget while the error is occuring, you get a popup CQC error that says "Driver 'Nuvo' is not currently connected to it's device"

Again, normal. When the driver loses communication and resets, all fields go in error, so any attempt to write to them throws the error you see. That's true for all CQC drivers.


Thanks for the efforts. The endeavor has been a good one because I uncovered two latent potential problems that could have caused errors down the road for others due to adding the T2 tuner which I didn't have at the time when the driver was first released. That's the frustrating thing about these serial protocols. Of the two I've done so far, I'd estimate 25% of the stuff is either undocumented or documented incorrectly and it takes a brute force approach to uncover them.

[robertmee]

Just a thought.... you could always use the free one from Sysinternals (now a part of Microsoft): http://www.microsoft.com/technet/sysinternals/utilities/portmon.mspx

Cool! Where's that been all my life. Very helpful.

[robertmee]

Okay,

I've made some changes, most notably:

Additional error checking around some undocumented/unexpected responses that could throw an exception and cause the driver to go offline.

Changed the 3 to 2 on the Volume create message. Didn't appear to cause a problem, but better safe than sorry.

Reversed the polarity of the Volume values. That makes a vertical/horizontal slider operate the correct direction. You'll be forced to use negative numbers for the valid range in order to make the appearance make sense (-78 to 0, softest to loudest).

Expanded the range from 73 to 78.

The attached driver will show up as Nuvo Concerto 2 in your list until I make an official drop to Dean. Give it a whirl and report the results. I've done about 200 consecutive slider changes with no dropouts.

While you're playing around with that, I'm going to try to get a Command field added. Sparks had requested an AllOn and AllOff command so I'm going to work on that.

Robert

[robertmee]

There is no ALLON command available, so here's an update with the ALLOFF command added. I made it an enumerated field so in case some other system wide command is thought of it can easily be added.

[Brightan]

I have to expose my newbie-ness and ask how to install the test driver. I opened the Admin interface and Import Package under the Administer menu, is that correct? I get a "An error occured while trying to parse the package"... "2 is not a valid format version in a 'TCQCPackage' object" on line "CQCKit_Package.cpp/1119" :-?

[robertmee]

I have to expose my newbie-ness and ask how to install the test driver. I opened the Admin interface and Import Package under the Administer menu, is that correct? I get a "An error occured while trying to parse the package"... "2 is not a valid format version in a 'TCQCPackage' object" on line "CQCKit_Package.cpp/1119" :-?

Yes, that's correct. Are you on version 2.0.2?

[Brightan]

Yes, that's correct. Are you on version 2.0.2?
I am now! (BTW, is there some trick to quickly unlock the install directory when the installer complains it's locked?)
testing... yah! 4000 clicks later and no errors!
Good job!
S

[Dean Roddey]

I'm sure it was the +3 instead of +2 because that's going to send an random extra byte, which (since it's beyond the terminator) will sit there. If you send another message quicker than the device times out and discards a partial message, then that extra byte will be the first byte of the next message. If you don't send quickly, most devices will timeout and throw away that partial buffer and the next message will work fine.

If the installer directory is locked it's because some CQC program is running, or some program/command prompt has a current directory inside the CQC directory. It's always best to stop any programs while doing an upgrade, and definitely stop any CQC programs.

[Dean Roddey]

So if this makes it happy, we should get this update into the upcoming release.

[robertmee]

I'm sure it was the +3 instead of +2 because that's going to send an random extra byte, which (since it's beyond the terminator) will sit there. If you send another message quicker than the device times out and discards a partial message, then that extra byte will be the first byte of the next message. If you don't send quickly, most devices will timeout and throw away that partial buffer and the next message will work fine.



Possible, however in this case, I don't think true. For two reasons. One, if the byte was after the terminator and was in front of the next message, the Nuvo would (or I should say 'should') toss it away as it looks for a particular STX before it considers a valid message coming. That erroneous byte would be ahead of the STX marker. Also, in this case, the extra byte was still in front of the terminator, not behind as I append the ETX (/CR) last. If anything, the unknown byte should have caused a failure in the volume write with a NAK and the bad message counter would have incremented, not the driver throwing an exception in code that caused it to drop and re-establish com resources. Even if I didn't get the NAK because the Nuvo didn't know what to do, I would throw a timeout which was also not happening. Sooo, I'm pretty sure that it was the improper decoding of a message thinking it had a number in it when in fact it had a character. When I tried to convert this to a Card it threw an error.

All in all, whatever it was, I'm glad it's not there now :-). When will your next drop be. I'll need to update the html doc as I added the command field for an All Off command.

[Dean Roddey]

That erroneous byte would be ahead of the STX marker.

But what if the byte was, in some cases, an STX? The byte that would be there would depend on a number of things but it could be quite repeatable on one system and almost never happen on another, and could change from restart to restart as well, or depend on the drivers loaded and so forth.

[robertmee]

But what if the byte was, in some cases, an STX? The byte that would be there would depend on a number of things but it could be quite repeatable on one system and almost never happen on another, and could change from restart to restart as well, or depend on the drivers loaded and so forth.

Dunno what would happen with a message that started with two STXs...But since the erroneous byte was before the ETX, I don't think it ever was the beginning of the next message. The message was formated such as Z01VOL50o/r (where o is the unknown byte) instead of Z01VOL50/r, so the ETX was still always at the end. Worse case the Nuvo should have responded with ? as an unknown command which is handled as a bad write, not thrown an exception.

[Brightan]

after a couple more days of playing everything is good, but, I do have another questions... I've noticed that it is easy to swamp the driver with more than a couple of commands, so, is it appropriate to use something like WaitDriverReady? Right now I've added 100mS delays between commands and it appears to be ok but I would like to know the best way of handling this.
Thanks,
S

[robertmee]

after a couple more days of playing everything is good, but, I do have another questions... I've noticed that it is easy to swamp the driver with more than a couple of commands, so, is it appropriate to use something like WaitDriverReady? Right now I've added 100mS delays between commands and it appears to be ok but I would like to know the best way of handling this.
Thanks,
S

What symptoms are you seeing when you say 'swamped'?

[Brightan]

What symptoms are you seeing when you say 'swamped'?

It is the same error as before where the driver disconnects and displays an error that the command failed.
I was just playing around with it some more and have narrowed it down to the power command. It would appear that you can send a number of volume or mute commands back to back without issue but as soon as you send two or more power commands without the delay the error pops up. It appears to be more sensitive when using the event server but that might be an anomaly. Another weird thing is that it seems more prone to happen when turning power on then off, maybe also an anomaly of testing.
You can send power/source/volume commands in a row to a zone and then repeat that for a second zone without delay and seemingly without error. If this is a Nuvo limitation then it is easily worked around with a delay or careful placement of commands.
One question I have is the fact that you have to turn the power on before selecting the source or the volume. Is this a limitation within the Nuvo device itself?

[Dean Roddey]

Its not uncommon for devices to go stupid for a while after a power on. It may just be something that the driver can handle, by doing an imposed 250ms second delay after a power on or something like that.

[robertmee]

It is the same error as before where the driver disconnects and displays an error that the command failed.
I was just playing around with it some more and have narrowed it down to the power command. It would appear that you can send a number of volume or mute commands back to back without issue but as soon as you send two or more power commands without the delay the error pops up. It appears to be more sensitive when using the event server but that might be an anomaly. Another weird thing is that it seems more prone to happen when turning power on then off, maybe also an anomaly of testing.
You can send power/source/volume commands in a row to a zone and then repeat that for a second zone without delay and seemingly without error. If this is a Nuvo limitation then it is easily worked around with a delay or careful placement of commands.
One question I have is the fact that you have to turn the power on before selecting the source or the volume. Is this a limitation within the Nuvo device itself?

The Nuvo probably requires some wake up time on power up before accepting another command. As for setting source, volume, yes the zone must be powered on before you can change any fields for that zone. It mimics the operation of a keypad as you can't do anything at a keypad either unless the zone is powered on.

I know where you're coming from in regards to event usage. It would be nice to set the source and volume prior to powering up as when using a zone for an alarm clock feature. Unfortunately as you see from the configurator software, each zone either powers up to a preset volume or its last known volume and I don't believe there's any way to change that while the zone is off. I can try to confirm with Nuvo Engineering if there is some workaround trick. They still owe me a firmware upgrade anyway to change the Slave Keypad display problem.

Dean,

Can you point me to an example of this imposed delay or attach a code snippet.

[Brightan]

The Nuvo probably requires some wake up time on power up before accepting another command.
<snip>
It would be nice to set the source and volume prior to powering


I was thinking the same thing as you and Dean regarding the device not responding while powering up so I took a look at the serial data and it appears to be responding to a power up command immediately...hey, what's this? (I'm testing and writing at the same time) After the second power command goes out, Nuvo responds with #Busy<CR> I don't find that in the protocol manual, do you? :shock:

As far as setting the volume after power up, there appears to be enough delay that you can set the source and volume after a power up without getting any sound before the new settings take place. (I woke to softly playing jazz this morning)

[Dean Roddey]

If it returns a Busy, then that's what you need. After sending out a Power command, turn around and try to query it, in a loop where'll wait up to a couple seconds and pause for 200ms between or some such thing. Once it stops returning the busy signal, then break out.

Or, if the required delay is very consistent and small, just do something like Sleep(500) after sending out a power on command. A short pause like that won't hurt anything, but it'll hold anyone else off while the zone is powering on.

[Brightan]

I don't know if Robert has more information on the protocol than the document that I have (which says nothing about the busy command) so he may have more insight into this but it would appear that the Nuvo sends the busy response and then doesn't accept anything until it is ready and then issues the response from the last command.

[Dean Roddey]

Actually, I guess the best thing to do is not to wait after sending the power, but just update the driver such that any time you get a busy signal when sending out a message, that you'll back off and try again a few times until it becomes unbusy. This would be more efficient since most of the time the issue won't come up, but if it ever does, whether for power or anything else, you will deal with it gracefully at any time it happens.

[robertmee]

I don't know if Robert has more information on the protocol than the document that I have (which says nothing about the busy command) so he may have more insight into this but it would appear that the Nuvo sends the busy response and then doesn't accept anything until it is ready and then issues the response from the last command.

I have the same document as you, but I have found MANY responses that are not documented through trial and error. I have not seen the #Busy, but I can try to incorporate that response so that the driver doesn't disconnect and handles it appropriately. It will be a week or so before I can attend to it as I'm currently on travel.

[jzh10]

Robertmee, the work that you're doing is truly impressive.
Would the basic features of your driver also work with the Nuvo Essentia? There wouldn't be any metadata display, but would basic power and zone on/off, volume and zone/source switching work?
I have some customers with the Essentia installed, and I'm investigating CQC to see if it's a good option for us.

[robertmee]

Robertmee, the work that you're doing is truly impressive.
Would the basic features of your driver also work with the Nuvo Essentia? There wouldn't be any metadata display, but would basic power and zone on/off, volume and zone/source switching work?
I have some customers with the Essentia installed, and I'm investigating CQC to see if it's a good option for us.

I've taken a look at the Essentia protocol before per another user's request and it is slightly different than the Concerto. However, if someone has a unit and is willing to be the guinea pig, I'll write the driver for the Essentia.

[Dean Roddey]

If it's only slightly different, it would be far better to have a single driver that handles both, using a user prompt to ask for which model.

[robertmee]

If it's only slightly different, it would be far better to have a single driver that handles both, using a user prompt to ask for which model.

I did that with the Maxent models as they were different in that while the protocol was the same format, the one model had an additional input. The Essentia and Concerto are slightly different in that while they share many of the same fields, the protocol messages are completely different, so I think it would be better served to create a different driver. I guess 'slightly' is in the eye of the beholder ;-)

[jzh10]

In that case, I may end up being your beta pig. Either that or encourage them to upgrade...I'll let you know.

[sic0048]

I downloaded the new Concerto installation manual and at the end it references an addendum that is suppose to give the Concerto RS232 protocal. The last 3 or 4 pages of the manual are blank, so I e-mail Nuvo asking them to provide me with the protocal.

Here is the response I got:

Hello Brian,

I have passed your request to our Senior firmware and software engineer. He
is overseeing the production of this document. It will be published when the
document is completed. It will be on the Website, but not in the manual. The
instance of upgrade to the document will be relatively high with the Grand
Concerto and its Suite products. The best way to stay current is on the
Website.

Thanks,

Steve Horton
Director of Education

[Bauer83]

I've taken a look at the Essentia protocol before per another user's request and it is slightly different than the Concerto. However, if someone has a unit and is willing to be the guinea pig, I'll write the driver for the Essentia.

There is a good chance I will have a unit in about two weeks. So I would really appreciate it if you could assist me in writing the driver, or even better, I could just be a guinea pig for you. Let me know if you are still able to write this driver, as it would be great for my new place.

[robertmee]

There is a good chance I will have a unit in about two weeks. So I would really appreciate it if you could assist me in writing the driver, or even better, I could just be a guinea pig for you. Let me know if you are still able to write this driver, as it would be great for my new place.

I should be able to get you something working...My time will be somewhat limited as I have a huge startup I'm gearing up for, but I write these to relax so I'm sure I can fit it in somewhere.

[Bauer83]

I should be able to get you something working...My time will be somewhat limited as I have a huge startup I'm gearing up for, but I write these to relax so I'm sure I can fit it in somewhere.

Unfortunately I missed out on the auction. In the last ten minutes it went from 600 bucks, to 1200. I thought I was safe putting in a bid of 1000, with 35 seconds left, but could not raise the bid quick enough to win the auction. Crappy luck.

[monetteboy]

Hello!

I have just got started with CQC and have an Essentia system. If you have developed a driver or plan on doing one I would be willing to test it as I really do need it.

If there is anything I can do to help please let me know!

Thanks!

[robertmee]

Hello!

I have just got started with CQC and have an Essentia system. If you have developed a driver or plan on doing one I would be willing to test it as I really do need it.

If there is anything I can do to help please let me know!

Thanks!

I'll try to take a look this weekend. Have you got the essentia set up and connected already to a PC with a serial cable and tested by sending it commands with Hyperterminal?

[robertmee]

Okay,

I have a Beta for the Essentia ready. As soon as I hear from Monetteboy I'll forward to him for testing. Any other guinea's ready?