Hi everyone !

Today was a hard day with the communication challenge and yesterday also because I spent the whole afternoon in order to configure my connection TCP/IP and to generate telecom paristech’s website in my shell.

Starting from tomorrow my group and I are back on our rails.

See you

Internet through the eyes of the STM32

Today, I worked a whole lot on my STM32 board. First, I had to put some order in my respository and create separate files instead of calling everything via my main function in a single file. This took me a lot of time since there were ununderstandable errors and compilation problems. Fortunately, I managed to fix everything eventually!

Then, I spent hours working on lwIP on the STM32 board. It was much much tougher than I thought! But in the end, I was really happy to see the HTML page printed (through serial-over-usb connection) in my tiny Chibi shell 🙂

Tomorrow is “Ze Big Communication Challenge Day”: a (almost) 24-hours coding challenge on the STM32 board. Looking forward to see what’s waiting for us!!

Day 17: the end is near!

Since yesterday, I worked a lot on my STM32 lab. I have now begun the TCP/IP part, and all the other parts are done! The end is near, I am now more confident in my ability to finish the lab before the communication challenge.

During these two days, I also worked a little on the nRF51822’s BLE stack, by reading parts of the API documentation. I haven’t seen everything yet, but I slowly begin to understand how the stack works. Hopefully, I will understand the whole of it in time to complete our PSSC (programming a scanner app for an advertising drop) before Sunday!

RoseOnRails and STM32

Hi everyone!

Monday, Noémie and I worked on our LEDs and on the magnetic we could us to detect the position. Some things to remember from this day. We order 30m of  LED strip which represent 900 LEDs ! We’ll receive these strips by 7 days. Concerning the Hall effect, we’ve learnt there are two kinds of sensor : one which detect a tension proportional to the amount of current we put through our coil and the other is kind of binary which detect when a threshold is reached. We’re going to use this last type in our train to identify above which coils is our train by modulating the current we’ll transmit binary identifiers.

Concerning my lab work I’d almost finished the serial port over usb on Monday and confirmed it was working properly by doing some tests with the shell implemented through the serial port. I’ve also had the possibility to turn on and off the buzzer through the shell.

Currently, I’m trying to implement the possibility to make a TCP to a web server on my board. I’m also looking through some documentation in order to take part in the conception of my group’s PCBs.

On the board again…

Just can’t wait to get on the board again.

Hello World!

The last two days were dedicated to boards. Yesterday Adele and I played with our nRF51822 dev kit. We managed to flash a little example program using radio to communicate (Benjamin already showed you what it looks like). We also published a little tutorial to help our classmates to make everything work. Then we tried to flash another program using real BLE this time. However it was a little more difficult: we had to write the Makefile because the demo was not shipped with it. In the end, I successfully flashed the software, but it was still not working. Sam explained us today that we had to flash the soft device before. I hope I will have time to investigate more on it very soon!

Today, I kept on my STM32 lab. I tried to make the potentiometer work, but the force was somehow not strong with me today. I will try again tomorrow. In the meanwhile, I managed to make my buzzer work. But as I respect the ears of my classmates, I didn’t try to compose a full 8-bit symphony (yes, this sound really makes me nervous!). Then I started to work on Serial over USB, but it is not yet working. I keep hope alive!!

In addition to that, I have a lot of things to do, especially for associations and internship search. I hope I will manage to finish everything by the end of the week! And also, I’m working on a side-project, but it deals with Web so you might not be very interested in it…

May the force be with you!

RoseOnRails – PCBs


Today was mainly lab session work on the STM32 board. I finally understood the concept of Chibi shell!! I even added some “personnalized” commands to expand the shell 🙂 Funny!

Then it was the “beep” step: run the buzzer of the STM32. It was rather straight forward now that we have well understood the concept of PWM, duty cycle, and so on.

After that, I started to think about how to use lwIP to carry out an HTTP request through the web. Though I haven’t had enough time to go too far in it yet…

