What’s Next For Me: Saving Lives With SUAS

by
A shot of the archer frs crew haning by the GCH, shot by an unmanned aerial vehicle, of course.

When Gordon Folkes III first approached me about joining Archer First Response Systems, I had a lot of questions. I had met Gordon through a hackathon in 2017, and I knew his company was working on delivering life-saving AEDs (Automated External Defibrillators) to cardiac arrest victims via unmanned aerial vehicles. I brushed shoulders with him at Orlando events from time to time, and he shared about what he was working on at the Orlando IoT Meetup last year. Still, I wasn’t quite familiar with what had been happening with Archer since then, and while the idea of joining a startup working on life-saving technology was definitely enticing, I wanted to know how viable this concept was before doing so.

The winners of the Orlando Smartest City Challenge, Justin Wells, Florin Lucha, Gordon Folkes III, and Jared Porcenaluk.
(from left): Justin Wells, Florin Lucha, Gordon Folkes III, Jared Porcenaluk, after winning the Orlando Smartest City Challenge hackathon in August of 2017.

So, I asked a ton of questions. First rule of joining any startup: is there funding? I do have a mortgage to pay, after all, and until we figure out that whole immortality thing, I still need to eat. Yes, there’s funding. Ok, well…

  • How many cardiac arrest victims are there?
  • How does this compare to ambulances?
  • How will people know to use the AED?
  • How far can the drone go?
  • Oh, drone is a loaded word. Unmanned Aerial Vehicle? No? Small Unmanned Aircraft System? Will people know what that is?
  • So how far can the sUAS go?
  • How will you know where to send it?
  • How will people know to ask for it?
  • Why not use AEDs from a local building?
  • What competitors are in the space?
  • How will this make money?
  • Where do you see the company in three to five years?
  • What’s the technology stack look like?
  • What challenges are you running into?
  • What’s the biggest obstacle to success?
  • Can I work in my pajamas from time to time?

I didn’t ask that last question, but thankfully it’s turned out I can work in my pajamas from time to time. Remember, kids, the code doesn’t care what you wear. For all the other questions, I got satisfactory answers from Gordon as well as Spencer Hehl, CTO. From him, I learned about their technology stack and the technical challenges that they’ve overcome as well as the ones coming down the pipe. The challenges form a technological playground that spans software, scaling, the cloud, and the edge, all within an environment that requires certainty and security unlike many others.

So, I did it. I had (and continue to have) more questions, but ultimately I knew that if they knew all the answers they wouldn’t need me. I joined.

And after being there for three weeks, it’s what I had hoped for. It’s solving problems quickly, moving fast and light, and also continuing to bootstrap a system that can be relied on, with a team that believes in the possible. I’m applying all of the knowledge I’ve gained at New Signature (née Nebbia) to give us the best chance of success as a company. While all of the details are a little hush-hush, I promise I’ll be updating you with more soon, and it will be worth the wait. I’ve seen this thing in action, and it’s incredibly impressive.

A shot of the archer frs crew haning by the GCH, shot by an unmanned aerial vehicle, of course.
The Archer FRS Team (Gordon Folkes III, Kade Aley, Spencer Hehl, and Jared Porcenaluk) by the Ground Control Hub.

I’m Leaving The Best Job I’ve Ever Had

by

The best job I’ve ever had was my pizza delivery job at Pasquale’s. Well, in 2007 that was the best job I’ve ever had. What wasn’t to like?

  • Tips are great.
  • A free meal every shift.
  • Driving a car around is fun.
  • No boss breathing down my neck while I’m out on delivery.

After moving to Florida, I had to find a job fast or else the old bank account might start running backward. So, I thought about what I liked to do. Well, I liked cars. I walked into a Volvo dealership and as it turns out, they were looking for a Porter. If you don’t know what a Porter is, they wash your car and deliver it to the front when it’s done at the dealership. They also generally do a laundry assortment of undesirable tasks no one else wants to do. A “gopher,” so to speak. There was a lot to like:

  • Driving new cars all day.
  • Free lunch on Saturdays.
  • Enjoying the great outdoors for most of the day.
  • Great camaraderie with co-workers.
  • Learned enough dirty and off-color jokes for a lifetime.

