Tiny software and electronics projects (TiPs) are ubiquitous. The The Arduino Ecosystem has facilitated many of them. But some TiPs do not evolve and eventually become obsolete. Others do evolve and have a tendency to become un-tiny and untidy and unfit. I would like my TiPs to evolve and to adapt to my needs while staying tiny.
In other words, I would like to make my TiPs resilient when submitted to changes. This website is about exploring strategies to make TiPs resilient.
Projects that are not tiny - in particular those that look tiny but turn out to be otherwise - are called NoTips (Not a TiPs).

Each project has a companion github repository. Please use the github issue tracker for questions, feedback and corrections. Or contact me directly with the email form below.

Feel free to copy (MIT license).

Copyright © 2024 Peter Vittali

TiPs #7

  • Smart Village: Remote monitoring of drinking water consumption in a rural environment .

Objectives (Jan 2024)
  1. Build a low power water metering system in a remote location.

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

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

  4. Transfer document base to zotero.

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

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

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

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

  5. Improve document management.

Resilience Report (Jan 2024)
  1. I believe that the proposed documentation approach can be useful, but it has to be applied to many TiPs before making more conclusive statements.

  2. The Arduino firmware that is part of this TiPs is not resilient at all. It suffers from the same problem as TiPs #5: Two software subsystems are coupled and can not be tested in isolation.

Status: in production.

TiPs #6

TiPs #5

Objectives (Apr 2020)
  1. Complement TiPs #3 with a set of hardware components.

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

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

Building Resilience
  • I consider reducing power consumption a strong resilience building technique.

  • Vendor independence is a fundamental requirement for resilient TiPs. In this case, this means independence from cellular network operators (and SIM cards) and thus reduced transmission costs. More importantly, though, this is also a path to longevity. GSM 2 has ceased to operate in at least several european countries and GSM 3 is bound for the same fate within the next five years. Many projects and installations will be rendered obsolete or will at least require upgrades.

Resilience Report (Jan 2024)
  1. Objectives still hold.

  2. [Checked 103 links, 47 destination URLs, 1 have errors,]

  3. Not a TiPs (NoTiPs), at least not for me.

Lessons Learned (Jan 2024)
  1. Don’t start a TiPs with multiple coupled sub-components. This is in fact not one TiPs but a whole set of TiPs.

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

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

Status: on hold.

TiPs #4

This projects is very similar to TiPs #3. However, the getting-started tools in this project have better vendor-support. I might pick up this project when I know more about BLE and microcontrollers.

Status: on hold.

TiPs #3

Objectives (Sep 2019)
  1. Learn to use bluetooth (BLE) connected microcontrollers and sensors.

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

Building Resilience
  • Bluetooth connectivity allows to replace hardware dependent I/O (display, buttons) with software defined I/O (for example, Android apps). This strengthens flexibility and thus resilience.

  • Managing references and bibliography across related projects improves documentation coherence and thus resilience and productivity.

Resilience Report (Jan 2024)
  1. Objectives still hold.

  2. [Checked 165 links, 56 destination URLs (1 ignored), 0 have warnings or errors]

  3. I am personally still satisfied with the documentation, except with the management of references and bibliography.

  4. Tightly coupled to proprietary software and hardware.

  5. Poor choice in getting-started tools.

Lessons Learned (Jan 2024)
  1. 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.

  2. 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).

  3. 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.

Status: failed.

TiPs #2

Objectives (Aug 2019)
  1. Learn to use cloud connected microcontrollers and sensors.

  2. Learn to use asciidoctor for technical documentation.

Building Resilience
  • The cloud as a reliable data store and application container.

  • Tools for documentation.

Resilience Report (Jan 2024)
  1. Objectives still hold.

  2. I am personally still satisfied with the documentation. Asciidoctor was a good choice.

  3. Tightly coupled to proprietary software.

  4. Conflict with the principle of Separation of Concerns.

  5. [Checked 98 links, 52 destination URLs, 6 have errors], 5 of 6 broken links go to the vendor website, 4 of them to the support & knowledge center.

Lessons Learned (Jan 2024)
  1. 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.

  2. 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.

  3. 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.

  4. 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).

Status: failed.

TiPs #1

Objectives (Jun 2020)
  1. Build a tool to test TiPs with microcontrollers.

  2. Learn to use asciidoctor for technical documentation.

Building Resilience
  • Tools for automatic testing.

  • Tools for documentation.

Resilience Report (Jan 2024)
  1. Objectives still hold.

  2. I am personally still satisfied with the documentation. Asciidoctor was a good choice.

  3. Tightly coupled to proprietary software and hardware.

  4. [Checked 73 links, 41 destination URLs, 2 have errors].

Status: on hold.

Contact & Imprint

Peter Vittali
Weidenweg 1
CH-4127 Birsfelden, Schweiz
+41 61 271 89 33

Legal: The content on this website may contain technical inaccuracies or typographical errors and may be changed or updated without notice. The authors of this website may also make improvements and/or changes to the content at any time without notice. The authors of vittali.ch assume no responsibility regarding the accuracy of the content and use of the content is at the recipients own risk. The authors of vittali.ch provide no assurances that any reported problems with any content will be resolved.