In a world of always-connected devices and 24/7 access to email and various social media and messaging platforms, it’s sometimes a good idea to take a step away from the hustle and bustle for peace of mind. But not too big of a step. After all, we sometimes need some limited contact with other humans, so that’s what [EverestX] set out to do with his modern, pocket-sized communication device based on pager technology from days of yore.

The device uses the POCSAG communications protocol, a current standard for pager communications that allows for an SMS-like experience for those still who still need (or want) to use pagers. [EverestX] was able to adapt some preexisting code and port it to an Atmel 32u4 microcontroller. With a custom PCB, small battery, an antenna, and some incredibly refined soldering skills, he was able to put together this build with an incredibly small footprint, slightly larger than a bottle cap.

Once added to a custom case, [EverestX] has an excellent platform for sending pager messages to all of his friends and can avoid any dreaded voice conversations. Pager hacks have been a favorite around these parts for years, and are still a viable option for modern communications needs despite also being a nostalgic relic of decades past. As an added bonus, the 32u4 microcontroller has some interesting non-pager features that you might want to check out as well.

Thanks to [ch0l0man] for the tip!

Somehow [hvde] wound up with a CB radio that does AM and SSB on the 11 meter band. The problem was that the radio isn’t legal where he lives. So he decided to change the radio over to work on the 6 meter band, instead.

We were a little surprised to hear this at first. Most radio circuits are tuned to pretty close tolerances and going from 27 MHz to 50 MHz seemed like quite a leap. The answer? An Arduino and a few other choice pieces of circuitry.

In particular, [hvde] removed much of the RF portion of the radio, leaving just the parts that dealt with the intermediate frequency at 7.8 MHz. Even the transmitter generates this frequency because it is easier to create an SSB signal at a fixed frequency. The Arduino drives a frequency synthesizer and an OLED display. A mixer combines the IF signal with the frequency the Arduino commands.

The radio had a “clarifier” which acts as a fine tuning control. With the new setup, the Arduino has to read this, also, and make small adjustments to the frequency. The RF circuits in the radio took some modifications, too. It is all documented, although we will admit this probably isn’t a project for the faint of heart.

As much as we admired this project, we think we will just stick with SDR. If you want to learn more about the digital synthesis of signals, check out [Bil Herd’s] post.

There’s something seriously wrong with the Arduino walkie-talkie that [GreatScott!] built.

The idea is simple: build a wireless intercom so a group of motor scooter riders can talk in real-time. Yes, such products exist commercially, but that’s no fun at all. With a little ingenuity and a well-stocked parts bin, such a device should be easy to build on the cheap, right?

Apparently not. [GreatScott!] went with an Arduino-based design, partly due to familiarity with the microcontroller but also because it made the RF part of the project seemingly easier due to cheap and easily available nRF24 2.4 GHz audio streaming modules. Everything seems straightforward enough on the breadboard – an op-amp to boost the signal from the condenser mic, a somewhat low but presumably usable 16 kHz sampling rate for the ADC. The radio modules linked up, but the audio quality was heavily distorted.

[GreatScott!] assumed that the rat’s nest of jumpers on the breadboard was to blame, so he jumped right to a PCB build. It’s a logical step, but it seems like it might be where he went wrong, because the PCB version was even worse. We’d perhaps have isolated the issue with the breadboard circuit first; did the distortion come from the audio stage? Or perhaps did the digitization inject some distortion? Or could the distortion be coming from the RF stage? We’d want to answer a few questions like that before jumping to a final design.

We love that [GreatScott!] has no issue with posting his failures – we’ve covered his suboptimal CPU handwarmer, and his 3D-printed BLDC motor stator was a flop too. It’s always nice to post mortem these things to avoid a similar fate.

[Dave Akerman]’s interest in high-altitude projects means he is no stranger to long-range wireless communications, for which LoRa is amazingly useful. LoRa is a method of transmitting at relatively low data rates with low power over long distances.

