device firmware upgrading
JohnMichnr
Posts: 279
in AMX Hardware
OK - another in a long series of potentially stupid questions but...
I'm of the believe that if it ain't broke don't fix it when it comes to firmware. But I have gotten in teh habit of upgrading master firmware when I begin a new project, or when I go back for major revisions in an old project.
But I have not gotten in the habit of upgrading the device firmware (NIxxx). I just always leave it unless there is a problem that needs the upgrade.
What does evereybody else do? Automatically upgrade the device firmware with the master firmware or leave well enough alone?
I'm of the believe that if it ain't broke don't fix it when it comes to firmware. But I have gotten in teh habit of upgrading master firmware when I begin a new project, or when I go back for major revisions in an old project.
But I have not gotten in the habit of upgrading the device firmware (NIxxx). I just always leave it unless there is a problem that needs the upgrade.
What does evereybody else do? Automatically upgrade the device firmware with the master firmware or leave well enough alone?
0
Comments
That said, you should probably upgrade anyway.
I'm moderately proactive with master firmware versions, but in reality my device firmware tends to lag a bit. After discovering how to brick the device firmware while upgrading (see this thread: http://www.amxforums.com/showthread.php?t=6326) I am going to deliberately roll out the latest version of both master and device when I am able to, probably in the new year. Leaving such a "time bomb" legacy issue for some unsuspecting AXM programmer after me to discover (once warranties have expired) is just asking for trouble. Yes, I like to protect the good name of AMX!
Having said all that, I don't update immediately when a new version is released, since there may also be unforeseen issues with the new release. I test the new firmware on a dev/test master, and wait around 6 week to see how the community feels about it before mass-deployment.
Roger McLean
Swinburne University
Ditto here. AMX employs people to continually improve, debug and optimize their product firmware for a reason. IMHO not updating firmware is along the lines of working on some AMX code, uploading an initial version for testing, then continuing to work on the code but not transferring it to the master when you made any changes.
Using the same logic though, if you were making some improvements to code that formed a critical part of a system you wouldn't just dump the code and run, you would make sure it was fully tested. The same thing goes for firmware. If you're lucky enough to be running standardised systems (such as a Roger's uni environment, or us with the courts) then it's a little easier to thoroughly testbench new firmware before rolling it out to operational systems.
After all, if everyone followed the 'if it isn't broken, don't fix it' paradigm chances are we'd still be living in caves, communicating with basic grunts.
Given the two outcomes, IMHO, there is no upside to fixing a functional system as the risk/reward ratio is against you. Basically, the only reward I can see is renewed contact with your client, but at the possible price of demonstrating to the client that renewed contact with you breaks the system
I do apply firmware upgrades when I am upgrading modules or code, or if there is anything weird occurring like unexplained processor lockups and the such, but I have been burned before with unnecessary upgrades biting me in the butt.
Jeff
Well I do live in Minnesota - some would say that is an apt comparison. (A not so subtle reference to the Bi-coastal folks that still consider this Flyover territory)
This suddenly came up for me in a negative way. I have been doing an upgrade to systems that were originally installed three to four years ago, programmed by a different programmer for a different company. around 20 rooms or so. I upgraded them in 2008 for RMS, and then this year I upgraded them again to change the codec dialing and bring the directory out to the touchpanel. During this process I've been upgrading master firmware as I load the new program in. I get a call from the customer a couple of weeks ago that he is getting RMS errors that the ClearOne is not responding and the mute and audo conference funtions don't work. This happenes only for 8-10 rooms. So I ask - what changed? Hummm.
I go onsite to find that this is an error in hardware handshacking and the cableing between the NI and the ClearOne. All of the rooms with the problem had Hardware handshacking turned on - Well that explains it.
BUT - I went back over three years of programs and HS has been set ON in all the programs that I received from the original contractor. I know this problem has not been happening for three years. I check the NI device firmware and in the rooms without the issue it is 1.12something. In the rooms with the issue it is 1.13something. (neither is really current) So somebody fixed something in some firmware sometime that caused the original programming error to suddenly appear. I just can't figure out how this happened as it has been a month since I was last down there.
So I started wondering if I need to upgrade device firmware at the same time I upgrade my master firmware and just make a policy of that. I still would have had this problem, but I would have found it 3 months ago, not now.
I still do it myself... I would say I remind myself why I don't do it by doing it at least once a year
Reminds me of an electrician that was having problems with one outdoor circuit (that the automation system was controlling using a simple relay). Whenever the system closed the relay, the breaker would pop. The electrician first tried to blame it on the automation system, so I disconnected our wires and closed the relay manually by pushing the rocker.... surprise, surprise, it popped the breaker. The electrician then said it was something I was doing (mind you, he was in the room watching me), and he tried it. POP! (Oh, he kept resetting the breaker after each pop, but did not change anything on the load side. Still insistent that it was the relay, he turned off the breaker and wire nutted the feed and load together. He tried to turn on the breaker, but it popped instantly. This next step REALLY amused/concerned me. The next step was to try and force the break to stay on by holding it on with his finger which resulted in a loud buzzing sound coming from the breaker panel. I would say it took him a good 5 seconds to realize this was a battle he would not win. After staring blankly at the panel for a minute or two, I finally asked if there were any junction boxes outside were an animal may have cause a short. He decided that as crazy as it sounded, maybe there could be a problem outside. Upon opening the outdoor junction box (which was in the ground) it was obvious that the 5 inches of water in the box was the cause of the problem
Sorry for the long story, but I was thinking about insanity and attempting the same procedure with the variables all the same over and over expecting a different outcome
Jeff
You know what is scary about that - other than the obvious - one of the first projects I work on as a brand new AV installer had a light for an in ceiling camera controlled via a realy. We provided the relay and the control to drive it, everytime we hit the switch nothing happened. (we couldn't hear the breaker - it was in another room) Took me a couple of hours working through stuff to realize that the electirican had wired the hot and nuetral accross the realy with nothing going to the light.
When I showed it to him he couldn't understand why that wouldn't work.
This guy was a journeyman electrician who was in charge of the entire floor. I thought for sure the building was going to burn down.