Relay Module KY-019 5V

[tlfong01]

HDC1080 Summary Notes for Programming 1/2

HDC1080 Summary Notes for Programming 2/2

HDC1080 Humidity and Temperature Sensor Module Test Program Design Notes

Now that I have studied the HDC1080 datasheet, I can start coding. But before that I need to do a selfie walk through of the python modules I have coded so far, to refresh my memory, and also thinking how to glue them together.

Old Modules Selfie Walkthrough

1. So far I have debugged 3 modules: i2cutil01.py, rtc01.py, iox01.py, and
now starting the new module, hts01.py.

2. i2cutil01.py

I started rtc01 testing the following RTC DS3231 functions:

Code: Select all

    '0'  'Write and read back Day Register                 
    '1'  'Repeat write 0x5a to Rtc Day Register (for scope)
    '2'  'Read and print temperature once                  
    '3'  'Read and print temperature four times            
    'x'  'Exit 

All 4 functions were almost bug free. Then I renamed rtc01.py to i2cutil01, which when runs standalone, allows user to select any test. It also contains low level I2C functions to read i2c slave device registers in general, and ds3231 register in particular. When imported by other modules, the user select test menu will not start, and the calling modules can use its low level device register access modules, or call the main rtc test menu.

3. rtc01.py

Then I wrote a new rtc01.py, which imports i2cutil01.py and has it own high level register read write functions which call i2cuitl01's low level slave register read write functions. This way, the ugly smbus functions are abstracted away. Module i2cutil01 is a Minimal, Complete, Verifiable, NoProblem Example. But this new rtc01 neess i2cutil01. In other words, only two modules together are then 'minimal'. This new rtc01 module has a fuller set of rtc functions, including real time and interrupt, as listed below:

Code: Select all

     '0' Write read Day register 
     '1' Read temperature  
     '2' Read dateTime              
     '3' Test Square Wave output              
     '4' Test Interrupt output                  
     '5' I2cUtil Write read Day register        
     '6' I2cUtil Read temperature              
     '7' I2cutil test                          
     'x' I2cutil exit  

/ to continue, ...

[tlfong01]

1. I think the pi only need to deliver the start signal. And the rest is done by the sensor ...
2. ... its only 28uS high. And you need also get that one.

MCP23017 sending DHT22 Start Signal

• 1. Yes.

• 2. Yes，the hts DHT22 Start Signal consist of two parts, (a) 1mS low signal, then immediately followed by (b) 28uS high. The 28uS High is the tricky part.

One solution is to use smbus block write. Iox MCP23017 can now block write a seemingly correct Start Signal, switch to input mode, and wait 7 milliSeconds to read 40 hts bits. The only bug is that Iox sends the correct signal at the wrong pin!

[Brandon92]

MCP23017 sending DHT22 Start Signal

• 1. Yes.

• 2. Yes，the hts DHT22 Start Signal consist of two parts, (a) 1mS low signal, then immediately followed by (b) 28uS high. The 28uS High is the tricky part.

One solution is to use smbus block write. Iox MCP23017 can now block write a seemingly correct Start Signal, switch to input mode, and wait 7 milliSeconds to read 40 hts bits. The only bug is that Iox sends the correct signal at the wrong pin!

2. my point with this was, can you detect the small pulse. Is your bus speed fast enough? And your software routine?