Despite LoRa’s long range, sometimes the transmissions of a device (like a balloon’s landed payload) cannot be received directly because it is too far away, or hidden behind buildings and geography. In these cases a useful solution is [Dave]’s self-contained LoRa repeater. The repeater hardware is simple, and [Dave] says that if one has the parts on hand, it can be built in about an hour.

The device simply re-transmits any telemetry packets it receives, and all that takes is an Arduino Mini Pro and a small LoRa module. A tiny DC-DC converter, battery, and battery charger rounds out the bill of materials to create a small and self-contained unit that can be raised up on a mast, flown on a kite, or carried by a drone.

The repeater’s frequency and other settings can even be reprogrammed (using a small windows program) for maximum flexibility, making the little device invaluable when going hunting for landed payloads like the one [Dave] used to re-create a famous NASA image using a plastic model and a high-altitude balloon. Check out the details on the GitHub repository for the project and start mashing “add to cart” for parts at your favorite reseller.

Potentially, one of the great things about having a device connected to the network is that you can update it remotely. However, how do you make that happen? If you use the Arduino setup for the ESP8266 or ESP32, you might try [scottchiefbaker’s] library which promises to make the process easy.

Adding it looks to be simple. You’ll need an include, of course. If you don’t mind using port 8080 and the path /webota, you only need to call handle_webota() from your main loop. If you want to change the defaults, you’ll need to add an extra call in your setup. You also need to set up a few global variables to specify your network parameters.

The only caveat is that long delay statements in your loop can block things from working and aren’t a great idea anyway. If you have them, you can replace all your delay calls with webota_delay which will stop the system from ignoring update requests.

The code started from a different online tutorial but packaged the code up nicely for reuse. To do an update, simply navigate to the device with a web browser and use the correct port number and path. From there you can upload a new binary image taken from the Arduino IDE with the export compiled binary command.

The only concern we saw was the code didn’t appear to authenticate you at all. That means anyone could load code into your ESP. That might be ok on a private network, but on the public Internet it is surely asking for trouble. The original tutorial code did have a hardcoded user and password, but it didn’t look very useful as the password was in the clear and didn’t stop you from uploading if you knew the right URL. Dropping it from the library probably makes sense, but we would want to build some kind of meaningful security into anything we deployed.

If you have a network connection, we’ve seen the same trick done with a normal Arduino with a wireless chip. You can even do it over WiFi but using an ESP8266 which you’ll then want to be able to update, too.

Sensor network projects often focus primarily on electronic design elements, such as architecture and wireless transmission methods for sensors and gateways. Equally important, however, are physical and practical design elements such as installation, usability, and maintainability. The SENSEation project by [Mario Frei] is a sensor network intended for use indoors in a variety of buildings, and it showcases the deep importance of physical design elements in order to create hardware that is easy to install, easy to maintain, and effective. The project logs have an excellent overview of past versions and an analysis of what worked well, and where they fell short.

One example is the power supply for the sensor nodes. Past designs used wall adapters to provide constant and reliable power, but there are practical considerations around doing so. Not only do power adapters mean each sensor requires some amount of cable management, but one never really knows what one will find when installing a node somewhere in a building; a power outlet may not be nearby, or it may not have any unoccupied sockets. [Mario] found that installations could take up to 45 minutes per node as a result of these issues. The solution was to move to battery power for the sensor nodes. With careful power management, a node can operate for almost a year before needing a recharge, and removing any cable management or power adapter meant that installation time dropped to an average of only seven minutes.

That’s just one example of the practical issues discovered in the deployment of a sensor network in a real-world situation, and the positive impact of some thoughtful design changes in response. The GitHub repository for SENSEation has all the details needed to reproduce the modular design, so check it out.

A few months back we first brought word of the progress being made in unlocking the SMART Response XE, an ATmega128RFA powered handheld computer that allowed teachers to create an interactive curriculum in the days before all the kids got Chromebooks. Featuring 2.4 Ghz wireless communication, a 384×160 LCD, and a full QWERTY keyboard, schools paid around $100 each for them 2010. Now selling for as little as $5 on eBay, these Arduino-compatible devices only need a little coaxing and an external programmer to get your own code running.

