Node Red Serial Port Maximum Baud Rate

Hardware
1

I did a quick search and did not find the answer.

The Serial node gives the option of maximum115,200 Baud rate. However, I do see an option of "Other" Baud rate from the Serial node. Does it mean that I might be able to use a higher Baud rate?

So the question is "can we use a higher baud rate such as 230,400 with the Serial node?

2

At least on Linux and OS X the underlying library should support higher baud rates. I didn't find any clear documentation of the supported rates but I found this piece of code from the bindings code to native libraries:

int ToBaudConstant(int baudRate) {
  switch (baudRate) {
    case 0: return B0;
    case 50: return B50;
    case 75: return B75;
    case 110: return B110;
    case 134: return B134;
    case 150: return B150;
    case 200: return B200;
    case 300: return B300;
    case 600: return B600;
    case 1200: return B1200;
    case 1800: return B1800;
    case 2400: return B2400;
    case 4800: return B4800;
    case 9600: return B9600;
    case 19200: return B19200;
    case 38400: return B38400;
    case 57600: return B57600;
    case 115200: return B115200;
    case 230400: return B230400;
#if defined(__linux__)
    case 460800: return B460800;
    case 500000: return B500000;
    case 576000: return B576000;
    case 921600: return B921600;
    case 1000000: return B1000000;
    case 1152000: return B1152000;
    case 1500000: return B1500000;
    case 2000000: return B2000000;
    case 2500000: return B2500000;
    case 3000000: return B3000000;
    case 3500000: return B3500000;
    case 4000000: return B4000000;
#endif
  }
  return -1;
}

By looking at the code it would seem that on OS X the maximum is 230400 and on Linux up to 4Mbps.

So I would expect the values from the above listing to work (given the hardware in use supports them).

3

I am not up to date with UART hardware, but I think you would also have to look at the capabilities of the hardware it is running on.

4

Simple way to find out. Try it.

1 Like
5

[quote="ristomatti, post:2, topic:33684"](given the hardware in use supports them).
[/quote]

But yep like Dave said, just try. Although if data integrity is paramount, I would recommend a lot of testing on the upper speed limits of the hardware at either end.

6

Thanks ladies and gentlemen. Yes the maximum also depends on the hardware. I will give it a try today and keep you updated :slight_smile:

7

OK I have the test result:
The maximum baud rate supported by the Serial port node is 230,400.

I will do more testing to make sure that everything is stable at this speed tomorrow.

If I set up the baud rate to the next level (460,800), then no data can be read at the moment.

8

That is possibly only the case for your hardware/OS. Other systems may behave differently.

9

I agree. I feel my well researched answer should have earned me that nice green badge. :innocent:

10

How did you test this BTW? Could there have been another bottleneck? Like debug node printing or something like that. Is the hardware capable of 460800bps?

11

Note: this is not a restriction of the node per se - more the underlying drivers and hardware.

12

The transmitter supports up to 921,600 baud rate. I match transmitter and receiver's baud rate and start from 921,600. There is no data coming out from the serial port until 230,400.

Yes you deserve the green badge too :slight_smile: But there is only one and my test gave the exact number :stuck_out_tongue:

13

Yes I agree with you. I believe that modifying the underlying driver could make the baud rate go higher. I checked PiGPIO serial port driver and it supports up to 230,400 baud rate. But I am not sure if the serial port node is written based on this driver.

A side note, the dashboard real-time chart makes the system very slow and crash the system when the data rate is high. The only solution is to restrict the incoming msg. I feel a strong need to upgrade the chart in the dashboard :blush:

14

The serialport node is based on the serialport npm package.

Yes the chart can easily get over overwhelmed if it has too many points to shuffle too quickly. So yes showing less points, either by filtering or dropping the visible number, helps.

Yes other charts will probably perform better.

15

What time range have you specified for the chart, how many lines are on it and how often are you adding data points? If you have multiple charts then what are those figures for each?

16

3 minutes range. 12 lines so far. I set a limit of 5 msgs per second, so there are only 5 lines updated in a second.

The other charts are updated more than 3 seconds each time, and they don't have impact on the performance.

17

Do you mean a total of 5 messages/second or 5 messages/second for each line? I think you mean the former, are you sure have you checked that is actually what is happening, it might be easy to mis-configure the node doing the delay so it is not doing what you think.
Even if it is the former that is still quite a lot of work for the browser shuffling the data down five times every second. What hardware are you running on? Are you running the browser on the same machine as node-red? If yes, then what happens if you move the browser to a different PC?

Also what do you mean by "crashing the system"?

18

Yes I meant the former. I am sure that there is no mis-configuration on the delay (other configuration such as 5 msgs per line will instantly crash the system). Node red is on Raspberry Pi 3B. I am using a browser on a latest Dell XPS i7 Desktop(A browser at Raspberry Pi 3B is super slow). Very fast LAN too. When you think about it, 5 msgs/second update is really slow. I used 20MS/s sampling rate and instant graphic display software 20 years ago :joy: Personally, I would love to pay for an upgrade of the chart in the Dashboard, since it is so easy to use :joy:

"Crashing the system" means that the browser at the fast desktop shows "Losing connection" and "trying to re-connect". Raspberry Pi 3B has 120-130% CPU usage and not responsive.

Sorry we have left the original topic :blush: It might be a good idea to open a new thread asking for the improvement of the chart in the dashboard :stuck_out_tongue:

19

Not in a browser I suspect.

The first thing I would do is to upgrade to a pi4. That should give you a dramatic improvement for minimal cost.

20

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.