Sunrises and sunsets hardly ever disappoint. Still, it’s difficult to justify waking up early enough to catch one, or to stop what you’re doing in the evening just to watch the dying light. If there’s one good thing about CCTV cameras, it’s that some of them are positioned to catch a lovely view of one of the two, and a great many of them aren’t locked down at all.
I’ve always been fascinated by AI and machine learning. Google TensorFlow offers tutorials and has been on my ‘to-learn’ list since it was first released, although I always seem to neglect it in favor of the shiniest new embedded platform.
Last July, I took note when Intel released the Neural Compute Stick. It looked like an oversized USB stick, and acted as an accelerator for local AI applications, especially machine vision. I thought it was a pretty neat idea: it allowed me to test out AI applications on embedded systems at a power cost of about 1W. It requires pre-trained models, but there are enough of them available now to do some interesting things.
I wasn’t convinced I would get great performance out of it, and forgot about it until last November when they released an improved version. Unambiguously named the ‘Neural Compute Stick 2’ (NCS2), it was reasonably priced and promised a 6-8x performance increase over the last model, so I decided to give it a try to see how well it worked.
I took a few days off work around Christmas to set up Intel’s OpenVino Toolkit on my laptop. The installation script provided by Intel wasn’t particularly user-friendly, but it worked well enough and included several example applications I could use to test performance. I found that face detection was possible with my webcam in near real-time (something like 19 FPS), and pose detection at about 3 FPS. So in accordance with the holiday spirit, it knows when I am sleeping, and knows when I’m awake.
That was promising, but the NCS2 was marketed as allowing AI processing on edge computing devices. I set about installing it on the Raspberry Pi 3 Model B+ and compiling the application samples to see if it worked better than previous methods. This turned out to be more difficult than I expected, and the main goal of this article is to share the process I followed and save some of you a little frustration.
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.
Have you ever had one of those moments, when you’re rummaging through your spare parts heap, and have a rather bizarre project idea that you can’t quite get out of your head? You know, the ones that have no clear use, but simply demand to be born, of glass and steel and silicon?
This time, the stubborn idea in question was sort of like a solar-rechargeable LED throwie, but instead of a blinking light, it has a fully cloud-accessible embedded Linux server in the form of a Raspberry Pi 3 Model B+. Your choice of embedded Linux board should work — I just happen to have a lot of these due to a shipping error.
There were two main challenges here: First, it would have to combine the smallest practical combination of solar panel, power supply, and Li-ion cell that could run the Raspberry Pi. Second, we’ll need to remotely activate and access the Pi regardless of where it is, as well as be able to connect it to WiFi without direct physical access. In this article we’ll be dealing with the first set of problems — stay tuned for the rest.
Have you ever torn open an Ethernet jack? We’d bet the vast majority of readers — even the ones elbow-deep into the hardware world — will answer no. So we applaud the effort in this one, but the conclusion landed way off the mark.
In the last few days, a Tweet showing a Raspberry Pi with its Ethernet socket broken open suggested the little PCB inside it is a hidden bug. With more going on inside than one might expect, the conclusion of the person doing the teardown was that the Raspberry Pi foundation are spying upon us through our Ethernet traffic. That’s just not the case. But we’re still excited about what was found.
We’ve become used to software-defined radio as the future of radio experimentation, and many of us will have some form of SDR hardware. From the $10 RTL USB sticks through to all-singing, all-dancing models at eye-watering prices, there is an SDR for everyone.
What about the idea of an SDR without any external hardware? Instead of plugging something into your Raspberry Pi, how about using the Pi itself, unmodified? That’s just what the Nexmon SDR project has achieved, and this has been made possible through clever use of the on-board Broadcom 802.11ac WiFi chip. The result is a TX-capable SDR, albeit one only capable of operating within the 2.4 GHz and 5 GHz spectrum used by WiFi.
The team had previously worked extensively with the chipset in the Nexus 5 phone, and the SDR extension was first available on that platform. Then along came the Raspberry Pi 3 B+ with a similar-enough WiFi chipset that the same hack was portable to that platform, et voilá: WiFi SDR on a Pi 3 B+.
If you’ve not looked at the Pi 3 B+ we’d like to direct you to our review. If you don’t have a Nexus 5 kicking around, and you’d like to do some WiFi-band SDR work, it’s looking like an amazing deal.
The latest Raspberry Pi, the Pi 3 Model B+, is the most recent iteration of hardware from the Raspberry Pi Foundation. No, it doesn’t have eMMC, it doesn’t have support for cellular connectivity, it doesn’t have USB 3.0, it doesn’t have SATA, it doesn’t have PCIe, and it doesn’t have any of the other unrealistic expectations for a thirty-five dollar computer. That doesn’t mean there wasn’t a lot of engineering that went into this new version of the Pi; on the contrary — the latest Pi is filled with custom silicon, new technologies, and it even has a neat embossed RF shield.
On the Raspberry Pi blog, [James Adams] went over the work that went into what is probably the most significant part of the new Raspberry Pi. It has new, custom silicon in the power supply. This is a chip that was designed for the Raspberry Pi, and it’s a great lesson on what you can do when you know you’ll be making millions of a thing.
The first few generations of the Raspberry Pi, from the original Model B to the Zero, used on-chip power supplies. This is what you would expect when the RAM is soldered directly to the CPU. With the introduction of the Raspberry Pi 2, the RAM was decoupled from the CPU, and that meant providing more power for more cores, and the rails required for LPDDR2 memory. The Pi 2 required voltages of 5V, 3.3V, 1.8V, and 1.2V, and the sequencing to bring them all up in order. This is the job for a power management IC (PMIC), but surprisingly all the PMICs available were more expensive than the Pi 2’s discrete solution.
However, where there are semiconductor companies, there’s a possibility of having a custom chip made. [James] talked to [Peter Coyle] of Exar in 2015 (Exar was then bought by MaxLinear last year) about building a custom chip to supply all the voltages found in the Raspberry Pi. The result was the MXL7704, delivered just in time for the production of the Raspberry Pi 3B+.
The new chip takes the 5V in from the USB port and converts that to two 3.3V rails, 1.8V and 1.2V for the LPDDR2 memory, 1.2V nominal for the CPU, which can be raised and lowered via I2C. This is an impressive bit of engineering, and as any hardware designer knows, getting the power right is the first step to a successful product.
With the new MXL7704 chip found in the Raspberry Pi 3B+, the Pi ecosystem now has a simple and cheap chip for all their future revisions. It might not be SATA or PCIe or eMMC or a kitchen sink, but this is the kind of engineering that gives you a successful product rather than a single board computer that will be quickly forgotten.