Hardware need not be hard: Our BAYDUINO

This is how the story of our BAYDUINO project went.

“There is a reason they call it hardware—it is hard.”
Tony Fadell

“Ideas are cheap. Only execution matters.” This business truism is a mantra, frequently uttered by my co-founder Michael Reuter. And I agree. However, there are two ways from conceiving an idea to executing the project that it entails. The first is the traditional: Go to the workshop, build the prototype, test, and if successful, get orders to build more. The second way, comparably young, is to develop the concept, get a patent, and then find a sweatshop to get your project produced as cheep as possible. The latter became fashionable with companies like Nike in the 1980s; it works of course only if you have global availability of cheap labour and efficient logistics for the goods. The main prerequisite however is that the idea as such can be owned, protected for exclusive exploitation to its inventors.

For artisans, securing intellectual property rights from their creation seems as absurd as it would have centuries ago. No carpenter or tailor would be fooled that their customers would buy their work because of its unique originality of its design. The separation of idea and manufacturing came with industrial mass production, when for the first time the designer became a specialized function within the process of manufacturing. Since the design dictated all the products’ properties and how to do them to the manufacturer, the blue collar workers were rendered exchangable. Once designing things was severed from building them, it was almost natural to split the two no longer connected businesses into separate companies.

Over the last thirty years, we have seen many branches of the manufacturing industry crumble. Textile, once strong in Germany, is almost totally lost. Worst is electronics. If you want to start something with electronics. it seems almost impossible to do without globally sourcing the components. All concerns, environmental and humanitarian likewise have to be abandoned.

When we started working with data, it was obvious that the richest source of data about humans was the so called Internet of Things. More and more devices carry sensors, small instruments that continuously measure all kinds of different values about people’s actions, their surroundings, and even their communication. Some of these devices are fixed, like thermostats or webcams, many are mobile, like the smartphones or wearable accessories.

Smartphones in general are by now the most common IoT gadgets. Their sensor measurements range from geo-location to delicate readings of the magnetic fields. However, the operation systems running on the phones hardly allow direct access to these sensors. Hence it remains basically a black box, how the data is generated. The information exists only mediated through Google’s or Apple’s interpretation of the data.

Understanding, how data works, how it is generated, collected, stored, processed, and finally analyzed and interpreted has become the basic skill in information technolgy. Data science is called the “hottest job” now. Without proper knowledge about the physical actuality behind the data, it stays just theorizing scholastics,

This is how the story of our BAYDUINO project went.

One year ago, I visited the beautiful city of Turin in Piedmont for a special occasion: The grand opening of Casa Jasmina at the Fab Lab there (see my report here). Next door to casa Jasmina sits the Officine Arduino. The Arduino (or Genuino respectively) has become the most common platform to prototype for the Internet of Things. It is open source and strongly tied to the maker culture.

I am not good in soldering. All educational hardware that I tried, ended in disappointment. In particular, most are way too complicated to just give to the kids; they would fail, too, and then come back to me, hoping I could help them. So I had a strong desire to come up with an easy path into sensor hardware. Also I was convinced that it should be possible to source such a projects locally in Munich, maybe with some help from other parts of Europe.

When back home, we discussed my experiences from Turin in our team and decided, that we would start developing. My friend Nils Hitze recommended us to Hans Franke, a hardware expert who turned out to be a total genious. After three month we had our design ready.

The BAYDUINO is an open source hardware board. It is compatible to the Arduino as well as the upcoming BBC Micro:Bit. All components come from Europe, most have traveled less than 150 km – with one exception: The CPU which is Chinese. Sadly we were not able to find a local one. The boards are also assembled locally.

Just two layers of circuitry, one on each side of the board. Every component would be labeled, so you could not only understand, how all the components are connected, but immediately see, what is what. The board carries various sensors like gyroscope, magnetic field instrument, or photo detectors, and five buttons as controls, has a small LED display and can easily be connected to other actors.

The BAYDUINO has an Open Roberta interface which is developed together with the Roberta team at Fraunhofer Gesellschaft.
Open Roberta is a language that lets children to do robotics with small building blocks of code that can be drag-and-dropped on a graphical user interface. This makes programming the BAYDUINO easy even for children who are not skilled in typing. We are also developing mobile apps for this task because many children have smartphones or tablets but no PC.

Rapid prototyping and accessible SMT placement shops, great support from the community, and of course the open source knowledge that is available on the net were indispensable help to getting the BAYDUINO accomplished.

With our first prototype we started a crowdfunding campaign. And in the next days the first boards will be send out.

The BAYDUINO is our idea of Slow Media translated to hardware and the IoT – Slow Technology.

Link to the Bayduino website: www.bayduino.com

The first prototype of the BAYDUINO
The first prototype of the BAYDUINO

The final BAYDUINO
The final BAYDUINO

