UNO Q interface with SDS011

Was able to access the SDS011 sensor from a UNO Q. There are several issues that are confusing. A few doc references are less than clear as applied to the UNO Q. Code is at: GitHub - iapaddler/unoq-sds011: Using a UNO Q board with an SDS011 sensor · GitHub.

The README attempts to explain a few things. Hopefully it's clear.

What are these issues?
//-------------------------------

There are a few specifics that are either confusing or incorrect in the docs:

  • Use the Monitor interface to create serial messages from the controller

    • Don't use the Serial interface directly for this
      Connect DPin-0 and 1 of UNO Q with RX and TX line of your sensor using level shifter.
  • Use the Bridge interface to pass data between the controller and Linux
    Correct

  • The hardware serial connections on D0 and D1 of the UNO Q are connected and available
    Are not anywhere; so, it is available

  • Several docs refer to the fact that these are not available because the serial port is used for communication with the Linux host
    Not Correct:
    To exchange data between MCU and MPU, there is brige made of LPUART1 port at MMCU side and UART1 Port at MPU/Linux side.

    • This is not the case on the UNO Q

    • They are in fact supported

    • Linux host communication takes place over the Monitor connection and not Serial1
      Correct:

  • The device on the UNO Q connected to the D0 & D1 pins is Serial1
    Correct: You execute: Serial1.begin(9600);

  • The SDS011 defaults to 9600 baud on the serial device
    Fine:

  • Use the 5V and GND pins from UNO Q to SDS011
    Correct:

  • Don't use the UNO Q 3.3V source
    Correct:

  • SDS011 requires 5v
    So, use level shifter for the RX and TX lines of you SDS011 sensor.

  • Note that Arduino defined SoftwareSerial is not supported on the UNO Q
    I am not sure.

  • Zephyr OS, used on the controller, does not support this
    Pass:

  • There is a bug in the Monitor.print & println functions
    Correct:

  • Floating point values are not displayed correctly
    Correct:
    Solution:
    ... pending

  • The accepted work around is the use of sprintf and then Monitor.print the buffer
    pass

  • When using the SDS011 polled mode a delay is a good idea

  • Delay for at least 150ms after the poll before reading

  • Exact times have not been tested

    • Currently using 200ms just to be safe
  • The SDS011 active mode works

    • Be aware of the period
    • Default period is a measurement every second
    • That can be changed
    • You'd want to read right after the auto measurement is made

Hi @iapaddler. Thanks for sharing your project and findings!

From https://github.com/iapaddler/unoq-sds011#there-are-a-few-specifics-that-are-either-confusing-or-incorrect-in-the-docs:

There are a few specifics that are either confusing or incorrect in the docs:

  • Use the Monitor interface to create serial messages from the controller
    • Don't use the Serial interface directly for this

I'm not sure I understand what you mean by this. Monitor, and its alias Serial, are used to communicate between the sketch program running on the UNO Q's microcontroller and the host PC.

I think the documentation does a pretty good job of explaining this for the Monitor object:

https://docs.arduino.cc/tutorials/uno-q/user-manual/#from-serial-to-monitor

It is true that the documentation is currently incorrect in regards to the change introduced last week that causes Serial object to be an alias for Monitor instead of the interface for the UART:

https://docs.arduino.cc/tutorials/uno-q/user-manual/#uart

An update to the documentation to reflect this change is in progress:


  • Use the Bridge interface to pass data between the controller and Linux

I'm not sure I understand what you mean by this. I will be happy to investigate and escalate them to the responsible parties at Arduino if you will provide more details. If you do so, please make sure to provide the following information:

  • Link to the specific documentation page that contains the problematic content.
  • Exact text of the content you are referring to.

  • The hardware serial connections on D0 and D1 of the UNO Q are connected and available
  • Several docs refer to the fact that these are not available because the serial port is used for communication with the Linux host

Please provide a link to the specific documentation pages that contain this incorrect information.

Please provide the exact text on those pages that is incorrect.


  • The device on the UNO Q connected to the D0 & D1 pins is Serial1

The object for the UART interface was originally named Serial. In order to provide compatibility with existing general purpose code written for the standard convention of Serial being the object for communication with the host PC, this was changed in last week's 0.55.0 release of the "Arduino UNO Q Board" platform:

https://github.com/arduino/ArduinoCore-zephyr/releases/tag/0.55.0#:~:text=⚠️-,Breaking%20Changes,-Serial%20Communication%3A

https://support.arduino.cc/hc/en-us/articles/27251870677916-Migrating-to-Zephyr-core-0-55-0-on-UNO-Q#what’s-changing

Unfortunately the documentation was not updated at the same time as the release was made that shipped that change to users, so the documentation currently reflects the interface provided by previous versions of the "Arduino UNO Q Board" platform. I apologize for any confusion caused by the incorrect documentation.

The documentation team is in progress of updating the content:


  • The SDS011 defaults to 9600 baud on the serial device
  • Use the 5V and GND pins from UNO Q to SDS011

[...]

  • When using the SDS011 polled mode a delay is a good idea

[...]

  • The SDS011 active mode works

I assume these are referring to some other documentation content than what is maintained by Arduino, since I don't think we maintain any documentation whatsoever for SDS011. If I am wrong about that, you are welcome to provide a link to the documentation and I'll investigate.


  • Note that Arduino defined SoftwareSerial is not supported on the UNO Q

That is correct. Did you find some information in the Arduino documentation that implies otherwise?


  • There is a bug in the Monitor.print & println functions
    • Floating point values are not displayed correctly

The bug has been reported to the developers here:

If you have a GitHub account, you can subscribe to that thread to get notifications of any new developments related to this subject.