User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Wed Aug 08, 2018 3:05 pm

Brandon92 wrote:
Wed Aug 08, 2018 9:45 am
tlfong01 wrote:
Wed Aug 08, 2018 7:44 am
  • (2) But then I can consider forgetting the stupid I2C thing altogether, and switch to SPI based MCP23S17
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?

OK, OK, I know my chance is small. But before switching to SPI, I am taking a last look at the hopeless I2C timing diagram.

I agree that I cannot overcome the two hurdles B and C+D, to get to point E where I can use MCP23017 pin change interrupt to catch up.

Only hope is taking some illegal drugs, like those dishonest sports guys, to cheat the system and get my gold medal. :lol:
Attachments
WrqGXEu[1].jpg
WrqGXEu[1].jpg (77.26 KiB) Viewed 349 times
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

Brandon92
Posts: 179
Joined: Wed Jul 25, 2018 9:29 pm
Location: Netherlands

Re: Relay Module KY-019 5V

Wed Aug 08, 2018 4:25 pm

I was reading a little bit in the datasheet of the DH22[/ur]. But I think the pi only need to deliver the start signal. And the rest is done by the sensor:
DHT22 protocol.PNG
DHT22 protocol.PNG (219.11 KiB) Viewed 336 times
My other concern is this:
DHT22 protocol read data.PNG
DHT22 protocol read data.PNG (170.3 KiB) Viewed 336 times
When the bit is low, its only 28uS high. And you need also get that one. So, a faster SPI bus would help. But I thing you can't run them easily at >1MHz at a long wire. And that's what you need. You could use something like this. But I think that's a little bit overkill for this. Are there no other sensor that you can directly connect to a data bus?

I assume that you want to use a io extender, because you can place than arround you house and connect different things to it.
A other possible is that you replace the io extender for a small microcontroller. The microcontroller can translate the signal from the sensors to a robust transmission line between him and the pi.

Brandon92
Posts: 179
Joined: Wed Jul 25, 2018 9:29 pm
Location: Netherlands

Re: Relay Module KY-019 5V

Wed Aug 08, 2018 7:59 pm

You could also be looking for this type of sensor, here a couple of examples :

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Thu Aug 09, 2018 4:05 am

Brandon92 wrote:
Wed Aug 08, 2018 7:59 pm
You could also be looking for this type of sensor, here a couple of examples :

Yes, I learnt DHT22 from a review of ladyAda who says it is good, and you can buy from adaFruit. :lol: But now I know DHT22 is perhaps good for hobbists and hacker, but not OK for I2C users. So I am looking for an I2C compatible sensor.

Just now I searched my favourite TaoBao shop and found the following goodies. It is very likely I would order the cheapest 32 yuan hts module, and also the as cheap 24 yuan power monitor module.

CJMCU-1080 HDC1080 hts module 32 yuan
https://item.taobao.com/item.htm?spm=a3 ... 0565169390

CJMCU-SHT21 hts module 43 yuan
https://item.taobao.com/item.htm?spm=a3 ... 2365842778

CJMCU-SHT11 hts module 48 yuan
https://item.taobao.com/item.htm?spm=a3 ... 2236350041

CJMCU-SHT15 hts module 98 yuan
https://item.taobao.com/item.htm?spm=a3 ... 2139521491

CMCU power monitor

CJMCU-226 INA226 voltage/power/monitor/alarm 36V AC/DC I2C 24 yuan
https://item.taobao.com/item.htm?spm=a3 ... 2110381646

TaoBao CMCU Shop
https://cjmcu.world.taobao.com/?spm=a31 ... 73438n1Xsd

CMCU Humidity Temperature Sensors
https://cjmcu.world.taobao.com/category ... %C6%F7#bd
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Thu Aug 09, 2018 8:17 am

Brandon92 wrote:
Wed Aug 08, 2018 4:25 pm
1. I think the pi only need to deliver the start signal. And the rest is done by the sensor:
2. When the bit is low, its only 28uS high. And you need also get that one. So, a faster SPI bus would help.
3. can't run them easily at >1MHz at a long wire.
4 use something like this. a little bit overkill for this.
5. Are there no other sensor that you can directly connect to a data bus?
6. you want to use a io extender, because you can place than arround you house and connect different things to it.
7. A other possible is that you replace the io extender for a small microcontroller. The microcontroller can translate the signal from the sensors to a robust transmission line between him and the pi.

  • 1. to 4. - I agree with you.
  • 5. I just ordered the cheap HPC1080 module. I also ordered the INA226 power monitoring thing. (update 2018aug11 - I forgot to include INA226 in my order.)
  • 6. Yes.
  • 7. Yes, my long term plan, perhaps 2 years from now, is a distributed Rpi system, say, Rpi3B+ x 4, and RpiZW x 4. That is why I am very interested in pigpio, which seems to be very powerful for distributed Rpi + Windows.
CJMCU-1080 HDC1080 hts module 32 yuan
https://item.taobao.com/item.htm?spm=a3 ... 0565169390

CJMCU-226 INA226 voltage/power/monitor/alarm 36V AC/DC I2C 24 yuan
https://item.taobao.com/item.htm?spm=a3 ... 2110381646
Last edited by tlfong01 on Sat Aug 11, 2018 1:03 am, edited 1 time in total.
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

Brandon92
Posts: 179
Joined: Wed Jul 25, 2018 9:29 pm
Location: Netherlands

Re: Relay Module KY-019 5V

Thu Aug 09, 2018 11:49 am

Okey. The only (possible) down-side of that sensor is that it doesn't have a changeable "address register". (I didn't read the datasheet). So, if you want to read out all those sensor on the same bus are going to replay at the same time. If they had only one, you could use the I/O extender to change the address pin. In that case you can read only one (and the others will have the same adress).

I you concern about the power use of the hole system. Than it's better to use one pi, and the rest small microcontrollers, because they use less power.

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Thu Aug 09, 2018 1:04 pm

Brandon92 wrote:
Thu Aug 09, 2018 11:49 am
1. Okey. The only (possible) down-side of that sensor is that it doesn't have a changeable "address register". (I didn't read the datasheet).
2. So, if you want to read out all those sensor on the same bus are going to replay at the same time.
3.If they had only one, you could use the I/O extender to change the address pin. In that case you can read only one (and the others will have the same adress).
4. I you concern about the power use of the hole system. Than it's better to use one pi, and the rest small microcontrollers, because they use less power.

1. The new humidity temperature sensor module I have ordered has only 4 pins, Vcc, Gnd, SCL, SDA. No hardware address pins.

