I am working with an I2C connection from my particle photon to a Sensirion differential pressure sensor. My code compiles and flashes successfully, but as soon as it starts to run the blue light on the photon turns off. But when looking at the Events console, it claims that the photon is still on and online. Also, I can still put it into safe mode and DFU mode. If I flash another app onto it, like tinker, the blue light comes back on and everything is normal. So really all that happens is that the blue light turns off, but everything else seems okay. I did some research and couldn’t find anything about this problem, does anyone know what would cause this? It almost has to be my code if everything is normal when I flash other code onto it. So here is my code, its fairly simple I’m still trying to figure it out with the help of the Particle guide. Any insights would be appreciated. I’m curious why you think this would turn the blue light off? Like does this code somehow short my board, or what is going on?
void setup() {
Wire.begin(0x40);
}
void loop() {
Wire.beginTransmission(0x40); // transmit to sensirion
Wire.write("hF1"); // sends transmit signal as designated by Sensirion manual
Wire.endTransmission(); // stop transmitting, which sends the signal I beleive
delay(500);
Wire.requestFrom(0x40, 6); // request 6 bytes from slave
while(Wire.available()){ // slave may send less than requested
char c = Wire.read(); // receive a byte as character
Particle.publish("It Went!",c); // print the character
delay(500);
}
}
Do you mean the RGB LED which is normally breathing cyan goes out completely and does nothing else anymore?
If so, I’d first ask whether you have pull-up resistors attached to D0 & D1.
The second question would be what system version you are on.
And if it’s not 0.6.2 (or above) I’d suggest to update.
BTW, your possible 6 publishes in 3 seconds will violate the rate limit.
Rather collect all 6 bytes first (without that long delay between each byte) and then publish them as one event.
Sorry for the confusion, but yes the light that would typically breath cyan is the one that went out. I do have the resistors and I used this scanner successfully earlier today, so I know my hardware is okay and that my address is correct: I2C Information
How do I check my version? I updated it from the CLI not to long ago, like a week tops, but I didn’t catch the version number.
Thanks for the response and good call on the publishing
Yep, that did the trick! For the light at least, now I am having trouble in that I receive garbage characters. Here is a screenshot of the manual for my sensor, it says that:
“On receipt of a header with R/_W=1, the sensor generates the Hold Master condition on the bus until the first
measurement is completed. After the Hold Master condition is released, the master can read the result as
two consecutive bytes”
I guess I’m not sure how to add that header, also maybe not sure if I’m reading the results correctly. Any help would be appreciated!
Wire.beginTransmission(0x40); // transmit to sensirion
Wire.write(0xF1); // sends transmit signal as designated by Sensirion manual
Wire.endTransmission(); // stop transmitting, which sends the signal I believe
delay(500);
Wire.requestFrom(0x40, 2); // request x bytes from slave
while(Wire.available()) // slave may send less than requested
{
inChar = Wire.read(); // Read a character
inData[Index] = inChar; // Store it
Index++; // Increment where to write next
inData[Index] = '\0'; // Null terminate the string
}
Particle.publish("Its Read!", inData); // print the character
delay(1000);
Index=0;
I might be wrong but I understand this behaviour as what’s called clock stretching which is supported by the I2C implementation by default.
You may leave off the delay(500) after the 0xF1 trigger measurement but add a short (e.g. 100ms) delay after the read request.
I’d also reset Index before the read block - at least for clarity.
Thanks for the response. That was worth a try but still gave garbage characters. I found some code online that works, so now I’m just curious why this would work and my code wouldn’t? I’m still fairly new to coding so I’m not sure what all of these commands do. But I am curious, so if someone could point out what is making this code work I would greatly appreciate it!
int ret;
uint16_t rawSensorValue;
int16_t signedSensorValue;
// To perform a measurement, first send 0xF1 to switch to measurement mode,
// then read 2 bytes + 1 CRC byte from the sensor.
Wire.beginTransmission(ADDRESS);
Wire.write(0xF1);
ret = Wire.endTransmission();
if (ret != 0)
{
Serial.println("Error during write measurement mode command");
}
else
{
Wire.requestFrom(ADDRESS, 2); // reading 2 bytes ignores the CRC byte
rawSensorValue = Wire.read() << 8; // read the MSB from the sensor
rawSensorValue |= Wire.read(); // read the LSB from the sensor
ret = Wire.endTransmission();
if (ret != 0)
{
Serial.println("Error while reading flow measurement");
}
else
{
Serial.print("Raw value from Sensor: ");
Serial.println(rawSensorValue);
I tried to figure out exactly which sensor you are using and I could not figure it out. Are you using a Sensirion i2c sensor? They all seem to take 2-byte commands.
Can you tell us exactly what part you are using?
Your code above takes bytes read from the sensor and seems to pretend that they are ASCII characters–I don’t think you want to do this. Instead I think you should convert the values to hex or ASCII and them stick them into the publish char array. They way you have it now explains why you are seeing garbage characters.
My sensor is the Sensirion SDP611-500mPa differential pressure sensor. What you said makes sense I think, the values I should be getting are on the order of 60000 so I was confused how to turn the two byte output into a number. How would I put them into a “publish char array”? I’m not exactly sure what that means.
So I got the device (Sensirion SDP611) communicating and reading data. This is a differential pressure sensor so it should be normally reading 0, however it consistently reads 1256Pa. With my conversion factors, this number becomes a raw value of 2^16, indicating that the sensor is maxed out. My code is adapted from this audrino code for simple sampling of a flow meter by the same company:
Wire.beginTransmission(ADDRESS);
Wire.write(0xF1);
ret = Wire.endTransmission();
if (ret != 0)
{
// Serial.println("Error during write measurement mode command");
writeData();
myFile.println("Error during write measurement mode command");
myFile.close();
}
else
{
Wire.requestFrom(ADDRESS, 2); // reading 2 bytes ignores the CRC byte
rawSensorValue = Wire.read(); // read the MSB from the sensor
rawSensorValue |= Wire.read() << 8; // read the LSB from the sensor
ret = Wire.endTransmission();
It was suggested that my bitshift might be incorrect, but to be honest I am not sure what that would mean or how I would fix it haha. Also, the manual mentions a hold master condition, can someone explain to me what this is and how I would implement it? Thank you! Here is the relevant page of the manual:
Sorry for repeating the hold master condition question, I guess I didn’t realize when you answered the first time that clock stretching was referring to the hold master condition. My bad haha. As for why I switched the Audrino code, I read that particle and Audrino reads these values in reverse, so it made sense to switch them. I was not aware that either of those lines had to do with the bitshift, but now that makes sense I got a new sensor, it’s possible that I just fried the first one while soldering or something like that, so I am going to switch the sensors out to see if that makes a difference. Interesting note: when I introduce flow to my sensor the reading drops, but then when flow stops the reading jumps back to the 1256
I connected a new sensor and switched my code back so now the read sequence is the same as the audrino read sequence. The results I am getting are interesting, about half the time I get a reading of 0.2 Pa (which is good), and the other half of the time I get the maxed out 1256 Pa (bad). Any ideas on why it would work half the time? Maybe a hardware issue? Thanks for the help!
Yeah we did! The problem is that the sensor was spitting out 2’s compliment binary (to account for negative pressures), but I was looking for regular binary. Once we got it going it was a great little sensor, perfect for all our differential pressure reading needs (we used it to determine the …oh wait, top secret I can’t say). And it was easy to set up the hardware!
I got a new sensor, it’s possible that I just fried the first one while soldering or something like that, so I am going to switch the sensors out to see if that makes a difference. Interesting note: when I introduce flow to my sensor the reading drops, but then when flow stops the reading jumps back to the 1256