After a year, I had gained residency in Florida, which made it much easier to get into UCF and not drown in the out-of-state tuition. At UCF, with a semester under my belt in Film, I started searching for yet another job. Would this be the Best Job Yet?

No. Regal Cinemas, I vow to never upsell popcorn again. This was the Worst Job Ever, and I hope that designation sticks for the rest of my life. Awful hours, especially when we had one car and Sarah would need to pick me up at 2:00 AM after a movie ended. Awful pay, near as makes no difference minimum wage. And a corporate structure that seemed, to me, to be set up entirely to disparage and demean. Yes, my drawer is off by a dollar. No, I don’t think I want a demerit point for that. I quit after a month and a half.

There was not a lot to like.

It took me until 2009 to get a job I enjoyed as much as Pasquale’s, although for wildly different reasons. It was my first office job, a place where cake was served to celebrate July birthdays and Dilbert was pasted up on cubicles. It’s also where I first learned to do web development, finally getting a bite of the forbidden fruit that sparked my insatiable appetite for learning the depths of technology. What wasn’t to like?

  • Free coffee & soda.
  • Dilbert jokes.
  • Great autonomy.
  • I got to stretch my creativity by making videos.
  • Learning web development.
  • Feeling appreciated for the work I’m doing.

By 2012, graduation from UCF was looming and I was not sure if I should stay or go. The economy was still slowly recovering from the recession, so the options didn’t seem to be wide open.

For the best chance for both my now-wife and I to get a job, we wanted to relocate to somewhere with more opportunity. We both interviewed in the Washington, D.C. area to see what kinds of post-graduation professional jobs we could get. With both some software development experience and a radio/television production degree, I applied to both video editing and software development jobs. Thankfully, Ronald Gregory gave me a chance at Interface Media Group to do web development, despite my thin resume in that area. What wasn’t to like?

  • Working in Washington, D.C.
  • Salary position + benefits.
  • Learning C# and strengthening my CSS, HTML, and JavaScript knowledge.
  • Worked on a project that ended up in a Smithsonian museum.
  • Hot chocolate at Pret-A-Manger on the way to work in chilly weather may be the closest thing to heaven on earth.

All was not sunshine and roses, however. After three years of the commute, and the weather in D.C., Sarah and I were ready to move back to Orlando. I wanted to see if I could hang out my shingle. Would this be the Best Entrepreneurship Job yet?

Well, no. After one contract job that went very well, I realized how important the business side was. Relying only on my technical know-how wasn’t going to make that venture successful. I was not filling up the sales funnel while it was draining, so I had no more work lined up after that initial contract. Still, there were some great perks:

  • Set my own schedule.
  • Work from home.
  • Very fulfilling working directly for a client.
  • Great sense of pride for the work accomplished.

But, with no prospects in the pipeline, it was time to find something a little more stable. That’s when I interviewed at Nebbia Technology.

And what a ride it’s been. When I started, we had no permanent office. I started as a fifth to add to the existing four people. Over the course of three and a half years, we got an office, grew to thirteen people, expanded our office, and was acquired by New Signature. We increased revenue and profits in that time by leaps and bounds, not always in a linear fashion. I can’t give enough credit to Chelsea’s tenacity as a head of Business Operations for keeping all of us technical people employed in those early years. And, of course, Esteban’s leadership in shaping the company into something worth acquiring. My own failures in starting a business has given me a lot of respect for those non-technical responsibilities.

Speaking of important non-technical roles, I also can’t thank Hannah Schaffer enough for making our lives so easy in her Operations role, and for shaping the Nebbia brand as Marketing Coordinator. Also, Alyse Hyatt, for coming on board as our Project Manager, and playing a key part in greasing the gears to make it so we could focus on what we do best: delivering.

And, boy have we delivered. I’ve worked with clients who have multi-million line code bases, who are looking for build & release pipelines, to automate, to move to the cloud, to create hiearchical picker extensions for Azure Devops, and who knows what else I can’t remember.

