Another great challenge was to find the right timing and synchrony between all the modules in the network.

The reboot after deep sleep had to be right.

If in advance it would cause high power consumption, if delayed it would result in information loss or blocking.

After struggling with mA, I also had to struggle with milliseconds ...

Communication description

The module that is programmed with address 1 is the one that controls the synchronization by periodically transmitting its 4 bytes + 2 bytes communication control packet used by all the modules:

• Sync time = offset parameter programmed by the user, to improve synchronization by anticipating or delaying it

• Life = number that increases with each sending of packets

The next module, after reading the sensor, performs the following functions:

1. Begins to receive data and when the "Life" byte
   increases in the correct way, it begins to transmit the data to the next module: therefore there is no transmission unless the data has been fully received before
2. Repeatedly transmits the "Life" control byte
   until the OK arrives from the receiving module, using the OnDataSent function: therefore, in order not to lose data, there is no complete transmission of the packet until the next module is ready to receive. 

3. Transmits the complete data packet, after which it enables Deep Sleep mode

Deep sleep time

The first important thing to define was the Deep sleep Time.

Green Detect is a project open to various objectives.

If our network aims to detect urgent environmental data for the prevention of disasters (for example: forest fires, floods), where it is necessary to be quick to detect any anomalies, it becomes essential to acquire the sensors very frequently.

If our network is used to acquire statistical data (such as ambient temperature, humidity), it is sufficient to read the sensors less frequently.

Clearly more frequent is the reading, higher is the power consumption of the module.

After a lot of tests, I decided to acquire the sensors every 30 seconds, so I set the deep sleep time to this value, here's why:

• It 's a time that allows a quick detection of catastrophic events, without consuming too much, for me it is the right compromise
• For slower processes, I know that I acquire and record more data than necessary... but what's the problem?
• RTC built into the ESP8266 controller is not very precise
  and I have verified that above 60 seconds, the deepsleep time varied significantly from sensor to sensor, making synchronization very complicated.

Sensor start up time and reading

The sensors require an initialization time to function, before which the reading is not reliable. In the various tests I have tried to minimize this time, but I have not been able to go below 100 msec.

The sensor reading time depends on the sensor itself and its libraries and I was not able to act on this task to improve synchrony.

Data waiting from previous module

This task is the one where I could act to improve the synchrony and reduce the awake time of the controller.

This time depends exclusively on how you set the deep sleep time.

In the first tests I set a constant deep sleep time at 30 sec.

This route proved to be immediately unsuccessful, with modules waiting to receive or transmit even for 3 or 4 seconds: unacceptable.

Why?

Because the network can include different sensors, with different reading times.

Because the clock of the microcontrollers is not perfectly accurate and within 30 seconds it can accumulates differences between the various modules.

Because transmission and reception don't always last exactly the same time.

How to solve this challenge?

Self adapting deep sleep time

The only effective solution was to dynamically vary the deep sleep time at each cycle, adding or subtracting an offset time to the 30 seconds of deep sleep.

To do this, I decided to measure the time from the controller awakening to the reception of the first byte, using micros() function.

Chronometer start:

 Chronometer stop:  

After that, by appropriately processing the measured time, I obtained the offset to add or subtract from the deep sleep, in order to determine a more correct awakening time at the end of the next deep sleep cycle, significantly improving synchrony!