I've narrowed the problem somewhat. In the examples, the page and starting column are sent followed by 160 x 4 bytes of data and grayscale information. Unfortunately, the library calls I am trying to use limit the data package to 32 bytes. I attempted in my original code to set the column each time through so I would only have to send the 4 grayscale bytes of data (all the same for black). This method does not seem to work, and I do not see why.

I've got connection and control with my RPi, but something is not right. Most likely it is my implementation of the grayscale. I adapted your examples, but when I send data (each byte 4x) I get a line through the display on the 3rd pixel level (0x04). Sending the data only once moves the line to the first pixel (0x01). Setting all the data to 0xFF shows it is data independent; only the number of times sent affects the lines' locations. Also, the "dark" pixels are not that dark, but the lines are.

I have pictures of the display with the three types of data, but have nowhere to upload it so I can link it.

I.write(Adr, "Block", Com, [0xAF])[/font]The "I.write(...)" lines at the bottom are the different data trials I have used. The current selected outputs 0xFF four times per byte. Real data are in the lines with the "RC"

Please help me understand how the grayscale SHOULD be used, as I obviously am doing something wrong.

I just got a chance to play with the pull-ups. I have a RPi - B, and I'm using the I2C pins on the GPIO header, so removed R1 and R2, and terminated the I2C lines with 10k. The display finally responds!

Thanks for the reply. I had already thought of that, and have checked and verified the I2C address using the detect command on the RPi. Also, the I2C commands throw an error if the address is invalid, so I'm fairly confident that I have communication.

I've been trying to add a NHD-C160100DiZ to my Raspberry Pi. I have interfaced the display using I2C with CSB tied low and RST tied high (always selected, not reset). The I2C bus detect finds the address (0x3F). Using the following program (which I hope is a faithful adaptation of the example code), I get nothing on the screen: