Why are there Paneldue Baud rates which do not work?

Andy Cohen

Why have selections in the settings for baud rates which are faster than what the controller board can handle? If they do not actually work and selection of them provides ZERO warning about the panel not functioning correctly after selected, then why have the faster baud rates as selections at all?

A Former User

Could be tolerances for the clock generation; some baud rautes require crystal oscillators that are not nice even round numbers to clock the uart accurately enough.

Or it could be noise issues if the problem is mainly higher baud rates?

Scachi

PanelDue works for me with baudrates set to 115200 (in paneldue and config.g)
I had problems (checksum errors) at first at any baudrate speed. After grounding my printer I can use all speeds now without any problems. A shielded cable for the paneldue with the shield connected to - on the panel due port on the duet side did also fix this issue for me.

grizewald

@bearer said in Why are there Paneldue Baud rates which do not work?:

Could be tolerances for the clock generation; some baud rautes require crystal oscillators that are not nice even round numbers to clock the uart accurately enough.

Or it could be noise issues if the problem is mainly higher baud rates?

Or it's not being driven by a real UART and is instead 'bit banged' by the processor? That might work fine until the processor starts to get busy and doesn't have enough time to pretend to be a UART.

Danal

@Andy-Cohen said in Why are there Paneldue Baud rates which do not work?:

Why have selections in the settings for baud rates which are faster than what the controller board can handle?

First answer:

Why are the baudrates in the buttons what they are? The literal physical reason is because the buttons are coded:

void CreateBaudRatePopup(const ColourScheme& colours)
{
	static const char* const baudPopupText[] = { "9600", "19200", "38400", "57600", "115200" };
	static const int baudPopupParams[] = { 9600, 19200, 38400, 57600, 115200 };
	baudPopup = CreateIntPopupBar(colours, fullPopupWidth, 5, baudPopupText, baudPopupParams, evAdjustBaudRate, evAdjustBaudRate);
}

However that's only half the story. Those baudrates were coded because this all runs on a SAM CPU, and the ATMEL libraries for the SAM specify the max/min baudrates that can be configured into the UART registers. I'm certain that DC42 simply coded the drop down to match the ATMEL provided SAM hardware libraries.

Second answer:

The default is 57600, which works. Why did you change it? (half kidding, half serious)

Third answer:

I have two PanelDue, each cabled to a Duet2 WiFi. Both panels run fine at 115200, if the DUET is configured to match. M575 P1 B115200 S1 on the Duet, then change the PanelDUE. Both of mine are running on the supplied cable.

So, there are NOT selections that are "...faster than...[works properly]". The fastest works fine, for multiple people. If it doesn't work for you, something is wrong with your cabling, or (very unlikely) your boards.

A Former User

If you wanna get into why the numbers are the numbers they are; it goes back before Atmel to the early days of modems. Starting at 300 (or 1200 depending on what religion you subscribe to) and all common baudrates since then are a integer multiplum of the first value. Its essentially Bell's fault back in the 60's and for interoperatibility all serial communication since have used the same values.

There is nothing stopping you from clocking the microcontrollers UART to any arbitrary baud rate that can be derived from the system clock and maintain a reasonable error rate, or even software controlled. Having a well known set of standard values on the other hand makes it easier to talk to different systems as well as having common clocks that divide reasonably close into the baud rates for low error rates.

This visualies the relations between system clock, baud rate and error rates quite well.
https://trolsoft.ru/en/uart-calc

So to summarize if only a few are having problems, then most likely cabling issues, but it could also be cheap clock crystals that are out of spec or extreme temperatures affecting perfectly good crystals .. and of course gremlins.

Dougal1957

@bearer said in Why are there Paneldue Baud rates which do not work?:

If you wanna get into why the numbers are the numbers they are; it goes back before Atmel to the early days of modems. Starting at 300 (or 1200 depending on what religion you subscribe to) and all common baudrates since then are a integer multiplum of the first value. Its essentially Bell's fault back in the 60's and for interoperatibility all serial communication since have used the same values.

Actually if you go back a bit further modems started at 75 baud but teleprinter comms before that were at 45 our 50 Baud using the 5 unit murray code (I know I am showing my age now).

A Former User

@Dougal1957 said in Why are there Paneldue Baud rates which do not work?:

Actually if you go back a bit further modems started at 75 baud but teleprinter comms before that were at 45 our 50 Baud using the 5 unit murray code (I know I am showing my age now).

Touché! Hopefully its still Bell's fault. And thanks, I fell young now