RoseOnRails – BLE, pwm, uart and ledstrip


Today, I continued on the BLE application I had started to write for the locomotive’s board. I can now, through the central station, connect to a train, write a value for the speed characteristic and have an LED lighted on in PWM mode with the duty-cycle being the value (0-255) that I had wrtiten in the characteristic. On the other hand, when a button is pressed on the board, my Python client is notified of it. On problem that I have however is that the time needed to write into a characteristic or to send a notification, through BlueLib is much more considerbale than with gatttool. I have tested my program in both ways (by connecting via gatttool and writing in a characteristc; and then by connecting via my central station server and using BlueLib). The delay is unfortunately a big problem right now and I still don’t see how to deal with it :\

This afternoon, Yann, Noémie, and I worked on the uart-based communication between the nrf51822 and the stm32f103cb. We started by flashing two example codes that almost already do what we want (sending characters through the nrf to the stm32 via UART). By writing some values in the tx characterisitc through gatttool, we managed to receive the characters in the rx buffer on the stm32 side 🙂 Then we started to write our own application, based on the example. So we took the ledstrip SPI controller code we had written, and we “dispatched” the two parts (the one filling in the buffer to send through SPI and the one effectively sending it through SPI) in the two codes (the one on the nrf, sending the buffer through uart and the one on the stm32, receiving the buffer through uart and transmitting it through SPI). Well, unfortunately, it didn’t work at the first shot… we will continue this tomorrow, that way we can light on the LEDs through BLE 🙂

See you.

RoseOnRails – ble and ledstrip on stm32f103

Hello all.

Today, I worked on the application I had started to code yesterday (the server app that listens for incoming connections from users, creates sockets to serve their commands, and (dis)connects and write to BLE devices characteristics upon request of users). I implemented the writing part, tested on different machines, and with several boards.It worked fine.

Then I started to code the thread responsible for receving notifications from the devices. The thing is that by doing fork() I could handle several connections with BlueLib (since forking makes two separate processes and not threads, so the memory is not shared). However, by creating threads, I had a BlueLib error telling me that a I couldn’t establish more than two connections (if I got it well, it’s because threads share the same memory and BlueLib contains global variables that are therefore common to all threads (furthermore, BlueLib itself deals with 2 threads..!) so in short, it’s not possible to have two connections since the two threads would have to share the same memory resources). Yann suggested we could do several fork()s, so several processes, to deal with the multislave connection. But since we saw Hubert in the afternoon we decided to talk directly to him about it. He explained how BlueLib worked to us and how we should do to implement the multisalve functionality… but it seemed “a bit” difficult to implement staright away. So he said he would have a look at it and do some improvements and let us know about what he’ll have done. I guess I’ll try the fork() just to see if it works, but I’ll ask Sam’s advice before… I’ll see this tomorrow.

Then I started working with a stm32f103cb (the board ROSE students used last year) since we’ll be using a stm32f103re processor (and not a stm32f407 anymore). I spent quite a long time re-configuring the SPI on it and doing the right connections… fortunately, I managed to light up the leds once again. Then I tried to assemble several led strips (10 on one SPI) to see if we had enough power (and memory for the buffer stocking the bits to send through SPI) to control them all.

Unfortuntely, it was fine up tp 8 ribbons (of 30 LEDs) but then I started to have ram overflow errors. Checking the datasheets, I figured out that we might have some memroy problems since the buffer will become too big with 30 ribbons of 30 LEDs each to control. I’m not sure yet, maybe I did the calcualtions wrong since I’m a bit tried right now, but I’m really worried about this and I guess first thing I’ll do tomorrow is to think about it and determine if yes or no we will have enough memory for our buffer…

That’s about it for now. See you soon!


Hello world!