I honestly marvel at how the team is chock full of experts and technical powerhouses, yet there’s nary an ego to be found. A dream team. It will be incredibly hard to leave when I know how easy it is to work with everyone there. Nebbia Alumni include Mikey Cooper, Brian Hall, Clementino De Mendonça, Cliff Chapman, Phil Hagerman, and Jeff Truman. I have appreciated working with every single one of you, and have learned from each of you. The team that I’m leaving now, Facundo Gauna, Justin VanWinkle, Ryan Buchanan, Troy Micka, Chris Ayers; thank you so much. Mostly, for laughing at my horribly punny jokes. But also, for teaching and inspiring me.

Although there is never a “right” time for anything, this feels about as close as I can get. I know I am leaving the team at a time when they are very able to succeed without me. I know with Esteban’s leadership, and the weight of New Signature behind them, they have the capacity to truly change the world.

So to them: go out there and teach ’em that software development doesn’t have to be drudgery. That all the Sev 1 late night all-hands-on-deck anxiety fests don’t need to happen. That the pointing fingers and rolling eyes and feeling stuck and being bored to death in silos can be replaced by celebrations and high fives and talking to users. I’m counting on you, team. Go out there and show ’em.

While it’s difficult to leave the best job I’ve ever had, I’m comforted by the knowledge that I’ve done it before. And each time, the next thing has never quite been what I’ve expected. Every job has managed to teach me something about myself, about what fulfills me, what I’m capable of, and each have given me the experience and confidence to take on the next thing. Now, I’m excited by the prospect that, maybe, the next position I’m taking will also be the best job I’ve ever had.

Stay tuned for next week, when I talk a little bit about what’s next for me.

Smart Bronco: Choosing Sensors for the Real World

by

Going from proof-of-concept to prototype, aka my single 1988 Ford Bronco II, offers up some challenges. Rather than using Seeed Grove to prototype temperature using a simple generic temperature and humidity sensor (the DHT11, if anyone is asking), I need to figure out how to read the coolant temperature from the engine block of a greasy 30-year-old Ford.

That means I need to consider a few things:

  • Temperature range (0 degrees F to about 300 degrees F ought to do it)
  • Thread size and pitch in engine block (3/8″ is the size and NPT, or National Pipe Thread, which indicates the pitch of the threads)
  • Waterproof (’cause it’s going to be in coolant)
  • Analog-to-Digital output (going from the analog input of the real world to a digital output requires some calculation, one that I’d prefer not having to figure out manually)
  • Accuracy (accuracy to about 1 degree F would be ideal, it can be a little more flexible but the more accurate the better)
  • How fast it responds to temperature change (how fast does the temperature vary? I might need to know if the temperature shoots up quickly! A few seconds would probably be fine)

Obviously these are a lot of things to keep in mind. You’ll be the first to know when I find a sensor (or a combination of things) that fits the bill!

Smart Bronco: Prototyping Measuring Coolant Temperature

by

So while I was figuring out how to get my application approved for the Microsoft Store, I decided to move forward with actually writing some code. Eventually I want to read the temperature in the Bronco, but before I get there I wanted to just test out reading temperature at all. Taking little steps and learning along the way is how I like to develop, as it makes it a lot easier to respond to failure. Only tactically when I realize I’m on a wrong path do I pivot. It’s a similar philosophy as laid out in the Lean Startup, which prescribes a lot of these ideas for starting a business, but they seem to apply for development as well.

In order to prototype this out, I knew that I didn’t want to think too much about the hardware. After all, I’m a software person, and besides I think there’s little value in reinventing the wheel unless it’s for the distinct reason to learn how the wheel works. So, I leveraged a hardware and software abstraction and used the Seeed Grove kit for Raspberry Pi that allows me to not worry about translating the analog world into the digital world. The Grove System is specifically created to make prototyping less painful, and I can certainly attest to that. With the Grove Starter Kit for IoT based on Raspberry Pi as a starter point, which I received as part of an IoT bootcamp put on by Microsoft, within an hour or two I was getting the temperature of the real world and displaying it on my screen.

While not all that earth shattering, that allowed me to create the code that I will need when I’m starting to use a temperature sensor more appropriate for the Bronco. And that is exactly what prototyping is for, so it was a great success. Now, if only they would approve my app for the Microsoft Store, then we’d be cooking with gas. Or cooling with coolant, I suppose.

