If you are beyond a certain age, you will recall when getting on the Internet was preceded by strange buzzing and squawking noises. Modems used tones to transmit and receive data across ordinary telephone lines. There were lots of tricks used to keep edging the speed of modem up until — at the end — you could download (but not upload) at a blazing 56,000 bits per second. [Martin Kirkholt Melhus] decided to recreate a modem. In a Web browser. No kidding.
We started to say something about a modem in the cloud, but that wouldn’t really be accurate. The modem uses the HTML 5 audio API, so it really runs in the browser. We would have been really surprised if [Martin] had cooked up a modem able to interact with a real modem, but as you might expect, the browser modem only communicates with other instances of itself. If you want a brief introduction to HTML 5 audio, you might enjoy the video below.
By now, most of us know the perks of using a VPN: they make private one’s online activity (at least from your ISP’s point of view, probably), and they can also make it appear as if you are in a different locale than you physically are. This is especially important for trying to watch events such as the Olympics which might air different things at different times in different countries. It’s also starting to be an issue with services like Netflix which allow content in some areas but not others.
Obviously this creates issues for Netflix as a company, and indeed a number of services (like craigslist, for example) are starting to block access to their sites if they detect that a VPN is being used. Of course, this only leads to an arms race of VPNs being blocked, and them finding ways around the obstacles, and on and on. If only IPv6 was finally implemented, we might have a solution for all of these issues.
Distributed computing is an excellent idea. We have a huge network of computers, many of them always on, why not take advantage of that when the user isn’t? The application that probably comes to mind is Folding@home, which lets you donate your unused computer time to help crunch the numbers for disease research. Everyone wins!
But what if your CPU cycles are being used for profit without your knowledge? Over the weekend this turned out to be the case with Showtime on-demand sites which mined Monero coins while the users was pacified by video playback. The video is a sweet treat while the cost of your electric bill is nudged up ever so slightly.
[Mike] is the only one in his house who drinks coffee, and uses a simple single-serving brewer with no auto-on feature. And since no one really wants to have to stand around making coffee in the morning, [Mike]’s solution was to IoT-ize his electrical socket.
The project consists of a relay board controlled by an ESP8266-packing Adafruit Huzzah. It’s all powered by a 9V power supply with a regulator supplying the relay coil and Huzzah with 5V. [Mike]’s using CloudMQTT to communicate with the outlet.
We often see these automation projects hit a wall when it comes to adding a user-side dashboard. [Mike] is using a free Android app called MQTT Dash which allows for a number of different UI components and even had coffee maker icons already built in. It’s certainly worth a look for your own projects. [Mike] uses it to turn on the outlet for 10 minutes, and by the time he grabs half-and-half the outlet is already off again.
[Raphael] built a prototype of the ESP8266 hardware on protoboard and used it to read and record the IR signals from the remote. Once he’d figured out the issues he was having with the IR library he was using, he could use it to send the IR commands to the AC unit. Since their office has two AC units, [Raphael] built a second prototype which had two IR LEDs but didn’t have the IR receiver. Using this he could turn both AC units on and off and set their temperatures.
For the server, [Raphael] turned to Clojure, a dialect of Lisp, which provides easy access to the Java Framework, mainly to get practice working with the language. The server’s main responsibility is to use Slack’s real-time API to listen for messages from a Slack bot and forward them to the ESP. In this way, a user talking to the Slack bot can send it messages which the server forwards to the microcontroller which, in turn, parses the messages and send IR commands to the AC units.
[Raphael] admits that this isn’t the most advanced, professional stuff, but it doesn’t matter. The schematics for the ESP8266 board and the code for both the ESP board and the server are available on GitHub. There seems to be a lot of hacks using Slack, such as this NERF Turret controlled by a Slack bot. Or this jukebox that users can interact with by talking to a Slack bot.
In what may be the strangest retrocomputing project we’ve seen lately, you can now access a virtual 6502 via Amazon’s Lambda computing service. We don’t mean there’s a web page with a simulated CPU on it. That’s old hat. This is a web service that takes a block of memory, executes 6502 code that it finds in it, and then returns a block of memory after a BRK opcode or a time out.
You format your request as a JSON-formatted POST request, so anything that can do an HTTP post can probably access it. If you aren’t feeling like writing your own client, the main page has a form you can fill out with some sample values. Just be aware that the memory going in and out is base 64 encoded, so you aren’t going to see instantly gratifying results.
[Sprite]’s method of blinking a light is simple: Use an ESP32 development board to turn on a relay. At the same time, send a packet out to the Internet and through four servers spread across the globe. When the packet goes through servers in Shanghai, the Netherlands, to Hong Kong, to Germany, and finally Japan — and back again — the light bulb turns off. It’s a physical demonstration of the speed of light and the quality of undersea optical fibers.
This route is quite long, and a reasonable estimate for the one-way, great circle path from Shanghai to the Netherlands to Hong Kong to Berlin and finally to somewhere near Osaka is about 36,000 km. A round trip for this light bulb packet is 72,000 km, or about 0.2 light-seconds. There are delays, of course, from fiber and cables not going directly over the Himalayas, delays in routers, and the difference between the speed of light in a vacuum and the speed of light in glass fiber. Still, light is quick, and the light blinks at about 1Hz.
You can check out [Sprite]’s entry video for the Flashing Light Prize below.