New firmware for Moving iMage Technologies IRC closed caption emitter - v260501

[Leo Enticknap]

Available on our website here (scroll to the bottom of the page and click on the downloads tab). It can be installed on earlier QSC and USL-branded units as well as the current MiT-branded incarnation.

For those of you that have emitters that have not been updated for many years, I would encourage you to do so, because a CCR caption reader bought now (e.g. to replace a broken one) might not be able to receive captions from an emitter on an older firmware version. There is document on the page linked above that goes into the version number combinations on that issue, but the bottom line is that an emitter with the current firmware version will work with any reader, regardless of the version it is on.

[Caleb Williams]

Hey, I just realized you're the guy in all the engineering bulletins for the IRC-28C at MIT. Thanks for all your work on the accessibility products!

We recently upgraded all of our IRC-28C units to 231221 and it was quite the task due to most of them having firmware sub version 180222. Incrementally upgrading firmware worked for us without having to factory reset the really old units. Do you anticipate any issues upgrading straight from 231221 to 260501?

[Leo Enticknap]

Jumping from pre-QSC, USL era versions straight to an MiT era version sometimes works, but sometimes it doesn't and you have to give 'em a poke. I'm a bit embarrassed to admit that we haven't been able to figure out precisely why! I've updated around 20 units from 231221 to 260501. Most were completely straightforward. The only ones that weren't were because I updated to the full duplex variant of 260501, and then discovered that the switch wouldn't auto detect the change of mode.

There are two changes between those versions: the addition of full duplex capability (which will likely fix dropped captions if the management LAN has a lot of traffic on it, including multicast network video and/or audio), and fixing a bug whereby if a CPL contains more than two language caption streams, the caption processing side of the emitter could crash. I'm not aware of any Hollywood studio having released a DCP with three or more CCAP languages in a single CPL, but at least one overseas distributor is now doing so, which was what brought the bug to our attention.

As for me being "the guy," my role in all of this is limited to end user support, which has included overhauling the documentation and resources on the website. The inventor of this unit at USL and the author of all its firmware versions since then works with us as a consultant to keep that firmware up to date and address issues as and when needed. There are some minor hardware differences between the units that ship now and the USL and QSC era IRC-28Cs (the most important one being that we ship them with a different 32V power supply brick, which we hope will last longer than the 5-7 years that is typical of the power supplies shipped with USL and QSC-era units) , but none that affect functionality. The firmware versions that we release can be installed on any IRC-28C, regardless of whether it was made by USL (before 2017), QSC (2017-22) or MiT (since 2022). But as you found out, if you're starting from a very old version, you may have to nuke the unit to factory defaults in order to be able to update it.

[Steve Guttag]

I have not had issues updating firmware on the various units. I have not installed anything past 121223 yet, but that is coming. It is not uncommon to have to need to purge your browser's cache images to get the various bits to update in your browser, but that shouldn't affect the caption/audio use.

