We bought a Compex WPJ 428 board + a SIMCom 8202G LTE/5GNR modem and we try to make it work on OpenWRT
Go to file
2023-10-02 14:55:33 +02:00
3D_model Init add 3D Model 2021-04-17 18:54:44 +02:00
doc Update DOC and add UCI defaults script ModemManager config 2022-04-26 18:39:30 +02:00
files Update DOC and add UCI defaults script ModemManager config 2022-04-26 18:39:30 +02:00
img Add pictures and a first report 2021-04-17 17:55:47 +02:00
reports Add some doc 2021-04-17 19:54:17 +02:00
xdp Working checksum computation 2021-04-25 16:56:35 +02:00
README.md typo 2023-10-02 14:55:33 +02:00
TODO.txt Update DOC and add UCI defaults script ModemManager config 2022-04-26 18:39:30 +02:00

WPJ428 + SIMCOM 8202G

We see this project as a way to assess how well we can regain control/understanding on our NR5G/LTE routers.
And for now the answer seems to be "very little".


During the process, it appears we made major mistakes. Because we had already bought the components, it was too late and had to live with them or find workarounds. But for a new build, it is advised to choose better components. Here are our major errors, that can be summarized as "the cost of trying to be on the edge":

  • The M.2 port of the board is only wired for the USB protocol 2.0 (and not USB 3.0 or PCI Express). The link is very slow and is probably our bottleneck which limits the connection to 10Mbps (!). Instead of choosing the new connector technology (M.2), we should have choosen an older connector (mini PCI) that is available on many more tested and validated boards.
  • More generally, the WPJ428 board is not really amazing: it is targeted at "IoT" which is really a diverted way to say that is really "underpowered" in many aspects. Due to its niche target market, it was not well supported by OpenWRT, especially just after it's release. And of course, we bought it "just after its release".
  • The firmware of our LTE/NR5G modem is very buggy. Avoid obscure references and, instead, choose already widespread references. Also, the market does not move at the same pace: while many smartphone are sold with support from NR5G, pluggable modems were still nascent, here again we paid the "early adopter" tax, with the UDP bug for example.
  • The support for LTE/NR5G is not optimal in OpenWRT. ModemManager is a great quality of life enhancer, but it is meant to work with NetworkManager, which is not integrated with OpenWRT. We had to write multiple flawed scripts to handle re-connections and the various quirks associated to mobile connections. Ideally, we should have written a daemon in a proper programming language (C or Lua) that observe/interact with ModemManager/NetworkManager through their dbus interface for a more reliable experience.
  • We did not invest enough time/energy on the antenna part. Having a clear line of sight and putting it above (and not below) the roof would have clearly improved performances. Also, your connection quality will heavily depend on your mobile provider's cell tower, and not all cell tower are born equals. Some of them are connected with fiber directly to the backbone, some of them are "meshed" through wireless connection with other ones. Some of them are also very overloaded, while other ones have only you as the client. Etc. Collecting information beforce deploying your router is very crucial.

In the end, we bought very expensive components to get only very mediocre performances (only 10Mbps while LTE alone supports up to 100Mbps). Buying a NR5G modem was clearly a waste of money.

Our research & experiment process

Our case study is a NR5G router as the main Internet access point in a place where we have no signal on our cellphones. Thus, we need external antennas that are put in the roof. Additionnaly, we want to maximizme the throughput (both RX and TX) and minimize latency while keeping a stable connection over time.

Our project is currently made of the following physical parts:

We try to document our journey here: