Sending binary frames?

[stickystyle]

I realize this is called 'serial-port-json-server', but is there any way to send binary data through the websocket? I see the methods for sending files that exist on a filesystem for the arduino firmwares, but what about adhoc data?

My use case is that the barcode scanner that I'm interfacing with requires sending ACSII control characters back to it, like 0x1B 0x37 0x2C (ESC 7 ,). Is there a way to do this that I'm perhaps missing?

[chilipeppr]

Well I think Unicode is natively supported but I have not tried. You could
also base64 encode and then decode in spjs by writing a new buffer or
adding a new command like sendbinary
On Jun 15, 2016 6:51 AM, "Ryan Parrish" [email protected] wrote:

I realize this is called 'serial-port-json-server', but is there any
way to send binary data through the websocket? I see the methods for
sending files that exist on a filesystem for the arduino firmwares, but
what about adhoc data?

My use case is that the barcode scanner that I'm interfacing with requires
sending ACSII control characters back to it, like 0x1B 0x37 0x2C (ESC 7 ,).
Is there a way to do this that I'm perhaps missing?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#14, or mute
the thread
https://github.com/notifications/unsubscribe/AHidbRiI7HSeXGP5QkOTo6KJfgnZwJzYks5qMANIgaJpZM4I2YLW
.

[seyyah]

I tried on the test code (thanks to @johnlauer) ,

websocket.send('sendjson  {"Cmd":"Write", "P":"/dev/ttyUSB1","Data": [{"D": "\x31"}]}')

it is successful. But below code produced an parse error,

websocket.send('sendjson {"Cmd":"Write", "P":"/dev/ttyUSB1","Data": [{"D": "\x01"}]}')
// OR
websocket.send('sendjson {"Cmd":"Write", "P":"/dev/ttyUSB1","Data": [{"D": "\u0001"}]}')

I receive this response/error message,

RESPONSE: {"Error" : "Problem decoding json. giving up. 
json: {"Cmd":"Write", "P":"/dev/ttyUSB1","Data":[{"D": "�"}]},
err:invalid character '\x01' in string literal"}

And also, when the serial port data arrives, there are also problems with this. For example real sended values are \xFD\x1\x41\x81\xC1\xFE, but received data via serial-port-json-server are \xfffd\xfffdA\xfffd\xfffd.

When hex value is greater than \x7f, i received the \xfffd (messed up). In unmarshal decoder, it is commented as,

When unmarshaling quoted strings, invalid UTF-8 or invalid UTF-16 surrogate pairs are not treated as an error. Instead, they are replaced by the Unicode replacement character U+FFFD.

As @stickystyle implies, it is missing for ASCII control characters. But I do not know where to start and the size of the job. Thank you for your effort in this excellent work @chilipeppr etc.

[DanielJoyce]

Because you are sending the cmd as JSON, when its parsed on the server side, its going to try and parse it as utf8 which corrupts the data. JSON is a text format.

Something like this will need to be added:

'sendjson {"Cmd":"Write", "P":"/dev/ttyUSB1","Data":[{"D":"SGVsbG8gV29ybGQK", "Base64":"true"}]}'

In this way, the binary data encoded as base64 will survive the utf8/json decoding unaffected, and then the server knows the payload needs to be further base64 decoded and sent to the serial port

[DanielJoyce]

In fact you will have this problem in general over WebSockets as they will be sent and encoded/decoded as utf8. So even the normal send command won't work. The server should support base64 encoded data, and send it on as-is.

Something like this:

send /dev/ttyACM0 SGVsbG8gV29ybGQK base64

[DanielJoyce]

Working on this right now....

[DanielJoyce]

Alright. Got it working for the SendJson case.

[DanielJoyce]

Hmm, there is ambiguity in the send case, I'd have to clean up the code, and decide on how to specify "base64" encoding as different choices would make the literal string 'base64' difficult to send to a client if that is truly the value you want to send, and the data really isn't encoded.

I will clean up the patch and get a pr in.

[DanielJoyce]

sendjson working and PR #31 available

[DanielJoyce]

Ugh, the problem of receiving binary data still exists. Hmm, how to handle?