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
As I wrote in my previous posts, the ESP, the STM and the server were working together to receive images or animations depending of what the user wants. Now it’s time for the STM to become the sender.
We want the devices to be able to received images from the server but we also want to establish a connection between Touchs to send images from one to the other. On top of that at the end we want to have a communication between both devices in both ways. But as you may know chi va piano va sano. So first things firts, we implemented the emitting part for the first device.… Read more
So far, the ESP32 was able to receive images from the server through MQTT and transmit them to the STM32. It also could transmit animations but only if the animation was directly hardcoded. So what we wanted to do was to be able to transmit animations through MQTT just like images and also to find a way to chose if we want to receive an animation or an image.
First things first : the server side
The first step we did to go in this direction was to find a way to transmit animations.
We chose that, at least for now, the server will publish periodically on two topics.… Read more
For the last two days, I mostly spent time making the code clearer. Some big functions got divided to make them easier to read and to modify once we will get the test PCB.
The second thing was to add semaphores to protect the variable shared between our threads on both the ESP and the STM. I also create a new thread that will be used to display the image or the animation we receive from the ESP. So far it only prints on the console the value of each bytes but having it already created allowed me to add the semaphores on the image so that when we will be trying to display images with the coils we will simply have to deal with the coils.… Read more
As I already wrote on previous post, we implemented a MQTT communication to send data from the server to the ESP, we also implemented an UART communication to pass data from the ESP to the STM. Now it is time to go all the way : sending data from the server all the way to the STM.
To do so we had to make a choice: at which point will we encode the data in regard of the communication protocol between ESP and STM.
As a remainder, to be able to differentiate data from commands, the bytes that will contain data will always start with a 1 and then code the state of 7 marbles.… Read more
As explained on my previous post, the communication between the ESP and STM will append through a protocol made to discriminate data and command bytes. We already had the code to send images from the ESP to the STM and this post will be about sending animations from the ESP to the STM.
Our first idea was to start like for the images with a byte to warn the STM about the kind of data that will be transmitted. TO do so we will start the communication with the byte “ANIM”. Then we wanted to send, after the ACK_BEGIN, the size and the animation itself in one time.… Read more
In our design, we want to use a STM as our main processor bu also an ESP to deal with the network part of our device. This imply a communication between those two.
The low-level protocol
At first we wanted to use the UART protocol. Yet because we will have very strong magnetic fields, we migh need a more reliable protocol. We decided that we will implement both an UART and an SPI interface and test both on the device. As of today we have implemented the UART communication but as we don’t have on our development board (iot-node) any RTS/CTS pin that can be mapped to the arduino connectors we used delays to avoid the overrun we initially had.… Read more
Now that the Hall effect sensor is working and while the coils are still being tested with the marbles, we started working on our WiFi module. As explained in our project’s presentation, we want our devices to be able to communicate through MQTT with a backend and with other Touch.
The WiFi module :
To do our test we took an ESP32 Wroom-32 Dev kit C. The main purpose of this module will be to connect to the WiFi, receive through MQTT the images that the box will display and then transmit them to the STM32. In some cases, the STM32 will send to the ESP the state of the box and it will have to transfert those data through MQTT.… Read more
We previously tested a Hall effect sensor that, was working, but which gave us a voltage from which we could get the marble’s side. The issue with this is that in the final box, with all the marbles and the coils, we could have had strong pertubations that could alter the data. To avoid this issue we decided to use a sensor that would send the data through a communication protocol that could resist. We chose the TLE493DW2B6A0HTSA1 Infineon Technologies. This sensor sends its data through the I2C protocol so it should resist to our perturbations.
Let’s connect it !… Read more
In the components familly, it was time for the Hall effect sensors to be tested.
We used the SS39ET from HonneyWell. This sensor has 3 pins. One is GND, one is Vcc and the last is the output. The output is a voltage proportional to the magnetic field. We choose for Vcc a value of 3.3V.
First tests, let’s use a voltmeter.
To do the first tests we measure the output voltage with a voltmeter. To power the device we used a DC power supply. We also added an ampermeter to measure the current going to the Hall effect sensor.… Read more