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

Re: Relay Module KY-019 5V

Sat Aug 11, 2018 2:28 pm

Brandon92 wrote:
Sat Aug 11, 2018 12:51 pm
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.

Ah, my I2C cables are 'only' about 2 meters long, three wires 'casually twisted' together, as shown in "A" of the picture below. I think I might only consider I2C extender when the wires are over 20 meters long.

Now I think I should not have twisted the ground wire and signal wires together. Ah, now I understand what you mean by 'twisting'!

Perhaps I should make the cable shorter and test again.

The cable you referred are 'twisted pair' cables. I always thought they are small guys, not important at all. I never thought I should pay any attention to them. Now I should think again. :shock:

Thanks for pointing out my carelessness.
Attachments
wnGoqn1[1].jpg
wnGoqn1[1].jpg (116.59 KiB) Viewed 1575 times
Last edited by tlfong01 on Sat Aug 11, 2018 3:09 pm, edited 1 time in total.
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Sat Aug 11, 2018 3:06 pm

tlfong01 wrote:
Sat Aug 11, 2018 12:34 pm
Brandon92 wrote:
Sat Aug 11, 2018 11:38 am
4. And did you twist the clock with a ground and the data with the ground?
4. What do you mean by "twist the clock with a ground and the data with the ground?" This is indeed hard to guess.

I said it was hard to guess what do you mean by twisting, because I have not read about the term 'twisted pair' for more than 10 years. In those days when everybody used Cat 5 cables, I heard the term twisted pair often. But now I used WiFi dongles, and now Rpi3 and RpiZeroW has Wifi. So I forgot Cat 5 altogether.

I remember I still have a couple of used Cat 5 cables. So I will try them later. I have colourful bright yellow and bright orange cables. I think even they are not proved that useful, I will still use them in my project, and display them in my project photos, to show off that I am knowledgeable in telecom things.

Appendix - Cat 5 Cables
https://en.wikipedia.org/wiki/Category_5_cable
Attachments
HmGELLv[1].jpg
HmGELLv[1].jpg (62.99 KiB) Viewed 1567 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Sat Aug 11, 2018 10:34 pm

tlfong01 wrote:
Sat Aug 11, 2018 2:28 pm
Ah, my I2C cables are 'only' about 2 meters long, three wires 'casually twisted' together, as shown in "A" of the picture below. I think I might only consider I2C extender when the wires are over 20 meters long.

Now I think I should not have twisted the ground wire and signal wires together. Ah, now I understand what you mean by 'twisting'!

Perhaps I should make the cable shorter and test again.

The cable you referred are 'twisted pair' cables. I always thought they are small guys, not important at all. I never thought I should pay any attention to them. Now I should think again. :shock:

Thanks for pointing out my carelessness.
Well. Two meter is already a lot. I successfully used with a cable of one meter. And your level shifter is designed for "driving" PCB traces. And not a large cable. So, I think you can forget about the 20 meter with a good reliability.
datasheet wrote:8.3.3 Output Load Considerations
TI recommends careful PCB layout practices with short PCB trace lengths to avoid excessive capacitive loading and to ensure that proper O.S. triggering takes place. PCB signal trace-lengths should be kept short enough such that the round trip delay of any reflection is less than the one-shot duration. This improves signal integrity by ensuring that any reflection sees a low impedance at the driver. The O.S. circuits have been designed to stay on for approximately 30 ns. The maximum capacitance of the lumped load that can be driven also depends directly on the one-shot duration. With very heavy capacitive loads, the one-shot can time-out before the signal is driven fully to the positive rail. The O.S. duration has been set to best optimize trade-offs between dynamic ICC, load driving capability, and maximum bit-rate considerations. Both PCB trace length and connectors add to the capacitance that the TXS0102 device output sees, so it is recommended that this lumped-load capacitance be considered to avoid O.S. retriggering, bus contention, output signal oscillations, or other adverse system-level affects.

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

Re: Relay Module KY-019 5V

Sun Aug 12, 2018 3:03 am

Brandon92 wrote:
Sat Aug 11, 2018 10:34 pm
tlfong01 wrote:
Sat Aug 11, 2018 2:28 pm
my I2C cables are 'only' about 2 meters long, ... I think I might only consider I2C extender when the wires are over 20 meters long.
Well. Two meter is already a lot. I successfully used with a cable of one meter. And your level shifter is designed for "driving" PCB traces. And not a large cable. So, I think you can forget about the 20 meter with a good reliability.
datasheet wrote:8.3.3 Output Load Considerations
TI recommends careful PCB layout practices with short PCB trace lengths to avoid excessive capacitive loading ...

Maximum I2C Bus Length

But I once read an ElectronicsStackExchange guy saying that he can do I2C 100 meters! :? Let me goggle what he says.

