Running a camera studio is a complicated affair from pretty much every angle. Not only is the camera gear expensive but the rest of the studio setup takes care and attention down to the lighting as well. When adding multiple cameras to the mix, like for a television studio, the level of complexity increases exponentially. It’s great to have a few things that simplify the experience of running all of this equipment too, without the solution itself causing more problems than it solves, like these network-operated Raspberry Pi-powered tally lights.
A tally light is the light on a camera that lets the person being recorded know which camera is currently in use. Networking them all together often requires complex wiring or at least some sort of networking solution, which is what this particular build uses. However, the lights are controlled directly over HTTP rather than using a separate application which might need a port open on a firewall or router, which not only simplifies their use but doesn’t decrease network security.
The HTTP interface, plus all of the software and schematics for this build, are available on the project’s GitHub page. We imagine the number of people operating a studio and who are in need of a tally light system to be fairly low, but the project is interesting from a networking point-of-view regardless of application. If you do have a studio like this and are looking for other ways to improve it, we do have a simple teleprompter hack that might be right up your alley.
In the server world, it’s a foregone conclusion that ports shouldn’t be exposed to the greater Internet if they don’t need to be. There are malicious bots everywhere that will try and randomly access anything connected to a network, and it’s best just to shut them off completely. If you have to have a port open, like 22 for SSH, it’ll need to be secured properly and monitored so that the administrator can keep track of it. Usually this is done in a system log and put to the side, but [Nick] wanted a more up-front reminder of just how many attempts were being made to log into his systems.
This build actively monitors attempts to log into his server on port 22 and notifies him via a numerical display and series of LEDs. It’s based on a Raspberry Pi Zero W housed in a 3D-printed case, and works by interfacing with a program called fail2ban running on the server. fail2ban‘s primary job is to block IP addresses that fail a certain number of login attempts on a server, but being FOSS it can be modified for situations like this. With some Python code running on the Pi, it is able to gather data fed to it from fail2ban and display it.
[Nick] was able to see immediate results too. Within 24 hours he saw 1633 login attempts on a server with normal login enabled, which was promptly shown on the display. A video of the counter in action is linked below. You don’t always need a secondary display if you need real-time information on your server, though. This Pi server has its own display built right in to its case.
Towering behemoths are prowling the docks of Auckland, New Zealand, in a neverending shuffle of shipping containers, stacking and unstacking them like so many out-sized LEGO bricks. And they’re doing it all without human guidance.
It’s hard to overstate the impact containerized cargo has had on the modern world. The ability to load and unload ships laden with containers of standardized sizes rapidly with cranes, and then being able to plunk those boxes down onto a truck chassis or railcar carrier for land transportation has been a boon to the world’s economy, and it’s one of the main reasons we can order electronic doo-dads from China and have them show up at our doors essentially for free. At least eventually.
As with anything, solving one problem often creates other problems, and containerization is no different. The advantages of being able to load and unload one container rather than separately handling the dozen or more pallets that can fit inside it are obvious. But what then does one do with a dozen enormous containers? Or hundreds of them?
That’s where these giant self-driving cranes come in, and as we’ll see in this installment of “Automate the Freight”, these autonomous stevedores are helping ports milk as much value as possible out of containerization.
If you keep up with the field of web development, you may have heard of WebAssembly. A relatively new kid on the block, it was announced in 2015, and managed to garner standardised support from all major browsers by 2017 – an impressive feat. However, it’s only more recently that the developer community has started to catch up with adoption and support.
So, what is it? What use case is so compelling that causes such quick browser adoption? This post aims to explain the need for WebAssembly, a conceptual overview of the technical side, as well as a small hands-on example for context.
The 1980s were the heyday of the venerable Z80, a processor that found its way into innumerable home computers, industrial systems, and yes — arcade machines. However, not everyone had a Z80 based machine at home, and so sometimes porting is required. [Glen] is tackling this with a port of Pac Man to the Radio Shack Colour Computer 3.
The key to any good arcade port is authenticity – the game should feel as identical to the real thing as possible. The Atari 2600 port got this famously wrong. Porting to the Colour Computer 3 is easier in theory – with more RAM, a Motorola 6809 CPU running at a higher clock rate, and a more powerful graphics subsystem, fewer compromises need to be made to get the game to run at a playable speed.
The way [Glen] tackled the port is quite handy. [Glen] built a utility that would scrape a disassembled version of the original Pac Man Z80 code, look up the equivalent 6809 CPU instruction, and replace it, while placing the original Z80 code to the side as a comment. Having the original code sitting next to the ported instructions makes debugging much easier.
There was plenty of hand tweaking to be done, and special effort was made to make sure all the data the original code was looking for was accessible at the same addresses as before. There was also a lot of work involved in creating a sprite engine that would reliably display the game video at a playable frame rate.
Overall, the port is highly faithful to the original, with the game code being identical at the CPU level. [Glen] reports that the same patterns used on the arcade machine can be used to complete the mazes on the Colour Computer 3 version, and it faithfully recreates the Level 256 bug as well. It’s an impressive piece of work to create such an authentic port on a home computer from 1986.
[deater] readily admits they’re a little behind on what’s new in gaming – only having just gotten around to Valve’s 2007 release of Portal. It’s a popular game, but [deater] didn’t want anyone to miss out on the fun – so set about porting Portal to the Apple II.
The port uses the “hires” mode of the Apple II for the flashy graphics that were state of the art around 1980 or so. It’s not a copy of the full game – only the first and last levels, combined with Jonathan Coulton’s now-classic ending theme, Still Alive. As is to be expected, it’s not a wild, fast paced gaming experience, but a cool use of BASIC to put together a fun tribute to a popular franchise.
It’s a little different to the original – portals can be placed anywhere, for example – but it rings true to the original. Source code and a disk image is provided, so you can try it for yourself – even in this online emulator.
[Piotr] was working on a recent Arduino project when he ran into a problem. He was having trouble getting his Arduino Pro Mini to communicate with an ESP8266 module. He needed a way to snoop on the back and forth serial communications. Since he didn’t have a specialized tool for this task, [Piotr] ended up building his own.
The setup is pretty simple. You start with a standard serial cable containing the TX, RX, DTR, and GND wires. This cable connects the Arduino to the ESP8266 WiFi module. The TX and RX lines are then tapped into. Each wire is routed to the RX pin of two different serial to USB adapters. This way, the data being sent from the Arduino shows up on one COM port and the data being transmitted from the module shows up on the other.
The next piece of the puzzle was coming up with a way to see the data more clearly. [Piotr] could have opened two serial terminals simultaneously, but this wasn’t ideal because it would be difficult to compare the timing of the data. Instead, [Piotr] spent less than an hour writing his own simple serial terminal. This one connects to two COM ports at the same time and prints the data on the same screen. The data from each COM port is displayed in a separate color to make it easy to differentiate. The schematic and source code to this project can be found on [Piotr’s] website.