What kind of chip are you?

Ok, all weekend I worked on finding chips that could be useful for our project, and gather them and the main information  that concerns us, in a Google Doc spreadsheet.

Two kind of architectures are possible. Whether we use a unique chip that is a MCU and a tranceiver, whether we us two separate chip for each of this functions. Of course we will choose the solution that give us the better range with the lower consumption rate. The STM32L has consumption rate very impressive. If we choose the two separate chips architecture, it will be surely the MCU.

If you want to recommend us chips, be my guest, I’ll take a look into it with pleasure.

ROSEly yours !

Episode 2 : more changes

Last Friday, we discussed with Alexis Polti and Samuel Tardieu of our current view of the project. This was really interesting.

First : our assumption that Ethernet would be great was false. Even in a local Ethernet segment we can’t assume that the jitter would be nearly inexistant if there is other people using the segment. No more lwIP then 🙂

As using Ethernet was mainly used to synchronize the beeps, they proposed a solution : using the emitters timer and just synchronize their clock using RF.


ZigBee sync architecture


So I wrote a prototype of code for the TP boards : a master would emit a synchro pulse via ZigBee every 4s, and two slaves will reset their timer when this message will be received. The timer interrupt would then be used to generate a pulse on a GPIO.

Using the LED as output, slaves clocks seemed to be well synchronized, but I need to analyze this using a logic analyzer to figure out if the slaves clocks are really synchronized enough for us.

Then, Alexis Polti told us that it was useless to use a class A amplifier with a pure sinus : making a square wave using the PWM output with a class D amplifier will result in a much higher efficiency. The piezzo tweeter will then filter out the square form to make it a square wave. No more DAC used.

In the week-end Issam and Jean-Baptiste made huge progress on the simulation side, but I’ll let them explain their work 🙂

A late tale. Episode 1 : how we reduced the complexity, and the story of a failed lwIP attempt

First, I want to say that I’m sorry. These last weeks I was not really writing posts on this blog for two reasons : the first is that I don’t like to write to say things with no deep content (like saying that I did my TP work). The second is that I was a little bit procrastinating these blog post, to be more focused on using the free time I had to currently work on the project, constantly saying that I’ll write something when I’ve finished what I’m currently doing. As a result, the WAMI project was not very transparent and I’m partly a culprit for that.

So, I’ve decided to fix this and write the tale of WAMI, the tale of our previous weeks of work.

Jean-Baptiste and I met on the 10th of December to merge our views of the project. We agreed that we needed to remove some complexity layers we’ve put then. No more complex modulation, no more complex error-correcting codes, and so on : we’ll only produce beeps. We had too many disavantages in term of complexity for the advantages we would gain (which was having a perfectly scalable system up to 255 emitters) to continue.

Our system is now far more simple for a nearly identical result.

We’ve decided to simplify even more : the emitters would be only a microcontroller with an Ethernet port which would connect itself to a local server using TCP. The local server would be a Python program which would say to the emitters “beep now” at the correct times. The idea behind this was to assume that the local Ethernet segment would have nearly no jitter so the latency would be constant and the latencies would be compensated in the localization algorithm (it computes by relative timestamp differences).


Ethernet architecture of WAMI


The emitters would use the mirocontroller’s DAC to produce the sinus wave to be emitted : it’s simple, effective and reprogrammable. So we’ve studied a little bit which class of amplifier we would need : as we were considering that we would need an amplifier which will not alter the signal content so we would have less error on the receiver, we were opting for a class A amplifier (like a common-emitter amplifier).

So Jean-Baptiste had just to figure out the formulas for doing the localisation given the beeps timestamps, and Issam had just to write some Python programs so we could test on computers what we’ve found before going deeper in the electronics part.

I have the chance to have access to a STM32F4DIS-BB board with all its accessories (Touchscreen, camera, …) which has an Ethernet port. I decided that I could try to begin the firmware using my development board while I wait Issam and Jean-Baptiste, so we could have a little precious advance for the firmware when we would receive the PCB.

STM32F4DIS-BB with its Ethernet port plugged

So I tried using ChibiOS with lwIP using ChibiOS’s demos. ChibiOS has an embedded version of lwIP (in the ext/) folder, and has a set of tools which integrates it nicely in ChibiOS (like pre-made configuration threads).

After tweaking the STM32F4DISCOVERY ChibiOS’s board configuration to route to the proper alternate pins, I hit a lot of problems.

Firstly, just note that if you want to use RMII, you need to add #define BOARD_PHY_RMII 1 in the board.h.

Secondly, on the STM32F4DIS-BB you must reset the PHY manually using a GPIO, but ChibiOS’s reset method in halInit(); issues a soft reset using RMII (so the PHY would already had its hardware RESET phase done). halInit(); was looping infinitly waiting for the PHY to send him that it has been successfully reseted. So I’ve replaced ChibiOS’s reset method with my own, using #define BOARD_PHY_RESET macro on board.h which will trigger the reset pin using the GPIO (by the way, I wasn’t able to figure out how to use the triggers of the poor Bus Pirate’s logic analyzer mode to figure out if I did the reset part correctly. I wonder if the triggers really work.)

