115200 verses 57600 bit rate speed for Silicon Labs EZSP on EFR32MG1 and EFR32MG2?

[Hedda]

What are the pros and cons with 115200 verses 57600 bit rate speed for Silabs EZSP serial protocol on EFR32MG1/EFR32MG2?

kirovilya brought up the question in Koenkk/zigbee-herdsman#168 for EByte-E180-Z120B and SM-011 V1.0 modules.

PS: The upcoming Sonoff Zigbee 3.0 dongle from ITead will ship with firmware config for 115200 -> https://fb.watch/386X5ET50f/

[Hedda]

Note! This is cross-posted at zha-ng/EZSP-Firmware#6

[MattWestb]

The EM35X was having 115200 with hardware flow control and 57600 with software flow control as standard (probably hardware limitations) and its inharaged to the EFR32 thats looks woking OK with 115200 SW (alos ZHA is having 57600 as standard for EZSP NCPs) and most host systems is having it for compatibility reasons.

And M35X with on chip USB serial is software derived and dont need hard or software flow control on the "cable" its being handled by the software bufferts as the speed is don (automatic).

[Hedda]

FYI, submitted PR to update bellows README.md for zigpy with more info about flow control speeds in zigpy/bellows#391

Note that there are generally two image versions of the Silabs EmberZNet NCP firmware in use. One version operates at a baud rate of 115200 with RTS/CTS flow control (i.e. hardware flow control), the other operates at a lower baud rate of 57600 with XON/XOFF flow control (i.e. software flow control). If you are flashing firmware image to your own EM35x or EFR32 adapter then it is advisable to use a version with hardware flow control, Many available commercial dongles (e.g. Nortek HUSBZB-1) seem to ship pre-flashed with a firmware that uses the lower speed and software flow control.

Paraphrased from https://www.openhab.org/addons/bindings/zigbee/#ember-ezsp-ncp-coordinator

[MattWestb]

I dont agree with the recommendation !
Silabs have one bug case if having massive transactions in large systems and using high speed and sw flow control it can being problems with the buffers in EZSP.

But for normal use 115200 SW is working very well and its better than the lower with HW then buffers is emptied faster and not halting the coordinators "normal" work.
If having long cables and unstable environment the lower speed and HW is recommended but its not the case then its some cm between the NCP and the host com port pins.

And i have long com cables and no nice environment for My Billy on the Pi3:

Pi3B+ ESP32 CAM and Billy EZSP also hosting HA and many ESPHome devices dont using ETH but 5Ghz WiFi so all is against it but still working well :-))

Gary please don't kill my for the bad hardware implantation !!!!

[MattWestb]

I think (= not knowing) that the comports on EFR32 chips is using real hardware UART with DMA transfer so its having no problems with timing of the communication if its lagging and the CPU only need reading / writing to the software buffers as long not killing the main thread its running.

[Hedda]

I did not base that on empirical tests, instead I just stole the recommendation from https://www.openhab.org/addons/bindings/zigbee/#ember-ezsp-ncp-coordinator

I believe that @cdjackson from @zsmartsystems wrote that original recommendation for EM358, (and he is also the author of https://github.com/zsmartsystems/com.zsmartsystems.zigbee and https://github.com/zsmartsystems/com.zsmartsystems.zigbee.sniffer plus maintainer of OpenHAB Zigbee Binding).

And I assumed that if EM358 has no issues with 115200 hardware flow control then EFR32 should have no issues either?

i have long com cables and no nice environment for My Billy on the Pi3:

But is your setup common (e.g. the norm) or the extreme exception? I would think most other people more common setups consist of a bought USB dongle/stick or a Shield such as for example Elelabs Zigbee USB Adapter or Elelabs Zigbee Raspberry Pi Shield?

Also, you really need to use shorter wires/cables once the project goes into production! ;)

[MattWestb]

I dont knowing how the hardware part of the EM35X is working and the EM368X have multi protocol versions (with Z-Wave) that can making it difficult getting the communication working stabile and need the hardware flow control then the NCP(s) is not have time "talking to the host" all the time.

ZHA have dropped the HW flow control so its not possible using their firmware.
And its looks no EFR332 have problems with 115200 with software flow control.

I think its more interesting if EM35X family is stable with 115200 SW than converting all new firmware (i think gary have make 95% of all adapter working with new ones if they is working OK on all hardware but waiting for verification on that) to it and make 115200 sw default in ZHA.

Then testing and working with longer cables its OK but doing one PCB its being much shorter and more away from other signals sources that can making interference.

[MattWestb]

I think the owner of this git and @walthowd can awsering if Em35X devices is working satbile with 115200 sw or need 57600 with sw (then HW is not working with ZHA) and the rest is speculation without experience.