This post talks about my past few years of work doing hardware consulting and realizing just how many clients are looking for help building IoT projects. I’d like to offer more services to that segment of customers, so I need to take on more skills. In the process, I joined a startup that enables people just like me.
Some of the content of this article was also discussed on my podcast The Amp Hour, on episode 569
When we last left off…
The last time I did a career post on my blog, I wrote about how I would be “Redirecting Beams”. That was really an announcement about how I was going to work for Hologram, a cellular MVNO. I was super excited about getting to work on hardware and interacting directly with developers. I was less enthused when Hologram stopped making embedded hardware.
While I still like and use the cellular service that Hologram provides, I politely declined to continue working with them. After stating I was happiest when I was doing hands-on electronics design, my then-girlfriend thought aloud “Hey, maybe you should try to do that all the time. Isn’t that what consultants do?”. I have been doing hardware consulting for industrial and commercial clients ever since via my company, Analog Life LLC. I have also married that wonderful woman, you don’t let that kind of insight go.
What a wonderful and unexpected gift that has been. Moving into hardware consulting felt similar to my experience early in my career: being overwhelmed with all the things I had to learn and then realizing the patterns and pitfalls of design. I was stronger than I remembered. I could do this. I got out of my head and started to enjoy the process. I continued to find work and clients that needed help getting things out into the world.
Down at the hardware level
I love building electronics. I was lucky enough to find clients with interesting problems where I got to design circuit boards on a regular basis. But I realized I needed a large slate of clients to keep me busy, not just one large client. Why?
I normally refer to hardware work as “choppy”. Unlike past jobs at large corporations, small consulting clients don’t need circuit boards built, tested, debugged, and redesigned over and over again. If I’m doing my work correctly, I am not needed after the beginning of the design cycle. Iteration happens after we wring out all of the bugs, including on the firmware and software.
Moving up to firmware
I like making money and billing hours…so why not try to take on more of the work? I decided to start “moving up the stack”, not just designing hardware, but also offering firmware design services to customers. To ensure I was offering a good product, I started hiring tutors, learning more of the firmware side of things, and offering to take on that part of consulting projects for my clients. Not every project was a good fit, if they had very specific or difficult firmware needs. But some of the firmware projects were simple implementations and I was able to use unbilled time and hired help for tough portions of the code in order to deliver at least a proof-of-concept.
If I really wanted to learn how to do all of the firmware work, I should take on the risk of being the end client. An added benefit is I could talk about every aspect of it on The Amp Hour or on the newly launched Contextual Electronics Podcast. This time lined up with the start of the COVID lockdowns, so I took the leap and started the Advanced BLE-CELL (ABC) board for Contextual Electronics.
I started with what I knew: the hardware. I recorded a video per day on a design that had been in my head, based on client requests. It would be a template for various industrial companies wanting to create low-cost, bespoke cellular projects. I would have not only a cellular modem (BG95), but also a low cost and popular Bluetooth SOC onboard (nRF52840).
6 months later, I had a slate of videos for people to watch of me going through the entire process from concept all the way through writing firmware to get the first blinking LED on board. But…what about connecting this thing to the internet?
Building products, not just boards
A quick aside: A couple of years back, a mechanical engineer sent me a DM about wanting to design a Bluetooth-based widget for his shop. He asked if I could teach him how to build one. I explained that I could teach him many aspects of electronics: how an LED worked, which components to choose, how to layout a circuit board that contained a Bluetooth module or SOC. Building an entire product was out of the scope for Contextual Electronics. He politely declined and moved on to build one with a development shop. As I thought about his request and the required skills, I realized I also required this training: it was out of the scope of things I would be capable of doing on my own. I always assumed I would be working on a team that would have a firmware engineer or that I could hire one for a consulting job.
Since I didn’t yet have the capabilities to build the entire system, I hired someone to help me build the ABC system. I wanted to move the project forward, so I decided to hire someone from Upwork. Not only to develop some of the firmware but to teach me in the process (that was part of the job listing).
I also wanted to learn about Real-Time Operating Systems (RTOS), so I included that in the job requirement. An RTOS would enable networking, more precisely controlled operations on microcontrollers, and simplify scheduling of tasks as more was asked of the device. Asking around, I kept hearing about the Zephyr Project, which was a cross-platform, open-source RTOS. I had another client who was also using Zephyr, so after some preliminary research, I chose that for the ABC board.
I hired a firmware engineer named Bilal to write firmware and show me the ropes of Zephyr. He wrote a driver for the cellular modem on the ABC board in Zephyr that we ended up contributing back to the project (pushing upstream). Bilal was a great teacher and we recorded some videos together about the process.
Moving up to the network (IoT) level
Looking at my consulting projects, I realized almost all of them involved adding connectivity to older projects or creating new projects that also have connectivity. What’s more, I had placed myself the same position some of my clients were in. I have a device, I have hired someone to build me hardware and firmware. What do we do with the data being generated from the device? I started looking for options for connecting things to the internet and handling network traffic.
Once again I would need to learn how to to “move up the stack”. It’s not enough to have firmware and hardware designed to communicate from the ABC board. If I wanted to take on more of this project and future IoT projects, I would have to learn how to write software on the receiving side (the internet). Bilal got the project to the point where it was sending MQTT messages (a messaging protocol) over cellular to a test server, but now what?
It was around this time that I got in touch with a friend who lived in the Bay Area. Jonathan had been working at companies like Particle, Google Nest, WeWork, and we chatted about his new startup idea. I mentioned my work with Bilal on Zephyr and he mentioned how his new company was working on a potential solution. I asked Jonathan to come on The Amp Hour in a few months’ time to talk about the startup. He was still in “stealth” mode, so instead, we chatted more generally about what makes IoT difficult. We were not short on topics. I complained about the hardware aspects and the opaqueness of what happens to data after it leaves the device. He mentioned the structural problems of being locked into cloud providers and developing vertically integrated solutions. Embedded devices like the ABC board require such specific architecture to all work together, and many of the choices that impact an IoT platform a year into development are made the day that a hardware engineer starts the schematic for a product. IoT is indeed difficult, and Jonathan laid out a plan for how to make it better. I agreed there’s a lot of room for improvement and went back to work on my shoddy implementation on the ABC board, since I was now trying to make things work on my own.
Switching to an exciting new product
The ABC board was put aside around this time for a very interesting, very new project: my daughter was a few months out from being born. I needed to prepare my consulting clients for me to take some time off. The timing worked out that a couple of my client projects were winding down anyway, so I was able to slide into a self-funded paternity leave alongside my wife.
As I emerged from the early parenting sleep-deprivation haze, I started thinking about the ABC board and restarting development. How was I going to get this board sending data to the internet? Where do I send that data? Who needs the data? How do I manage devices that I have created and deployed into the field? How do I package this up for future clients and sell the ABC board as a “starting point” for their cellular and Bluetooth designs? So many questions to answer.
Jonathan also got in touch and updated me on the progress of the company (Golioth) as he prepared to announce the availability to the world. I learned more about how it basically was designed to answer many of the questions I had. Golioth is built on top of Zephyr. It provides cloud infrastructure to connect to each of your devices. It has a “console” to manage these devices. It talks to MCUboot (an open-source bootloader) on the device to send updates over the air devices in the field. It has a built-in database function called LightDB so you can send and receive updates from the device.
It felt like Golioth was designed for me. It kind of was. Not me. But hardware engineers. Jonathan asked if I wanted to do some consulting around developer relations, helping support engineers understand the value of the platform and how to use it. So I have been doing that since June of 2021, making videos and onboarding new users to the platform. I enjoyed working with the team so much, I decided to join officially as of November 2021, so I can be part of the company long-term.
Moving up the stack, from hardware to the cloud
I have successfully been “moving up the stack” and doing hardware, firmware, and cloud, using Golioth. Towards the beginning of my consulting for Golioth, I also met a small software team looking to build an IoT product, so I recommended trying Golioth for fast prototyping and easy scaling later. I was able to create a proof of concept design using an off-the-shelf cellular modem, some external electronics, and some of the samples that Golioth offers. This prototype could:
- Communicate over cellular networks
- Had firmware on the microcontroller that controls/reads
- Solenoids
- LEDs
- Reed switches
- Had full access to push and pull data to the device from a web terminal (which could also be accessed via a REST API)
- Had over-the-air firmware update capability
And all of that took 3 hours to build.
I’m not saying I have solved creating any random IoT device. But I am much more capable as a result of this new platform. Now that I’m working with Golioth, I’m going to build my muscles around building fast turn-around prototypes and securely connecting things to the internet. One of my good friends is joining the team and we’re going to work together to build interesting devices.
I still have a lot to learn, especially around Zephyr and the network side of things. But I’m excited to keep building lots of interesting hardware in the future. Check out the Golioth YouTube channel and blog to see what I have been building and talking about lately.
I proposed a talk to the Hackaday Superconference yesterday titled, “Improve your circuit toolbox: Simple designs that will save your next product”.
While I don’t know if the talk will be accepted, I thought it could be a good discussion regardless and thought I could write out some thoughts here. I haven’t been writing much lately and wanted to stretch my muscles again, so why not?
The first circuit on that list will be an indicator LED.
Yep, that simple of a circuit. Allow me to share a diagram:
The power of the blink
All this circuit does is light up. When the user inserts batteries and enables the circuit via a physical switch, the power flows through the regulator and lights up D4 which is a red LED. That’s it.
The crazy thing about this circuit? The LED indicator was not implement until rev 3 of the design! Prior to implementing this I only knew the status of the board when I put a DMM across the power terminals.
Throughout the testing of the above project and in many other projects, I have shorted things out by accident. When there is a power indicator LED on board that starts to blink because I’m dragging down the power rail, it’s easier to stop doing what I’m doing. If that isn’t there, sometimes the only indicator is another part of the circuit communicating intermittently or the switching converter starting to whine.
The serial blink
Arduino users will know this one well, there are LEDs that are attached to the serial lines. When you’re programming the board or transmitting back via the serial console, the indication is obvious.
You need to be careful with your serial lines, ensuring your LEDs don’t pull too hard on the lines. Set your current with the proper sized resistors so you don’t mess up the edges of your serial lines. When in doubt, take them out.
Blink is optional
You don’t need to end up populating these parts when you go to production. Your low power product might not be able to spare the milliamps of current. You can either “turn down” the resistor brightness by using a higher value resistor or you can leave the LED out entirely when you’re certain you have a stable product.
Your eyes are test equipment
While these circuits are super simple, it effectively re-purposes your eyes as test equipment. There is a high amount of light sensitivity in the human eye and even small changes like brightness difference or flicker will showcase that “something is different” if not “something is wrong”.
LED indicators will help you troubleshoot your next product. Be sure to add them to any/all of the following:
- Input power
- Output power – After your custom regulation
- Output power – After regulation happening on a chip or module
- USB power (if separate from your input power)
- Battery charging
- Serial lines
- Status LEDs
For the audio fans out there: I discussed this topic on episode #358 of The Amp Hour
The past couple of years have been a mix of life events for me: I started my course full time, immediately jumped back into the work force (part time), traveled a bunch, started new projects, sold my old stuff, moved to Chicago, I met my podcast co-host in person and started my life over. It’s been a wild ride. Though there have been ups and downs, I’m super grateful for the opportunities I’ve had and the people I’ve been able to work with.
And since I only seem to post on this blog when I have big news these days, I’ll cut right to the chase: I’m starting a new role as a “developer advocate” at Hologram in mid-September.
Hologram is a start-up based here in Chicago, focused on making cellular data more accessible for internet-connected hardware projects. This takes the form of a SIM card that can be used with a wide range of cellular hardware. The business model is based around enabling projects to connect via cell towers and then charging for data and services. This is currently possible with other carriers, but not in a flexible way and definitely not in a friendly way for developers; this quickly becomes apparent for devs with a large number of devices and not much data needed per-device. The other neat thing is the ubiquitous nature of the SIM card. As an MVNO, Hologram works across a wide range of cell tower operators and in-between mobile carriers, meaning that devices using these SIM cards will work in a large range of the world.
My job will be talking to people building hardware or software and describing the benefits of using Hologram over something else. So…uh…how’d I do?
The past 3.5 years working at Supplyframe have been great. I have really enjoyed writing for the Supplyframe Hardware blog (something I helped create) and running the monthly hardware meetup called Hardware Developers Didactic Galactic (HDDG). One thing I’ve realized about myself is that I really do enjoy communicating information about electronics, even if I’m not the one with the expertise; this should have been apparent from my continued interest in running The Amp Hour (where Dave and I regularly interview people in the industry) and Contextual Electronics (where we have started a forum to get more community involvement and outside opinions).
Working as the “expert” has been increasingly rare as I moved away from daily electronics design. While I think I have become a better interviewer for the podcast, I think my ability to talk about everyday engineering challenges has faded. There is no replacing everyday anecdotes derived from the stress of creating electronic products. I’m looking forward to creating more hardware projects as part of Hologram, even if they are only example projects to help illustrate a point.
This will be the first time I’ll have co-workers and an office to go into in a long time (since 2014). I’m a bit more nervous about this, simply because it feels like I’ll be stepping backwards in terms of “freedom”. But one thing I’ve learned about remote work in the past few years has been the challenges of communication. Even with the near-infinite modes of communication available to us, nothing replaces face-to-face interaction. I would find myself looking forward to trips out to the corporate headquarters at Supplyframe because of the high-bandwith transfer of information that is possible when you’re sitting around a conference room table. So joining a local company is a cautious step back towards what I think is important in my working life.
That brings up thoughts about other things that are important to me. In fact, many of these things were present at my former job and I want them to be present at any future employer, including Hologram:
- Motivated, intelligent co-workers — This is an absolute must for me, but I realized over time that co-workers provide a feedback loop that allows me to create better work.
- Connection with hardware people — Not necessarily just engineers, but I really enjoy connecting people that are excited about hardware. I started a meetup here in Chicago to do just that.
- Hands on hardware design — This is something I was moving towards at Supplyframe and something that I get to do as part of my course. But I’m excited at the prospect of making hardware solutions for people looking to connect to the internet and solve problems.
- Work that has impact — At Supplyframe I was communicating with engineers that were solving real world problems. At Hologram, I’m hoping to also work with people that are solving problems using cellular connectivity.
- Learning opportunities — I am particularly excited about learning more about how cellular networks work “behind the scenes” and best practices for getting devices hooked up to the internet. This in addition to learning more about how to market to a new group of potential customers.
That last point is important and was tied into my decision to move jobs to this new opportunity. I have been trend-watching on The Amp Hour and as an EE over the past few years. There will always be subject matter experts with deep knowledge around a very focused topic (think “analog design”), but this has inherent risks. Companies that require this depth of knowledge continue to disrespect it; they outsource work to job shops or take advantage of the fact that there are fewer options for these kinds of employees. I think for opportunities as an employee or an entrepreneur, it’s necessary to have a hand in all parts of the process. As a result, I want to focus on more and more of the product design cycle, including sourcing/logistics, firmware and software. I recently wrote about the concept of a “solo engineer“; and while I am interested in working in-person with coworkers on a daily basis again, I truly believe the engineer of the future is capable of achieving a full product design using online services and persistence in their product vision. From an electronics standpoint, chip companies continue to consolidate and offer bespoke chip solutions for very targeted application. I think the solo engineer of the future will be tasked with finding and connecting a potential solution as fast as possible. Optimization is less important than proving out the design. This fast design cycle pace is unlikely to slow anytime soon. Not only is this a skill I’d like to work on (fast iteration), I think there are pieces missing in my ability to get a device operational as fast as possible (the software/platform piece). I’m excited to learn alongside all of you.
Again, I want to reinforce just how grateful I am for everyone I’ve met and interacted with over the past few years. It has been a really wonderful journey and I can’t imagine having done it without all the advice and friendship I’ve gained along the way. I hope to return that favor to others in the coming years; if you have a project you want help getting online, let me know!
