Repository navigation
Missing Characters on USB port #124
Description
I am facing issue that sometimes number of characters are not properly received. Using serialPort.readString(serialPort.getInputBufferBytesCount(), 150) Method.(Maven Version 2.8.0) I tried using multiple values of timeout but still either two different messages are received in correctly. For ex:
Expected Data:
[011131FF8300000F0000000000420001000000e9]
[001131FF8300000F000000000042000200000097]
Actual Received Data:
[011131FF8300000F0000
000000420001000000e9]
[001131FF8300000F000000000042000200000097]
Or
[011131FF8300000F0000000000420001000000e9]
[001131FF8300000F000000000
042000200000097]
Activity
tresf commentedon Apr 16, 2022
I'm not familiar with what could cause this, but I wanted to reply to acknowledge the bug report so you know that the project is still active.
tresf commentedon Jan 9, 2025
@danishmhmd I've looked over this bug report and I believe the library is working to the best of it's ability. I will elaborate:
If I'm reading your problem description properly, the expected and actual results do not appear to be missing characters, but rather appear in two separate chunks. Can you please confirm? I am basing this observation off of the fact that your expected and actual results are identical.
The way that
readStringworks is it callsreadBytes, which is basically just one of two native calls depending if you're on Windows or on *nix:jssc/src/main/cpp/windows/jssc.cpp
Line 274 in 4fcddd8
jssc/src/main/cpp/_nix_based/jssc.cpp
Line 656 in 4fcddd8
In the case of Windows, I believe it attempts to strictly send bytes back that are the size requested, but I'm not sure if this is 100% reliable. @hiddenalpha may be able to shed more light on this.
In the case of *nix, I believe it will send back only what could be read.
The reason I'm skeptical that this is an actual bug is because since I started using JSSC, I've always had to use byte delimiters (or length) in my application to detect when a stream was finished (I've never relied blindly on the result of readBytes) so I suspect this is a problem that all implementers have to work around.
Two years later I'm sure that you (@danishmhmd) have either chose a different library or coded these workarounds yourself, so I'm curious as to your thoughts, but at initial glance, I do not believe this to be a bug with the library, at least not one that we can easily and reasonably solve.
A response is required or this bug report will be closed.