Missing last byte from Serial ReadAll

I just realized it’s actually the last TWO bytes missing from the message received… one digit from the Time column and the last chr(13)

Can you get a serial terminal, like coolterm, and display the serial traffic in raw hex values? That may tell you what a message burst looks like and then you can decompose from there.

Same issue with cool term… last two bytes missing…

https://imgur.com/a/gjRKW5I

I’m lost here… Windows HyperTerminal works perfect, but any code or app I tried compiled in xojo fails to receive the last two bytes of the serial data. (those two bytes arrive later in the next burst, which lacks its last two bytes as well.).

Also, since we’re in the subject… could anyone explain me where this difference come from ?

https://drive.google.com/open?id=0B3LQKr6mspNPeklLdmxqRUotQUk

I’m doing something similar except reading from the serial port buffer for a total period (around 3-5minutes) using a Timer to read the buffer after every 0.5 secs, appending to a string, splitting the data then assigning each line to an array for later evaluation.

Timer Action Event (fires every 500ms)

[code]
//Read ALL available data from the serial port buffer
tempBuffer = Serial1.ReadAll(encodings.ASCII)

//Add the new data to incomingData
incomingData = incomingData + tempBuffer[/code]

After the reading period (3-5mins) has finished (ie. user presses the stop button):
Method: EvaluateRecordedData

[code]
dim grams as Double

//split the recorded data and save into an array (as string)
tempArray = incomingData.Trim.Split(EndOfLine.Windows)

'-----------------------------------------------------------------------

//read from tempArray
//then write to new array recordedGramsArray (as double)

redim recordedGramsArray(tempArray.Ubound)

//read data from tempArray
for i as Integer = 0 to tempArray.Ubound
grams = (val(tempArray(i)))

//write grams to array
recordedGramsArray(i) = grams

next[/code]

It may not help with what you’re doing but I found Serial.LookAhead didn’t work reliably, nor did using DataAvailable. Therefore with this method, I’m in control and decide when to read the serial buffer data, then evaluate later.

Like I said, it may not suit your purpose exactly but there may be something useful there.

Thanks Steve, Ill give It a try and let you know.
But I am already heading to visual basic to create some sort of helper app to read the serial port. I’m quite pissed off with xojo. All the xojo alternatives I’ve tried done by me or someone else failed while the demo project of vb6 to read the serial port worked fine first time.

I wouldn’t give up yet - Xojo has a great community.

My experience is limited, but I’m sure someone will be able to help you solve your particular issue.

[quote=394130:@Roman Varas]I’m lost here… Windows HyperTerminal works perfect, but any code or app I tried compiled in xojo fails to receive the last two bytes of the serial data. (those two bytes arrive later in the next burst, which lacks its last two bytes as well.).

Also, since we’re in the subject… could anyone explain me where this difference come from ?

https://drive.google.com/open?id=0B3LQKr6mspNPeklLdmxqRUotQUk[/quote]

Coolterm appears to be capturing the wrong 1st Byte in addition to missing the last byte of 0D.
1st Byte that works (WinTerm) = 2E
Coolterm incorrect 1st Byte = 0C

Can you post a screen shot of the Xojo IDE debugging the serial buffer?

[quote=394170:@Roman Varas]Thanks Steve, Ill give It a try and let you know.
But I am already heading to visual basic to create some sort of helper app to read the serial port. I’m quite pissed off with xojo. All the xojo alternatives I’ve tried done by me or someone else failed while the demo project of vb6 to read the serial port worked fine first time.[/quote]

For what is worth, I use serial in Xojo in numerous applications and haven’t had issues. I suspect your fighting something else. Could you post your project so we can help?

I suspect it might be the serial port properties. Please check those and ensure they match the device you are communicating with. Even if they do, start playing with those settings to see if that helps (stop bits CTS Parity, bit, etc.).

[quote=394178:@Joseph Evert]For what is worth, I use serial in Xojo in numerous applications and haven’t had issues. I suspect your fighting something else. Could you post your project so we can help?

I suspect it might be the serial port properties. Please check those and ensure they match the device you are communicating with. Even if they do, start playing with those settings to see if that helps (stop bits CTS Parity, bit, etc.).[/quote]

Also Cool term is showing UNIX CRLF - Carriage Return (OD) & Line Feed (0A) or CHR(13)+CHR(10) vs. hyper term is showing just 0D (CHR(13)). This should be an encoding issue but I’d like to see the Xojo debug if possible. Most likely you will have this same issue with C#.

So, guys, first thanks a lot for helping out!

@Mike Cotrone : Mike, what you are seeing in the google drive link I posted is the data captured by Cool Term, and copied (copied and pasted in a terminal window into a xojo project). Don’t ask me why it differs.

@Joseph Evert : The ACTUAL project I can’t paste it here because it’s huge. But this simple code in DataAvailable event handler already fails to capture the last (or last two) bytes… I do suspect, as well it’s something about the properties… but the varaibles are many and the possible combinations are many, so it’s impossible to go with try and failure method. Specially because the serial data comes from phone calls I can not control, and happen sporadically. What I did check is that the baud rate (obviously) , data bit , parity and stop bits were the same in HyperTerminal and evey single Xojo app I tried or code test I did.

Dim s as String s=Serial1.ReadAll() TextAreaRs232Rx.AppendText(s)

