Prototyping a proof-of-concept

This article was originally published on my blog on February 11, 2015.

Last year, from February to May, I was looking for an internship in the US and found one very interesting at Podo Labs. Unfortunately, the US authorities didn’t accept the internship because guys at Podo Labs worked in their apartment (although this is part of the US culture to start companies in the garage…). I learned this misadventure back in August, 3 weeks before the start date of the internship.

As I really wanted to go to the US for this internship, I decided to stay in France, patiently, and find an internship starting in February 2015. Then, I got lucky because a great opportunity was offered to me : boosting a startup launch by making a prototype for a new kind of product ! So, I asked my engineering school, the University of Technology of Compiègne ;-), to pause my studies for 5 months (we call this a « césure » in French). I had a lot of reasons to support this application so my university, which I love for this ability to be flexible, accepted.

It’s a bit early to talk about the business model, but basically, it’s kind of an activity tracker working wirelessly with a smartphone.

Thus, in some days, I became a « firmware engineer », before I even graduated :-P. I was the only person working full-time on the project and I worked remotely. The future CEO, Benoit Blancher, already graduated from my engineering school but wanted to go further so he is doing an extra year in a famous business school in France: HEC. Other schoolmates joined the project since then with key competencies, the project is moving in the right direction !


I have to admit, I am quite young in embedded software engineering,

Boards we used for the Equisense proto

I’ve been studying it for only 2 and a half years now so I can’t even pretend to be mature in this field. Having an industrial vision for prototyping smartly needs experience and as a student, there are too many things to learn and too little time to practice. I don’t have a lot of professional experiences but some gave me key competences and key insights. Moreover, I don’t spend any day without reading about new tech, entrepreneurship and hardware startups. I’m trying to do my best at everything I undertake and I am not an engineer yet but thanks to this unique experience, I tried to act like an engineer with all its responsibilities. In a startup, it implies working on a lot of different things. The best part of it is that I learn while practicing. Here is what I have been doing during these 5 months.

From decision-making to implementing

Arduinos or pieces from littleBits are great to obtain a minimum working prototype rapidly but for the long term, we need to have an industrial point of view. Sure we could have a Minimum Viable Product (MVP) with this kind of hardware in order to get feedback as soon as possible :

A minimum viable product is “that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to give you feedback on ». VentureHacks.

In fact, it is advised to make this kind of MVP and go talk to potential users as soon as possible but for our defense, some people in the team and around us are potential users and know very well what are the expectations of the product we are developing.

Jon Carver, the Senior Mechanical Engineer and Technical Advisor to Jewliebots at Highway1 emailed me after I rolled out the first post in this series to give me the feedback that he thought this post [About User Testing] should be first as you can do user testing even before you make a prototype. This was a great point. Sara Chipps

We also need to consider that :

It is easy to build something that is very minimal and that you can call a “product,” but it is very challenging to build something that is “VIABLE” too. Fast Monkeys.

We wanted to use our time wisely and we would better look for the right parts as soon as possible. AVR microcontroller in Arduinos are great but not what we want for our final product so why should we bother with something we will finally put into the trash one day or another? As a startup, we don’t have a lot of ressources and implementing a new product requires specific skills we can’t always have internally. Designing a PCB (Printed Circuit Board) is one of them. As an embedded software developer, I am able to read schematics and may be able to create a simple PCB design but when it comes to an industrializable product, relying on a development board is simply wiser. That’s why we thought that we have to choose the right development board, with the right MCU, from the very beginning with these considerations :

  • We know that making hardware is not simple : manufacturing is a big source of problems and not as scalable as making software so we checked price and availability of the key components we wanted to implement.
  • The firmware is going to change during the whole life of the product so we need to think about the evolution of the product : I am thinking about power and memory size here.

That’s why we needed to make our first important choices in an environment of extreme uncertainty (by definition) in order to define the hardware and software guidelines.

I thought : « The choice of the development board leads the whole prototyping process »

The hardware architecture (technical choices)

We made extensive research in order to choose the microcontroller (MCU) as this component is the heart of the product. Key criteria were peripheral support, power-efficiency, price, support of the MCU by manufacturers, developers… etc, and also knowledges we have of the different architectures. I personnally spent most of my time developping on ARM Cortex M3/M4 MCUs and had rather bad experiences with PIC microcontrollers (the Microchip IDE was terrible at this time, I don’t know if it gets better since then). I knew almost nothing about AVRs but 32-bit AVRs are in fact very interesting and were great entrants despite a bit pricier than ARM Cortex M with equivalent features. I also ported my attention on the MSP430 from Texas Instrument which I didn’t know but seems to be heavily used.

