Makahiya, Week 17


During the end of this week, I did what I expected, that is continuing to integrate features on the dev branch and thinking about how to bind a string to a servomotor and where to put the optical fiber on the plant.

Then, we found some bugs in the new features that Sylvain added on the server and on some usages of the websockets that I hadn’t tested until now so I fixed them.

Monday, we will receive the PCB and we will see what needs to be fixed.


Makahiya – websockets, music & server

Hi everybody,

During the last 3 days, I worked on the websockets, the music downloading and a bit on the server.

As said in my previous post, I had some problems with the websockets: sometimes the connection between the plant and the server couldn’t be established and I didn’t know why. So on Thursday morning, I carefully reviewed my code and made several tests in order to find the origin of this problem. What appeared from these tests is that when one connection was succesfully established, I had to wait for a certain amount of time in order to have another successful connection. So I made the tests by properly disconnecting the plant from the websocket instead of simply shutting it down. And this solved the problem. On the server, there is a mechanism that periodically checks if the plant is connected to the websocket and if not, close it. But if I try to reconnect the plant to the websocket before it has been closed, it creates problems and most of the time doesn’t work. It was a good news to finally solve this problem.

On Friday, I worked a little on the server, to improve it’s appearance and make it send messages to the plant. But the tests I did to check if my modifications worked well didn’t cover all the cases and Tanguy had to make some corrections after having run other tests.

After that, I decided to work again on the music download. But this time, I tried to first download it in Flash and when the flash is full, read the music from the flash. I used Arnaud’s code (that he had himself taken from someone else) to write in flash and implemented this idea. And it worked well: on Friday evening, I was able to download 900ko of music and to play it. After that, I tried to use the flash as a circular buffer in order to be able to play longer music. And on Saturday afternoon, I managed to do it. There is still one (small) problems: the sound sometimes ‘freezes’ for some milliseconds so I will try to find the origin of this problem if I have time.

Before we receive the PCB (which should happen tomorrow afternoon), I will integrate the wifi code in the dev branch, the one that holds the code that will be flashed on the PCB. And as soon as we receive our PCB we will test them and finalize our project: add the whole logic (properly react when the user ask for turning on a led for instance).

Makahiya, Week 16.5


During the first part of this week, I began with adding the servomotors to the PWM driver. I thought it would be easier, but we are lacking timers. We need in total 24 PWM outputs for the Leds and the servomotors and we have only 6 timers to do it, but one of them must be used for the system ticks, which leaves only 20 channels. So I had to use virtual timers for the servomotors.

I also began integrating some features on our demo code, we won’t have our PCB before Monday, which is quite annoying. I also tested the possibility of streaming music with Bluetooth instead of Wi-Fi as we have difficulties to make it work, but I could transfer files at only 9 kilobytes/second which isn’t sufficient.

Until the end of the week, I will continue integrating other branches that are ready and think on mechanical aspects of the project.


Makahiya – capacitive sensor & alarm

Hi everybody,

Since last post, I worked on the capacitive sensor and on alarms.

For the capacitive sensors, I integrated the algorithm previously developed. It works pretty well with the sensors pad of the evaluation board: I’m able to detect touches. I didn’t encounter specific problems for this integration. Next step will be to finely tune the algorithm settings with the sensors glued to the leaves, but I’ve estimated that it’s better to do it directly with the PCB as I have other tasks and problems to solve before.

The other topic which occupied my time is the addition of alarms. Indeed, we want to be able to use our plant as an alarm clock with both sound and light. First, I tried to implement this mechanism on the server side (and the commands would have been sent to the plant at the awakening time). After several hours of vain intents, I made a break and thought that in fact, it could be interesting to have a more reliable alarm clock, one that doesn’t depend on the internet connection. And thus, it was no more necessary to implement the timer on the server. So I implemented only the settings selection on the server and the alarm is created directly on the plant side. When you create your alarm, you send a list of commands to the plant that will be executed at the awakening date. These commands belongs to 3 categories: sound to play (for the moment, you have the choice between 3 ringtones), lights to turn on and servomotors to move. Doing and testing this functionality showed me that I wasn’t able to play several music sequentially, so I had to correct this point (it was simple).

During the end of the week, I want to solve the last major remaining problem: the connection to the websocket which doesn’t work perfectly. It works sometimes, and sometimes not. So I want to find what is the cause of this strange behaviour and to correct it.

Makahiya, Week 16


This Friday, I added higher level functions to control the LEDs so that it would match the commands that the server will send. I also did some modifications with the server to avoid some bugs when the user passes inconsistent values or if the plant disconnects.

Next week, we should finally receive our PCB, in the meantime I will add other functionalities to the test code that we will flash on our cards to see if it works and then we will see what needs to be corrected.


