function execution and timing related bug

Following program serves to receive data over a radiolink with HC-12 modules (with very big thanks to Robin2 !!). The transmitter sends every minute once a minute following data:

  1. duty cycle value
  2. temperature at TX
  3. battery voltage
  4. minute of transmission (taken at transmitter)
  5. second of transmission (taken at transmitter)
    The program in question here does the following:
  6. wait for radio data, parse the data and store for further use in next point
  7. once a minute (at second 35)
    2a. calculate moving averages (0.5 weighting) for duty cycle data, temperature and battery voltage
    2b. decide whether to open or close a irrigation valve
  8. once a minute (at second 55) send data to Thingspeak:
    a. temperature at RX
    b. atmospheric pressure
    c. duty cycle moving average (calculated from the received data)
    d. duty cycle raw data (as received in the last minute)
    e. the minute value data was last sent from transmitter
    f. humidity at receiver
    g. battery voltage (raw value) from TX
    h. status of electrovalve2 (in actual use, together with data used above)

I am 100% sure that the transmitter works well and correct data is sent every minute; if the transmitter would stop or its messages not understood or were corrupted then the minute value from the transmitter would not evolve and remain identical (since the transmitter sends once a minute the minute values increment from 0 to 59 and so on).
The data from the receiver that is sent to Thingspeak just drops dead to zero, for one cycle (one transmission) to Thingspeak. The next transmission to Thingspeak the data reverts back to what it should be. This seems to happen at random.

The problem I have is that once in a while, and more often or less often dependent on the timing (seconds past the minute) that the irrigationCommand() and actionTime() functions are executed.

What happens from time to time is that all received values revert to 0 (zero) for one receive cycle and then pick up again, sometimes to revert back to zero again and then pick up again to their correct values.

Since changing the "second" value for execution of irrigationCommand () and actiontime () seem to affect this problem I suspect that while data is actually being received then the values used to calculate the moving averages, and battery value and minute value received from the transmitter are set to zero either during parsing or during reading the receive buffer.

Because the timing at the transmitter is read from a DS3231 clock module and the time at the receiver also is read from its own DS3231 module they may not run the seconds at exactly the same time, in other words: both DS3231 modules are correctly set for the right time and date, their actual seconds values are not synchronised.

Now I hope this is the issue, but then I need a way to get this program to prevent execution of irrigationCommand () and actionTime ()( when actual data is being received.

Does anyone have any clues what may be happening that causes the values posted on Thingspeak to sometimes revert to 0? And how to best solve this?

Note 1: the code is compiled for ESP8266 but the same code will (with a few small modifications) work on Arduino Uno. In other words: this is the same C++ as used for Arduino

Note 2: the code is too large to include here so I attached it in txt format

You should be validating the message with a checksum of some sort I think, you may be getting garbled packets that you assume are valid when they are not.

MarkT:
You should be validating the message with a checksum of some sort I think, you may be getting garbled packets that you assume are valid when they are not.

If they are garbled, why would I receive neat zero's? I admit, introducing a checksum would give 100,00% certainty, while now I cannot give you that.
But why would altering receiver variables affect accuracy at transmitter side?

I added two screenshots of the Thingspeak output, field 4 = duty cycle, field 3 = moving average for this variable. At one point, right before 9:00 AM a dip to zero is visible in fields 3, 4 and 5 (field 5 dips to zero also after 9:00AM but that is because the minutes restart from 0 after 59).

TX Thingspeak output 9-5-18 v2.pdf (86 KB)

TX Thingspeak output 9-5-18.pdf (72.5 KB)

brice3010:
I admit, introducing a checksum would give 100,00% certainty.

Knowing the received data has a high probabilty of being accurate sounds like a very good idea.

So introduce checksuming and see if the 'problem' dissapears because you are now able to reject corrupt data.

srnet:
Knowing the received data has a high probabilty of being accurate sounds like a very good idea.

So introduce checksuming and see if the 'problem' dissapears because you are now able to reject corrupt data.

Can you give me an idea how to introduce a checksum in this case please?