Android Question AsyncStreams, non prefix, long messages

[yogie]

I use AsyncStreams in non-prefix mode for receiving bluetooth messages
(HC 05, controlled by a STM32). The messages end on chr(13), only then they are
complete. I observe that the messages are transmitted over bluetooth in pieces,
so I use a global buffer (aStrHlp). This buffer is filled as long as no chr(13) is received,
then the complete message is merged :

strNewData = aStrHlp & BytesToString(Buffer, 0, len, "UTF8")

and aStrHlp is cleared. For short messages (about 100 ... 150 byte) I can observe in the log
how everything works. But there are also longer messages with about 1600 bytes.
I can control this kind of messages in a terminal program (HTerm) and see the
correct end with chr(13).

In AStream_NewData (Buffer() As Byte) it does not work.
The buildup of aStrHlp is slow (??) and the complete message seems to have the double
length as expected. In release mode it does not run correctly either.

private Sub AStream_NewData (Buffer() As Byte)
    Private aStr As String
    Private strNewData As String
    Private len As Int = Buffer.Length
    
    If Buffer(Buffer.Length - 1) = 13 Then
        len = len - 1
        strNewData = aStrHlp & BytesToString(Buffer, 0, len, "UTF8")
        Log("new_data : " & strNewData)
        aStrHlp = ""

        For Each Target In Array(Main, EM_SerialBT_Test, EM_Scan2, EM_Frequency, EM_OffsetGain)
            CallSub2(Target, "UG12Message", strNewData)
        Next
    Else
        aStr = BytesToString(Buffer, 0, len, "UTF8")
        aStrHlp = aStrHlp &    aStr
        Log("new_data strHlp: " & aStrHlp)
    End If
End Sub

It seems that chr(13) is not / not always recognized.
Once again : in a terminal program I see the long message practically "immediately" and also chr(13) is present at the end.
I am grateful for any advice

 

[Erel]

Why aren't you using AsyncStreamsText?

 

[emexes]

It seems that chr(13) is not / not always recognized.

The chr(13) is not necessarily always at the end of a received block of bytes.

You can allow for this by eg:

Dim LineBuffer As String    'where we build up BLE bytes into complete lines

private Sub AStream_NewData (Buffer() As Byte)
    Private aStr As String
    Private strNewData As String
    Private len As Int = Buffer.Length

    '*** ADD RECEIVED BYTES TO LINE BUFFER ***
 
    Dim NewData As String = BytesToString(Buffer, 0, len, "UTF8")    'note that UTF8 only nicely handles byte values 0..127 ie 7 bit ASCII values
    LineBuffer = LineBuffer & NewData
    Log("new_data: " & NewData)
 
    '*** SLICE OFF AND DESPATCH COMPLETE LINE(S) FROM LINE BUFFER ***

    'speedup: if NewData contains chr(13) then    'rather than repeatedly and unnecessarily searching entire (longer) LineBuffer'
    do while true
        dim P as int = index of chr(13) in LineBuffer
        if P = -1 then
            exit
        end if
 
        Dim CompleteLineExcludingCR As String = leftmost P characters of LineBuffer
        LineBuffer = LineBuffer from after character P ie the CHR(13)
 
        For Each Target In Array(Main, EM_SerialBT_Test, EM_Scan2, EM_Frequency, EM_OffsetGain)
            CallSub2(Target, "UG12Message", CompleteLineExcludingCR)
        Next
    loop
    'speedup: end if

End Sub

 

[Erel]

1. Don't use activities at all and especially not with projects dealing with communication.
2. Use StringBuilder to concatenate strings. Your current code is very inefficient.
3. Use AsyncStreamsText: https://www.b4x.com/android/forum/t...n-working-with-streams-of-text.27002/#content

 

[yogie]

Thanks for the really quick responses.
I started this project in 2018 and can only continue now (retired).

@emexces : thanks, will test it.
@Erel: I didn't know AsyncStreamText yet, will have a look at it

 

[emexes]

@Erel: I didn't know AsyncStreamText yet, will have a look at it

Erel's right: AsyncStreamsText is a better solution, provided that your data doesn't include ASCII 10 (line feed).

Also, note that AsyncStreamsText interprets the incoming bytes as UTF8, which means that ASCII byte values 0..127 will be fine (except for end-of-line bytes 10 and 13), but byte values outside that range will be lost or misdecoded into other Unicode characters.