Maximum I2C Bus Length? - electronics.stackexchange.com
https://electronics.stackexchange.com/q ... bus-length

I work for a company making USB sensors. Most of them are based on I2C sensor chips, those devices can be split in two, so you can install the CPU part in one place and the sensor part in another. We conducted quite a lot of tests on the I2C connection between the device CPU and the I2C sensors. At 100 kHz, with a good error recovery protocol, 25m can be easily reached using basic wires. We were even able to reach 100m once with CAT5 cable. - martinm answered 2014apr12.
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Sun Aug 12, 2018 3:34 am

tlfong01 wrote:
Sat Aug 11, 2018 2:06 pm
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.

Trying to ask MCP23017 to send DHT22 Start Signal

Last evening I found intermittant, seemingly interference prolem when writing to GPIOA, so I swapped to GPIOB. Now I am thinking of also swapping between 3 MCP23017s and long/short I2C cables.

Therefore I have done some more function refactoring to make swapping things easy. Now the main test functions looks like this:

def test():
print('')
pretest()
testRepeatWriteGpioOneBlock('GPIOA', [0xff, 0x00, 0x00, 0xff],
........totalRepeatCount = 100, pauseMilliSeconds = 2)
testRepeatWriteGpioOneBlock('GPIOB', [0x00, 0x00, 0xff, 0xff],
........totalRepeatCount = 100, pauseMilliSeconds = 2)
return

My expected scope screen display is the following:

For block writing to GPIOA - 4 continuous, no time gap bytes 0xff, 0x00, 0x00, 0xff.
For block writing to GPIOA - 4 continuous, no time gap bytes 0x00, 0x00, 0xff, 0xff

I have listed the minimal, complete, verifiable, no problem, example below. Again, don't bother to read the details now, because the whole program still needs more polishing. Perhaps just skimmed through to get a rough picture.

Code: Select all

# iox01.1097 tlfong01 2018aug12hkt1038

# *** 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

# *** 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 writeGpioOneBlock(gpioName, writeBlock):
    dvRegAddrByte = regAddrByte[gpioName]    
    writeDvRegOneBlock(i2cCh, dvAddrByte, dvRegAddrByte, writeBlock)
    return

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

# *** Config ***

deviceAddressByteDict = \
    {
        'MCP23017 #1' : 0x22,
        'MCP23017 #2' : 0x21,
        'MCP23017 #3' : 0x23,
    }

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

configByteDict = {'NoAutomaticRegisterPointerIncrement': basicCnfgBnk0NoMrrNoAutoIncActDrvIntHghAct}

def configDevice(configByteName):
    writeRegOneByte('IOCON', configByteDict[configByteName])
    return


# *** Test Functions ***

def testWriteReadPrintOneByteIoDirA():
    def writeReadPrintRegOneByte(regName, writeByte):
        printRegOneByte('IODIRA', 'Old Byte =')
        writeRegOneByte('IODIRA', writeByte)    
        printRegOneByte('IODIRA', 'New Byte =')
        return

    programTitle = 'testWriteReadPrintOneByteIoDirRegA'
    print('*** Begin', programTitle, ' ***\n')
    timeNowStr = getTimeNowStr()
    print('  Time     = ', timeNowStr, '***\n')
    writeReadPrintRegOneByte('IODIRA', 0x55)
    writeReadPrintRegOneByte('IODIRA', 0x77)
    print('\n*** End  ', programTitle, ' ***\n')
    return

def testRepeatWriteGpioOneBlock(gpioName, writeBlock, totalRepeatCount, pauseMilliSeconds):
    programTitle = 'testRepeatWriteGpioOneBlock'
    print('*** Begin', programTitle, ' ***\n')
    print('  Time     = ', getTimeNowStr(), '***\n')
    print('  Begin write block', gpioName, ',...')
    for count in range(totalRepeatCount):
        writeGpioOneBlock(gpioName, writeBlock)
        time.sleep(pauseMilliSeconds / 1000)
    print('  End   write block', gpioName, '. \n')
    print('*** End  ', programTitle, ' ***\n')
    return

# Notes:
# total repeat count > 100 usually gets the following error message:
#   "OSError: [Errno 121] Remote I/O error"

# *** Init ***

i2cCh = smbus.SMBus(1)
dvAddrByte = deviceAddressByteDict['MCP23017 #1']

configDevice('NoAutomaticRegisterPointerIncrement')
pretest = testWriteReadPrintOneByteIoDirA

# *** Test ***

def test():
    print('')
    pretest()
    testRepeatWriteGpioOneBlock('GPIOA', [0xff, 0x00, 0x00, 0xff], totalRepeatCount = 100, pauseMilliSeconds = 2)
    testRepeatWriteGpioOneBlock('GPIOB', [0x00, 0x00, 0xff, 0xff], totalRepeatCount = 100, pauseMilliSeconds = 2)
    return
    
