Writing this in the frigid darkness of a Northern Hemisphere January evening, I have to admit to more than a little envy of Samy Kamkar and his friends. One of their summer events is a private party at a secluded campground somewhere that looks quite warm, which from here seems mighty attractive.
Samy wanted to provide a spectacle for his friends. What he came up with is glowing orbs; LED balloons that would float above the campsite and wow his friends with their pretty synchronised illumination. Thus an adventure in wireless communications, lighter-than-air flammable gasses versus electronics weight calculations, and code optimization began, the details of which were shared in Samy Kamkar’s 2018 Hackaday Superconference talk embedded below.
Designing circuit boards for high speed applications requires special considerations. This you already know, but what exactly do you need to do differently from common board layout? Building on where I left off discussing impedance in 2 layer Printed Circuit Board (PCB) designs, I wanted to start talking about high speed design techniques as they relate to PCBs. This is the world of multi-layer PCBs and where the impedance of both the Power Delivery Network (PDN) and the integrity of the signals themselves (Signal Integrity or SI) become very important factors.
I put together a few board designs to test out different situations that affect high speed signals. You’ve likely heard of vias and traces laid out at right angles having an impact. But have you considered how the glass fabric weave in the board itself impacts a design? In this video I grabbed some of my fanciest test equipment and put these design assumptions to the test. Have a look and then join me after the break for more details on what went into this!
Filesystems for computers are not the best bet for embedded systems. Even those who know this fragment of truth still fall into the trap and pay for it later on while surrounded by the rubble that once was a functioning project. Here’s how it happens.
The project starts small, with modest storage needs. It’s just a temperature logger and you want to store that data, so you stick on a little EEPROM. That works pretty well! But you need to store a little more data so the EEPROM gets paired with a small blob of NOR flash which is much larger but still pretty easy to work with. Device settings go to EEPROM, data logs go to NOR. That works for a time but then you remember that people on the Internet are all about the Internet of Things so it’s time to add WiFi. You start serving a few static pages with that surprisingly capable processor and bump into storage problems again so the NOR flash gets replaced with an SD card and now the logs go there too. Suddenly you’re dealing with multiple files and want access on a computer so a real filesystem is in order. FAT is easy, so the card grows a FAT filesystem. Everything is great, but you start to notice patches missing from the logs. Then the SD card gets totally corrupted. What’s going on? Let’s take a look at the problem, and how to reach embedded file nirvana.
The Moon is a desolate rock, completely incapable of harboring life as we know it. Despite being our closest celestial neighbor, conditions on the surface couldn’t be more different from the warm and wet world we call home. Variations in surface temperature are so extreme, from a blistering 106 C (223 F) during the lunar day to a frigid -183 C (-297 F) at night, that even robotic probes struggle to survive. The Moon’s atmosphere, if one is willing to call the wispy collection of oddball gasses including argon, helium, and neon at nearly negligible concentrations an atmosphere, does nothing to protect the lunar surface from being bombarded with cosmic radiation.
Von Kármán Crater
Yet for a brief time, very recently, life flourished on the Moon. Of course, it did have a little help. China’s Chang’e 4 lander, which made a historic touchdown in the Von Kármán crater on January 3rd, brought with it an experiment designed to test if plants could actually grow on the lunar surface. The device, known as the Lunar Micro Ecosystem (LME), contained air, soil, water, and a collection of seeds. When it received the appropriate signal, LME watered the seeds and carefully monitored their response. Not long after, Chinese media proudly announced that the cotton seeds within the LME had sprouted and were doing well.
Unfortunately, the success was exceptionally short-lived. Just a few days after announcing the success of the LME experiment, it was revealed that all the plants which sprouted had died. The timeline here is a bit hazy. It was not even immediately clear if the abrupt end of the LME experiment was intentional, or due to some hardware failure.
So what exactly do we know about Chang’e 4’s Lunar Micro Ecosystem, and the lifeforms it held? Why did the plants die? But perhaps most importantly, what does all this have to do with potential future human missions to that inhospitable rock floating just a few hundred thousand kilometers away from us?
Like many Victorian gentlemen of means, Richard Carrington did not need to sully himself with labor; instead, he turned his energies to the study of natural philosophy. It was the field of astronomy to which Carrington would apply himself, but unlike other gentlemen of similar inclination, he began his studies not as the sun set, but as it rose. Our star held great interest for Carrington, and what he saw on its face the morning of September 1, 1859, would astonish him. On that morning, as he sketched an unusual cluster of sunspots, the area erupted in a bright flash as an unfathomable amount of energy stored in the twisted ropes of the Sun’s magnetic field was released, propelling billions of tons of star-stuff on a collision course with Earth.
Carrington had witnessed a solar flare, and the consequent coronal mass ejection that would hit Earth just 17 hours later would result in a geomagnetic storm of such strength that it would be worldwide news the next day, and would bear his name into the future. The Carrington Event of 1859 was a glimpse of what our star is capable of under the right circumstances, the implications of which are sobering indeed given the web of delicate connections we’ve woven around and above the planet.
Let’s be honest, no one likes to see their program crash. It’s a clear sign that something is wrong with our code, and that’s a truth we don’t like to see. We try our best to avoid such a situation, and we’ve seen how compiler warnings and other static code analysis tools can help us to detect and prevent possible flaws in our code, which could otherwise lead to its demise. But what if I told you that crashing your program is actually a great way to improve its overall quality? Now, this obviously sounds a bit counterintuitive, after all we are talking about preventing our code from misbehaving, so why would we want to purposely break it?
Wandering around in an environment of ones and zeroes makes it easy to forget that reality is usually a lot less black and white. Yes, a program crash is bad — it hurts the ego, makes us look bad, and most of all, it is simply annoying. But is it really the worst that could happen? What if, say, some bad pointer handling doesn’t cause an instant segmentation fault, but instead happily introduces some garbage data to the system, widely opening the gates to virtually any outcome imaginable, from minor glitches to severe security vulnerabilities. Is this really a better option? And it doesn’t have to be pointers, or anything of C’s shortcomings in particular, we can end up with invalid data and unforeseen scenarios in virtually any language.
It doesn’t matter how often we hear that every piece of software is too complex to ever fully understand it, or how everything that can go wrong will go wrong. We are fully aware of all the wisdom and cliches, and completely ignore them or weasel our way out of it every time we put a /* this should never happen */ comment in our code.
So today, we are going to look into our options to deal with such unanticipated situations, how we can utilize a deliberate crash to improve our code in the future, and why the average error message is mostly useless.
For the last few years, the Last Great Hope™ of the consumer electronics industry has been voice assistants. Alexas and Echos and Google Homes and Facebook Portals are all the rage. Over one hundred million Alexa devices have been sold, an impressive feat given that there are only about 120 Million households in the United States, and a similar number in Europe. Look to your left, look to your right, one of you lives in a house with an Internet connected voice assistant.
2018 saw a huge explosion of Internet connected voice assistants, in sometimes bizarre form factors. There’s a voice controlled microwave, which is great if you’ve ever wanted to defrost a chicken through the Internet. You can get hardware for developing your own voice assistant device. 2019 will be even bigger. Facebook is heavily advertising the Facebook Portal. If you haven’t yet deleted your Facebook account, you can put the Facebook Portal on your kitchen counter and make video calls with your family and friends through Facebook Messenger. With the Google Home Hub and a Nest doorbell camera, you too can be just like Stu Pickles from Rugrats.
This is not the first time the world has been enamored with Internet-connected assistants. This is not the first time the consumer electronics industry put all their hope into one product category. This has happened before, and all those devices failed spectacularly. These were the Internet appliances released between 1999 and 2001: the last great hurrah of the dot-com boom. They were dumb then, and they’re dumb now.
