Embedded Developer

A previous post looked at measuring rainfall using a pluviometer that generated a pulse for every 0.2794mm of rainfall. The conclusion of that post was that the algorithm used to read the counter could generate a significant error in the right circumstances.

So let’s have a look at what we can do about the error.

Parallelism

Time for an admission, the algorithm used to collect the sensor reading was not as efficient as it could have been. The code read one bit at a time from the MCP23017 chip and built up the 8-bit sensor reading gradually. This reading took approximately 2800us to complete.

This is more than enough time for one or more of the bits to change in the time taken to take the sensor reading.

Fix One – Read 8 Bits in One Go

A more detailed examination of the library for the MCP23-17 reveals methods for reading not only one bit but 8 and 16 bits in a single operation (from a callers pint of view). The point about a callers point of view will become important later.

For a single 8-bit read the application can obtain all of the bits in a single, near instantaneous pass. Reading the counter in this manner takes approximately 480us. Most of this time will be spent setting up the call to the API and talking to the MCP23017 at 100kHz.

So for a single 8-bit read we have reduced the possibility or error caused by the data changing during the time the reading is being made.

Fix Two – Stop the Clock – FAIL

Within the API for the MCP23017 is an additional method for reading both of the registers “at the same time”. This is quoted because the library reads the first 8 bits in one request and then makes a second request for the next 8 bits. The request mechanism is working at 100 kHz and so there is going to be a finite delay between reading the two 8 bit registers. Plenty of time for the values to change.

One solution is to borrow on an old idea from CPU design, namely using a clock to synchronise operations.

Any operation in a CPU is a combination of signals passing from one gate to another, to yet another and so on. Each gate takes a finite amount of time to process any signals and generate a result. This time is know as the propagation delay.

In the case of the pluviometer, the propagation delay is the amount of time needed to read the counter (the registers in the MCP23017).

In a CPU the clock synchronises the signals and output by effectively freezing the state of the system. So, the input to a system might be changing but the use of the clock freezes the output of the CPU until the next clock pulse.

The same idea can be used with the pluviometer but instead of freezing the output we freeze the input while a reading is being made.

The only problem with the implementation being considered was that the switch caused multiple signals to be generated even with the debounce circuit.

Time for a rethink.

Fix Three (or Two Revisited) – Multiple Readings

Stepping away from a problem can often yield an alternative solution as the mind works on the problem subconsciously. The problem is that we could have a reading taken whilst the input signal is changing the value being read. So if a reading is taken twice and the values are the same then we can be confident that the input has not changed provided that the time between the samples is longer then the time taken for the input to change.

A simple solution to the problem.

Software Changes

The software change is minimal, read the input twice until a consistent sample is read, then reset the counter.

A retry counter is also used in order to prevent the reading method from blocking the application.

uint8_t first, second;
byte retryCount = 0;

do
{
    first = _outputExpander.readGPIO(1);
    second = _outputExpander.readGPIO(1);
    retryCount++;
}
while ((first != second) && (retryCount < 3));
if (first == second)
{
    _pluviometerPulseCount = first;
    _pluviometerPulseCountToday += _pluviometerPulseCount;
    ResetPluviometerPulseCounter();
}
else
{
    _pluviometerPulseCount = 0;
}

One important point to note is that if the retry count exceeds three, then the method exist but sets the current count to zero without resetting the pluviometer counter (hardware). This allows the rainfall measurement to continue and allow for the reading not to be distorted.

Conclusion

A couple of minor software changes have improved the reliability of the pluviometer samples. There is still the chance of missing a single sample (0.2794mm) for every time the counter is read.

A further enhancement would be to increase the time between samples. This could be done by taking a measurement every hour (or more) or to accumulate the readings over a long time (say a day) and reset the counter once a day.

The last days have seen the final two sensors connected to the Oak, the wind direction and the ground temperature sensors.

Ground Temperature Sensor

This sensor is a DS18B20 sensor that has been encapsulated in a rubber like coating to make it waterproof. The sensor has a 1.8m (6 ft) waterproofed cable attached.

DS18B20 Waterproof Temperature Sensor

The sensor uses a one wire protocol to communicate with the microcontroller, so only three connections required, power, data and ground. Strictly speaking, only two connections are required, data and ground as the sensor can use power from the data line to provide enough power for the sensor.

Adafruit also provide a library for communicating with the DS18B20 sensor along with some example code. This makes working with the sensor a relatively simple job. Most of the code required to set up and read the sensor was taken from the example code provided and as such will not be discussed is any detail here.

Wind Direction Sensor

The wind direction sensor is an analogue sensor and the last of the sensors on the Weather Station sensor kit.

