[REQUEST] Hardware Flow Control "HW" firmware for ITead Zigbee 3.0 USB Dongle

[Hedda]

@xsp1989 can you make firmware builds with Hardware Flow Control (RTS/CTS) configuration for ITead Zigbee 3.0 USB Dongle?

OpenHAB developer recommend "Hardware Flow Control" = RTS/CTS flow control.

https://community.openhab.org/t/itead-zigbee-3-0-usb-dongle-stick-only-cost-7-and-is-based-on-silicon-labs-efr32mg21/115034/33

Support for Hardware Flow Control ("HW") was added to zigpy / bellows about a month ago so not yet supported in HA's ZHA:

https://github.com/zigpy/bellows/pull/403

https://github.com/zigpy/bellows/releases/tag/0.23.0

https://github.com/home-assistant/core/pull/47873

PS: According to OpenHAB developer, Silabs recommend using either hardware flow control or software flow control. Not none.

[MattWestb]

Is hardware flow control implanted in the hardware USB connection ? If no its dont working at all.

[Hedda]

Is hardware flow control implanted in the hardware USB connection ? If no its dont working at all.

You think CH340E chip or driver does not support RTS/CTS? Or it not been soldered and have PCB lines for hardware flow control?

http://www.wch-ic.com/products/CH340.html

WCH website says: "Supports common MODEM interface signals RTS, DTR, DCD, RI, DSR and CTS" but is it correctly hardwired?

https://arduino.stackexchange.com/questions/23159/arduino-hardware-serial-library-with-rts-cts-flow-control-support

OR perhaps hardware flow not fully supported by the Linux kernel driver or Python pyserial / pyserial-asyncio perhaps?

https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers?_ga=2.41031015.417113913.1617180575-428830341.1616414600

[xsp1989]

It seems that EFR32MG21 does not connect CTS/RTS to CH340, so it cannot support hardware flow control.

[MattWestb]

That is not the problem. If loading on HW flow control firmware on one hardware that dont have the 2 extra lines for it you cant communicating with it because its waiting for on hardware hand chalking that is not connected.

Check is the pins is connected between the EFR32 and the USB chip and if you is finding all 4 its possible using on HW firmware.

i have loading on SW EZSP in tuya ZBGW and was one 110% (software) brick then the Ser2Net ws only sporting HW.

[MattWestb]

So time for little cable and soldering if like having HW flow control :-))

[Hedda]

It seems that EFR32MG21 does not connect CTS/RTS to CH340, so it cannot support hardware flow control.

