Relay Module KY-019 5V

[tlfong01]

So I have swapped the stupid RpiZW by the smart Rpi3B+, which booted without any problem. I ran the old python program to read the RTC temperature and everything looked good.
Rpi3B+ copies 16G speed 10 to 16GB speed 10 only takes 12 minutes!

I2C frequency setting and signal wave form display

I also wrote a short function to repeatedly send the character 0x5a to RTC day register, to check if the I2C signal is good or not.

I read that Rpi I2C speed can not be set below 100kHz. I tried to set the speed to 40kHz, 50kHz, 100kHz, and 400kHz, but Rpi I2C always runs at 100kHz.

I displayed the I2C signals (after level shifting by TSX0104E, and buffered by HC04) and found them more or less OK.

[tlfong01]

I2C frequency setting and signal wave form display
I also wrote a short function to repeatedly send the character 0x5a to RTC day register, to check if the I2C signal is good or not.

Now I have tested 4 RTC functions:

• 1. Write a byte to RTC Day register, read back, and print it.

• 2. Repeatedly write a byte to RTC Day register (for scope display).

• 3. Read RTC temperature once

• 4. Read RTC temperature 4 times.

I have also written a menu function for user to select which test function to execute. This makes the tests newbie friendly. The newbie just runs the program, and selects a test from the menu.

*** RTC DS3231 Test Functions ***
0 Write and read back Day Register
1 Repeat write 0x5a to Rtc Day Register
2 Read and print temperature once
3 Read and print temperature four times
x Exit
Your selection = ?

The complete program is long and boring to read. So I just list the sample output of user selection and results below.

Code: Select all

# *** Sample Output Begin ******************************************************
'''
*** RTC DS3231 Test Functions ***

0 Write and read back Day Register
1 Repeat write 0x5a to Rtc Day Register
2 Read and print temperature onece
3 Read and print temperature four times
x Exit

Your selection = ?0

+++ writeReadPrintRtcDayRegisterTwoTimes Begin +++

Old Byte = 0x2
New Byte = 0x4
Old Byte = 0x4
New Byte = 0x6

+++ writeReadPrintRtcDayRegisterTwoTimes End   +++


*** RTC DS3231 Test Functions ***

0 Write and read back Day Register
1 Repeat write 0x5a to Rtc Day Register
2 Read and print temperature onece
3 Read and print temperature four times
x Exit

Your selection = ?2
Temperature = 28.0 degrees C

*** RTC DS3231 Test Functions ***

0 Write and read back Day Register
1 Repeat write 0x5a to Rtc Day Register
2 Read and print temperature onece
3 Read and print temperature four times
x Exit

Your selection = ?3

+++ repeatReadAndPrintRtcTemperatureFourTimesPauseOneSecond Begin +++


Time        = 2018-08-04 22:28
Temperature = 28.0 degrees C

Time        = 2018-08-04 22:28
Temperature = 28.0 degrees C

Time        = 2018-08-04 22:28
Temperature = 28.0 degrees C

Time        = 2018-08-04 22:28
Temperature = 28.0 degrees C

+++ repeatReadAndPrintRtcTemperatureFourTimesPauseOneSecond End   +++


*** RTC DS3231 Test Functions ***

0 Write and read back Day Register
1 Repeat write 0x5a to Rtc Day Register
2 Read and print temperature onece
3 Read and print temperature four times
x Exit

Your selection = ?x
Exit
Test End
>>> 
'''

[tlfong01]

A new toy also arrived.

I checked out the new toys, the digital mains meters and found them working,

But I have been too busy reading the manuals. Anyway, I set up both digital mains meters, one for monitoring the heater, another for electric fan.

[tlfong01]

But I have been too busy reading the manuals. Anyway, I set up both digital mains meters, one for monitoring the heater, another for electric fan.

I am coming back to the Temperature and Humidity Sensor DHT22.

My plan is to use 4 MCP23017 output signals to control 4 DHT22s.

[tlfong01]

With a DS3231 you're much better off using the built-in linux kernel driver which is activated by adding a simple line to /boot/config.txt

Code: Select all

dtoverlay=i2c-rtc,ds3231

Doing your own thing with a python program is a waste of time (excuse the pun).

