That was exactly what I said - your source has to produce a stream of data appropriate for LoRaWAN, it cannot simply ignorantly toss serial characters over the fence.
Once you have a serial source producing appropriate messages (length, rate, degree of redundancy), you should look at improving the interaction between the generator and the LoRa stack.
Probably you want to do this with a packet structure, ie, you have a reserved start sequence, then a byte count, then the actual payload, and then perhaps a checksum or terminating.
An even simple way to do this is to make the exchange on the serial line by printable ascii, with a hexdump of the actual message bytes, ie something like “SEND 2a 45 3c 59\n”. This not only solves the framing problem, it also gives you something that can be readily monitored during debug with a serial terminal.
The payload is a hex dump only on the serial line - the raw binary values the hexdump represent are what get put into the LoRaWAN packet assembler.
Also keep in mind that the maximum legal (in some places) or sensible (everywhere) LoRaWAN packet depends on radio conditions, so you may need feedback from the LoRaWAN stack to the data source.