# *** Main ***

test()

# *** Sample Output ***

'''
*** Begin testWriteReadPrintOneByteIoDirRegA  ***

  Time     =  2018-08-12 10:38 ***

  Old Byte = 0x77
  New Byte = 0x55
  Old Byte = 0x55
  New Byte = 0x77

*** End   testWriteReadPrintOneByteIoDirRegA  ***

*** Begin testRepeatWriteGpioOneBlock  ***

  Time     =  2018-08-12 10:38 ***

  Begin write block GPIOA ,...
  End   write block GPIOA . 

*** End   testRepeatWriteGpioOneBlock  ***

*** Begin testRepeatWriteGpioOneBlock  ***

  Time     =  2018-08-12 10:38 ***

  Begin write block GPIOB ,...
  End   write block GPIOB . 

*** End   testRepeatWriteGpioOneBlock  ***
'''

# *** End ***
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Sun Aug 12, 2018 4:44 am

tlfong01 wrote:
Sun Aug 12, 2018 3:34 am
def test():
testRepeatWriteGpioOneBlock('GPIOA', [0xff, 0x00, 0x00, 0xff], 100000, 4)
testRepeatWriteGpioOneBlock('GPIOB', [0x00, 0x00, 0xff, 0xff], 100000, 4)
return

My expected scope screen display is the following:

For block writing to GPIOA - 4 continuous, no time gap bytes 0xff, 0x00, 0x00, 0xff.
For block writing to GPIOA - 4 continuous, no time gap bytes 0x00, 0x00, 0xff, 0xff

Trying to ask MCP23017 to send DHT22 Start Signal

I changed the repeat loop pauseMilliSeconds from 2 to 4, the intermittant transmission error messages disappeared! :D
Attachments
zxAXrte[1].jpg
zxAXrte[1].jpg (114.47 KiB) Viewed 1518 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Sun Aug 12, 2018 8:00 am

tlfong01 wrote:
Sun Aug 12, 2018 4:44 am
I changed the repeat loop pauseMilliSeconds from 2 to 4, the intermittant transmission error messages disappeared! :D

Trying to ask MCP23017 to send DHT22 Start Signal

I was wrong. :( The i2c transmission error messages reappeared. I need to modify the test program to make it easier to change the between-write-block-milliseconds.

The test program now becomes very high level and therefore reader and tester friendly.

def test():
testHighLowLowHighSignal()
testLowLowHighHighSignal()
return

def testHighLowLowHighSignal():
print('>>>> testHighLowLowHighSignal <<<<<<<<<<<<')
testRepeatWriteGpioOneBlock \
(
'OLATB', \
['AllBitHigh', 'AllBitLow', 'AllBitLow', 'AllBitHigh'],
'RepeatTwoThousandTimes',
'PauseFourMilliSeconds'
)

def testLowLowHighHighSignal():
print('>>>> testLowLowHighHighSignal <<<<<<<<<<<<')
testRepeatWriteGpioOneBlock \
(
'OLATB', \
['AllBitLow', 'AllBitLow', 'AllBitHigh', 'AllBitHigh'],
'RepeatTwoThousandTimes',
'PauseFourMilliSeconds'
)

I attach the complete list of the 350 lines long the MCVNE program. Again, it is not that reader friendly and need more polishing.

Next post I will show some more test results.

Code: Select all

# iox01.1098 tlfong01 2018aug12hkt1544

# *** 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,     
    }

loopNumTime = \
    {
        'PauseTwoMilliSeconds'                      : 2,
        'PauseFourMilliSeconds'                     : 4,
        'PauseFiveMillliSeconds'                    : 5,
        'RepeatOneThousandTimes'                    : 1000,
        'RepeatTwoThousandTimes'                    : 2000,
        'RepeatThreeThousandTimes'                  : 3000,
        'RepeatFiveThousandTimes'                   : 5000,
        'RepeatTenThousandTimes'                    : 100000,
        'RepeatOneHundredThousandTimes'             : 100000,
    }