Slow Coding

by Regine Heidorn, Bit-Boutique®.

[Read this post in German]

The breathtaking speed with which some products arising from programming like software or websites seem to be developed may mislead over the fact that programming is not a fast kind of work.

Code is poetry – the slogan absorbed by WordPress – stands for one of the many movements of digital poetry coming into existence with the arrival of Zuses computers in the mid 1950s. Artificial texts result from the programmatic exchange of words as for example “Substitute each n-th noun of a text by the n-th following noun of a certain dictionary.“ – one of the experiments of Oulipo (Ouvroir de Littérature Potentielle, Working Group for Potential Literature), formed in 1960 in France, who viewed text as a fabric and fathomed the potential of aesthetics of artificial texts under laboratory conditions.

Code is poetry – in regard to the production of programming code requirements are compressing to efficient because dense production of text. Characterized by the least possible number of lines of code and characters in preferably clear nomination of either the elements of the underlying programming language and the author-chosen elements like variables and functions. The less characters and lines of code the less typewriting for the code-genesis. The more meaningful the nomination, the less semantically unambiguous, the easier the maintainability of the code. Various discussions about the structure of an ideal programming language gather around those basics.

The sense of programming is, similar to assembly line production of bulk goods, to split operations into recurring steps. Being the definition of a first criteria for the usage of programming: the operation to be programmed is anticipated as a concept which is the base for estimating expenses. Anticipating too much speed in this stage means running the risk of exploding budgets. That may result in unmanagable projects. Thus revealing another criteria for the usage of programming: the expenses of programming are measured by the defined purpose of a production step or an operation consisting of several such steps. Transformation into programming will be worth the trouble if expenses for the development of a programmed product and the integration into existing operations fall short of the expenses for operations to be substituted.

This approach is based on the assumption that the expenses of programming could be determined in advance. In fact it‘s only infrequently possible to reuse already existing software or script-libraries without verifying their applicability for the specific project-case. Programming processes contain a variety of basic requirements that are subject to permanent technical change: the chosen programming language itself is subject to change as is our everyday language. Some wellknown script-libraries or frameworks may not be maintained anymore, (new) hardware might be incompatible to some well-established programming-habits, the clients‘ usage of outdated hard- and software might prevent the usage of already established innovations in programming, maybe the hard- and software to be programmed for is already patched specifically and thus may avoid further extension. If in the latter case the documentation is incomprehensible or, worse, doesn‘t even exist, expenses are becoming incalculable. Constantly security vulnerabilities are discovered prohibiting the usage of up to then valid script-snippets. Losses in performance evolving from a certain programming-habit might force to switch to a completely new way of programming for projects being more complex.

All those conditions make up for one basic requirement of a programmer: re-reading. Rereading of own programming code for up-to-dateness and compatibility. Rereading the code of others in order to patch it with own extensions. Rereading of programming languages in order to check for the parts needed to realise individual project objectives. Rereading the code to check the criteria for security and compatibility. That‘s why programmers live in constant consciousness that their code on the date being delivered certainly is state-of-the-art but nonetheless already outdated.

“Re-reading, an activity totally against commercial and ideological habits of our society, calling us to ‘throw away‘ history as soon as consumed (…) so that we have to pass on to another story, buying a new book … re-reading is suggested here to begin, because it solely prevents the text from repetition (the ones not being able to re-read are forced to read the same (hi)story everywhere).“ (translation into English by Regine Heidorn)

Roland Barthes states in 1981.

Rereading is preventing code from repeating his history: reproduction of incompatibilities and security vulnerabilities. Cementing intricate programming and incomprehensible nomination resulting from not reflecting the use of already existing code. Adopting useless functions for the actual project that might become incalculable reasons for misfunctions. Transporting routines that might not have any function at all because they were solely coded to meet specific requirements of the previous project.

“The ones not being able to re-read are forced to read the same (hi)story everywhere“ – this is exactly what‘s happening eg to webdesigners who learned their HTML at the beginning of the 1990s and didn‘t change their habits of code-production. The result are websites based on outdated code and being incompatible to innovations such as mobile internet usage. Superfluous to tell that rereading requires time, same applies for checking the requirements for programming to establish realistic project-budget and schedule.

Code is poetry – on the contrary to prose poetry is dense – few words transport compressed meanings. Meanings also subject to change in programming languages and occasionally producing trivial redundancies. “For the master craftsperson, great code and great poetry are lean and trim, with no excess of words or other unnecessary elements.“ states Matt Ward in Smashing Magazine. Programming is a creative process demanding concentration. Slow coding thus is not a sophisticated postulate of aesthetic polemics but a semantic redundancy, a pleonasm. Which as a rhetoric figure is of ongoing importance because the breathtaking speed with which some products arising from programming like software or websites seem to be developed may mislead over the fact that programming is not a fast kind of work.