last day (16 days later) » 

12:17 PM
0
Q: Having issues interfacing SPS30 with Pico

RobotI am trying to interface SPS30 via UART, but I am not able to start the fan. I am getting some response but it won't match any possible response from the datasheet. Using Micropython. Below is the code snippet - import machine import time from micropython import const if __name__ == "__main__": ...

 
Are you using the particular model: Datasheet SPS30 Particulate Matter Sensor for Air Quality Monitoring and Control cdn.sparkfun.com/assets/2/d/2/a/6/…
I would suggest to first make sure Pico UART/serial loopback test is OK.
 
@tlfong01 yes I am using this model only. I have tested UART works with another sensor that I have used over UART. To be clear, not using both sensors on uart at once. The previous sensor is from different project.
 
What does this command do: [0x7e,0x00,0x11,0x00,0xee,0x7e]? Pls let me know which section of the datasheet you are reading.
 
This is wake up command. Cmd:0x11. Pg 12 of datasheet.
 
It appears that we are not reading the same datasheet. Can you give me the link to your datasheet?
 
Oh my goodness. Your datasheet is Version 1.0 – D1 – March 2020. Me Preliminary – Version 0.9 – D1 – November 2018.
 
12:46 PM
Yeah
Did you get anything?
 
1:44 PM
Well, I skimmed the datasheet and got confused. (1) Question: So you are using RxTx, and speaking SHDLC Commands? (2) Suggestion: Try "5.3.8 Device Information (CMD 0xD0)", to just read something, without first writing anything to go to Idle mode. Only 50% sure of any success.
 
2:06 PM
Okay, so under device info (cmd 0xD0), I sent command for Product type and it's written that it will always return this string - "00080000". I am getting that string. The proper response that I am getting is ~\x00\xd0\x00\t00080000\x00\x9e~. But the string response mentioned in datasheet have 0x09 before the first '0'(I am getting \t which is tab and it's dec value is 0x09 so that's fine). But 0x9b after the final '0' (getting 0x9e). So this is right to some extent
But I guess this is something. First response which is right according to datasheet
So the sensor is working okay
 
2:22 PM
Ha, so you are getting the expected "00080000", and as you say, "So the sensor is working okay". Ah, locking down bed time. See you later. Cheers.
 
Sure, one more thing what I was doing wrong was not using delay after uart.write()
I was doing uart.read() without delay
Using delay helps. It stuck my mind after I first tried sending 0xD0 command string. The response I get was very weird, though it contained 00080000 but start and end characters were very random. That's when it struck me that the response i am getting is mixed of previous cmd response as well
Thanks for the support
I tried other commands as well and was able to run the fan and I am getting readings now as well
Btw where are you from?
 

  last day (16 days later) »