Interfacing a Grove sensor to Arch GPRS V2

Since I had gotten serial communication working to my Arch board, and with it basic debugging, I decided the next step was to get measurements from the Grove humidity sensor.

Firstly, the Wiki entry isn’t particularly helpful, as it only explains how to interface the sensor with Arduino or RPi. Fair enough, as these are popular platforms, but it was a little disappointing seeing as the Arch GRPS V2 and Grove seem to both come under the Seeed umbrella.

Fortunately, the mbed cookbook has a nice little page on the Grove temperature and humidity sensors. The example given with the library was my starting point.

I replaced DHT sensor(p23,SEN11301P); with DHT sensor(P1_14,SEN51035P);, as P1_14 is the pin on the Arch GPRS V2 that matches the pinout of the connector to the Grove.

P1_14 connects to the data line on the Grove DHT22 sensor.
P1_14 connects to the data line on the Grove DHT22 sensor.

SEN51035P is used as it is the product name given to the overall Grove – Temperature&Humidity Sensor Pro module, in some contexts. It is the DHT22 sensor, on a nice and simple breakout board with some pull-up resistors on the data line.

Taking a quick peek at DHT.h, we can see that the enums for DHT22 and SEN51035P are the same:

enum eType{
    DHT11     = 11,
    SEN11301P = 11,
    RHT01     = 11,
    DHT22     = 22,
    AM2302    = 22,
    SEN51035P = 22,
    RHT02     = 22,
    RHT03     = 22
} ;

I found it was going straight to the error case in the main while loop of the example. I went ahead and fleshed this out a bit so that it would print out the specific error, based on the return enum value of sensor.readData(), to a terminal.

enum eError {
    ERROR_NONE = 0,
    BUS_BUSY =1,
    ERROR_NOT_PRESENT =2 ,
    ERROR_ACK_TOO_LONG =3 ,
    ERROR_SYNC_TIMEOUT = 4,
    ERROR_DATA_TIMEOUT =5 ,
    ERROR_CHECKSUM = 6,
    ERROR_NO_PATIENCE =7
} ;

The first error to come back would be “BUSY”, followed by “NO PATIENCE” ad infinitum.

Activity log when trying to interface with the DHT22.
Activity log when trying to interface with the DHT22.

I ignored the BUSY error at first, as this was probably just a wiring issue. It was the NO PATIENCE error that grabbed my attention.

This error comes from the following snippet in DHT.cpp:

    time_t currentTime = time(NULL);
    
    DigitalInOut DHT_io(_pin);

    for (i = 0; i < DHT_DATA_BIT_COUNT; i++) {
        bitTimes[i] = 0;
    }

    if (!_firsttime) {
        if (int(currentTime - _lastReadTime) < 2) {
            err = ERROR_NO_PATIENCE;
            return err;
        }
    } else {
        _firsttime=false;
        _lastReadTime=currentTime;
    }

The program is convinced that I haven’t left at least two seconds between measurements, but back in my main function I had a wait(5) between each measurement, ensuring there was at least 5 seconds between calling the readData() function.

currentTime and _lastReadTime both get their values (directly or indirectly) from time_t currentTime = time(NULL);. Time is documented very poorly in the mbed handbook, so I couldn’t be sure if I was doing something wrong, such as having to initialise it. Using time(NULL), I added seconds since boot to my output log to see if it was incrementing. The answer was:

Timed responses to readData()
NO! The time never increments.

So that’s a big problem. If other libraries use this function for time-dependent processes (which, hey, in the real world that firmware exists in, I’m sure wouldn’t happen too often… right?) then all of these libraries are going to have timing issues.

The solution was to simply comment this check out in DHT.cpp. I know that my program will not be calling this function more than it should, so I am comfortable doing this for now. In the future, there is an example with the on-board RTC that I will look into. For printing messages that are (sort of) timestamped, I will implement Ticker, which is demonstrated on Arch GPRS V2 here.

(After I had fixed this problem for myself, I found someone else had run into the *exact* same issue on the forums.)

Getting rid of this check, I was then stuck on “BUSY”. After checking some wiring and pin declarations (ensure the sensor is plugged into UART, and the data pin must be declared P1_14).

Connecting the Grove humidity sensor to the Arch GPRS V2 UART input.
Connecting the Grove humidity sensor to the Arch GPRS V2 UART input.

With this, I progressed from “BUSY” to “DATA TIMEOUT”. I decided to measure the 3V3 line going into the Grove sensor, and found it was sometimes flickering. It would display about 3.3V briefly, before dropping to about 0.8V once the multimeter had been on there for less than a second. Restarting the unit sometime later, I found it was now reading 0V. This is why we were getting data timeouts, as the sensor was not responding to the microcontroller, as it was not being properly powered.

Checking the schematic, I discovered that you have to enable 3V3 to these three connectors on the board, through Q1:

Schematic of power to Arch GPRS V2 connected sensors
Powering Grove sensor connected to the Arch GPRS V2.

Setting P1_3 to low ensured that the p-channel MOSFET connected VCC_3V3 to the UART connector, and subsequently to the Grove sensor. Checking with my multimeter confirmed this. That this subtlety did not appear in any example is baffling. If you don’t set your pins, they could be high, low, or somewhere in between.

I was now getting data spat out over my USB serial connection! I tested the humidity sensor by letting it log at room temperature, and then holding it over a hot cup of tea:

Output of DHT22 readings
Testing humidity readings from the DHT22

You can see both the temperature and humidity increase, due to the warm steam coming up. It actually took about a minute to get back to 60% after I took it away from my tea, so I suppose there’s a bit of hysteresis in the system, or it had just gotten saturated by the steam.

One last thing – there are a lot of checksum errors (where it reads “CHECKSUM”). This is not critical at the moment, but it is something I will be investigating in the future, along with the way the time function works.


One thought on “Interfacing a Grove sensor to Arch GPRS V2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s