-
Sat 2021.03.27
'But why the data in the console just change when I upload the code again?'
It's likely the chip select line is now in a correct state before the snippet in post #1 executes, and/or sufficient settling time occurred and the sensor is now happy and ready to respond.
'Then i get the values ([96, 0, 0, 0, 0]) in the console.'
While I have never used this sensor, I took a quick peek at the device specification data sheet. Has any of the following been tried or considered?
Although I'm not able to find the fastest write/read interval, hammering on the device five times a second may be a bit too fast for a settling time. Changing L4 to a setTimeout() so that better control (number of times) over what data is retrieved might improve.
From p.15
Has the status byte been viewed to see if the sensor is 'actually' ready to send back it's data?Has an attempt to place pull-ups on the I2C control signal lines been attempted?
Has the bitrate freq value been modified? (rounded pulse edges) See table 18 p.16
opt as data was detected post #1: Has an attempt to use SPI over I2C been tried? p.17
Is there a solid ground between the sensor, uP and power supply?
See note on p.14 about capacitance on SDA and SCL relating to clock speed.
Is there the availability of a logic analyzer to speed the debug process?
For what it's worth, after hours of struggle with SPI, I2C and UARTS, I eventually buckled and picked up a logic analyzer ~$20 that provides immediate feedback on what is on the data lines. I had a floating CS chip Select that rounded out the leading edge, so the receiving device never started the data receive, and thus nothing during the expected read was seen. Here are some sample images. but with a UART:http://forum.espruino.com/comments/14687689/
Note the protocol analyzer output that allows the conversion of Hi-Lo to actual ASCII we may read
Then i get the values ([96, 0, 0, 0, 0]) in the console.