That is too bad :(

[MattWestb]

Not bad then is not needed if having god hardware in both ends and one OK cable. Silabs PTI interface is running with 1615384 baud on USB2 and parallel with debug and normal serial and no HW flow control so the hardware on the EFR32 side is no problems more your cable or host system.

[MattWestb]

For @Hedda

Configuration Parameter	Value
Address Table Size	8
Child Table Size	32
Source Routes	7
CTUNE value	128
TX	PA00
RX	PA01
CTS	PC00
RTS	PC01
Part	EFR32MG21A020F768IM32
Version	EZSP 6.9.2.0
Status	Untested

LED and buttons is not known so not programed.

ncp-uart-sw_21.zip

[Hedda]

@MattWestb FYI, Chris Jackson (a.k.a. cdjackson) who is the maintainer of Zigbee binding in OpenHAB and developer Z-Smart Systems said that he recommend hardware flow control for commercial systems using his com.zsmartsystems.zigbee framework:

https://community.openhab.org/t/itead-zigbee-3-0-usb-dongle-stick-only-cost-7-and-is-based-on-silicon-labs-efr32mg21/115034/33

"Personally I would recommend the hardware flow control - it’s what we normally use for most or all of our commercial systems."

[silabs-RaoulvB]

Hi Guys, if I may chime in here. Indeed the USB stick does not have HW flow control lines connected. it would have had the cost of 2 extra PCB traces as the CH340 supports it. Sad and a missed opportunity. So at least XModem flow control should be used, but it would even be better to pick a higher baudrate, which is possible as well.

Besides the mentioned FW versions one has the options to also update the SE (secure element) FW as well as the bootloader (my sticks came with 1.9.2, current is 1.12.0) through gbl updates. For the moment this does not give any functional advantage, so it is not needed, but can be done.

On the configuration table supplied by MattWestb I like to comment as well. Choosing PC00 for CTS is a bad decision as PC00 is connected to the LED. PA00 is connected to the "BOOT" button.

For the optimal CTUNE value one needs to have the datasheet of the HF Xtal used. I am not sure if the original manufacturer is reading along. If so I am happy to work with them to get the optimized value for this.

The other parameters are depending actually on the host software and many of these can be runtime changed through the EZSP protocol, but I do not know the various host software to know if they use this, so changing some defaults is not bad in itself. To give you an example of what SiLabs own example Z3GatewayHost application does at startup:

$ ./build/exe/Z3GatewayHost.exe -p COM14 -f x
Reset info: 11 (SOFTWARE)
ezsp ver 0x08 stack type 0x02 stack ver. [6.9.2 GA build 256]
Ezsp Config: set address table size to 0x0002:Success: set
Ezsp Config: set TC addr cache to 0x0002:Success: set
Ezsp Config: set MAC indirect TX timeout to 0x1E00:Success: set
Ezsp Config: set max hops to 0x001E:Success: set
Ezsp Config: set tx power mode to 0x8000:Success: set
Ezsp Config: set supported networks to 0x0001:Success: set
Ezsp Config: set stack profile to 0x0002:Success: set
Ezsp Config: set security level to 0x0005:Success: set
Ezsp Value : set end device keep alive support mode to 0x00000003:Success: set
Ezsp Policy: set binding modify to "allow for valid endpoints & clusters only":Success: set
Ezsp Policy: set message content in msgSent to "return":Success: set
Ezsp Value : set maximum incoming transfer size to 0x00000052:Success: set
Ezsp Value : set maximum outgoing transfer size to 0x00000052:Success: set
Ezsp Config: set binding table size to 0x0010:Success: set
Ezsp Config: set key table size to 0x0004:Success: set
Ezsp Config: set max end device children to 0x0020:Success: set
Ezsp Config: set aps unicast message count to 0x000A:Success: set
Ezsp Config: set broadcast table size to 0x000F:Success: set
Ezsp Config: set neighbor table size to 0x0010:Success: set
NCP supports maxing out packet buffers
Ezsp Config: set packet buffers to 253
Ezsp Config: set end device poll timeout to 0x0008:Success: set
Ezsp Config: set zll group addresses to 0x0000:Success: set
Ezsp Config: set zll rssi threshold to 0xFFD8:Success: set
Ezsp Config: set transient key timeout to 0x00B4:Success: set
Ezsp Endpoint 1 added, profile 0x0104, in clusters: 8, out clusters 19
Ezsp Endpoint 242 added, profile 0xA1E0, in clusters: 0, out clusters 1

[xsp1989]

@silabs-RaoulvB Silicon Labs employees?

[MattWestb]

Hi @silabs-RaoulvB thanks for very constructive feedback !!

I was liking putting the HW flow control pins on PA02 and PA03 but hardware configurator is allocating them for SWD (PA01 also) so i was thinking better using on other hardware port then braking SWD that is used for flashing the ship if not can do it with bootloader.

I dont have the device so i can only looking on photos i have finding online.

The chip is normally very stable then PTI is normally running at 1600000 without hardware flow control and if the PCB design is god 115200 with software flow control shall not being any problems. And yes HW is better then SW (some % but is normally higher data speed in the other end) buut still no problems in normal operation. If need more speed then implanting SPI NCP.

The community have problem that the NCP is not transmitting any thing then the NCP is plugged in one USB without extension cable but is working well then putting it away and its looks being common with PI4 and NUC with USB3 and SSD disk attached.

Is its bad decoupling on the PCB or is interference nuking the HF-Xtal or going in the HF stage of the chip thry external components ?

I think with some more decoupling capacitors and shedding the RF / HF-Xtal is being fixed but i is not the hardware designer of the PCB.

Thanks for very constructive feed back !!

[Hedda]

For the optimal CTUNE value one needs to have the datasheet of the HF Xtal used. I am not sure if the original manufacturer is reading along. If so I am happy to work with them to get the optimized value for this.

@silabs-RaoulvB FYI, for reference, know that HFXO Capacitor Bank calibration value was discussed in https://github.com/xsp1989/zigbeeFirmware/issues/4

The other parameters are depending actually on the host software and many of these can be runtime changed through the EZSP protocol, but I do not know the various host software to know if they use this, so changing some defaults is not bad in itself. To give you an example of what SiLabs own example Z3GatewayHost application does at startup:

@silabs-RaoulvB If you have time, please also see related discussion regarding config parameters in https://github.com/xsp1989/zigbeeFirmware/issues/6

FYI, know that host software that use USB-dongles like this foremost is the worlds most popular open-source home automation software applications in which USB-sticks like these are used as Zigbee Coordinator to make a DIY Zigbee hub/gateway/bridge.

These software applications primarly include:

Home Assistant ZHA integration (which depends on python libraries zigpy and bellows https://github.com/zigpy/zigpy )

https://www.home-assistant.io/integrations/zha/

OpenHAB (which depends on the com.zsmartsystems.zigbee https://github.com/zsmartsystems/com.zsmartsystems.zigbee )

https://www.openhab.org/addons/bindings/zigbee/

Zigbee2MQTT dev branch (which depends on zigbee-herdsman https://github.com/Koenkk/zigbee-herdsman )

https://www.zigbee2mqtt.io

IoBroker (which depends on zigbee-herdsman https://github.com/Koenkk/zigbee-herdsman )

https://github.com/ioBroker/ioBroker.zigbee

Jeedom Zigbee plugin (which also depends on python libraries zigpy and bellows https://github.com/zigpy/zigpy )

https://community.jeedom.com/t/plugin-zigbee-beta/40301

[Hedda]

Indeed the USB stick does not have HW flow control lines connected. it would have had the cost of 2 extra PCB traces as the CH340 supports it. Sad and a missed opportunity. So at least XModem flow control should be used, but it would even be better to pick a higher baudrate, which is possible as well.

Do you mean that recommend setting the default baud rate speed that is even higher than 115200 for the application firmware?

[xsp1989]

Future versions may support HW folow control.

[MattWestb]

I dont knowing if its giving any advantage but very likely you need having one good UART in the host side or you is running in problems.

On more thing is that EZSP NCP is little lazy and not replaying on IEEE 802.15.4 ack then its communicating with its host system (at least EFR32MG1 is doing that) but perhaps its being better running on higher comport speed so the CPU is not spending time on the comport or its being bad for the NCP i dont knowing without testing.

[MattWestb]

@xsp1989 then making on RF shield and some extra decoupling capacitors on the PCB for eliminating the problems with connected to USB 3 ports with other devices and you is getting much less problem from users.

[Hedda]

Future versions may support HW folow control.

Off-topic but I wished that ITead had chosen to go with the FT231 chip by FTDI as a USB-to-Serial component chip instead (as that had allowed them to customise strings and also allow for auto-reset/put the device in BSL mode via the DTR/RTS pins exposed).

FYI, an upcoming ZZHP/ZZH2 adapter by Electrolama will use FT231 which has more mature device drivers and will allow them write a customized string onto the EEPROM of the USB-to-Serial chip (such as for example "Electrolama ZZHP v1.0.0") should make it more plug-and-play friendly and easier for different home automation software to automatically discover and configure without end-user interactions. The bonus feature in FT231 of allowing users to auto-reset and put the device in bootloader mode via the DTR/RTS pins exposed will enable much easier firmware upgrades for the end-users as they will no longer need to press any buttons to enter bootloader mode, and now bootloader mode can be activated via software from the firmware flasher program software which could make the firmware upgrade procedure more user-friendly.

https://ftdichip.com/products/ft231xs/

https://ftdichip.com/products/ft231xq/

I believe that Silicon Labs CP21xx USB-to-UART bridge products like for example the CP2104 offers the same or similar features?

https://www.silabs.com/interface/usb-bridges/classic

https://www.silabs.com/interface/usb-bridges/classic/device.cp2104

[MattWestb]

As long the NCP is up and running its possible booting in bootloarer mode. But if loading on image that have wrong comm parameters (wrong pins, wrong flow control or speed) its needed on hardware triggering for going in boot loader mode. Hardware triggering is nice but for normal user not needed then having ob reset and botloadre button.

Silabs standard is the bootloadder always without flow control then its not needed with x-modem download and the NCP is doing CRC (sign and crypto if being handled in the GBL file) check before flashing the image.

[xsp1989]

Will not use the FT231 chip, which will increase the product price. If there is a problem with the memory driver of the CH340 chip, it may be replaced with another chip, such as CP210X, otherwise it will not be replaced.

[MattWestb]

@Hedda If you is using the DTR/RTS pins for bootloader can you still using the RTS for HW flow control ? I have not looking on how Electrolama have doing it on the hardware plane but i thinking its not possible using it for 2 purposes.

[Hedda]

Will not use the FT231 chip, which will increase the product price. If there is a problem with the memory driver of the CH340 chip, it may be replaced with another chip, such as CP210X, otherwise it will not be replaced.

You think it would raise the cost a lot to use CP2104 or FT231 instead? The CP2104 might get you better official support from Silabs.

I have not looking on how Electrolama have doing it on the hardware plane but i thinking its not possible using it for 2 purposes.

Should maybe have mentioned that the upcoming ZZHP/ZZH2 adapter by Electrolama will be based on Texas Instruments CC2652P.

[MattWestb]

@xsp1989 If you is interesting in having god tester for your hardware in alpha or later stage i can recommending shipping some example to the devs of bellows that have the most experience of working from the host software side (next after Silabs team) and also need hardware for testing then running in problems with specific hardware. https://github.com/zigpy/bellows#how-to-contribute

One example no of the devs have one Sonoff ZBB and cant verifying all the problems the ZHA and tasmota user was having, and if they was having the hardware it was possible verifying the problem is in the host system or in the hardware / firmware. Also its god for you to getting deep reporting back and not users that is not understanding the problem behind = win win situation.

Most of the core devs is in the US but some is also in other parts of the world but the core is the most important.

[Hedda]

@xsp1989 If you is interesting in having god tester for your hardware in alpha or later stage i can recommending shipping some example to the devs of bellows that have the most experience of working from the host software side (next after Silabs team) and also need hardware for testing then running in problems with specific hardware. https://github.com/zigpy/bellows#how-to-contribute

More suggestions there is OpenHAB devs as well as zigbee-herdsman devs (a mixture of Zigbee2MQTT devs and IoBroker devs)

https://community.openhab.org/t/itead-zigbee-3-0-usb-dongle-stick-only-cost-7-and-is-based-on-silicon-labs-efr32mg21/115034

https://github.com/Koenkk/zigbee-herdsman/issues/319

[Hedda]

@silabs-RaoulvB Are you by the way following the related discussion about this dongle here -> https://github.com/home-assistant/core/issues/48592 ?

FYI, it now sounds there as if the root cause of much of ITead dongle problems could be due to lack of shielding + antenna design.

[Hedda]

@xsp1989 How much would it add to total cost to use a metal shield cover and a ceramic chip antenna like MGM210P (MGM210)?

Ceramic chip antenna are less sensitive to component and environmental noise/interference + easier to tune + other advantages:

https://resources.pcb.cadence.com/blog/2020-understanding-ceramic-chip-antenna-vs-pcb-trace-antenna

...and metal shield cover plate for RF/EMF shielding might be needed if ever plan on gettings FCC and/or CE certifications in the future.

MGM210P looks like this without and with a grounded metal RF/EMF shield cover plate to prevent RF signal interference (image from https://fcc.report/FCC-ID/QOQGM210P/4460964):

MGM210L looks like this without and with a grounded metal RF/EMF shield cover plate to prevent RF signal interference (image from https://fccid.io/QOQMGM210L/Internal-Photos/Internal-Photos-4211021):

MGM210 (MGM210L and MGM210P) are official EFR32MG21 Series 2 Modules from Silicon Labs so should be good references.

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-modules

[silabs-RaoulvB]

Hi Guys, a lot going on here ;) yes I work for SiLabs, but not representing SiLabs as a company here, it more personal interest to have a USB stick with a MG21 for quickly developing some demos. So I am also not active in any of the HA forums (but thanks for some links, I will look there).

Setting the CTUNE to 128 is as arbitrary as setting it anything else unless you know what you are doing. CTUNE value can be calculated from the datasheet of the HFXO used, so if anyone knows what XTal is used (and have a link to its datasheet) I am happy to calculate the optimal CTUNE value for it.

One the configuration parameters side: as said, most parameters can be set anyway from EZSP commands, and some of the parameters are dependent on how the Zigbee network is operated, like, does it use source routing or not? And this depends on choices done by HA gateway/Host software, so I am afraid I cannot help here. There are some values, like the heap size which should be set such that all parameter settings are possible and not "refused" because of the NCP firmware on the USB stick running outof memory.

On security side, one can do a lot, like was mentioned, with signed fw images, encrypted fw images etc, but this has to be supported by the bootloader. As we have no information (besides its version 1.9.2) on its configuration, I also cannot say anything here. But I was successful updating all FW through xmodem/uart, so my stick is running SE FW 1.2.8, bootloader 1.12.0 and NCP image 6.9.2 (with SW flow control). With a bootloader update followed by NCP update, one can safely push higher baudrate variants, but i will test this first, as I do not know the limitation the CH340 may impose here, need to test that.

I even was able to convert it into a BLE and BLE Mesh NCP stick as well. I have not done any performance measurement or anything yet. As far as CTUNE goes for BLE, without changing anything yet, I had no issues seeing all BLE devices in my home.

On USB-serial, yes the CP2102N https://www.silabs.com/documents/public/data-sheets/cp2102n-datasheet.pdf will do the job perfectly.

Hope I have answered all issues in the posts before... Sorry I am not at my computer every day/evening.....

take care.

[Hedda]

@silabs-RaoulvB ITead marketing should maybe make it more clear that the target audience for this relatively inexpensive Zigbee 3.0 USB Dongle product is primarily users of the most popular DIY home automation software applications such as Home Assistant, OpenHAB, Zigbee2MQTT, IoBroker, Jeedom, etc. ...and the reason for that target audience is clearly for ITead to sell more of their Sonoff branded Zigbee devices to that DIY home automation market (following the attach rate business concept).

With users of DIY home automation software applications so clearly being the target audience for this Zigbee 3.0 USB Dongle product the default firmware for it should really come fully pre-configured with optimized parameters tuned for that purpose out-of-the-box, e.g. optimized for plugging it into Raspberry Pi type single-board-computers then connecting and controlling anything from a few to a few of hundreds (maybe ~ 20-200) Zigbee devices that are similar to the relatively inexpensive Sonoff branded Zigbee devices (whether they are powered by mains-power or battery-operated).

On security side, one can do a lot, like was mentioned, with signed fw images, encrypted fw images etc, but this has to be supported by the bootloader. As we have no information (besides its version 1.9.2) on its configuration, I also cannot say anything here.

ITead did not ship this stick with any signed firmware on purpose because would make it less user-friendly to DIY target audience.

With a bootloader update followed by NCP update, one can safely push higher baudrate variants, but i will test this first, as I do not know the limitation the CH340 may impose here, need to test that.

CH340 spec sais it support communication baudrates from 50 baud to 2 Mbaud -> http://www.wch-ic.com/products/CH340.html

Setting the CTUNE to 128 is as arbitrary as setting it anything else unless you know what you are doing. CTUNE value can be calculated from the datasheet of the HFXO used, so if anyone knows what XTal is used (and have a link to its datasheet) I am happy to calculate the optimal CTUNE value for it.

Yes please! It would be great if you could do that! Is it only the transmitting side and not receiving side that also needs to be tuned?

@xsp1989 Do you have information on the XTal used (and have a link to its datasheet) for this ITead Zigbee 3.0 USB Dongle?

I even was able to convert it into a BLE and BLE Mesh NCP stick as well. I have not done any performance measurement or anything yet. As far as CTUNE goes for BLE, without changing anything yet, I had no issues seeing all BLE devices in my home.

That is very cool! It would be very nice if someone could build and release a pre-configured firmware image for those as well(!).

Possible to make a Thread firmware image as well? That might get new developers started with Project Connected Home over IP.

[MattWestb]

@Hedda

Yes please! It would be great if you could do that! Is it only the transmitting side and not receiving side that also needs to be tuned?

The HFXO is the main common synthesizer for both receiver and transmitter then Zigbee (IEEE 8022.15.4) is sending and receiving on the same frequency and is its being wrong of TX its also being wrong for RC. As for the ZHA issue is getting interference in the HFXO all is messed up and its not working at all. And is one device is miss tuned then it have problem "talking" with other device in the network (worse with miss tuned ones in the other direction and is working better with device miss tuned in the same direction and with same frequency diff). Pure mathematics + and -.

[Hedda]

@xsp1989 Do you have that information on the XTal used (and have a link to its datasheet) for this ITead Zigbee 3.0 USB Dongle?