2. I usually use a I2C demultiplexor/switch to switch one of many chips (up to 8 x 8 = 64 chips) with same I2C address. I also make use of the enable pin of the TSX0104E level converter to demultiplex I2C channels (so I can demultiplex as many as 128 I2C channels). I used to use 4 Rpi GPIO pins to select 4 I2C channels without any problem. I once used demultiplexor ICs HC137, HC138 to save Rpi GPIO pins. My greedy approach is scaleable, though gets exponentially messy.

3. I don't seem to have heard the term IO extender. I think MCP23017 is IO expander.
I also heard of I2C expander and also I2C extender.

It is indeed confusing.

I2C Demultiplexor/Switch
https://i.imgur.com/BITWxkY.jpg

TCA9548A 8 Channel I2C Switch
http://www.ti.com/lit/ds/symlink/tca9548a.pdf

I2C Expander
https://i.imgur.com/TD6VjeW.jpg

I2C Extender
https://i.imgur.com/L89dhcC.jpg
Last edited by tlfong01 on Thu Aug 09, 2018 2:01 pm, edited 3 times in total.
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

Brandon92
Posts: 179
Joined: Wed Jul 25, 2018 9:29 pm
Location: Netherlands

Re: Relay Module KY-019 5V

Thu Aug 09, 2018 1:12 pm

Nice, that will work used fine.
Yes, is used the wrong word for that :?

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Thu Aug 09, 2018 1:50 pm

tlfong01 wrote:
Wed Aug 08, 2018 1:56 pm
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?
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.

IO Pad reading notes

I googled to read about IO pad. I found out that this pad thing is usually discussed in CMOS chip design. It is indeed a piece of metal 150 sq mm, 'stuck' in the die/chip. But of course the pad has it uses. I skimmed 2 references, got a very rough idea, and gave up. My conclusion is that to fully understand the pad thing, I might need to spend some 20 hours or more. And because this pad is irrelevant to my use of MCP23017. So I stopped here.

CMOS VLSI DEsign Lecture 23 IO [IO pads]
http://pages.hmc.edu/harris/cmosvlsi/4e/lect/lect23.pdf

Module D7: VLSI Design, Technology, and CAD 14 I/O Pads and Pad Drivers
http://www2.eng.cam.ac.uk/~dmh/4b7/reso ... tion14.htm

14.1 The Function of Pads and Pad Drivers

The circuitry on a chip has to connect with other circuits. These may be chips or display devices, transducers or electro-mechanical devices and the capacitance connected to the chip could be very large. In some cases the devices being driven will require or supply TTL signal levels, in others they may be liable to be short circuits, have high noise levels or be liable to discharge spikes of several kV. Each of these situations will require the imposition of circuitry to interface the chip to the external environment. Most IC designers avoid the problem of pad design and take pad drivers from standard libraries.

Physically, pads are the squares of metal, generally 100-150 mm square, that are connected to the pins of the package with bonding wires. The word pad is often used to also include the circuitry that is used to interface the CMOS logic within the IC (typically composed of near minimum-geometry transistors) to the outside world. At least two pads in each circuit will be used to connect the chip to the VDD and VSS power supply lines, while other pads will be used for input connections and output connections. Some pads may also be required to be bi-directional, (for use both with input signals and output signals). In such cases there is usually a control connection to determine the direction of signal transfer.

An important function for all pad driver circuitry is the protection of the chip circuitry against destruction due to overvoltage pulses or sustained overvoltages. These may be due to electrostatic discharges or due to faults on other circuitry that cause unexpectedly high voltages to be applied to the chip pins.

14.2 The Positioning of Pads and Associated Circuitry

Typical arrangements for pads and associated circuitry are shown in Figure 14.1. ...


.END
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

Brandon92
Posts: 179
Joined: Wed Jul 25, 2018 9:29 pm
Location: Netherlands

Re: Relay Module KY-019 5V

Thu Aug 09, 2018 2:05 pm

Well, in this case the "pad" isn't that imported for the use of the MCP23017. It's just a fancy name.
Brandon92 wrote:
Wed Aug 08, 2018 2:14 pm
tlfong01 wrote:
Wed Aug 08, 2018 1:56 pm
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 the outside world) And in that picture it has the pink colour as well. (I/O pad)
https://www.raspberrypi.org/documentation/hardware/raspberrypi/gpio/README.md wrote:GPIO pads
The GPIO connections on the BCM2835 package are sometimes referred to in the peripherals data sheet as "pads" — a semiconductor design term meaning 'chip connection to outside world'

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Fri Aug 10, 2018 2:26 am

Brandon92 wrote:
Wed Aug 08, 2018 9:24 am
So, is your MCP23017 with the clock speed fast enough for you purposes?
1. 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. ...
2. 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. ...
3. 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). ...
4. 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. ...

MCP23017 Study Notes

Thanks for your detailed explaination, and conclusion that the Rpi I2C is not fast enough to ask MCP23017 to talk to DHT22. I have not yet read the TI app report on I2C bus. I have made a list of reference I need to read again, before I try to follow your explanation.

Your references remind me the first time I heard about MCP23008, when I read MagPi 2013Sep. Yes, that was 5 years ago. I was glad to learn that I could expand Rpi's GPIOs. The author says that the topic is advanced. But his tutorial is very good, very newbie friendly, ...

Now that I have read the references, I will comment on your argument and conclusion in my next post.

Appendix - I2C References

Expanding your senses with I2C - Difficulty: Advanced, MagPi Issue 16, 2013 Sep
https://www.raspberrypi.org/magpi-issue ... page 4~10

MCP23017 MCP23S17 16-Bit I/O Expander with Serial Interface
http://ww1.microchip.com/downloads/en/D ... 01952C.pdf

AN1043 - Unique Features of the MCP23X08/17 GPIO Expanders - Pat Richards Microchip Technology
http://ww1.microchip.com/downloads/en/A ... 01043a.pdf

Understanding the I2C Bus - TI Application Report SLVA704–June 2015
http://www.ti.com/lit/an/slva704/slva704.pdf
Last edited by tlfong01 on Fri Aug 10, 2018 3:58 am, edited 1 time in total.
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Fri Aug 10, 2018 3:53 am

Brandon92 wrote:
Wed Aug 08, 2018 9:24 am
So, is your MCP23017 with the clock speed fast enough for you purposes?
1. first we need to look at the datasheet and the app notes AN1043, ...
2. you what to buy a nice cold beer from a supermarket ,...
3. In the case of the MCP23017 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.
4. each clock pulse representative one bit transfer data you clock speed is 100kHz, the duration of one clock cycle is 10uS.
5. 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.
6. So, this means that it will take at least 240uS to send data from you pi to the output register of the MCP23017.
7. 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.
8. And this means that you clock speed is to slow to generate the pulse that is required for the DHT22.

Well, after reading your recommending references, I can now barely follow your argument. I think there might still be some hope. Your 16 bit mode example seems to write to GPIOA, then GPIOB.

What if I use 8 bit mode, disabling address pointer increment, and write to GPIOA, and again GPIOA?
Attachments
GoWluI5[1].jpg
GoWluI5[1].jpg (137.75 KiB) Viewed 220 times
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Fri Aug 10, 2018 6:37 am

Brandon92 wrote:
Wed Aug 08, 2018 9:24 am
Is your MCP23017 with the clock speed fast enough for you purposes?
1. I think you use a library for sending data to the MCP23017 by you I2C bus.
2. 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. ... To send data to him, each clock pulse representative one bit transfer data, ... clock speed is 100kHz, one clock cycle is 10uS.
3. 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.)
4. 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 output (500ns).
6. 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.

To follow your argument, let me walk slowly. I have written and tested a "Minimal, Complete, Verifiable, NoProgram Example (MCVNE) as list below. I will use this as an example. There is no need to read my example, though.

  • 1. Yes, I use import smbus.
  • 2. My function to write a byte to a mcp23017 register takes 4 parameters: i2c bus channel object, mcp23017 device address, mcp23017 device register address, the byte to write.

    def writeDvRegOneByte(i2cCh, dvAddrByte, DvRegAddrByte, writeByte):
    ...
    return
  • 3. Here I am a bit confused. I think what I need to do first is ask MCP23017 to send the start signal, which consists of 2 steps, (1) send a 50ms High signal, (2) send a 26mS signal. So I will write one data byte to GPIO A, and another data byte again to GPIO A.

    I am not sure if I read the datasheet correctly, I will pause here, read the datasheet, and come back later.

Code: Select all

# iox01.1089 tlfong01 2018aug10hkt1355

# *** Import ***

import datetime
import smbus

# *** Config ***

programTitle                                = 'MCP23017 Example Test Program '
timeNowStr                                  = str(datetime.datetime.now())[0:16]
i2cCh                                       = smbus.SMBus(1)
dvAddrByte                                  = 0x22
ioDirRegAddrByteA                           = 0x00
dataByte0x55                                = 0x55
dataByte0xaa                                = 0xaa

# *** Device Functions ***

def readDvRegOneByte(i2cCh, dvAddrByte, DvRegAddrByte):
    readByte = i2cCh.read_byte_data(dvAddrByte, DvRegAddrByte)
    return readByte

def writeDvRegOneByte(i2cCh, dvAddrByte, DvRegAddrByte, writeByte):
    writeDvTwoBytes(i2cCh, dvAddrByte, DvRegAddrByte, writeByte)
    return

def writeDvTwoBytes(i2cCh, dvAddrByte, dataByte1, dataByte2):
    i2cCh.write_byte_data(dvAddrByte, dataByte1, dataByte2)
    return

def printDvRegOneByte(i2cCh, dvAddrByte, DvRegAddrByte, printTitle):
    readByte = readDvRegOneByte (i2cCh, dvAddrByte, DvRegAddrByte)
    print(printTitle, hex(readByte))

# *** Test Functions ***

def testWriteReadPrintIoDirRegA(testDataByte):
    printDvRegOneByte(i2cCh, dvAddrByte, ioDirRegAddrByteA, 'Old Byte =')
    writeDvRegOneByte(i2cCh, dvAddrByte, ioDirRegAddrByteA, testDataByte)    
    printDvRegOneByte(i2cCh, dvAddrByte, ioDirRegAddrByteA, 'New Byte =')
    return

def test():
    print('*** TimeNow = ', timeNowStr, '***\n')
    print('***', programTitle, 'Begin ***\n')
    testWriteReadPrintIoDirRegA(dataByte0x55)
    testWriteReadPrintIoDirRegA(dataByte0xaa)
    print('\n')
    print('***', programTitle, 'End  ***')
    return

# *** Main ***

test()


# *** Sample Output ***

'''
*** TimeNow =  2018-08-10 13:59 ***

*** MCP23017 Example Test Program  Begin ***

Old Byte = 0xaa
New Byte = 0x55
Old Byte = 0x55
New Byte = 0xaa


*** MCP23017 Example Test Program  End  ***
'''

# *** End ***
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Fri Aug 10, 2018 7:16 am

tlfong01 wrote:
Fri Aug 10, 2018 6:37 am
  • 3. Here I am a bit confused. I think what I need to do first is ask MCP23017 to send the start signal, which consists of 2 steps, (1) send a 50ms High signal, (2) send a 26mS signal. So I will write one data byte to GPIO A, and another data byte again to GPIO A.
    I am not sure if I read the datasheet correctly, I will pause here, read the datasheet, and come back later.

One thing I need to first refresh my memory is the I2C block write command list below.

write_i2c_block_data(addr, cmd, vals)

Appendix

Linux Kernel - I2C and SMBus Subsystem
https://01.org/linuxgraphics/gfx-docs/d ... i/i2c.html

SMBus Protocol Summary
https://git.kernel.org/pub/scm/linux/ke ... s-protocol

wiki:linux:python:smbus:doc]] wiki.erazor-zone.de
http://wiki.erazor-zone.de/wiki:linux:python:smbus:doc
Attachments
cpJlVqO[1].jpg
cpJlVqO[1].jpg (162.14 KiB) Viewed 199 times
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Fri Aug 10, 2018 12:42 pm

tlfong01 wrote:
Fri Aug 10, 2018 7:16 am
One thing I need to first refresh my memory is the I2C block write command list below.
write_i2c_block_data(addr, cmd, vals)

Testing notes of Rpi repeatedly sending Start Signal to DHT22

Now I have written a function to repeatedly write a 3 byte block, to check timing. The test function is summarized below. The complete program of 85 lines long is listed in the code block. The displayed waveform will be shown in the next post.

def testRepeatWriteBlock():
writeBlock = [0x0f, 0x55, 0xf0]
for count in range(500):
writeDvOneBlock(i2cCh, dvAddrByte, ioDirRegAddrByteA, writeBlock)
time.sleep(0.01)
return

Code: Select all

# iox01.1092 tlfong01 2018aug10hkt2022

# *** Import ***

import datetime
import time
import smbus

# *** Config ***

