• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About lambroffs

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Location
    Chesapeake, VA
  1. I have a stack of three I-Tech 8000 amps running firmware 1.301. With no applied signal and no apparent fault conditions, one of the amps shows an exclamation mark right below the "dB" letters on the Attenuation Screen. Cycling power does not clear the "!". I cannot find reference to the symbol in either the User's Manual or the Application Guide. What is this amp trying to tell me? It appears to operate correctly otherwise.
  2. OIF Fault Parameters

    From your last reply: "Object 16385 lists all the possible error strings." How do I call object 16385? I tried issuing an IdGetState request and referenced HEX [40][01]. I received the following error: "error: bogus object id in description: 16385". I am running firmware v1.301 in an ITech8000. I also get the same "error: bogus object id in description: 16272" when I query the Component Online status and "error: bogus id in description: 16312" when I query the IQ Address. These last two are listed in the OIF file, while the error string object is not. Any help is appreciated. If easier, it would be a huge help if you could cut-n-paste the error string dump to this forum. Thanks.
  3. OIF Fault Parameters

    I was not critiquing your UDP-IQ Protocol Document. I have had no problem using GET and SET on most OIF parameters. I was commenting on the lack of available information on individual OIF parameters. Your documentation tells me how to access the "Proportional VCC Monitor" value, but I have no avenue for deducing what the parameter means. Most of the OIF parameter functions are obvious from the name alone, but others are obscure functions that apparently only those with "inside" information can deduce. That is all I was saying. Sorry for the miscommunication. Scott
  4. OIF Fault Parameters

    Was my post not appropriate for this forum? I am trying to fully utilize the UDP tool kit you freely distribute as it is allowing me to offer my customers some pretty high-level features that they aren't used to expecting from their system. But, while the toolkit hints at the exciting possibilities tucked away in your I-Tech firmware, it doesn't provide enough as a stand-alone document to fully (or even partially) explain some available features. Is there an alternate channel at Crown that I can use to answer my questions? Have I stepped into the realm of fee-for-service engineering support? Thanks. Scott
  5. I am using a Crestron controller to communicate with your amps (formerly MA5002VZ, but looking to switch to I-Tech 8000) using the UDP-IQ tools and OIF parameters. Since I install these amps on US Navy ships, I need to be notified of every fault, large and small, sensed by the amp so that the Crestron controller can automatically switch to a redundant amp and also report an alarm to the duty technicians for investigation. In the past I have used the AUX port to trigger an alarm. Since the I-Tech has done away with the AUX port (although I did find a reference to it in the I-Tech manual paragraph 4.6.13 Error Reporting... which I think is a typo... right?) I need to fish for errors using the UDP-IP protocol. My problem is that the OIF descriptors are not sufficient enough to figure out what I need to be monitoring. I think I need the following: - LINE VOLTAGE MONITOR / REPORT LVM VIA NETWORK - POWER SUPPLY TEMPERATURE MONITOR (Is this part of Thermal Error?) - IOC MONITOR / REPORT IOC ERROR VIA NETWORK - REPORT SUPERVISOR ERROR VIA NETWORK - THERMAL ERROR / REPORT THERMAL ERROR VIA NETWORK Other OIF entries look promising, but I just don't know enough about them to know (i.e. Proportional VCC Monitor, Sharc workload, Power Supply Current). Are there addtitional critical faults that I can access through UDP-IP that I have not listed? Are there other faults tied to the front panel Fault Indicator that I can tap into? Also, the UDP protocol says that application errors are only broadcast to controllers that have sent an idGetState within the past 30 seconds. Can I send ANY idGetState to qualify, or does it have to be a poll of that specific error? In other words, do I have to continuously poll all errors that I want to monitor? Thanks. Scott
  6. USP3 Firmware Crash

    I tried that and got nowhere. It still shows up red in TCPIQ Utility, and it won't complete a firmware upload. IQWiq does not recognize it. Scott
  7. ...and if I'm using shielded CAT-5 for TCP-IQ do I still need to install the core?
  8. New PIP-USP3's are shipping with a clamp-on ferrite core for emission regulations. The enclosed instruction sheet says to place the supplied ferrite core on "the cable" but doesn't identify the cable. The picture shows an RJ-type connector, but it isn't clear whether this is the AUX or NETWORK cable. Can you clarify? Scott Lambroff
  9. I've got one of those "I'm afraid I know the answer, but I've gotta ask anyway" questions... Out of ten PIP-USP3's that I have tried to upload firmware V1.101 using TCPIQ Utility V7.0.0.10, two have given me an error midway through upload ("...error uploading, cannot complete") and aborts. After failed attempts on both PIPs, the Signal/IOC lights are steady green (the other eight successful upgraded amps have red ODEP lights). I have tried to reset the PIP by holding the reset button with power on and also with it off. Its not completely toast, because I can still connect to the unit via TCPIQ Utility (it reads the IP and IQ addresses from memory, but the TCP checkbox column does not light up, and every time I try to reinitialize firmware upgrade it errors-out midway through). Is there any way to salvage this situation short of pulling the PIPs and sending them out to for repair? Any advice on running a smooth firmware upload? I am guilty of having a few other programs running in the background, but I'm on a relatively new laptop with plenty of speed and RAM. Scott Lambroff
  10. We use a Crestron control system to GET and SET various PIP-USP3 parameters by sending HEX strings over TCP-IP formatted in accordance with your protocol spec. While searching Crestron's website, I found a Sept 2000 press release touting a Crestron/Crown partnership that was to replace the tedious HEX string commands with Crestron e-control integration. I can find only a brief mention of e-control in the IQ NETServer page, but no details on how to setup the interface. On the opposite side of the fence, Crestron does not list any Crown modules ("macros") on their site and tech support is limited to their registered dealers only. Did this e-control partnership pan out and where can I find specifics? Scott
  11. Woodhead Connectivity makes a line of ruggedized industrial ethernet products under the RJ-LYNXX brand that use waterproof, locking RJ45's.
  12. We are currently testing our first amp rack since switching to PIP-USP3 modules (from PIP-USP2). In the rack that I am now testing, we have three MA5002's and all are running very hot (~45% thermal capacity) when sitting at idle. The amp at the bottom of the stack is running coolest and the amp at the top is running hottest. The problem appears to be the internal fans not running fast enough. We only measure approx 60VAC across each internal 115VAC-rated fan. Amp thermal levels (as shown on IQ software) heat up dramatically when test tones are applied (using only a minimal 250W load). I am frequently getting the "TDH above limit on channel xx" message in IQ software which I'm assuming is a temperature alarm message, but can find not referene to TDH in the manual or help menu. Back when we used PIP-USP2 installed in MA5002VZ's the internal fans were heard loud and clear whenever power was applied to the amp. Under the PIP-USP3, the fans are either running quieter or slower to the point where you cannot hear them pushing air (although opening the top cover shows that they are turning... although much slower than expected.) Is the fan speed controlled on or off the PIP module? I have upgraded all PIPs to V1.10 firmware. Any insight is appreciated. Scott
  13. Bill, I have sent these commands and waited for some time (a min or so) for a response without receiving any. I am able to get responses from get state commands for anything dealing with controls but fail to get a response from a get state sensor request even after waiting. Perhaps its my command string I am sending the following string from the crestron unit to request a getstate from a level sensor (in this case channel 1 Z average): 4951 00000014 0007 0100 FA64 0000 0003 0001 088A When I send this string I get no response. Also of interest is the fact I will not get any error responses from the amplifier to the crestron if I send an incorrect code/ id object request. I ONLY get a response from the amplifier for a getstate control request. Scott
  14. I have exhausted all known variations of the idGetState command to retrieve LevelSensor values from three different USP3's installed in three MA5002VZ's running firmware "Feb 10, 2004". Have you gotten any feedback from engineering or been able to test the problem on a local machine? Scott
  15. I have a strange addendum to my problem: When I issue an idGetState command with two queries built into one message (Count=2) such as Query Ch1 power state (ID=07D0) Query Ch1 load impedance (ID=088A) The formatted response only contains the power state data (BinaryControl). The load impedance (LevelSensor) data request is apparently ignored.