Sure, so you’re likely sending the same data that you printed to the debug output? And as apparently that debug output did not need any conversion to print it, that buffer seemed to be holding ASCII text? Unless the debug output showed quite a lot of garbage due to non-printable characters.
Anyway, @hediger and future readers: think twice before delegating a serial stream to LoRaWAN as is. If the serial stream is using ASCII text, then depending on the used characters, applying some inversed Base64 or maybe even Base32 might help decrease the payload length. But still then a serial stream, as is, might simply include data one does not really need to send at all. Also, when boldly forwarding data without interpreting it: how to determine which data can be dropped if the serial data exceeds the limits?
In many cases it will be better to have an intelligent bridge from serial to LoRaWAN, not some dumb forwarder. Or not use LoRaWAN at all. Just make sure to give it some thought before implementing anything.