The long-held dream of wireless network hackers everywhere is to dispense with centralised network infrastructure, and instead rely on a distributed network in which the clients perform the role of distribution and routing of traffic. These so-called mesh networks promise scalability and simplicity on paper, but are in practice never as easy to implement as the theory might suggest. Much venture capital has been burned over the years by startups chasing that particular dream, yet most of our wireless connectivity still follows a hub topology.
An exciting development in our sphere concerning mesh networking came in early 2018, when Particle, the purveyors of wireless-equipped dev boards, launched their third generation of products. These offered mesh networking alongside their other features, but this week they have announced that they’ll no longer be developing that particular side of their offering. The Wi-Fi-equipped Argon and Cellular-equipped Boron will remain on sale, but they will henceforth discontinue the mesh-only Xenon. Existing owners of the now orphaned board will be compensated with store credit.
Their rationale for discontinuing mesh networking is interesting, and reflects on the sentiment in our first paragraph. Mesh networking is hard, and in particular their attempt to make it work with zero configuration was simply not successful. But then they talk about the realisation that maybe mesh networking was not the right solution for the IoT applications the boards were being used in, and perhaps another technology such as LoRa would be more appropriate.
So the mesh experiment from Particle is over, but the company and its connected dev boards are very much still with us. We salute them for being bold enough to try it, and we wonder when we’ll next find a piece of similar mesh networking hardware.
With the release of TensorFlow Lite at Google I/O 2019, the accessible machine learning library is no longer limited to applications with access to GPUs. You can now run machine learning algorithms on microcontrollers much more easily, improving on-board inference and computation.
[Brandon Satrom] published a demo on how to run TFLite on Particle devices (tested on Photon, Argon, Boron, and Xenon) making it possible to make predictions on live data with pre-trained models. While some of the easier computation that occurs on MCUs requires manipulating data with existing equations (mapping analog inputs to a percentage range, for instance), many applications require understanding large, complex sets of sensor data gathered in real time. It’s often more difficult to get accurate results from a simple equation.
The current method is to train ML models on specialty hardware, deploy the models on cloud infrastructure, and backhaul sensor data to the cloud for inference. By running the inference and decision-making on-board, MCUs can simply take action without backhauling any data.
He starts off by constructing a simple TGLite model for MCU execution, using mean squared error for loss and stochastic gradient descent for the optimization. After training the model on sample data, you can save the model and convert it to a C array for the MCU. On the MCU, you can load the model, TFLite libraries, and operations resolver, as well as instantiate an interpreter and tensors. From there you invoke the model on the MCU and see your results!
Over the years we’ve seen several attempts at adding Internet connectivity to the lowly wired doorbell. Generally, these projects aim to piggyback on the existing wiring, bells, and buttons rather than replace them entirely. Which invariably means at some point the AC wiring is going to need to interface with a DC microcontroller. This is often where things get interesting, as it seems everyone has a different idea on how best to bridge these two systems.
That’s the point where [Ben Brooks] found himself not so long ago. While researching the best way to tap into the 20 VAC pumping through his doorbells, he found a forum post where somebody was experimenting with optocouplers. As is unfortunately so often the case, the forum thread never really had a conclusion, and it wasn’t clear if the original poster ever figured it out.
[Ben] liked the idea though, so he thought he would give it a shot. But before investing in real optocouplers, he created his own DIY versions to use as a proof of concept. He put a standard LED and photoresistor together with a bit of black tape, and connected the LED to the doorbell line with a resistor. Running the LED on 60 Hz AC meant it was flickering rapidly, but for the purposes of detecting if there was voltage on the line, it worked perfectly.
Wanting something slightly more professional for the final product, [Ben] eventually evolved his proof of concept to include a pair of 4N35s, a custom PCB, and a 3D printed enclosure. Powered by a Particle Xenon, the device uses IFTTT to fire off smartphone notifications and blink the lights in the house whenever somebody pushes the bell.
The idea here is pretty simple: use a remote temperature sensor to tell a fan located behind the fireplace when it’s time to kick on and start sharing some of that warmth with the rest of the house. But as usual, it ended up being a bit trickier than anticipated. For one, when [Ben] took a close look at the Vornado 660 fan he planned on using, he realized that its speed controller was “smart” enough that simply putting a relay on the AC line wouldn’t allow him to turn it on and off.
So he had to do some reverse engineering to figure out how the Sonix SN8P2501B microcontroller on the board was controlling the fan, and then wire the Photon directly to the pins on the chip that corresponded with the various physical controls. This allows the Photon to not only “push” the buttons to trigger the different speeds, but also read the controls to see if a human is trying to override the current setting.
For the remote side [Ben] is using a Particle Xenon, which is specifically designed for Internet of Things endpoints and sensor applications. Combined with a TMP36 temperature sensor and 3.7 V 500 mAh battery, this allowed him to easily put together a wireless remote thermometer that will publish the current temperature to the Photon’s mesh network at regular intervals.
Imagine what it must have been like for the first human to witness an aurora. It took a while for our species to migrate from its equatorial birthplace to latitudes where auroras are common, so it was a fairly recent event geologically speaking. Still, that first time seeing the shimmers and ribbons playing across a sky yet to be marred by light pollution must have been terrifying and thrilling, and like other displays of nature’s power, it probably fueled stories of gods and demons. The myths and legends born from ignorance of what an aurora actually represents seem quaint to most of us, but it was as good a model as our ancestors needed to explain the world around them.
Our understanding of auroras needs to be a lot deeper, though, because we now know that they are not only a beautiful atmospheric phenomenon but also a critical component in the colossal electromagnetic system formed by our planet and our star. Understanding how it works is key to everything from long-distance communication to keeping satellites in orbit to long-term weather predictions.
But how exactly does one study an aurora? Something that’s so out of reach and so evanescent seems like it would be hard to study. While it’s not exactly easy science to do, it is possible to directly study auroras, and it involves some interesting technology that actually changes them, somehow making the nocturnal light show even more beautiful.
Home brewing is a pastime that can be as much an art or a science as you make it, depending on your predilections. [Brandon Satrom] is one who leans very much towards the science side. There’s plenty that can be done to monitor and control a brew, and [Brandon] is one of many who have built custom hardware to help get the best possible results. Now, that hardware was due for an upgrade.
[Brandon]’s original BrewBuddy system relied on the Particle Photon, a useful platform that was nonetheless getting on in years. With the launch of the new Particle Argon, [Brandon] set his sights on new features that were possible with the added horsepower available. Graphics were added to the LCD screen, and a piezo sensor to detect the start of the fermentation process. This is in addition to the original temperature monitoring and plotting features of the first build.
The upgrade from one microcontroller platform to another can be fraught with headaches, but in this case, only minor changes were needed. 3 lines of code were changed to account for different pin assignments, and the rest fell neatly into place. It’s a testament to the compatibility of the Particle platforms that this upgrade was so easy.
The build relies on a Particle Photon to do the heavy lifting of connecting the door to the Internet. Particle offer a cloud service that makes setting up such a project easy for the first timer, and [Brad] was able to get things working quickly. A relay is used to activate the garage door remote button, as it was desired to leave the main control board of the garage door opener untouched. Reed switches are used to sense the position of the door, and [Brad] coded a state machine to ensure the door’s current state is always known.
It’s a simple project, but [Brad]’s use of state machine techniques and position sensing mean it’s less likely he’ll get home to find his garage open and his possessions missing. If you’re new to programming simple physical devices, you could take a page out of his logbook. Of course we’ve seen similar builds before, like this one from parts from the scrapbin.