1 May 2014 @ 18:43 
Hi,
Our receiver almost works. We are able to receive the tension of our 3 coils :
Our measures
But we still have a problem, our function that compute the maximum of 3 values doesn’t want to work …
Stay tuned.
|
|||||
|
Hi! I have one graph to show you. The audio codec is alive, and we will harness its power , just wait for it !
 In blue, our raw signal
In blue we can see our raw signal. It no longer have discontinuities =)
On a side note, Noble seems a good option for Ble as 3 out of 4 group of us are using it. I’m glad it helped. I just hope it won’t burn. Hello, Today I have worked on the emitter with Guénolé. As we can’t have a cool project without LED, we have added 4 RGB LED on our emitter, and we will soon add 4 more.
Aside from that, this morning I have work on the joystick application of our system. I have selected and installed two open source First-Person Shooter that we will use to show how cool is our project with video games (Xonotic and Unvanquished). Hi 🙂 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. See you soon. Guénolé. Hi readers ! This last week, I worked on the core of the receiver software : the control part. I had to answer these questions : How will the data be processed on the mini-DSP of the codec we choose? We chose to multiply our signal by a cosine on one hand and by a sine on the other, each at the frequency of the signal (19kHz) and send the results, after a lowpass filtering, on the left and right output channels of our codec. That way, we bring our signal back in baseband and thanks to the 90° phase shift, we will be able to compute the amplitude of our signal and follow the evolution of its phase. How will we synchronize with the emitter on start-up? Let me remind you that our emitter has a four steps periodic operation : it emits on one coil, then on another, then on the last one, and then stops for a time. All of these steps have the same duration. So to find the correct synchronization, what we have to do is simple in theory, we wait for the signal we measure to be small enough to consider we have no emission, then we wait to sense something to consider the first coil has started emitting. How will we keep this synchronization through the time? Though quartz oscillators are rather precise, but at a 192kHz audio sampling rate, the synchronization might shift of one audio sample every 0.4 s if we don’t fix it on a regular basis. But as we compute the phase of our signal at each measure, we can use it very easily to fix this synchronization. For example, let’s suppose the clock of our emitter is a little faster than the one of our receiver, instead of sensing a 19000Hz signal, we will have a 19000.001Hz signal, therefore instead of having constant values on the left and right output channels of our codec, we will have a cosine and a sine at 0.001Hz. by measuring the phase of this output, we will be able to compute on each measure cycle the corresponding phase shift to fix it, by skipping an audio sample for example. How should I organize and trigger the different steps I have to do on each emission cycle? For each emitting coil, we have three steps:
We will receive the values from our codecs through I2S and use a DMA controller to record them on two buffers synced on an emission period, so that one address will always correspond to the same time of an emission, that way it will be really easy to access the samples we need. To trigger our different steps, we will use a PWM and callbacks. How will we transmit all of our values? The problem with bluetooth low energy is that it can only transmit 20 bytes packets. Considering the rate at which we will transmit, we might not be able to transmit more than one packet for each measure, therefore we need to compress the 9 values on 32bits we had to a smaller size.To do this, I decided to send the 9 values with a 16 bits precision, and one single bit-shift indicator to use on everyone of them. As the 9 values should always be on the same order of magnitude, we shouldn’t be losing in precision doing that.
I already have written the code to execute all of that, but as Guénolé told in a previous message, we haven’t received our PCB yet, so I may not test all of this before Tuesday. I am really looking forward to testing the software on the real board, but I am afraid of the time it will take to debug everything ! We’ll see that soon !
See you !
Hi everybody, Today I worked on the Serial Audio Interface that we will use to communicate with the Audio Codec. We have to use it as an I2S Bus. However, it is not very simple because the documentation on the Internet about it is very poor. So I made my own configuration, I’m ready to use it. Moreover, this option (SAI) is only available on the STM32f2xx. I’m currently waiting to receive our receiver board to check my code and my configuration. Moreover, I worked on the emitters and specifically on the emitters coils. We have to made them by ourself, and it’s not a very funny work. I just finished now and we have 3 perfect emitters coils of 700 uH each. 😛 We will use it tomorrow. I have some pictures for you… 🙂
Hi all, After one week of work, I have finally succeded in making our first simple version of the application work.
We send the 9 simulated tensions through the zeroMQ socket and plot the position.
Whereas I’m working on the software of our receiver, I take few breaks to continue working on the packaging of our transmitter / receivers. I 3D printed our components. Here are some previews of it. The emitter coils will be hide by the “white part”.
Moreover, we received our receivers. Howerver, PCBPool forgot to weld the Audio Codec on the board. We can’t use the board yet. 🙁 
Hi everybody, As you may know, all the nRF that we will use in our project, will be the N51822QFAAC0. The C0 refers to an old version of Nordic SDK (4.4). However, with our eval kit, we were using SDK 5 because we had N51822QFAAG0. Our goal was to use the same chip, but PCBPool made a mistake. We have to deal with it. Yet, there are a lot of differences between these versions. Some functionalities are only working using the new SDK. Moreover, as explains in this post, the nRF has a 6 byte UART-buffer. But with the C0, the buffer is reduced to 1 byte. So, we have to choose an other protocol to communicate between the nRF and the STM32 using a software flow control. Here is the frame specification I imagined to do that. Note : This protocol that describes the frame to exchange data between our STM32F4xx and the nRF on the receiver is directly inspire from the API Frame Specification of Digi XBee module. For more information, go on Digi website. Introduction Our communication between the nRF and the STM32 requires that communication be done through a structured interface (data is communicated in frames in a defined order). This paper specifies how data and data responses are sent and received using a UART Data Frame. UART data frame structure – with escape control characters
Type of message For our system, we will send and receive only a few kind of message which will correspond to a type of data. As every type of message won’t be sent in both directions we can organize them into three categories. STM32 > nRF Data from the receiver coils :
nRF > STM32 Calibration data :
Sampling rate :
Both ways …
Escape characters When sending or receiving a UART data frame, specific data values must be escaped so they do not interfere with the UART data frame. To escape an interfering data byte, insert 0x7D and follow it with the byte to be escaped XOR’d with 0x20. Data bytes that need to be escaped :
ACK When sending a frame from the STM to the nRF, we are not able to send more than 1 byte in a row, due to the buffer in the nRF. So, to deal with this problem, we have to define a software flow control ; when the nRF receive 1 byte, it sends an ACK to the STM. CONCLUSION The protocol is implemented on our board. We managed with Benjamin to test all the communication from the STM32 to the nRF to the computer (using a BLE dongle). It also works in the other way.
Hello, I have good news today. Secoudly, our H Bridge works as expected. The alternative intensity that is going through the coil have a magnitude of 1.1A. Aside from that, today I have finished to code the interface, using ZeroMQ, between NodeJS that handle the BLE and the calculator. |
|||||
Recent comments