The previous post inspired [Larry Bank] to try his hand at hacking the SMART Response XE, and so far he’s made some very impressive progress. Not only has he come up with his own support library, but he’s also created a way to upload Arduino code to the devices through their integrated 802.15.4 radio. With his setup, you no longer need to open the SMART Response XE and attach a programmer, making it much easier to test and deploy software.

[Larry] has written up a very detailed account of his development process, and goes through the trouble of including his ideas that didn’t work. Getting reliable communication between two of these classroom gadgets proved a bit tricky, and it took a bit of circling around until he hit on a protocol that worked.

The trick is that you need to use one SMART Response XE attached to your computer as a “hub” to upload code to other XEs. But given how cheap they are this isn’t that big of a deal, especially considering the boost in productivity it will net you. [Larry] added a 5 x 2 female header to his “hub” XE so he could close the device back up, and also added a physical power switch. In the video after the break, you can see a demonstration of the setup sending a simple program to a nearby XE.

Between this wireless bootloader and the Arduboy compatibility covered previously, we’d suggest you get your SMART Response XE now. We wouldn’t be surprised if the prices of these things start going up like they did with the IM-ME.

Cheap second-hand hardware is usually a fertile ground for hacking, and it looks like these digital classroom aids are no exception. [is0-mick] writes in to tell us how he managed to hack one of these devices, a Smart Reponse XE, into an Arduboy compatible game system. As it turns out, this particular gadget is powered by an ATmega128RFA, which is essentially an Arduino-compatible AVR microcontroller with a 2.4GHz RF transceiver tacked on. This makes it an extremely interesting platform for hacking, especially since they are going for as little as $3 USD on eBay.

There’s no USB-Serial converter built into the Smart Response XE, so you’ll need to provide your own external programmer to flash the device. But luckily there’s a labeled ISP connector right on the board which makes it pretty straightforward to get everything wired up.

Of course, getting the hardware working was slightly more complicated than just flashing an Arduino Sketch onto the thing. [is0-mick] has provided his bootloader and modified libraries to get the device’s QWERTY keyboard and ST7586S controlled 384×160 LCD working.

Playing games is fun, but when his friend [en4rab] sent him the Smart Response XE to fiddle with, the goal was actually to turn them into cheap 2.4 GHz analyzers similar to what was done with the IM-ME. It seems they’re well on their way, and [is0-mick] invites anyone who might be interested in filling in some of the blanks on the RF side to get involved.

Some of the best hacks are the ones which seem perfectly obvious in hindsight; a solution to the problem that’s so elegant, you wonder how it never occurred to you before. Of course we also love the hacks that are so complex your eyes start to water, but it’s nice to have a balance. This one, sent in by [Eduardo Zola] is definitely in the former group.

In the video after the break, [Eduardo] demonstrates his extremely simple setup for using ultrasonic transducers for one-way data communication. Powered by a pair of Arduinos and using transducers salvaged from the extremely popular HC-SR04 module, there’s a good chance a lot of readers can recreate this one on their own bench with what they’ve got lying around. In this example he’s sending strings of text from one computer to another, but with a little imagination this can be used for all sorts of projects.

For the transmitter, the ultrasonic transducer is simply tied to one of the digital pins on the Arduino. The receiver is a bit more complex, requiring a LM386 amplifier and LM393 comparator to create a clean signal for the second Arduino to read.

But how does it work? Looking through the source code for the transmitter and receiver, we can see it’s about as basic as it gets. The transmitter Arduino breaks down a given string into individual characters, and then further converts the ASCII to eight binary bits. These bits are sent out as tones, and are picked up on the receiving end. Once the receiver has collected a decent chunk of tones, it works through them and turns the binary values back into ASCII characters which get dumped over serial. It’s slow, but it’s simple.

If you’re looking for something a bit more robust, check out this guide on using GNU Radio with ultrasonics.