timeNowStr                                  = str(datetime.datetime.now())[0:16]
i2cCh                                       = smbus.SMBus(1)
dvAddrByte                                  = 0x22
ioDirRegAddrByteA                           = 0x00
dataByte0x55                                = 0x55
dataByte0xaa                                = 0xaa

# *** Device Functions ***

def readDvRegOneByte(i2cCh, dvAddrByte, DvRegAddrByte):
    readByte = i2cCh.read_byte_data(dvAddrByte, DvRegAddrByte)
    return readByte

def writeDvRegOneByte(i2cCh, dvAddrByte, DvRegAddrByte, writeByte):
    writeDvTwoBytes(i2cCh, dvAddrByte, DvRegAddrByte, writeByte)
    return

def writeDvTwoBytes(i2cCh, dvAddrByte, dataByte1, dataByte2):
    i2cCh.write_byte_data(dvAddrByte, dataByte1, dataByte2)
    return

def printDvRegOneByte(i2cCh, dvAddrByte, dvRegAddrByte, printTitle):
    readByte = readDvRegOneByte (i2cCh, dvAddrByte, dvRegAddrByte)
    print(printTitle, hex(readByte))

def writeDvOneBlock(i2cCh, dvAddrByte, dvRegAddrByte, writeBlock):
    i2cCh.write_block_data(dvAddrByte, dvRegAddrByte, writeBlock)
    return

# *** Test Functions ***

def testWriteReadPrintIoDirRegA(testDataByte):
    printDvRegOneByte(i2cCh, dvAddrByte, ioDirRegAddrByteA, 'Old Byte =')
    writeDvRegOneByte(i2cCh, dvAddrByte, ioDirRegAddrByteA, testDataByte)    
    printDvRegOneByte(i2cCh, dvAddrByte, ioDirRegAddrByteA, 'New Byte =')
    return

def testWriteReadIoDirA():
    programTitle = 'testWriteReadPrintIoDirRegA'
    print('***', programTitle, 'Begin ***\n')
    print('Time     = ', timeNowStr, '***\n')
    testWriteReadPrintIoDirRegA(dataByte0x55)
    testWriteReadPrintIoDirRegA(dataByte0xaa)
    print('\n')
    print('***', programTitle, 'End  ***\n')
    return

def testRepeatWriteBlock():
    programTitle = 'testRepeatWriteBlock'
    print('***', programTitle, 'Begin ***\n')
    print('Time     = ', timeNowStr, '***\n')
    writeBlock = [0x0f, 0x55, 0xf0]
    print('Writing block begin, ...')
    for count in range(500):
        writeDvOneBlock(i2cCh, dvAddrByte, ioDirRegAddrByteA, writeBlock)
        time.sleep(0.01)
    print('Writing block end.')
    print('\n')
    print('***', programTitle, 'End  ***\n')
    return

def test():
    testWriteReadIoDirA()
    testRepeatWriteBlock()
    return
    
# *** Main ***

test()

# *** Sample Output ***

# *** End ***
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Fri Aug 10, 2018 12:55 pm

Testing notes of Rpi repeatedly sending Start Signal to DHT22

I am making a very rough calculation of timing of writing 3 bytes to MCP23017 register IODIRA.

A very quick and dirty, not yet proof read calculation shows that

writing one byte takes roughly 133uS.

Now I need to test toggling pin in GPIO A, or OLAT A, to see how much time it takes to make a toggle.

Appendix A - Repeat write 3-byte block function

def testRepeatWriteBlock():
writeBlock = [0x0f, 0x55, 0xf0]
for count in range(500):
writeDvOneBlock(i2cCh, dvAddrByte, ioDirRegAddrByteA, writeBlock)
time.sleep(0.01)
return


Appendix B - StackOverflow Code of Conduct
https://stackoverflow.com/conduct?utm_s ... t%20launch
Attachments
xdnZPvu[1].jpg
xdnZPvu[1].jpg (110.35 KiB) Viewed 173 times
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Fri Aug 10, 2018 1:54 pm

Brandon92 wrote:
Wed Aug 08, 2018 4:25 pm
So, a faster SPI bus would help. But I thing you can't run them easily at >1MHz at a long wire. And that's what you need.

Python Multiprocessing Learning Notes

  • 1. Perhaps I can use software bit bang type I2C packages. Then I can have high speed I2C, 400kHz, 800kHz, or even higher.
  • 2. Or do some sort of multiprocessing. For example, to generate the DHT22 Start Signal, I can run 2 python processes, one process to write the first, Low level part of the Start Signal, another process to write the second, High level part of the Start Signal.

    Perhaps I can use 2 MCP23017s, one controlled by one process.
  • 3. Some two months I ago I started learning Python multiprocess and found that it is not that difficult to implement. I might consider using multiprocessing in my home automation project.
To refresh my memory, I am reading some of my old multiprocessing program, to check out if I can still understand my not well commented functions.

/ to continue, ...

Appendix - Python Multiprocessing Example

Part 1
https://i.imgur.com/L9SLkgr.jpg
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

Brandon92
Posts: 179
Joined: Wed Jul 25, 2018 9:29 pm
Location: Netherlands

Re: Relay Module KY-019 5V

Fri Aug 10, 2018 2:22 pm

tlfong01 wrote:
Fri Aug 10, 2018 1:54 pm
Brandon92 wrote:
Wed Aug 08, 2018 4:25 pm
So, a faster SPI bus would help. But I thing you can't run them easily at >1MHz at a long wire. And that's what you need.

Python Multiprocessing Learning Notes

  • 1. Perhaps I can use software bit bang type I2C packages. Then I can have high speed I2C, 400kHz, 800kHz, or even higher.
  • 2. Or do some sort of multiprocessing. For example, to generate the DHT22 Start Signal, I can run 2 python processes, one process to write the first, Low level part of the Start Signal, another process to write the second, High level part of the Start Signal.

    Perhaps I can use 2 MCP23017s, one controlled by one process.
  • 3. Some two months I ago I started learning Python multiprocess and found that it is not that difficult to implement. I might consider using multiprocessing in my home automation project.
To refresh my memory, I am reading some of my old multiprocessing program, to check out if I can still understand my not well commented functions.

/ to continue, ...

Appendix - Python Multiprocessing Example

Part 1
https://i.imgur.com/L9SLkgr.jpg
1 You can set the I2C in the hardware of your pi faster, as I belive.
2 I think this is to compulicated for a simple sensor, see below:

Perhaps its easier to connect the sensor directly to you pi. Because the code is already "long" if you connect it directly to the pi, As show here, there is somewhere a example of you sensor. So, how you can integrate this in you system design. I assume that you gone use this connector for each room you want to measure / control. Than you can dedicate one (pair) wire to use as a dedicated transmission line for special stuff. You can use the MCP23017 to select with device you want to communicate with. The MCP23017 can control for example a analog switch. I think this is a easiest way for you. But the most easiest is to chose a sensor with a easier communication bus.

