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
After talking with Tarik, it seems our approach to FPGA/HPS communication was a bit off.
We wanted to use one data bus for writing on the LED band controllers and use GPIOs for the other signals coming from the HPS. It turns out that the GPIOs of the HPS cannot be directly connected to the FPGA, and according to Tarik the workaround are a bit sloppy.
So instead we decided to use the second data bus to write on registers in the FPGA, which will create the needed signals. The first bus will stay dedicated to the DMA module which transfers RAM data to the LED band controllers.… 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
Since thursday I’ve looked into how to implement the wifi communication we need between our phyllos (see Ruling the colony of Phyllos ).
We need a way for multiple Phyllos next together to broadcast data between themselves, and a way to communicate with the Phyllos from a smartphone or computer (for instance), and we will be using a ESP32 dev kit C integrated in our Phyllos.
Data exchange between Phyllos
The rate at which the phyllo need to exchange data doesn’t have to be very high at all: we just want to exchange small messages such as “Here is my ID: xxxx” , or “Start animation X at time T”.… Read more
Last Friday we received new motors : the EP4108 320KV with built-in ESC.
We’re particularly interested in those because they have a reflashable integrated BLHeli ESC. It turns out that, starting with BLHeli_S v16.5, which is an open source ESC firmware, a new protocol is supported to replace the old PWM control method : DShot. It’s a serial protocol where speed information is encoded in 16-bit frames, instead of analogically in the duty cycle of a PWM signal.
There are three generations of BLHeli firwmare : BLHeli, BLHeli_S, and BLHeli32 (wich is no longer open source), each with several versions.… 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
Yesterday we mostly worked out the detail of how we’ll be detecting neighbouring Phyllos.
Without further ado, here it is :
Step 1 : Discovery and identifier attribution
The first step for the Phyllos is to establish collectively which other Phyllos are present. Each Phyllo must therefore broadcast its presence and be given an identifier.
This step must be repeated regularly in case Phyllos are switched on/off.
As described in this post, we plan to base the protocol on wifi broadcast: a Phyllo regularly broadcasts its IP over wifi to signal that it is still on. The others register this IP address in a local running Phyllos table.… Read more
In order to display animations that flow back and forth between several Phyllo, the Phyllos need first to be able to know each other’s position.
For now, we have reduced this problem to this : to display animations in the proper orientation relative to its neighbours, each Phyllo needs to know the direction of each neighboring Phyllo. They have no real need to know exactly how far they are from each other.
Associating detection and communication
It is not enough to merely detect Phyllos if the detection method doesn’t allow us to distinguish one Phyllo from another. We have to be able to both talk to a specific Phyllo AND know where it is physically located.… Read more