dataByte = \
    {
        'AllBitHigh'                                : 0xff,
        'AllBitLow'                                 : 0x00,
        'FourBitLowFourBitHigh'                     : 0x0f,
        'FourBitHighFourBitLow'                     : 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

# *** 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 writeGpioOneBlock(gpioName, writeBlock):
    dvRegAddrByte = regAddrByte[gpioName]    
    writeDvRegOneBlock(i2cCh, dvAddrByte, dvRegAddrByte, writeBlock)
    return

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

# *** Config ***

deviceAddressByteDict = \
    {
        'MCP23017 #1' : 0x22,
        'MCP23017 #2' : 0x21,
        'MCP23017 #3' : 0x23,
    }

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

configByteDict = {'NoAutomaticRegisterPointerIncrement': basicCnfgBnk0NoMrrNoAutoIncActDrvIntHghAct}

def configDevice(configByteName):
    writeRegOneByte('IOCON', configByteDict[configByteName])
    return


# *** Test Functions ***

def testWriteReadPrintOneByteIoDirA():
    def writeReadPrintRegOneByte(regName, writeByte):
        printRegOneByte('IODIRA', 'Old Byte =')
        writeRegOneByte('IODIRA', writeByte)    
        printRegOneByte('IODIRA', 'New Byte =')
        return
    programTitle = 'testWriteReadPrintOneByteIoDirRegA'
    print('*** Begin', programTitle, ' ***\n')
    timeNowStr = getTimeNowStr()
    print('  Time     = ', timeNowStr, '***\n')
    writeReadPrintRegOneByte('IODIRA', 0x55)
    writeReadPrintRegOneByte('IODIRA', 0x77)
    print('\n*** End  ', programTitle, ' ***\n')
    return

def testRepeatWriteGpioOneBlock(gpioName, byteNameList, repeatTimesName, pauseMilliSecondsName):
    programTitle = 'testRepeatWriteGpioOneBlock'
    print('*** Begin', programTitle, ' ***\n')
    writeRegOneByte(gpioName, controlByte['AllPinsOutput'])
    print('  Time     = ', getTimeNowStr(), '***\n')
    print('  Begin write block', gpioName, ',...')
    writeBlock = genWriteBlock(byteNameList) 
    for count in range(loopNumTime[repeatTimesName]):
        writeGpioOneBlock(gpioName, writeBlock)
        time.sleep(loopNumTime[pauseMilliSecondsName] / 1000)
    print('  End   write block', gpioName, '. \n')
    print('*** End  ', programTitle, ' ***\n')
    return

# Notes:
# total repeat count > 100 usually gets the following error message:
#   "OSError: [Errno 121] Remote I/O error"
# update 2018aug12hkt1208: setting pauseMilliSeconds to 5 seems solving the problem.

# *** Init ***

i2cCh = smbus.SMBus(1)
dvAddrByte = deviceAddressByteDict['MCP23017 #1']

configDevice('NoAutomaticRegisterPointerIncrement')
pretest = testWriteReadPrintOneByteIoDirA

# *** Test ***

def genWriteBlock(byteNameList):
    writeBlock = []
    for byteName in byteNameList:
         writeBlock.append(dataByte[byteName])
    return writeBlock

def testHighLowLowHighSignal():
    print('>>>> testHighLowLowHighSignal <<<<<<<<<<<<')
    testRepeatWriteGpioOneBlock \
        (
            'OLATB', \
             ['AllBitHigh', 'AllBitLow', 'AllBitLow', 'AllBitHigh'],
             'RepeatTwoThousandTimes',
             'PauseFourMilliSeconds'
        )

def testLowLowHighHighSignal():
    print('>>>> testLowLowHighHighSignal <<<<<<<<<<<<')
    testRepeatWriteGpioOneBlock \
        (
            'OLATB', \
             ['AllBitLow', 'AllBitLow', 'AllBitHigh', 'AllBitHigh'],
             'RepeatTwoThousandTimes',
             'PauseFourMilliSeconds'
        )

def test():
    testHighLowLowHighSignal()
    testLowLowHighHighSignal()
    return
    
# *** Main ***

test()

# *** Sample Output ***

'''
========== RESTART: /home/pi/python_programs/test1097/iox01.004.py ==========
>>>> testHighLowLowHighSignal <<<<<<<<<<<<
*** Begin testRepeatWriteGpioOneBlock  ***

  Time     =  2018-08-12 15:44 ***

  Begin write block OLATB ,...
  End   write block OLATB . 

*** End   testRepeatWriteGpioOneBlock  ***

>>>> testLowLowHighHighSignal <<<<<<<<<<<<
*** Begin testRepeatWriteGpioOneBlock  ***

  Time     =  2018-08-12 15:45 ***

  Begin write block OLATB ,...
  End   write block OLATB . 

*** End   testRepeatWriteGpioOneBlock  ***

>>>  
'''

# *** End ***

I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Sun Aug 12, 2018 8:20 am

tlfong01 wrote:
Sun Aug 12, 2018 8:00 am
def test():
testHighLowLowHighSignal()
testLowLowHighHighSignal()

def testHighLowLowHighSignal():
['AllBitHigh', 'AllBitLow', 'AllBitLow', 'AllBitHigh'],

def testLowLowHighHighSignal():
['AllBitLow', 'AllBitLow', 'AllBitHigh', 'AllBitHigh'],

Trying to ask MCP23017 to send DHT22 Start Signal

Now the results of the two test functions.

Next post is the real thing - DHT22 Start Signal! :)
Attachments
WAKFG3I[1].jpg
WAKFG3I[1].jpg (108.06 KiB) Viewed 1492 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Sun Aug 12, 2018 8:29 am