This sensor could be relative cheap, but if you need to spent a lot of time, and possible more than one part to control it. Is it then still cheap?

Please let me know were you need some advice. I unfortunately doesn't know much about Python. I started a couple weeks back with it.

Brandon92
Posts: 179
Joined: Wed Jul 25, 2018 9:29 pm
Location: Netherlands

Re: Relay Module KY-019 5V

Fri Aug 10, 2018 7:53 pm

Importend:

tlfong01 wrote:
Fri Aug 10, 2018 12:55 pm
Testing notes of Rpi repeatedly sending Start Signal to DHT22
Wait a minute. I was looking at you oscilloscope picture of the I2C data that you provided. But I found something suspicious about the signals. I see in that picture, you bus is low when its inactive. (When you don’t use the bus its 0V). But a proper I2C bus is a high when its not in use. Because of the pull up resistor.
UM10204 (like above) wrote:3.1.1 SDA and SCL signals
Both SDA and SCL are bidirectional lines, connected to a positive supply voltage via a
current-source or pull-up resistor (see Figure 3). When the bus is free, both lines are
HIGH
So, I looked up what you used:
tlfong01 wrote:
Sat Aug 04, 2018 2:10 pm
I displayed the I2C signals (after level shifting by TSX0104E, and buffered by HC04) and found them more or less OK.
You know that the I2C bus is a Bidirectional data bus and this IC is one direction! And it get even worse, it will invert you signal. This explain what I wrote at the start. And you can better use a product that is designed for this task. For example: P82B715, but there are many more ;)
P82B715 I2C Bus Extender wrote:I2C Bus Operation Over 50 Meters of Twisted-Pair Wire


Please confirm if this is right or not

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Sat Aug 11, 2018 4:41 am

Brandon92 wrote:
Fri Aug 10, 2018 7:53 pm
Importend:
Wait a minute. I was looking at you oscilloscope picture of the I2C data that you provided. But I found something suspicious about the signals. I see in that picture, you bus is low when its inactive.
tlfong01 wrote:
Sat Aug 04, 2018 2:10 pm
I displayed the I2C signals (after level shifting by TSX0104E, and buffered by HC04) K.
Please confirm if this is right or not

Why use HC04 to buffer (therefore invert) I2C Signals

Ah, here is one problem you might help.

Some days ago when I was checking out why my I2C clocks always shows 100Khz, even I modified /boot/config.txt to set it to 400kHz. I found that if I used my scope probe to directly check/touch I2C Clk, I immediately got Rpi I2C transmission error message. I guessed my scope probe input impedance is too low, and so overloaded TSX04E's I2C CLK output.

My get around is to use HC04 as a buffer. I usually use this trick to off load SPI, UART lines.

RE: RELAY MODULE KY-019 5V Post by tlfong01 » 2018-Aug-04
viewtopic.php?f=37&t=77158&start=275#p1349002

To avoid future scope display watchers' confusion, I should have inverted the I2C signals twice. :lol:
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Sat Aug 11, 2018 8:38 am

tlfong01 wrote:
Sat Aug 11, 2018 4:41 am
To avoid future scope display watchers' confusion, I should have inverted the I2C signals twice. :lol:

MCP23017 Repeatedly block write 2 bytes to GpioA testing notes

Now I have done the following things:

  • (1) Invert I2C SCL, SDA twice by HC04.
  • (2) Refactoring using the following approaches:
    2.1 Add one more level of abstraction to the read/write/print MCP23017 register functions.
    2.2 Use dictionary (not stupid lists) to index the register addresses, config bytes, config bits with human friendly, less error prone names
    2.3 Almost pure function programming approach, closely following the software engineering's Open Close Principle
  • (3) Last time I tested repeatedly sent 3 bytes to DirRegA, this time I do the following.
    3.1 Disable auto register pointer incrementing
    3.2 Bank0 (not sure if this means 8-bit, nonsequential, byte mode)
    3.3 Set all GpioA pins output
    3.4 Repeatedly block write 2 test bytes 0xf0, 0x0f to GpioA
  • (4) Include design notes and output sample with the program listing.
I have attached a full list of the test program for your comments. The 308 line long program is a Minimal, Complete, Verifiable, NoProblem Example (MCVNE)

Code: Select all

# iox01.1095 tlfong01 2018aug11hkt1626

# *** Import ***

import datetime
import time
import smbus

# *** Config ***

# *** MCP23017 Device Register Address Dictionary (iocon.bank = 0) ***

regAddrByte = \
    {	
        'IODIRA'  	: 0x00, 
	'IODIRB'	: 0x01, 
	'IPOLA'		: 0x02,
	'IPOLB'		: 0x03, 
	'GPINTENA'      : 0x04, 
	'GPINTENB'	: 0x05, 
	'DEFVALA'	: 0x06, 
	'DEFVALB'	: 0x07, 
	'INTCONA'	: 0x08, 
	'INTCONB'	: 0x09, 
	'IOCON' 	: 0x0b, 
	'IOCON' 	: 0x0a, 
	'GPPUA' 	: 0x0c, 
	'GPPUB' 	: 0x0d, 
	'INTFA' 	: 0x0e, 
	'INTFB' 	: 0x0f, 
	'INTCAPA'	: 0x10, 
	'INTCAPB'	: 0x11,
	'GPIOA' 	: 0x12,
        'GPIOB'         : 0x13,
        'OLATA'         : 0x14,
        'OLATB'         : 0x15,
        'PortA'         : \
            {
                'Direction'         : 0x00,
                'OutLatch'          : 0x14,
                'GpioPort'          : 0x12,
            },
        'PortB'         : \
            {
                'Direction'         : 0x01,
                'OutLatch'          : 0x15,
                'GpioPort'          : 0x13,
                'IntPinsEnable'     : 0x05,
                'IntPinsDefault'    : 0x07,
                'IntPinsCompare'    : 0x09,
                'InterruptFlagByte' : 0x0f,
                'IntCap'            : 0x11,
                'PullUp'            : 0x0d
            },
        }


# *** MCP23017 Control Byte Dictionary ***

