Interfacing to Sensor - HardwareSerial - compile error

I am converting Arduino code to run on a Xenon. The project is located at:

I am getting a compile error: " no matching function for call to 'LW20::LW20(USARTSerial&, int)"

The statement is LW20 lw20(Serial1, 115200);

I am almost sure this has to do with the following 3 lines of code:

        HardwareSerial* serial;
	unsigned long serialBaud;
	LW20(HardwareSerial& Serial, unsigned long BaudRate);

I would appreciate the communtiy’s help in fixing these few lines so that the program compiles.

There is a problem with the constructor of the LW20 object - the data type HardwareSerial?

Have you tried #include “Particle.h” in the lw20.h file?

I don’t understand the use of the referencing and dereferencing of HardwareSerial. Nor why HardwareSerial is declared as public:

Do you really need to specify the serial port as a parameter or could it be simply defined as Serial1.begin(), etc. where used and avoid all the bother?

Thank you @armor.

It is not my code and my knowledge of C is limited. I tried #include “Particle.h” in the lw20.h file but I got the same error.

What is the alternate way of doing this because I need the lw20 variable …

That is to keep the used HW interface dynamic.
e.g. on the Electron you have Serial1, Serial4 & Serial5 to chose from so you need a way to tell the library which one to use.

@Jimmie, you can try adding #include <Arduino.h> to add some extra layer of compatibility to Particle.h but I’m not sure whether Particle has already ironed out some of the oversights where Gen3 devices got “forgotten” to be addressed too.

Another workaround may be to modify the library to actually take a USARTSerial object type instead of HardwareSerial. And while at it you probably need to replace the function parameter Serial with something else since in the Particle world Serial is a reserved macro used for USBSerial which would collide with that library naming.

1 Like

Thank you @Scruffr for your usual help. I have followed your guidelines but the same compile error persists and now even more errors are produced when using USARTSerial.

I have found a much simpler version of the program and tested it on an Arduino and it works. I then compiled it and it also compiles on the Xenon with no errors. However, it does not run. I do not know if this is related to the Serial port implementation on mesh devices.

The project (very short) is at:

I have isolated the problem to the following statements:

if (lw20SendCommand("?\r\n")) {


// Send a command string and wait for a response. Returns true if a response was received.
// The response string will be held in 'responseData'.
bool lw20SendCommand(const char* CommandStr) {
  // Make sure there is no unwanted data left in the buffer.
  while ( != -1);

  // Send the command.

  // Only have 1 second timeout.
  unsigned long timeoutTime = millis() + 1000;

  responseDataSize = 0;
  // Wait for the full response.
  while (millis() < timeoutTime) {
    int c =;

    if (c != -1) {
      if (c == '\n') {
        responseData[responseDataSize] = 0;
        return true;
      else if (c != '\r') {
        if (responseDataSize == sizeof(responseData) - 1) {
          responseDataSize = 0;
        responseData[responseDataSize++] = (char)c;

  return false;

I would really appreciate your help as what may be causing this and thank you in advance for your time.

I got your original version compiling

About your other code it’s rather difficult to know what may be amiss without the sensor.

1 Like

Thank you very much @ScruffR. I just tried it.

Something really odd happened. When I flashed your share, the Xenon was flashed.

When I copied your share to my program (tab for tab), I got the same compile errors as before …and also system asked if I want to include lw20api.h.


What can I try? The same code is running on an Arduino. I have a hunch that it is related to the function above

bool lw20SendCommand(const char* CommandStr) 

but not sure what …

That “Are you sure…” message is just a warning when one of the extra headers is not included in the main .ino but since I know it will be included via lw20.h there is on need.
However, if you don’t want that message, just add the include statement.

Also this builds as is for me
Your issue may be in connection with some residual intermediated (previously compiled) files that won’t be recompiled for whatever reason.
Why you not just rename my project and work with that?

What Arduino? Is it also a 3.3V controller?

When you say “it does not run” what does that mean?
Does it hang? Where? Do you get any data? Have you double checked the wiring? Have you added Serial.print() checkpoints? …

1 Like

Thank you @ScruffR for taking the time.

It is an Arduino Mega (5V) not 3.3.

I have found that “part” of the problem is related to the following statement (in the short version)

while ( != -1);

The micro is reading -260. When this statement is commented out, the serial stream seems to be correct. I am doing some more testing and have written to the sensor vendor but it is nigh time there.

Hello @Scruffr,

The code you fixed is working with the sensor. Thank you again.

When you say “it does not run” what does that mean?
Does it hang? Where? Do you get any data? Have you double checked the wiring? Have you added Serial.print() checkpoints?

In the simpler code version, the port is sending something that the code does not like. The code is expecting every once in a while a -1 and is hanging. I double checked the simpler code and the byte stream looks correct but somewhere, some values are causing the functon to block.

-1 is a way how the device OS treats the case that you running while Serial1.available() == false.
I also use similar code to flush unwanted RX data out before actually starting an async read, but I rather do it as

  while( >= 0);

The -260 you see can’t stem from the external device as it can only send single bytes (0…255 or -128…+127) - unless you are using 9bit protocol which is not supported on Gen3 devices - so it may indicate an issue with the Serial1 implementation which needs to be checked.

Thank you @ScruffR. I will try the change. I also tried the same code on a Photon (latest firmware) but the same problem persisted.


The code you fixed compiles and runs fine but after a few hours, the Xenon locks up.
I have a suspicion this has to do with a sensor whose update rate is > 300Hz.

Can you direct me to a link that shows how to restart the Xenon when this happens? I have no idea how one would debug an error like this which is hard enough even using .NET code on a Win machine…

Thank you in advance,

I have now tested the behaviour of and it in deed has a bug

I also had a typo above - ready where it should have been read() (now corrected).

1 Like

Thank you @scruffr for your efforts.

It may be worthwhile for Particle to also check Photons because I “think” I got the same result with a Photon running the latest firmware.

Nope the Photon returns -1 as expected (I have tested it too).

OK, thanks. (was firmware 1.0.1)?


Are hardware watchdogs the right way to prevent micro-controllers apparent freezing when connected to high-rate serial sensors or is there a better way?

Thanks again.

Yes, 1.0.1.

HW watchdocs are the most reliable option.

1 Like