Niles ICS
jdiaz
Posts: 3
I have a Niles ICS systems wth 2 GXR-2 (12 zones) and I'm using the Module Niles_Gxr2_v1_0_0_dr1_0_0, the poblem that i ve is when i use the systems,i can control zone 1 - 8, zones 9,10,11 and 12 I can't control I check all my pogram and heverithng looks find.
0
Comments
Please call Tech Support and report the problem. Problems with modules need to escalated to engineering. This way everyone can benifit from these issues.
Having said that, the box does not work as advertised when it comes to responses and feedback. For starters, the protocol is just not really designed for external control. There are the usual suspects like play/stop/vol up/down/ etc... However, they are not zone specific. So, for example you don't have a 'zone 2 vol up' command.
The way it works is that you send a command to address a particular zone. Then all commands sent following that pertain to that zone. This includes feeback. Most feedback must be solicited. You get nothing voluntarily.
So, if you're monitoring zone 2 and someone changes the source on zone 5, you won't know that it happened. Same with everything else including volume/mute/etc...
Therefore, the only way to get some kind of accurate set of states is to create a polling loop. The poll cannot happen quickly as the Niles gear gets mad if you bang on it too much. For my 8 zone system, it typically took the poll about 45 seconds to get all the way around. I was polling for current source, current volume, current mute state, and meta data from a Sirius radio and/or AM/FM radio.
If the thing had functioned this way we could have lived with it. However, to add to the frustration, there were feedback issues beyond the normal workings. It seemed that the Niles box would get confused sometimes when you changed from one zone to the next.
So, if you had polled all the data from zone 1 and were moving on to zone two, it would sometimes send some of zone two's data from values from the last zone you were in. So, you might get zone one's volume setting for zone two and etc...
The bottom line is that we tried to get it figured out with Niles engineers on the phone and they couldn't make it work.
The solution seemed to be that we would have to get an RS-232 interface for each zone we wished to control. (in our case 8 zones-8boxes.)
In the real-life situation where we were forced to make this work, we ended up only controlling one zone of Niles from AMX. As long as we stay on the one zone, all seems to work well. I tested 4 zones on a Niles here at the office using 4 RS-232 interfaces. Here again, it worked well enough but burning up 4 rs-232 ports on the AMX side seemed a bit silly since we have other systems that do the same thing for the same price with a lot better perfromance.
So, while I'm not known for my love of AMX modules, I have to come down on thier side on this. I don't think it's a problem with the AMX module. I'd attribute it more to the wierdness of how the Niles box works. (or doesn't as the case may be)
As for the Niles end of it - I've been working with them on this too. My boss has been leaning on them rather heavily in trying to work out the major issues with it (chief of which is it is so dang sluggish, and a close second being the box can only reside in one zone at a time). I'll try to keep everyone up-to-date; I have a note on my desk that the Niles engineer called me, but I've been out sick for a week, and risking a relapse playing catch-up the last few days.
Please do. I won't mention names on this forum, but in the end we couldn't figure out a way to get it work the way we wanted. I suppose, if you think about it, Niles only has to make it work with Niles. And it does that already. Anything beyond that is on the engineer's free time.
I had a working module of my own; it worked as well as the Niles protocol itself did, which is to say when the RS232G box itself didn't drop commands entirely, things did what I expected them do, if slowly. As of the latest Niles firmware update, however, it seems to be broken. It's buffering commands to the extent that things can stack up and keep happening several minutes after the fact after send a lot of commands in sequence. I don't know if the fault lies in the RS232G or my module at this point, just that it worked before and it doesn't now.
So I called my contact at Niles ... he was due a call anyway, since he had assured me weeks ago they had some solutions in testing that looked pretty good. It seems, however, he is no longer employed by Niles, and no one that I spoke to knew who was taking this over for him. I wound up leaving a voice mail with an engineer whose accent was so thick I truly dread trying to work this out over cell phone connections.
I'm probably done with the Nile product too, but I don't have the option to bail on this entirely because of currently in-progress jobs.
cue: Trombone sound...
"Whamp whamp whaaaaaaaa"
Do you have any idea what the last working firmware version was?
I am pretty sure there is a manual firmware option that would allow you to roll back to an earlier version.
Turns out it wasn't the firmware that caused the issue; it was a change I made based on the now-gone programmer that I had implemented earlier but hadn't tried in the field. I think I have it sorted out now ... jury is out on the other issues that were always there though.
I believe the new firmware is in the 1.38 version of Intellifile. I got a BIN file directly from Niles just for the RS-232G. Check what version the firmware updater shows - if it's 2.1.1.1 or better on the RS-232G, you are good to go. If not, contact Kenneth Johnson at Niles (he's going to hate me for this, I'm sure) for the file and instructions to update it yourself.
2.0.20.1 is in 1.38
http://www.nilesaudio.com/docs/software/ICS_Firmware_Rel_log_20081125.pdf
Dave,
please expand more on this. What exactly do you mean?
Which standalone multi-room audio systems (other than custom Autopatch ones) are you referring to?
Elan S12, Matrix (slow but gets the gig done.)
The RS-232G must be assigned a single zone to operate. While it is controlling that zone, it cannot control or get feedback from other zones. You can switch the controlled zone, but you have to give it a few seconds to settle before doing anything.
The commands have no zone parameter. They all work on the "current" zone the RS-232G is controlling. What that comes down to is that if you are controlling your kitchen zone, you can't shoot out a quick command to change sources in the living room; you have to re-assign the box to the new zone, wait 5 seconds, then do whatever control you wanted, then switch back. It's not a completely terrible situation, but it would be nice if the commands had the ability to specify a zone.
I spent a lot of time trying to get the most of the RS232 integration of an GXR2. I ended writing my own code for this in Netlinx and only implemented features as per the particular installation, reducing the dialogue with it at a minimum... Still dissapointing.
Nevertheless, I would have saved a lot of time, frustration and client dissatisfaction if I knew what I eventually found out from Niles suport:
Enjoy!
They are quite keen on the announced official update... And, to be honest, I already spent on this too much time and airtime calling in the USA.
My "inside person" was John Hamilton, apparently the Support Manager, but he did nothing to go out of his way and proably out of the letter of the flight text book...
That's why I suggested getting it from Niles, in case you have a warranty issue. If you have no luck, shoot me your e-mail in a PM and I'll send it to you, but definitely try the correct channels first, just in case. Besides, I've had it for a while, you may want to be sure there is no update to the update.
From the release notes:
o Third-party control systems can be programmed to retrieve the zone status of multiple zones with faster response. The RS-232G now caches all of the GXR2?s source metadata to improve reporting when used with third-party control (AMX, ******** and Home Logic)
o Updated RS232 protocol document reflects new commands
I used to work for Niles during the time that this module was being written. I kicked and screamed when I saw that they didnt even bother to include the alphanumeric search for iPod. They should have realeased the IP protocol (for ICS) and let someone write a proper module for it. Can't believe people are still taking about this. The RS232G is too slow.......they were supposed to release an IM-NET gateway to address this. I have a great deal of sympathy for dealers that have had so many other issues with ICS.....hope they get it ironed out.