This morning I also “played” with my BLE Evaluation Kit. I managed to flash some example programs and test them.

Tonight, Gleison and I started the conception of the PCB of the locomotive. But as Blyste mentioned, we’re still missign a lot of things. So, we rather started by creating issues on Bitbucket, mentioning the components we need for our circuit… impatient to have them and start this famous PCB conception at last 😉 !!!

First step with BLE kit

Hey !

Yesterday, and even the day before, I have worked on my STM32 lab. I am now able to control the trimmer potentiometer. After the incident (Saturday afternoon and evening), it has been a relief to notice that the work that I had done was nearly complete. I have still to work on the UART.

Yersterday afternoon, Matthieu and me also worked on the BLE kit we received this week-end. We flashed the same example as Benjamin did. And it worked. But it was not BLE communication, so we continued.
We wanted to flash ble_app_proximity profile, but there was not any Makefile. So we wrote it. However, when at last, the program compiled, I had not enough time to check its behaviour (and Matthieu told me… nothing was happening).

I wanted to continue this morning, but I can’t access to Matthieu’s session. And the Makefile is really unpleasant to write. So I decided to begin PCB. But the components were not ready on the libraries of PCB Expedition. Hope it would be accessible this afternoon.


RoseOnRails – final steps before the PCB of the locomotive

Hi all.

Today, we finally had the opportunity to talk to our teachers Alexis and Sam about our solution for the implementation of the H-bridge and the BEMF measurement circuit for the motor (of the locomotive). Below are the three solutions we have tackled with so far. Today, after discussion with Alexis and Sam, we finally decided that “the current measurement” method is the most efficient one. The amplifier-based method is definitely too much complicated (further, and OA is often big and expensive…). The method with the 3 transistors works, but is still more complicated than the method using simple current measurement, namely the method have retained. The most interesting about this technique is that it doesn’t require to stop the motor! We can thus measure the BEMF while the motor is running!

circuit_moteur_loco_sol1 circuit_moteur_loco_sol2circuit_moteur_loco_sol3_3

Implementation 1 (OA)            Implementation 2 (3 transistors)      Implementation 3 (current measurement)

At this stage, we know how to control the motor. We have also found the references for the components we need to implement this circuit. The next step is to make the layout of the PCB… surely tomorrow!

Regarding the STM32 lab session, well I worked on the serial over usb connection today, but very little… mostly because I wanted to take the time to discover the BLE kits we received on Friday. So, I installed the necessary programs and flashed some demo codes. For now, I’m stuck with minicom configuration… I’ll have a closer look at it tomorrow.


Day 14: so much to do, so little time…

I have a loooot of things to tell you tonight. Are you ready? Let’s go!

On Friday, Matthieu, Adèle and I spent a lot of time reading several datasheets to compare different SoCs. In the end, only the nRF51822 and the CSR101x series seemed flawless… until we discovered that the CSR101x was really difficult to get. As a result, we definitely chose the nRF51822. The timing was good, since we received our developement kits on the very same day! We also worked on the choice of other components, in particular the button cells, with Adèle spending a lot of time on Farnell. Having filled up a table of the characteristics of all components, we were able to choose. For the battery, we selected a few of them (CR2032 and CR3032, rechargeable and not rechargeable), but we still needed some information on the support availability and actual prices for big ordering.

Setting up a comfortable environment

I invested my Saturday to ensure a better productivity later: I configured my development environment. More precisely, I set up a .screenrc file which automatically opens windows in the right directory, for all the tasks I do when developing for embedded systems and runs the appropriate commands (openocd, arm-none-eabi-gdb ch.elf, git status, emacs -nw main.c, and so on) at startup, with appropriate key bindings in addition. It was a bit difficult at first to understand how to write this file, but now it is done, and I am very happy of the result! When I start my computer, all I have to do now is to plug my STM32, create (or attach) a screen… and program! It may not seem like such a big change, but I know that I was always spending much time opening, renaming and closing tabs, remembering where my openocd.cfg and .gdbinit files were, opening lots of buffers in emacs… And now I won’t have to anymore. Of course my .screenrc is specific to my directories and my habits, but I can help you setting your own environment if you want!