Hardware clock, software clock, and fake clock reading notes

Well, for linux newbies, everything is hard. It took me hours to partially understand the term dt (Device Tree). And I still don't understand thoroughly why "overlay" (over write?)

And for newbies, fiddling with low level drivers installation using sudo nano is dangerous. Actually, everything involved sudo is dangerous, I mean, for newbies.

Anyway, to appreciate the difficulty of installing the built in RTC DS3231 linux kernal driver, I am reading the Arch linux article on how to use the driver commands, and made a summary.

By the way, even the term 'kernal' scares away Rpi newbies, who have already been hopelessly spoiled by the very sweet Windows plug and play (auto detect, auto install hardware drivers, no questions asked, or at most some click click click, and job is done!).

Hardware clock, software clock, fake clock - ArchLinux last edited 2018aug03
https://wiki.archlinux.org/index.php/Time

Standard behavior of most operating systems is:

• 1. Set the system clock from the hardware clock on boot.

• 2. Keep accurate time of the system clock, see #Time synchronization.

• 3. Set the hardware clock from the system clock on shutdown.

Hardware clock commands

Read hardware clock

# hwclock --show

Set hardware clock from system clock

# hwclock --systohc

Software clock commands (System clock)

The initial value of the system clock is calculated from the hardware clock, dependent on the contents of /etc/adjtime. After boot-up has completed, the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.

Read software clock (and hardware clock?)

$ timedatectl

Set system clock directly (manual, by hand!):

# timedatectl set-time "yyyy-MM-dd hh:mm:ss"

Hardware clock time standard (UTC etc)

To query and hardware clock time standard, eg UTC (Arch command)

$ timedatectl | grep local
RTC in local TZ: no

To change the hardware clock time standard to localtime, use:
# timedatectl set-local-rtc 1

To revert to the hardware clock being in UTC, type:
# timedatectl set-local-rtc 0

UTC commands in Ubuntu
...

Time skew

Every clock has a value that differs from real time (the best representation of which being International Atomic Time); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'.

Time synchronization

The Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks.

The following are implementations of such protocol:

Network Time Protocol daemon — The reference implementation of the protocol, especially recommended to be used on time servers.
http://www.ntp.org/ || ntp

sntp — An SNTP client that comes with NTPd. It supersedes ntpdate and is recommended in non-server environments.
http://www.ntp.org/ || ntp

systemd-timesyncd — A simple SNTP daemon that only implements a client side, focusing only on querying time from one remote server.
https://www.freedesktop.org/wiki/Software/systemd/ || systemd

OpenNTPD — Part of the OpenBSD project and implements both a client and a server.
http://www.openntpd.org/ || openntpd

Chrony — A client and server that is roaming friendly and designed specifically for systems that are not online all the time.
https://chrony.tuxfamily.org/ || chrony

ntpclient — A simple command-line NTP client.
http://doolittle.icarus.com/ntpclient/ || ntpclientAUR

Fake Hardware Clock

alarm-fake-hwclock designed especially for system without battery backed up RTC, it includes a systemd service which on shutdown saves the current time and on startup restores the saved time, thus avoiding strange time travel errors.

Install fake-hwclock-gitAUR, start and enable the service
fake-hwclock.service.

.END

[tlfong01]

With a DS3231 you're much better off using the built-in linux kernel driver which is activated by adding a simple line to /boot/config.txt

Code: Select all

dtoverlay=i2c-rtc,ds3231

Doing your own thing with a python program is a waste of time (excuse the pun).

Well, I have read the documents about the built-in kernel RTC DS3231 driver, and now know how to activate the driver, and how to use the hwclock commands.

Linux hwclock - query and set the hardware clock (RTC)
https://linux.die.net/man/8/hwclock

But I am using Python to do things including the following:

• 1. Get current time from NTP time server using python's datetime module.

• 2. Sync to hardware clock RTC DS3231 (I am not for now, using the linux system clock, or linux software clock.)

• 3. Set DS3231 alarms to schedule events by date, every morning 8am etc.

