PLUME – Getting started on the software part

Hi everyone !

As I said last time, we have finished designing our PCBs, so from now on we will spend all our time on the software !

This last week-end, we all worked on the presentation that should have occurred on Monday,  so we haven’t had much time to start fully working on the software, but now that it is finished, we need to coordinate ourselves to work efficiently on each part of the project.

Yesterday, with Benjamin and Olivier, we argued on the structure of the computing part of the system. We finally decided that we will use a Node.js block to communicate using Bluetooth low energy, and a C++ block for the computation of the position, the two blocks will exchange data using sockets (probably with the 0mq library).

I also have started thinking about the way the receiver software should be structured, to be correctly synchronized with the emitter and to keep information on the phase of the signal and find every information we need to calculate a good position. Unfortunately, it brought me doubts about the method we chose to eliminate the symmetry problems. I will need to verify that…

See you next time !

RoseOnRails – the global architecture


This morning, I did a plan to summarize the architecture of our system.


RoseOnRails – Global architecture

Then I started to work on BLE again. So borrowed MarcO’s board and… of course the app worked fine…. almost! The connection with gatttool was successful and didn’t get interrupted accidentally after a second or so (like it did on my board). However, I couldn’t manage to change the characteristic’s value. Matthieu said he managed on Nexus 4 so I guess the problem doesn’t come from the code. But I don’t yet see what the problem could be?? Gatttool maybe? Anyway, I have to make it work on Linux (for now it’s in command line but we’ll eventually use BlueLib to code the whole app) since our Central Station will be on a PC.

In the afternoon, Gleison and I carried out some experiments to determine how we were going to provide the alimentation for the railroads. In fact, we found out that the current alimentation system (that is, with the booster and the DCC remote control), isn’t relevant for our system (since of course we won’t be using DCC anymore). The problem (actually it’s not a real problem..) is that the tranfomers don’t do the rectification from AC to DC. Therefore, we’ll have to insert a cicuit (diod bridge + capacitors) to convert the AC signal to DC before providing the alimentation to the railroad.

Tonight, in order for me to be able to go further in the simulation of the motor woth Simulink (to determine the PWM frequency), Gleison and I carried out some experiments to determine the inductance of the motor. We first measured its resistance then the inductance. However, unfortunately, we obtained some incoherent results for the inductance. More precisely, we did’nt find the same values when we tried different methods (for the resistance… but since the inductance was calculated based on the resistance, the inductance value we obtained wasn’t relaibale either of course). We will re-do it tomorrow to find out what went wrong…

See you soon.

Plume – Project Architecture

I too haven’t posted here in a long time, though the week has been filled with work ! Things are getting more concrete, and this is really exciting. On Saturday the 15th, I spent much time working on the software architecture of our project. Putting the ideas on paper really helped me figure out how to implement our software and how to make everything work, and I think that the resulting architecture definition will really be helpful to work efficiently.

During the remaining of the week, we worked on choosing the various components we will need on our different systems. That means reading datasheets to find the various data we need to properly design our system. The sensitive part of it was designing the analogical amplification chain to be able to detect the very small signal variation of the magnetic field necessary to compute precisely the position and orientation of our system, even at a 5m distance from the emitter. With Virgile, we evaluated the amplification we needed, depending on the range of distance and the precision needed, thanks to an Octave program. The value we got were useful to fix the gain and the ADC we needed.

But that was before we found the magical component : the audio codec, which comprises all the elements we needed to amplify and measure our signal in a single chip. Therefore, during the last days I have worked to see how it worked and how to use it to check if there aren’t any flaw that would make useless for our application.

Thus we also had to redefine our hardware architecture to include this chip in it. I will also have to change some stuff in the software architecture to make it match with the hardware, but there shouldn’t be much changes, so that is alright !

See you soon !