LabVIEW
Regarding .wav file to readable string conversion
I think we are all stumbling around in the dark. We need to know WHY it needs to be done this way. I feel like this could be really simple if we knew the reasoning behind this scheme.
@jwscs wrote:
have a look at this thread https://forums.ni.com/t5/Example-Program-Drafts/LabVIEW-Utility-VIs-for-Base64-and-Base32Hex-Encodin...
base64 encoding is the way attachements in emails are encoded,
which is a reliable way to transfer binary data over channels allowing only ascii, like tcp
TCP/IP is a byte stream protocol. Nothing in the TCP/IP specification mandates use of ASCII at all. Higher level protocols such as HTTP do use ASCII as transfer format, but it is totally fine to transmit binary bytes over TCP/IP too. What your protocol specification needs to do, is to define a certain way of encoding the data in such a way, that the receiver can reconstruct it properly. This could be like what HTTP does, where the principal delimiter is a carriage return (and a double carriage return separates the header from the body) with either another double carriage return for the end of the body or an optional Length attribute line in the header that defines the number of bytes to receive for the body (and several other optional and seldom used variants) or it can be a binary protocol where you first send a header with length and type information in binary or text format and the actual data load as a byte array.
The OP has so far not motivated the actual use nor described in clear enough words what the real problem is, to make any meaningful recommendations for how to go about this and if there is even any need to convert at all. Maybe all he needs to use is a simple Byte Array to String Node, which is basically a NOP in LabVIEW but does change the wire color from blue to pink, but without more explanation this recommendation could be leading a beginner into a dead end, just as any other possible suggestion.
