Konekt Dash Hardware Update: The Future Of The Future

/ Written By Daniel D Lindmark

This post is less about the Konekt Dash hardware and more about:

  • M2M development tools
  • what tools will win ‘The Internet of Things’
  • what tool-builders need to add to edge out the competition and grow

The way I view each of these things and how I interact with them has changed throughout my career.

I’m a classically trained Electrical Engineer. I cut my teeth on theory, followed by math and chased down with a tall glass of experimentation, followed by a desert of due diligence. That means (aside from occasionally forgetting social graces), grabbing onto a problem and not stopping until I’ve understood every aspect and mastered it.

It’s taken me a long time to learn that this is often not the best approach. It’s taken the maker community, armed with Arduinos to make me see the light and I’m almost a little ashamed at how wrong I’ve been. Let me explain:

The “Right” Way To Solve An Engineering Problem

If I have a problem with a circuit, I break out a scope and a logic analyzer. I pour over the schematic. I go online and read up on every post on the part. I make simulations. I remove components and bridge their lines and try to isolate the problem. Days can go by. In some cases, weeks have gone by.

If a novice has a problem with a part, they replace it with a different part. To repeat: If someone who doesn’t understand a problem encounters a problem, they try to avoid the problem. This is genius that I was too smart (stupid?) to realize.

For the longest time, I thought this was the wrong approach. The “Right Thing To Do” is slave away until the problem is solved. My job is to be an expert, right? Well, not exactly. The job of a person creating a circuit is to solve a problem in a timely manner and stay under budget. There are times when you can’t replace a part number, but most of the time there is a better option out there.

So… There’s A Dev Kit For This, Right?

What happened on Konekt was simple. We were using a fuel gauge that I’ve used multiple times on multiple designs. For whatever reason, I couldn’t communicate with the device. I was a little miffed when I asked the FAE for libraries and was told that everything I needed was in the datasheet. The old me would have been shamed to have asked for a shortcut. The new me knew the value of a hardened library made of a robust class that would work with just a few member function calls. A library that had already been written and had seen a lot of use, making it even more robust.

No worries, there was a dev kit. I overnighted the dev kit and tried to hook it up. The default, out-of-the box experience was reading back gibberish. The instructions were targeted to Windows 98. The screenshots showed a completely different software than was included in the same package. The documentation had been updated in 2013. Windows 98 in 2013. Huh. The dev kit didn’t work.


A Lesson In The Importance Of Usability

Normally I can live with these things. Normally, I can slave away and get to the root cause. I understand that keeping documentation up-to-date costs a lot of money. But this is 2015, and we are in a Cambrian-Explosion of devices.

For every poorly documented part, there is an equally useful device that has a low-cost devkit on Sparkfun, Adafruit, SeeedStudio, or elsewhere. Devkits that have a community behind it and drivers/libraries to interface with the devices. Devices that I know I can get up and running in minutes, not hours or days.

Just like the Cambrian-Explosion, there is a survival of the fittest. Parts that have better tools will survive. We are mere years away from systems that can be defined by features in code/GUI that will pick components and libraries and integrate onto a PCB “automagically.” Devices like the fuel gauge we jettisoned will only survive if their tools get upgraded. Devices that make integration not just painless, but transparent will be the ones that lead the market and outperform.

Redefining An Engineer’s Role

There are now currently more amateurs working on PCBs than there are degreed Electrical Engineers. This trend will continue. The role of an EE is going to shift from being the sole responsible agent for making boards, to being the person who does research to create new technical solutions. They won’t necessarily be the person who makes the PCB.

EEs are being joined by Computer Scientists who have all the experience of building robust web applications. Their job is to make the tools efficient and robust. We are being joined by web designers and UX specialists. These people tell us how the tools can be alienating and then how to make them more useful, in less time. Good tools and paradigms are going to very quickly outpace bad tools.

I don’t know exactly what all of us are going to make in the future. I do know that development in the second half of 2015 is going to be faster than in the first half. I know that the tools are better, more productive. I know that because the Dash is open hardware, we want all of the components on the board to be as easy as possible to use in case you want to change or re-use parts of the design. I know that the Dash is such an easy to use tool that you don’t have to understand how it works. You just have to want to talk to a remote device and we make it as easy as possible to use.

I don’t know what you’re going to build, but I do know that it’s going to blow my socks off and that together we are helping to make the future happen sooner than any of us could have imagined.

Daenerys drops mic | Konekt Dash Hardware Update

You can join the hardware conversation about the Konekt Dash and Konekt Dash Pro on our community support page.

Comments are closed.