controlByte = \
    {
        'WriteRegBaseByte'                          : 0x40,
        'ReadRegBaseByte'                           : 0x41,
        'EnableAddressPins'                         : 0x08,
        'AllPinsOutput'                             : 0x00,
        'AllPinsInput'                              : 0xff,
        'LowNibblePinsOutputHighNibblePinsInput'    : 0xf0,
        'IntAllPinsEnable'                          : 0xff,
        'IntPinsEnable'                             : 0xff,
        'IntAllPinsCompareDefault'                  : 0xff,
        'AllPinsPullUp'                             : 0xff,
        'AllHigh'                                   : 0xff,
        'AllLow'                                    : 0x00,
        'AllPinsHigh'                               : 0xff,
        'AllPinsLow'                                : 0x00,
        'IntAllPinsHigh'                            : 0xff,
        'IntAllPinsLow'                             : 0x00,
        'IntLowNibblePinsEnable'                    : 0x0f,
        'IntLowNibblePinsComparePrevious'           : 0x00,
        '0x01'                                      : 0x01,
        '0x55'                                      : 0x55,
        '0x66'                                      : 0x66,
        '0xaa'                                      : 0xaa,
        '0x0f'                                      : 0x0f,
        '0xf0'                                      : 0xf0,     
    }

# *** MCP23017 Config Bit Dictionary ***

basicCnfgBits = \
    {
        'BaseByte'                      : 0x00,
        'RegAddrBank0'                  : 0b0 << 7,
        'TwoIntPinsNoMirror'            : 0b0 << 6,
        'TwoIntPinsMirror'              : 0b1 << 6,
        'AutoIncRegAddrDisable'         : 0b1 << 5,
        'SlewRateDiable'                : 0b0 << 4,
        'HardwareAddrEnable'            : 0b1 << 3,
        'ActiveDriver'                  : 0b0 << 2,
        'OpenDrain'                     : 0b1 << 2,               
        'IntActiveLevelHigh'            : 0b1 << 1,
        'IntActiveLevelLow'             : 0b0 << 1,
        'Unimplemented'                 : 0b0 << 0,
    }

# Notes:
# Byte mode       = disable automatic Address Pointer incrementing.
# Sequential mode = enable  automatic Address Pointer incrementing. 
# Toggle register pointer mode = Byte mode with IOCON.BANK = 0
# GPIO module = 16 bit bidirectional port splie into 2 8-bit ports
# GPIO module contains
# (1) Data ports (GPIOn),
# (2) Output latches (OLATn)
# (3) Pull up resistors
# GPIO and OLAT relationship (Datasheet Section 3.4)
# Reading GPIOn register read the value on the port.
# Reading OLATn register only reads the latches, NOT the actual value on the port.
# Writing to the GPIOn register actually causes a write ot the latches (OLATn).
# Writing to the OLATn register forces the associated output drivers to drive to
# the level in OLATn.
# Pins configured as inputs turn off the associated output driver and put it in
# high impedance


    
# ***MCP23017 Default Config Byte ***

# Notes - V0.1.1092 tlfong01 2018aug11hkt1330
# Bank number = 0
# Interrupt flags configuration = mirror
# Hardware address select = On
# Interrupt pin configuration = Totem Pole (push/pull, not open drain)
# Interrupt trigger level = low

basicCnfgBnk0NoMrrNoAutoIncActDrvIntHghAct =                   \
                   basicCnfgBits['BaseByte']                 | \
                   basicCnfgBits['RegAddrBank0']             | \
                   basicCnfgBits['TwoIntPinsMirror']         | \
                   basicCnfgBits['AutoIncRegAddrDisable']    | \
                   basicCnfgBits['SlewRateDiable']           | \
                   basicCnfgBits['HardwareAddrEnable']       | \
                   basicCnfgBits['ActiveDriver']             | \
                   basicCnfgBits['IntActiveLevelLow']        | \
                   basicCnfgBits['Unimplemented']

# *** System Time Functions ***

def getTimeNowStr():
    timeNowStr = str(datetime.datetime.now())[0:16]
    return timeNowStr

# *** Generic I2C Device Register Functions ***

def readDvRegOneByte(i2cCh, dvAddrByte, DvRegAddrByte):
    readByte = i2cCh.read_byte_data(dvAddrByte, DvRegAddrByte)
    return readByte

def writeDvRegOneByte(i2cCh, dvAddrByte, DvRegAddrByte, writeByte):
    writeDvTwoBytes(i2cCh, dvAddrByte, DvRegAddrByte, writeByte)
    return

def writeDvTwoBytes(i2cCh, dvAddrByte, dataByte1, dataByte2):
    i2cCh.write_byte_data(dvAddrByte, dataByte1, dataByte2)
    return

def printDvRegOneByte(i2cCh, dvAddrByte, dvRegAddrByte, printTitle):
    readByte = readDvRegOneByte (i2cCh, dvAddrByte, dvRegAddrByte)
    print(printTitle, hex(readByte))

def writeDvRegOneBlock(i2cCh, dvAddrByte, dvRegAddrByte, writeBlock):
    i2cCh.write_block_data(dvAddrByte, dvRegAddrByte, writeBlock)
    return

# *** Specific I2C MCP23017 Device Register Functions ***

def readRegOneByte(regName):
    dvRegAddrByte = regAddrByte[regName]
    readByte = readDvRegOneByte(i2cCh, dvAddrByte, dvRegAddrByte)
    return readByte

def writeRegOneByte(regName, writeByte):
    dvRegAddrByte = regAddrByte[regName]
    writeDvRegOneByte(i2cCh, dvAddrByte, dvRegAddrByte, writeByte)
    return

def writeRegOneBlock(i2cCh, dvAddrByte, regName, writeBlock):
    dvRegAddrByte = regAddrByte[regName]    
    i2cCh.write_block_data(dvAddrByte, dvRegAddrByte, writeBlock)
    return

def printRegOneByte(regName, printTitle):
    readByte = readRegOneByte(regName)
    print(' ', printTitle, hex(readByte))
    return

# *** Test Functions ***

def testWriteReadPrintIoDirRegA(testDataByte):
    printRegOneByte('IODIRA', 'Old Byte =')
    writeRegOneByte('IODIRA', testDataByte)    
    printRegOneByte('IODIRA', 'New Byte =')
    return

def testWriteReadOneByteIoDirA():
    programTitle = 'testWriteReadPrintOneByteIoDirRegA'
    print('*** Begin', programTitle, ' ***\n')
    timeNowStr = getTimeNowStr()
    print('  Time     = ', timeNowStr, '***\n')
    dataByte0x55 = 0x55
    dataByte0xaa = 0xaa
    testWriteReadPrintIoDirRegA(dataByte0x55)
    testWriteReadPrintIoDirRegA(dataByte0xaa)
    print('\n')
    print('*** End  ', programTitle, ' ***\n')
    return

