Serial baud rate. (114K vs 57K vs Lower?)

[PizzaProgram]

Since I've upgraded to latest firmware, I'm experiencing lot's of disconnecting / unresponsiveness.
So I'm wondering:

• is it possible that the new, higher default value at the example is responsible for this?

#else 
	Firmata.begin(115200);
#endif  

1. The "host" (Raspberry Pi 4) is connecting to the PRi Pico via 3m USB cable
2. The JavaScript program there (called firmata-io ) is initializing the connection via 57K

So how does it work in reality?

• is the host adjusting itself to higher speed after connection?
• is it asymmetric ?
• can I set lower speed on both sides ?
• Is it enough to set on one side to increase stability?
• can I activate any: Parity bits + Xon-Xoff handling?

[pgrawehr]

The new default is 115.2K. I never had any problems with this, and a 3m cable shouldn't be a problem either. I would expect problems only if the cable goes to the dozend of meters.

• You do need to set the same speed on both sides. There's no automatic detection implemented. There are some Uart chips that can do that, but ASFAIK the Arduino doesn't support auto-speed-detection. So whatever is set in the firmware, you also need to set in your javascript program.
• The communication is asynchronous - both ends can send simultaneously. I've seen some cases where this causes echos on the wire, but usually not with an RPI.
• Yes, you can set it to lower speeds, they just need to be equal on both sides
• I never tried to use flow control measures. Parity might work, Xon-Xoff probably not, because it interferes with the binary protocol. Xon-Xoff is intended for ascii communication only.

You should look for possible causes of the connection issues, such as erroneous parsing of data, or sending incomplete packets.

[PizzaProgram]

Is there a way to ask for the speed from the host side (Rpi / Windows) about the firmata's current firmware connection speed?
(So the host could adjust to it = reconnect.)

Actually I'm thinking about, what a nice new feature would be, if firmata would send a 2th line by default after:
Firmata.sendString(F("Booting device. Stand by..."));

Something like:

{"baud":57600,"data":8,"par":2,"stop":1,"flow":"none"}

---

I never tried to use flow control measures. Parity might work, Xon-Xoff probably not, because it interferes with the binary protocol. Xon-Xoff is intended for ascii communication only.

During my 30+ years trying to solve serial communication errors as IT manager + programmer I came to these conclusions:

• Parity should be always a: "MUST TURN ON" standard. Usually I use: "even". (not odd)
  (Without that I always had troubles. So I really not understand why is default the opposite.)
• DTS/RTS or XonXoff helped also a lot to stabilise communication.

Question:

• do You think enabling RTS/CTS flow control would be possible?
• or USB-serial (and wifi-serial) are actually using "3-wire standard" ?
• How do I set these values on Firmata's side?

[PizzaProgram]

One more thing I've found :
Setting RTS/CTS on the host site will not work, because the underlying "node-serialport" code can not properly handle it. See:
serialport/node-serialport#2710

So, (answering my own question,) setting on Firmata's side only would not matter anyway.

[pgrawehr]

Many hardware devices these days do not support RTS/CTS any more, as only 3 wires are actually connected. Also, communication problems are rarely caused by anything that could be helped with flow control, as speed is not an issue. 115.2 K is slow in todays terms, even for a microcontroller. Data corruption usually occurs due to noise on the lines, which should be prevented by better shielding, not by flow control. Most protocols used on serial ports also include some kind of checksum to detect such errors. This is however not the case for firmata.

[PizzaProgram]

This is however not the case for firmata.

Exactly that's why I'm suggesting to improve that!

How about:

• After Firmata has sent it's protocol version to host, (using default 57K baud rate,)
• this new version should send a second line, giving infos in JSON format (or including it in "capabilities")
• Than It should listen for "reconnect" protocol by default, (I think there is already one)
• and if the host sends new baud + parity (Default: EVEN parity)
• than it should reconnect.

My main problem is, that nor Firmata, nor the host side can properly handle situations, where serial transfer is stopping.
I've found this code at the .cpp file:

void FirmataClass::begin(long speed)
{
    Serial.begin(speed);
    Serial.setTimeout(0); // ???

[PizzaProgram]

I've made a small test, to measure actual speed, if I change original connection baud rate.

The result:

It does not matter what speed I set at the beginning. (Even as low as 2400.)

SerialUSB is always near 1Mbit on RPi Pico.

1000 * 1424 bit -> 1584ms elapsed = 904126 baud

setup() {
...
  unsigned long t1, t2 = 0;
  char buf[50];
  // send 1000*100 char and measure speed (100 char = 1424 bit including SYSEX start/stop)
  t1 = millis();
  for (int k = 0; k<1000; k++) {
    Firmata.sendString(F( "1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890" ));
  }
  t2 = millis();
  snprintf(buf , 32, "start (ms): %d ", t1); // 1882ms
  Firmata.sendString(F( buf ));
  snprintf(buf , 32, "end (ms): %d ", t2); // 3466ms
  Firmata.sendString(F( buf ));
  snprintf(buf , 32, "Ellapsed: %d ", t2-t1); //1584ms 
  Firmata.sendString(F( buf ));
}