Products > Dodgy Technology

C.F.S. (Chinese Firmware Syndrome)

(1/5) > >>

WimWalther:
We've all experienced it, but can any of us explain it? Chinese Firmware Syndrome refers to the nonsensical, often bizarre choices made by Chinese firmware coders on any number of (often low-end, inexpensive) products. Note that CFS doesn't cover bugs - only intentional behaviors and features that make no sense.

Example #1 - mini BT transmitter/ receiver. It uses simple, easily-understood tones to indicate power on/off and connect/disconnect. But if the battery runs low, it blurts out "Battely row! Preese chaghe!" like every five seconds.

Example #2 - another mini BT transceiver. This one uses a combo of tones and robovoice that's uncorrected for pronunciation. On startup, "Bluh-tuth mode active!".  (Bluetooth is the only mode it has, btw).

There are countless others. Which are your favorites? How about 12/24hr clocks that only display temp in C when in 24hr mode? =)

ataradov:
It is the same thing universally, not specific to China. Hardware is usually fast and easy, software is hard and takes a lot of time. If you are optimizing for cost, then the first version of the firmware that works is going to be released. Often it is just the vendor demo code with minimal modification, so it is full of goofy stuff.

Normally this gets worked out with updates, but if you are saving money, there are no updates.

One thing I wish they all figure out is that if you publish the code and let people modify it, you may end up with a way better product in the end. Or potentially nothing will happen if nobody really cares about the product. And in many cases those things run obscure MCUs with no documentation and no toolchains, so usefulness of that may vary too.

Nominal Animal:

--- Quote from: ataradov on November 09, 2023, 04:31:54 pm ---It is the same thing universally, not specific to China. Hardware is usually fast and easy, software is hard and takes a lot of time. If you are optimizing for cost, then the first version of the firmware that works is going to be released. Often it is just the vendor demo code with minimal modification, so it is full of goofy stuff.
--- End quote ---
Can confirm.

For reasons, some years ago (when they were finally convinced to provide the sources), I took a look at many a router firmware based on some variant of Linux.  "Reputable" vendors for home-class routers like ASUS were the worst.  They really looked like a highschool kid had taken a SoC vendor's SDK as-is, and made random changes to it until it seemed to work.  I still get the heebie-jeebies when I think about those, because there are tens of millions of those things used and relied upon by people all over the world.  Reminds me of the videos where someone is halfway up a skyscraper, poking a hole into the concrete support, finding only loose sand behind a thin layer of mud.

WimWalther:
WRT Home WiFi routers, I'm not at all surprised considering the number of bugs and crash events they exhibited.. the classic "just try unplugging it" fix for mysterious non-working internet.

But everything you two mentioned falls under "bugs". CFS is limited to strange *intentional* behaviors.. stuff someone thought would be clever / nifty but simply doesn't work out that way...

Example #3 - Low Battery warnings that trigger every few seconds, when once per minute or two is completely adequate.

SiliconWizard:

--- Quote from: ataradov on November 09, 2023, 04:31:54 pm ---It is the same thing universally, not specific to China. Hardware is usually fast and easy, software is hard and takes a lot of time. If you are optimizing for cost, then the first version of the firmware that works is going to be released. Often it is just the vendor demo code with minimal modification, so it is full of goofy stuff.

--- End quote ---

Exactly. And the relatively universal way of managing projects these days is to assume the hardware will be the hard part with long dev times (due in part to many managers not understanding much of hardware, and in part to the fact that, indeed, there are fab times for hardware that can't be compressed), while software is quick and easy (often again because managers think they understand software, and think that software is always quick and easy and that features can always be added at the last minute). Experience invariably proves that it's the software side that takes the most time in any modern product development (except probably niche devices with very complex hardware and relatively simple, to no software), but companies still manage projects in the same way, invariably assuming that software is so flexible and easy.

Assuming that is not entirely their fault (at least initially), as that's what people have been told for several decades now. (But it becomes their fault when they have experienced otherwise and still keep managing projects in the exact same way.)
Utlimately, I think we still don't know (I mean, on average) how to develop software properly and how to manage software development, despite a myriad of attempts that have often added to the confusion rather than solved much.
 :popcorn:

Navigation

[0] Message Index

[#] Next page