tlfong01 wrote:
Sun Aug 12, 2018 8:20 am
Next post is the real thing - DHT22 Start Signal! :)

Trying to ask MCP23017 to send DHT22 Start Signal

I forgot how the real thing should look like, so I searched my image box of imgur.com.

The start signal should be

typical 1mS, max 20mS low, typical 30uS, max 200 uS high.
Attachments
WrqGXEu[1].jpg
WrqGXEu[1].jpg (77.26 KiB) Viewed 1484 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Sun Aug 12, 2018 9:12 am

tlfong01 wrote:
Sun Aug 12, 2018 8:29 am
The start signal should be
typical 1mS, max 20mS low, typical 30uS, max 200 uS high.

MCP23017 generated DHT22 Start Signal testing notes

This function generating the DHT22 Start Signal is listed below:

# iox01.1100 tlfong01 2018aug12hkt16444
def testDht22StartSignal():
print('>>>> testDht22StartSignal <<<<<<<<<<<<')
testRepeatWriteGpioOneBlock \
(
'OLATB', \
[
'AllBitLow', 'AllBitLow', 'AllBitLow', 'AllBitLow', \
'AllBitLow', 'AllBitLow', 'AllBitLow', 'AllBitLow', \
'AllBitHigh', 'AllBitHigh', \
'AllBitLow', 'AllBitLow', 'AllBitLow', 'AllBitHigh'
, \

],
'RepeatOneThousandTimes',
'PauseFourMilliSeconds'
)

And the results is as attached.

I expected all 8 pins of GPIOB should have 8 Lows, followed by 2 Highs, then 4 Lows.

However, only GPIOA pin 4 and pin 7 shows the output below. All other pins are either all high or all low.

I guess there is a bug in my MCP23017 hardware wiring. But I did checked it with a blink test. Perhaps I need to do the blink test again.
Attachments
j2CL9Ez[1].jpg
j2CL9Ez[1].jpg (78.22 KiB) Viewed 1478 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Sun Aug 12, 2018 12:15 pm

DTH22 protocal
Well, I think that your mcp only need to drive the singal low, and after that the output can be changed into a input. And the DHT22 will give that short pulse.
Brandon92 wrote:
Wed Aug 08, 2018 4:25 pm
I was reading a little bit in the datasheet of the DH22. But I think the pi only need to deliver the start signal. And the rest is done by the sensor:
DHT22 protocol.PNG

My other concern is this:
DHT22 protocol read data.PNG

When the bit is low, its only 28uS high. And you need also get that one. ...
I2C cable
tlfong01 wrote:
Sun Aug 12, 2018 3:03 am
But I once read an ElectronicsStackExchange guy saying that he can do I2C 100 meters! :? Let me goggle what he says.

Maximum I2C Bus Length? - electronics.stackexchange.com
https://electronics.stackexchange.com/q ... bus-length

I work for a company making USB sensors. Most of them are based on I2C sensor chips, those devices can be split in two, so you can install the CPU part in one place and the sensor part in another. We conducted quite a lot of tests on the I2C connection between the device CPU and the I2C sensors. At 100 kHz, with a good error recovery protocol, 25m can be easily reached using basic wires. We were even able to reach 100m once with CAT5 cable. - martinm answered 2014apr12.
But, the problem with you is that you are using a level shifter and he can't drive that length of a cable. The prove is in that when you connect a scope probe to the bus, you signal is dead. And that's normally not a problem.

I2C testing
I think you need to go a couple steps back. Al least in the hardware side. I think you should remove the level shifter. And connect the MCP directly to you pi at a voltage of 3.3V with a short connection. Than you can see if there is a software problem or the level shifter is the problem. Also because the signals at you scope contains a lot of noise.

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

Re: Relay Module KY-019 5V

Sun Aug 12, 2018 1:34 pm

Brandon92 wrote:
Sun Aug 12, 2018 12:15 pm
DTH22 protocal
Well, I think that your mcp only need to drive the singal low, and after that the output can be changed into a input. And the DHT22 will give that short pulse.

DTH22 protocal

I agree, now I am calculating how short is the DHT22 short pulse (40 data bits). It should be:

bigger((55 + 30) , (55 + 75)) * 40
= (55 + 75) * 40
= 5200 uS
= 5.2 mS
== 10 mS

So rpi should do a loop something like this:

  • 1. mcp sends a start signal
  • 2. mcp sets gpio pin to input
  • 3. pauses 10 mS (scope to check if dht sends out 40 data bits)
