Arduino, BLE and Mobile app

During summer 2013 we welcomed two students from MIT for a 2 months internship. They developed Alldoblue, a system that combines Arduino, BLE (Bluetooth Low-Energy) and mobile application to send data from an equipment to the cloud, without having to deploy a dedicated Internet connection.

On this page the two students share their experience ranging from agile development to marketing and demonstration to customers.

Angelique

Hello! My name is Angelique Nehmzow and I am a third year undergraduate at MIT, studying Physics with Biology. This summer, I am interning at Alldonet, teaming up with Austin Liew, another MIT intern, to develop a new feature for the company’s remote monitoring service. Stay tuned for more updates

Austin

Hello

My name is Austin Liew, and I just finished my first year at MIT. I am majoring in Computer Science and Math. I am working at Alldonet as an intern for the summer. My primary task is to handle an Arduino component responsible for data collection and transmission (to a mobile device).

So far I have been programming for a bluetooth module (RBT-001) we are using to send data from the Arduino to a mobile device. At the moment the android application developed by Angelique can request the list of files stored on the Arduino (SD card), download files from the Arduino (SD card), turn on attached LED lights, and configure the microcontroller I/Os. These elementary operations will serve as the backbone for the more complicated tasks handled by the Arduino. The operations of the Arduino are designed not to interrupt ongoing processes, so that it can continue collecting data while sending new files to a mobile device.

Do not try to bend the spoon.Check your premises!

There is a quote from The Matrix which goes: “Do not try to bend the spoon — that's impossible. Instead, only try to realize the truth: there is no spoon.”

To put this another way (from Ayn Rand’s book Atlas Shrugged): “Contradictions do not exist. Whenever you think you are facing a contradiction, check your premises. You will find that one of them is wrong.”

The other day I was trying out multiple approaches to get around a problem of losing bytes when storing packets of data received via Bluetooth into a JavaScript string.

Some bytes were mysteriously vanishing — or so I thought because there was no sign of the unreadable characters (out of the range of printable ASCII ones) in the debug print statements, not even in some ersatz form. However, just because I couldn’t see them didn’t mean they weren’t there (which seems obvious in retrospect, but wasn’t intuitive at the time). As Mr Safa demonstrated, a dump of a string of incoming data (which prints the character codes) quickly confirmed that actually all bytes were there; I wasn’t losing any.

To solve the problem I just had to reassess my basic assumptions (some bytes are thrown away), and in this case it turned out there was no problem – I already had the answer but didn’t recognize it as such.

Sometimes it’s not worth fighting to have your cake and eat it too

A few days ago I had problems integrating an LCD module into the Arduino system. The Arduino microcontroller provides a library to simulate a serial connection over digital pins. This is great because I can use the built-in hardware serial to communicate between the computer and the Arduino, and originally the only other component I had that required serial communication was the Bluetooth module.

As the project expanded, eventually I received an LCD which also used serial communication. It is easy to get caught up in the moment when a system works as intended, and lose foresight on potential difficulties down the road. In this case, I had not read the fine print in the serial connection simulation library documentation, which noted that the Arduino can only receive information from one instance of a simulated serial connection. This in and of itself should pose no problem, as I only need to listen to the Bluetooth module. However, no matter how many times I combed over the code that began to spiral out of control, I could not pinpoint where communication between the Bluetooth and Arduino was being polluted.

On a tight development schedule, it is simply not worth it to force a particular solution. Thus, I stopped trying to force the integration of two simulated serial connections, and forfeited the convenience of a hardware serial dedicated to debugging.

To reduce the amount of code that I had to rewrite, and to allow for switching between using the Bluetooth module over simulated serial or hardware serial, #if pre-processor commands work great for this purpose. Essentially, it tells the compiler which parts of the code to actually compile, saving memory space as a result of trimming out unused parts.

Now the system works great again, with a reduced program file size! (Very important, since the Arduino has very limited resources)

Weekly integration session

Weekly integration session, all parts of the system developed by the interns start working together. We use Trello to manage the project, and bitbucket with mercurial to manage the source code.

Next week we'll start polishing the application.

A little goes a long way: Coding for UI

When I first started working on the app, I focused my efforts on functionality. Only once the bare bones of the app were in place, when I could download data via Bluetooth and upload data to the Alldonet server, did I begin thinking about how I should change the UI of the app to make it more usable and pleasing to the eye.

This change in focus meant a different approach to programming. Instead of thinking about algorithmic functions, I needed to think about attributes and layouts. When coding for functionality, I used default UIs for everything (buttons, tables etc.), and copied code from example applications to make new windows and create views. There were few instances in which I needed something really non-standard. However, when I began coding the UI, I had a precise picture in mind of what I wanted to achieve, so I needed more control over the elements in the app. To gain this control, I needed to learn more about the properties of each element.