It tried cool term and a lot of variations like this

https://blog.xojo.com/2015/03/23/guest-post-serial-communications-with-xojo/

Different approaches with ReadAll, Read, LookAhead, DataAvailable… every time I miss the last two bytes. The only thing i Did not try yet is what steve suggested, but I don’t have much faith.

What happens with Xojo is that the last two bytes of every message don’t even show up in the buffer UNTIL another message comes. This does NOT happen using HyperTerminal or another app. So, It’s either a xojo thing, or a xojo-setup related thing. All the other factors (i guess) are discarded.

I could post every single bit of code I tried… For example this…

[code]Dim s as String

Dim CallData as String

while me.BytesAvailable > 0

s=me.ReadAll() // READ SERIAL

CallDataRaw =  CallData+ s

me.Poll

wend

TextAreaRs232Rx.AppendText( CallData)[/code]

or this…

[code]// Get last END OF LINE
dim c as string = chr(13)+chr(10)
dim s as string = Me.LookAhead(Encodings.ASCII)
dim PositionLastEOL as integer
Dim MsgLength as integer = len(s)
Dim CantidadDeOcurrencias as Integer = CountFieldsB(s, c)
PositionLastEOL = MsgLength- len(NthField(s, c, CantidadDeOcurrencias))

// Get data up to last EOL
Dim data as String = (Me.Read(PositionLastEOL,Encodings.ASCII))

TextAreaRs232Rx.AppendText(data)[/code]

or this

/// DONT GET DATA UNLESS ITS TERMINATED

[code] Dim buffer as String = me.LookAhead(Encodings.ASCII)

Dim LastByte as integer = AscB(RightB(buffer,1 ))

if LastByte = 13 then // chr(13)

buffer = me.LookAhead(Encodings.ASCII)
LastByte = AscB(RightB(buffer,1 ))


Dim s as String
s=Serial1.ReadAll(Encodings.ASCII)
TextAreaRs232Rx.AppendText(s)

end[/code]

At this point I cant confirm that all of the above failed in the same way. In between bursts there is always the last 2 bytes missing.

So you’re not actually losing data, it’s just coming in differently than you expect. You are not guaranteed, nor should you expect, to get a complete message in DataAvailable. If you need to parse out “packets” of information, you should buffer the info and use Instr() to find the chr(13) and peel out the individual lines. Don’t assume the delimiter will be at the end of the string from ReadAll. It probably won’t be.

Hey Tim,

“you should buffer the info and use Instr() to find the chr(13)”

That’s pretty much what I am trying to.
In the examples I posted (and tried) all the input from the COM port was gathered in a text area which replaces (as a debugging tool) a long string.

I am not trying to get a full message in dataavailable. I understand. But please, observe that with hyperTerminal all data reachs the input in one burst. That’s what I want.

This would work if you used

dim c as string = chr(13)

as your delimiter seems to just be a carriage return with no line feed.

I will install another Terminal software to make sure this is true (your delimiter seems to just be a carriage return with no line feed) as I’ve seen inconsistencies depending on where I see the data. See Mike Cotrone’s post. And also to check If the data is split there or not.

Then I will try again the code you suggested, considering the actual delimiter in the data.
Then I will also try Steve’s suggestion.
That’s my plan for the weekend.
I’ll let you know how it goes.
Thanks
R

The hex’0C’ at the beginning suggests that you’re reading a log output intended for a serial printer. hex’0C’ is Chr(12) is form feed/new page, which is followed by the headers.

The hyperterm screen grab looks to be missing the last character as well. I suspect hyperterm is also silently discarding the line feed since that would be necessary for a simple serial printer to format properly.

Missing characters are usually a flow control problem.

I think that John is onto something there. You really need to know what data is being delivered to the serial port - unfortunately we (most of us) don’t have your hardware device to do some “real world” tests. I’ve used Notepad++ to help view characters that are not easily view-able and therefore make sense of the “real” data.

I wouldn’t bother with testing my solution, I doubt if it would suit your needs. It was just put out there as a possibility to think about.

It’s always difficult to post code regardless of the forum. There are intricacies, peculiarities and particular requirements that only YOU fully know and understand. Sometimes it’s hard to define and explain them, sometimes the reasons are commercial constraints, sometimes it’s other unknown quantities, etc…

I don’t think that there has been a question that I’ve asked on this forum that has not been resolved to a satisfactory result.

I’m confident your problem will be resolved.

Here are screenshots of the captured data with (on top) RealTerm and (below) HyperTerminal as seen on notepad++
These are examples of complete data, caputred ok with no end bytes missing.

https://drive.google.com/open?id=1HkYka84gkKmy-SEDVsQIthpEsunBYBo5

I think at this point is safe to assume that the line endings are chr(10)+chr(13)… am I ok there ?

Also in the upper pic the port settings can be seen. So I tried to configure the port in Xojo like that (19200, 8, none, 1, XON off, DTR off, RTS off). Until now… I received nothing… I’ll wait some more time because I have no way to know if there were no phone calls or the port is missconfigured.

Thanks.

If you want bytes you probably wanna set the encoding to nil for the string and check with Chr(&0D) or so. Or try ascii encoding.

Probably the last 2 bytes are not read, because you don’t have a visable character.

See if LenB returns the right lenth for the string.