Building resilience in Tiny Projects (TiPs)

Build a low power water metering system in a remote location.

Having failed to do so in TiPs #5, drop the requirements for low power and non-cellular.

Learn Latex for document typesetting involving math and for improved tooling for references and bibliography.

Transfer document base to zotero.

Describe the electronics design part of this TiPs as a set of modules.

Propose an approach to reason about electronic circuits that is inspired from API ( Application Programming Interface) design.

Each circuit module should be as autonomous, reusable and testable as possible.

Apply Unit Testing, a standard software development method, to electronics design.

Improve document management.

Complement TiPs #3 with a set of hardware components.

Build a low power water metering system in a remote location using a Sub 1 Ghz radio to transmit sensor readings to the cloud.

Use a Sub 1 Ghz network rather than a cellular network.

Don’t start a TiPs with multiple coupled sub-components. This is in fact not one TiPs but a whole set of TiPs.

Break up NoTiPs until the real TiPs show up. Projects that can be understood and tested.

Every TiPs contains at least one even tinier TiPs struggling to get out (;-.

Learn to use bluetooth (BLE) connected microcontrollers and sensors.

Learn to use asciidoctor for technical documentation, specifically for managing references and bibliography.

The chosen SensorTag mini evaluation kit was utterly unsuited to get started with a complex technology like BLE. I was clearly undereducated when starting this project and I should have watched for example some of the excellent videos by Andreas Spiess first. It was a bad idea to start from the vendor’s website.

Be more selectively in choosing the right tools for each TiPs. For example, the quality of T.T.H.W - Time To Hello World evaluation boards differs enormously. So does the quality of IDEs (Integrated Development Environment).

Choose a different toolchain to manage references and bibliography. While asciidoctor is an excellent tool, I feel that I need more help to keep track of all the documentation that is typically involved in microcontroller TiPs.

Learn to use cloud connected microcontrollers and sensors.

Learn to use asciidoctor for technical documentation.

I will never, ever, again use "free", proprietary packaged cloud services like IBM bluemix for TiPs. While this offer certainly had benefits for industrial projects, it produced a massive overhead of security related ceremony (many different passwords and tokens) that completed outweighed its benefits for TiPs.

The cloud service I used did not offer any kind of backward compatibility. After a year or so, the initial project stopped working. Worse, the documentation of tools related to the service was not available anymore on the company’s website.

The cloud service promoted the use of "quick-start" tools like Node-RED and a complete integrated toolchain including a hosted git repo and an application deployment service. This conveyed a feeling of comfort and easiness. Clearly, I fell for the T.T.H.W - Time To Hello World fallacy. As soon as I started to adapt different parts of this quick-start package, things became very difficult. For example, rather than developing my code in the cloud, I wanted to continue developing on my desktop. This in turn required complicated mechanisms to provide passwords from the local machine to the application deployment service.

Node-RED is certainly an amazing project as it promotes a modular way of coding without actually writing code. As such, it is a perfect example for a TiPs enabler. However, mixing code and visualization elements (dashboards) runs foul of established software design practices promoting clear separation of semantics (model) and visualization (views).

Build a tool to test TiPs with microcontrollers.

Learn to use asciidoctor for technical documentation.