Thirdly, ChibiOS’s uses a strange method for probing the PHY address. It sends a message to all possible PHY having a specified physical address and sees if someone replies. The problem was that the PHY is a SMSC LAN8720A and its PHY ID is not in ChibiOS’s constants so I needed to figure it out. After digging deep in the LAN8720A’s datasheet, I couldn’t manage to have a reply from the PHY. So I looked in the examples given in the STM32F4DIS-BB kit (on Element14 website) which use FreeRTOS and ST’s peripheral library, to see that they were using a PHY address of 0x01. So I skipped the probing method, and used #define BOARD_PHY_ADDRESS 0x01 to do this.

At last, I was locking on a DMA transfer (the micro-controller was looping infinitly for a pending bit). I stopped there, as the next post will tell you some direction changes in our project.

Rolling rosace or enslaved sphero?

Today we used the serial/usb cable to talk with the opened sphero in shell mode using a small python script. It works so we know if we want to flash sphero via seria we will be able to use the uart.

We settled on reusing the hardware of sphero, but adding a pcb above it.  The features we want to add is a spinning led bar like RoseAce, and some IR sensors, using maybe some IRDA to modulate the IR.

One architecture we could do is one board plugged on the uart of sphero,  and a motor in the center of this board.  On the axis of the motor just a bar or disc with some leds on it and powered by a “button battery”.

So we are sure to do an additional pcb but we don’t know if we will do our own firmware our just talk to sphere via the api mode.

Our next step is to succeed in flashing the sphero with our own code. But it’s scary because we have only one try, if we flash it with another code, it’s original firmware would be whiped and there will be no going back.

Our idea to check if we can flash is to code a simple application, for example with chibios, that just changes the led color (in order to check if it works). And then put the BOOT0 to 1 and BOOT1 to 0 to go in alternate bootloader, then use the stm32loader python code to flash over the serial.

If sphero boots and the led blinks it’s a green light!

We will try this as soon as we are confident enough to do that.

Work on wizzimote

While Sacha was reading the code of Wizzilab and make some interessting modifications. I worked on the wizzmote, for further tests. Now I can send information trhough a UART bus to a computer. I need to to specify what information I have to send. I’m looking on how to send the quality signal.

I also work on finding chip. I look for tranceiver or MPU with tranceiver include, like the CC430, their comsumption in RX, TX and normal mode and sleep mode. I still have some information to find then I will share the table to you

Days 26-28

I advanced on my schematics but I mainly spent time to understand Wizzilab code and beginning to modify and appropriate it.

Since the code must have a limited size, I compared the size after each modification I made, I was then able to see how factorizing the code and declaring things static is important.

capacitive sensor and first PSSCs

Friday was a long day and after finishing the schema of the TP PCB, we continued to work on the project choosing some components and  doing some tests with the capacitive sensor. The idea is that the proximity of our hands of an iron wire will change its capacity in a way that we can measure by analyzing the time delay between a signal sent in one side and received in the other. After a lot of different tests, we were only able to obtain significant differences when we touch the wire, but not when we are near the wire, as we hoped. This means we’ll have to use an other kind of sensor.

We also started working on some PSSCs such as the architecture and the choice of components.

Servo control

Today I worked nearly all day on the servo-control of the Sphero. I wanted to do pseudo-code for the Kalman Filter but I realised that I needed to come up with an design for the servo control.

I tried to understand what the actual Sphero does by reading and re-reading this article : Apparently they are using quaternions, which are very useful to combine rotations without doing too much computation.

I also think that we need to understand the mechanical part a bit more, I found several interesting articles that deal with it.

I plan on doing a synthesis of my work so I can submit it to the teachers.




It has been a while since my last post, and a lot of things happenned.
First of all, we have a small 3*3*3 cube which allowed us to think about the best techniques to build a perfect 12*12*12 cube. On monday we will start to build a mold in order to simplify the construction of straight LED column.
Also, our list of components is almost done. We have LED, drivers for column and drivers for plates. We just miss our gyroscope, but Alexis told us about some trouble to connect it to our PCB because our PCB will be too large… So we may choose an external gyroscope. And at last, we need a micro-controller. We already have the number of pin it will need (60). But we will choose it when our components will be validated. However, we experienced some deception about our presence captor. We tried a lot on Friday but we could not manage to build a capacitor captor with a single wire. So we are thinking in other solution: just the kinect camera, or I thought about a row of infrasonic captor at the base of the cube (horizontal axis is given by the presence or not of a return signal, and distance on the vertical axis is given by the captor, so we can place the hand on a plane…) But it might be a bit too imprecise.
At last, I am now thinking on how our cube will communicate with a PC. Our first idea is to use the USB protocol (The PC is an USB host and the cube is a device). It just seem a bit complicated, so I am doing some research about other bus we can use… (Now, I am trying to use Serial over USB)
PS: I do that in parallel with another routing try on the PCB practical work.

Days 26&27

Friday, we decided to test our method of detection, which consist in mesuring the capacitance of our body thanks to a RC circuit. But our conclusion, after tests, are that we can only detect if our hand touch the wire, not the presence. At the end of the day we decided to abandon this option. We thought that we were only going to have the Kinect, but on the evening, Patrick gave us the idea of the theremin, it’s an instrument of music detecting the presence of hands nearby two antennas. With this new hope, on Saturday I studied this instrument and his way of detecting, I hope we will be able to start tests soon, even if this week we have Athens.
We will receive the LED at the end of next week (I keep my fingers crossed).

On Friday I continued the placement for the PCB and did a first route, unsatisfying. So on Saturday I started another one (in fact I did it twice…), better I think. But I still can improve it.