‘Flexing my UI muscles’, I had fun playing and getting familiar with different aspects of the UI, primarily the size, color, and arrangement of different elements. It was cool to see how small changes could have a significant effect on the user experience. For example, having a button change color while it is being touched is a small thing to program, but is much more satisfying for the user than having a button which doesn’t give immediate feedback that it recognizes it is being clicked – even if both buttons do what they are supposed to do once they are clicked.

Angelique.

Less Is More

In the day and age of 8 gigabyte RAM sticks and terabyte-large hard drives, it is not uncommon for the everyday computer programmer to go wild with the seemingly endless amount of resources available.

In many situations, unless the task in question is particularly resource intensive, it is not always worth the effort to micro-optimize every line of code. However, when dealing with significantly smaller-scale equipment like the Arduino microcontroller, it is necessary for many projects to squeeze out every byte possible.

There are two types of memory limitations that especially have to be accommodated: RAM and flash memory. In a nutshell, RAM is used by the Arduino to store readily-accessible information necessary to perform its tasks as the program runs, and flash memory is used to store the program that will be executed upon boot-up. Without enough of the two, the program cannot operate correctly.

As features were added to the Arduino, the program size inevitably grew larger. I reached points in the development schedule where I had hit the maximum of both my RAM resources and my flash memory resources.

To reduce my RAM and flash memory footprints, I had to refactor (change the internal structure without changing the output) my code many times. It is important for programmers to consider ways to optimize code later to achieve the same result, such that the way for future development is paved.

Above you can see how the Arduino program’s size changed over time as features were added. Fortunately I’ve been able to keep it to a safe distance from the limit, and as long as I refactor as I proceed, it should stay that way. Indeed, sometimes less is more.

Austin.

Making a product brochure

Just a quick update: I'm working now on a brochure for our app - which is a new feature for the Alldonet service. It's exciting because we're close to being ready with something to demonstrate to customers. The brochure will just be a brief explanation of Alldonet and the app, and I'd like to make it colorful, eye-catching and interesting to read. So I think we still need a few photos to spice it up and then it will be ready to print!

Angelique.

Need for speed / 速度の必要性

When one tries to create a system that works, one needs to be careful that a system works practically as opposed to only working technically. A recent example of this was the data transmission over Bluetooth component of the Arduino data logging system.

Several weeks ago I had successfully coded the functions so that a file could be requested and received by a remote device over Bluetooth. Since this was working I had shelved the job so that I could work on the rest of the system. Only recently did I realize that although the data transfer worked, it worked very slowly. In the modern day, taking 30 minutes to transfer 1.5MB of data is unacceptable, particularly in commercial applications.

So thus the task that remained was to locate and eliminate the bottlenecks that were strangling the Bluetooth communication and widen the transfer tube. The first revision took 226 seconds to transfer two 33Kbyte files. I tried increasing the packet size so that more data was sent in each transfer round (a packet). This worked quite well relative to the first revision and cut the time down to 72 seconds for the same sample. However, for real-world applications this was still far too slow to be a practical solution.

So then the next attempt was to redesign the data transfer process. Originally each packet transfer had to be started by the remote device. So essentially, after the Arduino sending one set of data, it was just sitting in stand-still waiting for orders. I redesigned it so that it would continue through sending packets by itself unless interrupted by a remote device to restart at a certain point. I originally had high hopes for this optimization because I thought the call and response design adding unnecessary padding time to the transfer process. I had not realized however that this will only significantly affect files that require a lot of packets, which was no longer an issue since I had already made the optimization to increase the amount of data sent in one packet. As a result, it ended up only shaving off 4 seconds off the aforementioned sample.

What was left was to suspect that perhaps the most significant bottleneck was that data was not being sent to the Bluetooth from the Arduino as fast as it could. After tinkering and debugging sending data at a higher baud rate, an increase from 9600 bps to 115200 bps; the savings were huge! Now it took 7 seconds to send the sample. Finally, I had a practical solution in my hands.

There were two main takeaways I gathered from this endeavor. One was that in real world applications any functionality is not equivalent to actual functionality. A barely functioning system in some cases is practically equivalent to a broken system. The other takeaway was that understanding the building blocks to system design is crucial to efficiently eliminating the bottlenecks that matter. Not all bottlenecks are worth the effort, especially on a tight development schedule.

Austin.

Product demonstration to customer

Here are some photos from our visit to a customer this morning. We would like to thank them for their time and attention, and also for allowing us to take these photos.

Angelique explains the operation of the Alldoblue application (on an Android tablet).

The visit marked the end of the hard-core development of this project for us, and it was an opportunity to demonstrate what we've been able to achieve in so short a time. Explaining our work to people who had no prior knowledge of it required us to be as clear and engaging as possible, which was a valuable experience in and of itself, but in addition to that, we benefited from their feedback about the project, as they saw it with fresh eyes and their own priorities in mind. In short, then, the visit was a success, and a very positive and enjoyable experience.

