On January 3rd, 2009, the Genesis Block was created. This was the first entry on the Bitcoin blockchain. Because of the nature of Bitcoin, all transactions lead back to this block. This is where Bitcoin began, almost exactly ten years ago.
The Genesis Block was created by Satoshi, a person or persons we know nothing about. In the decade since, we’ve seen the astonishing rise and meteoric descent of Bitcoin, and then it happened again after the bubble was re-inflated.
Due to the nature of Bitcoins, blockchains, and ledgers, the entire history of Bitcoin has been recorded. Every coin spent and every satoshi scrupled has been recorded for all to see. It’s time for a retrospective, and not just because I wanted to see some art based on the covers of Now That’s What I Call Music albums. No, ten years is a lot of stories to tell.
There’s a new soap opera that I can’t stop watching. Actually, I wish I could change the channel but this is unfortunately happening in real life. It’s likely the ups and downs of drone sightings would be too far fetched for fiction anyway.
If you aren’t British, maybe you will know a little of our culture through the medium of television. We don’t all live in stately homes like Downton Abbey of course, instead we’re closer to the sometimes comedic sets, bad lighting, and ridiculously complicated lives of the residents of Coronation Street or of Albert Square in Eastenders that you may have flashed past late at night on a high-number channel.
Unfortunately it didn’t end there. We’re back once more to catch up with the latest events down on the tarmac, and come away with a fresh set of reasonable questions unanswered by the popular coverage of the matter.
We are somewhat spoiled because electronics today are very reliable compared to even a few decades ago. Most modern electronics obey the bathtub curve. If they don’t fail right away, they won’t fail for a very long time, in all likelihood. However, there are a few cases where that’s not a good enough answer. One is when something really important is at stake — the control systems of an airplane, for example. The other is when you are in an environment that might cause failures. In those cases — near a nuclear reactor or space, for example, you often are actually dealing with both problems. In this installment of Circuit VR, I’ll show you a few common ways to make digital logic circuits more robust with some examples you can run in the Falstad simulator in your browser.
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?
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.
