[Renzo Mischianti] got himself a Chinese 3D printer, specifically a FlyingBear Ghost 5. (Cracking name, huh?) He was more than a little irritated with the fact that whilst the controller, an MKS Robin Nano, did have a integrated Wi-FI module, it provided no browser-based interface for monitoring and control purposes. This seemed a bit short-sighted in this day and age, to say the least. Not being at all happy with that situation, [Renzo] proceeded to write dedicated Wi-Fi firmware using websockets, but not without fully documenting his journey in a detailed series of the blog posts.
The resulting BeePrint web interface supports all the usual functions you would expect when managing a printer, everything from monitoring warm-up at the prep stage, to keeping tabs on the potential spaghetti monster via the connected IP camera. All good stuff. [Renzo] used an ESP32-cam, which is a low-cost 2 MP unit from our friends at Olimex, but we suspect it wouldn’t vastly difficult to add your own IP camera into the mix.
[Renzo] has a YT channel detailing quite a few other projects, which is definitely worth some viewing time in our opinion.
[Sebastian Staacks] came across his old Game Boy and was wondering (as you do) what happened to recent attempts at getting a WiFi interface wedged into a standard cartridge. After a while the conclusion was that people had been scuppered by approaching the problem in a way that made it too hard. Obviously that meant it was necessary to follow through and build something, which is precisely what he did with his WiFi Game Boy Cartridge.
A trend lately has been to hook up a fast microcontroller to a bus, then move the whole interfacing shenanigans into software. This works fine in some circumstances, but for the GB interface, it’s not so easy. The GB is powered by the Sharp LR35902, running at a smidge over 4 MHz, but its machine cycle takes four clocks giving an instruction rate of only 1 MHz. The cartridge interface presents the raw CPU bus directly. This is both good and bad. It’s good, because it enables all kinds of expansion modules, like cameras, printers, and other custom peripherals, but it’s bad because the burden of interfacing with the CPU, at its full speed, lies squarely in the cartridge’s remit.
Rather than trying to hook this bus directly to a fast microcontroller, [Staacks] has taken a different approach; by decoding the address bus with discrete logic, it was easy to derive chip selects for an embedded ESP8266 as well as a socketed EEPROM. The clock for the former was also gated and sent into the ESP8266, generating an interrupt to wake it up. The EEPROM stores a simple application whose job is to present an OSD keyboard and send requests to Wikipedia, via the ESP8266 WiFi stack. The resulting text is then displayed on the 160×144 dot matrix display. The interrupt latency of the ESP8266 was mitigated by the application simply discarding the first data byte sent to it, and retrying the access. This way the ESP8266 could spend the majority of its time dealing with wireless duties, only pausing to swap a byte now-and-then with the application. A simple solution which appears to actually work! If you’re up for building one of these and writing your own applications, you can wander over to GitHub, clone yourself a copy and crack on!
As an itinerant Hackaday writer I am privileged to meet the people who make up our community as I travel the continent in search of the coolest gatherings. This weekend I’ve made the trek to the east of the Netherlands for the ETH0 hacker camp, in a camping hostel set in wooded countryside. Sit down, connect to the network, grab a Club-Mate, and I’m ready to go!
Forget the CTF, Connecting To WiFi Is The Real Challenge!
There no doubt comes a point in every traveling hacker’s life when a small annoyance becomes a major one and a rant boils up from within, and perhaps it’s ETH0’s misfortune that it’s at their event that something has finally boiled over. I’m speaking of course about wireless networks.
While on the road I connect to a lot of them, the normal commercial hotspots, hackerspaces, and of course at hacker camps. Connecting to a wireless network is a simple experience, with a level of security provided by WPA2 and access credentials being a password. Find the SSID, bang in the password, and you’re in. I’m as securely connected as I reasonably can be, and can get on with whatever I need to do. At hacker camps though, for some reason it never seems to be so simple.
Instead of a simple password field you are presented with a complex dialogue with a load of fields that make little sense, and someone breezily saying “Just enter hacker and hacker!” doesn’t cut it when that simply doesn’t work. When you have to publish an app just so that attendees can hook up their phones to a network, perhaps it’s time to take another look . Continue reading “So. What’s Up With All These Crazy Event Networks Then?”→
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.