On the power supply, QSC was using a newer/better version of the 32V supply than USL was (USL might have switched at the very end, I don't recall). They still didn't last forever. There is a 2A version of the supply that seems to do okay. Is that what you all have switched to or is it something different?

[Harold Hallikainen]

You SHOULD be able to update from any firmware version to any firmware version since the entire application are of flash is rewritten. However, some early versions had an option to reboot on lease terminate. If this was enabled when you did a firmware update, the update would fail since the system would reboot in the middle of the update. Disabling that feature SHOULD allow the update to proceed. Also, the update process goes like this:

1. The Intel hex file is received by the web server and parsed to a stream of bytes that are stored in external flash.

2. On successful reception of the entire hex file (the checksum on every line passed, and we received the end of file record), the application code calls a function in boot flash that erases the internal application flash and copies the stream of bytes in external flash to the internal flash, then reboots the system.

Because the system uses the application for updates, it's not possible to try again should the system get bricked (which it should not since we checked every line of the hex file, but someone might load code for another product, which WOULD brick the system). To avoid bricking the system, a copy of the factory firmware is also saved to external flash. Holding down the restore button during power up causes the boot code to copy this backup copy to the internal application flash and return the system to its original firmware.

[Caleb Williams]

On the power supply, QSC was using a newer/better version of the 32V supply than USL was (USL might have switched at the very end, I don't recall). They still didn't last forever. There is a 2A version of the supply that seems to do okay. Is that what you all have switched to or is it something different?

We ended up purchasing power supplies from Amazon that are overkill, but we haven't had a single one die yet. https://www.amazon.com/dp/B0CY7LLY4V...fed_asin_title The original power supplied provided with the units did not have a very long life at all.


As for updating firmware; Because it can take some time and the web UI doesn't provide a progress meter, I did some research to automating the task across our fleet. I was able to run a command to upload the hex file with a progress indicator to tell me if anything went wrong with the file transfer. Also, this allowed me to run a simple bash for loop to push the hex file out to all the units at a location. I used this curl command:

curl --progress-bar --http1.0 -u <credentials> \
-H "Connection: close" \
-F "md5file=@IRCv231221.hex;filename=IRCv231221.h ex;t ype=application/octet-stream" \
"http://<unit-IP>/protect/update.htm" \

The for loop would look something like

for s in {21..41}; do

curl --progress-bar --http1.0 -u <credentials> \
-H "Connection: close" \
-F "md5file=@IRCv231221.hex;filename=IRCv231221.h ex;t ype=application/octet-stream" \
"http://<3-octet-ip>.$s/protect/update.htm" \

done

That will loop through all devices ending in ip address 21-41 and push the hex file out. There is no indication that the unit reboots other than a dropped connection, but the progress bar is helpful in determining the upgrade's success. Replace "<credentials>" with the admin credentials for the unit.

[Steve Guttag]

Isn't there a USL batch updater already?

[Caleb Williams]

Isn't there a USL batch updater already?

Uh, is there? I would like a copy if it's available. That would be much better than my hacky batch update script

[Harold Hallikainen]

The USL batch updater is at http://ftp.uslinc.com/Products/IRC-2.../BatchUpdater/ .

One feature of it is that it quits on the first failure instead of bricking every unit in the chain.

[Caleb Williams]

The USL batch updater is at http://ftp.uslinc.com/Products/IRC-2.../BatchUpdater/ .

One feature of it is that it quits on the first failure instead of bricking every unit in the chain.

This is definitely cleaner. Thanks Harold.

We've fully upgraded our fleet to 260501 without any issues

[Leo Enticknap]

Great news! Thanks for confirming.

The only issues I'm aware of have involved managed switches dating from the Old Testament in IT years (as in, the lurid blue Netgear ones dating from around 15-20 years ago) that wouldn't auto detect the full duplex.

[Harold Hallikainen]

The network interface chip in the IRC does not support autonegotiation, so switches default to half duplex. If the IRC is configured for full duplex, the IRC does not hold off transmitting until the switch stops transmitting as it would in half duplex. If the switch defaults to half duplex, it will not transmit when the IRC is transmitting (since it's half duplex). But, luckily, most switches, even if in half duplex, do not reject data received from the IRC when the switch is transmitting. So, the IRC running the full duplex firmware with the switch defaulting to half duplex due to the lack of autonegotiaion allows the IRC to transmit when it would not be allowed to if it were configured as half duplex. This lets the IRC get "a word in edgewise" when the network is busy. Some switches may need to be forced into full duplex to support the IRC with full duplex code, but I think most will work with no special configuration. Some switches may refuse to work with the IRC full duplex firmware, in which case half duplex firmware is available.

Have fun!

[Steve Guttag]

Oof...I have some SMC switches from the initial deployment still going though most are being changed out due to age, if nothing else. I've been pretty adamant about using unmanaged switches for my booth's control networks. With unmanaged, if you have a switch go down, the client can go to Best Buy, Walmart or whatever is local and pick up a cheap switch and be back going within the hour. If you have it all carefully managed and VLANed off, then they're down (possibly). On my Q-SYS networks, yeah I have to go managed but then I also go redundant network to avoid a single point of failure bringing any screen down.