Leds, Leds, Leds, Leds everywhere…! Well, yes, as Noémie said in her last post, we have been working on the ledstrip lately, trying three different methods to light them on: first, we decided to use SPI&DMA. So Noémie worked on it and read millions of pages of doc (cf. her post “Oh my Doc” 😉 !). Then we thought we could more simply control it with one GPIO and a TIMER. But before, we started with the very simple (but not precise enough) method of bit-banging. Then, we attacked the TIMER method (GPT driver and GPIO control in the callback method). The thing is that the duration of the high signal is as short as 0.4us (the total period is 1.25us, so three times 0.4us, making it three bits to send for a ‘1’ or a ‘0’). This required us to use a 168MHz timer and a callback method every 67 cycles, buuuuut…. the callback fucntion Noémie and I wrote was waaaaaay too big. So today Sam helped me to shorten it a bit a whole lot (by the clever idea of preparing one huge buffer containing all ones and zeores to send, so that the callback method would simply read one bit in the buffer every 67 cycles and send it).

You’ll probably not beleive it… but yes! The whole code was in fact useless! Because even with the optimization, the callback took about 42 processor instructions (so 66 with the 2*12 instructions for entering then exiting the interrupt routine). In short, it’s almost impossbile to use this method if we want to control all of the leds on our ribbon.

So: back to SPI! Hopefully Noémie had already done the beginning of the code (thank you ;)!) So, we changed some bugs and made sure the config was correct (APB1 bus->42MHz->prescaler 16->final freq=2,625MHz which is almost equal to 1/(0.4us) = 2.5MHz). Of course, it was far from working at the beginning. We analyzed the signal with the logic analyser and found some incoherences (there were too many zeroes). As I was desperately trying to understand what was wrong, Sam offered his help 🙂 We reviewed the code and figured out that the code for the generation of the buffer was somehow bugged (writing it just before lunch this noon was obviously not such a good idea!!) In short, after correcting these little mistakes, we tested the code on the led and…. guess what:

led2I’m really so happy. So is Noémie 🙂 Now, we’re sure we can use three SPIs (available on our STM32F407) to control three ledstrips with almost no CPU power required (therefore we think of using it for other purposes, for instance helping the nrf with handling the data it receives by BLE, or even doing other funny things we could do with the leds…).

I have written too much, sorry. Now the priority is to finish the PCBs and to catch up with our lateness in BLE!

See you!

RoseOnRails – motor and LED

Hi everyone!

This morning, Gleison and I re-did the experience to measure the inductance of the motor (we had made an error in our circuit, related to the reference voltage of the ocilloscopes..). We also re-measured the internal resistance of the motor and after several measurements found an average value of 31ohms. For the inductance, we found a value of about 6mH, however the measurement seemed to be incoherent at some point, so we’ll use the inductance-meter Alexis said we would receive in the following days. We then did the Simulink simulation (with the motor controlled with the PWM and the H-bridge) and visualised di/dt with the change in PWM frequency. However, the simulation didn’t re-produce the result we were waiting for and there were several things we didn’t understand and (in spite of researches on Google for help with Matlab and Simulink) didn’t manage to perfectly control. After discussing with Alexis we decided it was just a loss of time to try and determine it so precisely. So we well just take a PWM frequency of about 20kHz.

This afternoon, Yann, Gleison, and I talked about the LED and Yann told us that according to Sam we could simply control the led strip with GPIOs (no need for SPI). While Yann was busy with the PCB, I decided to write the code to control the led strip with one GPIO and one timer (in PWM mode), on our STM32 Olimex board. Since I started this pretty late, I finished it at about 11h30.. and Télécom students know well what that means: “Bonsoir. C’est l’heure svp.” (Hello. Time to leave please.). I was a bit disappointed since I would have liked to test and do the changes until it would (finally!) work. But well, we’ll do it tomorrow then! (can’t wait 🙂 !!)

Regarding BLE, well unfortunately I didn’t have the time to work on it today. I will try to do so tomorrow though.

Challenge + Ble

Good evening !