Way you are waiting, when if read the datasheet the DTH22 will give direct the data after the start pulse. And is you start pulse correct, because I thought it should look like this. (the line is the DTH22, and the normal is the MCP:

----\____/\__.
(inactieve high, like your I2C bus)

By the way; does the MCP* work for 100% if you tell him to do something? Does you oscilloscoop have a I2C decoder inside? Than you could check easily if the data is correctly transmitter between the two devices.

[tlfong01]

1. I think the pi only need to deliver the start signal. And the rest is done by the sensor ...
2. ... its only 28uS high. And you need also get that one.

MCP23017 sending DHT22 Start Signal
One solution is to use smbus block write. Iox MCP23017 can now block write a seemingly correct Start Signal, switch to input mode, and wait 7 milliSeconds to read 40 hts bits. The only bug is that Iox sends the correct signal at the wrong pin!

Stall MCP23017 + DHT22 project , Start HDP1080 project

So I got stuck in DHT22. I think I need to take a break to cool down my head. In the mean time, I am starting HDP1080.

You once suggested that using MCP23017 is not my as cheap as possible way, because I am wasting a lot of non cheap time trying out things. However, I think that going the hard way forces me to learn new things. Using googled GPIO compatible DHT22 drivers or easy to use newbie libraries should be many times more time efficient, but then I don't learn new ways of doing things.

Now I am playing with HDP1080. Again, I googled and found a couple of python examples which I can simply copy and paste and finish my project in 5 minutes.

However, I am trying new things which I never tried, like I2C reading a word rather than a byte which is the only way I used before. It took me a couple of hours to clarify the differences between smbus read a byte without specifying register, read a byte from register, read a word from register, read a block from register. After clarifying the confusing smbus commands, I am now more confident in using them.

Just now I spent two hours to debug my program only to read a HDP1080 register. I learned some new tricks and I think next time I do similar things it should take me less than 5 minutes.

[Brandon92]

You once suggested that using MCP23017 is not my as cheap as possible way, because I am wasting a lot of non cheap time trying out things. However, I think that going the hard way forces me to learn new things. Using googled GPIO compatible DHT22 drivers or easy to use newbie libraries should be many times more time efficient, but then I don't learn new ways of doing things.

My point was not that you should use a library or something like that. But us suggested once that you want to use two mcp to get the data from the DHT22. And that's not really ideal. And if its not theoretic possible to communicate with the pi <-> mcp <-> DHT22, than you are gone wast some time. However, you are now learning how to use the mcp at is best and the I2C protocol / hardware. And that could be good information later on this project.

[tlfong01]

Start HDP1080 project
It took me a couple of hours to clarify the differences between smbus commands, ...
Just now I spent two hours to debug my program only to read a HDP1080 register. I learned some new tricks and I think next time I do similar things it should take me less than 5 minutes.

HDP1080 Humidity and Temperature Sensor program completed

So I spent two more hours completing the program. The main function of reading temperature and humidity and the sample output is listed below. The other functions of reading Device ID, Manufacturer ID, and Serial ID are straightforward, so are not list here.

# *** Sample Output ***
Time = 2018-08-17 16:14
Temperature = 28.96 degrees Centigrade.
Humidity = 82.81 %.
Device Id = 0x1050
Manufacturer Id = 0x5449
Serial Id = 0x00 0x8d 0xe4 0x80

Code: Select all

# hts01.1115 tlfong01 2018aug17hkt1458

def readTemperatureAndHumidity():
    print('\n    >>>> Begin Read Temperature and Humidity <<<<<<<<<<<<\n')
    print('      Time        =', getTimeNowStr(), '\n')

    # *** Config Device ***
    writeDvNumRegOneByte(dvNum, 'Config', configByteDict['0'])

    # *** Trigger Temperature Measurement ***
    writeDvNumSlaveOneByte(dvNum, regAddrByteDict['Temperature'])
    pauseMilliSeconds('TenMilliSeconds')

    # *** Read Raw Temperature Data ***
    tempWord = readDvNumSlaveOneWord(dvNum)
    tempMsByte = tempWord & 0x00ff
    tempLsByte = tempWord >> 8
        
    cTemp1 = (((tempMsByte * 256) + tempLsByte) / 65536.0) * 165.0 - 40
    print('      Temperature =', '%.2f' % cTemp1, 'degrees Centigrade.\n')

    # *** Trigger Humidity Measurement ***
    writeDvNumSlaveOneByte(dvNum, regAddrByteDict['Humidity'])
    pauseMilliSeconds('TenMilliSeconds')

    # *** Read Raw Humidity Data ***
    humidWord = readDvNumSlaveOneWord(dvNum)
    humidMsByte = humidWord & 0x00ff
    humidLsByte = humidWord >> 8
    percentHumid = (((humidMsByte * 256) + humidLsByte) / 65536.0) * 100.0
    print('      Humidity    =', '%.2f' % percentHumid, '%.')    
    
    print('\n    >>>> End  Read Temperature and Humidity <<<<<<<<<<<<')
    return

# *** Sample Output ***
'''
*** HDC1080 Test Functions ***
    0   Print/Change Device Number
    1   Read Temperature and Humidity
    2   Read Device Id
    3   Read Manufacturer Id
    4   Read Serial Id
    t   Test Temp
    x   Exit

    Test Number  = 1  Your selection = ? 0

    Device Num         = 0
    Device Name        = Thomas
    Device address     = 0x40

    Test Number  = 2  Your selection = ? 1

    >>>> Begin Read Temperature and Humidity <<<<<<<<<<<<

      Time        = 2018-08-17 16:14 

      Temperature = 28.96 degrees Centigrade.

      Humidity    = 82.81 %.

    >>>> End  Read Temperature and Humidity <<<<<<<<<<<<

    Test Number  = 3  Your selection = ? 2

    Device Id = 0x1050

    Test Number  = 4  Your selection = ? 3

    Manufacturer Id = 0x5449

    Test Number  = 5  Your selection = ? 4

    Serial Id = 0x00 0x8d 0xe4 0x80

'''

[Brandon92]

Good to hear that you can read the data from the HDP1080.

But now the main question, will the HDP1080 replace the DHT22 in you project for now on?

[tlfong01]

Good to hear that you can read the data from the HDP1080.
But now the main question, will the HDP1080 replace the DHT22 in you project for now on?

Ah, I am only scratching the surfaces of the following things.

• 1. RTC DS3231 with temperature sensor

• 2. IOX MCP23017

• 3. THS DHT22 Humdidity and temperature sensor

• 4. THS HDP1080 Humidity and temperature sensor

My plan is to let RTC, together with IOX to time and schedule to measure all 3 types of temperature sensors, and 2 groups of humidity sensors. Of course more other types of sensors are actuators are coming.

As I have been boasting for a while, I want to time, schedule, alarm, sense and control at least 64 IoT group of things, including heaters, motors, pumps, fans, lights etc etc.

That is one main reason that I don't consider Rpi GPIO pins, because there are too few GPIO pins available.

Appendix - Why use complex MCP23017 and not simple Rpi GPIO

RE: RELAY MODULE KY-019 5V - Post by tlfong01 2018-Jun-08
https://www.raspberrypi.org/forums/view ... 5#p1325530
geoffr wrote: ↑ 2012-Sep-09 Sun 9:38 pm

... I agree - the approach I am taking is more complex, but it has greater longer-term expansion potential. Given how cheap the MCP23017 is, it is not a major thing adding another one. I ultimately also plan to expose the I2C bus via a header on my board, allowing me to just add a daughter board later. I may want to add some AD converters later on - and there are readily available chips with I2C interfaces to do this. That is the stage where all the extra work will pay off, ...

[Brandon92]

As I have been boasting for a while, I want to time, schedule, alarm, sense and control at least 64 IoT group of things, including heaters, motors, pumps, fans, lights etc etc.

Okay, that is a large amount of devices. So, you need to pay "a lot" of attention to you I2C bus. But you already know this.

So, you want to different type of humidity and temperature sensor?

[tlfong01]

1. Okay, that is a large amount of devices. So, you need to pay "a lot" of attention to you I2C bus. But you already know this.

2. So, you want to different type of humidity and temperature sensor?

LCD/LED Display and Manual Control Buttons for Sensors and Relays

1. Yes, I guess I have learnt 80% of I2C things I need to learn for near future projects. It is only these few weeks I learnt how to do smbus /readwrite a word (two bytes), and write a block (many bytes). Before that I was still an I2C newbie and only knew how to read/write single byte.

2. Well, there are perhaps at least 10 sensors I need to play with, including the following: atmosphere pressure, air quality related (smoke, CO2, pm2.5 etc etc), ambient light sensor, weight sensor (to check if my cat is over weight) etc

CJMCU Sensor Modules List
https://cjmcu.world.taobao.com/category ... 5%C1%D0#bd


I also need to add manual control, such as buttons and LED/LCD display for my sensor outputs.

MULTIPLE DS18B20 SENSORS ON 20X4 LCD - T-EGWZ34 » 2018-Aug-18
https://www.raspberrypi.org/forums/view ... 6#p1354499

[tlfong01]

LCD/LED Display and Manual Control Buttons for Sensors and Relays]
I also need to add manual control, such as buttons and LED/LCD display for my sensor outputs.

