Comparing BC660K and BG950A module

IoT Modules LPWA Module
1

Hello.
After spending meanwhile weeks with BC660K module, I am meanwhile very unsure if this is useful for my needs.

  • I have very unreliable TCP/IP connection.
    Often the modem claims to be registered, but I cannot get anything sent to a host. Sometimes it needs up to 20s to transmit one packet of less than 100 bytes.
  • Round trip time (Sending a packet and waiting for respons/confirmation) reaches 20 seconds, sometimes I am at 2-4 seconds (this is acceptable).
  • Often I can not connect to a server while pings are working.
  • When trying to send more than 92 bytes in one at+qisend command, nothing appears at all on server side. Also not at later time (>40 seconds).
  • Resistration in the network often needs horribly long

So, over all, NB-IoT may be useful for sending a few bytes, but even attempting to send 30 datablocks of 92 Bytes is a nightmare, and I have no idea if I can improve that by special settings.

Compared to the above troubles, is the BG950A module drastically better?
It is important to me that I can more or less trust the modem. When I open a TCP/IP connection, it should be stable and allow a round trip time of 2-4 seconds in average, but not exceed 10-15s.

If some of you could tell me their experience, it will be very valuable to me.

About power supply (VBAT) on BG950A:

  • Does it really need two sets of capacitors, or can both VBAT pins be connected at the module and connected to one set of capacitors? It is a question of space on PCB.
  • Is a Low Voltage Drop regulator 5.0V → 3.3V, like LD1117S33 sufficient for BG950A? My Microcontroller is running on 3.3V, but I also have 5.0V up to 2A available from switching regulator. I would like to give the modem a separate voltage regulator because of its current spikes.
  • I try to understand how to power the module up/down by reading the datasheet. Itr is a bit blurry to me. There is a PON_TRIG pin and a PWRKEY pin. Do I understand right that PON_TRIG is an input accepting only 1.8V ? Can I take this 1.8V from 1.8V output of this module?
  • How shall I connect the BG950A to my microcontroller? Series resistor in data lines is sufficient? I am a bit scared about MCU UART’s Tx pin. If the UART is idle, it is high (3.3V). What if the BG950 is in PowerOff powersave mode? Does it allow 3.3V on input?

I hope I could express well enough what I am thinking about. I do not want to develop another PCB (because that with BC660K I can forget) and finally find out that nothing of importance to me is better at all.

2

BC660K-GL and BG950A-GL are modules for different network types. While the former supports NB-IoT only, the latter supports NB-IoT and LTE-M. We use BC660K a lot and it us a very reliable module.

  • If round-trip takes 20 seconds then you’re still within specs for NB-IoT that defines latency up to 10 seconds (in each direction). So it’s not about the module, but the network. Our round-trip time is mostly within a second or two.
  • Registration takes long time. Again, this is NB-IoT, that’s how it works (it’s a result of better link budget). You can (and should) restrict the bands that are searched, but complete band search will still take a few minutes. It’s not the module, it’s the technology. Check Quectel_BC660K-GL_BC950K-GL_Network_Searching_Scheme_Introduction_V1.1.pdf document for more details.
  • Sending longer data packets. Works fine, we even transfer tens of kB of data. If you’re not able, then there’s something in your setup or the network coverage is not good enough in your area. But remember that NB1 offers max. downlink rate of 26 kbps and uplink rate of 62 kbps. NB2 can be a bit faster, but still nowhere near LTE (or even LTE-M).

Prior deciding between these two modules I suggest you think of your requirements and check what networks are available in the areas you want to deploy your devices.

3

Hi, rastik.
Thank you very much for this detailed explanation. Because of the lack of cell roaming (or how transitioning between radio cells is named), I meanwhile decided to use BG950A instead of BC660K. LTE-M should allow that and is even faster, so this is worth the little higher price.
But I also decided to not use the BG961 model, this is ways more expensive than using a BG950A+separate M8N GPS Module, and I also already know what the M8N module does. (And it works like a charm, while I can find only very thin information about BG951A module.)

I will hopefully receive the BG950A modules coming week, then I will build up two modems on my own PCBs and can test. But at the moment I have no modules at hands.