We need to handle 4 or 5 sensors using I2C which create a maximum data flow of 1kB/second. Some peripherals are pretty slow like the UART which will be used with a Bluetooth transciever and sleep time must be optimized because the final product will be battery-powered. To help us manage easily everyone of these aspects, we decided to use a Real-Time Operating System (RTOS). Based on these considerations, I figured out the minimum memory size needed, the MCU architecture and frequency. This article from AnandTech is very interesting and helped me to have preferences for the ARM Cortex M0 or M0+ architectures. Then I use Farnell’s website to compare different Cortex M0/M0+ microcontrollers : I was able to choose depending on supported peripherals and memory size. I included PIC32 and AVR32 into the comparative table and it actually conforts my choice of the Cortex M0(+) architecture.

Based on the different MCUs I retained, I looked for the appropriate dev-board. There was an interesting board from Atmel but it is based on an AVR32 MCU and the board is too big for our tests. NXP manufacture a board based on a Cortex M0+ MCU but it is a bit expensive and doesn’t carry any sensor while there are several boards from Freescale which are based on cheap ARM Cortex M0+ microcontrollers, embed some sensors and have extension boards available : perfect! These are Freedom boards : FRDM-KL25Z, FRDM-KL26Z, FRDM-KL46Z…

After a discussion with the other people involved in the project, we all decided to buy the Freescale’s FRDM-KL26Z board with the FRDM-FXS-MULTI extension board and I have to say, I was very satisfied with this choice. Freescale provides a great support, a lot of documentation and the Processor Expert plugin which is compatible with Eclipse offers tools for fast-prototyping (I work on a GNU/Linux distro so Eclipse is the most appropriate IDE). But above all, there is (thanks Erich Styger, the author of this blog), which widely covers the use of the FRDM-KL25Z board with Processor Expert on Eclipse. By the way, I also provide some Processor Expert components for the FRDM-FXS boards.

So finally, I was able to propose a complete list of different hardware components in order to start working on the first prototype and more importantly : something we can use to iterate in order to build a scooter using the skateboard wheels.

Building an MVP is all about experimenting and learning.

The first month was aimed to get our first skateboard, so I spent all my time implementing : programming, soldering, designing. Thus, I worked on configuring some sensors and storing acquired data as simple CSV

files onto an SD card using the FAT filesystem. As we wanted to have the files available by plugging an USB cable into the product, I also implemented the USB Mass Storage Device Class. At the end of this first month, we were able to test our prototype in the real world in order to get our very first data, not really to analyse these data and get results, but to let us configure the sensors to have better signals.

Then, I worked on implementing Bluetooth on the prototype and developed an Android application in version alpha. The smartphone app served as an ugly interface to use the prototype to start and stop the acquisition. This was kind of our « first MVP », with some known issues we needed to fix but something that was working for our first demo with a potential user.

A lot of things needed to be improved. First, the CSV format didn’t suit well : acquisition files were too big and it was a loss of time to convert values in ASCII. I implemented a new file type containing a header with important information followed by the raw and packed data. Second, the Bluetooth communication and transmission had some glitches : when the connection was lost, data were lost too. I implemented my own transmission protocol in order to transmit all the data and also pass some commands to the remote tracker.

Then, I worked most of the time on the Android application : implementing small UI improvements, adpating the transmission protocol and file type to save the data and finally by adding a synchronization feature so that acquisition files can be transferred directly to our servers, flawlessly and in an invisible way.

We now have a working tracker and an Android application which is able to start a session, store it as a formated file and send it to the servers. The acquisitions are then processed and key performance indicators are computed.

Conclusion — Never stop learning.

I am now leaving the project for a little while because I am in San Francisco working as a full-time intern at Spire. With Benoit and the help of other young professionals, we have designed a proof of concept that will enable us to show users what services will be offered. Basically, it’s time to have customer feedback and harvest a lot of data. There is still a lot to do regarding data analysis.

Bad choices

Working as lean as possible, we actually made some bad choices. From the beginning, we thought that the final product will work using Bluetooth Low Energy (BLE) because we don’t have a lot of data to transmit (we thought…) and because Apple is not asking for money if we use this standard with Apple products (which is in fact different if we want to use previous Bluetooth versions). The actual throughput of the BLE is 1kB/s (with a pessimistic point of view, but it is important) and the tracker generates 800 bytes of data per second. If we stream data via Bluetooth during the acquisition, the bandwidth is used a bit too heavily. Also, if we want to transfer the acquisition data later, it will take a lot of time (about 12 minutes for 15 minutes of acquisition!). One solution is to compress data. To do so, we would better have more computational power, preferably with a Floating Point Unit (available on ARM Cortex M4 but not on ARM Cortex M0(+)). This is also useful is we want to process data on the fly and make the tracker smarter.

Lessons learnt

This was a startup life, and it made me learn a variety of new things, of new skills. From a recent article entitled Embedded Engineers: 10 Skills You Need Now, I have to mention some :

During the past few months, I’ve been working on prototyping but also, with the other people involved, we have been thinking about the whole process of making a product: we planned the development of the product, we talked with 3rd party companies about manufacturing. I was informed with the main expenses : from R&D to financing communication/marketing. Finally, this experience has been the best professional experience so far!

Originally published at on February 11, 2015.