Categories

RoseOnRails – The end = a mixture of relief and nostalgy!

This is my last post on this Logbook (#nostalgy). It’s not going to be so long! Just a little message to say that I really appreciated ROSE and the great amount of things I learnt during this UE. Most of all, the way I learnt them was quite often “harsh” enough so that I’ll never forget them again (cf. remap registers… almost 2-3 days spent “debugging” an UART communication just because of this!).

True, there was a whole lot of work, a whole lot of stress, a lot of surprise also (as expected 😉 !). But on the whole it was an unforgettable experience of learning and having fun at the same time, with cool teachers and great classmates 🙂 !

Thank you all and hoping to see you soon some day again 😉

One little photo (just for le “swag”) :

IMG_5018

RoseOnRails – switch to node.js !

Hellllo 🙂

A whole lot of things have been happening lately.

After having (finally!) solved the UART “problem” as explained in my previous post, we were ready to test the intellligence module. While having done so, though, we found out that there were several bugs in the database and in the code. Therefore, the game, did not fully work as we expected! Furthemore, there were problems with the BLE communication, or more precisely, BlueLib, since we see that the commands are well sent through the TCP socket to the C server but not to the devices… so it can only be BlueLib…

Yesterday, we had to make a point to Alexis & Sam about our advancement and the current state of our project. Since the intelligence module still didn’t properly work and that we had random problems with BlueLib, we couldn’t have a proper demonstration unfortunately. But the imporant hting is that Sam & Alexis advised us to use noble (node.js module for BLE central applications) instead of BlueLib!

This morning, I spent a lot of time to correctly install noble (there are a lot of “tricks” in the installation process, for instance you have to rename files, else Ubuntu doesn’t find the one it’s looking for, you have to downgrade to Python2.6, etc.). Then I started looking at the code. Before this, I tried to learn Javascript with CodeAcademy, but I guess it’s not necessary yo fully learn it, since the code is fairly inderstdandable. However, in order to make sure BlueLib wasn’t functional in our case, I did several tests in order to find out where the problem came from the day of the presentation. The result was that, with my test program where I simply connect to 1-3 devices and send comands/receive notifications, everything works fine, but as soon as we test with the intelligence module (where we connect to up to 6 devices), there are timing issues and some commands are not taken into account by BlueLib. Gleison checked with the BLE sniffer that indeed the BLE commands weren’t sent. According to him, it must be the fact that we connect to too many devices that gives rise to these timing issues and lost packets. This sounds logical since the way Hubert has coded the BlueLib multislave functionality is that he uses several threads, each safely using resources thanks to mutexes. When we have more than 2-3 devices this process takes too much time and we believe this is what leads to timing issues and unsent commands/unreceived notifications…

After having seen all this, I firmly decided to switch to noble because I want our demo to work 100% on the presentation day. So I discussed with Benjamin who has already used this, and he told me that it’s not that difficult to use even if you doesn’t know javascript. So I started coding the central station in node.js using noble… Meanwhile, Noémie impelmented the code for the socket-based communication betweent node.js and our “gateway.py” module (that links the user to the inteligence modue and then to the node.js BLE app). I hope we’ll manage to finish it at most tomorrow night! Then we can do the test with the intelligence module.

Stay tuned 🙂

RoseOnRails – Good newS!!!

Hi.

Yesterday and today, I spent a lot of time trying to resolve the big mistery of the UART communication between our nRF51822 and our STM32f103RE. Yesterday, we found out that actually, there was still an error in our board.h file for the nRF regarding the TX pin, which we corrected. But this wasn’t the error… I checked also everything in the Makefile, switched to the new verison of chconf, mcuconf anf halconf files (just in case), and checked in the sources of ChibiOS and the reference manual of the STM32f103xE that we had the right configurations. But when checking if the program entered the interrupt handler (by putting a breakpoint then by toggling a pin’s state), we got that the answer was no. To make it short, the signal was received on the RX pin but didn’t seem to be interpreted by the STM32.

Today, Sam gave me some precious advice to try and find out the origin of the “problem”. we used different techniques to make sure the RX pin wasn’t read correctly: first we looked at the USART1’s SR register’s RXNE bit by writing a function that returned this value, the RXNE was 0 ! Then we “mirrroed” the state of the RX pin towards another one (i.e. we toggled its state accroding to that of RX), the result was as expected (we saw the right UART signal with the correct timing -> 26us for 38400 baud). So what wasn’t working? We checked the clock as well (STM32_PCLK2 as the datahseet specified)…. then, Yann pronounced the word “remap” and it made Sam almost jump!! Actually, what we had forgotten to do was to configure one bit (yes, just one *** bit) to mention that our AFIO (pin 7) had to be remapped to the USART1_RX register!!!! Now it works… no wonder! I’m actually rather happpy to have learnt it this way, I’ll never ever forget it again in my whole life…

On Saturday nigt, Glesion and I spent quite a certain time thinking about how to deal with the electromagnetic and magnetic noise of the motor distrubing the Hall effect sensor. After discussion, we found out that the debouncing method wasn’t a very good one, since the perturbation is, in our case, continuous (it happens all the time, before and after the detection of he magnet) whereas the debouncing is a method used usually when the perturabtion occurs after you the event is detected. We then thought about shielding the motor with a metal case but Alexis said it would be too costly and diffciult. We thought also about a low pass filter, but its implementation in software would require too much calculus and power consumption for our nRF51822. The other idea was a hardware low pass filter. But before this, when discussing with Alexis, he suggested we first put the sensor as far away from the motor as possible (in order to avoid that the  magnetic field of the motor disturbs the sensro), and then, that we use a lower pullup resistance (this time, in order ot avoid the electromagnetic perturabtion). So we configured the pin as no pull and now use an external pullup resistance of 1.5kOhm (the internal oullup resistpr if the nRF51822 was much higher: 13kOhm). It still didn’t work as expected. So we finally, soldered a capacitor to have a hardware low pass filter and now it works as expected. Ouf! One less problem 🙂

What else?… Oh yes, after the LEDs worked, I completed the code of the central station to send commands to the ledstrip according to the encoding protocol that Yann defined (send <strip num>, then send <led num>, then <r>, <g>, <b>). In parallel, I wrote the Python function called from the Inteligence module to sned the 5 commands in one shot. The latter is still to be improved….

See you soon, gotta go make things work now… !

 

RoseOnRails – the last days… work, work, and make it work!

Hi all.

On Thursday, I finished implementing the “gateway”, i.e. the Python module where I receive commands from users (through websocket), commands from the Intelligence module (through Python function calls), and send commands to the Intelligence module (through Python function calls) and to the TCP server (through localhost TCP sockets). The latter then sends the commands to the train circuit (through BLE with BlueLib). Then, since I had finished this, I started looking at the Intelligence module on which Yann was working. I completed our database with the name of the sections (A1, etc.) and the portions of ledstrips that were associated to each section. When Yann finished implementing what he was coding, we started “merging” the code of the Intelligence module and the gateway, in a game.py whose name reveals all! In short, we just created several locoThreads and a turnoutThread controlling the reservation procedure. In parallel to this, we launched the websocket server and the TCP server by importing the gateway module. It took me a whooooole lot of time debugging the code, while Yann was helping Gleison with putting the turnout PCBs under the paltform. When I “almost” finished, I decided to help them too since three people would make this difficult task much faster. We almost finished soldering and placing all of the PCBs on Thursday night, but some work still remained.

On Friday, we finished doing this first. Now all 4 PCBs are placed and we have tested that we can control all 25 turnout motors (there are “on average” 7 turnout motors controlled by each PCB) through BLE 🙂

Then as Alexis had given us our new LED PCB, Yann started testing it by flashing our beloved program that controls the ledstrips through SPIs and communicates with the nRF thourgh UART. Guess what? The UART still didn’t work 🙁 🙁 I was really disappointed… first, we tried to debug with a serial communication with the board and using minicom. We “lost” a lot of time trying to figure out why minicom displayed a series of garabge charaters with no reason… usually this is due to speed disaccordance but we were fully sure all of the configurations were correct. Finally, we discovered that it was simply due to the micromatch connector being a bit loosened!!! In short, we managed to solve the problem by kindly asking MarcO his for a while… Then, in order to understand what was wrong with the STM32<->nRF UART communication, we decided, thanks to Sam’s advice, to test the same program on his evaluation board (which had a nRF version C0 like the one on our PCBs) and another STMF103CB (and not RE but this is not supposed to change almost anything). Of course, all worked perfectly well: we managed to control the LEDs one by one thorugh BLE. So why didn’t it work on our PCB? At first, we thought we had forgotten to fetch in our ChibiOS mailbox (!!!), but by coming back to the correct version with git, we found out that the problem wasn’t this. Then we thought maybe the spiSend wasn’t at its right place (not in a loop), which we corrected (but this wan’t the problem either..). In fact, the problem is not even linked to the SPI nor the mailbox… it’s simply that we never enter the interruption routine that handles the UART reception in the STM32 module..

In short, at the end, everything was similar to the program we had flashed on the eval Kit boards and it was sill not working on our PCBs. I was getting mad! What on Earth was wrong with our PCB?? The only explanation can be a possible mistake in the board.h (STM32 and/or nRF ‘s) or the maybe a slight difference between the STM32F103CB and the STM32F103RE. I was really eager to find out, but I was really tired. After having struggled again a little bit with teh code while Yann was helping Gleison with the circuit, I finally decided to use my new friend “Ze oscillo”, but I couldn’t since I needed someone to look at the oscllo and press STOP, etc. while I would place the sonde on the PCB. But Gleison and Yann insisted that I give up and help them with the circuit, which I finally did.

The rest of the night we were busy putting in place the new supplying scheme that Alexis suggested we do to supply all of our 600 LEDs on 9 different supply points.

See you guys, stay tuned!

RoseOnRails – WIP

Hello all!

Yesterday and today I “lost” a lot of time dealing with out Hall effect sensors. More precisely, yesterday, I tried to test that the sensors detected the magnets when the latter where put on the table. To do this, I activated BLE notifications that informed the state of the pin (after a pin read) in loop. The sensors where placed in the configuration that you can see in Yann’s post. The result was that they were detected on the table with no problem, but when put under the rails, the value of the pin read was always 0, in short no magnet detection. I then tested the same model of latch (our Hall effect sensors are A1221 latches) with our Nodic Evaluation Kit (in case the problem was due to out PCB) but still obtained the same result.

Since Gleison had previously done some experiences with the Hall sensors (another model though), I asked him some help. He suggested I don’t activate notifications in loop, but rather use an event-driven detection. We searched and found out about app_gpiote event handlers in the Nordic SDK. I then implemented one that after each pin state toggle increments a counter (one for eahc latch). That way, we can know how many latches we detected. This seemed to work well, but still not with the magnets under the rails. The worse was when we switched on the motor: the counter went up to 2xxx without any magnet (in fact, it’s because the sensor detects the magnetic field created by the wire loops around the motor)!!!! Since “the oscilloscope is your friend” is my new rule of ROSE, I suggested we use it to better see what really happens at the pin. Gleison started to do this and I rather switched to another task which was the completion of our Central Station code. Gleison said he obtained very weird results…. yesterday afternoon, he told me that there was an error in the way we had soldered the hall sensors (in fact we had connected the GND and Vcc of our PCB to the rails…!!). This led the nrf to burn when Gleison mistakenly switched GND and Vsupply when supplying the board…. I’m so sad+nervous about this “event” that I don’t really want to talk more about it… now, while waiting that Alexis kindly solders another loco PCB, we can’t do much else 🙁

As I mentioend above, I also completed the code of the Central Station to control the switches, and improved some little things in the code. Yesterday afternoon, since we couldn’t work on our dead PCB anymore, we coded the intelligence part. I completed the code of what I have called the “gateway”, i.e. the interface between the player, the Intelligence module, and the circuit of the train. Now, it seems to be complete. I have implemented the functions to be called by the Intelligence module and compelted the part requiring me to ask the user his choice of section (the section where he wants to move to) through the websocket, and (wait to) receive the answer to transmit it to the Intelligence module. Today (or maybe tomorrow) we might have the time to test the whole code (gateway + Intelligence module).

Yesterday, we also completed the Trello – a useful tool for organizing our tasks until the (very near) end of the project.

Humm, I think I have said everything for now! See you!

RoseOnRails – the train is on!

Hi all.

Well as you have seen in my teammates’ posts, a whole lot of thigns have been going on lately in our project: the LEDs are shining everywhere in the circuit now, and the little loco is running 🙂

As Yann explained, yesterday, we finished to complete the circuit with LEDs and tried to command them through BLE, which we unfortunately didn’t manage to achieve, since the UART communication betweeen our nRF and our STM32 failed to work. It might be because of an error in the pin decalarations in the board.h file (which would lead to the nRF TX pin connected to the STM32 TX pin, both configured as output!) The thing is that now when we measure the TX pin on the nRF we have an anormally low amplitude (0.5V when the pin is set). According to Alexis, this is very probably due either to a shirt circuit between this pin and GND (which I verified wasn’t the case) either the nRF’s internal P transistor which is damaged, which we therefore think is the case. In short, we decided to use another pin for the TX on the nRF (since on the nRF we can choose the pin we want to use for TX and RX, contrary to the STM32 where it’s imposed by hardware). The nRF RX pin got damaged too but it doesn’ matter because we only use TX (nRF) -> RX (STM32). So Alexis kindly soldered 2 other nRF pins (too smal to be soldered invidually) to the RX pin on the STM32. We still have to test it but haven’t had the time this afternoon.

This afternoon, we also dealt with the “problem” of the motor on the locomotive. More precisely, we noticed that the motor couldn’t start up when directly supplied wuith 22V (which is the voltage of the rails). However, when supplied with 10V then progressivley up to 21V, the motor did continue to turn. We tried to “simulate” this progressiveness with progressively rising our PWM’s duty-cyle, but still, the motor didn’t want to work. We then thought it might come from the OCP (Over Current Protection) of our HBridge which might just deactivate the output when the current drawn was above 3.5A. But, when trying to verify this with the oscilloscope, we found out that the soldering of the motor’s wires on the PCB was far from being perfect, which led to the motor randomly stop working when tilted to one side for instance…!! In short, after having discussed with PHH and Olivier and having read the datasheet of the HBridge, still without any rational explanation, we went to see “doctor Alexis” who “cured” our loco by replacing the HBridge (which was damaged because of an over current and a lack of decoupling capacitor) and adding another decouplig capacitor to the power supply pin. Furthermore, he advised us not to supply the rails with 22V any more but rather with a maximum of 15-18V. After having done all this, we now manage to control the motor thourgh BLE. See Noémie’s post for the fabulous video 🙂 or rather, come see us in a406 for the stunning live demo (@Sam)

Next step(s) -> Test the Hall captors (we soldered them tonight on the loco), test the turnout PCBs (Alexis kindly finished to solder them all 5 today), control everything in BLE.

Then of course, we have to finish the intelligence code for the game…

See you very soon!

 

RoseOnRails – a little bit of beauty

Hey hey!

Hot news… and beautiful photos.

ledstrip4 ledstrip7

Well, as you can see, this weekend we spent a lot of time on our ledstrips (once again!). On Friday, Alexis helped us a whole lot by properly soldering connectors to our beloved PCB so that we can easily test our ledstrips by simply connecting and disconnecting the power supply and/or the ledstrip itself. After having prepared the correct boards, we could then test our three SPIs and make sure all worked fine. However, the UART still doesn’t seem to properly work (as a reminder, we use it for the communication between the STM32F103RE and the nRF51822). We hacen’t much ahd the time to see where the problemt might come from yet, due to all we had to do with the ledstrtps.. but we’re going to have a look at it today for sure.

Yesterday, we spent the whole day testing our 22x LED-ledstrips, re-soldering the broken wires, and replacing the defectuous LEDs… It took much longer than we thought and was way more tiring. Once we were (almost..) sure that all was ok, we decided to paste them below the rails, which we did in the afternoon. It’s not fully finished yet. Hopefully, today we’llfinish this and then kindly ask Alexis to help us with the PCB of the loco which seems to have a defectuous capacitor, as well as the PCB of the turnouts that we need to place on the circuit a soon as possible. Then we can test everythig with the little BLE apps we have already prepared, hoping that all’ll work fine 🙂

See you very soon !

RoseOnRails – PCBs, tests, good news, bad news!

Hello world!

Yesterday, in the morning, we started to do the interfacing between the intelligence module and the commuication module I was in charge of. I changed some things in the architecture (described in the scheme in my prevoious post). I will do another diagram to summarize the new architecture, but I wait a bit so that we can make a little test with the intelligence module first.

Talking of the intelligence module… we discussed about it with Sam on Wednesday and he gave us some very precious advice. Instead of dealing with “position”s, we now rather deal with “section”s of the circuit that the player reserves when he wants to go from one point to another. See Noémie’s post for more info.

On Wednesday, we also soldered our first PCB loco. Noémie and I helped Alexis by giving him the right components. Then Noémie continued and I went back to code in a406 since one person seemed to be enough for this task. I therefore continued what Yann had started namely the adaptation of our programs to the new version of SDK we’re using (4.4.2 instead of 5.1.0). It was mainly a matter of files/folders/paths to change and deal with uncompiling programs for a while… When Noémie came back, we first placed the PCB on the loco and flashed our simple application to command the H-bridge in PWM on it. Well it didn’t work immediately since we had forgotten to comment the use_softdevice line!!

The day after, I re-tested the app without softdevice and the wheels turned (with PWM command) 🙂 Then I flashed another app doing BLE advertising. While discussing with Adèle, she told me they had the same “problem” and that it was necessary to generate an internal low frequencey (32kHz) clock (we already have an external 16MHz clock), which I simply added to the code and initialized the softdevice with. The loco then did advertise and by writing the value of the speed characteristic we could control the speed in PWM.

In the afternoon though, when we wanted to try and supply the loco with our 22V rails, some unfortunate measuring led to our nrf51822 being seriouly damaged 🙁 The other PCB also seems to have a “problem” with the balun. We of course have to test it.. which we’ll do today.

Yesterday night, Yann also soldered the remaining ledstrips and we re-tested them with the stm32f103 SPI.

See you

 

RoseOnRails – a lot of things

Hey.

These last days have been difficult and full of work! Since this weekend we have been fully “immersed” in the Python code for the intelligence part of the game on the one hand, and the communication part on the other.

First of all, for what regards the positioning mechanism, as Yan explained, we won’t use any absolute positioning simply because we don’t need it 🙂 Instead, we’ll use magnets that, when detected (by the two latches one in the front and another at the rear of the train), let us update the “position” to “position + 1”, roughly. In other words, it’s no more a matter of detecting the position of the train at all time but rather keep track of its position and time t relative to where it was at time t-1. Fortunately, this conclusion that we have made after discussion with Alexis&Sam has considerably facilitated our task for what regards the positioning mechanism.

The other question was the intelligence architecture which we discussed about with Sam. Yann and Noémie have started coding it, but there are regulary questions that are raised… Today, we’ll continue working on it again and I hope we’ll be able to have a first “draft” done by tonight.

On my part, I dealt with the communication part. Below is a diagram of how I have so far structured the code:

comm3

RoseOnRails – Communication scheme

So far, I can manage to have the different threads work as expected, however as long as the interface with the intelligence part is not made.. well it’s pretty useles! Today , I’ll complete the code to put in place the interface with the intelligence module so that we can make some tests.

For what regards the PCBs, due to a “small” hardware problem with the boards, Alexis&Sam spent a lot of time yesterday to solve it on the already soldered PCBs (namely those of the DropsNRoses). Fortunately, it’s now solved and we shall have ours soon. Then we can flash the tests and check that everything works (yes, we believe it will 🙂 !)

Another task we have to do before testing the BLE code is to make our code compatible with the correct SDK version (which is different from the one we have used for our code flashed on the Evaluation Kit so far). I’ll talk about later when we’ll have done it… which means very soon!

See you guys

RoseOnRails – code

Hi.

This weekend, I continued the Python tutorial and reviewed what I had already learned. We’re all going to badly need Python for the intelligence part of the game.

I also carried out some tests with the code of the central station, since I felt there was a considerable latency in the characteristics being written through my code compared to when I wrote them directly with gatttool. I activated all DEBUG print options in BlueLib and tried to dive as deep as I could in the sources of BlueLib and BlueZ to figure out what was responsible for that latency. Well, (fortunately!!) it was simply due to the fact that I “got primary services” and “got characteristics” each time a user wanted to write a value to a charactertistic of the train. But since we already know the (only) service and the (few) charactersitics that we use, it’s wiser to just stock them in an array at the beginning of the code (when I connect to all of the trains and start the notification) and then simply use the struct that I have stocked in this array to write to the desired characteristc. It’s way faster now! Ouf!

On Sunday, Yann and I started thinking about how to structure the intelligence of the game. But first, we had to determine how, precisely, we were going to detect the position of our locomotive with the magnets on the circuit and believe me, it was much less obvious that we thought! In fact, given that we had seen on Friday that the Hall sensors we currently use, detected only the South pole, we woud have a problem to encode ones and zeroes according to North or South… more simply put, there is South or nothing for the Hall sensor switch we use, so we can’t do any encoding based on the pole of the magnet, as we had thought we could do.

In short, we thought of using a combination of a Hall switch (the one I described above) and a Hall latch (which detects the North pole too). However, there’s still a problem since we won’t know if we have ran over one or N North poles (becuase the switch simply doesn’t detect North and the latch does detect it but it changes state the first time it sees an N after having seen S, and that’s it, it’ll stay to N as long as there’s no S). So, we simply had to do a type of encoding that flipped one bit each time, I mean encodings of type NSNS or SNSN, or SSS, etc. in short no code with two or more consecutive Ns… However, we’re still not fully certain, we have to discuss with Alexis & Sam about it, which I guess we will do today.

As mentioned above, we then started to think about the intelligence itself and how we would implement it in Python (what classes, attributes, modules, how many threads, what type of security for simultaneous access to the shared arrays of LEDs and turnout, etc.). We already have an idea that Yann started to implement last night, however, I won’t describe it here now. I will do so when we will have talked about it to the other members of the group and will agree on the architecture.

Last night, I changed again some things on the code of the central station (added some metadata to the notification in order to know which train notified, parsed commands in Python in order not to have to type MAC address each time but rather the number of the train, etc.).

Hopefully, we will soon have the PCBs with the components soldered and will be able to implement all these codes “for real” and see what happens!

Stay tuned 🙂