Hello,
I purchased a NovaM (based on u-blox SARA R410) Cat-M1/NB-IoT in late 2018. I purchased 55 more in early 2019. I was active on this forum throughout 2019 as I was learning the ins and outs of writing software to control this device. My company designed a variation of the open-source NovaM and manufactured 250 of our own devices.
Our plan was to deploy those devices for testing and, if successful, produce many more for our own purposes and as a new product to sell in the Cat M1/NB-IoT space. Unfortunately, we ran into insurmountable reliability problems with the u-blox SARA R410-02B (more below) and pulled the plug on that project. It was painful and expensive, but we won’t sell an unreliable product.
Now we have designed and manufacture a family of USB modems,
• Cat-M1/NB-IoT w/GNSS
• Cat-1 w/GNSS
built on Quectel modules (BG96, EG91). The Quectel modules are more feature rich and better-behaved. We have been able to get outstanding technical support from Quectel, while u-blox was unwilling to provide competent technical support at any point.
The u-blox SARA R410-02B and Quectel BG96 Cat-M1/NB-IoT specs are similar. They are both Cat-M1/NB-IoT devices and operate on all the widely used bands around the world. The u-blox module is a bit more compact.
Both modules can provide GNSS data from multiple satellite systems (GPS, BeiDou, Galileo, GLONASS and QZSS) . The R410 makes GNSS data available only via AT commands. The BG96 allows AT access to GNSS data and can also stream NMEA sentences to a dedicated USB port (/dev/ttyUSB1) from which they are easily read and processed. The NovaM does not provide any GNSS antenna connection so no GNSS data is available with that device. My devices provide two SMA connectors, one for an LTE antenna and another for a GNSS antenna. I have not tested the performance of R410 GNSS. The BG96 GNSS is well-behaved and perfoms well.
Costs
The NovaM for Cat-M1/NB-IoT is listed for $69 on the Hologram web site. My company’s device is called SimpleLTE and list price is $50 with significant discounts available on volume purchases. We can also provide a 3D-printed enclosure for the device and we can provide higher gain, rugged, SMA antennas, rather than the u.fl PCB antenna provided with the NovaM.
Contact
Feel free to reach out via this forum, or contact me directly: mbrenner@unme2.com
Technical Support
First, let me say that Hologram has been helpful at every turn, but the NovaM is built around a u-blox module that does not work reliably and u-blox is unwilling or unable to provide vital technical support and seemingly also unable to fix firmware problems in their module. u-blox never allowed us access to technical support beyond the field engineer level. The firmware problems of the SARA R410 are deep and far beyond the expertise of field engineers.
Quectel, on the other hand, has provided us with technical support at the highest level. We have ready access to their Linux experts, firmware engineers, antenna design and supply chain teams. They have generously and costlessly reviewed our designs before prototyping and tested our devices in their RF lab in preparation for Verizon/ATT certification, and provide us with access to their certification team during that process.
Make no mistake, all of the LTE cellular modules are relatively new, and so are the LTE networks. The modules are complex devices and still evolving. When problems are discovered, good techinical support is often needed uncover the nature of the problem (is it the firmware, the driver, the application program, the circuit design or something else?). If the problem is not rooted in circuit design, manufacturing, or the application program then there will be no solution without help from the module manufacturer. Quectel has demonstrated a deep commitment to quality and support. u-blox has time and again shown indifference.
What all of this means is that if you choose a u-blox-based module you better be sure it works for your purposes when you get your first one and hope it continues to work on subsequent version of the module. It is a mistake to anticipate u-blox will make any effort to sort out problems in their firmware no matter how clearly you demonstrate them. Also, I have watched u-blox provide firmware updates intended to fix firmware problems that change but do not fix the original problem.
If you are going to deploy IoT technology that depends on the SARA R410, where high reliability is a key requirement, you will be disappointed. Even firmware upgrades, from u-blox, are a nightmare to install. My experience (and that of others in this forum) is that such updates sometimes install and sometimes do not. Nobody seems to know why.
I’ll also add that u-blox prices the SARA R410 modules much higher than Quectel’s BG96 and won’t lift a finger to assist in VAT recovery so, if manufacturing devices in China (as we do), there is an additional 13% tax on R410 modules. Thus, we can produce devices with a richer feature set, reliable performance and significantly lower cost using the BG96 than is possible with the R410.
Finally, the SARA R410 is a family of one module. There are some regional variations that affect band coverage, but all are Cat-M1/NB-IoT only. The BG96 is part of a broader family of modules with identical footprints/pinouts, and that family offers Cat-M1/NB-IoT with (or without GNSS), or Cat 1 (higher speed) simply by module selection during PCB assembly.
Drivers
Both the u-blox and Quectel modules can be accessed via UART or USB interfaces. No driver is needed for UART access, but all of our devices are USB. The necessary USB drivers for u-blox and Quectel modules are readily available for Windows. For Linux, Raspbian, Armbian, etc., the USB driver for u-blox is part of virtually all Linux kernels. The Quectel driver must be built, but the build process is simple.
Hologram NovaM (u-blox R410-02b) Problems
I will focus on three problems of the SARA R410 that I encountered in 2019 that, a year later, are not resolved. Maybe I would have discovered more had I not thrown in the towel. Those problems are absent in the BG96.
For purposes of discussion, I will assume a Linux environment, but the problems are intrinsic in the device and the operating system is not relevant.
Only One USB Channel
With the proper driver installed, when an R410 is connected via USB, four new devices will appear. They will usually be:
/dev/ttyUSB0
/dev/ttyUSB1
/dev/ttyUSB2
/dev/ttyUSB3
Only one will be useful:
/dev/ttyUSB2
This port can be used to send AT commands and receive responses. If you want to set up PPP connection the PPP deamon (pppd) must use that port. Once you hand that port over to pppd you cannot send any AT commands until you close the PPP connection. So, while the PPP connection is open you cannot communicate with the R410 to obtain signal strength, registration status, or anything else.
With the BG96 driver installed and a BG96 device connected, again four devices will appear, usually named:
/dev/ttyUSB0
/dev/ttyUSB1
/dev/ttyUSB2
/dev/ttyUSB3
The BG96 accepts AT commands on:
/dev/ttyUSB2
/dev/ttyUSB3
I routinely use /dev/ttyUSB2 for AT commands and ask pppd to set up a PPP connection using /dev/ttyUSB3. Then, while the PPP connection is active I can still use /dev/ttyUSB2 for AT commands.
Network Registration Problems
Both modules cover many Cat-M1/NB-IoT bands:
SARA R410-02B: 1, 2, 3, 4, 5, 8, 12, 13, 18, 19, 20, 25, 26, 28
BG-96: 1, 2, 3. 4, 5, 8, 12, 13, 18, 19, 20, 25, 26. 28, 39
Both also support EGPRS:
SARA R410-02B: 850/900/1800/1900 MHz
BG-96: 850/900/1800/1900 MHz
Notice how many fewer frequencies/bands are used by EGPRS (pre-LTE) than for Cat-M1. A fundamental challenge for LTE module manufacturers is that mobile network operators (MNOs) operate their networks on many different bands. Verizon, for example uses primarily Band 13 (for Cat-M1) while ATT uses primarily Band 12 but may use other bands in various geographic regions. Developing firmware for the modules that is able to connect to so many bands across so many networks is complicated by differences in optimal module configuration from one MNO to another.
The approach of using AT commands to interact with modems dates back to 1981 and the 300 baud Hayes Smartmodem. It was a hack in 1981 and it is more of a hack today. There remain a bunch of core AT commands (e.g. ATZ, reset) that all modems still support, but every single modem/module manufacturer extends the AT command set with additional, unique AT commands for their product and features.
Sometimes this is necessary. For example, some Cat-M1 modules also support GNSS and have added AT commands to access location information. Sometimes it is for convenience. For example, the BG96 includes AT+QCSQ which obtains many signal strength metrics at once (RSSI, RSRP, SINR, RSRQ).
The R410 modules includes a unique and very troublesome AT+UMNOPROF command. The purpose of this command appears to be to give the module “hints” about how best to register on a specific network (or a non-specific network in the case of SIMs which can connect to multiple networks). The u-blox documention is fuzzy, ever-changing, incomplete, and incorrect.
I can provide complete details of the problems using this command (or review my posts on this forum in Dec 2019, and Jan 2020). The guidance from u-blox is inadequate. They “strongly recommend” an approach which does not work reliably and insist that taking the approach I developed which works more reliably than theirs is done “at my own risk.” In screen shares with a u-blox field engineer I demonstrated exactly the problem with their recommended approach. He confirmed the problem–as he could not deny what he saw with his own eyes–and refused to elevate the issue for resolution.
The BG96 has no command similar to the u-blox AT+UNMOPROF command and registers readily across providers and bands with native SIMs and multi-network SIMs.
Others on this forum have also found the R410 does not register reliably, or it registers reliably for days or weeks and then won’t. A module which does not register reliably and consistently may be suitable for some applications, but is wholly unsuitable for many others.
Difficult To Determine When Connection Drops, Can Lead to Data Loss
The Ublox module makes it hard to determine if the connection has dropped. There are several “features” of the module which contribute to this problem.
First, if you are using the USB interface you can have only one communication line to the module. If you choose to control the device via AT commands, then you can send whatever AT commands you want, including commands to check the status of the module. If, however, you set up PPP connection, then only the ppp daemon will have access to the module so you will NOT be able to ask the module for its connection status. IMHO this is a serious design flaw. A $5 ZTE MF190 (USB 3G modem) allows two simultaneous connections to its module, so one can be handed to PPP and the other can be used to monitor connection status.
Checking for a connection by looking for a ppp0 stanza in ifconfig (ip link) might seem like a good solution, but it can take 5 or more minutes for that stanza to disappear after the connection actually drops.
Second, u-blox has tried to make the module smart enough to handle short-term connection loss (as can happen in a mobile context after leaving the range of one cell tower (and losing the connection) until it enters the range of another cell tower). When the module loses its connection it hides this loss while waiting to establish a new connection and internally caches data during this period. However, the data cache is volatile, so if the device is powered off before it gets a new connection (and sends the cached data) the cached data is lost and the app never knows about the loss. There are possible software workarounds for this problem (which I’m happy to discuss), but you should be aware of this problem.
The field engineer with which I raised this issue intitially insisted that the R410 did no such caching. This “feature” is completely undocumented, so I wasn’t surprised he didn’t know about it. However, I constructed the following experiment which conclusively proves the existence of this undocumented feature:
A. Preparation
You’ll need a way to be able to reduce the signal strength to/from the Nova on demand. I did this by making a poor-man’s “Faraday Cage” using aluminum foil. My Nova is in a 3D-printed case I made. The case also includes a u.fl-to-SMA adapter cable, so the SMA connector sticks out of the case at one end (and the USB connector sticks out the other end). I have attached a very short (2") SMA antenna.
By wrapping the case in numerous layers of aluminum foil, coupled with the poor performance of the 2" antenna, I can weaken the signal to the point where my server is no longer receiving any data from the Nova. Furthermore, I can slide the case into the foil, to get the device to stop sending, and also slide it out to strengthen the signal and regain connectivity.
B. Experiment
Okay, here’s the experiment:
- establish a connection from the Nova to the server and watch data come in (in my case the data are GPS location packets every 30 seconds)
- run your bash script (“ip link show ppp0”) on the device with the Nova and observer that ppp0 is UP.
- slide the Nova into the Faraday cage and note that data is no longer arriving at the server. Wait for a few minutes to be sure no data is arriving. (My device, attached to the Nova, displays console messages when it sends location packets, and it continues to show these messages while no data is arriving at the server)
- run your script (“ip link show ppp0”) and observe that it still indicates that ppp0 is UP, long after data stopped arriving at the server.
- slide the Nova back out of the Faraday cage and observe that, suddenly, a bunch of location packets arrive at the server and continue to arrive (every 30 secs in my case).
- run your script again and see that ppp0 is UP.
C. Interpretation of Results
- the Nova lost connectivity while in the Faraday cage
- the shell script never detected that connectivity was lost
- the Nova cached the data packets it was asked to send during the period where it didn’t have connectivity. (So, it must have known it lost connectivity.)
- when the Nova regained connectivity it sent the cached packets
I’ll add that in a separate experiment, where I power off the Nova while it has cached packets, those packets are lost. That is, when the Nova is powered up and connected it does not send the previously cached packets.