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).
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.
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.
Merry Christmas to everybody,
I hope that each of you can enjoy a wonderful day with his/her family or his/her friends, and that Christmas father has been kind with you.
Just a few words on what I’ve done since last Wednesday. I spent some times working on connecting my Wi-Fi module with the websockets that run on our server. I managed to have first results: connection is established and I can send messages. As I don’t have access to the server and Tanguy doesn’t have Internet access, I can’t have any information on what is received by the server, thus debugging is quite difficult. So next steps will wait a bit.
I also had a look to the I2C driver, in order to talk to the capacitive sensor. I’m able to start a exchange but I don’t receive any ACK from the slave. As I don’t have pull-up resistors, it can be the origin of the problems (the internal pull-ups are said to be too weak). I will add pull-up resistors next week, once returned to Paris, and make new tests with them.
The 2 targets are thus in pause, and I don’t have more to say for now.
My goal hasn’t changed: having both Wi-Fi and capacitive sensors working by the end of the holidays.
During the second part of this week, I continued my work with websockets. First, I made them be able to communicate in both ways (in the beginning, I was only sending data, now I can also receive some simultaneously). Then, I tried again to run gunicorn on Heroku. The problem was that gunicorn needs to the port to use in a config file but Heroku allows to use only one specific port that changes every time to deploy. I found a trick that consists in modifying the config file with sed during the deployment. So I was able to deploy our server on Heroku, but we found later that Heroku closes websockets if you don’t use them during 2 minutes, so as we don’t want to ping the server continuously, we will have to deploy our server elsewhere.
Then, I tried to have multiple websockets concurrently. I wanted each socket to have a different URL, the difference being a number at the end of it. With pyramid, it is easy to dispatch URLs with such variables in it and to use the values of these variables for normal views. But aiopyramid that I use to handle websockets like views doesn’t give access to this information. After a long search, I found the problem to be solvable only by adding a line in the code of the library. Later, I also handled the closing of websockets : it crashed on every disconnection, so when we wanted to reopen a websocket at the same URL, it didn’t work. Now, the websockets are properly closed upon disconnection and can be reopened later without any problem.
Next week, I will continue working on the server.