RoseOnRails – WIP


Yesterday, Yann and I finished the test on the UART communication between the nrf51822 and the STM32F103. We can now light on/off an LED with the required color by writing the corresponding value in a BLE characterstic. We checked with gatttool and it works fine!

This morning we had our presentation where we presented our product, the main people potentially interested by buying it, as well as the price we would sell it at.

This afternoon, we took the final decision of not using optical captors for detecting the train’s position, but simply the Hall sensors, since we already have all the required GPIOs on the PCB and that furthermore, we can simply detect the position of the train as well as knwo on which LED it has passed only thanks to the Hall sensors.

Later on, Noémie, Yann and I worked on the ADC on the nrf51822. More precisely, we studied the datasheet to better understand how it works (which pin to choose for the input, what type of reference : external or internal, etc.) and then we completed Noémie’s code to test the funcionlity. For this, we used an external reference of 1.2V and read the value (with gdb breakpints) returned by the function reading the GPIO pin state. We obtained the expected result.

Finally, tonight, Yann and I did the test for the Hall effect sonsors. For this, we connected our Hall effect sonsor to the nrf 51822, and we implemented a continuous notification of its detected value through BLE. For testing, we enabled the reception of notification with Gatttool and effectively managed to see the activation (0->1) when the Hall sensor detected our little magnet.

That’s it for today. Se  you!

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 software

Hi all.

The last 2 days, we have been mainly busy preparing today’s presentation which finally was postponed to Friday! But it was a good occasion for us to discuss about the following steps to make. This morning we discussed with our teachers Alexis & Sam about the diffculties we have encountered but above all about how we should start to code: the best idea is, according to them both, to go step by step. Our goal for now is, therefore, to be able to command the trains as soon as we receive the PCBs (even if the Android app is npt conceived yet, as long as we can do it through a Web application or even throuhg a shell, it’ll be fine for now!)

We also took the time to clearly define what we need to do from now on from the software point of view. These are mainly: one BLE app to flash on the nrf board of the locomotive, one for the LED controller and one for the railroad switches. Then there is the central station which is almost over by now. I am now in charge of working on the BLE application for the locomotive. I started to write a small program this afterfnoon. I begun by writing a program based on the LEDButtonService app, by changing some paramters, for instance trying to use PWM to light on an LED in one of the characteristic handlers. Talking of PWM, actually I encountered some problems to make it work, I had double-defined functions and variables.. I will look at it again tomorrow, tonight I didn’t manage to understand why it was so ..? I will also dive in more deeply in the code, since there are still some concepts that I don’t fully understand (bondig vs pairing, assert handlers, modules (as in the GPIOTE handler module)…)

See you!

RoseOnRails – still ledstrips, almost over!!

Hey hey!

Today we continued to find out the “apparently mysterious” reasons why our ledstrips didn’t work fully properly! Measuring the duration of our high and low SPI bits on the oscillosocpe we discovered that there were some “little” software bugs (for instance, with the help of Alexis and Sam we found out that since the idle state of the SPI was high by default, it was a better idea to avoid sending a 1 as first bit (else, the first 1 was longer than it should have been and we would send 100 instead of 000 to the first led hence some inexpected behaviour..). Sam’s great idea was just to place the reset at the beginning which very simply solved this problem.) On the other hand, Alexis advised us to first make sure that our experiments were compliant with the ledstrip’s datasheet, especially by making sure that our alimentation voltage was always in the [4.5V; 5.5V] interval. Since the SPI output voltage of the stm32f103cb is only around 3.65V, we did a simple montage to pull up the voltage to +5V (Since the montage is an inverter, our SPI now sends the logical inverse of the original buffer).

ledstrip ledstrip

Having solved this, there was much less randomness in the experiments!

Apart from the LEDs, we also discussed today in group about what had to be done from the software point of view. I did a brief explanation of the central station code done so far, and cleaned up our git repository a bit, adding readmes and comments.

At night, all four of us gathered to think about the Monday presentation and set the general layout of what we are going to say.

Then I worked on the Python code again a bit to clean it up and complete it.

As Yann said, tomorrow we’ll have to prepare the Monday presentation (of course, apart from doing some software since the LEDs have taken us too much time lately).

See you!

RoseOnRails – Python… and ledstrip testing


Today, I continued “playing” a bit with PyCharm trying to get used to Python. Then I wrote a small program that does the client role in a TCP socket connection with my C program where I have implemented the server part. Now I can send the commands through the Python client and see the results on the nrf Eval Kit board (by writing values in the characteristic of an LED in the BLE app running on the nrf).

