Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SoftwareSerial is broken #6

Closed
yburkouski opened this issue Dec 25, 2019 · 10 comments · Fixed by #9
Closed

SoftwareSerial is broken #6

yburkouski opened this issue Dec 25, 2019 · 10 comments · Fixed by #9

Comments

@yburkouski
Copy link

Doesn't work with 7003 under Arduino
@avaldebe
Copy link
Owner

Will look into this, hopefully sometime this weekend.
In the meantime, can you give me some extra information?
Did you try any of the library examples?
Which Arduino board are you using?

@pczekalski
Copy link

pczekalski commented Jan 28, 2020 •
edited
Loading

Hi, same here "Incomplete message header". The sensor is early PMS7003.
Just started testing with Softserial on ESP8266-12E (NodeMcu 1.0).
I do make this work as I wrote a library in C# and connected via USB to Serial converter to my PC so I'm absolutely sure it is OK. What I found is that sometimes it used to send "shortened" frame. I didn't analyze your library but what happens if you once discover invalid header? Do you just drop the frame and wait for the starting flag?

[update]
Works well with same config and PMS.h library by Mariusz Kacki, PlatformIO ID 1891

@avaldebe
Copy link
Owner

Will look into this, hopefully sometime this weekend.

Alas, I'm yet to find time to look into this issue.

I didn't analyze your library but what happens if you once discover invalid header? Do you just drop the frame and wait for the starting flag?

Invalid messages are drop. The status returned should tell what was the problem.
The SoftwareSerial example shows how to interpret the return status

PMserial/examples/SoftwareSerial/SoftwareSerial.ino

Lines 35 to 63 in 5555925

switch (pms.status) {
case pms.OK: // should never come here
break; // included to compile without warnings
case pms.ERROR_TIMEOUT:
Serial.println(F(PMS_ERROR_TIMEOUT));
break;
case pms.ERROR_MSG_UNKNOWN:
Serial.println(F(PMS_ERROR_MSG_UNKNOWN));
break;
case pms.ERROR_MSG_HEADER:
Serial.println(F(PMS_ERROR_MSG_HEADER));
break;
case pms.ERROR_MSG_BODY:
Serial.println(F(PMS_ERROR_MSG_BODY));
break;
case pms.ERROR_MSG_START:
Serial.println(F(PMS_ERROR_MSG_START));
break;
case pms.ERROR_MSG_LENGTH:
Serial.println(F(PMS_ERROR_MSG_LENGTH));
break;
case pms.ERROR_MSG_CKSUM:
Serial.println(F(PMS_ERROR_MSG_CKSUM));
break;
case pms.ERROR_PMS_TYPE:
Serial.println(F(PMS_ERROR_PMS_TYPE));
break;
}
}

Now, I'm not sure what would be the best way to deal with thins kind of errors.
Maybe could add an optional retry argument to the read method.

@strange-v
Copy link

I've just started to use this library and it does work with PMS7003 on ESP32 (hardware serial).
AFAIK, ESP8266 has some issues with software serial.

@pczekalski
Copy link

pczekalski commented Feb 2, 2020 via email •
edited by avaldebe
Loading

@avaldebe avaldebe changed the title doesn't work with 7003 SoftwareSerial is broken Apr 15, 2020
@Matz88
Copy link

Matz88 commented Apr 15, 2020 •
edited
Loading

Same issue here with ESP8266, "Incomplete message header", you were mentioning the possibility to add a retry in the read, could you further explain? I can try

I have activated the debug and the following is the output:

12:25:43.019 -> Booted
12:25:43.019 -> PMS sensor on SWSerial
12:25:43.054 -> RX:2
12:25:43.054 -> TX:0
12:25:43.054 -> 424D 0004 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:25:43.159 -> Errors 1/1, waited 10 ms
12:25:43.159 -> Incomplete message header
12:25:53.096 -> 424D 0014 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:25:53.165 -> Errors 2/2, waited 11 ms
12:25:53.199 -> Incomplete message header
12:26:03.129 -> 424D 0014 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:26:03.199 -> Errors 3/3, waited 10 ms
12:26:03.234 -> Incomplete message header
12:26:13.133 -> 424D 0014 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:26:13.203 -> Errors 4/4, waited 10 ms
12:26:13.237 -> Incomplete message header
12:26:23.156 -> 424D 0014 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:26:23.224 -> Errors 5/5, waited 11 ms
12:26:23.258 -> Incomplete message header
12:26:33.180 -> 424D 0014 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:26:33.248 -> Errors 6/6, waited 10 ms
12:26:33.282 -> Incomplete message header
12:26:43.222 -> 424D 0014 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:26:43.291 -> Errors 7/7, waited 10 ms
12:26:43.324 -> Incomplete message header
12:26:53.250 -> 424D 0014 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:26:53.318 -> Errors 8/8, waited 11 ms
12:26:53.353 -> Incomplete message header

@Matz88
Copy link

Matz88 commented Apr 15, 2020

Further update: I have disabled one by one all the error triggered by the library to let the SW run till the end. I can see the raw numbers changing but the calibrated numbers are never !=0:

12:35:00.747 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:35:10.697 -> 424D 0014 0000 0002 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:35:10.766 -> Errors 1/4, waited 10 ms
12:35:10.800 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:35:20.736 -> 424D 0014 0001 0002 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:35:20.805 -> Errors 1/5, waited 10 ms
12:35:20.839 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:35:30.770 -> 424D 0014 0001 0002 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:35:30.838 -> Errors 1/6, waited 11 ms
12:35:30.873 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:35:40.782 -> 424D 0014 0001 0002 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:35:40.851 -> Errors 1/7, waited 10 ms
12:35:40.886 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:35:50.834 -> 424D 0014 0002 0003 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:35:50.902 -> Errors 1/8, waited 10 ms
12:35:50.937 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:36:00.853 -> 424D 0014 0024 00AC 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:36:00.922 -> Errors 1/9, waited 10 ms
12:36:00.957 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:36:10.910 -> 424D 0014 0033 00CA 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:36:10.978 -> Errors 1/10, waited 10 ms
12:36:11.012 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:36:20.935 -> 424D 0014 0035 00CD 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:36:21.005 -> Errors 1/11, waited 10 ms
12:36:21.040 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:36:30.953 -> 424D 0014 0016 002B 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:36:31.023 -> Errors 1/12, waited 10 ms
12:36:31.057 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:36:41.014 -> 424D 0014 0007 000E 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:36:41.049 -> Errors 1/13, waited 10 ms
12:36:41.084 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]
12:36:51.025 -> 424D 0014 0006 000C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
12:36:51.095 -> Errors 1/14, waited 10 ms
12:36:51.130 -> PM1.0 0, PM2.5 0, PM10 0 [ug/m3]

@avaldebe
Copy link
Owner

avaldebe commented Apr 15, 2020 •
edited
Loading

Looks like it goes deeper than this library

Here is the PMSA003 output of the debug sketch for

[env:d1_mini]
platform = espressif8266
board = d1_mini
build_flags = -D PMS_RX=D7 -D PMS_TX=D6
PMSx003 on SoftwareSerial
 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Errors 1/1, waited 1004 ms
Sensor read timeout
 424D 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Errors 2/2, waited 780 ms
Incomplete message header
 424D 001C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Errors 3/3, waited 783 ms
Incomplete message header
 424D 001C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Errors 4/4, waited 423 ms
Incomplete message header
 424D 001C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Errors 5/5, waited 422 ms
Incomplete message header

increasing the waiting time for a complete message from 1s to 5s deals with the timeout error,
but it fails to decode

PMSx003 on SoftwareSerial
 424D 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Errors 1/1, waited 2742 ms