def testRepeatWriteOneBlock0x0f0x550xf0IoDirA():
    programTitle = 'testRepeatWriteBlock0x0f0x550xf0IoDirA'
    print('*** Begin', programTitle, ' ***\n')
    timeNowStr = getTimeNowStr()    
    print('  Time     = ', timeNowStr, '***\n')
    writeBlock = [0x0f, 0x55, 0xf0]
    print('  Writing block begin, ...')
    ioDirRegAddrByteA = regAddrByte['IODIRA']
    for count in range(500):
        writeRegOneBlock(i2cCh, dvAddrByte, 'IODIRA', writeBlock)
        time.sleep(0.01)
    print('  Writing block end.')
    print('\n')
    print('*** End  ', programTitle, ' ***\n')
    return

def testRepeatWriteOneBlock0xf00x0fGpioA():
    programTitle = 'testRepeatWriteBlock0xf00x0fGpioA'
    print('*** Begin', programTitle, ' ***\n')
    timeNowStr = getTimeNowStr()    
    print('  Time     = ', timeNowStr, '***\n')
    writeBlock = [0xf0, 0x0f]
    print('  Writing block begin, ...')
    ioDirRegAddrByteA = 0x00
    for count in range(500):
        writeRegOneBlock(i2cCh, dvAddrByte, 'IODIRA', writeBlock)
        time.sleep(0.01)
    print('  Writing block end.')
    print('\n')
    print('*** End  ', programTitle, ' ***\n')
    return

# *** Init ***

def configDv01():
    # *** Config MCP23017 no autoincrement of register address pointer ***
    configByte = basicCnfgBnk0NoMrrNoAutoIncActDrvIntHghAct
    writeRegOneByte('IOCON', configByte)
    # *** Config IO Direction Port A as all pint output ***
    ioConfigByteName = 'AllPinsOutput'
    ioConfigByte = controlByte[ioConfigByteName]
    writeRegOneByte('IODIRA', ioConfigByte)
    return    

i2cCh      = smbus.SMBus(1)
dvAddrByte = 0x22
configDv01()

# *** Test ***

def test():
    print('')
    testWriteReadOneByteIoDirA()
    #testRepeatWriteOneBlock0x0f0x550xf0IoDirA()
    testRepeatWriteOneBlock0xf00x0fGpioA()
    return
    
# *** Main ***

test()

# *** Sample Output ***

'''
========== RESTART: /home/pi/python_programs/test1094/iox01.004.py ==========

*** Begin testWriteReadPrintOneByteIoDirRegA  ***

  Time     =  2018-08-11 15:58 ***

  Old Byte = 0x0
  New Byte = 0x55
  Old Byte = 0x55
  New Byte = 0xaa


*** End   testWriteReadPrintOneByteIoDirRegA  ***

*** Begin testRepeatWriteBlock0xf00x0fGpioA  ***

  Time     =  2018-08-11 15:58 ***

  Writing block begin, ...
  Writing block end.


*** End   testRepeatWriteBlock0xf00x0fGpioA  ***

>>> 
'''

# *** End ***
Attachments
gGXoHJq[1].jpg
gGXoHJq[1].jpg (92.97 KiB) Viewed 110 times
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

Brandon92
Posts: 179
Joined: Wed Jul 25, 2018 9:29 pm
Location: Netherlands

Re: Relay Module KY-019 5V

Sat Aug 11, 2018 11:38 am

tlfong01 wrote:
Sat Aug 11, 2018 4:41 am
Some days ago when I was checking out why my I2C clocks always shows 100Khz, even I modified /boot/config.txt to set it to 400kHz. I found that if I used my scope probe to directly check/touch I2C Clk, I immediately got Rpi I2C transmission error message. I guessed my scope probe input impedance is too low, and so overloaded TSX04E's I2C CLK output.
I read something also about that, it should have worked. Did you restart you py after you change that. Or maybe you need to make a new topic about that problem.

Anyway, normally it should not make any different if you connect you scope probe to you circuit. Because you scope probe have probably a input resistance of 10M ohm and a capacitor of <16pF. And the input of the MCP* is 135pF. So, I think you wiring is to long. And did you twist the clock with a ground and the data with the ground?

If I had some time to spend I will look into the code.

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Sat Aug 11, 2018 12:34 pm

Brandon92 wrote:
Sat Aug 11, 2018 11:38 am
tlfong01 wrote:
Sat Aug 11, 2018 4:41 am
Some days ago when I was checking out why my I2C clocks always shows 100Khz, even I modified /boot/config.txt to set it to 400kHz.
I found that if I used my scope probe to directly check/touch I2C Clk, I immediately got Rpi I2C transmission error message. I guessed my scope probe input impedance is too low, and so overloaded TSX04E's I2C CLK output.
1. I read something also about that, it should have worked. Did you restart you py after you change that. Or maybe you need to make a new topic about that problem.
2. Anyway, normally it should not make any different if you connect you scope probe to you circuit. Because you scope probe have probably a input resistance of 10M ohm and a capacitor of <16pF. And the input of the MCP* is 135pF.
3. So, I think you wiring is to long.
4. And did you twist the clock with a ground and the data with the ground?
5. If I had some time to spend I will look into the code.

1. Well, @samtal started the I2C baud rate setting discussion a week ago, and concluded that software bit bang I2C is the only quick solution.

RASPBERRY PI3 I2C BAUD RATE SETTING Post by samtal » 2018-Aug-04
viewtopic.php?f=29&t=219675&p=1348886#p1348848

2. I only remember the probe resistance is 10M. I forgot the capacitance. I need to check my scope's user guide.

3. Yes, perhaps wire too long. I might try to make it shorter and do it again. You remind me that even my new program does not run OK every time. Perhaps only 5% runs to completion, without the "os error - bad transmission" message.

4. What do you mean by "twist the clock with a ground and the data with the ground?"
This is indeed hard to guess.

5. Ah, I forgot to show the main test function. I originally planned to show only the main test function and not the whole boring program. The complete program still needs more polishing, so not readable yet. Anyway, here is the main function. Just read the highlight part, don't bother to look into the boring details.

def test():
print('')
testWriteReadOneByteIoDirA()
#testRepeatWriteOneBlock0x0f0x550xf0IoDirA()
testRepeatWriteOneBlock0xf00x0fGpioA()
return