As our internship nears to a close, we will be focusing on cleaning up code, commenting, and documenting our work - so that we can 'hand over the baton' and make it as easy as possible for the next person to continue our work here at Alldonet.

Angelique & Austin.

Frying a Babel fishモバイルアプリで複数言語のサポート

Presenting – AlldoBlue in Japanese! The app now has two language options: English and Japanese. The app will automatically detect the device’s language settings, and display itself accordingly.

The ‘secret’ behind this is very simple. All the strings used (for buttons, labels, table headers, alert popups etc.) are saved as global variables in xml files (one file for each language). Two strings which say the same thing in different languages (and which are therefore in different files) are referred to by the same name. That way, all the javascript code has to do when it needs a string is, instead of creating the string, refer to its name. Based on the device’s language, the app knows which strings file to access, and so whenever the code names a string it would like to use, the string returned will be in the appropriate language.

For those of you unfamiliar with the book The Hitchhiker's Guide to the Galaxy, a Babel fish is “probably the oddest thing in the Universe... if you stick a Babel fish in your ear you can instantly understand anything in any form of language.”

Angelique.

Video presentation of AlldoBlue

Your browser does not support the video tag.
We cannot play the video presentation of AlldoBlue.

The presentation video of AlldoBlue, the summer internship project of Angelique and Austin, is ready for viewing! It is a two-minutes demonstration of real-time data logging, local data collection via Bluetooth, data display on mobile, and data transfer to the cloud. Check it out!

Last day

Yesterday was my last day at the Alldonet office!

Interning here was an interesting and varied experience – as well as learning how to use Javascript to make an Android app, I visited a company to demo it, and I tried my hand at making a video to explain how it works. Overall, I feel like I was able to achieve a lot in a relatively short period of time, and to get involved in different aspects of the company.

I especially enjoyed the working atmosphere. There was a good team spirit; Laurent, Austin and I worked independently, but coordinated closely and were in constant communication. Though sometimes I got stuck and that was frustrating, it was encouraging to know that they were always available and very willing to help.

My thanks to Laurent and everyone I met at S-Cube. They were all very kind to me, and I will remember my time here fondly because of it! I will be keeping up to date on Alldonet’s progress, and I hope you to join me :-)

Angelique.

Passover引き渡し

Although Angelique officially finished her internship last week, I have a few days remaining to complete my Passover and by extension my internship at Alldonet.

For my remaining days I need to clean-up the code I have now and write up a README file that documents the architecture of the code, including any particular design points that may not be obvious. Any experienced developer or user will understand that an accompanying README file is probably the most useful document for using or developing software. Trying to plow through the intricacies of the system architecture individually is typically too time-consuming and inefficient a task to be worth it. For the development cycle to be reasonably maintained for any project, it is crucial for solid communication between developers.

Once these tasks are completed, I can officially “pass over” my work to the next developer, and make the learning process for that developer as smooth as possible. This way, my work will continue to live on beyond my internship. It will mark my coding project to date, and knowing that it will not end after my involvement is over brings me some comfort that my work can evolve.

Austin

Farewell送別

今日は、皆さん。今までいつも英語だけでブログポストを書いたけど、今回は日本語でも書いてみます。
Hello everyone. Up until now I’ve written these blog posts in English, but this time I will try writing this one in Japanese as well.

この二ヶ月半は結構楽しくて、面白かったです。たくさんプログラミングのことをサファ社長に教えてもらったし（C言語とかソースコードの片付け方とかコンパイラによる最適化とか）、色々な名所で観光したし（インスタントラーメン発明記念館とか手塚治虫記念館とか）、多くていい経験がありました！アルドネットに働いた前に、「いい経験が取れるかもしれない」と思ったけど、本当に良かったです！
These past two and a half months were quite fun and interesting. I learned a lot about programming from Laurent (like the C language or how to clean up source code, or compiler optimization), went sightseeing at various famous places (for example, the Instant Ramen Museum and the Osamu Tezuka Museum). I had some many great experiences! Before working at Alldonet I wasn’t sure if it was possible to have so many great experiences, but it really turned out well!

では、これからどの道を行きますか。もちろん、大学に戻らなければならないのに、一緒懸命日本語とコンピュータサイエンスを同時に勉強します。来年の夏にもう一度日本に来るつもりです。関西地域か関東地域に来るかもしれないけど、是非日本の中でどこかに来るつもりです。
Well then, what path will I follow now? Of course I have to return to university. However, I will try my best to study both Japanese and Computer Science simultaneously. Next summer I plan to come to Japan again. I don’t know if I will be coming to the Kansai region or Kanto region but it will definitely be somewhere in Japan.

サファ社長とS-Cubeの皆さんに本当に感謝します。皆さんがいなければ、私の経験に比べると、そんな経験の方が良くないと思います。皆さんを是非忘れません！
Thank you Laurent and everyone at S-Cube! Without all of you, my experience would have not have been as great. I won’t forget any of you!