Microsoft Reject My App Store Submission

by

Being rejected is difficult. When I submitted my Universal Windows Platform (UWP) application to the Microsoft Store, I had no reason to think it would not pass with flying colors. I followed their checklist. I checked all the appropriate boxes, dotted all the t’s and crossed all the i’s. 

Wait, the other way around.

Either way, it was rejected, and the reason (in my mind) was quite funny. There was no screenshots of the application! That was the reason! Why is this funny? Well…

The purpose of the IoT application is that it will be pre-installed on an OEM device. Aka, this thing is built to be installed on an IoT device that shows up in a store and sits on a shelf, and when a user buys it and takes it home, the single application that is installed on it will show up. They won’t even know it’s a Windows 10 IoT Core device, they won’t know it is connected to the Microsoft Store, they won’t go and find the app to download.

Well, that won’t really happen for the Bronco as it’s just kind of a proof-of-concept for that, but the logical issue still stands. No one is going to see this app in the Microsoft Store (and in fact, one of the checkboxes I checked was “hide this from the Microsoft Store search).

So, putting a screenshot or two of what the app does seemed a little superfluous to me. Perhaps it’s for the reviewers to make sure there’s a little meat to the potatoes in submissions. I know that the Microsoft Store (and really, all app stores) have an issue with quality of apps, so maybe that’s what they wanted to check out.

Either way. I’ll keep you up to date when I find out if they approve it!

Developing IoT Devices from Your Local Computer

by

