14 ms·
In my corner of the world (electric/water/gas utilities), we had been using proprietary techniques that matched the "NB-IoT" description for 20 years, and they
by jjoonathan 2y ago
In my corner of the world (electric/water/gas utilities), we had been using proprietary techniques that matched the "NB-IoT" description for 20 years, and they weren't new then. It was fun to watch the public dialogue walk the same path for a while and rediscover some of the main tricks, but there were other important tricks left untouched (broadcast firmware downloads, highly compressed debug logs, low power clock synchronization so that you can do timeslots for ultra low power, mesh heuristics) probably because they were a massive pain in the rear and the people who would have risen to the occasion saw that the major ecological niches were already occupied by players who got in 30 years ago when this all became viable. (Disclaimer: I didn't actively chase down NB-IoT talks so I might just have been missing these things.)
If your market is large enough that managing your own infrastructure is attractive (vs cellular), you were also able to afford a few EEs and RF guys 30 years ago, and your needs are already met by a competitive ecosystem of players who have been walking this path for a long time. It doesn't leave much to compete on except price, and you don't want to compete on price.
- tliltocatl 2y agoThat makes me envious. I've figured out the debug log compression part myself, but the rest is beyond my reach. > If your market is large enough that managing your own infrastructure is attractive This. I imagine proprietary is perfect when you are deploying in a single country with single RF plan. And your customer utility company that is willing to maintain a bit of extra infrastructure. But if you want to deploy on several sites scattered across all ITU regions, and each site is a huge plant with devices from maybe fifty different suppliers, it's just a no-go.