def testRepeatWriteOneBlock0xf00x0fGpioA():
programTitle = 'testRepeatWriteBlock0xf00x0fGpioA'
print('*** Begin', programTitle, ' ***\n')
timeNowStr = getTimeNowStr()
print(' Time = ', timeNowStr, '***\n')
writeBlock = [0xf0, 0x0f]
print(' Writing block begin, ...')
ioDirRegAddrByteA = 0x00
for count in range(500):
writeRegOneBlock(i2cCh, dvAddrByte, 'IODIRA', writeBlock) < bug!!!
time.sleep(0.01)
print(' Writing block end.')
print('\n')
print('*** End ', programTitle, ' ***\n')
return

def writeRegOneBlock(i2cCh, dvAddrByte, regName, writeBlock):
dvRegAddrByte = regAddrByte[regName]
i2cCh.write_block_data(dvAddrByte, dvRegAddrByte, writeBlock)
return
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

Brandon92
Posts: 179
Joined: Wed Jul 25, 2018 9:29 pm
Location: Netherlands

Re: Relay Module KY-019 5V

Sat Aug 11, 2018 12:51 pm

1. Okay.

3. Thats also a good indication that there is something wrong. how long are your wires.

4. I mean a cable like this. In that way the current return route is better. And your signal will become better. But I think you should use a extender. Like in my previous post.

User avatar
tlfong01
Posts: 310
Joined: Sat Jun 02, 2018 1:43 pm
Location: Hong Kong

Re: Relay Module KY-019 5V

Sat Aug 11, 2018 2:06 pm

tlfong01 wrote:
Sat Aug 11, 2018 12:34 pm
5. Ah, I forgot to show the main test function. I originally planned to show only the main test function and not the whole boring program. The complete program still needs more polishing, so not readable yet. Anyway, here is the main function. Just read the highlight part, don't bother to look into the boring details.

I found GpioA not working properly. So I switched to GpioB, and found it more or less OK. I found there is some interference between GpioA and GpioB. So I decided to test only GpioB. I also found me too ambitious to get the DHT22 Start Signal OK. I think I better go slowly.

Now I am doing something not so ambitious: toggle GpioB, use writeByte and writeBlock commands. They more or less work. I need to swap MCP23017 #1 with #2 or #3 to make 100% sure.

Here are the main functions, just in case you would like to look at the big picture. Don't bother the details.

Good night, see you tomorrow or Monday. Have a nice weekend.

Code: Select all

# *** Test GpioB ***

def testToggleOneByteGpioB():
    writeRegOneByte('IODIRA', controlByte['AllPinsInput'])
    writeRegOneByte('IODIRB', controlByte['AllPinsOutput'])
    programTitle = 'testToggleGpioB Byte'
    print('*** Begin', programTitle, ' ***\n')
    timeNowStr = getTimeNowStr()    
    print('  Time     = ', timeNowStr, '***\n')
    print('  Toggle GpioB Byte begin, ...')
    for count in range(4):
        writeRegOneByte('GPIOB', 0x00)
        print('    ', count, 'GpioB all pins Low  Now')
        time.sleep(1)
        writeRegOneByte('GPIOB', 0xff)
        print('    ', count, 'GpioB all pins High Now')        
        time.sleep(1)
    writeRegOneByte('GPIOB', 0x00)
    print('  Toggle GpioB Byte end.')
    print('\n')
    print('*** End  ', programTitle, ' ***\n')
    return

def testToggleOneBlockGpioB():
    writeRegOneByte('IODIRA', controlByte['AllPinsInput'])
    writeRegOneByte('IODIRB', controlByte['AllPinsOutput'])
    programTitle = 'testToggleGpioB Block'
    print('*** Begin', programTitle, ' ***\n')
    timeNowStr = getTimeNowStr()    
    print('  Time     = ', timeNowStr, '***\n')
    print('  Toggle GpioBA Block begin, ...')
    for count in range(4):
        writeRegOneBlock('GPIOB', [0x00, 0x00])
        print('    ', count, 'GpioB all pins Low  Now')
        time.sleep(1)
        writeRegOneBlock('GPIOB', [0xff, 0xff])
        print('    ', count, 'GpioA all pins High Now')        
        time.sleep(1)
    writeRegOneBlock('GPIOB', [0x00, 0x00])
    print('  Toggle GpioB Block end.')
    print('\n')
    print('*** End  ', programTitle, ' ***\n')
    return

# *** Init ***

def configDv01():
    # *** Config MCP23017 no autoincrement of register address pointer ***
    configByte = basicCnfgBnk0NoMrrNoAutoIncActDrvIntHghAct
    writeRegOneByte('IOCON', configByte)
    # *** Config IO Direction Port A, PortB all pins input ***
    writeRegOneByte('IODIRA', controlByte['AllPinsInput'])
    writeRegOneByte('IODIRB', controlByte['AllPinsInput'])
    return    

i2cCh = smbus.SMBus(1)
dvAddrByte = 0x22
configDv01()

# *** Test ***

def test():
    print('')
    testWriteReadOneByteIoDirA()
    testToggleOneByteGpioB()
    testToggleOneBlockGpioB()
    return
    
# *** Main ***

test()

# *** Sample Output ***

'''
*** Begin testWriteReadPrintOneByteIoDirRegA  ***

  Time     =  2018-08-11 21:49 ***

  Old Byte = 0xff
  New Byte = 0x55
  Old Byte = 0x55
  New Byte = 0xaa


*** End   testWriteReadPrintOneByteIoDirRegA  ***

*** Begin testToggleGpioB Byte  ***

  Time     =  2018-08-11 21:49 ***

  Toggle GpioB Byte begin, ...
     0 GpioB all pins Low  Now
     0 GpioB all pins High Now
     1 GpioB all pins Low  Now
     1 GpioB all pins High Now
     2 GpioB all pins Low  Now
     2 GpioB all pins High Now
     3 GpioB all pins Low  Now
     3 GpioB all pins High Now
  Toggle GpioB Byte end.


*** End   testToggleGpioB Byte  ***

*** Begin testToggleGpioB Block  ***

  Time     =  2018-08-11 21:49 ***

  Toggle GpioBA Block begin, ...
     0 GpioB all pins Low  Now
     0 GpioA all pins High Now
     1 GpioB all pins Low  Now
     1 GpioA all pins High Now
     2 GpioB all pins Low  Now
     2 GpioA all pins High Now
     3 GpioB all pins Low  Now
     3 GpioA all pins High Now
  Toggle GpioB Block end.


*** End   testToggleGpioB Block  ***
'''

# *** End ***
I am an electronics hobbyist. I started playing with relays some weeks ago. Me finding things so confusing. Google is my friend and makes me great again!

Return to “Automation, sensing and robotics”

Who is online

Users browsing this forum: No registered users and 6 guests