Yesterday, I finally had a PCB to work on !
After spending a few days acting like a kid before Christmas awaiting his presents (here LEDzep’s PCB), Santa (here Alexis) brag ma my present
Isn’t it a nice board ?
I had a few troubles making it work at first, as I used the wrong linker script at the begining and forgot that it had a 16MHz clock instead of an 8MHz one.
Nevertheless after Alexis and Sam explained me which PLL values to change (and thus saving me quite a while of datasheet reading) I manage to make the board work !
I had time to have a LED blink and use the LED strip on the balloon and it was rather encouraging !
Later I worked on driving the servos and the motors, I realized that we most likely would have to patch my gift, as the servo connector didn’t have the proper wiring nor the good voltage (they are plugged on the LiPo battery which gives between 3.3 and 4.2V whereas the servo datasheet asks for at least 3.6V so we will have to see if they respond at a lower voltage :/). I was stuck a little bit on them so I didn’t manage to have them move properly (our previous code wasn’t working as expected), but I am confident that by tomorrow afternoon we will be able to drive both the servos and the motors !
Our only lasting foe will be the controll system, but I’m rather optimistic !
See you soon
After one week of work, I have finally succeded in making our first simple version of the application work.
It display, thanks to blender, the position of a receiver in 3D space. If you are interested, watch this video https://www.youtube.com/watch?v=eUJvMnjXj9o. We send the 9 simulated tensions through the zeroMQ socket and plot the position.
If we look at our architechure, The demonstration proves that the red blocks start to work.
This morning, Yann Valeh and continued working on the intelligence.
This afternoon, we had the occasion to talk about how we were going to model the circuit, the train position and how trains would be able to book a part of the circuit. As Sam has worked at least three times on this circuit in the past, we benefited from his experience on the subject a lot. Whereas we had designed the circuit in a too complex way,Sam proposed to us a simpler, more adaptable and more general model.
Later in the day, I helped Alexis solder components on two of the Locomotives PCBs. It took quite some time but was really rewarding in the end!
In the evening, I installed a PCB in one of the locomotives. After some time testing it, we managed to have the locomotive work… However, it does only work in one direction right now…
As Matthieu and Lau said, yersterday was a stressful day. I spend the day trying to make our PCB send something in BLE… to prove that our antenna and balun were functional. I checked everything : the fact our components were well-welded, the fact we had only the high frequency quartz, the fact that the softdevice 6.0.0 was not working on our chip (we have a N51822QFAAC0). With Alexis and Sam, I even check with an oscilloscope the behaviour of an eval kit with a N51822QFAA which was functional, to compare it with our drop, which was not functional… And it was quite weird, because the behaviour was quite the same for each pin. I also checked our PCB plan, because I was thinking that I made a mistake.
At least, we noticed that the quartz on the eval kit was 16 MHz and not 32Mhz as we thought. Matthieu, who was reading all bugs for SDK4 that we had to use (we have a N51822QFAAC0) told us that one bug was that the microcontroller could not work with 32MHz…
So Alexis welded a 16Mhz quartz instead, and it works ! We were really eased.
This morning, I spend some time correcting some part of my code for programing the memory, or refactoring it. I also wanted to add the hardware protection by controlling the WP pin. I thought I programmed it correctly, but I made some tests, and it does not work… I still don’t know why, because I really do it as the documentation recommends it.It is quite mysterious… so maybe we’ll have no hardware protection on our external flash.
Then, I read all our Scaloid code… again and again, to understand it. It is quite complicate to understand for me, because I am not used with Java anymore, and I have never programmed anything in Scala nor Android.
I began to make some minor changes. I need some information from Matthieu to continue, because it concerns BLE characteristics to exchange data, and we have to agree about what I have to send him.
As he sends me an email when I was writing this post, I think I can go back to work !
I’m thinking about the architecture of our program. It must first define how the user will program the different choreographies through the android app. Here is a first glimpse into what this application could look like.
We would find three tabs:
1) The first one allows the user to choose an mp3. An algorithm will then recognize the tempo.
2) The second one allows the user to choose the order in which the various movements proposed will be executed.
3) The third one allows to choose light transition movement.
When the user have set everything, he clicks on the load button and the app will send successively to all the balloon connected the different triplets composed of the time before the next beat, the movement to perform and the light transition that matches it.
At the reception, the NRF will handle the BLE layer and transmit through his uart connection the different triplets to the STM that will store it in his FIFO. Once the connection is completed. All balloons wait to capture a clap with their integrated microphone. Soon as they receive it, they initialize their timer and read the FIFO. After the clap, the app start playing music and all balloons are synchronize.
Two days ago, Valeh ,Yann and I decided to allocate the tasks for the week.
I was assigned with coding the locomotive thread in Python. I had quite a few problems with that as I didn’t know how to communicate with the rest of the code (notably the part which receives the notifications from the BLE). Therefore, I spent quite some time reading docs on how to implement even handlers and interruptions in Python.
Valeh, Yann and I have finally decided that we would tackle the communication later and focus on the content of our threads.
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:
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
Before the week-end and on Monday, I worked on DropFS, our flash memory management system for drop messages.
First, I had to establish precisely the byte (even bit!) mapping for each type of page in memory. I did it with packed structures and bitfields in order to simplify parsing. Consequently, I spent a few days on writing and rewriting lots of typedefs and function prototypes, because our model changed everyday and because I wanted data structures as easy to manipulate as possible. And when we discovered that our flash could be written bit per bit, I once again had to rethink all my structures! But now I think that the result is very near to its final state.
Then on Monday, I was able to begin programming DropFS’s actual functions. Right now the basis (creating, reading and deleting indexes, boxes and messages) is done, I only have to finish the write and edit functions for tonight. Actually, I didn’t have much time to work on DropFS today because we received our first drops and discovered that their radio wasn’t working! Hopefully, we solved all the problems we had (with a big help from Alexis and Sam!) and now each of us has a working drop in their pocket. To summarize, we were unlucky on several points: the nRF we received was a C0 revision instead of G0 (with a lot more bugs and differences for PCB design) and some components weren’t delivered in time, so we had to use similar but inadapted quartz, capacities and resistances for the first prototypes. With this special combination of changes, everything went wrong! We were in a configuration where our SoftDevice and SDK versions weren’t supported, the HFCLK was supported by the chip but not the radio… In the mean time, our git repository went half-crashed… For a few hours, we thought that maybe none of this year’s PCBs could work with BLE. So having them working tonight was quite a relief.
Solving these issues nevertheless took us the whole day and we weren’t able to do anything else. So I can’t wait for testing DropFS on an actual drop!
Hi everyone !
Short sum up of my work since Saturday
On Saturday, I look how to implement our BEMF. I already had some useful explanations from Gleison and Valeh were chosing the component in order to use for our motor. But, on Saturday I got a clear picture (See these useful links 1 2 3 on the way we’re going to implement it (simple implementation in C). I’ve also looked through Valeh’s of our central station to understand how it was implemented. Unfortunately, I had lend my BLE dongle to Gleison. So I couldn’t make any test to improve the code. Luckily he had gave it to Valeh, so I got it back on Sunday and I started trying to improve the way the code was working. On Saturday night, I realized something was wrong with the suggestion made in my previous post to detect the absolute position of the train.
On Sunday, we’ve met with Valeh the whole afternoon in order to discuss the way we think the intelligence of our game is going to be implemented. Unfortunately, the resolution of the problem of the detection of our absolute took us a very long time (like two or three hours) each time coming up with a solution and then realizing it couldn’t work a few minutes later. We were taking into account the following constraints of our hall sensors and the fact that we had magnet (turn either north or south below our rails).
“Hall-effect switches are most commonly used in sensing absolute position, because they require a south pole of sufficient strength to turn the output on and then removal of that field to turn the output off. ”
“Hall-effect latches are most commonly used in sensing multi-pole ring magnets for motor commutation, because they require a south pole of sufficient strength to turn the output on and a north pole of sufficient strength to turn the output off. ”
Finally, we came up with a solution I tried to explain it on the rose2014 mailing list but it seems it was way to complicate. So, on Monday we’ve decided to abandon the detection of an absolute position (which was a question raised during our Friday presentation) and we’re just going to detect the change of the kind of pole.
Then still on Sunday, we’ve started to define our architecture and I started to code our classes before midnight.
On Monday, we’ve discussed our architecture with Noémie some questions and doubts were raised. We’ve also discussed our solution to detect an absolute position with Alexis and Sam. But as I said, we’ve eventually abandoned this ambition. We had to make some tests in order to be sure that the electro-magnet use to turn the turnouts weren’t disturbing our hall sensors. We’ve seen that their magnetic (active only when we’re turning a turnout) doesn’t disturb our hall sensors on a distance superior to 8mm. So their will be no problem. We’ve also divided our work between Valeh, Noémie and I. I’ve started to implement our database according to our classes.
Today, I’ve finished to enter all the data we need (I hope) in our database and I’m now implementing the serial thread which is going to change the direction of our turnout.
See you soon
Kinda like this thing but there’s something you should know
I just came to say hello
What a touching moment. Our first drop (Drop65) just said “Hello”.
It was not an easy journey to make it work. We came through doubts, tears and despair. But we finally got it. We got a sign of life from our dear and beloved drop.
We encountered many problems before achieving this. First, we noticed that the nRF chip was a very old revision, with its bunch of bugs. So we had to downgrade to a previous version of the nRF SDK compatible with this revision. Then we tried to test a simple program using BLE, but the drop was not even advertising (whereas the same program was working on the development board). Next, we decided to test another program directly using the radio (without BLE), but again it did not work on the drops. Finally we tried to replace the 32MHz quartz with a 16MHz quartz (so that we had the same clock than on the development board). And guess what… it worked! We can now see our drop advertising! However, we still don’t know why it was not working with the 32MHz quartz, but it seems that there is a bug with this quartz frequency in our chip revision.
May the force be with you!