The sensor consists of a series of reed switches in a star shape. The wind vane uses magnets to close the reed switches and the resulting connections connect a resistors to ground through one of the wires. The second wire should be connected to a a resistor (the example in the data sheet is 10K) with the other end connected to V_cc.

The result is a potential divider circuit. The output from the circuit can be connected to an Analog to Digital Converter (ADC). The datasheet for the sensor is supplied with a list of the resistance values along with expected outputs for a 5V supply. All of the circuitry used so far has been using a 3.3V supply as the Oak is a 3.3V component. A little bit of spreadsheet wizardry converts the values to a 3.3V supply:

This now brings us on to the problem of the number of ADC channels on the Oak, there is only one and we have two analogue devices, the ultraviolet light and the wind direction sensors. One solution is to add a multichannel ADC to the system.

The ADS1115 is a four channel ADC with a an I2C bus. As with the DS18B20, there is a library available in the Arduino library collection, again written by Adafruit.

In the initial experiments with this library using a potentiometer I experienced problems with the conversions appearing to be duplicated / incorrect. It appeared that the conversion was appearing on the next channel (i.e. conversion for A0 was given on A1) or on both channels (i.e. A2 and A3 having the same reading). Perhaps there is not enough time being left for the ADC to complete the sample and conversion. A brief investigation into the library code lead to a pause parameter being used to allow the ADC to perform the conversion. This was 8ms, changing this to 10ms fixed the issue.

Next step is to calibrate the wind direction sensor and confirm the sensor readings with the theoretical values from the spreadsheet.

A painstaking few hours with the sensor, the ADC and the spreadsheet followed. The net result was the following:

The final column in the table above is the actual 16-bit reading from the ADC. The intention is to use these values when working out the wind direction, it is quicker (from a processor point of view) to work with integers rather than floating point numbers. Comparisons are also more accurate.

From a code perspective, the best way to deal with the above is to use a lookup table. The table can be ordered on the actual reading, or a mid-point reading.

If the readings are ordered in ascending order then we can calculate the values that are midway between two readings. The idea is to give a spread of possible values for a particular reading. There will be slight variations in the ADC reading around the theoretical value for any particular angle. Rather than define the actual spread, or a tolerance, say 100 points either way, a mid-point value should give a very wide range and should ensure that we have the right result for the particular ADC reading.

So let’s look at some code. There are a couple of basic things we need to set up, an enumeration to represent the wind direction and a data structure for the look up table:

enum WindDirection
{
    North, NorthNorthEast, NorthEast, EastNorthEast, East, EastSouthEast, SouthEast, SouthSouthEast,
    South, SouthSouthWest, SouthWest, WestSouthWest, West, WestNorthWest, NorthWest, NorthNorthWest
};

//
//  Entry in the wind direction lookup table.
//
struct WindDirectionLookup
{
    uint16_t midPoint;
    uint16_t reading;
    float angle;
    WindDirection direction;
    char *directionAsText;
};

WindDirectionLookup _windDirectionLookupTable[16];
uint8_t _windDirectionLookupEntry;

The last two entries direction and directionAsText are really there to give us a meaningful description within the code and also a textural description should we need to output the wind direction to a display.

Now that the table is declared we should really populate it:

//
//  Populate the wind direction lookup table.  Each entry has the following form:
//
//  midPoint, reading, angle, direction, direction as text
//
//  Note that this table is order not in angles/wind direction but in terms of the
//  mid points of the ADC readings found empirically.  This allows for easier
//  searching of the table.
//    
_windDirectionLookupTable[0] = { 0, 1112, 112.5, EastSouthEast, (char *) "East-South-East" };
_windDirectionLookupTable[1] = { 1262, 1412, 67.5, EastNorthEast, (char *) "East-North-East" };
_windDirectionLookupTable[2] = { 1489, 1567, 90, East, (char *) "East" };
_windDirectionLookupTable[3] = { 1851, 2136, 157.5, SouthSouthEast, (char *) "South-South-East" };
_windDirectionLookupTable[4] = { 2630, 3124, 135, SouthEast, (char *) "South-East" };
_windDirectionLookupTable[5] = { 3627, 4131, 202.5, SouthSouthWest, (char *) "South-South-West" };
_windDirectionLookupTable[6] = { 4359, 4587, 180, South, (char *) "South" };
_windDirectionLookupTable[7] = { 5726, 6866, 22.5, NorthNorthEast, (char *) "North-North-East" };
_windDirectionLookupTable[8] = { 7333, 7801, 45, NorthEast, (char *) "North-East" };
_windDirectionLookupTable[9] = { 9220, 10639, 225, SouthWest, (char *) "South-West" };
_windDirectionLookupTable[10] = { 10640, 10642, 247.5, WestSouthWest, (char *) "West-South-West" };
_windDirectionLookupTable[11] = { 11263, 11884, 337.5, NorthNorthWest, (char *) "North-North-West" };
_windDirectionLookupTable[12] = { 12585, 13287, 0, North, (char *) "North" };
_windDirectionLookupTable[13] = { 13639, 13991, 292.5, WestNorthWest, (char *) "West-North-West" };
_windDirectionLookupTable[14] = { 14497, 15004, 315, NorthWest, (char *) "North-West" };
_windDirectionLookupTable[15] = { 15491, 15978, 270, West, (char *) "West" };

