Problem with Serial

We use Explorer board (after an upgrade from Mbili)
We already miss the softserial and we have some problems with hardware serial working with Honeywell Particle sensor…

In order to have the I2C groove connector to work (for other i2c devices) we had to add this:

For the Serial we just connected the Serial (pins 0 and 1) and we see commands sent to the hpma115S0 but the reading of the PM values usualy give out wrong numbers (od no data)
We use 9600 baus rate and we use a hpma115s0 library which is designed for hardware serial…

Any idea how we can fix this…
Also, is there any option to use additional Serial ports (our of the 3 hardware we have Serial, BLE and LORA) in future needs for other sensors?

Thanks you for creating this wonderfull device…

Hi @bidikov,

SoftSerial is indeed not available for the boards with a SAMD microcontroller.
You should use one of the available hardware serials.
Here you can read more about the available hardware serials: Overview - SODAQ Support pages

The pins should be added automatically when you select the correct board files.
The library should be added when using I2C devices.

It should maybe be possible when you change the boardfiles.
We only support the default configuration.
For the autonomo board we have a different boardfile to support multiple hardware serials.

Can you share a bit of code, hopefully we can then identify the problem. If you don’t want to publish it publicly on the forum you can send it to with a link to this topic.

Best regards,

Just to clear up…
The I2C part worked just after i added the definition…
allthought the selected part in Arduino software is:

I will send you the code on email becouse i caanot give it our publicily…
Thanks for the fast response…


Thanks for the email.

I see that int he library there are a few hard-coded lines for debugging: Serial.println(
Can you remove these or use SerialUSB.println( to print to the SAMD USB debug stream?

Let me know if this helps.

Best regards,

sorry for not mentioning that…
We have already commented those parts out of the code…

The strange behavior is that sending commands work - but only the read function does not read or after some time it reads but the values does not seem real (they seem lower)…

Any idea on how we can debug this?
Seems the problem is still existing…

Hi @bidikov,

I have had a look at the data sheet for that sensor. Interface wise, it looks compatible, 3.3V UART.

However, the device requires a 5V power source, how are you powering it from the ExpLoRer?
The ExpLoRer 5V pin is only powered when the USB is connecting (and feeding a 5V source).

One other thing to check might be whether the UART logic levels are inverted. I didn’t see anything specifically in the datasheet about this, but I didn’t check fully. This is one feature that SoftSerial supports, but as far as I know is not supported by the SAMD hardware serials.

The power for the sensor (the +5V) is given from the power board which we use to power the Explorer over usb…

I whouls realy like to know how we can check this “whether the UART logic levels are inverted”
It’s quite interesting that most of the serial commandswork all the time - but the “read od values” funtion is the one which is problematic…
We realy like to get to the bottom of this expecialy since we are going into production with this remarcable Sodaq board :slight_smile:

Thanks for the support…


I would recommend having a look at the UART signal (coming from the sensor) with a logic analyzer. This should allow you to confirm whether the correct signaling is coming from the sensor, and additionally it will be possible to detect if the signal levels are invert.

Additionally, if most of the communication works fine, but it fails on specific actions or commands, it might be an issue with the power supply. A standard USB from a PC will only provide 500mA max. I see in the datasheet for that sensor the max inrush current is 600mA. It might be that the command you are sending is triggering an action which requires a lot of power and might be causing a brown out or something.