• 19.10.26

    Oleg Vyalkin • 2 days ago • 0 comments

    I spent the whole day analyzing the situation with MQTT. Well, there's nothing new on the server side, mosquitto + rust provides a ready-made server application in a few lines of code. With the mqtt client under no_std, frankly, some kind of bullshit. Either clients do not fully implement the necessary functionality (such as TLS and authentication support), or they lack some of the functionality of the library itself. I've hired the most popular embedded client, rust_mqtt. It doesn't have a poll loop implemented. At the same time, its API is designed in such an unobvious way that it is not immediately clear how to do this poll without breaking all the logic of asynchronous exchange. Glory be to Astra, we almost smashed our heads against the wall, but after digging through all the examples and sources, we figured out how it works under the hood, so today there is even some kind of blank mqtt service for ESP32.

  • 17.10.26

    Oleg Vyalkin • 2 days ago • 0 comments

    I spent half a day struggling with the INA3221 board I bought yesterday. For some reason, it was designed as a low‑end meter. That is, despite the fact that the chip itself has six pins of the ChX+ ChX- type, the developers somehow decided that such functionality would be unnecessary and shorted all the pins to GND. Why and for what purpose? Probably, I’ll never know the answer to this question. After studying the board, I realized that this could be quickly fixed by trimming three traces and resoldering the power line contacts directly to the shunt. After that, the board started working as it should. I made a simple Power Manager; now I know the status of the lines: solar panel — controller, controller — battery, and battery — device.

    DEVICE POWER STATE:
Solar panel: 0.0103872 W
Charging: 0.001616 W
Battary charge: 84 %
Device conumtion: 0.79356164 W

    Power Manager Source Code

    Image

  • 16.10.26

    Oleg Vyalkin • 4 days ago • 0 comments

    I’ve started putting together a "mock-prototype" for a long-term test setup to evaluate stability and power consumption. I call it a "mock" because it’s impossible to accurately measure power consumption using development kits—there’s too much parasitic current draw from components unnecessary for the task, such as cheap LDO regulators and RGB LEDs. The goal of this build is to refine the software; later on, I’ll need to design a custom PCB and assemble a dedicated board. I picked up an INA3221 sensor and soldered together a new version that includes a 5W solar panel. I also tried to add over-discharge protection for the 18650 cells, but the nickel strips wouldn’t take solder at all—not even a little bit. I definitely need a spot welder. For now, I’m using cells that have built-in protection (salvaged from a flashlight). The purpose of the INA3221 is to monitor current and voltage pairs at three specific points: between the solar panel and the charge controller, between the charge controller and the battery, and between the battery and the device itself.

    Image
    Image

  • 15.10.26

    Oleg Vyalkin • 5 days ago • 0 comments

    I set up a test bench to study the node synchronization process within a network. An ATGM336H GNSS module was connected to Node 1, and a synchronization handler was implemented that incorporates PPS (Pulse Per Second) correction. Node 2 was configured as a Wi-Fi station that retrieves time via the NTP protocol, synchronizes itself accordingly, and broadcasts this time using the ESP-NOW protocol. Node 3 receives this time wirelessly and synchronizes itself in the same manner. For visual verification, I created a simple scheduler that triggers an LED every two seconds within a 10-second epoch. Initial testing immediately revealed the presence of jitter between the devices, as the LEDs did not light up in perfect unison. High-speed footage (captured at 240 fps) showed the following sequence: Node 3 -> (8.5 ms) -> Node 2 -> (12.5 ms) -> Node 1. These figures are generally within the expected range. The GNSS-derived time on Node 1 is highly accurate. Conversely, NTP-based time on Node 1 inherently involves jitter, stemming from the Wi-Fi stack, wireless transmission, and asymmetric routing across the internet. Collectively, these factors introduce an unavoidable error in time correction—in my case, 12.5 ms. The 8.5 ms latency for wireless data transmission from Node 3 to Node 1 is also within the typical range for consumer-grade Wi-Fi.


    Sources of the synchronization methods

    Image
    Image
    Image

  • 14.10.26

    Oleg Vyalkin • 10/14/2026 at 06:51 • 0 comments

    In this first log, I will outline the work completed on the project so far. I have implemented the L3 layer of the mesh network. While it is currently a preliminary version, it already includes all the functionality required for dynamic routing, node discovery, and multi-hop data transmission. The software is being developed in Rust using the Embassy framework. To verify the system on actual hardware, I built four simple breadboard prototypes using the ESP32-C6 microcontroller, powered by 18650 batteries. To simplify testing, I utilized the ESP-NOW protocol for the MAC layer. Testing confirmed that the mesh network functions correctly, with packets successfully transmitted between nodes in multi-hop mode.

    I am currently investigating time synchronization within the network and have successfully implemented time acquisition via GPS and NTP.

    This post serves as a brief summary of the current status; future posts will provide more detailed and technical information.

    Image