Categories

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 – 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 – WIP

Hi.

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

Hi.

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.