Gina

I'm running the timer interrupt at 3s.  Only the number of hardware interrupts within that period is important.  The 1m speed integration can be done on counts of the timer ISR.  As long as there are 20 sets of counts summed in the 1m routine it doesn't really matter if the odd set of counts gets lost.

Since the wind measurements no longer mean anything (except the direction) I have unscrewed the mast from the obsy corner post and brought the whole contraption indoors.

Guess I could put

interrupts++;

back into the ISR and remove the print statements from the loop.  OTOH I would really like to know what the code in the loop is actually doing.  I'm not happy just using code "blind".

I have yet to work out what I need to do to this to suit my system.

void loop() {
  if (interrupts > 0) {
    portENTER_CRITICAL(&timerMux);
    interrupts--;
    portEXIT_CRITICAL(&timerMux);
    totalInterrupts++;
    Serial.print("totalInterrupts");
    Serial.println(totalInterrupts);
  }
}

Only the wind speed timings and calculations are time critical, the direction isn't and could be handled with periods in the main loop as before.  Same with all the MQTT messages with a flag to show when speed messages were ready to send.

Tried increasing number of timer ticks to 3,000,000 for 3s and that worked as expected.

Now I presume I just need to insert the do3sJobs(); in the interrupt handler instead of interrupts++;

void IRAM_ATTR onTime() {
  portENTER_CRITICAL_ISR(&timerMux);
  interrupts++;
  portEXIT_CRITICAL_ISR(&timerMux);
}

Like this

void IRAM_ATTR onTime() {
  portENTER_CRITICAL_ISR(&timerMux);
  do3sJobs();
  portEXIT_CRITICAL_ISR(&timerMux);
}

Then inside the do3sJobs(); count 20 times and do the do1mJobs(); after which it will return to what it was doing in the main loop including reconnecting.

Ah...  had a thought - the sending messages to MQTT would be in the time critical code.  Only the time critical calculations need doing within the interrupt coding.  I could set a flag and do the sending messages in the main loop.

Tried moving the interrupt handler above the setup and it worked!!!

volatile int interrupts;
int totalInterrupts;

hw_timer_t * timer = NULL;
portMUX_TYPE timerMux = portMUX_INITIALIZER_UNLOCKED;

void IRAM_ATTR onTime() {
  portENTER_CRITICAL_ISR(&timerMux);
  interrupts++;
  portEXIT_CRITICAL_ISR(&timerMux);
}
 
void setup() {

  Serial.begin(115200);

  // Configure Prescaler to 80, as our timer runs @ 80Mhz
  // Giving an output of 80,000,000 / 80 = 1,000,000 ticks / second
  timer = timerBegin(0, 80, true);                
  timerAttachInterrupt(timer, &onTime, true);    
  // Fire Interrupt every 1m ticks, so 1s
  timerAlarmWrite(timer, 1000000, true);      
  timerAlarmEnable(timer);
}

void loop() {
  if (interrupts > 0) {
    portENTER_CRITICAL(&timerMux);
    interrupts--;
    portEXIT_CRITICAL(&timerMux);
    totalInterrupts++;
    Serial.print("totalInterrupts");
    Serial.println(totalInterrupts);
  }
}

Found this and tried it :- Timer Interrupts Explained with Examples

volatile int interrupts;
int totalInterrupts;

hw_timer_t * timer = NULL;
portMUX_TYPE timerMux = portMUX_INITIALIZER_UNLOCKED;

void setup() {

  Serial.begin(115200);

  // Configure Prescaler to 80, as our timer runs @ 80Mhz
  // Giving an output of 80,000,000 / 80 = 1,000,000 ticks / second
  timer = timerBegin(0, 80, true);                
  timerAttachInterrupt(timer, &onTime, true);    
  // Fire Interrupt every 1m ticks, so 1s
  timerAlarmWrite(timer, 1000000, true);      
  timerAlarmEnable(timer);
}

void IRAM_ATTR onTime() {
  portENTER_CRITICAL_ISR(&timerMux);
  interrupts++;
  portEXIT_CRITICAL_ISR(&timerMux);
}

void loop() {
  if (interrupts > 0) {
    portENTER_CRITICAL(&timerMux);
    interrupts--;
    portEXIT_CRITICAL(&timerMux);
    totalInterrupts++;
    Serial.print("totalInterrupts");
    Serial.println(totalInterrupts);
  }
}

But it won't compile - with this error :-

I thought "This looks simple enough."  Thought I'd found something I could build on, after all it shouldn't be that difficult.  Just need the info.  Guess my search continues...  Unless anyone can help or explain this.

