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.

readValue needs to be passed as a reference, since the contents will be modified by the i2c_read function. That's likely causing the segmentation fault. Or change readValue to a point and allocate two bytes before passing it to i2c_read See the documentation for the i2c_read function for more details: http://docs.onion.io/omega2-docs/i2c-c-library.html#i2c-c-read-multiple-bytes

@Nathanial-Hendler There may not be a solution for this right now. To do it right, you would need to monitor the pins with an interrupt, and have a tight ISR check whatever the highest resolution timer is, then report to something that runs more leisurely. But it's not clear if interrupts on GPIO are really supported; system components seem to poll them, and the userspace GPIO interface you may be familiar with from the pi does not seem to work (that would probably also be too slow, but if it worked something using the same capability in kernel would be more appropriate). A $1 practical solution would be to hang just about any microcontroller on an available serial, I2S, or SPI interface or even the USB, have that time the events, and report the timestamps more leisurely to your Linux-based software. If you use serial or USB, and advantage of this sort of approach is that you can test your whole scheme on a PC without cross compiling for the omega. Meanwhile a potential disadvantage is that while you find out when the events happened with high precision, there's delay of a millisecond or more in that information making it's way to you. So you have great records, but don't quite know about things as they happen.... which may be good or bad, depending on your application need.

@zembrowski You can probably have a script to trigger a new photo and use file exec to run the script. I think the method you outlined above will work, can't really think of a better way