Incomplete message header
 424D 001C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Errors 2/2, waited 850 ms
Incomplete message header
 424D 001C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Errors 3/3, waited 712 ms
Incomplete message header
 424D 001C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Errors 4/4, waited 424 ms
Incomplete message header
 424D 001C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Errors 5/5, waited 422 ms
Incomplete message header

The header is incomplete on the 1st message, but the next ones look fine. Explicitly waiting until the 32 bytes are available does not solve the incomplete message header error.

But with those 2 small changes on a small version of the esp3266 framework,
works fine

[env:d1_mini]
platform = espressif8266@2.3.0
board = d1_mini
build_flags = -D PMS_RX=D7 -D PMS_TX=D6
PMSx003 on SoftwareSerial
 424D 001C 0000 0012 0040 0000 0012 0040 0000 0000 0000 0000 0000 0000 9700 01E6
Errors 0/1, waited 5002 ms
PM1.0  0, PM2.5 18, PM10 64 [ug/m3]
N0.3    0, N0.5   0, N1.0  0, N2.5  0, N5.0  0, N10  0 [#/100cc]
 424D 001C 0000 0008 0009 0000 0008 0009 00C0 0040 0026 0022 0000 0000 9700 02AC
Errors 0/2, waited 5007 ms
PM1.0  0, PM2.5  8, PM10  9 [ug/m3]
N0.3  192, N0.5  64, N1.0 38, N2.5 34, N5.0  0, N10  0 [#/100cc]
 424D 001C 0000 0006 0006 0000 0006 0006 004E 001A 000F 000F 0000 0000 9700 01E0
Errors 0/3, waited 5006 ms
PM1.0  0, PM2.5  6, PM10  6 [ug/m3]
N0.3   78, N0.5  26, N1.0 15, N2.5 15, N5.0  0, N10  0 [#/100cc]
 424D 001C 0000 0002 0002 0000 0002 0002 001B 0009 0000 0000 0000 0000 9700 016E
Errors 0/4, waited 5007 ms
PM1.0  0, PM2.5  2, PM10  2 [ug/m3]
N0.3   27, N0.5   9, N1.0  0, N2.5  0, N5.0  0, N10  0 [#/100cc]
 424D 001C 0000 0000 0000 0000 0000 0000 0027 000D 0000 0000 0000 0000 9700 0176
Errors 0/5, waited 5007 ms
PM1.0  0, PM2.5  0, PM10  0 [ug/m3]
N0.3   39, N0.5  13, N1.0  0, N2.5  0, N5.0  0, N10  0 [#/100cc]

@avaldebe
Copy link
Owner

Looks like the failed decoding with espressif8266@2.4.0 is related to plerup/espsoftwareserial#63
downgrading the platform to espressif8266@2.3.0 or upgrading underlying SoftwareSerial library to EspSoftwareSerial@>=6.7.1 seems to work

;  downgrade the platform
[env:d1_mini]
platform = espressif8266@2.3.0
board = d1_mini
build_flags = -D PMS_RX=D7 -D PMS_TX=D6
;  upgrade SoftwareSerial
[env:d1_mini]
platform = espressif8266
lib_deps = EspSoftwareSerial@>=6.7.1
board = d1_mini
build_flags = -D PMS_RX=D7 -D PMS_TX=D6

@Matz88
Copy link

Matz88 commented Apr 15, 2020

Thanks, worked after downloading the latest SWserial and killing the one under AppData\Local\ !

avaldebe added a commit that referenced this issue Apr 15, 2020
@avaldebe
ESP8266 use EspSoftwareSerial@>=6.7.1, see #6
f4ea89e
@avaldebe avaldebe mentioned this issue Apr 15, 2020
Merged
@avaldebe avaldebe mentioned this issue Apr 20, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

SoftwareSerial on ESP boards avaldebe/PMserial
5 participants
@strange-v @Matz88 @avaldebe @yburkouski @pczekalski