Developing a typical software application locally often involves an IDE (Integrated Development Environment) or even a simple text editor (even Notepad), some sort of build system in the case of compiled languages (like C#) or an interpreter in the case of interpreted languages (like JavaScript). The process often looks like this: Write some code, compile it, run it, see what’s changed. If you are really cool, you can just run some unit tests as you develop to find out if what you have is working rather than running the whole application just to test one thing.

When you are developing for an IoT device, it can get more complicated. Sometimes there are emulators available that can simulate the physical device, other times it makes more sense to actually deploy code to the physical device. If there’s a physical device in the mix, you can deploy code over the wire, like through a USB cable that connects your device to your computer, or over WiFi, or in certain setups even through the internet.  For my Raspberry Pi 3, running Windows 10 IoT Core, I can develop locally using Visual Studio and deploy over my local WiFi new code to my RPi directly from within Visual Studio. For most devices, there are a few ways to develop and deploy to it and it’s highly dependent on the platform of choice.

Whatever the process, reducing the time it takes from changing something to finding out if it works is very important.   The first line of defense I have for being able to iterate quickly is unit tests. Unit tests can run very quickly, and can run against most of the code base all at the same time. Although they can be a pain to set up, the long-term efficiencies gained from knowing that most of your code works every step of the way is a huge time-saver.

This is true of regular development. When IoT is thrown into the mix, with the additional time it can take to deploy code to an emulator or a physical device, the efficiencies gained can be even greater than from application development. The next tactic is to use emulators when you can (as it’s typically faster than deploying to a device), and then when you do have to deploy to a device, make it as repeatable and quick as possible.

 

Smart Bronco: Choosing an IoT Operating System

by

What’s a piece of hardware without the operating system to run it? When buying a new desktop computer, the decision often comes down to a few choices: Mac, PC, or Linux. Operating systems in general are designed to run on a limited variety of processors, for example, Microsoft Windows historically has run on processors that run the x86 instruction set (they do occasionally get it to run, with some qualifications, on ARM processors). Linux has been compiled to run on a variety of computer architectures. macOS, it turns out, used to run on Mac processors and now runs on x86 and ARM.

With x86 and ARM being the dominant processors on laptops, desktops, and even phones, does the same hold true for IoT devices? Yes! And no. It depends.

If we are talking about microcomputers, which are essentially tiny desktop computers, often with GPIO (General Purpose Input Output) pins, then yes. The Raspberry Pi 3 is a widely adopted version of this. With an ARM processor, the same architecture as the ones that are in the vast majority of Android phones these days, it can run both many flavors of Linux and a special version of Microsoft’s operating system called Windows 10 IoT Core that gets specifically compiled for ARM processors.

When we want to go with even smaller, cheaper, less power-hungry (and less versatile) devices called microprocessors, the operating systems are more tied to the hardware because they run so “close to the metal” as they say. Rather than talking through abstractions, like the full-fat operating systems mentioned thus far, they often have strong dependencies on the underlying hardware. This category of operating system are typically called “Real Time Operating Systems.” Because there are many different types of microprocessors, there are many different types of RTOS in use today. For example, if you choose to use a Particle Photon, it comes with an operating system called “Device OS”. For any given microcontroller, there are usually a few different RTOS compiled down to be used by that hardware. With so many microcontroller choices, the mix-and-match options with operating systems are varied. Which one you choose is all about what you want to do. For example, if you wanted to use JavaScript to control your Particle Photon (rather than the out-of-the-box C-like language), you could install a new OS (or “firmware”) called VoodooSpark and run the Johnny Five framework on top of it.

For the Smart Bronco project, I am choosing a Raspberry Pi 3 with Windows 10 IoT Core running on it. Windows 10 IoT Core is like Windows-light, with the ability to run only Universal Windows Applications. It is specifically designed for the Internet of Things, even going so far as allowing users to create their own build of the operating system, for example if you’d like to remove the ability to do SSH in production for security purposes. When it comes to operating systems, I know that Microsoft has a great track record with stability and support, and so that confidence also helped make this decision easier for me.

As a developer, the operating system allows me to write code in C#, which is a language I’m familiar with. It will also allow me to take advantage of some of the tools that Microsoft gives for deploying updates to devices (more on that later). I also will be able to run multiple programs at the same time, which could be useful as I start to add more functionality to the Bronco. In addition, because I want to have the option for both “headed” (with a user interface) and “headless” (without a user interface), I know Windows 10 IoT Core gives me both those options.

In your own search for the perfect operating system for your project, making a choice and learning from it is more important that choosing the perfect solution right out of the gate.

Smart Bronco: How to Choose IoT Prototyping Hardware

by

Choosing hardware to prototype with in the realm of IoT can be overwhelming. There are so many choices! And, there’s so many constraints when it comes to putting a piece of hardware into production:

  • Power requirements vs. availability
  • Internet connectivity options
  • Processing requirements
  • Preferred programming language support
  • Security
  • Manufacturer’s support
  • Availability
  • Longevity

My advice is simple: Don’t worry too much about those constraints when you are just getting started. To make a prototype, focus on what’s going to allow you to fail early and often. In my experience, the prototype will only serve as a reference for the real thing. So, use the hardware that will allow you to get up and running quickly and worry about the constraints later.

For example, if you know JavaScript really well (or your team does), and your aren’t sure what processing power you’ll need, go with a microcomputer with some decent computing power that supports a mainstream operating system like a flavor of Linux or Windows. While options like Raspberry Pis with Windows 10 IoT Core or Raspbian works, don’t be afraid to spec out an Intel NUC or something similar if you want the full power of a desktop processor. This is a proof of concept, after all.

For me, I know the .NET platform pretty well, I’m familiar with C#, and I’ve used the Raspberry Pi with Windows 10 IoT Core before. I think I’ll stick with this tried-and-true formula (at least at first) as I validate that I can get information from a sensor reading the coolant temperature on the Bronco and send it up to Azure using IoT Hub.

Once the concept is proven, assuming that the concept is something like “Can we take this outdated protocol from an old machine and run it through an IoT edge device and get it to the cloud?”, the next step is to take those constraints into consideration and move the code to the hardware that will support those constraints. I’ll cover that another day!

Smart Bronco Project Announcement

by

 

Over the course of the next few months, I am planning on taking my 1988 Ford Bronco II and making it a little more smart and a little more connected, thanks to the power of the Internet of Things. I plan on using this cruddy old truck to experiment and learn about IoT being applied in the real world. Of course, because I work at Nebbia Technology, I will be applying DevOps practices and using the Azure cloud. I’m really looking forward to creating, learning, and sharing about how to apply IoT best practices to not only crusty Ford Broncos, but to new IoT projects and products as well. Stay tuned!