This Friday occured the ROSE’s famous communication challenge. It went BAD for most. I count myself lucky to be one of the lot whom have finished it before 23h30, it was maddening for the most part, with all the mistakes I made under pressure.

This weekend I worked on my Nordic ble kit, and I managed to flash my board with the example Mathieu talked about. It’s very satisfying. Now I’m studying documentation and code to get an idea on how it works. It going well so far. I’m wondering if Chibios could run on the nrf51822… Is it worth ?

Next is Athens’ Week but I won’t go too far from A406 …


Communication Challenge


Friday it was the communication challenge. It was tough: it began at 8:30 and ended at 23:30. There were several steps to complete. In the first step we had to retrieve the instructions on a server using the STM32 board. The next steps were about listening to sound downloaded from the server through headphones using the board.

In order to get the headphones working, I had to set up the audio codec, which uses I2S. Once it was done, I was able to listen to the first audio instruction by downloading it entirely to the board RAM. It contained the path to the next audio instruction. The next audio instruction was too big for the board RAM so I had to implement a “streaming” system to hear it. Each time a packet containing audio was downloaded, it was put in a queue. I set up an interrupt to fire up when the codec was ready to get a sample (64k times per second) to feed the codec a 16-bit sample from the queue. It worked fine.

By luck, I had not major problems or mysterious bug during  the communication challenge so I managed to finish it the first. Now I can get back to the PLUME project. I hope there will be enough free time during the Athens week (which I will spend in Télécom) to make progress on it.

Day 20: a nice morning

This morning… I slept!

For the first time in a few days, I had some time to rest, which I enjoyed a lot. Since my last post, I have worked a lot on my STM32 for the lab and the communication challenge. We went on until late yesterday (the door closed at 23:30…), but I did it! After exploring non-deterministic bugs, a lot of documentation, and with the help of my best friend Google, I finally reached the final step. There are so many reasons why I could hate myself yesterday (it’s amazing how many stupid mistakes one can make when working under pressure…), but overall it was a very good experience. I am quite proud of what we achieved (basically, audio streaming) and the whole principle of discovering our board features in an ouverture-facile manner was very fun. This challenge was really a platform game! So, thank you, everybody: Alexis and Sam for organizing it, the students for having suffered with me and the alumni for passing by and encouraging us (the cookies were delicious!).

Therefore, I allowed myself to take some rest as a reward. But as soon as the morning was over, I was back in A406! No rest for the brave. This afternoon, Matthieu and I worked again on establishing a first communication between the BLE kit and an Android phone. While he was working on the kit, I managed the Android part. We agreed to develop the apps in Scala (with the scaloid library), which is much more compact and flexible than Java. But first, I had to remember how to program in Scala! So I spent some time reading documentation on Scala, Android, Scaloid, installing Android SDK, Sbt, and so on. I have now a DropScanner app on my Nexus 4… which does nothing yet, except displaying a text and a button. But tomorrow I will try using the BLE API for scanning.

By the way, be careful if you plan on testing BLE apps with a Nexus 4, since before Android 4.4 it couldn’t unbound Bluetooth Smart devices. Of course, I had not upgraded my Android yet…

Communication challenge

It was hard, at least I could make the sound peripheral work, but the shared data between the HTTP Client and the sound management thread didn’t work. Well, a great opportunity to learn lots of things, as well as being familiar with ChibiOS.

Ze Communication Challenge…


Today, we experienced the first ROSE Challenge: almost a whole day coding, datasheet reading, and of course learning! It was fun at times, but over all pretty tough. I managed to establish a connection (lwIP with fix IP address) to the Web with my STM32 and use the I2S bus to generate sound. I tackled a lot with the playback of the sound received through the website, but unfortunately didn’t manage to make it fully work.

Beginning from tomorrow, we’re going to work on our little trains again (Yay 🙂 !) and I’m surely going to work with my BLE kit as well.