It would be great if the table of hardware (and I suppose the underlying "dataentry" that it presumably uses) included more structured (values are restricted) fields related to radios.
In particular:
Number of radios
Base frequency band of each radio (e.g. 5Ghz)
Channel ranges available on each radio
Allowed channel widths of each radio or maybe just maximum one
MIMO configuration of each radio (currently often captured in freeform comments)
Other specialty radio information like DFS, etc
Some of these are captured in freeform text fields in varying formats, but even that is inconsistent. Some of it (e.g. the presence of at lease one 5Ghz radio) can be derived from the current structure, but I find it insufficient. I feel like the core of OpenWrt is about wireless, so information on wireless radios in the hardware database should be the most comprehensive.
Is is possible to extract any of this information programmatically from the source tree in the repo? For example, is there a script I can write to parse source code or config files somewhere in the repo to determine the number of radios of each supported device?
While I understand your desire, the devil is in the details here. The definition of a "radio" is getting more and more fuzzy these days, with DBDC ('TBTC') and MLO (wifi7), if you try to define that too closely, you will hit a snag quite soon (apart from making it very hard for the submitter). Quite a few of your requested data will also be region dependent., so nothing that could be answered globally (both because the submitter won't/ isn't allowed to ignore their regional restrictions, but also because the EEPROM/ EFUSE restrictions do vary depending on the target market).
Yes that devil in the details makes sense. But there is probably some middle ground between going crazy with details that are hard for the submitter to even know and the current state. I think there is probably some meaningful way to capture DBDC/TBTC and MLO if needed too as optional fields. Maybe it isn't counting radios but something else that captures the essence. But maybe counting radios is ok too.
Can't the regional variations/restrictions be captured as well if we really wanted to? Or at least a field to specify the region of the submitter. Or yes maybe the channel ranges and DFS are too country-specific and can often be skipped.
I wonder if the DokuWiki data plugin is also in a sense the source of these shortcomings. I think you can create a "type alias" to allow for essentially having a composite data structure as a field value in a parent. So if the master type is say a "hardware device", then it could have a field called "radio" whose value is restricted to a "radio details" type in the wiki, which itself has fields like "band" and "MIMO config", etc. But it's probably cumbersome and harder to understand for the person doing entry, and harder to render into the wiki pages (especially the TOH itself and the corresponding CSV).
Basically I want there to be a variable number of and nested structure of fields for each device and that is a pretty big deal to get working. But, capturing the hardware characteristics of so many complex devices nowadays without a variable number of and nested structure of fields (in a flat TOH with a fixed number of columns) is also basically impossible.
Using the TechInfoDepot Wiki to do a semantic search ends up being a pretty good way to substitute for the issues I've raised in this thread. It has a better structure to the data for devices and is using MediaWiki rather than DokuWiki, which maybe facilitates this.
Luckily it also has some basic information about OpenWrt support too.
I find it better than wikidevi.wi-cat.ru in terms of the set of devices covered and data structure for complex semantic searches.
For example here is a custom query for tri-band devices that have some form of OpenWrt support and are 802.11 AX devices.
right now, there is no way to query the ToH to find wifi 6E devices. so some routers sold somewhere may have e-fuses blown to force a location that does not support such or such band. do you think that is reason enough to disallow users from getting a list of routers that in principle support the 6 GHz band?
i think adding some columns just saying how many main radios (ideally excluding IoT) support the 2.4 GHz, 5 GHz, and 6 GHz band would be immensely helpful to query the ToH. it doesn't matter if it doesn't capture all info. it doesn't matter if the info has caveats, or even if it isn't entirely correct. what matters is that i can look up and research those few devices instead of every device in the database.
making it very hard for the submitter
some devices in the ToH are completely empty of details. i mean literally just the name and nothing else loaded. letting people mark some things up won't hurt.
i had to compile this list myself just to be able to buy a 3-band router for a project. the amount of work i needed to do just to choose a router was frankly ridiculous. and thankfully, people helped!
btw, while on the topic:
i would very much add at least two other fields:
whether openwrt installation is supported by the stock firmware or requires hacking of any sort.
whether the device has secure boot enabled.
we should absolutely help people avoid manufacturers who are unfriendly to the community. in fact i think automated banner warnings should be displayed on devices pages with any of these two flags.
Agreed. Not that this is inherently the responsibility of OpenWrt, but if OpenWrt makes it easier for people, more people will end up using OpenWrt. I know that's true for me. It took me many hours to find the existence of the TechInfoDepot Wiki, learn that it supported semantic query, learn the syntax, etc. All because I really want to use OpenWrt but I need to find the right hardware for my situation that supports it without digging up specs for hundreds of devices one by one.