• 4. Program DS3231 signal generators (enable/disable 32kHz and 1kHz to 8kHz square wave etc.

• 5. Read DS3231 built in temperature sensor

hwclock cannot do the above things. So you need to use python, or C/C++ to help. In short, python is a one stop shop, built in kernel driver or hwclock is not needed.

[tlfong01]

Hardware clock, software clock, and fake clock reading notes
By the way, even the term 'kernal' scares away Rpi newbies, who have already been hopelessly spoiled by the very sweet Windows plug and play (auto detect, auto install hardware drivers, no questions asked, or at most some click click click, and job is done!).

So I am using python as a one stop shop to do things that can be done by the kernel driver and hwclock commands, and many more.

Selfie program walk-through and brain storming

I have more or less debugged all the RTC basic functions like reading and writing a register, and reading temperature etc. The program is getting long, with many little functions about 300 lines.

I was thinking of moving on to the remaining RTC functions, like syncing time with NTP time server, setting alarms for scheduling etc. To keep pythong modules smaller, I decided to rename the old rtc01.py python program module to i2cutil.py

i2cutil.py has all the verified test functions, with the basic functions like register reading and writing etc, that can be called from other modules than import this i2cutil01 module.

It took me a couple of hours to tidy up things, and refactored an old function of reading network time and sync etc. This new function is called initRtc and a sample output is listed below.

Code: Select all

''' Sample output

*** RTC DS3231 Test Function List 1 ***

0   Write and read Day Register 0x04 0x06     
1   Write and read Day Register 0x05, 0x07    
2   Read temperature                          
3   Init RTC DS3231                           
4   Write and read back Day Register (i2cuitl)
5   Read temperature                 (i2cutil)
x   Exit

Your selection = ? 3

        Begin configClock(), ...
        End   configClock().
        Date Time now long            = 2018-08-06 22:41:54.037150
        Date Time now short           = 2018-08-06 22:41
        Date today                    = 2018-08-06
        Time now long                 = 22:41:54.037150
        Time now short                = 22:41:54
        Year str                      = 2018
        Year num                      = 2018
        Month num                     = 8
        Date num                      = 6
        Hour num                      = 22
        Minute num                    = 41
        Second num                    = 54

        Begin printDateTime(), ...
          Time      =  2018 Aug 6 22:41
        End   printDateTime(), ...

'''

[tlfong01]

Selfie program walk-through and brain storming
I was thinking of moving on to the remaining RTC functions, like syncing time with NTP time server, setting alarms for scheduling etc. To keep pythong modules smaller, I decided to rename the old rtc01.py python program module to i2cutil.py
i2cutil.py has all the verified test functions, with the basic functions like register reading and writing etc, that can be called from other modules than import this i2cutil01 module.

RTC DS3231 Real Time Clock Alarm Functions Design Notes V0.1

Now I am moving on alarms.

I am trying to upload images inline, ie, after a text line. But I still find a problem. Everytime I try to upload 2 or 3 images, I could see them in preview. But next preveiw, only one image left. Will try again later.

[tlfong01]

RTC DS3231 Real Time Clock Alarm Functions Design Notes V0.1
I am trying to upload images inline, ie, after a text line. But I still find a problem. Everytime I try to upload 2 or 3 images, I could see them in preview. But next preveiw, only one image left. Will try again later.

Image 2 of 3

[tlfong01]

RTC DS3231 Real Time Clock Alarm Functions Design Notes V0.1
I am trying to upload images inline, ie, after a text line. But I still find a problem. Everytime I try to upload 2 or 3 images, I could see them in preview. But next preveiw, only one image left. Will try again later.

Image 3 of 3

[tlfong01]

RTC DS3231 Real Time Clock Alarm Functions Design Notes V0.1

It took me more than 3 hours to write one function to basic interrupt operation. The interrupt test works something like this.

• 1. Config RTC, with interrupt output enabled.

• 2. Get datetime from NTP time server, sync RTC, print datetime

• 3. Set alarm once per second

• 4. Sleep 4 seconds

• 5. Clear interrupt flag.

This test begin with alarm interrupt set, LED on, then sleep 4 seconds, then interrupt cleared, then within 1 sec, alarm interrupt is set again.

Code: Select all

def testInterruptOutput():
    configRtcInterruptOutput()
    dateTimeNowDict = getDateTimeNowFromInternetTimeServer()
    updateRtcDateTimeRegisters(dateTimeNowDict)
    printDateTimeNow()
    setAlarmOncePerSecond()
    time.sleep(4)
    clearAlarmInterruptFlag1And2()
    return

Now I have two python modules i2cutil01.py, and rtc01.py.
i2cutil01 contains the basic i2c and also rtc basic tests, with the following function list:

Code: Select all

functionList1 = \
    ['I2C Utility Test Functions',
        [
            ['0',  ['Write and read back Day Register                 ',  writeReadPrintRtcDayRegisterTwoTimes]],
            ['1',  ['Repeat write 0x5a to Rtc Day Register (for scope)',  repeatWriteRtcDayRegister0x5aPause10Ms]],
            ['2',  ['Read and print temperature once                  ',  readAndPrintRtcTemperatureOneTime]],
            ['3',  ['Read and print temperature four times            ',  repeatReadAndPrintRtcTemperatureFourTimesPauseOneSecond]],
            ['x',  ['Exit                                             ',  exit]],
        ]
    ]

rtc01.py has the following test functions list:

Code: Select all

funList1 = \
    ['RTC DS3231 Test Function List 1',
        [
            ['0',  ['Write read Day register                   ',  writeReadDayRegister]],
            ['1',  ['Read temperature                          ',  readTemperature]],
            ['2',  ['Test Square Wave output                   ',  testSquareWaveOutput]],
            ['3',  ['Test Interrupt output                     ',  testInterruptOutput]],
            ['4',  ['I2cUtil Write read Day register           ',  i2cutil.writeReadPrintRtcDayRegisterTwoTimes]],
            ['5',  ['I2cUtil Read temperature                  ',  i2cutil.readAndPrintRtcTemperatureOneTime]],
            ['6',  ['I2cutil test                              ',  i2cutil.test]],
            ['x',  ['I2cutil exit                              ',  i2cutil.exit]],
        ]
    ]

i2cutil01.py is about 450 lines long, rtc01 350 lines. It is getting complicated. My very first plan is to start with a simple Minimal, Complete, Verifible, NoProblem Example (MCVNE). It is OK for a very simple task, such as writing to a register, read back, and print it. But it is getting very messy to write a MCVNE even for the simple RTC functions I am doing now, reading temperature, time, setting interrupts.

And I am only scratching the surface. My python modules are still buggy, and I am refactoring them every time I add something.

So I gave up the MCVNE project, because the programs start getting very complicated, it is unlikely any newbie can read and understand. I myself spent over 10 hours studying the datasheet, and 20 hours writing the functions, and I think after 6 months, I would have difficulty understand the details.

MCP23017 IO Expander (IOX) controlling DHT22 Temperature and Humidity Sensor (THS)
Now I move on to IOX controlling THS.

[tlfong01]

MCP23017 IO Expander (IOX) controlling DHT22 Temperature and Humidity Sensor (THS)
Now I move on to IOX controlling THS.

I am reading the DHT22 manual.
https://akizukidenshi.com/download/ds/aosong/AM2302.pdf

DHT22's temperature is typical +- 0.5 degree C (max +- 1 degree C) and humidity +- 2% accurate, better, but not that much better than DS3231's 3 degrees accuracy.

[tlfong01]

DHT22's temperature is typical +- 0.5 degree C (max +- 1 degree C) and humidity +- 2% accurate, better, but not that much better than DS3231's 3 degrees accuracy.

Sampling time = 2 seconds.

[tlfong01]

DHT22's temperature is typical +- 0.5 degree C (max +- 1 degree C) and humidity +- 2% accurate, better, but not that much better than DS3231's 3 degrees accuracy.

Sampling time = 2 seconds.

Now the timing diagram. I need to tell MCP23017 to send the following pulse -

Send
Idle = High
Start = Low 1ms, High 20 uS

Receive
Start = High 80us, Low = 80uS
Data
Bit 1 = 50 us Low, 26 uS High
Bit 0 = 50 uS Low, 70 uS High

[Brandon92]

So I have swapped the stupid RpiZW by the smart Rpi3B+, which booted without any problem. I ran the old python program to read the RTC temperature and everything looked good.
Rpi3B+ copies 16G speed 10 to 16GB speed 10 only takes 12 minutes!

I read that Rpi I2C speed can not be set below 100kHz. I tried to set the speed to 40kHz, 50kHz, 100kHz, and 400kHz, but Rpi I2C always runs at 100kHz.
I displayed the I2C signals (after level shifting by TSX0104E, and buffered by HC04) and found them more or less OK.

Okay, so you your I2C speed is 100kHz. (By the way, if you connect the other ground from your probe. The signals on your oscilloscope are better).

And you want to send a high puls of 20uS.So, the T of one clock cycle is 1/100k = 10uS. And I (believe) that if you want to control the output of the MCP23017 you need to send at least 3 data packages. (device opcode, register address and the data). So, you need to send (at least) 3*8bits. So, your minimum time for transmit data to the device is about: 3*8*10uS = 240uS. This means that your I2C bus is to slow for this.

[Brandon92]

So I have swapped the stupid RpiZW by the smart Rpi3B+, which booted without any problem. I ran the old python program to read the RTC temperature and everything looked good.
Rpi3B+ copies 16G speed 10 to 16GB speed 10 only takes 12 minutes!

I read that Rpi I2C speed can not be set below 100kHz. I tried to set the speed to 40kHz, 50kHz, 100kHz, and 400kHz, but Rpi I2C always runs at 100kHz.
I displayed the I2C signals (after level shifting by TSX0104E, and buffered by HC04) and found them more or less OK.

Okay, so you your I2C speed is 100kHz. (By the way, if you connect the other ground from your probe. The signals on your oscilloscope are better).

And you want to send a high puls of 20uS.So, the T of one clock cycle is 1/100k = 10uS. And I (believe) that if you want to control the output of the MCP23017 you need to send at least 3 data packages. (device opcode, register address and the data). So, you need to send (at least) 3*8bits. So, your minimum time for transmit data to the device is about: 3*8*10uS = 240uS. This means that your I2C bus is to slow for this.

[tlfong01]

I displayed the I2C signals (after level shifting by TSX0104E, and buffered by HC04) and found them more or less OK.

By the way, if you connect the other ground from your probe. The signals on your oscilloscope are better.

I don't understand. I connected Ch1 ground clip to ground, and Ch2 ground clip floating. I did not bother to ground Ch2, because I know Ch1 and Ch2 ground clips are, inside the scope box, connected together. (My Ch1 probe ground clip is connected to HC04 pin 7 ground)

Anyway, I needed to tidy up my wiring for coming MCP23017 signal testing. So this time I also tested connecting Ch2 ground clip to ground. But I did not notice any difference in the scope waveforms (Ch2 waveform still has thin lines hanging from the ceiling of the high part of the waveform).

Rpi3B+ 5V I2c Wavefrom
https://i.imgur.com/zEoQGR5.jpg

Do you have any theory to support your hypothesis?

[tlfong01]

Okay, so you your I2C speed is 100kHz.
And you want to send a high puls of 20uS.So, the T of one clock cycle is 1/100k = 10uS. And I (believe) that if you want to control the output of the MCP23017 you need to send at least 3 data packages. (device opcode, register address and the data). So, you need to send (at least) 3*8bits. So, your minimum time for transmit data to the device is about: 3*8*10uS = 240uS. This means that your I2C bus is to slow for this.

My goodness, your speak too fast for my slow ears. Let me do some selfie arithmetic paced to my low speed brain.

First I take a look of the DHT22 spec.

DHT22 Timing
https://i.imgur.com/dy13BFm.jpg

To make my thinking loudly quicker, from now on I shall use the following short names.

• 1. iox = MCP23017 16-Bit I/O Expander with Serial Interface

• 2. hts = DHT22 Digital-output relative humidity & temperature sensor/module

Secondly, I look at the I2C timing.

I2C Timing
https://i.imgur.com/zEoQGR5.jpg

The DHT spec seems to say the following.

iox side:

• 1. iox sends a start signal of 50uS low from idle high.

• 2. iox then has a 20uS time period allowed to release the I2C bus.

• 3. iox must change its Output mode to Input mode, hopefully, before the 20uS time period expires.

hts side:

• 1. hts waits until the iox guy sends the idle High to 50uS Low start signal.

• 2. hts, as soon as the 20uS allowed time period expires, knows the I2C bus is (hopefully) released, sends a response signal of 80uS Low, followed by 80uS High.

• 3. hts then sends 5 groups of data bit signals. Each group contains 8 data bits signals. Each data bit signal is either a '0', or a '1' signal. A '0' data bit signal is 50uS Low, followed by 26uS high, while a '1' data bit signal is 50uS low, followed by 70uS high. In other words, '0' bit signal is (50 + 26) = 76uS long, and '1' big signal is (50 + 70) = 120uS long.

This is a bit complicated. I need to take a break.

[tlfong01]

Okay, so you your I2C speed is 100kHz.
1. And you want to send a high puls of 20uS.So, the T of one clock cycle is 1/100k = 10uS. And I (believe) that if you want to control the output of the MCP23017 you need to send at least 3 data packages.
2. So, you need to send (at least) 3*8bits. So, your minimum time for transmit data to the device is about: 3*8*10uS = 240uS.
3. This means that your I2C bus is to slow for this.

I agree with your first 2 points above, but I need to think carefully with your conslusion in point 3.

• 1. I agree that to set a iox (mcp23017) gpio pin from Low to High, I need to send 3 bytes through the I2C bus to tell iox to do so.

• 2. I agree that to send 3 bytes, I need 240uS, which is too long for the allowed time period of 26uS for iox to release the bus.

• 3. But there is some allowance for the iox bus release time period of 26/30uS. Actually the max allowed release time is 200uS. See attached below.

Yes, even the max allowable 200uS is still over the min iox release time of 240uS.

Now let us have some brain storming.

• (1) If hts couldn't wait longer than 200uS, then I seem to be hopeless, unless I do hardware get around, such as automatically generating the 26/30/200uS high by using hard ware logic gates etc. But that is stupid and might damage my reputation .

• (2) But then I can consider forgetting the stupid I2C thing altogether, and switch to SPI based MCP23x17, that is MCP23S17. Last year I tried MCP23S08 and MCP23S17 and found them OK. I only chose I2C and not SPI because I read that I2C wires can be much longer, perhaps 200m, than SPI, perhaps 10m.

Any ideas?

[tlfong01]

Now let us have some brain storming.

• (1) If hts couldn't wait longer than 200uS, then I seem to be hopeless, unless I do hardware get around, such as automatically generating the 26/30/200uS high by using hard ware logic gates etc. But that is stupid and might damage my reputation .

• (2) But then I can consider forgetting the stupid I2C thing altogether, and switch to SPI based MCP23x17, that is MCP23S17. Last year I tried MCP23S08 and MCP23S17 and found them OK. I only chose I2C and not SPI because I read that I2C wires can be much longer, perhaps 200m, than SPI, perhaps 10m.

Any ideas?

Just now I searched my junk projects box and found 6 mcp23Sxx sister boards, collecting dust, anxiously waiting to kick out their stupid mcp230xx brothers.

[Brandon92]

I don't understand. I connected Ch1 ground clip to ground, and Ch2 ground clip floating. I did not bother to ground Ch2, because I know Ch1 and Ch2 ground clips are, inside the scope box, connected together. (My Ch1 probe ground clip is connected to HC04 pin 7 ground)

The short story is: When you let one ground clip not connected to the ground of you system. It can/will act as some kind of antenna and could pick up some noise. And that noise is superimposed on you signal that you want to measure. And if there is in system, or around the system, a decent amount of noise it will show up. And it will look like you signal is not good and you could go down the rabbit hole. To find out why it is. And yes, if have been there too

My goodness, your speak too fast for my slow ears. Let me do some selfie arithmetic paced to my low speed brain.

Okay, I will slow down a bit.

So, is your MCP23017 with the clock speed fast enough for you purposes?
First of all, lets talk something about I2C. I think you use a library for sending data to the MCP23017 by you I2C bus.

So, first we need to look at the datasheet and the AN1043. And yes, this is a lot of information if you are not familiar with it.

You can see the communication with a I2C devices as following (figure 3-3 from datasheet or figure 7 from AN1043). To make it a little bit clearer how the basic I2C communication works.
Let’s say; You what to buy a nice cold beer from a supermarket. There are a lot of options here, but you go to Walmart (device opcode). At the store you go to the beer aisle (register address). And you take out of the shelf (data) a nice cold beer.

In the case of the MCP23017 every “thing” you send to him or get from is one byte (8bits). See, this picture. Discard the 14h for now. So, if you want to change the output of the GPIOA and the GPIOB you sent this information to him: device opcode -> register address, where the data need to be stored -> data for the GPIOA -> data for the GPIO.

MCP23017 data register.png (101.05 KiB) Viewed 3563 times

To send data to him, each clock pulse representative one bit transfer data, see this image:

i2c data timing.png (54.88 KiB) Viewed 3563 times

And because you clock speed is 100kHz, the duration of one clock cycle is 10uS. So, if you want to send the data that are described above. It will take at least 4*8*10uS = 320uS. (4 data packeges, each is 8bit). And if you doesn’t want to change the data of the GPIOB, it takes 240uS.
(*it will take a little bit longer because of the start, acknowledge, and stop are not included in this.)

So, this means that it will take at least 240uS to send data from you pi to the output register of the MCP23017. And there is also a slide delay before the data is present at the ouput (500ns).

What does this al means to you. Well we conclude that with a clock speed of 100kHz it takes around 240uS to send data from the pi to the MCP23017. And this means that you clock speed is to slow to generate the pulse that is required for the DHT22.

I hope it’s now a little bit more clear

[Brandon92]

Now let us have some brain storming.

• (1) If hts couldn't wait longer than 200uS, then I seem to be hopeless, unless I do hardware get around, such as automatically generating the 26/30/200uS high by using hard ware logic gates etc. But that is stupid and might damage my reputation .

• (2) But then I can consider forgetting the stupid I2C thing altogether, and switch to SPI based MCP23x17, that is MCP23S17. Last year I tried MCP23S08 and MCP23S17 and found them OK. I only chose I2C and not SPI because I read that I2C wires can be much longer, perhaps 200m, than SPI, perhaps 10m.

Any ideas?

Original the I2C bus and the SPI bus are designed to be a PCB communication bus. And not a long wire bus. So, if you speed things up. It can cause some data issues. The easiest way to solve this issue is to speed up the clock speed of you I2C bus. Or use a other IO expansion that is only 8 bit to speed up some thing.

As I show in my previous figure 7. It's possible to send constant data to the MCP* chip. This will save you some time to change the output faster. But after you send the pulse, you have 75*2uS the time to change the ouput of the MCP* to become a input. And after that, you need to read all the data from the DHT22 and is you data bus than fast enough?

[tlfong01]

The short story is: When you let one ground clip not connected to the ground of you system. It can/will act as some kind of antenna and could pick up some noise. And that noise is superimposed on you signal that you want to measure. And if there is in system, or around the system, a decent amount of noise it will show up. And it will look like you signal is not good and you could go down the rabbit hole. To find out why it is. And yes, if have been there too

Many thanks for opening my eyes. Yes, the key word is antenna. I never imagine that my little probe can, in some situations, become an evil antenna.

[tlfong01]

AN1043. And yes, this is a lot of information if you are not familiar with it.

Ah, I read the datasheet many many times, but still find things confusing. And App Notes AN1043 is very useful, when I need to dig deeper.

One of the many confusing things is the pad. What the hell is a pad? Is it a piece of physical metal stuck on the chip/die, or one logical bit of an eight bit data register/buffer?

Another thing is the difference between the OLAT and GPIO register. In the app note's diagram, the eight d-type flipflops are labelled OLAT or GPIO. But the data sheets says they are two registers.

Don't bother to explain or clarify anything for me now. I will try to read the datasheet and app notes one more time and think harder to clear my mind. This way I will understand and remember better.

BTW, I always stare at the following AN1043 picture for at least 3 minutes, before I debug my MCP23x17 functions.

[Brandon92]

One of the many confusing things is the pad. What the hell is a pad? Is it a piece of physical metal stuck on the chip/die, or one bit of an eight bit data register/buffer?

Wel, in this case the pad in the IO pin of the chip (to tje outside world) And in that picture it has the pink colour as well. (I/O pad)