Particle.io CEO Zach Supalla’s latest Atoms and Bits* newsletter issue analyzing “Hardware/Software Business Models” reminded me of many discussions I’ve had with organizations shifting between very different business models. The newsletter covered six different hardware-software business model mixes and the hardware-software offering implications of each business model.
What the newsletter issue didn’t cover, and I suspect will be a topic for a later issue, were the business and organizational implications for the organization attempting to switch from a hardware-centric business to a software-centric business (except for a quick “Going from a traditional hardware sale to a full subscription business model is a heavy lift”).
Tale as old as time (or at least not a new problem) Most of the companies or teams I’ve worked with in the past 20+ years had some mix of software in their predominantly hardware-driven business model (indeed, I’ve often been one the software folks at these hardware companies).
Most of these companies knew that software, media, and Cloud services could help drive more revenue. Though for most of them, revenue was really meant to be derived from hardware sales and software and services were just something to throw in to entice the hardware purchase.
But all of them spent some effort trying to understand how to use software and services, tied closely to their hardware, to generate new revenue or accelerate their current hardware-centric revenue streams. And I do recognize how they all flirted with one or more of the six business models Zach mentions in his newsletter.
Once a leopard… What I was most interested in exploring at these companies when they attempted to shift away from their hardware-centric business was to figure out how to do the shift and what it implied for how the company operated.
Zach hints at the challenge of the shift briefly at the end of the newsletter, talking about the need for a hybrid business model to “shift from purchase-heavy revenue to subscription-heavy revenue.”
Keep in mind, though, that a hardware-centric business model is built around discrete product design and manufacturing, embedded software engineering and UX, hardware design and supply-chain constraints, logistics, and unit and volume sales and commissions. From end to end, the whole company is built to design, make, and distribute atoms. And the marketing and sales are mentally and organizationally architected to serve the pushing of those atoms.
Moving into the bits world of software, Cloud, and services calls for a quite different way to design, make, and deploy. You can’t get hardware designers designing web services. You can’t get your embedded software engineers building your service back end. You have to shift your usual expenses spent on factories, machinery, components to servers and software which are priced and paid for in a different way. And you’ll need to figure out how to incentivize your sales teams, especially when software subscriptions can have a much lower cost than the average hardware sales your sales team is use to. Also, I’ll even claim that there might need to be a wholesale change in leadership – leadership with deep skill in hardware, might not be able to understand or take full advantage of any of the more software-flavored business models Zach describes.
Heavy lift, indeed Despite that, I still agree with Zach that there’s so much more value a hardware organization can unlock by folding in software. But I’ve seen first-hand that to get there the hardware-centric company needs to gain a whole new set of competencies, reconfigure the manufacturing and logistics flows, change how the company speaks and sells.
No, I don’t think it’s impossible. Just hard. And companies who are not paying attention or investing in the needed organizational shifts will end up failing, or, like some I worked for, vanishing.
Thoughts?
*I first heard the term ‘atoms and bits’ decades ago from Nick Negroponte of the MIT Media Lab. And I’ve always lived at the intersection of bits, atoms, and narratives. So I smiled when I saw that Zach chose to title his newsletter Atoms and Bits, especially as Particle.io adds more bits to their atom-based business.
In a previous post, I talked about how I worked on a vaccine fridge monitor that was designed to alert me over Pushover if anything was going on with the fridge. At the end of that post, I mentioned that I had received some kits for some contests – both of which were hefty multi-sensor boards.
Arduino Oplà While having alerts pushed to the phone and reading the temperature from a dashboard in the cloud could be considered sufficient, I wasn’t satisfied. When I saw the Arduino Oplà, I realized I could probably make it into a IoT display.
After reading about the Arduino Cloud and how easy it was to get a board online, I decided to buy an Arduino Nano 33 IoT to replace my D1 clone [reminder: the D1 served to send temp info over WiFi to a dashboard in the cloud, to save the Particle Boron from using up cellular bandwidth when there was no need to use cellular].
UART my friend While I was in the process of expanding this monitor, I added an Adafruit SD card reader to log alerts and data. I also realized that there was no reason to have two temperature probes (one for the D1 and one for the Boron), so I decided to connect whatever was the WiFi board to the Boron over UART (which is stooopidly easy – well, mostly because I did such data transfer before).
I mounted everything on a perfboard. The SD card reader and the Nano were powered from the Boron, with the catch that the Nano was powered from the VUSB, meaning it’s off when the power is out (because if the power is out, there isn’t any WiFi anyway).
Additionally, the Nano was connected to the Boron via UART. Periodically, the Boron writes out pertinent data (and alerts if they happen) to the SD card, and then sends the same data to the Nano, which then sends it to Arduino Cloud.
Arduino Cloud The Boron allows firmware update over the air, but I try not to do that much, as it consumes cellular data. But OTA update was helpful when I was tweaking some things after things were assembled.
On the Arduino Cloud side, provisioning the Oplà and Nano was quite pleasant – select your variables, fill in what happens when they change, upload the sketch. While trying to get the Arduino web editor to work over USB with my Mac was hit or miss, I was quite pleased with how easy it was to do OTA firmware updates over WiFi.* The only unpleasant surprise was I didn’t see that you can’t duplicate sketches in the web editor, almost losing a ton of code (I happened to have copied it out in a previous version).
Once in the Arduino Cloud, I could have the variable linked to another device (in my case the Oplà) that would respond to changes in the variables. And I could make a dashboard, as well.
Tying it all together I now have a temperature probe connected to a Particle Boron. The Boron is taking readings and writing them to an SD card log. I can query parameters from the Boron through the Particle Console.
The Boron has a battery back up and can also sense power state (USB or Battery) and will alert me of anything by push message to Pushover on my phone.
For the WiFi part, the Boron sends data to the Nano. The Arduino Cloud makes it easy to work with multiple variables, I am able to report temperature, battery level, contacts status, Boron connection to cloud status, and SD card free memory.**
Once the Nano receives the data from the Boron, all it has to do is update its own variables. These variables then change in the Arduino Cloud, and the Oplà, linked to the same variables, updates its own variables, showing them on its display.
What’s more, because this is a critical device connected over cellular and WiFi and logging data, I have put in quite a few checks and module re-initializations, to ensure that all the services and functions I’m using are healthy, robust, and available. Plus I can update the firmware over the air, if needed.
That’s the IoT dream.
Filling slots Ok, I will admit, part of picking five variables is because the Oplà has five buttons. I programmed the Oplà to always show temperature (see above). But if you press another button, it temporarily shows one of the other readings. Plus, if something goes wrong, the LED goes red and flashes the variable until things get back in range. Like a good display should.
In closing This has been an interesting project. And there was a significant degree of complexity, made easy by how the vendors themselves (with great communities) make it easy to program and provision their devices. I can see myself tweaking things more, but I think I’ll let this rest a while. Plus, my wife is tired of me talking about it. 😁
*Now I understand what Adafruit is doing with Whippersnapper – this is indeed the way IoT needs to go
**The connection to cloud status for the Boron is partly because it could disconnect and I’d never know. I was also concerned that I’d run out of SD memory and not know. But after writing the code to handle all of the SD free memory calculation, I realized that the amount of data I was writing will take forever to fill up the SD.
Everyone these days knows the importance of keeping vaccines safe and functional. This is the same, of course, with veterinary vaccines.
A local veterinarian I know stores all her vaccines in a special vaccine fridge at her home (she’s a mobile vet, so has no clinic). She asked me to create a monitor that can log the fridge temperature, alert her when the fridge is out of temperature range or out of power, and pass on any alarms from the fridge itself (there are exposed contacts for that).
Brainstorming I first wanted to see what was on the market.
An online search failed to uncover any fridge monitors that could easily send text message, log data to the cloud, or was easily programmable. For the most part, the fridge monitors I found were geared toward professional environments with a cost and operational profile very different from a home environment: built for local logging, alerts through building Ethernet or WiFi network (not useful if the power is out), and closed (can’t modify the code).
I knew I wanted the solution to be connected to a mobile network, battery-powered, use a temperature probe (there’s a hole in the side of the fridge specifically for that), be connected to the fridge’s alarm contacts (they were designed for someone to interface their own alarm system directly to the fridge), log temperature (locally on SD or over the air to a dB), and be connected to some text message service.
Something to look at I regularly look for dashboards I can send data to, such as Adafruit.io or Thingspeak. What’s interesting is that most IoT system vendors are focused on device management, not helping someone visualize their data. And IoT tools from folks like AWS and Google just seem too complicated to whip up a dashboard attached to a device. I ended up using Adafruit.io, but Thingspeak was pretty good as well. The rest of the ones I have seen cost more than I was willing to pay. And as I said, almost all IoT services that connect to devices aren’t geared toward visualizations or easily connecting to visualization tools. Really.
The design The Particle Boron comes with most of what I needed. It’s cellular-connected, so it doesn’t need a WiFi network to send data (Do you realize how many IoT boards are WiFi or Bluetooth only? How useful are those during power outages?). The Boron also has a battery connector and has easy code for you to know when the main power is out and it’s running on battery (bonus: it can tell you the battery level, too). The Feather format of the Boron also means there are a lot of pins for the temperature probe, wires, and SD card reader I was adding.
Therefore, the main use of the Boron is sensing temperature, logging to the SD, and issuing any alerts.
Wait, you may ask, what about sending data to the cloud?
As I was building this, I realized that using cellular to send temperature data or constant status messages was a waste of bandwidth (I must say my old Nokia-days frugal-data mind-set came back in force). So I decided to snag a cheap LOLIN D1 and temperature probe for a cheap, WiFi-based temperature reader, sending data to Adafruit.io. That data is really to just see how things are going. The logging by the Boron is the main data log, because it’ll still be able to do so under battery-only power.
About those alerts I spent a lot of time thinking of all the ways to get a notification. I thought of an Adafruit.io or IFTT kinda notification. I also looked at Twillio. And there were some hacks one could do to email a text message.
In the end, I stumbled upon Pushover, which integrates really simply (thank you, tutorials here and here) with the Particle system. I set up different levels of alerts, such as critical for power outages, silent for daily proof of life messages. And it works really well to alert me to changes in the system.
Leveling up I am so used to living in the Arduino and CircuitPython world of ample examples, easy programming tools, great set of libraries.
For the Particle, the libraries are the same or ported from Arduino. So there was familiarity there. But for me to program, I ended up using the VS Code-based SDK. There were some good first-use tutorials that helped me get a clue. But for sure it was all one step removed from my usual maker world. And, overall, developing for the Boron took a bit more effort on my part than my usual boards, partly due to less examples and community resources.
But the Particle system has some cool tricks, like being able to call a variable or function remotely over cellular from the device console in a browser. And there are some system health stats for when I want to know how the system is running. [That’s what most IoT providers offer – device management]
For me, learning a new SDK, doing local and over the air firmware updates, coding the board to return variable or run functions remotely all really leveled up my skills.
Where I’m at and where I’m going I’ve had the Boron running for a while. It’s been silent, mostly because no alerts are needed. And the D1 is streaming data points to Adafruit.io, so I can see how the fridge is behaving.
Moving forward, I’m not too keen on using two temperature probes. So I am thinking to use the D1 simply as a WiFi bridge, receiving data from the Boron via serial. That way, the Boron does all the work and then tells the D1 to upload the data to Adafruit.io.
Also, right now, while I’ve been prototyping, the whole set up is on a breadboard and in a zip case. I need to permanently bring all the parts together and put it all in a decent enclosure.
Yeah, feature requests never end.
Finally, we’d really like to figure out how to control a power switch to the fridge backup battery to ensure uninterrupted power.
But for now, I’m just excited to have an LTE board sending alerts to my phone to ensure that the fridge is taken care of. Now I really need to clean it all up.
And then something unexpected: Both Electromaker (with Nordic Semi) and Arduino are running contests around IoT, with free kit. I pitched this project to them, mostly because I didn’t think I would be awarded anything, but BOTH awarded me.
One project sends the Nordic Thingy 91, the other the Olpà IoT Kit. These boards are BEASTS – chock-full of sensors and functions – way overkill for a fridge sensor. And, in any case, they’d still both need a temperature probe for a fridge monitor, as one really wouldn’t place the whole board in the fridge, for various reasons.
While I pitched a fridge monitor, I feel a bit disappointed these guys are actually not well-suited for that. On the plus side, my brain is racing thinking how to use these multi-faceted devices.
One thing these devices taught me, tho, is they are really a multi-faceted dev platform. They have way too much to actually deploy anything with them. But that’s the point. Tho the Boron, also meant to be a ‘dev’ board, is priced and featured right that it can be the core of a deployed solution. As I am doing here.
In any case, look for more adventures in IoT as I figure out what to do with these two devices. 😁
[One more thing: Yes, you did notice that I have NO pics of the setup. Partly, because so much was happening in software and I wasn’t taking many pics. That’s not normal for me. I promise to do better next time.]
I thought I could add my voice to the folks sharing their wishes for CircuitPython in 2022.
Boards I like I was really pleased with how many boards came out last year that run CicruitPython, particularly those built on ESP32-S2 and RP2040.
For this year, the tease at the start of 2021 for a ESP32-TFT combo has finally turned into reality. Want. No, I have no idea what I am going to do with it. But it’s bonkers. That’s gotta be good, no?
And the recent Adafruit brain wave of different QtPys, especially those built on ESP32 (catching a theme?) have my head abuzz. Especially with the LiPo BFF-Sprinkle-Topping. I like smol, wireless, and battery-powered for lots of the things I mess with. But I’ve been usually going to a Feather S2 or TinyPICO, devices WAY overpowered and expensive for the things I usually do. Usually if I go for those, I want to GO BIG.
In any case, a QTPy ESP32 with LiPo feels like it changes these calculations. Let’s see.
Coding I love As for CircuitPython itself, I’m impressed with how many new features have showed up in the past year, such as deep sleeping and asyncio (so new!). For sure I will be exploring asyncio, as most of my projects have various things going on in parallel and I have to manually manage all that.
Looking forward There are a few areas that I struggled with CircuitPython, wanting it to do something and then having to turn to Arduino to do it.
UDP – alas, I had a project that used UDP that I just couldn’t get to work on CircuitPython. UDP is common in connected devices to send data to an endpoint without the chattiness of TCP. Alas, this isn’t a biggie for me in 2022, as I don’t think I’ll have a project with that.
So sleepy – this wish might have already been answered, but I want to see deep sleep spread to all the CircuitPython chips. In the small boards I use, they don’t have deep sleep (last I checked), only the hefty chips do. Tho, with the ESP32 line spreading to other formats, perhaps I won’t care the M0s are left out.
AudioIn – this one is the biggest for me at the moment. I have had many rounds using sound with various CircuitPython boards. Oh, CircuitPython might be great for MIDI, or for generating or mixing waveforms (yay, Winterbloom), or for playing snippets stored in memory or an SD card. But (and maybe it’s me) CircuitPython really isn’t designed for AudioIn, say, for recording someone and then doing something with it. Well, at least I’ve not had any luck trying to do that.
CircuitPython Audio Mixer – with that in mind, I would really be happy if we could design audio systems for CircuitPython like Teensy folks can do with the Audio System Design Tool. I’m trying really hard not to spring for a Teensy. But something like this could be really powerful, even if it were for the RasPi and a voice bonnet.
This AudioIn issue has been plaguing me in general, so it’s not a fault of CircuitPython. But, since we are making wishes, my biggest wish for 2022 is more AudioIN tools for CircuitPython.
Ok, so maybe part of the list above is just indicative of my skillz (or lack thereof). So, do let me know if you agree the list above needs to be added to CircuitPython, or if I just need to up my skills. 😁
Image shamelessly snagged from MasterTheHandpan (don’t judge, it’s the image I was looking for)
This is a chapter from a book I wrote during NanoWriMo 2011. The story was about folks who ‘shepherded’ marine mammals and fish (with the aid of dolphins, hence the dolphin reference below). Interspersed in the story were short chapters, interludes of unspecified origin – dreams? digressions? thoughts? This is one of them, pertinent to a recent, previous, post on technology, hence why I am sharing this now.
Pocket Universe
I was amazed by how fast nothing happened.
The sun hung for hours in the same spot, smiling from the clear blue sky, causing the raft to hum with vivid orangeness. The water gently lapped and rocked the raft, and the mild breeze took me in a direction I only had a vague idea might have been where I wanted to go.
I didn’t think of my dolphins, but I did, and wondered where they were. I’d been here so long, I no longer remembered why. All I could remember was that the sun hadn’t moved in a long time and my life vest chafed at my neck. And the overalls were hot too, their dark fabric absorbing the sun’s heat, almost burning.
I kept counting the seconds to 60 but kept forgetting to count how many times I’d gone around. I think time had run out of minutes, and I was stuck with just seconds. Each time I hit 60, I started back at 1, instead of marching on to 61 or 6001.
It must have something to do with the sun not wanting to budge from her spot.
I shifted a bit and I felt something in my pocket.
A pencil. Yellow. The standard hexagonal American kind with metal collar holding a red rubber eraser. The pencil was nice and factory sharp, with a bit of fine saw dust still around the grey graphite tip.
It was an amazing graphite tip.
I could almost see the atoms dancing on the tippy tip.
A pencil is made of many parts, and each part has its origin story. There’s the paint, print, metal ring, rubber eraser, wood case, and lead. Each one has its origin and use, and this simple yellow pencil is the product of complex material manipulations, chemistry, extrusions, cutting, mixing, rolling, sanding, painting, handling, wrapping, shipping, and moving until it’s an object to be fondled under a stationary sun in the middle of the Pacific.
ISN’T THAT JUST MIND-BLOWING? Never mind worrying if anyone will find me in the middle of nowhere, I have a PENCIL that is more amazing, Alyosha, than all of your philosophies. It’s the manifestation of the Universe all wrapped up and ready for a wee kid to doodle with. It’s the Universe hidden in the mundane. It’s the bloomin’ magical Universe, styoopid, and it’s right under your fat nose. And no need to invoke any higher power, neither. It’s a pencil. You and I can make one.
You’ll need a casing – fragrant cedar is my favorite – cut into slats from blocks and blocks of the finest wood, down to a small bed with a groove to intimately sandwich, hold, and enfold the pencil lead like a precious woman in her lover’s arms. And the lovers – casing and lead – are shot through a planning process that adds multiple facets to their relationship, in the case of the yellow object in my hand, six facets (Hm, what might those facets represent? – family, children, society, friends, work, death, money – no, that’s seven, are there seven-sided pencils? I digress.)
And then the polished and burnished pencil casing is painted and lacquered multiple times (sure would be less times if it weren’t mechanized) for children everywhere to ingest chips of while chewing, holding, handling these blessed, Universe-on-a-Stick, pencils.
Regarding pencil lead: There’s no lead in pencil lead. Pencil lead is made of graphite, made of the same stuff diamonds are, and fullerene, if you’re particular. Therefore, you didn’t get poisoned in school when you aggravated your friend and she poked you in anger and broke the lead tip in the palm of your hand. (OK, I, I didn’t get poisoned.)
The folks who are to blame for this misconception were, presumably, pre-Chemistry, when it was thought that graphite chunks looked a lot like lead. Though, I have more respect for ancient chemists than most and am pretty sure they could tell the difference – c’mon, lead is HEAVY.
But the pencil lead, I mean, pencil graphite is not pure graphite, but mixed with clay for different hardness and darkness. The mixture itself is ground and pressed into long cylinders and then kiln dried, carefully so as not to damage the lead. So next time a svelte boho artiste designer-type asks you if she makes you BBB or HHH, give her a knowing grin.
But we’re not done, you need to let the world know you made the pencil, and so with the lightest foil and hardest punch, you imprint whatever you darn well please on the side of that pencil, around it if you wish (it is you making the pencil, after all), and then send it off to get it’s crown of rubber and metal.
I looked up and the sun still had not moved. In protest, I tilted myself, just so that my shadow would take on a different angle. If the sun won’t move my shadow, then I will take full responsibility.
The sad thing is that this pencil is mass produced. Also, most of us only think of the “How they make it” part. But it’s much deeper than that.
Graphite is not just some soft carbon material used for steelmaking, brake linings, lubricants, or, of course, pencils. It’s a hexagonal crystal of dihexagonal dipyramidal symmetry. Crystalline symmetry! And it’s the most stable form of carbon, to boot (or is that, “to soot”?)
If I look closely at the pencil point, I see the mixing of the clay and graphite. Getting closer, I can see the phyllosilicates of the clay next to the dihexagonal dipyramidal of the graphite. And getting closer still I see – well, it’s really interesting what I see.
We’re so trained in the balls and stick model of atoms and molecules, but when I get down to this level, it’s really not the same. Each atom is a force field, filled with electrons (Carbon has six in three different orbitals – and no, I don’t mean electrons spinning around the nucleus like planets, but electrons spinning about on their axes moving about in a defined area, captured – argh, it’s really hard to explain sub-atomic wonders via macro-atomic imagery; that will make more sense as I push closer)
As I push farther, into all the shells, the orbitals, I can see the nucleus, a dense knot of protons and neutrons. These two defy explanation, as, to me, they are just bundles of energy. But I am not going to stop there; I’ll plow into a proton where there are even smaller tangles of energy – two up quarks and one down quark.
At this level, I find it meaningless to talk about elemental particles. They are just fluctuations in the fabric of the Universe, braille bumps that somehow are stable, join up into higher order structures, and higher, and higher – oh, I’m back at my pencil lead tip.
I look up. The sun still hasn’t moved. I’ve traversed the whole of Creation on a pencil and the sun doesn’t have the courtesy to move. This day will never end.
I can hear the photons taking their eight and a half minute journey from the surface of the sun, through space, to slam into my face, tripping photo sensors, causing a cascade of genes to produce melanin, making me feel happy, and setting my sleeping clock.
I can taste the blue of the sky, full of wispy water, neutral nitrogen, obnoxious oxygen, and a smattering of argon and carbon dioxide and a few other gasses. Mmm.
I am buoyed on the orangeness of my raft, its brightness a hand lifting me up, caressing me, protecting me from the water, gently rocking me to sleep.
Damn, that sun hasn’t moved. The nothing is happening faster than I can keep up with it.
I stumbled upon a brief rant on technology by Ursula LeGuin via The Prepared. Great stuff. Alas, I required a bit more than a tweet for me to riff off of it.
“Technology is the active human interface with the material world.” What I like about this rant is that it echoes my own view of what folks call ‘technology’. I often point out to tech-worshippers that a frakkin’ pencil is ‘technology.’ Indeed, you could write a while book on the pencil and cover so much about science and engineering and, yes, technology (well, I know I could (well, I did, sort of in a NaNoWriMo chapter)).
As LeGuin sorta says, it doesn’t have to be some LIDAR-carrying mobile phone with scratch-proof glass and precision machining and connects to dozen of satellites and can receive push messages from your Roomba when it rolls over your cat.
Clothing, dishes, toothpicks – they are all ‘technology’ – things we make to interact with our physical world.
Humans are inveterate technoweenies Usually the next thing I say after the pencil comment is, heck, even a chipped flint stone is technology. And humans have been making things (*cough* technology) for evah – IT DEFINES US. I have visions of cavehumans hanging around the fire in a deep discussion on the latest flint techniques and what Harg in the next village over did with that wicked deerhorn to chip the stone just right – just like we all hang around talking about hi-fi (d’oh, dating myself) mobile phones.
To hark back to LeGuin’s rant, it’s stupid to say her stories don’t have technology when technology is everywhere for any civilization (or even non-civilizations – go google about animal tool use).
Technology Finally, one related secret about my writing: I try not to use the word ‘technology’ at all (ok, so this post is messing up my score). This writing choice was inspired about 15 or more years ago by Ben Hammersly who was taking over some editorial duties at Wired and was going to ban ‘technology’ from everyone’s writing. Well, that’s how I remember it,* and how I was affected by it. And I’ve cut out a gazillion instances of the word ‘technology’ from my writing (and I’ve written a krapload in the past 15+ years).
Rant-triggered rant So, when I read LeGuin’s rant, I needed to riff off of hers and add mine – she’s so right, a damn pencil is technology; we have always been technoweenies; and don’t don’t don’t ever use THAT WORD again.
I feel better.
*One other item that stands out from that conversation with Ben: matte black magazine covers. I can’t unsee that. Thank you, Ben.
Image from Blick, purveyors of all sorts of fine pencils (and other stuff, too)
I’ve been posting these pauses for almost 17 years. They are meant to give folks a quick overview of where I am at, but when I look at them, they serve a good reminder of where I have been. And, wow, krazy how much change one can go through in 17 years.
Me Who am I? I’m Charlie Schick. I’m passionate about exploring how the intersection of bits and atoms help us tell stories of our physical-digital-sublime world. Indeed, one story I’ve lately been trying hard to explore is how we use physical constructs to connect to the sublime.
I also advise companies on product design, client engagement strategies, and new market opportunities. I’m a recovering PhD, too, and proudly ex-IBM, -Boston Children’s, -Nokia.
By day I just started (December 2021) a new role as VP of Marketing for Quartic.ai, helping the small startup grow into the leader in industrial AI we know we are. I am excited to be back into the world of AI and pharma and know that 2022 and beyond will be kick-ass.
By night A most amazing development in the past few years is my journey into embedded electronics, 3D printing, and making in general. I know I will be doing more in 2022 and that the modest superpowers I have gained in the past year will be dwarfed by the superpowers I expect to gain in the coming one. Oh, the places we’ll go.
Because I can’t stop For a very long time, I’ve been sharing my experience, insights, and exploits, especially through writing for and speaking to large audiences and engaging with others in stimulating conversations, including the office of CxOs. With my new role, I expect things kick up again in this space. Let me know how I can help in this capacity.
And of course, my standard disclaimer (my usual riff off of an ancient Cringely disclaimer) Everything I write here on this site is an expression of my own opinions, NOT of any of my clients or anyone I work for, especially Quartic. If these were the opinions of my clients or Quartic, the site would be under their name and, for sure, the writing and design would be much more professional. Likewise, I am an intensely trained professional writer 😛, so don’t expect to find any confidential secret corporate mumbo-jumbo being revealed here.
If you have ideas or projects that you think I might be interested in, please contact me, Charlie Schick, at firstname.lastname@molecularist.com or via my profile on LinkedIn.
Yes, you can find me on Twitter. I use it more to follow an amazing community of makers, to be marveled by their creativity, commentary, and caring; though, do say ‘hi’ if you swing by.
Image from a project of mine using a microcontroller to explore death and deathlessness
Many decades ago, my mother bought my father a Tissot Seastar Seven. A very simple watch, which also has its own pendulum to keep it wound as the wearer moves about. I used to use it a lot. And it had an activity tracker sort of vibe: if I spent most of the day sitting around, the watch would eventually stop.
Alas, the crown was damaged and I didn’t use it for many years. But after my father passed away, late last year, I thought I’d get it fixed, in his honor. I knew the watch would have to compete with my daily wearing of my Apple Watch, so I knew I’d want to get some sort of watch winder, so that it would keep time and be ready to wear when needed.
This wouldn’t be my first watch winder, nor the last. I had built a watch winder for my For All Time project. And my father left another, fancy, watch, also a self-winder, for my kids, so I felt that there would be yet another watch that would need a watch winder.
Spinning in a fancy way I didn’t want some boring spinner like I had to use in my For All Time project. I had seen some gyro watch winders that were really cool. After some research, I found this one by Bruno Esgulian. And I’d seen many versions to get some thoughts on the color pattern.
So I bought the model from Bruno and the parts on the list that I didn’t have and got printing the whole set up in black and transparent blue PETG.
No so fast The buttons I got didn’t fit into the hole in the original model, leading to some funny attempts by me to fit it and ruining one of the two buttons that came (I had bought a 2-pack because I eventually was going to build a second winder, right?).
I had to modify the model to enlarge the hole a tad and print it again. And that worked.
An aside: I don’t know about you, but I regularly do test prints of specific sections of my models so I don’t print a whole model and potentially waste time and materials. On the right, I printed just the section of the base that had the modified button hole.
The second modification was the code. I wasn’t too enthused with the code that the maker was offering, so I made my own from scratch (well, not from scratch, I was reusing some code from the For All Time project, so I knew what I wanted and what to do).
A third modification was the power cable. I wanted to be able to power it, switch it off from the button on front for when I’m using the watch, and still be able to program the winder in case I had to change a parameter.
For that, I did some careful surgery on a USB cable, breaking out the power to be controlled by the button and keeping the data wires intact. Worked really well.
Drifting One thing with winders is that you need to find the right amount of rotations so as to not overwind or underwind, which show up as the watch getting ahead or behind the time, respectively.
But as I was tweaking how many rotations per hour, I noticed that the stepper, not so accurate (there’s a reason the library is call “Cheap Stepper”), was slowly drifting out of true at the end of the rotations (that is, not returning to home, off by a bit each rotation).
Not aesthetically pleasing. So I needed to design a homing mechanism.
I made a modified spinning arm with a place for a magnet (image right), and used a reed switch to sense homing (and borrowed the homing code from my For All Time project). Worked like a charm, and the gyro is now always spot on.
With that, I was able to tweak the rotations, and now the watch is always wound and keeping time, ready for me to wear.
In the end, what I thought was going to be a straightforward build, turned out to require a bit of ingenuity and modification to get it to work just how I wanted.
The image to the right shows lots of the parts that went into the base. The heart is an Arduino Nano. Then there’s a cheap stepper motor and driver, you can see the blue wires of the reed switch go between the button and the motor. And there’s a nifty power button that is on-off and glows blue when on. One other thing: as the blue covers were translucent, I pointed the Nano and the stepper driver downwards, so as not to shine their LEDs up through the top cover.
[BTW, the sharp-eyed might notice that I have the USB cable coming out the top of the base instead of the bottom. Yes, for some reason, I usually end up assembling things backwards or having to repeatedly disassemble for some stupid reason. Rest assured, all is good in the final version.]
All that jazz One of the great things about making is not just all the projects out there that you can download and build. The great thing is that there is always room for tweaking, re-purposing, or modifying to fit your needs. Indeed, many of my projects are exactly that – just look at some of the projects from this challenge.
The process feels like one big jazz jam session – everyone riffing off others, weaving in their own voice, making something new and surprising.
You don’t need to follow the project to the letter, nor do you have to do it all yourself. Just go out there, find something you like, build from there, and join the jam.
The Death and Deathlessness* project was my exploration of life, death, and immortality. EEPROMs, the permanent memory in some chips, have finite life for writing. I had seen examples of folks killing EEPROMs, basically repeatedly reading and writing until they encountered an error, a failure for the address in the EEPROM to correctly take a write. I therefore thought running down an EERPOM to the last failure would be the equivalent of death. And recording it for playback would be like immortality – or would that still be life?
As I was building the project, I realized there were a few questions I could not find answers for. For sure, folks had shown that ATmega or ATtiny EERPOMs actually can be faithfully read and written way more than the 100k cycles the manufacturer guarantees. But everyone stopped their experiments at first failure.
I wanted to know if when an address failed, was it the whole address or was it the whole EEPROM? It felt like it was the whole address, as I’ve heard that folks would stop using that failed address. Though, if an address failed, did it stay failed? And if it stayed failed, would other addresses also start failing until the whole EEPROM had failed? And because I was writing then immediately reading, would the fail be harder to find? That is, my failure test required failure right after a write. What if failure after 100k cycles really was related to long-term stability of the address, which I’d never see, or which is why folks could hit 1M or 2M quick read-write cycles before seeing a failure?
Well, since I was going to run this EEPROM down, I realized that I would be able to answer some of these questions.
When the whole thing started
Some parameters I was using an ATtiny45, which has 256 bytes of EEPROM. I was only using the first 128 addresses (because my readout was an LED matrix with 128 pixels). For each byte I alternated writing 240 (binary 11110000) and 15 (binary 00001111), meaning all the bits alternated each cycle. I read the value after every write to see if it retained the expected written byte.
My first try blew past 2M cycles with no errors showing, so, in disbelief, I stopped to check my code. It was good. So I got a fresh chip and started another experiment, and with extreme self-control, let the damn thing run for what felt like forever, without watching it.
Errors! Addresses 25, 33 and 115. Image from day 28.
And then I saw an error. And some interesting behavior. After a few days, and some more interesting behavior, I stopped the experiment.
There was a challenge handling a CSV file with 4.9M rows, but I was able to see that the experiment did about 3.7M cycles, throwing about 1.2M errors.
And now for something completely different The addresses that failed would only show a failure every other cycle. That’s the first insight: failure is at the BIT level, not the BYTE level, such that when it wrote and read a number, it would fail, and when it wrote and read the next one (all different bits), it would read fine. For example, address 33 always failed on the odd cycles, while address 41 only failed on the even cycles.
Bit-level failure (morning of day 29)
Crazier still, while a failed address would fail consistently for a long stretch, it would then NOT fail for a long stretch, too. Indeed, I saw other failed addresses, also showing the alternating of fail and succeed, pop up and then not show up for a long time. For example, 33 is first to fail at cycle 666,517; and it fails 263,318 times in the subsequent 3,004,848 cycles.
I did a histogram and saw that only 29 addresses had ever failed. Address 33 was the address with the most failures. But address 34 fails 3 times (adjacent odd cycles 3,440,911; -913; -915) and then never again (that’s for the remaining 231k cycles before I turned it off).
Long stretches no errors (evening of day 29)
This failing for stretches and then not failing suggests to me that this is a probabilistic fail rather than a catastrophic terminal fail. Think of it as the bit has an issue holding a charge (probabilistic) rather than no longer holds a charge (catastrophic fail). So it can go long stretches when its probability of holding a charge improves, until the probability gets bad again.
Of course, for the manufacturer and anyone looking to depend on the EEPROM, stepping into that probabilistic failure might as well be a terminal failure as it makes that whole address useless. As for me, who thought that perhaps the whole address would fail, or that at least when a bit failed, the address would stay failed, this probabilistic nature basically killed the nature of my project.
Yup.
I could do a bit more statistical digging into the data, but I don’t really have that skill, or the right toolset. Nonetheless, what I can figure out is that the condition where EVERY address fails is likely impossible (or way longer than I am willing to wait – tho I am tempted).
Below is a link to the CSV is you’re interested in checking this out. The columns are Cycle, Address, Result (0 for failure). For my own logging and for the LED matrix output, I wrote out a row for every cycle. But, to save space and speed things up, I only wrote out Address and Result when there was a failure.
Please note, I share the original so I can avoid inadvertently introducing something in editing. There was some writing artefact that added a null row after every error (about 1.2M – sorry). And there’s some gibberish before the first cycle you need to delete. I suppose I could revisit the logging code.
Summary I had wondered a few things about how EERPOMs fail. I wondered if when one bit failed, the whole EEPROM failed. That’s not the case. Also, I couldn’t find anything that suggested if errors were at bit or byte level. I now know that they are at the bit level. I also wasn’t sure if a failure was terminal. Turns out failures are probabilistic, so an address can function properly after having failed numerous times. Also, that means that I likely would never be able to kill off a whole EEPROM, where ALL the addresses fail on EVERY read and write cycle.
In the end, what I thought would be an achievable and straightforward running down of an EEPROM, turned into an interesting revelation of resilience for the wee chip.
You’d think everything there is to know of ATtiny or ATmega EEPROM failure is known. Well, perhaps not (or maybe I just couldn’t find the answers to my questions). In any case, my Death and Deathlessness project did teach me many interesting things about EEPROM failure.
Do these finding jive with the EEPROM behavior you’ve seen?
*Deathlessness is a key concept in the Lord of the Rings. I even wrote a short story on it in college, as extra credit, that the prof read out in class, to my embarrassment. In any case, when the movies came out, I had a chance to teach my kids how deathlessness was a key thread throughout JRRT’s stories of Middle Earth.
I recently completed the final project of my year-long challenge to make a project a month from 15jul20 to 15jul21. This marks the end of my second year of making, counted from when I had to do a project for work and resurrected a Arduino Uno I had in the closet for 10 years (I never figured it out the first time). And by making I mean chips, circuits, PCBs, 3D printing, and the like [I’ve always been creative making and designing things, but not the level of these past two years (sort of)]
Anyway, I chose the challenge as a constraint – both to hold me to making 12 projects, and to time constrain things so that things just had to get done.
Well, things were not that simple.
Life intrudes Before I list the projects I did and provide some commentary, I will admit that I did not keep to the schedule of constraining the projects from the 15th of one month to the 15th of the next. Already with the second project, timelines slipped. And then a death in the family (my father) had me skip two months – yeah, I had other things to focus on – and was subsequently affecting the amount of time I had during the rest of challenge period. Some months I would go a week or two not touching a single project.
At the same time, the projects kept me going after my father passed, and also engaged my mother (she’s a long-time maker, very creative and totally grokking what I do, providing great advice on project design – really). So while on the one hand parts of our lives were up-ended, the projects also helped us move on after the up-ending.
But none of this is any excuse. The whole part of a challenge such as this one is to provide concrete achievable goals, constraints, and urgency. Arising from that, we learn about ourselves, our materials, and our limits.
Gaming life For every project, I was trying to insert some meaning, or trying to make a concept tangible. Not sure I hit the mark each time, but the intent was there.
My first project was the Multi-mode Game of Life. This one was meant to show aspects of contagion (it was the Summer of Covid) and #BLM. As a bonus, I whipped up a Game of Life: Contagion Mode, Rose Garden Massacre Edition, inspired by the disastrous super-spreader event during the nomination of the last Supreme Court Justice.
Slowing down time Next came Seeing Thru Time, inspired by the closeness of Jupiter, Saturn, and the 4th of July full Moon last summer (the three, including a full Moon, were up again last night, tho not as close). The goal was to show how long it takes for light to go from the Sun to these celestial bodies and then back to Earth. I thought it was cool, even if most people didn’t. For me at least, this was the first one to hint at the sublime – awakening a sense of fearsome wonder for the universe.
The funny thing is that I really don’t have anywhere to put it, so this project has inspired me to rearrange my workshop for more permanent installations.
Spooky After that, I wanted to do something for Halloween, perhaps something scary that I could hang for trick-or-treaters. And being a bio-geek, I knew I wanted to do a virus.
For this project I knew I wanted to dodecahedron or icosahedron. And fed by a ton of LEDs and resistors I had lying around, I made a spiky model with animated LEDs (over 60!).
Quite fun.
Pausing And then my dad died. There was only so much attention I could give while I dealt with the aftermath, I ended up skipping the next two months of projects. Indeed, those two months were actually planned to be a two-part project around book making. The first month was supposed to be print making, the second 3D printing a book. I had just started the test prints. But really, I could tell that my mind wasn’t up to working on the projects. There’s only so much attention one has, and my mother and family definitely took precedence.
Picking up on the next measure That pause took me to mid-December, ready to start what would have been the sixth project, but was now the fourth. This one came out of a zany idea that someone with one watch knows the time, but someone with, uh, five, is never sure. The idea (“For All Time”) was to set up different timepieces and watch the times deviate.
This was an elaborate project, forced me to up my skills in Fusion 360, work with stepper motors for the first time, and fill every single pin possible in my TinyPICO. I was also pleased to see the project get called out in the Adafruit Blog (*blush*).
Alas, everything worked well except the stepper motor. That is, the holder for the stepper motor failed, so the whole winding mechanism was useless (for the bottom middle watch). And then I ran out of time to make it better.
One thing I haven’t said until now is that one of the watches was my father’s (the one with the white face), that I took off him when they took him away. So, one thing I want to do, now that the challenge is over, is go back and fix the winding mechanism and get this contraption turned on again.
Being cheeky The watch project was to show that time could seem arbitrary. Serious stuff. In contrast, the next project was all cheek.
Early this year, COVID vaccines were all the rage (not sure why they no longer are, considering). My extended family members were all getting their Fauci Ouchys. Therefore, I wanted to make a range of blinkybadges for them to proclaim their vaccinated state.
Alas, I only made one of the designs. Though I did learn heaps from the process – new chip, my own artwork, hot air gun soldering of SMT – among other things.
A quite interesting project My father was old, and in those final years I was thinking a lot about death, dying, and immortality. I was also thinking how I could express such concepts in a tangible way. What I came up with was recording the life of an EEPROM as it dies.
The project was called “Death and Deathlessness“, a saying out of the Lord of the Rings (indeed, in college, I wrote a short story on the topic). Deathlessness, rather than immortality, was a key concept in the LotR.
The project, inspired by others who would take an EEPROM to first failure, was to take every address on the EERPOM to failure, record it on the way, and the replay it. My first question was if the replaying was life, or what, if it was the exact same as the life of the EEPROM.
Truth is stranger than fiction. The damned thing ran so long before the first failure that I kept verifying if the code was right (it was). I’m not going to say more here as I did some forensics I want to share in a separate post. Interesting stuff.
Pretty pictures End of April, we were heading to graduation season. Me, in all my wisdom, decided to make something image-based for graduations in the family. I recalled lithophanes and found a really helpful website for me to create the files to use in 3D printing.
This project was really fun, the 3D printer working long hours every day. And this projects is one of the rare ones my family has asked for more. Tho, I realized when the lithophanes were done, that the graduates wouldn’t want a photo of themselves, so I gave the framed lithophanes to their mothers. Haha.
I have a few frames left over so will definitely get back to these to make more, especially to complete the one of my mom holding my dad’s hand, shown here.
Another unfinished project The next one was one I had been pondering since I first thought of the challenge: “what does Dignity look like?” And throughout the year, I was nowhere near getting that answer, until one day it clicked. Alas, in the time I had, I was able to work on the electronics and the code, but got bogged down with the enclosure, which is instrumental to delivering the experience.
I’m not going to say more here, as I will be going back to this one, as this one is important to me.
Blinkenbugs One other project that I was excited to get to, but that had to wait for the start of Summer, was around fireflies. The original project concept was some funky Boldport artsy freeform and PCB type creation that could simulate firefly flashes. But due to time, travels, and the chipocaplypse, I instead decided to use mostly what I had already.
Soon after I wrote the post on the project, I did manage to attract some fireflies. Quite thrilling. But more importantly, the project had me (and at times, other family members) out most nights, marveling at nature’s light show (that fearsome wonder of nature, again).
Tree of Life After that, I reached the final project, the Tree of Life. Not to be just some lit up image, I decided to add a twist, a twist that I hope makes one think of what dementia looks like.
Also, it just is one wicked beautiful build. Which got me thinking: the 3D model was purchased and I riffed off of it (multi-color, mounted, animated). At first I felt awkward mentioning where I got the model (folks would go ‘wow’ and I quickly let them know it wasn’t me who did the model). But then I realized that remixing things is OK, kinda like with my COVID decoration (also a purchased and modified model).
Indeed, if there’s one big thread through my past year is that so much of what I made is based on the genius of others and I’m just a humble remixer, seeing new ways to bring all those bits and bobs together into something that means something to me, and hopefully to others. While the challenge forced me to go in and out of projects quickly, it also taught me a wide range of skills that I can now go more deeply into for fuller materialized ideas.
Yeah, that kinda suggests what the next year will be like, haha.
