It all started when [Damien Walsh] got his hands on some surplus LED boards. Each panel contained 100 mini-PCBs hosting a single bright LED that were meant to be to be snapped apart as needed. [Damien] had a much better idea: leave them in their 20×5 array and design a driver allowing each LED to be controlled over WiFi. He was successful (a brief demo video is embedded down below after the break) and had a few interesting tips to share about the process of making it from scratch.
The first hurdle he ran into was something most of us can relate to; it’s difficult to research something when one doesn’t know the correct terms. In [Damien]’s case, his searches led him to a cornucopia of LED drivers intended to be used for room lighting or backlights. These devices make a large array of smaller LEDs act like a single larger light source, but he wanted to be able to individually address each LED.
Eventually he came across the IS32FL3738 6×8 Dot Matrix LED Driver IC from ISSI which hit all the right bases. Three of these would be enough to control the 100-LED panel; it offered I2C control and even had the ability to synchronize the PWM of the LEDs across multiple chips, so there would be no mismatched flicker between LEDs on different drivers. As for micontroller and WiFi connectivity, we all have our favorites and [Damien] is a big fan of Espressif’s ESP32 series, and used the ESP32-WROOM to head it all up.
The other issue that needed attention was wiring. Each of the LEDs is on its own little PCB with handy exposed soldering pads, but soldering up 100 LEDs is the kind of job where a little planning goes a long way. [Damien] settled on a clever system of using strips of copper tape, insulated by Kapton (a super handy material with a sadly tragic history.) One tip [Damien] has for soldering to copper tape: make sure to have a fume extractor fan running because it’s a much smokier process than soldering to wires.
A 3D-printed baffle using tracing paper to diffuse the light rounds out the device, yielding a 20 x 5 matrix of individually-controlled rectangles that light up smoothly and evenly. The end result looks fantastic, and you can see it in action in the short video embedded below.
Throwies occupy a special place in hardware culture — a coin cell battery, LED, and a magnet that can be thrown into an inaccessible place and stick there as a little beacon of colored light. Many of us will fondly remember this as a first project. Alas, time marches inevitably on, and launching cheerful lights no longer teaches me new skills. With a nod to those simpler times, I’ve been working on the unusual idea of building a fully functional server that can be left in remote places and remain functional, like a throwie (please don’t actually throw it). It’s a little kooky, yet should still deliver a few years of occasional remote access if you leave it somewhere with sunlight.
A short while ago, I described the power stages for this solar-powered, cloud accessible Linux server. It only activates on demand, so a small solar cell and modest battery are sufficient to keep the whole show running.
Where we left off, I had a solar cell that could charge a battery, and provide regulated 12 V and 5 V output. For it to be a functional device, there are three high level problems to solve:
It must be possible to set up the device without direct physical access
You must be able to remotely turn it on and off as needed.
It needs to be accessible from the Internet.
The funny thing is, this hardware reminds me of a satellite. Of course it’s not meant to go into space, but I do plan to put it somewhere not easy to get to again, it runs off of solar power, and there’s a special subsystem (ESP8266) to tend the power, check for remote activation, and turn the main computer (Raspberry Pi 3) on and off as necessary. This sounds a lot like space race tech, right?
As I have a bit more code than usual to share with you today, I’ll discuss the most interesting parts, and provide links to the full firmware files at the end of the article.
One of the biggest advantages of using the ESP8266 in your projects is how easy it is to get WiFi up and running. Just plug in the WiFi library, put the SSID and encryption key in your source code, and away you go. It authenticates with your network in seconds and you can get on with building your project. But things get a little trickier if you want to take your project someplace else, or distribute your source code to others. Quickly we learn the downside of using static variables for authentication.
While there are already a few solutions to this problem out there, [Martin Raynsford] wasn’t too thrilled with them. Usually they put the ESP8266 in Access Point mode, allow the user to connect, and then ask which network they should authenticate with. But he didn’t want his projects to require an existing network, and figured he could do just as well making a field-configurable AP.
Using it is simple. Once the ESP8266 starts up it will create a new network in the form of “APConfig XXXXXX”, which should be easy enough to find from your client side device. Once connected, you can go to a simple administration page which allows you to configure a new AP name and encryption key. You even have the option to create an open AP by leaving the “Password” field blank. Once rebooted, the ESP8266 will create a new network with the defined parameters.
[Martin] has also included a “backdoor” to let anyone with physical access to the ESP8266 board create a new open AP that can be used to reconfigure the network settings. During boot up there is a brief period, indicated with specific blinks of the LED, wherein you can hit the reset button and trigger the open AP. This keeps you from getting locked out of your own project if you forget what key you gave it.
We use the Internet to do everything from filing our taxes to finding good pizza, but most critically it fulfills nearly all of our communication needs. Unfortunately, this reliance can be exploited by those pulling the strings; if your government is trying to do something shady, the first step is likely to be effecting how you can communicate with the outside world. The Internet is heavily censored and monitored in China, and in North Korea the entire country is effectively running on an intranet that’s cutoff from the wider Internet. The need for decentralized information services and communication is very real.
While it might not solve all the world’s communication problems, [::vtol::] writes in to tell us about a very interesting communication device he’s been working on that he calls “Hot Ninja”. Operating on the principle that users might be searching for accessible Wi-Fi networks in a situation where the Internet has been taken down, Hot Ninja allows the user to send simple messages through Wi-Fi SSIDs.
We’ve all seen creatively named Wi-Fi networks before, and the idea here is very much the same. Hot Ninja creates a Wi-Fi network with the user’s message as the SSID in hopes that somebody on a mobile device will see it. The SSID alone could be enough depending on the situation, but Hot Ninja is also able to serve up a basic web page to devices which actually connect. In the video after the break, [::vtol::] even demonstrates some rudimentary BBS-style functionality by presenting the client devices with a text field, the contents of which are saved to a log file.
In terms of hardware, Hot Ninja is made up of an Arduino Mega coupled to three ESP8266 boards, and a battery to keep it all running for up to eight hours so you can subvert a dictatorship while on the move. The user interface is provided by a small OLED screen and a keyboard made entirely of through-hole tactile switches, further reinforcing the trope that touch-typing will be a must have skill in the dystopian future. It might not be the most ergonomic device we’ve ever seen, but the fact it looks like something out of a Neal Stephenson novel more than makes up for it in our book.
Do you remember the screeching of a dial-up modem as it connected to the internet? Do you miss it? Probably not, but [Erick Truter] — inspired by a forum post and a few suggestions later — turned a classic modem into a 3G Wi-Fi hotspot with the ubiquitous Raspberry Pi Zero.
Sourcing an old USRobotics USB modem — allegedly in ‘working’ condition — he proceeded to strip the modem board of many of its components to make room for the new electronic guts. [Truter] found that for him the Raspberry Pi Zero W struggled to maintain a reliable network, and so went with a standard Pi Zero and a USB Wi-Fi dongle dongle. He also dismantled a USB hub to compensate for the Zero’s single port. Now, to rebuild the modem — better, faster, and for the 21st century.
What makes [mwagner1]’s Raspberry Pi Zero-based WiFi camera project noteworthy isn’t so much the fact that he’s used the hardware to make a streaming camera, but that he’s taken care to document every step in the process from soldering to software installation. Having everything in one place makes it easier for curious hobbyists to get those Pi units out of a drawer and into a project. In fact, with the release of the Pi Zero W, [mwagner1]’s guide has become even simpler since the Pi Zero W now includes WiFi.
Using a Raspberry Pi as the basis for a WiFi camera isn’t new, but it is a project that combines many different areas of knowledge that can be easy for more experienced people to take for granted. That’s what makes it a good candidate for a step-by-step guide; a hobbyist looking to use their Pi Zero in a project may have incomplete knowledge of any number of the different elements involved in embedding a Pi such as basic soldering, how to provide appropriate battery power, or how to install and configure the required software. [mwagner1] plans to use the camera as part of a home security system, so stay tuned.
If Pi Zero camera projects catch your interest but you want something more involved, be sure to check out the PolaPi project for a fun, well-designed take on a Pi Zero based Polaroid-inspired camera.
When you are running a hackspace, network security presents a particular problem. All your users will expect a wireless network, but given the people your space will attract, some of them are inevitably going to be curious enough to push at its edges. Simply plugging in a home WiFi router isn’t going to cut it.
At Santa Barbara Hackerspace they use Unifi access points on their wireless network, and their guest network has a system of single-use codes to grant a user 24-hour access. The system has the ability to print a full sheet of codes that can be cut individually, but it’s inconvenient and messy. So the enterprising hackspace members have used a Raspberry Pi and a receipt printer to deliver a single code on-demand at the press of a button.
The hardware is simple enough, just a pull-up and a button to a GPIO on the Pi. Meanwhile the software side of the equation has a component on both client and server. At the server end is a Python script that accesses the Unifi MongoDB database and extracts a single code, while at the client end is another Python script that reacts to a button press by calling the server script and printing the result. It’s a simple arrangement that was put together in an evening, but it’s an effective solution to their one-time WiFi access needs.
It’s a temptation as a hackspace to view all of your problems as solvable in one go with the One Piece Of Software To Rule Them All, and as a result some spaces spend a lot of time trying to hack another space’s effort to fit their needs or even to write their own. But in reality it is the small things like this one that make things work for members, and in a hackspace that’s important.
Does your space have any quick and simple projects that have automated a hackspace process? Let us know in the comments.