Thanks for the updates. Would you care to provide a succinct but complete listing of steps required to manually establish the connection in Windows IoT? I see the device registered as Qualcomm CDMA Technologies MSM in the Connected Devices listing.
Unless your business model is completely balanced on your portal/dashboard and message passing SDK, I think it would be immensely beneficial to your company to decouple the driver/connectivity portion from the rest of the SDK, and strive toward providing “near plug and play” internet connectivity for as many devices as possible, such that the connection is available and usable by the system generally.
There is really a dearth of available options for plug and play cellular connectivity for iot devices, but plenty of options for devices that have cell connections but strong-arm you into particular SDKs/portals etc.
Your idea of providing carrier-neutral cell plans, connecting to whatever tower has the best signal (that is how you guys operate, correct?) is excellent, and if you could provide a gamut of modem options from full bandwidth LTE to the low bandwidth, high-penetration of Cat-M, that would be brilliant.
Some background: my company has an existing nationwide network of 20K+ IoT devices using 3G connections and needing to be updated to some variant of 4G. Since our bandwidth needs are low and since on-site cellular connectivity is the primary source of woe for us, it would be hugely beneficial to be able to try different options on-site to determine the optimal cellular protocol.
After 5+ years of running through a vendor’s AWS-hosted portal and dealing with the many issues of their hulking black box, we’re considering bypassing cloud solutions and adopting a model of edge devices with enough intelligence to filter data for minimal bandwidth consumption, then send messages to an onsite message broker, preferably through a private tunnel/APN.