I already removed the problematic hc04, and the 2 meter long i2c wires from txs40e to hc04, and see how it goes.

Worst case is go back step by step, until the bare Rpi3B :(
Attachments
lT6b3EI[1].jpg
lT6b3EI[1].jpg (101.86 KiB) Viewed 1446 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Sun Aug 12, 2018 2:31 pm

tlfong01 wrote:
Sun Aug 12, 2018 1:34 pm
Worst case is go back step by step, until the bare Rpi3B :(
I would start here. Than you have less variables. And easier to troubleshoot.
If that's is working like a charm. Than you can go back to the old situation. If that's not working. You know that the software is okay. And the problem is in the hardware.

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

Re: Relay Module KY-019 5V

Mon Aug 13, 2018 1:37 am

Brandon92 wrote:
Sun Aug 12, 2018 12:15 pm
But, the problem with you is that you are using a level shifter and he can't drive that length of a cable. The prove is in that when you connect a scope probe to the bus, you signal is dead. And that's normally not a problem.

TSX0102 / TSX0104 / TSX0108 Level Shifter Problem

I agree. So I need to read the level shifter datasheet once more.

Study notes and ideas

  • 1. Multiple masters configuration
  • 2. TXS0104E has internal 10K pull up resistors, OE control signal on 3V3 side
  • 3. Why NACK
Appendices - I2C References

Level shifting techniques in I2C-bus design - NXP Application note AN10441 2007jun18
https://www.nxp.com/docs/en/application ... N10441.pdf

Understanding the I2C Bus - TI Application Report SLVA704 – 2015jun
http://www.ti.com/lit/an/slva704/slva704.pdf

I2C Bus Pullup Resistor Calculation - TI Application Report SLVA689 – 2015feb
http://www.ti.com/lit/an/slva689/slva689.pdf

TXS0104E 4-Bit Bidirectional Voltage-Level Translator for Open-Drain and Push-Pull -
Applications - TI SCES651H 2018may

http://www.ti.com/lit/ds/symlink/txs0104e.pdf
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Mon Aug 13, 2018 4:24 am

Brandon92 wrote:
Sun Aug 12, 2018 2:31 pm
tlfong01 wrote:
Sun Aug 12, 2018 1:34 pm
Worst case is go back step by step, until the bare Rpi3B :(
1. I would start here. Than you have less variables. And easier to troubleshoot.
If that's is working like a charm. Than you can go back to the old situation. If that's not working.
2.You know that the software is okay. And the problem is in the hardware.

Practising Python Programming and Learning IOX MCP23017

1. I agree it is easy to debug from bare Rpi, adding hardware and software bit by bit. Now I am thinking of keeping the current Rpi hardware and software no change, and start with a fresh new Rpi, and TXS0104, MCP23017 and incrementally retest everything.

2. Well, the software is not OK. I am doing this project with one objective of practising python in general, and MCP23xYY specific. Now I am modifying the functions to make easier to repeat testing, and swapping MCP23017s.

My MCP23017/DHT22 program works more or less, but there are a lot of imporvement I should make. For example, after the frequent I2C transmission error, the program terminates. I need to learn how to use try/except to continue program after error. This try/except thing seems good for my case. I did not use it before because I was too lazy, and also I did not have any program that gets error message and unexpectedly stops so often.

Why I 'waste time' writing my own python code and not drivers and libraries

You once commented that it might be a waste of time doing python coding myself, and why not save time by using third party packages or libraries, such as pipgio. I did google around for mcp23017, ds3231, and dht22 libraries and example programs. But I found studying other programmer's programs and modifying them to adapt my requirements is often very time consuming. It often saves my time if I am doing many projects at the same time, building up common functions and modules that can be shared by other project modules. Though I don't use other programmer's codes, but I often study their ways of doing things, but I usually think about it myself, and then compared my way with their way. Usually other professional programmer's code are very clever, and time and space efficient. But what I like is forgetful newbie friendly. If I write easy to read, though slow running programs myself, I will remember them well, and reuse the function better, ...

One other reason is that many example programs I found are C++ object oriented. I prefer python and only functional programm style of python for many reasons. It is a bit messy to translate C++ OO code into python functional programming style.

I am just thinking aloud, typing while thinking. My apologies for typos unstructured paragraphs and phrases.

Python Rererences

List of 10 Best Programming Languages to Learn in 2018 A ranking based one the number of job advertisements and the amount of salaries paid - Vicky Singh Rao 2018aug13
https://www.technotification.com/2018/0 ... -2018.html

A ranking based one the number of job advertisements and the amount of salaries paid

DHT11/22 References

RE: DTOVERLAY=DHT11? post by joan » 2018-Aug-12 Sun 5:11 am
viewtopic.php?f=29&t=220213#p1351876
http://abyz.me.uk/rpi/pigpio/examples.html#pdif2_DHTXXD

DHT series Temperature & Humidity sensor on Arduino - Tutorial
https://roboindia.com/tutorials/DHT-sensor-arduino
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Mon Aug 13, 2018 9:33 am

tlfong01 wrote:
Mon Aug 13, 2018 1:37 am
Brandon92 wrote:
Sun Aug 12, 2018 12:15 pm
But, the problem with you is that you are using a level shifter and he can't drive that length of a cable. The prove is in that when you connect a scope probe to the bus, you signal is dead. And that's normally not a problem.

TI TXS010x Level Shifter Studying Notes

OK. I agree my level shifter has a problem, and I don't know why. I am feeling small. So I asked my friend Google who will for sure makes me great again.

Appendix - TI TXS010x References

A Guide to Voltage Translation With TXS-Type Translators - Application Report SCEA044 – 2010jun
http://www.ti.com/lit/an/scea044/scea044.pdf

Effects of External Pullup and Pulldown Resistors on TXS and TXB Devices - SCEA054A – 2018mar
http://www.ti.com/lit/an/scea054a/scea054a.pdf

TXS0108E 8-Bit Bi-directional, Level-Shifting, Voltage Translator for Open-Drain and Push-Pull Applications TXS0108E SCES642E – 2018feb
http://www.ti.com/lit/ds/symlink/txs0108e.pdf

TXS0104E 4-Bit Bidirectional Voltage-Level Translator for Open-Drain and Push-Pull Applications - SCES651H – 2018may
http://www.ti.com/lit/ds/symlink/txs0104e.pdf

Introduction to Logic - Application Report SLVA700 – 2015apr
http://www.ti.com/lit/an/slva700/slva700.pdf
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Mon Aug 13, 2018 1:58 pm

Brandon92 wrote:
Sun Aug 12, 2018 12:15 pm
But, the problem with you is that you are using a level shifter and he can't drive that length of a cable. The prove is in that when you connect a scope probe to the bus, you signal is dead. And that's normally not a problem.
The more I google, the more I agree with you. :)

RE: MAXIMUM CABLE LENGTH I2C WITH TWISTED PAIR? Post by Richard-TX » 2014jul18
viewtopic.php?t=82049#p580616

Sending I2C-bus signals via long communications cables - Application note AN10658
2008feb

https://www.nxp.com/docs/en/application ... N10658.pdf

P82B715 I2C-bus extender - NXP 2009nov
https://www.nxp.com/docs/en/data-sheet/P82B715.pdf

P82B715 I2C Bus Extender - TI 2016feb
http://www.ti.com/lit/ds/symlink/p82b715.pdf
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Mon Aug 13, 2018 2:53 pm

Brandon92 wrote:
Fri Aug 10, 2018 7:53 pm
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

Many thanks for your advice and recommendation. So I have ordered 20 pieces of P82B715 (DIP8) from TaoBao, at RMB 8 each. SF Express delivery usually takes less than 2 days.

BTW, I mentioned I read people saying they are do I2C up to 100 meters, I think they all use I2C extenders plus twisted pair cables. I also read other people saying that they can only do I2C for only 6 inches to 20 inches. Some of them say that it depends on IC to IC. So I agree with you that less than 20 inches for no I2C extenders.
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Mon Aug 13, 2018 4:29 pm

tlfong01 wrote:
Mon Aug 13, 2018 2:53 pm
Many thanks for your advice and recommendation. So I have ordered 20 pieces of P82B715 (DIP8) from TaoBao, at RMB 8 each. SF Express delivery usually takes less than 2 days.

BTW, I mentioned I read people saying they are do I2C up to 100 meters, I think they all use I2C extenders plus twisted pair cables. I also read other people saying that they can only do I2C for only 6 inches to 20 inches. Some of them say that it depends on IC to IC. So I agree with you that less than 20 inches for no I2C extenders.
Good to hear that you are making progress and do a research about what I'm saying :). To be fare, I have used this schematic successfully with a ribbon cable for 1meter. But, this was a communication bus between two microcontrollers (atmel).
tlfong01 wrote: --
3. Why NACK[/list]
--
The (N)ACK is a important part of the I2C protocol.

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

Re: Relay Module KY-019 5V

Wed Aug 15, 2018 3:23 am

Brandon92 wrote:
Mon Aug 13, 2018 4:29 pm
tlfong01 wrote:
Mon Aug 13, 2018 2:53 pm
BTW, I mentioned I read people saying they can do I2C up to 100 meters, .... I also read other people saying that they can do I2C for only 6 inches to 20 inches. Some of them say that it depends on IC.
... I have used this schematic successfully with a ribbon cable for 1meter. But, this was a communication bus between two microcontrollers (atmel).

Ribbon vs UTP vs GKT cable

Your I2C with ribbon cable should look pretty. You might like to take a look of my work using the same circuit. I used 2N7000 instead of your BSS138, and GKT instead of ribbon.

RE: FAVORITE REPLACEMENT FOR 8-CHANNEL BI-DIRECTIONAL LOGIC LEVEL CONVERTER - TXB0108 tlfong01 2018aug14
viewtopic.php?f=44&t=217340#p1352588

I think my GKT should be as good as UTP. I did the following test to prove my hypothesis.

  • 1. Use a 15cm long gkt cable to connect Rpi3B 3V3 I2C SCL SDA to TXS0104E's two inputs. (A)
  • 2. Use 15cm long gkt to connect one TXS0104E 5V0 SCL SDA output to RTC DS3231.(B)
  • 3. Use 15cm long gkt to connect another TXS0104E 5V0 SCL SDA output to IOX MCP23017. (C)
  • 4. Use $ i2cdetect -y 1 to detect IOX x 3 (0x21, 0x22, 0x23), and EEPROM, RTC (0x57, 0x68).
  • 5. Use my little python function to ping IOX at sub address 0x22 (write, read, print IODIRA).
  • 6. Tests 4, 5 make sure that short, <30cm gkt cables are doing their job OK
  • 7. Then I used long 1 meter gkt cable, inserting at points before A, and at B, and C, to check any bad effects of 2 meters long gkt cables.
  • 8. I found i2cdetect and my ping functions working OK.
  • 9. This proves that 2 meter long i2c gkt cables are ok. :)
Attachments
VwiB144[1].jpg
VwiB144[1].jpg (117.17 KiB) Viewed 1295 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Wed Aug 15, 2018 7:47 am

tlfong01 wrote:
Wed Aug 15, 2018 3:23 am
I think my GKT should be as good as UTP. I did the following test to prove my hypothesis. ...
  • 8. I found i2cdetect and my ping functions working OK.
  • 9. This proves that 2 meter long i2c gkt cables are ok. :)

