use of "stop measurement"

[michapr]

Hi, not full clear from documentation for me - maybe you could explain? What is the right sequence for reading data?

• 1. 0x0010 Start Measurement Set Pointer & Write Data
• 2. 0x0104 Stop Measurement Set Pointer
• 3. 0x0202 Read Data-Ready Flag Set Pointer & Read Data
• 4. 0x0300 Read Measured Values Set Pointer & Read Data

and for next loop again 1/2/3/4 ?

If I will skip the second step (stop measurement) will get other values. I know that I must not check flag (step 3) if loop > 1 second (currently use about 5 seconds). When the "Stop" should be used?

Thanks! Michael

[psachs]

Hi Michael

The start measurement command will start the fan and put the sensor in to measure mode. You only have to trigger that once.

The stop command will stop the fan and disable measure mode (put sensor to sleep). Only use this command when your done measuring. Don't do this between consecutive read-outs.

We recommended to don't turn of the sensor for as long as your measurement takes. E.g several days, weeks, month. After the start-up the sensor requires a couple of minutes to achieve a stable flow and show the most accurate values.

The recommended sequence is (as pseudo code):

startup();
start_measurement();
sleep(60s);  // e.g. first minute is not accurate enough for our use case.
while (1) {
    while (not data_ready) {
         sleep(100ms);
    }
    read_measurement();
    sleep(5s);
}
stop_measurement();
shutdown();

[abrauchli]

Maybe it also helps to clarify that the SPS30 is not the typical "dumb" i2c device where you set the pointer. The SPS (actually all Sensirion Sensors) execute commands and maintain an internal state machine. The SPS goes even further in that it keeps states between power cycles. So when your device looses power while measuring, it will start measuring again automatically when it's powered the next time. stop_measurement() thus also ensures that the SPS will not start measuring again automatically after a power cycle.

[michapr]

Thank you for clarify this. Maybe it could be helpful to add some of these information to the documentation?

I get these values (for inside room) - are these possible right? PM1.0 .. PM10 1.50 / 1.55 / 1.55 / 1.55 [μg/m³] PM0.5 .. PM10 10.65 / 12.22 / 12.26 / 12.26 / 12.26 [#/cm³] Typical Particle Size 0.53 [μm]

(maybe you could give some reference values anywhere for users? So that they can be sure that received values correct ;) ...)

Thanks! Michael

[edit:] have now values for PM1.0 ..PM10 between 0.40.. 0.43 μg/m³ in my room - can this be a real value?

[michapr]

ok,... after have "optimized" my experimental setup get stable values.

• Have double checked the oltage at SPS (was only 4.3V from WEMOS D1 mini) - is now 4.99V
• Have added a capacitor 470uF to voltage input After restarting all and begin at new get now such values (still for my working office room): PM1.0 .. PM10 2.40 2.48 2.49 2.49 [μg/m³] PM0.5 .. PM10 17.04 19.57 19.63 19.63 19.63 [#/cm³] Typical Particle Size 0.59 [μm]

Values seems for me very low (μg/m³) - or what do you think? Have also checked with original sample code - get the same values here. And - no big changes within 18 hours.

[rnestler]

Values seems for me very low (μg/m³) - or what do you think?

You could try to tear apart a piece of paper very close to the sensor, this should give you a spike of particles for a short time. Another thing you can try is to light a candle which will also produce particles.

[michapr]

I have of course tried this before (candle) and have seen that values will be changed. But 2 - 3 μg/m³ for a living room (home office) looks for me too low, that's why was asking about the value ranges. Want to be sure that I can "trust" the values I have got ;)

[psachs]

@michapr It really depends on your environment. 2 - 3 μg/m³ for a living room is actually reasonable. Depending on the area you live in the values should increase if you open a window. It is quite usual that there are not a lot of particles indoors. E.g. in our office or at my home I get similar values.

I am not sure what kind of reference values you are expecting. E.g. there is no world wide standard for Air Quality based on PM values. You can find some interpretations on Wikipedia: https://en.wikipedia.org/wiki/Air_quality_index

You can find the technical specifications on the datasheet: https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/0_Datasheets/Particulate_Matter/Sensirion_PM_Sensors_SPS30_Datasheet.pdf

[michapr]

Thanks, of course I know these and other documents. closed.

[kevinjwalters]

What's the best place for feedback on the data sheet? For the Version 1.0 – D1 – March 2020 version

I've noted (all for i2c on a V2.2 firmware sensor)

1. to change the returned data type, e.g. from integer to floating-point, I have to issue a stop command before the start with the new value (0x03 or 0x05) otherwise it ignores that value.
2. it would be useful to be more explicit about what the command execution time implies, e.g. for a start should a program or library wait for 20ms after issuing any more commands.
3. might be worth highlighting units for Typical Particle Size differ between floating-point and integer mode, it's in the table but it's the only one that differs and it's easier to miss that difference
4. there is a 5ms delay between write and read for reading the device status in this library and https://github.com/Sensirion/arduino-sps/blob/master/sps30.cpp but requirement for that is not mentioned in data sheet
5. [added later] after changing mode (int <-> fp) reads will still come back in the previous format for approximately 1.07 +/- something seconds which either causes junk data or CRC check failures (tested on 2.2 firmware)

[winkj]

Hi @kevinjwalters,

Thanks for reaching out. For feedback on data sheets, please reach out to our technical support team via the "Contact" link on https://sensirion.com/support.

Regarding your question #4, the 5ms delay: Please note that the data sheet is authoritative, and the sample code may use different timings for a number of reasons (typically to increase cross-platform compatibility); therefore it should only be reported as an issue in the data sheet if tests show that it actually fails without the delay.