I also spent an important part of my weekend on my STM32 lab, and I have now working semaphores, threads and events!

Today, I worked with Matthieu and Adèle to complete today’s PSSCs: the choice of components and the BLE architecture for drops.

While Matthieu was crying in front of complex schemes of solar panel connectors and Adèle was losing hope to find a CR3032 support, I was busy searching for rechargeable batteries cheaper than button cells and for application notes about impedance matching in datasheets. However, I found neither of them. I guess that we will keep our first idea of rechargeable button cells!

BLE architecture

Afterwards, we considered our BLE architecture. I read the SoftDevice specification and Android API documentation for BLE. Then the three of us discussed about architecture questions: what is the best granularity level, from a consumption point of view? How to ensure atomicity for read and write operations? We designed four architectures :

  • A single service, very generic, with characteristics “OperationID”, “Input”, “Output”. The current operation (read, write, edit, list boxes…) is selected by the “OperationID” characteristics and the semantics of the other characteristics depends on the operation.
  • A single service Message (characteristics “id” and “content”, when the client changes one value, the server updates the other one accordingly) and a service Box to select the appropriate box for current operations.
  • One service per operation, and appropriate characteristics for each one of them. For instance, service Read would have characteristics BoxId (write only), MsgId (write only), MsgContent (read only). In this architecture, there can be a service Authentification, used before any other operation, typically for the treasure hunt.
  • One service per operation and per box. It increases a lot the number of services, but reduces the number of characteristics by 1 per service.

The first architecture is conceptually the easiest, but probably the hardest to implement. The second one may create concurrence issues when several devices are connected. For the fourth one, the risk is to have too much services and exchange a lot of messages just to give the list of services. But in the third case, the problem is the same, except that it is moved to the level of sending the list of boxes.

There is still a problem of atomicity. With the second architecture for instance, when the client reads the message 136 and then writes the message 137, it first writes id=136 (the server updates content=foo), then reads content=foo, then writes id=137 and content=bar, but in which order? The server must wait for both characteristics to be updated or the box will be corrupted. Possible solutions are to add an extra boolean characteristics that could act as a mutex, or to require a short delay (how much?) after each update before processing.

Right now, we don’t understand BLE well enough to decide what the best architecture is. We need to start developing an Android app with BLE API to know what is easy or not to implement and how much messages it represents.

Another idea: maybe we could use characteristic descriptors (for instance the MsgId as a descriptor for MsgContent), but we are not sure yet of what changes between attributes and descriptors, concerning notifications, updates and number of messages. Are descriptors really the same as attributes, but only at a different level, with different semantics?


PHEW! That was already a lot of work for a few days. I will now spend the rest of the day working on ADC and reading documentation for Android development. Then I will rest a little, because next week will be very dense: we must finish our STM32 lab, design the PCBs, learn how to use the nRF51822 and how to develop Android apps… and develop our first app!

Gala, components and BLE

Hello World!

I had a busy schedule this week end, and it didn’t let me a lot of time to work. Fortunately, the Gala was amazing!!

Today we finished the research for the components we will use in our project. We still have a few remaining questions, but we hope that everything will be clear tomorrow. Personally, I looked for a led (and it was really hard to pick one among thousands of leds!!) and a resistor to protect it. I also investigated on how to plug the solar panel on the board. I hesitate between choosing a coaxial connector (because the solar panel we will order uses it) or leaving two pins to connect any kind of solar panel.

Then we tried to think about the BLE architecture we will use. However it was harder than expected, and I think we need to hack a few things in order to really understand how it works. This will be our main task next week, with the design of the PCB.

About the STM32 labs, I didn’t have time to work on the potentiometer, but I will start tomorrow evening (I begin to worry a little bit about this because I have a lot of things planned next week in addition to ROSE and I must have finished the lab by Thursday).

May the force be with you!