Sensirion sps30

[Horowitz]

From within MicroBlocks I tried to interface through serial and I2C with the Sensirion sps30 particle matter sensor. My question: is this even possible? Thank you. Link to the Sensor specs:

[John Maloney]

Hi Horowitz,

I have reviewed the specs for the device and it is definitely possible to communicate with it using either protocol from MicroBlocks: uart or I2C.

Since we do not have a library readily available for that device, the task will involve building command strings specified in the document.

All the blocks required to establish comms and data exchange can be found under the communication category of the IDE interface. We support both Serial UART and I2C.

Depending on which microcontroller you intend to use, the serial and I2C pin info can be found on our WIKI: https://wiki.microblocks.fun/boards/special_pins

While your device's specs are very descriptive for someone familiar with communications coding, it could be a challenge for others. Not knowing where you fall in that spectrum, I will leave it to you to decide. If you need assistance, don't hesitate to ping us again. I'll also await John's response re any library feedback. He has done some Databot work recently and may have info not available to me.

Turgut

[Horowitz]

Hi Turgut,

Thank you for the reply and pointing me out: the special device pins. I am inexperienced to communicate to the metal of sensors. I have managed, from the sps30 sensors specs to write some bits tot the sps30 sensors register but I can't make any sense from the bits response it gives? Are there any good practices to tackle this. Can the Arduino script be a workaround?

Hans

[John Maloney]

Sensor data sheets can be difficult to understand. They usually do should contain all the information you need, but it can be hard to find it it. If you are using I2C, the register descriptions are key.

That said, I often Google for Arduino code for a sensor as a guide. The Arduino programs are often much longer than the MicroBlocks code ends up being and often include extra features that are not actually necessary, so I don't try to transcribe the entire Arduino library into MicroBlocks. Instead, I look for the key features I want to use (i.e. reading data from the sensor) and figure out what registers are read and how the raw data from those registers is converted into useful sensor values. I also look for the Arduino code that initializes the sensor since some sensors need to have certain registers set up before they will work.

Writing the code to interface to a sensor via I2C or serial is a challenge, and it can feel almost impossible the first time you do it. But MicroBlocks allows you to tinker with the sensor interactively, which help you build understanding and confidence that you are making progress. And it is incredibly satisfying and exciting when your code finally works and you start start getting sensor values.

Good luck!

[Horowitz]

Thank you, Turgut and John. I will explore this further.

In the meantime, it's possible that someone has already tackled this issue. I've developed some code to simplify and enhance image writing using the TFT library for the Pico, making it more educational. The existing method on the microblocks wiki website seems cumbersome to me and can likely be achieved more effortlessly. However, I'm uncertain if this has already been addressed.

If you're interested, please let me know.

Best regards,
Hans

[John Maloney]

The Wiki article you link to is fairly old. This past spring, José Garcia extended the BMP library to read any type of BMP file and Bernat added the "8-bit" library that can render bitmaps with color maps (i.e. BMP files with 1, 2, 4, and 8 bits per pixel), so it is now much easier to draw small images on TFT screens. This is pretty new, so we haven't yet written a good tutorial explaining how to use the new features. However, if you ask in our Discord server (linked from the footer of the microblocks.fun website) someone can point you in the right direction.

[Horowitz]

I successfully established a connection with the Sensirion SPS30 on the Raspberry Pi Pico. The fan cleaning command is functioning as expected. When attempting to retrieve device information (as I understand it), the sensor provides a response in bytes. The manual specifies that the expected response should be "00080000". It's worth noting that the Sensirion SPS30 uses the SHDLC protocol for communication. Is it possible to get a more readable output from the SHDLC bytes?

Manual Sensirion sps30

‌

‌

[John Maloney]

You've made great progress!

Due to "byte stuffing" (page 9 of the manual), the pair 125, 49 (which is 0x7D 0x31 in hexadecimal) is encoding the single byte value 17 (0x11). Thus, the message is a zero-length message for the command 17 reporting the state 67. You can see the message format for a MISO message (i.e. a response from the SPS30) on page 8. There is a 126 0x7E at the start and end of the response. The second byte is the addres (0), the pair 125, 49 -> 17 is the command, 67 is the state field, and the following 0 is the length. The second to last byte, 171, is the CHK byte.

So, it looks like a well-formed message. I don't have time right now to figure out what it actually means, so I'll leave that to you. :-)

[Horowitz]

Thanks for the quick reply, much to think and learn about…it’s not easy I already mentioned “start fan cleaning” is working.

‌

[John Maloney]

The "byte stuffing" mechanism adds an extra layer of complexity. To add to the confusion, it looks like their examples show messages before applying the byte stuffing.

According to the table, the byte 0x11 should be replaced with 0x7D, 0x31. So it looks as though the two messages in your code "7E 00 11 00 EE 7E" should be "7E 00 7D 31 00 EE 7E". The checksum is the same because it is computed before byte stuffing.

My inclination would be to write two helper functions: "byte-stuff" and "un-byte-stuff". Each function would take a byte array input and return a new byte array with the given byte stuffing transformation:

Note that if you download the script image PNG file, you can drag-and-drop it onto your project to add those scripts.

Using these functions, you just need to byte-stuff each message before sending it to the SPS30 and un-byte-stuff the message you get back.

Hope that helps!

[Horowitz]

Thanks for your contribution of byte stuffing blocks. As of now, this is the progress I've managed to make. Everything was functioning smoothly yesterday, but today, unfortunately, there has been no progress. ☹️ I have hopes that someone can provide some insight into this.

‌

[John Maloney]

Although I tested the byte stuffing, it's possible that I got something wrong. I would try going step-by-step to debug. Often when "nothing works" you just need to find and fix one tiny bug and suddenly everything works. Hope that happens for you!

[John Maloney]

I'm guessing you got this working, so am marking it resolved. Feel free to re-open if you have further questions.

[Horowitz]

Did not get the SPS30 to work correctly. I’m switching to I2C protocol hopefully with more luck.

[John Maloney]

I'm sorry you didn't get it working yet.

The SPS30 uses a more complex protocol than most sensors for both UART and I2C communications. The I2C protocol uses two-byte addresses and responds with two data bytes plus a checksum. MicroBlocks can handle that but you will need to use the "i2c device read list" and "i2c device write list" blocks rather than the simpler i2c register blocks that work with single bytes. You will also need to generate a checksum when you send data to the device.

Good luck!

[Horowitz]

Thank you John, I will have a look at the I2C protocol for the SPS30. For me getting acces to the sensor it is more like a learning process.