Unfortunatey, I couldn’t go further in this since we had to test the “pieces” of ledstrip we had soldered. The thing is that this turned out to be waaaay longer and tougher than I thought. In fact, while some ledstrips were perfectly functional (we tested them with a program sending random RGB values to the LEDs in loop, through the stm32f2103’s SPI bus). However, on some others, we observed total random behavior: for instance, some LEDs blinked on the first pieces of the ledstrip, and then the rest of the LEDs were off, or sometimes, all LEDs blinked except one or two! Sometimes, this was due to our soldering (some pieces of wire weren’t well soldered, or sometimes some wires touched…), in which case we resoldered them correctly. But the most disconcerting situtations were those where we had made sure all connections were ok (with the multimeter) but still, some LEDs were off for no obvious reason! Several ideas came into our mind: maybe we had damaged some LEDs in a way that we had changed their electrical characteristics (typically the required voltage for a high state for instance), maybe the voltage drop by the LEDs was too important, in  way that the first LEDs blinked correctly whereas from a certain position on, the voltage was not necessary for the other LEDs to blink anymore, maybe the voltage provided at the SPI output of our mircontroller is too low (3,658 according to our measures with the oscilloscope) compared to what is specififed as the minimum voltage required for a high state for the LEDs…. we discussed about this also with ph and Félix and they gave us some ideas, encouraging us before all to check the voltage drop of the LEDs on some pieces of our ledstrips, as well as check the output voltage of the SPI. It was unfortunaly a bit late (midnight..) to carry out the tests so we will have continue tomorrow. I strongly hope we will solve this “problem” soon, since we have a lot of work to do on the software part too!

See you soon.


RoseOnRails – solder and code!


Still soldering…  Yes, we have a HUGE amount of leds (607) and consequently a whole lot of tiny pieces of ledstriop to solder with tiny pieces of wire. So all four of us have been working on it for a few days now, hoping that we’ll be able to finish it soon.

Apart from that, I tried to find some time to work on my code for our central station. I don’t recall if I had already mentioned, but Hubert kindly implemented the multi-slave functionality in BLueLib therefore I can easily use several connections in one thread (or more). However, while discussing with Sam, he told me that the programming language I’ve been using so far (namley C) is not perfectly apropriate and that Python (for instance) is much more well-suited fr this kind of application (above al for the “intelligence” part of the application which is in charge of verifying that the user commands are compatible with the current configuration of the circuit). Later on, while discussing with Alexis about the same subject, he too strongly recommended the use of Pyhton instead of TCP sockets in C.

Being a bit confused about all this new information (I don’t yet know Python very well, so I still can’t “feel” to what point it’s user-firendly, interfaceable and portabe..), I asked more details on the mailing list and received a lot of good explanation from Sam, Aexis and Matthieu. Now, I’m pretty sure I’ll use a websocket-based connection between the server and the smartphones (users) – coded in Python, an application using BluLib for the BLE connection between the server and the train circuit  – implemented in C, and an application that represents the “intelligence” of the game – coded in Python. C and Python will then be interfaced (with sockets or other useful tools). However, I’ll talk to Sam about this again tomorrow just to make perfectly sure about everything and then start to change my current code… and above all learn Pyhton!

See you guys!

PS: Thanks to all of the groups who helped us today with the soldering 🙂

RoseOnRails – Railway work… continued!

Cut it, solder it, mark it, drill it, place it, light it…. enjoy it!

A whole Sunday of “railway work” for RoseOnRails! Let the photos speak:

RoR - brico

As you can see, we started by cutting our ledstrip in pieces (corresponding to the different “types of pieces of rail” (small, medium, large, staright, curved, etc.). Then we soldered the curved ones (GND<->GND, DIN<->DOUT, Vcc<->Vcc). This took us a lot of time since at first we tried with minute pieces of wire (very difficult to bare and to solder). But then Noémie suggested we rather solder them directly (with the correct curved angle) without wire. We also un-soldered the cables that were already there for the connection (the green, red and white ones) to solder the ribbons directly instead (of course we will leave three of them at the extremities that we will connect to the SPIs of our STM32 😉 !)

The next step was the drilling of the rails and the placing of the ledstrips. See Noémie’s post for the rest of the fun!

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!

RoseOnRails – ble and client/server

Hello all!

Today, I mainly worked on BLE. I started by “discovering” BlueLib, how it was done, and how it could be used. I looked at the example program get_ble_tree (that prints the tree of services, characteristics and descriptors of a BLE connection in a file), to better understand how the code to use BlueLib should be structured. I also tried to add some functionalities to better understand the code (like the possibility to specifiy the hciX local adapter and the macaddress by user, etc.)

Then I tested ge_ble_tree with the nrf example application (the famous LEDButtonSerivce). It worked perfectly well. In fact, once you know how to use it well, BlueLib is actually very handy, and far more useful to my mind, than gatttool, for instance (thanks @Paluche 🙂 !)

Then, I started to program a client/server application for the communcation between the user and the central station. Later on, the client will be the Android user. But for now, I did a simple version where the client is simply an application that opens a TCP socket towards the server. The latter then receives the commands from the client through this TCP socket. Once this was done, I started to use BlueLib to make the server establish BLE connection, disconnection, to print the ble-tree in a file, and to let the user write/read/notify/indicate values to/from characteristics. For this, I wrote a treat-command function that parses the command entered by the client to find out if it’s a connect/disconnect/write etc., and take into account the variables (mac address, local ble adapter, value to write, etc.) For now, it’s not fully finished, but I will very probably finish it tomorrow so that we can start to implement our custom service(s) on the nrf…

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!