Freesteel Blog » Wind trace interrupt hiccups

Wind trace interrupt hiccups

Wednesday, January 28th, 2015 at 11:52 am Written by:

As I suspected, this is where all my grand designs go completely wrong. Recall that I proudly got the wind speed probe to convert each passing of the fan blade into a square wave voltage spike earlier this month.

Well, the reading of this signal was to be done with the following code:

volatile int windcount = 0; 
volatile int microtimewind = 0; 

void windinterrupt() 
{
    long microtimestamp = micros(); 
    windcount++; 
    microtimewind = microtimestamp - lastmicrotimestamp; 
    lastmicrotimestamp = microtimestamp; 
}

void setup()
{
    attachInterrupt(windpin, windinterrupt, RISING);
}

In other words, I’d capture the exact number of microseconds when each blade of the wind sensor fan went past the proximity detector.

I saved the values to the SD card and then plotted them as I blew air through the detector and spun the fan. And I got all these horrible spikes where the microsecond time went down to zero:

windtrace1

Of course I thought this was a hardware issue, some noise in the amplifier or something, so I wrote some spike detection code to find out how frequently this was happening.

I also added some buffering on the microtimewind value so that I could capture every single interrupt.

Here is a series of values annotated from that logfile:

microsecond     microsecond     buffer 
timestamp       interrupt gap   placevalue
 7242251,         2311,           600 
 7244505,         2255,           601 
 7246746,         2241,           602 
 7249025,         2279,           603 [buffering starts here]
 7249025,         2262,           603 
 7249025,         2226,           603 
 7249025,         1,              603 [interrupt queuing starts here]
 7249025,         2,              603 
 7249025,         2,              603 
 7249025,         2,              603 
 7249025,         2,              603 
 7249025,         1,              603 
 7249025,         3,              603           
 7249025,         1,              603 
 7255705,         2178,           614 [buffer cleared]
 7257875,         2169,           615 
 7260086,         2212,           616

As you can see, there’s an event (probably to do with the SD card) which holds back the main loop, and we get 3 good readings when the values begin to be buffered. But then the windpin RISING interrupts (which gets called with each passing fan-blade) starts to get queued.

When whatever is blocking the interrupt function gets unblocked, eight calls are made to windinterrupt() in quick succession (less than 3 microseconds apart).

Well, that was my first impression, until I calculated how many readings should have been in that gap, and my answer is none, because 7249025+2279+2262+2226=7255792, which is close to the reading present when the buffer was cleared.

These extra interrupt calls might be happening, or I might have a bug in my buffering code (I doubt it as the buffer is 12 items long, so would tend to have things of that size instead).

At any rate, it’s completely screwed up. When I enable my spike detector code, it finds no spikes when the SD card is disabled.

It finds spikes when I write the numbers to the OLED display, which is also on the SPI bus.

I get no spikes when I run an I2C device, like the Gyro/accelerometer.

So the SPI is the problem. And this explains why my barometer readings (which communicate through timed bit-banging across an opto-isolator) are also getting the occasional scrambled numbers.

I need the SPI devices for human input/output and datalogging.

What a bummer.

I’m fresh out of ideas for how to transmit this data for the minute.

It’s a shame, because I was looking forward to doing something interesting with this wind meter today.

Here’s a zoomed-in view of the readings. (Ignore the spikes)

windtrace2

If you look carefully, you can see a 6-sequence cycle for the 6 different blades on the fan. As the blades don’t have identical electrostatic characteristics, some of them appear wider and earlier to the sensor than they should. It’s like they are not quite evenly spaced.

I was going to spend today writing the code to measure their ratios in order to factor out this wobble and get a smooth curve. But now there doesn’t seem much point. On to something else.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>