Reading the sensor is as easy as getting the ADC rading and then walking through the look up table:

//
//  Read the wind direction sensor and calculate the direction the vane is pointing.
//
WeatherSensors::WindDirection WeatherSensors::ReadWindDirection()
{
    uint16_t windDirection = _adc.readADC_SingleEnded(_windDriectionAnalogChannel);

    _windDirectionLookupEntry = 15;
    for (int index = 0; index < 15; index++)
    {
        if ((windDirection > _windDirectionLookupTable[index].midPoint) && (windDirection <= _windDirectionLookupTable[index + 1].midPoint))
        {
            _windDirectionLookupEntry = index;
            break;
        }
    }
    message = "Wind is blowing from ";
    message += _windDirectionLookupTable[_windDirectionLookupEntry].directionAsText;
    Debugger::DebugMessage(message);
}

//
//  Get the last wind direction reading as a textural description.
//
char *WeatherSensors::GetWindDirectionAsString()
{
    return(_windDirectionLookupTable[_windDirectionLookupEntry].directionAsText);
}

The principle is to walk through the look up table and compare the reading from the ADC with the midpoint reading. The midpoint for any element in the table is the value halfway between this value and the previous value.

So if a reading x is greater then x_m and greater than x_m+1 (where x_m is the midpoint of the current element in the table x_m+1 is the midpoint of the next element in the table) then the program should move on to the next element.

If in doubt walk thorough an example. Take a reading x = 1567, the exact reading for East and walk through the table above. The answer you should reach is East. Now take a reading x = 1566 or x = 1568 and the answer should be the same, namely East. Finally, be a little more extreme, say x = 1530, the answer should still be the same.

Conclusion

The final two sensors have been connected to the Oak (on breadboard) and indoor readings are available through the serial port.

Next steps:

1. Fix the rain fall meter issue wher it is possible to produce an incorrect reading when a pulse is generated by the rainfall guage at the same time as the gus=age is being read.
2. Add a real time clock (RTC) to the system for times when the internet is not available.
3. Send data to the cloud
4. Transfer the design to protoboard and start to work on PCB designs

Still plenty to do on the design / coding front. And at some point this needs to be made hardy enough for the great outdoors, and become self powered.

A new day and a new sensor to look at, the pluviometer.

The pluviometer is a mechanical sensor that looks a little like a see-saw. A small plastic bucket is placed on each side of the fulcrum. The buckets are designed so that when a critical mass of water is in one bucket it tips the see-saw and the bucket on the other side starts filling. The process continues as each bucket is filled and emptied. A picture paints a thousand words, so here is a view of the inside of the pluviometer:

Inside the Pluviometer

A small magnet is placed on the see-saw and a reed switch is behind the fulcrum. The tipping motion triggers the reed switch each time the see-saw tips, this in turn generates a single pulse.

Reading the switch becomes a seeming simple repetition of the wind speed problem, namely debouncing a switch and attaching an interrupt.

One long term goal has to take this solution off grid. This will make power consumption a critical factor in the design. Attaching an interrupt does not necessarily become an attractive option as the Oak would be running continuously and with the WiFi running this would consume a fair amount of power.

According to the specification for the pluviometer, a pulse will be generated for every 0.2794mm of rainfall.

Offline Counting

One possible solution to the power problem would be to put the Oak to sleep and wake it up every say 5-15 minutes to take measurements and upload them to the cloud. Doing this would reduce power but would also mean that no measurements would be take during the sleep period if interrupts were used.

A cheap solution in terms of cost is to use the 74HC4040 counter. This could be put into a circuit and kept active while the Oak is sleeping. The output from the debounced switch would then be used as a clock signal for the 74HC4040. This would allow the pulses from the pluviometer to be counted while the Oak is sleeping.

One final connection that is required for the counter is a reset connection. Left to itself, the rain gauge counter would continue to count pulses until the counter overflowed and started from zero once more. From a design perspective there are a few options:

