Readers of a certain age will remember the payphone trick of letting the phone ring once and then hanging up to get your quarter back. This technique was used with a pre-planned call time to let someone know you made it or you were okay without accruing the cost of a telephone call. As long as nobody answered you didn’t have to pay for the call, and that continues to be the case with some pay-per-minute cellphone plans.
This is the concept behind [Antonio Ospite’s] ringtone data transfer project called SaveMySugar. Don’t judge him, this work has been ongoing for around ten years and started back when cellphone minutes were a concern. We’re just excited to see that he got the excruciatingly slow thing to work.
Those wanting to dig down to the nitty-gritty of the protocol (and you should be one of them) will want to read through the main project page. The system works by dialing the cellphone, letting it ring once, then hanging up. The time between redials determines a Morse code dot, dash, or separation between characters. Because you can’t precisely determine how long it will take each connection to read, [Antonio] built ‘noise’ measurement into the system to normalize variations. The resulting data transfer works quite well. He was able to transfer the word “CODEX” in just six minutes and thirty seconds. But it is automatic, so what do you care? See the edge-of-your-seat-action play out in the video below.
If you can’t stomach that baud, here’s a faster Morse code data transmitter but it doesn’t use the phone.
Continue reading “Free Cell Data Transfer with Slowest Morse Code Ever”
If there’s any indication of the Commodore 64’s longevity, it’s the number of peripherals and add-ons that are still being designed and built. Right now, you can add an SD card to a C64, a technology that was introduced sixteen years after the release of the Commodore 64. Thanks to [Leif Bloomquist], you can also add WiFi to the most cherished of the home computers.
[Leif]’s WiFi modem for the C64 is made of two major components. The first is a Microview OLED display that allows the user to add SSIDs, passwords, and configure the network over USB. The second large module is the a Roving Networks ‘WiFly’ adapter. It’s a WiFi adapter that uses the familiar Xbee pinout, making this not just a WiFi adapter for the C64, but an adapter for just about every wireless networking protocol out there.
[Leif] introduced this WiFi modem for the C64 at the World of Commodore earlier this month in Toronto. There, it garnered a lot of attention from the Commodore aficionados and one was able to do a video review of the hardware. You can check out [Alterus] loading up a BBS over Wifi in the video below.
Continue reading “Giving the C64 A WiFi Modem”
Where you might see a can, [Adam Kumpf] sees a robot. [Adam’s] robot (named [Canny]) doesn’t move around, but it does have expressive eyebrows, multicolored eyes, and a speaker for a mouth. What makes it interesting, though, is the fact that it receives audio commands via the headphones it wears. You can see [Canny] in action in the video below.
The headphones couple audio tones to [Canny’s] microphone using AFSK (audio frequency shift keying). [Canny] uses an opamp to bring the microphone level up and then uses a 567 PLL IC to decode the audio tones. [Adam] selected two clever frequencies for the mark and space (12345 Hz and 9876 Hz). In addition to being numerically entertaining, the frequencies are far enough apart to be easy to detect, pass through the headphones with no problem, and are not harmonically related.
Continue reading “Robot Listens to Commands–Literally”
In the old days, a serial port often connected to an acoustic coupler that gripped a phone handset and allowed a remote connection to a far away serial port (via another phone and acoustic coupler) at a blistering 300 baud or less. The acoustic coupler would do the job of converting serial data to audio and reconstituting it after its trip through the phone lines. Modems advanced, but have mostly given way to DSL, Cable, Fiber, and other high speed networking options.
In a decidedly retro move, [James Halliday] and [jerky] put a modern spin on that old idea. They used the webaudio API to send serial data to a remote Arduino. The hack uses a FET, a capacitor, and a few resistors. They didn’t quite build a real modem with the audio. Instead, they basically spoof the audio port into sending serial data and recover it with the external circuitry. They also only implement serial sending (so the Arduino receives) so far, although they mention the next step would be to build the other side of the connection.
Continue reading “Serial Data from the Web to an Arduino”
[Maurice] recently built a clock that draws the time (Google Doc) on a white board. We’ve seen plenty of clock hacks in the past, and even a very similar one. It’s always fun to see the different creative solutions people can come up with to solve the same problem.
This device runs on a PIC16F1454 microcontroller. The code for the project is available on GitHub. The micro is also connected to a 433MHz receiver. This allows a PC to keep track of the time, instead of having to include a real-time clock in the circuit. The USB connector is only used for power. All of the mounting pieces were designed in OpenSCAD and printed on a 3D printer. Two servos control the drawing arms. A third servo can raise and lower the marker to the whiteboard. This also has the added benefit of being able to place the marker tip inside of an eraser head. That way the same two servos can also erase the writing.
The communication protocol for this systems is interesting. The transmitter shows up on [Maurice’s] PC as a modem. All he needs to do to update the time is “echo 12:00 > /dev/whiteboard”. In this case, the command is run by a cron job every 5 minutes. This makes it easy to tweak the rate at which the time updates on the whiteboard. All communication is done one-way. The drawing circuit will verify the checksum each time it receives a message. If the check fails, the circuit simply waits for another message. The computer transmits the message multiple times, just in case there is a problem during transmission.
We’re not quite to the 25th anniversary of the world wide web, but that doesn’t mean the greatest innovation in information distribution since [Gutenberg]’s press can’t be celebrated a bit early, does it? [Suhayl] is throwing some of his hardware into the ring, and loading up the first web page with a modem from the mid 1960s and a teletype from the mid 70s. No, no sane person would have ever done this 25 years ago, but it’s neat to watch in any event.
The hardware [Suhayl] is using includes a Livermore Data Systems modem. It’s a finely crafted wooden box with an acoustic coupler on top, and a DB-25 connector on a side that connects to a terminal or computer via RS-232. If that Livermore Data Systems acoustic coupler modem looks familiar, you might be right. This modem was demoed back in 2009 by [phreakmonkey]. It’s an impressive little box that can connect to a remote system at up to 300 baud.
The I/O is handled by an ASR-33 teletype. This was the standard way to connect to computers and mainframes before we were all blessed with video terminals and TV typewriters. The whole setup connects to a Unix system with a much more familiar Hayes modem, runs a text-only browser, and retrieves the first web page as it was served up at CERN some 25 years ago.
[psgarcha]’s modem/router comes straight from his internet provider, is on 24/7, and is built with the cheapest components imaginable. Eventually, this will be a problem and for [psgarcha], this problem manifested itself sooner than expected. Fortunately, there was a soldering iron handy.
The problems began with a boot loop – starting the router up, watching the blinking LEDs, and watching these lights follow the same pattern forever. Initially thinking this would be a problem with the firmware, [psgarcha] did the only thing he could do – take it apart. Inside, he found some bulging capacitors. Unsheathing his iron and replacing the obviously faulty components, [psgarcha] plugged the router in and had everything work. Great. Until those caps failed again a few months later.
There was obviously something wrong with the circuit, or wrong with the environment. Figuring it was hot out anyway, [psgarcha] replaced those caps again and added a fan and a small heatsink to the largest chip on the board. This should solve any overheating problems, but the real testing must be done in summer (or putting the router in a well-insulated enclosure). It’s an easy fix, a good reminder of exactly how often caps fail, and a great example of reducing the electronic cruft building up in landfills.