Does the BG950A require the entire challenge of trial & error with finding required settings to be started by zero, or will it work with almost no changes? I ask because I wasted so much time with getting the BC660K working (meanwhile it seems to be solved), I hope and pray this will not be necessary again with BG950A.

Does the BG950A automatically use (and prefer) LTE-M and use NB as some kind of fallback (when SIM is open for both modes), or do I have to actively select what mode to use by an AT command?

I strictly followed the Hardware Application Notes of BG950 and built all interfaces with transistors (BC817) for interfacing PWR_KEY and similar, but also use the two transistors schematic for level shifters. Hope this allows operation at 115200 bps well enough to switch baudrate down to 19200 bps.
(I cannot understand how a manufacturer can get the crazy idea to set a high baudrate as default. What, if one has hardware not supporting 115200bps at all? Therefore I would set a slow speed as default, i.e. 9600bps, and allow setting a higher speed by software. This is the safe way. Luckily I can use 115200, but I still switch down to 19200bps to have a little more time in my multitasking for processing.)

4

You always need to go through the documentation and set the module according to your needs. It may work out of the box, but it’s definitely not enough. But both have all relevant settings described in the documentation, e.g. whether to use LTE-M or NB-IoT and what’s their priority. BG950A is not easier to work with than BC660K. If you feel lost with BC660K, you might end up in the same situation with BG950A.

Is there any MCU that does not support 115200 these days? Is there any reason why would you work with 9600? 115200 is a common default in modules for many years, even GNSS receivers have it as default. And sometimes you need to use higher speeds. If you’re going to upgrade firmware in BG950A the recommended speed is 3Mbps and flow control. Without flow control you’ll use 921600 and it will take more than 7 minutes.

I prefer ready-made level shifters. With the most basic config you only need two channels for main UART. And for PWR_KEY you can use tri-state config, because there’s internal pull-up resistor. So on MCU side you either pull it to ground or set it to high impedance state. Basically it’s the schematic with a button, but instead there’s an MCU doing it.

5

rastik,
sorry, but I have to disagree…

It seems to be a very typical point of view of today’s developers. “Get what you can get, use as much as possible, …” following the idea: Much helps much. The result often is increased sensitivity and other things… You absolutely corretly said: “And sometimes you need to use higher speeds.” – Sometimes yes, but often no.

An example?
My MCU is a PIC18F67K40 @ 64 MHz. It is really fast, I am running more than 20 tasks in parallel on it. Of course, it is able to use 115200bps, but because I am using a multitasking system, the CPU is also busy with other things. The problem is not the transmission at 115200, this is well done by the interrupt routines, the problem is the time between particular received lines (= time I have to process the line before it is overwritten by the next line). The simplest way is reducing the baud rate, this gives more time for processing.

You ask: Which today’s CPU does not support 115200…
I could also ask: Why can’t the module do automatic baud rate detection?
Automatic baud rate detection is the best approach at all, because you can use (and talk with the module) on literally every possible speed without any issues, and without the need for configuring its UART speed. This is LOTS smarter than starting with 115200 bps and locking out hereby all MCUs that are not able to (reliably) use such speed.

Send “at” and and find the baudrate of it inside the modem automatically! All the modem has to do is measuring the time a character needs. Or, if too complicated to do that with any character, do use a series of $AA for auto-bauding. $AA is a nice “magic byte” with a perfectly symmetric 1-0-1-0-1-0-1-0 pattern for counting bits. I would recommend that instead of setting such unnecessarily high default of 115200 bps.

Next approach is having a lo w default speed, i.e. 9600bps. If one wants faster speed, he can configure it as he likes, too! But the module itself starts on safe side, it can be used with literally every CPU.

In practice, this would give a lots wider range of compatibility.

6

Actually, BC66 (predecessor of BC660K-GL) supported automatic baud rate detection and we always disabled it during production, because the module would not send any data prior it’d received AT from us. But all modules (BC66, BC660K and BG950A) can be configured for specific baud rate, so maybe you can add this step to your device production - send AT+IPR=rate, e.g. during firmware initialization when no other tasks are running yet. You can even set it to auto detection on BG950A, just it’s not a default, so it has to be changed once. Don’t forget AT&W and it’s for the module lifetime.

With BG950A you can as well use hardware flow control, this should cover situations when your MCU does not have enough time to process incoming data.