1. Reset the counter each time it has been read
2. Reset the counter once a day
3. Let the counter overflow and detect the reset to zero

One consideration will be the amount of rainfall the system can detect before it resets to zero.

Maximum number of counts = 2¹²

Which gives 4096 counts. However, for simplicity we will only consider the lower 8 bits, i.e. 0-255 counts. The system can always be expanded later should this be necessary (or if the system has the capacity).

Maximum rainfall = 255 * 0.2794 mm

Giving a maximum rainfall count of 71.247 mm per counting period. It is envisaged that the counting period would be somewhere in the region of 5-15 minutes. This would make an hourly average of 285mm assuming a steady rainfall and a 15-minute interval between counts.

This should be well within expectations for UK weather.

As an aside, the full 12-bits would allow for a rainfall of 1144mm per counting interval, or 4.5 metres of rain per hour.

Schematic

With a little supporting hardware to be added, the schematic looks as follows:

Weather Station Partial Schematic

Note that the BME280 and TSL2561 are also on the schematic.

The rain gauge counter bit values have been labeled RXQx, RG = Rain Gauge and Q is the standard notation for a bit in a logic design.

Software

The MCP23017 (I2C version of the IO expander) is sold by Adafruit. They have a standard Ardunio library for this component and so in the interest of code re-use, expediency and idleness this will be used.

So the first thing to do is to create an instance of the MCP23017 IO expander:

Adafruit_MCP23017 _outputExpander;      // MCP23017, I2C controlled 16-port output.

Next up, the output expander needs to be setup. Looking at the schematic, the output from the counter is mapped to port B on the MCP23017. This maps to IO pins 8 to 15 inclusive. These bits should be set to inputs. One final piece of configuration is the reset pin, this needs to be set to output:

//
//  Set up the pluviometer, zero the counts and then attached and initialise the
//  counter to the output expander.
//
void WeatherSensors::SetupRainfallSensor()
{
    _pluviometerPulseCount = 0;
    _pluviometerPulseCountToday = 0;
    //
    //  Attach the rainfall counter to the output expander.
    //
    int index;
    for (index = 8; index < 16; index++)
    {
        _outputExpander.pinMode(index, INPUT);
    }
    //
    //  Attach the counter reset pin to the output expander and reset the counter.
    //
    _outputExpander.pinMode(PIN_RAINFALL_RESET, OUTPUT);
    ResetPluviometerPulseCounter();
}

As well as setting up the pulse counter, the above code resets internal counters for rainfall today and also resets the pulse count.

Reading the pulse counter is a simple matter to reading the state of each bit starting at 0:

//
//  Read the counter from the Rainfall sensor then reset the count.
//
void WeatherSensors::ReadRainfallSensor()
{
    byte mask = 1;

    _pluviometerPulseCount = 0;
    for (int index = 8; index < 15; index++)
    {
        if (_outputExpander.digitalRead(index) == 1)
        {
            _pluviometerPulseCount |= mask;
        }
        mask <<= 1;
    }
    _pluviometerPulseCountToday += _pluviometerPulseCount;
    ResetPluviometerPulseCounter();
}

Accuracy

The eagle-eyed amongst you will have spotted a small flaw in the above logic, namely that the pulse counter could increment whilst the system is reading the values. It turns out that this matters a great deal in some cases. Consider the following:

The pulse counter has counter 15 pulses (0b00001111). The software is processing these bit values and has processed bit 2, counter value = 7. A pulse is registered by the counter and the pulse count becomes 16 (0b00010000). The system processes bit 3 and finds it is 0 and then moves on to bit 4 and finds this is 1, i.e. 16. The counter then becomes 16 + 7 = 23 instead of 15. A little bit difficult to see, so lets put this in tabular form:

The counter column contains the value in the 74HC4040 counter chip (lower 8 bits only).

The problem occurs because the reading of the pulses is not instantaneous, the software takes longer to process the data than the counter takes to register a clock pulse and update the counter.

There are two possible solutions to this, both left for later investigation:

1. Add an AND gate between the incoming rain gauge pulse and the 74HC4040 clock pin. This can be turned off when taking a reading.
2. Check the documentation for the MCP23017 to see if the values can be latched and then read. Latching the values means that they cannot be changed; once latched and the values being read would be consistent.

Both offer a solution to the problem and will be left as a later refinement.

Conclusion

The pluviometer is a seemingly simple switch but it needs to run constantly. This presents a challenge when considering the requirement to save power where possible. This article presented a possible solution using a small number of components bringing powered on permanently.

The solution does introduce a possible error in the reading, although this should be reasonably small. A full analysis will be presented in a future article.