I'm looking at ESP32 Timer interrupts and found this from Espressif :- API Reference »Peripherals API »Timer

Thanks.  I'm understanding MQTT better and better as I go along with the help of people like you.  😀

I need to sort it out but it looks like Timer Interrupts are what I want to guarantee that the calculations take precedence over MQTT reconnection.

That's fixed it.

Maybe it needs to reconnect to MQTT each time it wants to send a message.  That's once a minute.

Now it isn't connecting to MQTT.

2 hours ago, skybadger said:

you can also drop this line as no longer required 

if (!client.connected()) {reconnect();}

since the Wifi object will auto reconnect if it detects a broken connection.

That reconnect is what is causing all the trouble it seems - leave the system frozen for at least 5s while it tries to reconnect.

I can easily remove that line but what about the following line - is that alright still.

void loop() {
  if (!client.connected()) {reconnect();}
  client.loop();

I shall have to try to arrange that a lost connection doesn't interfere with the calculations. 

I can see why the disconnections cause an increase in Gust speed and a reduction in Mean speed.  The Gust speed is obtained from the number of anemometer pulses and therefore the number of counts from the interrupt handler.  The interrupt handler is not interrupted by disconnection but the resulting count continues to rise if the 3s period is interrupted by disconnection.  OTOH the Mean is dependent on the summing process and if that is interrupted, data is lost resulting in a lower sum.

I can use the test setup to cause connection failures by interrupting the WiFi signal.

Or so I thought but I can't stop the connection.  I've completely shielded the WiFi with metal but it still connects.  Maybe it's because it's connected to my Mint box by USB.

29 minutes ago, globular said:

I'm not sure why everything resets to zero though - it seems unlikely connection delays could last long enough to cause that. 

Yes, that's a puzzle.

16 minutes ago, skybadger said:

Can you get a ring buffer dump every time you have gone round the ring index. 

I certainly could.

Quote

Is your buffer being written from somewhere else too ?

Pretty certain it isn't.

Quote

If you are happy that the individual values are in range, does the sum overflow ?

No, it doesn't.

Quote

Are you getting a rash of spurious edges that cause it to occasionally overflow ? a la button damping ?

No, I don't think so, the Hall device has considerable hysteresis and produces clean, square pulses.

Things seem to work fine when there are no disconnects - I think this is the problem.  I need to take account of the ESP32 getting locked up by connection problems.  And I though using timing periods was a clever approach!!!  Guess I'm not as clever as I like to think!! 🤣

12 minutes ago, globular said:

Hi Gina,

The maths within do1mjobs relies on do3sjobs being called 20 times between runs; you have a /133 (and the 133 = 10 * 20/1.5).  With connection issues causing 5 second waits between retries there may not always be 20 calls to do3sjobs and so your mean calculation will be too low (i.e dividing the sum of less than 20 speeds by 20 will lower the average speed).

You could solve this by incrementing a counter in do3sjobs which is then used in do1mjobs instead of the fixed 133 (i.e. use /(10*counter/1.5); and then reset it to zero after it's been used in do1mjobs.

I'm not sure why everything resets to zero though - it seems unlikely connection delays could last long enough to cause that. 

Ah yes, lost connection delays could cause a problem and yes, using counting rather than timing would be better.  The actual timing of messages is not important but getting them right is.

It's still doing it!!  Got up to 4mph and then crashed back to zero!!

Well, the test sketch is not showing the problem I'm getting with the real thing!!  That seems to prove the problem is not with the calculations but there is a problem none the less!!  The direction calculations are still running and everything is the same as the real thing except I'm simulating the anemometer pulses.  The only thing I can think of trying is to set up all the dials and graphs as the real thing in a Test tab on the Dashboard.

One other thing occurs to me - everything was fine with the display for a couple of days so I'm wondering if there is something time related.  I guess I could reset the real wind client by powering down and back up again.

Here's the current Wind display before I shut it down.

Well, I guess it isn't too bad but it isn't right so it fails the test.  Timing variations might explain the Gust speed varying between 12 and 13.  The Mean Speed is supposed to be displayed in tenths but I may have used int as speed to the nearest mph is good enough.  Think I'll try a large increase in wind speed and see if serious errors arise.  I'll go to 200ms next - 5pps = 5x4.5mph = 22.5mph.  I would expect the speed to show as 22 or 23.

Problem showing.  Mean Speed rose to 11mph rather than 12 then dropped back to 10.  Continuing the test at this simulated wind speed.