Serial port binary buffer config serves string

Hello everyone,
I am struggling with the proper configuration of the node-serialport node.
While it generally works very well, I have not been able to make it serve a binary buffer.

This is my setting:

If I attach a function node and print out the msg.payload typedef, I get String as answer.

Can anyone please give me some hint on what I need to do to really have a binary buffer/stream in the following node?

Thanks a ton,
Andrea

Rather than feeding it into a function node feed it to a debug node and see what it shows.

The result doesn't change, it seems to be still string:
image

What is being sent are indeed bytes of a file that contains text, but some binary header is put in front of it and I need to be able to get that all as a binary buffer.

Start node-red in a terminal and post the log here (it should have the Welcome to node red message in it). That will let us see what versions of the various tools are in use. Also which version of the serial node are you using?
What hardware and operating system are you using?

Thanks for the reply Colin.

Here my terminal startup welcome:

13 Nov 08:40:30 - [info] Node-RED version: v1.0.2
13 Nov 08:40:30 - [info] Node.js version: v8.10.0
13 Nov 08:40:30 - [info] Linux 4.15.0-66-generic x64 LE
13 Nov 08:40:30 - [info] Loading palette nodes
13 Nov 08:40:31 - [info] Settings file : /home/hydrologis/.node-red/settings.js
13 Nov 08:40:31 - [info] Context store : 'default' [module=memory]
13 Nov 08:40:31 - [info] User directory : /home/hydrologis/.node-red
13 Nov 08:40:31 - [warn] Projects disabled : editorTheme.projects.enabled=false
13 Nov 08:40:31 - [info] Flows file : /home/hydrologis/.node-red/flows_hydrotick.json
13 Nov 08:40:31 - [info] Starting flows
13 Nov 08:40:31 - [info] Started flows
13 Nov 08:40:31 - [info] Server now running at http://127.0.0.1:1880/
13 Nov 08:40:31 - [info] serial port /dev/ttyACM0 opened at 115200 baud 8N1

The version of node-red-node-serialport is 0.8.8.

I am running xubuntu 18.04.3 LTS.

The hardware is a BM70 bluetooth LE chip configured to work in UART mode.

Well I can't see anything wrong there, your version of node.js (8.x) is old and going out of support at the end of next month but it is still a supported version. It might be worth upgrading that to 12.x. Other than that I think maybe it needs @dceejay to comment.

[edit] If you do upgrade nodejs then after doing that re-install node red (sudo npm install -g --unsafe-perm node-red) and go into your .node-red folder and run npm install. That rebuilds everything for the new version.

Thanks for the edit. But I saw it only after fighting with the upgrade (I had to reset) :-/

Now I have:

13 Nov 10:18:07 - [info] Node-RED version: v1.0.2
13 Nov 10:18:07 - [info] Node.js version: v12.13.0

Even if I am happy to have upgraded, the result is still a string.

Well it looks like a bug to me. Have to wait for a developer to comment I think.

If I use a simple flow like this

[{"id":"b9a0fc68.58d13","type":"serial in","z":"5051cb93.cf0d34","name":"","serial":"43cf8569.5fe10c","x":500,"y":700,"wires":[["a76bf97e.1b2e88"]]},{"id":"a76bf97e.1b2e88","type":"debug","z":"5051cb93.cf0d34","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":780,"y":700,"wires":[]},{"id":"43cf8569.5fe10c","type":"serial-port","z":"","serialport":"/dev/tty.usbserial-14240","serialbaud":"4800","databits":"8","parity":"none","stopbits":"1","waitfor":"","newline":"1000","bin":"bin","out":"time","addchar":"","responsetimeout":"10000"}]

I get

Can you share the snippet of flow you are using ?

(I'm using a simple USB GPS device - don't have any bluetooth serial ports)

Hi @dceejay, thanks for your feedback.

I am using the exact same flow as yours. Just the baudrate changes.

But the payload of my debug is a String, no matter what I try to do.

Actually, what makes things really strange, is that if yours is a GPS, then the stream si actually a NMEA strings stream, so I would rather expect yours to fail in conversion, not mine :slight_smile:

I am not sure what is going on and sadly I am not able to give you something to reproduce the issue.

I will now try to replicate the same configuration with node outside of node-red, to see if I find something.

If I find something worth to mention, I will be back.

Andrea

just to double check can you share your flow anyway ? Thanks

Yes, sure, thanks for asking.

Here it goes:

[{"id":"c6ea21c5.72c9e8","type":"tab","label":"send file flutter -> raspberry","disabled":false,"info":""},{"id":"7615da85.9ee8c4","type":"serial in","z":"c6ea21c5.72c9e8","name":"BM70","serial":"5cab4e54.8562c","x":210,"y":140,"wires":[["43740662.731f"]]},{"id":"43740662.731f","type":"debug","z":"c6ea21c5.72c9e8","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":500,"y":300,"wires":[]},{"id":"5cab4e54.8562c","type":"serial-port","z":"","serialport":"/dev/ttyACM0","serialbaud":"115200","databits":"8","parity":"none","stopbits":"1","waitfor":"","newline":"1000","bin":"bin","out":"time","addchar":"","responsetimeout":"10000"}]

Thanks

I notice the serial port node has just been updated to 0.9. I don't know whether that is significant.

actually now 0.9.1 - :wink: - hopefully not - but bumped the underlying library it so it compiles ok on node12 and electron. - So yes maybe worth updating.

Hi @dceejay,@Colin, I think I found the issue.
I would have not if I didn't import @dceejay's flow. Which made me notice that when importing a flow, the serial port configuration is added to the list of available configs.
Even if the name of the serial port setting and name is the same (whilst the input/output configuration not), it is added with the same "name".

I think this might bring some conflict. In my case one of the two was configured with String (a leftover from previous tests) and the one I was using instead as binary. But it still was returning Strings.

Once I removed all serial port config but one and set that to binary, the stream finally got binary.

Now I am asking: does this reconstruction of events even make sense? :slight_smile:

1 Like

Yes it makes sense (sort of) - as in I can believe that could happen.