I’ve been running the Blackmagic Design ATEM 1 M/E Production Studio 4K for about 18 months now. It’s been a great unit; however, it has always been a little noisy. And lately, one (or maybe more) of the fans inside appears to have developed a failing bearing and the noise has been far too loud for any production environment.
There is so little info that I could find online about what’s under the hood of the Blackmagic Design ATEM 1 M/E Production Studio 4K. So, I had to pop it open to see what I was working with here. Since I was outside my warranty period, I wasn’t concerned with those consequences. If your fans fail within your warranty, feel free to go ahead and have Blackmagic to fix it.
Inside, there are three exhaust fans along the left side (one is already removed in the above image) and four fans atop heatsinks to cool internal components. The right side is open for the exhaust fans to pull the cool air from.
Remember the USP RPS that we saw in the new 6U rack last month? Well, it has hit the beta store and additional product photos shown with it reveal yet another new device likely surrounding the (still-being-revamped) Unifi Protect product line.
In an Early Access product drop for the new Ubiquiti U-Rack-6U, which sold out quickly for Early Access members, we also got a sneak peek at the upcoming USP RPS and the UNAS 4 (in RU slots 01 and 02, respectively), two products we’ve been hoping to see for quite some time…
For clarification of what we’re looking at here, let’s list the products in the rack from top to bottom.
06: UDM Pro
05: 24-port patch panel
03: 24-port patch panel
02: UNAS 4
01: USP RPS
Zooming in closely on the photo reveals the product names on the devices.
Since Ubiquiti has stopped updating UniFi Video, we’ve all been waiting for a bigger move on the UniFi Protect front so that is properly scalable (unlike the single-drive Cloud Key Gen2 Plus). The UNAS 4 is likely that solution in combination with the UDM Pro, which is currently in beta with the Early Access program.
Whether the UNAS 4 (and you know there is a UNAS 8 and maybe larger in the pipeline, if they’re making the effort to call it UNAS ‘4’) is a pure NAS device or whether it runs UniFi Protect is unknown at this point. All we have is the image of a 1U device with four 3.5″ drive bays and is in the range of 10-14″ deep by just spitballing the image.
We have virtually nothing to go on for the USP RPS other than the name, which I think could be a true regulated power supply (aka RPS) for converting AC to DC power that then feeds the new UniFi products with the ULS RPS inputs on the rear. Below is a close up of the USW-PRO-48-POE switch that has the ULS RPS power input.
How nice would it be to eliminate the AC plugs and power supplies for every unit in your rack and replace the rack-mounted PDU with a USP RPS that powers your entire rack? Additionally, you would be able to monitor and likely remotely power cycle every connected device from the UniFi SDN interface.
I’ve had a persistent issue over the past month or so as my primary LAN connection kept dropping its Internet connectivity – seemingly at random and with no real trigger that I could identify. What was even more perplexing to me was that my VLAN 20, which is connected to my PIA VPN, maintained its connection for the 22 days since the last reboot of my pfSense box.
For reference, I’m currently running pfSense 2.4.4.
In my system logs under Status > System Logs > System > Gateways, I noticed a repeated DCHP error entry, “sendto error: 55” – the process and full error looks something like “dpinger WANGW x.x.x.x: sendto error: 55.”
Whenever the Internet connection would drop, I could reestablish connectivity by physically unplugging the LAN cable from the pfSense box and plugging it back in.
There are a number of things that can cause this error to occur. In my case, however, it was a pretty innocuous issue narrowed down to the Monitor IP in the Gateway settings page. Go to System > Routing > Gateways and click the edit icon for your WAN.
I simply changed the Monitor IP (it’s blank by default) to Google’s server at 188.8.131.52 and the network hasn’t dropped since. (It’s been several days now – from what was dropping every few random hours.)
I have gateway monitoring turned off for my VPN VLAN connection, which may be why this is only affecting my default LAN going out over my public WAN connection. I haven’t seen anyone with this exact set of circumstances but I wanted to pass along my solution in case anyone else is pulling their hair out over it.
I set up a dedicated VPN VLAN on my home network this weekend with the latest version of pfSense (ver. 2.4.4 as of July 2019) for IoT and Firestick types of devices. I ran into some hiccups with older guides because a few of the settings and menu options have changed, so I’m putting together my notes here for my own reference and anyone else struggling with more recent pfSense releases and VPN/VLAN configuration.
I was setting up an old Dell PowerEdge R610 server in my home lab this week and kept getting an error message from Java 8 after I attempted to launch the Virtual Console Client from its iDRAC 6 Enterprise card:
Unable to launch the application.
I narrowed the issue down to the disabled algorithms in the java.security file. You’ll need to open this file in a basic text editor and look for the jdk.tls.disabledAlgorithms entry.
Then, delete RC4 from the list of algorithms in that entry. Make sure you save the file as a .security file (not a .txt file) and then launch the Virtual Console Client again.
After I removed RC4 from the disabled algorithms, it connected just fine.
Notably, I ran into a slightly different issue on my MacBook Pro. I went through all the steps above that I had done on my Windows 10 machine but I still had the error. When I clicked through for more info, I saw that a different algorithm was the culprit.
So, I deleted MD5 from the jdk.tls.disabledAlgorithms entry and that solved the problem on my Mac.
I’m not sure how this is handled with later versions of iDRAC on Dell servers; however, removing RC4 and/or MD5 from the list of disabled algorithms in your Java 8 java.security file should solve connectivity issues with other 11th-generation servers like the R710, R510, R410 and so on.
The ProVideoInstruments VeCOAX PRO-X QAM RF Modulator has been a great tool for me to use in our campus-wide video distribution at my church. Essentially, it has allowed us to take an antiquated RF distribution system to campus-wide HD distribution in an almost plug-and-play upgrade.
When I was doing research for last year’s complete video overhaul, this is a device that was on my radar. While I wasn’t certain it would work out of the box, it is something we needed to find a way to make work. I was thrilled when we racked it up into our system and connected the 20-year-old RF network. We had four channels available to every coax connected TV accessible via their QAM tuner.
Additionally, we upgraded several of our RF splitters to more modern Extreme 5-1002MHz splitters at our various IDF locations. Other than that, the PVI VeCOAX just works.
Having the four channels gives us plenty of flexibility to distribute content on channels 1-1 through 4-1 with a simple auto-tune setup on every TV’s cable tuning menu. And we can quickly swap out signals if we need something special for a one-off event just by changing the HDMI input source. We can roll our primary video program feed from our SDI switcher output to a Decimator MD-HX and then to HDMI. We also use a dedicated MacBook Pro equipped with ProPresenter for running digital signage that can quickly be altered to all endpoints on the fly.
I’ve wanted to write about this device for a long time because I love it so much. And it’s part of the reason I dusted off Tech Tilt to fire it up and write about things like this.
The ProVideoInstruments VeCOAX PRO-X QAM RF Modulator is available from Tech Tilt’s trusted retail partner, B&H Photo, at the following link: