improve readme with a warning

README.md

@@ -9,6 +9,26 @@ 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"*.
 
+---
+
+⛔✋ THIS IS NOT AN HOW-TO GUIDE. 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 where only at the beggining and we paid the "early adopter" tax here.
+  - 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 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.