Fixing the M5 Camera System
Sometimes, working with old technology or systems—especially ones installed a long time ago without any documentation—can be an absolute pain to work with. M5’s cameras are undoubtedly very old, it’s obvious from their appearance that they’re an early 2000s product. Despite this, I knew that I could bring these aging devices back to life with enough reverse engineering and the right software.
One of the M5 cameras right after it was powered on for the first time
The Beginning: Investigate and Document
I knew the first things I had to do were:
Find/Document all the cameras and give each of them an ID.
Figure out how/where all the cameras connect together and what the network they reside on looks like.
Finding and documenting all the cameras was easy, I walked around M5 and counted 9 total. Figuring out how they connect together was hard part.
I managed to steal the extension ladder from the SDP lab so I could poke around the ceiling and trace cables. From previous experience running cables through M5’s ceiling for the Telethon back in April, I knew that there was an old network switch residing near 5A.
The switch and router sitting above the ceiling
Once I saw all the camera cables converging to this switch/router, I knew this was the heart of the camera network. I plugged both of them back in to see if everything would spring back to life, and it did! All the cameras immediately turned on (since the switch had Power Over Ethernet, so it powered and connected the cameras together).
Now, with all the network components located, I figured I would start setting up the server computer.
Setting Up The Server
The Optiplex right after I opened it up
A brand new Dell Optiplex was set aside for managing the cameras now. Before I started installing anything though, I wanted to check what kind of hardware it had. I poked around inside the case quickly and saw the 12TB drive(!) set aside for the camera recordings. Besides that, everything else was what you would find in a standard Dell Optiplex.
With me being a Linux and Free & Open Source Software enthusiast, I did my research to see what kind of camera software I could get running on a Linux machine. I found Motion, and MotionEye, which both work together to provide web interface to manage and configure all the cameras. As for the Linux distribution, I knew immediately that I would be using Debian since it is extremely reliable.
After setting up Debian 12 on the server, I needed to set up some essential network services before I could continue to setting up Motion and MotionEye.
The first service was time synchronization. The cameras needed all their internal clocks to be synchronized so that they display the right time in the recordings. A Network Time Protocol Server (NTP server) provides this exact functionality. After quickly setting one up on the server computer, all of the cameras would then synchronize their clocks to the server computer’s clock.
The next service was Domain Name System (DNS). This wasn’t exactly essential to the camera network functioning, but it’s good to have and also allows devices on the network to refer to each other by name instead of IP address. Luckily, this was already part of Debian 12, I just needed to tell the cameras to use it.
The last service was Dynamic Host Control Protocol (DHCP). This service would automatically configure new devices that connected to the network. I mainly used this for the cameras so in case they got factory reset or their configuration got messed up, it would automatically reconfigure their IP addresses, hostname, etc. This also was already part of Debian 12, I just needed to turn off the router’s DHCP server so the cameras would use this one instead.
Now it was finally time to setup Motion and MotionEye. The installation for both was very straightforward, I figured the time-consuming part would be configuring both. However, I didn’t have to worry about that yet; I needed to reset all the cameras to factory settings so I could have Motion/MotionEye access them.
Resetting & Configuring the Cameras
Each camera had to be manually reset, which meant I had to go around to every camera, press and hold a reset button for 15 seconds, and then make sure it reconfigured itself properly. This was one of the most time consuming parts of the project, mainly because the cameras took a couple minutes to reconfigure themselves properly, and I had to manually adjust NTP/DNS/DHCP settings on the server computer quite a few times before things were working perfectly. After a few hours of resetting and fine tuning, the cameras were nearly ready to go.
Viewing the camera web interface immediately after it was reset
One thing I noticed, was that there seemed to be an extra device on the network that I haven’t discovered yet (from reading the DHCP logs). It seemed to be a camera, since its MAC address was very similar to the other cameras on the network, so I had somehow missed a camera somewhere. I was able to narrow down that it was connected to port 4 of the switch by pinging it and disconnecting cables from the switch one by one. I went back up into the ceiling to trace where that cable went, and surprisingly, it brought me to ElectronicaLab! I somehow didn’t see the tenth camera in the corner, which meant I had to go back and change my configurations and documentation to account for this new camera. However, once I settled that out, it was finally time to setup Motion and MotionEye.
Setting Up Motion & MotionEye
This project really started getting interesting by this point. MotionEye conveniently provides a web interface to add new cameras and adjust all their settings, which was a nice change from all the bare-bones configuration files I was modifying before. I added each camera one by one, and soon the web interface had every camera showing all at once, which was really cool to see.
Unfortunately, I couldn’t copy the settings for one camera to another, so I had an idea. I could configure one camera perfectly (with the right motion & video settings, framerate, etc), and then copy the config file and replace any settings that were particular to that camera (which was the URL the camera would pull the video stream from). Using a basic bash script I made, I was able to copy the settings from the first camera to all the others. At this point, the system was fully operational. I continued writing documentation for the system, and over the next few days I observed the recordings the cameras took and tweaked some settings.
The MotionEye web interface showing all the M5 cameras at once
It was really satisfying to see such an archaic system be brought back to life. The camera quality surprisingly still holds up remarkably well today, but I think some upgrades are definitely due soon.