Now that I don't worry anymore about my long I2C cables, I am moving on to test the MCP23017 controlling DHT22. But the other sensor HDC1080 also arrived, so now I have 12 sensors to test:

  • 1. RTC DS3231 temperature sensor x 4,
  • 2. DHT22 humidity and temperature sensor x 4, and
  • 3. HDC1080 humidity and temperature sensor x 4.

I wired up one HDC1080 and i2cdetect -y 1 found its address 0x40 without any problem.
Attachments
L8PTj2j[1].jpg
L8PTj2j[1].jpg (93.01 KiB) Viewed 1279 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Wed Aug 15, 2018 8:00 am

tlfong01 wrote:
Wed Aug 15, 2018 7:47 am
But the other sensor HDC1080 also arrived, so now I have 12 sensors to test:
I wired up one HDC1080 and i2cdetect -y 1 found its address 0x40 without any problem.

I read again the HDC1080 datasheet, and found their application circuit interesting. I like the manual things like 4 buttons and one LCD/LED display. I think I should also use buttons and display in my project.
Attachments
tzQ6CPL[1].jpg
tzQ6CPL[1].jpg (88.06 KiB) Viewed 1274 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Wed Aug 15, 2018 8:10 am

tlfong01 wrote:
Wed Aug 15, 2018 8:00 am
I read again the HDC1080 datasheet, and found their application circuit interesting. I like the manual things like 4 buttons and one LCD/LED display. I think I should also use buttons and display in my project.
HDC1080 studying notes

Now I am reading the registers and data format.

https://i.imgur.com/fjbML1i.jpg
Attachments
fjbML1i[1].jpg
fjbML1i[1].jpg (118.19 KiB) Viewed 1272 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Wed Aug 15, 2018 1:07 pm

tlfong01 wrote:
Wed Aug 15, 2018 8:10 am
HDC1080 - Now I am reading the registers and data format.

HDC1080 Summary Notes for Programming 1/2
Attachments
GzC1Hjj[1].jpg
GzC1Hjj[1].jpg (194.01 KiB) Viewed 1259 times
I am an electronics and smart home hobbyist.

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

Re: Relay Module KY-019 5V

Wed Aug 15, 2018 1:11 pm

tlfong01 wrote:
Wed Aug 15, 2018 1:07 pm
HDC1080 Summary Notes for Programming 1/2

HDC1080 Summary Notes for Programming 2/2
Attachments
DJCnMdp[1].jpg
DJCnMdp[1].jpg (130.12 KiB) Viewed 1259 times
I am an electronics and smart home hobbyist.

Return to “Automation, sensing and robotics”