LCD/LED Display and Manual Control Buttons for Sensors and Relays]

I think I will first test using touch sensitive buttons to control 4 relay boards for heater, pump, lamp etc.

I have setup a Minimal, Complete, Verificable, NoProblem Example of hardware, as displayed. I am using a cheap，5 yuan, NE555 square wave generator to generate the signal to control a 12V relay, display the waveform and compare with human touch button. I read that touch button has no bouncing. I need to find if it is true.

Now I found the ground line is very noisy. I need to find if it is AC noise. Perhaps I can use my bench PSU to compare with the 2 wall warts power.

[tlfong01]

MCP23017 sending DHT22 Start Signal
One solution is to use smbus block write. Iox MCP23017 can now block write a seemingly correct Start Signal, switch to input mode, and wait 7 milliSeconds to read 40 hts bits. The only bug is that Iox sends the correct signal at the wrong pin!

2. my point with this was, can you detect the small pulse. Is your bus speed fast enough? And your software routine?
Way you are waiting, when if read the datasheet the DTH22 will give direct the data after the start pulse. And is you start pulse correct, because
I thought it should look like this. (the line is the DTH22, and the normal is the MCP:
----\____/\__.
(inactieve high, like your I2C bus)

MCP23017 sending DHT22 Start Signal

Well, your ugly little wave form matches the part PQRS in my beautiful wave form. I am repeating PQRS, PQRS, ... 100000 times so I can use my scope to display the wave form.

You might like to check out my block write function, and calculate the R (the block 4L4H, 4H4L), the short pulse, timing is OK.

Update 2018aug20hkt2221

There is a bug in my write-start-pulse function. Please don't waste time reading my program. I will show you a debugged version later. Sorry for the trouble.

[tlfong01]

One solution is to use smbus block write. Iox MCP23017 block writes a Start Signal, then immediately switches to input mode, and waits 7 milliSeconds to read 40 hts bits.

MCP23017 Block write DHT22 Start Signal

My old Send Start Signal function sends 3 blocks separately:

• 1. Long High (idle)

• 2. Long Low (part 1 of Start Signal, 1mS typical)

• 3. Very short pulse (part 2 of Start Signal, typical 30uS, max 200uS

There might be some jittering between the 3 block writes. Now I am trying to combine the three Long Low, Long High, Very Short High block writes into one Very Long Write. The details of the block write in as attached. I am not using block read, but detect MCP23017 GPIO pin changes.

Now let me do the arithmetic for the very short pulse.

• 1. I2C SMBus clock is 100KHz.

• 2. So each I2C Clk pulse is (1/100k * 1000k uS) = 10uS

• 3. Time to send one byte = 8 data bit clk pulse + 1 ack clk pulse = 9 clk pulse = 90uS

• 4. That means the shortest High signal is 90uS, less than the 200uS required.

[Brandon92]

• 1. I2C SMBus clock is 100KHz.

• 2. So each I2C Clk pulse is (1/100k * 1000k uS) = 10uS

• 3. Time to send one byte = 8 data bit clk pulse + 1 ack clk pulse = 9 clk pulse = 90uS

• 4. That means the shortest High signal is 90uS, less than the 200uS required.

Okay, and what is the time that the DTH22 will provide his data. (logic 1 and logic 0)?

[tlfong01]

• 1. I2C SMBus clock is 100KHz.

• 2. So each I2C Clk pulse is (1/100k * 1000k uS) = 10uS

• 3. Time to send one byte = 8 data bit clk pulse + 1 ack clk pulse = 9 clk pulse = 90uS

• 4. That means the shortest High signal is 90uS, less than the 200uS required.

Okay, and what is the time that the DTH22 will provide his data. (logic 1 and logic 0)?

MCP23017 talking to DHT22

Ah, not that long. MCP23017 pin change interrupt should be quick enough to handle that. But I have not done the arithmetic yet. I hate arithmetic.

[tlfong01]

MCP23017 sending DHT22 Start Signal
One solution is to use smbus block write. Iox MCP23017 can now block write a seemingly correct Start Signal, switch to input mode, and wait 7 milliSeconds to read 40 hts bits. The only bug is that Iox sends the correct signal at the wrong pin!

MCP23017 sending DHT22 Start Signal
Update 2018aug20hkt2221
There is a bug in my write-start-pulse function. Please don't waste time reading my program. I will show you a debugged version later. Sorry for the trouble.

The bug was caused by my carelessly handling of the inconsistency of NXP's smbus spec on and python smbus definition of block write command.

[tlfong01]

You once suggested that using MCP23017 is not my as cheap as possible way, because I am wasting a lot of non cheap time trying out things. However, I think that going the hard way forces me to learn new things. Using googled GPIO compatible DHT22 drivers or easy to use newbie libraries should be many times more time efficient, but then I don't learn new ways of doing things.

My point was not that you should use a library or something like that. But us suggested once that you want to use two mcp to get the data from the DHT22. And that's not really ideal. And if its not theoretic possible to communicate with the pi <-> mcp <-> DHT22, than you are gone wast some time.
However, you are now learning how to use the mcp at is best and the I2C protocol / hardware. And that could be good information later on this project.

Learning how to use MCP23017

Yes, I am learning new iox skills which should be useful for my project later on. I also google around to check out how mcp23017 newbies like me learn. One stockOverflow mcp230187 newbie post I found interesting is the following:

SMBus write_i2c_block_data() command - asked 6 months ago by SO user82776 2018Jan30, viewed 359 times, Answer = 0
https://stackoverflow.com/questions/485 ... ta-command

So I started a project on a microcontroler that uses I2C communication a month ago with no knowledge about anything but python.

I have to talk to a peristaltic pump that uses ASCII strings for communication. So my setup currently consists of a Raspberry Pi, the I2C bus, Arduino and the peristaltic pump. The Arduino is only used as a powersupply. I thought a good starting point would be just to try and turn the pumps LED on and off.

The code for LED on is "L,1" and for LED off is "L,0". (The "" indicates that whats inside it is the absolute code). [a link] https://www.atlas-scientific.com/_files ... asheet.pdf

By using smbus.SMBus in python I sent the data through the command through write_i2c_block_data. Documentation of smbus gives the following:

write_i2c_block_data(int addr,char cmd,long vals[])

however i dont understand what is meant with 'char cmd'.

I couldnt put a string command in there and it only worked when I put an integer in there.

Here is the code:

Code: Select all

import smbus
import time

bus = smbus.SMBus(1)

slave_address = 0x67
led_on = 'L,1'
led_off = 'L,0'

def string_to_charlist(a_string):
    stringlist = list(a_string)
    return stringlist

def string_to_intlist(a_string):
    lst = string_to_charlist(a_string)
    intlist = []
    for i in range(len(lst)):
        an_int = string_to_charlist(lst[i])
        intlist.append(an_int)
    return intlist

ledon_intlist = string_to_intlist(led_on)
ledoff_intlist = string_to_intlist(led_off)

# this will result in ledon_intlist = [76,44,49]
# this will result in ledon_int =list [76,44,48]

command1_on = ledon_intlist.pop(0)
command1_off = ledoff_intlist.pop(0)

for i in range(1):
    time.sleep(0.5)
    bus.write_i2c_block_data(slave_address, command1_on, ledon_intlist)
    time.sleep(0.5)
    bus.write_i2c_block_data(slave_address, command1_on, ledon_intlist)

After running this code through the raspberry Pi command prompt the pumps LED started blinking on the given time frame. Unfortunately it never stopped blinking and also didt show up when I searched for it using i2ctools command i2cdetect -y 1 I assume the pump's chip is in an infinite loop now.

My questions are:

1. How should one use the write_i2c_block_data() command and what argument does it take. Currently I figured that the 1st argument is the slave address, 2nd is the initial byte of the stream and the 3rd argument is the rest of the stream integer values to be sent.


2. What possibly could have gone wrong that the pump is stuck in an infinite loop and how do I fix it

Tags: python raspberry-pi3 i2c smbus

Share/Improve this question

Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

[/i][/color]

Appendix

Embedded Dosing Pump - Atlas Scientific Environmental Robotics V1.8 2018jan8
https://www.atlas-scientific.com/_files ... asheet.pdf

[tlfong01]

• 1. I2C SMBus clock is 100KHz.

• 2. So each I2C Clk pulse is (1/100k * 1000k uS) = 10uS

• 3. Time to send one byte = 8 data bit clk pulse + 1 ack clk pulse = 9 clk pulse = 90uS

• 4. That means the shortest High signal is 90uS, less than the 200uS required.

Okay, and what is the time that the DTH22 will provide his data. (logic 1 and logic 0)?

MCP23017 talking to DHT22

Ah, not that long. MCP23017 pin change interrupt should be quick enough to handle that. But I have not done the arithmetic yet. I hate arithmetic.

Finally a 200uS pulse!

I tried more block write experiments and finally got a 200uS high pulse. I expect 90uS. Don't know why it becomes 200uS. Perhaps I missed some extra overhead.

def testDht22StartSignal():
# *** Repeat Idle 10mS, Low 2mS, Short Pulse, Low 7ms ***
for count in range(100000):
# *** Idle High - High for TenMilliSeconds ***
# *** Start Signal Part One - Low for Two MilliSeconds ***
# *** Start Signal Part Two - 5 cycles Low, 1 cycle High, 5 cycles Low
# *** Seven MilliSeconds Time to read data from DHT22 ***
# *** Will Change GPIO to input mode ***
return

Code: Select all

# iox01.1120 tlfong01 2018aug21hkt1532

def testDht22StartSignal():

    # *** Block to write = byte count = 12, 5L, 1H, 5L ***
    fiveLowOneHighFiveLow = \
        [
            'Twelve', \
            'AllBitsLow',  'AllBitsLow', 'AllBitsLow', 'AllBitsLow', 'AllBitsLow', \
            'AllBitsHigh', \
            'AllBitsHigh',  'AllBitsLow', 'AllBitsLow', 'AllBitsLow', 'AllBitsLow', \
        ]

    # *** Repeat Idle 10mS, Low 2mS, Short Pulse, Low 7ms (will change to input mode) ***
    for count in range(100000):

        # *** Idle High - High for TenMilliSeconds ***
        writeHoldGpioOneByte(dvNum = 0, ioDirName = 'IODIRA', gpioName = 'GPIOA', \
                             writeByteName = 'AllBitsHigh', \
                             holdMilliSeconds = 'TenMilliSeconds')

        # *** Start Signal Part One - Low for Two MilliSeconds ***
        writeHoldGpioOneByte(dvNum = 0, ioDirName = 'IODIRA', gpioName = 'GPIOA', \
                             writeByteName = 'AllBitsLow', \
                             holdMilliSeconds = 'TwoMilliSeconds')

        # *** Start Signal Part Two - 5 cycles Low, 1 cycle High, 5 cycles Low  
        writeGpioOneBlock(dvNum = 0, gpioName = 'GPIOA',
                          writeByteNameList = fiveLowOneHighFiveLow)

        # *** Seven MilliSeconds Time to read data from DHT22 ***
        # *** Will Change GPIO to input mode                  ***
        writeHoldGpioOneByte(dvNum = 0, ioDirName = 'IODIRA', gpioName = 'GPIOA', \
                             writeByteName = 'AllBitsLow', \
                             holdMilliSeconds = 'SevenMilliSeconds')    
    return

[tlfong01]

Okay, and what is the time that the DTH22 will provide his data. ...

Winner Winner Chicken Dinner!

I did the following things:

• 1. Added the change-gpio-to-input-mode statement after the 200uS long pulse

• 2. Connected DHT22 signal pin to MCP23017 GPIO A pin 4

• 3. Ran the code. I saw DHT22 outputs something, but then program halted, no looping.

• 4. I guess DHT22 needs to take a rest of 2 seconds, before making another measurement. So I changed the 100000 times loop to 1, and set scope from auto to single (I forgot what that means, perhaps single trigger, capture and store, or something like that.)

• 5. Then I ran the program, and scope single trigger gave a beautiful picture, which I have been hoping to see for some weeks, ...

Code: Select all

def testTemp():
    print('    >>>> Begin Test Temp Function <<<<<<<<<<<<')
    # *** Block to write = byte count = 12, 5L, 1H, 5L ***
    fiveLowOneHighFiveLow = \
        [
            'Twelve', \
            'AllBitsLow',  'AllBitsLow', 'AllBitsLow', 'AllBitsLow', 'AllBitsLow', \
            'AllBitsHigh', \
            'AllBitsHigh',  'AllBitsLow', 'AllBitsLow', 'AllBitsLow', 'AllBitsLow', \
        ]

    # *** Repeat Idle 10mS, Low 2mS, Short Pulse, Low 7ms (will change to input mode) ***
    for count in range(1):

        # *** Idle High - High for TenMilliSeconds ***
        writeHoldGpioOneByte(dvNum = 0, ioDirName = 'IODIRA', gpioName = 'GPIOA', \
                             writeByteName = 'AllBitsHigh', \
                             holdMilliSeconds = 'TenMilliSeconds')

        # *** Start Signal Part One - Low for Two MilliSeconds ***
        writeHoldGpioOneByte(dvNum = 0, ioDirName = 'IODIRA', gpioName = 'GPIOA', \
                             writeByteName = 'AllBitsLow', \
                             holdMilliSeconds = 'TwoMilliSeconds')

        # *** Start Signal Part Two - 5 cycles Low, 1 cycle High, 5 cycles Low  
        writeGpioOneBlock(dvNum = 0, gpioName = 'GPIOA',
                          writeByteNameList = fiveLowOneHighFiveLow)
     
        # *** Set GPIO A All Pins Input, wait 7 mS to collect DHT22 data ***
        setIoDirRegAllPinsInput('IODIRA')
        pauseMilliSeconds('SevenMilliSeconds')     
  
    print('    >>>> End   Test Temp Function <<<<<<<<<<<<')
    return

Notes:

• 1. When running the program with the DHT22 connected, the short pulse has a little dip or hollow at the top. I guess it is because DHT22 is loading down the MCP23107 GPIO pin.

• 2. DHT22 outputs 3V3 signal. I guess I need to shift it up for the 5V
  MCP23017.

[Brandon92]

Does the left side of you signal, before the puls, also need to be high, before you talk to the DHT22


However, congratulations that you can control the MCP* and that you will receive data from the DHT22. No the next tast is if you can read all the data from the sensor -> mcp -> pi. I think you might have a issue with the timing here (bus to slow).

My questions are:

1. How should one use the write_i2c_block_data() command and what argument does it take. Currently I figured that the 1st argument is the slave address, 2nd is the initial byte of the stream and the 3rd argument is the rest of the stream integer values to be sent.


2. What possibly could have gone wrong that the pump is stuck in an infinite loop and how do I fix it

Are this you quesitons, I think you already know the answer by now.

[tlfong01]

1. Okay, that is a large amount of devices ...
2. So, you want to different type of humidity and temperature sensor?

2. Well, there are perhaps at least 10 sensors I need to play with, including the following: atmosphere pressure, air quality related (smoke, CO2, pm2.5 etc etc), ambient light sensor, weight sensor (to check if my cat is over weight) etc

Blood Pressure and Brain Wave Sensor

Actually my long term main interest is sensing my own body, such as blood pressure, brain waves etc.

This morning I read the following Spectrum articles and found them very interesting.

IEEE SPECTRUM JOIN IEEE 21 August 2018
http://view.media.ieee.org/?qs=2224a424 ... a01621cdf7

Glasses Monitor Blood Pressure - By Jeremy Hsu

BMI control of a third arm for multitasking
https://www.youtube.com/watch?v=h2SDqdSTvA8
https://www.digitaltrends.com/cool-tech ... third-arm/

[tlfong01]

My questions are:
What possibly could have gone wrong ... and how do I fix it.

Are this you quesitons, I think you already know the answer by now.

Testing I2C Extender

Ah, I still think I am scratching the surface, especially on I2C and MCP23017. Earlier I said that long I2C wires should have no problem. But this afternoon I found the I2C smbus transmission error message keeps coming back, when I am looping for some time. I suspect looping causes some mysterious things happening. So I am thinking of adding a I2C extender to make sure it is not I2C long wires that causes the trouble.

I am also wiring a couple of GPIO pins for testing input, output, and interrupt.

I will be using

GPIO pins 17, 18, 27, 22 for I2C demux, and

GPIO pins 26, 12, 16, 20 for interrupts.

[tlfong01]

So I am thinking of adding a I2C extender to make sure it is not I2C long wires that causes the trouble.
I am also wiring a couple of GPIO pins for testing input, output, and interrupt.
I will be using
GPIO pins 17, 18, 27, 22 for I2C demux, and
GPIO pins 26, 12, 16, 20 for interrupts.

Testing I2C Extender

Now I have wired the 4 I2C demux wires, with their own ground, and 4 interrupt wires, also with their own ground wire. (The I2C wires SCL, SDA, and dedicated ground wire, are all about 30cm to the signal routing board.

[Brandon92]

This topic might be interesting for you

Don't use an smbus library when you want an i2c one. They may have a lot in common, but they are not the same (smbus is really a subset of i2c).

[tlfong01]

This topic might be interesting for you

Don't use an smbus library when you want an i2c one. They may have a lot in common, but they are not the same (smbus is really a subset of i2c).

Dallas DS18B20 1-Wire Temperature Sensor

Ah, the discussion explains my difficulty, as summarized below.

• 1. The OP has a problem using the following python smbus block read command:
  
  long[] read_i2c_block_data(int addr,char cmd)

• 2. One guy suggests the following C commands:
  
  read_i2c_block_data(addr, 0, 4)
  
  block = bus.read_i2c_block_data(sens_addr, 4) #read 4 bytes
  
  But the OP is using python import smbus. So might not be very helpful.

• 3. The pigpio library developer suggests to use his pigpio library python equivalent command:
  
  i2c_read_i2c_block_data(handle, reg, count)
  
  This looks OK, but you need to use the pigpio, which needs to system start as a daemon. But I am a newbie using the simple gpio.pi. I don't know linux enough to handle any seemingly scary daemon.

• 3. A Rpi software engineer suggests not to use the smbus library. But he does not mention any alternative.

• 4. The OP's python program imports tkinter. I don't know anything about tkiner. So not sure if that causes any trouble.

• 5. OP uses a sensor with I2C address 0x28. I think the sensor is:
  
  Dallas DS18B20 Programmable Resolution 1-Wire Digital Thermometer
  https://cdn.sparkfun.com/datasheets/Sen ... S18B20.pdf
  
  This sensor has a one wire system which might not be compatible with smbus. But I know nothing about this 1 wire system, ...

The above are just some selfie brainstorming comments. No reply necessary.