First the uart between the nrf and the stm32 is now fully functionnal. We had some trouble because the remote control through the app seemed to work 10 seconds and after that it was all random. But the bug is now fixed and we can go on.
We’re gonna have two android apps : one for the direct remote, and the other for the light ambience and choregraphy control.
So we have to implement the way to take control of a particular balloon. Here is a quick draft of what I think would be a good idea to do that.
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!
After some problems with the shipment of our receiver boards, we finnaly got its. With the greatfull help of Alexi we welded all the components (except the SWD debug port, beacause, we didn’t able to find it). Then I checked the card and all possible mistakes and I booted it.
And….. our receiver board is alive.
Now, we will debug all our work. And there is a lot of to do.
I am still working on Cairn application. It is a huge work to do on Scaloid. I have an application able to scan and list the specific cairn devices (it is done by filtering some advertising data). This app also notifies its user when a new cairn device is found. Then, it gives the possibility for the user to connect to any device nearby.
The next step is to list automatically the ten most recent posts in the guestbook.
It is still hard to work on Scaloid (because I am not used to it). But I was much more concerned about the guide lines I will have to adopt. I have some problems implementing the different functions and activities because… I don’t really know what is for the best.
It is quite weird to be confronted to such problems. I really feel lost.
But it is in progress… step by step, I create my first app
Today, during the morning, I worked on detecting the magnet with the hall sensors we’ve soldered yesterday. I’ve also Th soldered in some wired on the turnout PCB in order to test it. Then I’ve tried the new patch for the UART connection between our nRF51822 and our STM32F103RE. During the TH of the afternoon we made a Trello, it took us way more time than expected. Then, I tried to identify the origin of the problem on our UART connection, unfortunately my minicom doesn’t print the right characters (I’ve checked all the parameters I put in our STM32 serial port and made it correspond to my minocom parameters..). I measured with the oscilloscop what was at the output of the new pin we use when I toggle it. I obtained the same signal (slot with amplitude 0.5V instead of 3.3V..) that we got with the previous pin we were using for our UART-TX. Maybe we’re going to soldered another LED PCB.
Tonight I’ve worked again on the hall sensor but with Valeh, but we’ve noted that the motor was interfering with the hall sensor when we put it under the motor. And when we put it at the extremity of our train it’s too high. Moreover the hall sensor must be right above the magnet in order to hope a detection from around 1cm of the magnet. We’ve reached a catch 22 situation and asked Gleison what he thinks about it. Because more than two people on this task wasn’t productive, I’ve exchanged of task with him, continued solder the wire on our PCB and tested it with the rails powered. It worked perfectly.
Friday we eventually managed to fix most of our issues, which allowed us to have a working prototype with a very rudimentary control system, even though it was a first draft it was rather cool
Saturday I spent all day (and night) soldering with Alexis and Daniel, and was rather happy to discover that I was able to solder 0402 components (even there was a lot of free space around the components), we now have our 10 PCB soldered !
Later I tried to improve the barometer measurements, as they were not very good …
I also helped Daniel adapt the Invensense library for the mpu9150 for ChibiOS and STM32.
From now I will spend all my time on improving the altitude measurement and flight control until I consider they are good enough
Initially we thought the LED strips would be a piece of cake, it is just a matter to weld everything together and it should work, right? NOOOOOOOOOOO, and that’s a huge no. We spent lots of time making things work. We had all sorts of problems, some with the connection itself, wires that were too fragile, strips which had tracks physically damaged. For the software, we had a problem with the SPI, which according to the LED’s datasheet was irrelevant, but it was not. For the electronics, we had two types of strips and the incompatibility between them was not documented. Nightmares, days spent to debug all the problems we had.
Consequently, our turnout PCB software PSSC had to be postponed, and worse, we had a very short deadline to code it. Well, I finished it one week ago and we have just received the PCBs, hopefully we will get them working today. The code is basic and based in an example, but I spent sometime getting familiar with the code, specially commands related to the BLE stack. Additionally, the drivers are protected from overheating by a sequential switching with a cool down sleep.
Today, following Allegrem’s tradition, here a musical quiz on our students projects. Will you recognize to which project each following hit belongs ?
Warning : to make things a tiny little bit harder, some lyrics may have sightly changed… 2nd Warning : to make things even harder, some project might have two songs ! Or none.
1.Je ne veux pas travailler Je ne veux pas déjeuner Je veux seulement oublier Et puis je fume [ter]
2.What you want, what you make, Everybody knows it’s only what you take And now what you see, and what you hear, When it comes around again it’s not gonna be the same thing Because you’re gonna say yes, and they’re gonna say no And everybody’s gonna talk, and talk, And bla bla everywhere you go…
3.Volare, Oh oh, Cantare, Oh oh oh oh oh
4.At first I was afraid I was petrified Kept thinking I could never live with this damn project by my side But then I spent so many nights Thinking how I did things wrong And I grew strong And I learned how to get along
And now I’m back, from hacker space I just walked in to find you here with that sad look upon your face I should have changed that solder bond I should have had far more concern, If I had known for just one second
That else I’d make ev’rything burn
5. And so how am I ever to know? You only tell me Perhaps, perhaps, perhaps. A million times I ask you, And then I ask you over again. You only answer Perhaps, perhaps, perhaps…
6.Ground Control to Major Tom
And may God’s love be with you
[Ten, Nine, Eight, Seven, Six, Five, Four, Three, Two, One, Liftoff]
7.F… you, I won’t do what you tell me
F… you, I won’t do what you tell me
F… you, I won’t do what you tell me
F… you, I won’t do what you tell me
F… you, I won’t do what you tell me [etc.]
First to give the good answer wins a bottle of Champagne (to drink with moderation of course !). One answer per person (IP logged), real name mandatory
Leave response in the comments below.
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…
Excellent news today our PCB locomotive runs on the track. With Valeh this morning we’ve made some tests changing the duty cycle of our PWM, increasing it slowly but the motor didn’t wanted to turn. We’ve measured the voltage which was going in our motor the difference between the two outputs of our bridge. We’ve read the datasheet of our H bridge. If they were peak of intensity, the output then would be disabled. But it wasn’t the only problem. We’ve seen weird thing, we asked PHH some help, same conclusion… Then Alexis looked at it more precisely and our H bridge was dead. He changed it and add a decoupling capacitor that we had forgotten. Indeed the one we had put wasn’t active in case of high intensity because there is a diode and the H bridge and the decoupling capacitor we had put.
Yesterday, after measuring the voltage when we were toggling the pin we were going to use for our the UART-TX of our nRF51822 (we measured only 0.5V of amplitude). We conclude the P-transistor could be dead and we asked Alexis to patch our PCB by connecting an other pin (indeed two because nRF51822 are very small) on the track to the pin UART1-RX of our STM32F103RE.
Then we change the way our rails were powered because Alexis warned us not to use more than 15-18V. So we tried to put a safe connection trying to prevent short cut. As you’ve seen in Noémie’s post our train runs on the track. The record is 10 laps !! But even with our cautiousness this when our train derailled on a turnout he litterraly tooked fired.
Tonight, I soldered with Valeh our hall sensors on our locomotive. I hope we’ve made it strong and clean. Let’s see our mouse