Ready? Steady? Wait…

On Thursday and Friday, I continue to work on the H-bridge code for the test PCB and finally find a way to implement some timers that should stop the current in the coil.

I also have to go to Télécom to cut another box for testing so that we can even work with the closing of our school. However, we do not have the cable and a battery, so even if our code may work, we cannot make our tests. We hope we could take it at school this week.

Now, I will merge my code with Ilan and Zennedine and I will try to implement a watchdog too that will halt the coil even in debug mode.

CRC must stand for Crazy Real Confusion

I’ve Come to a Reliable Conclusion upon working on CRC yesterday. Don’t try to understand what’s going on. Many walked this path before me, and yet I couldn’t look away at the promised cognitive pleasure of understanding it. In the end, I was denied this pleasure and here I am, left in frustration.

Well I might be a little bit exaggerating, but I’m sure that I’m miles away from having a grasp solid enough on CRCs to implement my own. For those who would want to do so though, this article from Barr’s group seems to stand as a reference, or at least a reliable entry point on the subject.… Read more

Finally we can send

Finally, after a few posts, and a lot of work, our testing device (ie our dev board and our ESP) can be a complete sender. As a reminder at first our device will receive images from our server but we also wanted it to be able to send data to another device. Since my last post here are the issue I faced and the solutions I found.

The first issue was to send the data to the other device once we got its topic. To ensure we send the correct amount of byte, I wrote a python script that played the role of our second device.… Read more

Task notify: Hello goodbye

On Wednesday, I spent some times implementing task notify on the sensor task, until implementing it on the h-bridge task. Then, I realize that it creates many memory errors and was not really useful since the thread should not call the function that change the multiplexer until the I2C communication was finished.

I also find the way to put some values in the esp32 that I used for the test as an I2C slave, and realized that it works with only 7 bits adresses whitout a read/write bit at the beginning, so I changed its adress and it correctely acknowledge to my communication.… Read more

Task Notify

On Tuesday, I realize that I need to make two tasks for the sensors. One that will enable the good sensor on the multiplexer, and another that will enable the sensor once the first one is finished. I would like to implement a semaphore, but the FreeRTOS manual suggest that I use a task notification instead of a semaphore. They use less RAM, but I still do not understand well how it works after a day at looking and testing it. I’ll sleep on it and hope that I will understand better how it works.

I also configure an ESP32 as an I2C slave device in order to have an ACK when I communicate with the STM because I have no other device that can do this job.

Working on communication data integrity

Lately I’ve been working on a way to make the communication between the STM and the ESP more reliable.

While searching on the subject, I came across two methods.

The first one made me reminisce some of the lessons we had in first year about information theory. The idea is to use a Hamming code for the messages of the protocol. This will make the communication more robust because of the properties of such a code. We plan to use a Hamming code (7,4) which means that the words will be 7 bits wide, with 4 bits of information (meaning we can go up to 16 different words, including the words with only bits at 0) and 3 bits of parity.… Read more

Coding for test

On Thursday and Friday, I spend some times coding the threads of the test PCB. I first debug and check if everything was ok for our thread that will read the state of all the box via the hall effect sensor. I used a logic analyser to check if everything was fine. I checked that the four pins that will be used for the multiplexer will not change until the end of the sending of an I2C message. Then I code a thread that initializes all the H-bridge by putting them at the 0 state.

I also realize that I have not seen a mistake in our scheme.… Read more

Time for testing

On Wednesday, I have corrected some more bugs in the PCB. I saw that I have route some nets between the bottom and the top of the PCB, so I route them again.

After a Skype with Alexis, I clean the git repository, and begin to prepare the folders for the tests on the PCB. Alexis asks us to make our tests on the STM of the iot_node before implementing them on the test_PCB. We receive it today, so we just need to wait for some soldering and then we can begin our tests of the H-bridge and other codes.

Here is the test PCB, we need to solder the coils on it

Now, I will begin to code the test code for the H-bridge and check if the code for the sensor works for the Iot_node.

More fixes on the PCB

On Tuesday, I check again the PCB and clean it a little. I found that some capacitors disappear during my cleaning, and I change the scheme a little. Because of the system of copy-paste of mentor and the way we put the decoupling capacitors, they are not linked with the same components. So I need to put again the capacitor near the component to check if I have all the capacitors I need.

Now, we receive the PCB, so we can begin the tests on it and I need to check with some documents Alexis give that all is ok with the HAL

I’ll be waiting for PCB

On Monday, I spend some times cleaning the PCB, by removing some resistor blocks and capacitors. We cannot take them out easily, so I have to clear them from the scheme one by one. I also move some multiplexers since they were very close to the route border. Now, we have a clean PCB but I need to clean a little the scheme.

I also continue to cut the oak plank for the final device, but I had some problems because of one of the planks which bends during the cutting. Two times. So we need to ship a new one.… Read more