Makahiya – music download & RTT

Hi everybody,

Since last Wednesday, I spent most of my time working on the music download. And it still doesn’t work, unfortunately. On Thursday, I found that on many set of bytes sent by the WiFi module to the microprocessor, one or two bytes were not received properly. But the ‘end of frame’ bytes were received, so this loss occurred in the middle of the frame. After some inquiry, I found that a noise error was raised by the serial driver. Alexis first advised me to directly connect the GROUND of the 2 boards, but this doesn’t solved the problem. Then, again following his advice, I grouped the RX, TX and GND wires together, again without any visible results. I also tried to slow down the UART speed from 921600 baud to 115200 baud. With that baudrate, communication works well (no more bytes loss) but the sound still doesn’t look like music. Some initial buffering of data seems to improve a bit the problem (the sound looks more or less like the original music during the first seconds). For me, this confirm my opinion of a transmission rate which is too slow. But it shouldn’t be the case as 115200 baud is supposed to be enough for a mp3 encoded at 96kbps. More work is thus needed on this topic.

On Friday afternoon, we had to make a presentation of the advancement of the project.

Yesterday afternoon, I worked on RTT, a function offered by the SEGGER probes to create a bidirectional serial communication through the debug wires. Using it to send and receive messages is really fast forward, but I wanted to be able to use it transparently in ChibiOS, like a common serial link. So I had a look at how to implement the Base Sequential Stream interface. This took me some time because of the RTT Client proposed by SEGGER. In fact, this tool sends ‘\n’ when you press ‘Return’, and ChibiOS shell waits for a ‘\r’. For the moment, I simply convert ‘\n’ to ‘\r’ before sending it to the shell but this is not a definitive solution, just a temporary bandage.

Next week, I will work on combining the capacitive sensor with my algorithm used to detect touches and on the music download, until we receive our PCB (we still don’t know when they will arrive).

Makahiya – server, capacitive sensor and Wi-Fi

Hi everybody,

The beginning of this week has been quite productive. Indeed, I managed to have different tasks reaching a functional state.

First, I worked on the server. I added several pages to provide an interface that allows the user to trigger all the actions that the plant can perform. I also improved the login/logout functionality. For the front-end, after some discussion with my classmates, I chose to use Bootstrap. It allowed me to have an acceptable-looking website in a short time.

On Tuesday, we received the new FDC evaluation board (for the capacitive sensor). This time, I connected the pins very carefully, entirely reviewed my code and tested it. After some minor correction, I was able to configure the sensor and to read data by polling it. After that, because polling is a bad thing and that in that case, it can be avoided, I implemented the part of the driver that waits for an interrupt (that signals that a new set of data is available). With this, the driver seems operational to me. Next step will be to connect it with the detection algorithm I wrote a few months ago.

Finally, I also worked on the Wi-Fi module. I greatly improved the websocket part of the driver and after the corrections made by Tanguy on the server side of the websockets, it worked very well. Like with the capacitive sensor, it was done by polling the module. And in this case also it was possible to avoid it by using an interrupt. So I tried to implement this part of the driver. I had some problems to find a pin on which the pulldown resistor worked (because on the 2 first  I tried, there was a pull-up somewhere on the board…). And I had also some (stupid) mistakes on my code that make me lose some time. But it forced me to carefully review my code and thus to improve it, so it’s been useful. So now, websockets are fully operational. I also improved a lot the management of the errors and started to implement the decoding of the commands that will be received through the websocket. As one of these commands is to play a music downloaded from the server, I tried to re-use the code I’d already written for this. And the last error re-appeared unfortunately: the Wi-Fi module takes too much time to answer to my requests. And I don’t have any idea of possible origins of this problem. I will try tomorrow with another Wi-Fi network to see if it changes something, but I don’t hope too much.

The end of the week will be dedicated to solving the problem with the music and to connect the detection algorithm with the capacitive sensor driver: assembling several parts together in fact. It’s the beginning of the integration phase and this is a good news.

Makahiya, Week 15.5


This week, I expanded the test code for our card by adding a driver for the LED’s that should handle both hardware and software PWMs (we couldn’t put every LED input on a pin that allows hardware PWM). But I didn’t test it because we still don’t have our PCB, we should have it next week.

I also fixed some bugs regarding the websockets on the server : there was a problem when the plant tried to speak when no client listens and it is now also possible to send commands to the plant directly from the webpage without connecting to the server through a websocket.


Makahiya, Week 15



during the end of this week, I managed to have a communication through Bluetooth, now it is like if I had a Serial port over Bluetooth. I also wrote a board.h for our card and it seems that the refactoring I did with the server code fixed the problems I had noticed before the holidays.

This week, we should receive our PCB, so we will have to integrate everything.