Hello again! The wiring is one issue (can't say for sure if it works with the expansion per se cause I have another breakout of the chip for testing purposes). Though, you can easily adapt this example -> https://www.element14.com/community/community/raspberry-pi/blog/2012/12/14/nfc-on-raspberrypi-with-pn532-py532lib-and-i2c and use I2C. Lastly, there is no official documentation regarding the schematics of the NFC/RFID expansion but our tests showed that that onion has left out SPI/I2C support for their chip -sth that needs to be checked. We are using python tools for now but I will get back to you if we find anything else!

Thank you for such an excellent reply. It points me in the right direction. We may be doing a custom U-Boot and kernel build anyhow. I am starting to become fond of this platform. I just picked up the Omega2S a couple weeks ago for the first time and had the streaming USB UVC video working on day one over Wifi.

I cant find a library , every one sends bit value to control the pins , not that practical if i need to read and write from all the pins a a lot

If you installed node-red-contrib-bme280 in the config window just change bus# to 0 and it should work. I noticed that i have to reboot each time a new node is installed to see it or make it work.

Serial.println() inside requestEvent() always fails, even with NUL str, Serial.println(""). root@Omega-745F:~# i2cdump -y -r 0x30-0x32 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: 0c XX 0c ?X? where as Serial.println() inside receiveEvent() can print one or two characters, for eg, void receiveEvent() { reg = Wire.read(); Serial.println(reg, HEX); } to a certain volume of data. root@Omega-745F:~# i2cdump -y -r 0x30-0x32 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: 30 31 32 012 root@Omega-745F:~# i2cdump -y -r 0x30-0x3F 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? root@Omega-745F:~# i2cdump -y -r 0x40-0x4F 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO root@Omega-745F:~# i2cdump -y -r 0x30-0x41 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: XX 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f X123456789:;<=>? 40: 40 41 @A If there is more data, it fails.. root@Omega-745F:~# i2cdump -y -r 0x30-0x45 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: XX 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f X123456789:;<=>? 40: 40 41 42 00 00 00 @AB... root@Omega-745F:~# i2cdump -y -r 0x30-0x4F 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? 40: 40 41 00 00 00 00 02 XX 00 00 00 00 00 00 00 24 @A....?X.......$ It fails every time if a long str such as "Hello, World!" is to be printed, even inside receiveEvent(). It is not a problem associated with ARD Dock; I am not using ARD Dock at all.. Thanks..

@Modest-Polykarpovich I tried but the device did not appear in /dev/ echo rtc_m41t80 0x68 > /sys/class/i2c-dev/i2c-0/device/new_device dmesg show [ 152.302693] i2c i2c-0: new_device: Instantiated device rtc_m41t80 at 0x68 root@Omega-61B6:/# lsmod | grep 41t8 rtc_m41t80 8704 0 root@Omega-61B6:/# i2cdump -y -f -r 0-6 0 0x68 c 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 00 ff ff 7f 07 3f 1f ...????

@Decagrog the shipping cost to Oz would exceed 20 Euros, otherwise I would purchase.

Yes, those work perfectly and are used to determine the device is there. But there is no way to read the actual range data without a lot of i2c back-and-forth with their custom protocol. There are python libraries to handle this, but none of them work on the Omega (yet)

@jose-r You don't have to do anything with an Onion ADC Expansion Board: the power supply voltage of the ADS1115 is 5V each I2C bus line has a usual 5V-to-3.3V MOS-FET bidirectional logic level shifter

I hadn't finished and it submitted somehow. The Python code is: bytes = [0xAA, 0, 0] try: i2c.write(0x18, bytes) except: print "write failed" time.sleep(0.01) y0 = i2c.read(0x18,4) print y0 This returns a status byte, but zeros for the pressure data. The i2c waveforms which I captured from an oscilloscope look different enough to matter. Can I upload them here somehow? The command bytes to read the pressure [0xAA, 0x00, 0x00} for Arduino and Onion: And the two responses showing that the sensor only returns zeros on the Onion The oscilloscope interprets all of the i2c bus traffic correctly, but it appears that the sensoe is never getting triggered by the [0xAA...] command to start digitizing. So it only sends back zeros. Does anybody know why the i2c waveforms are different and how to make the Onion i2c library behave as the Arduino does which works properly. I am not having any trouble with other i2c communication from the Onion, only this sensor. Thanks to anyone who is up on this. Stay safe! Y.

@cmelnick It's possible the onion-i2c:: debug readings aren't 100% correct. Can you try changing your code when you read to this: val = i2c.readBytes(0x5a, 0x5d, 1) print(val)

@Victor-Lucio Please take a look at this: Official Onion Omega2 Documentation I2C Python Module. '/usr/lib/python2.7/OmegaExpansion/onionI2C.so' is not empty - it's an ELF binary file. The source code can be found in the Onion i2c-exp-driver GitHub Repo. An example of how the onionI2C library is used can be found in the i2c-exp-driver repo. The example code programs the Relay Expansion (an MCP23008 8-bit, general purpose, parallel I/O expansion IC for I2C) directly. Good luck.

Thank you for responding, the real direction is 0x70 using 7 bits. In other words is 111-0000. If I include the bit of R/W, this will be 0 if i want to write a data in the slave(sensor). .111000-R/W ----------> 11100000 11100000 Is E0 in hex. For this reason, I have several concerns about this module, but I hope to solve it later. Thans again for taking my doubt. I will try to send you 6 bits as data and include the CRC byte. It is likely that when I insert the writeBytes command, the R/W bit is inclued internally without me noticing.

Thanks. I'd seen that before, ran into bigger problems with the pigpio build (eg no ldconfig available for the omega). That said, I found a method to use with the smbus2 package that allowed me what I needed.

It looks like this was an error in the library that I was using as the libraries author has confirmed they are seeing the same thing when they tried to read from the same kind of sensor.