Sim7000E difference between networkmodes automatic and GSM/LTE only

[I-Connect]

Hi,

I am using a SIM700E with an ESP32.

When trying to connect to a network the first time with a new sim7000 and networkmode set to "automatic" (CNMP=2) it does not connect, when checking the network status I get CSQ=99 (not known or not detectable).

I was in doubt if it was related to coverage so I left the modem trying it for a prolonged period of time, no result. (and tried different antennas)

Then I switched the network mode to "GSM only" and it immediately connected. (modem was not powered down) Switched it back to "automatic" and again immediately it connects.

So what is the difference between " automatic" and "GSM and or LTE only" what are the other options automatic would try (as the sim7000 is a data modem only...)?

thx

[star297]

Hi I. I'm using the SIM7000E PCI-e module on a ESP32-PCI-e board. Arduino v1.8.13 IDE ESP32 board v1.0.6 TinyGSM v0.10.9 library Arduino PubSubClient library v2.8.0 Arduino Json v6.18.5 Emnify SIM card

Works seamlessly in a static or mobile environment. I set up with network MODE to 'automatic' and modem.setGNSSMode(3, 0);

Depending on your location, due to 2G and 3G being phased out, certain GSM connection types may not be available, I would suggest to contact your airtime provider for more information.

[I-Connect]

thx for the reply.

I know some networks are phasing out (that is why I am switching from sim808 to sim7000 :-) ). I expected the "automatic" setting to resolve this automatically. But as stated above, when I am commissioning a new sim7000 IC it does not connect with the setting "automatic" at first but is does after I first connect with setting "GSM" so I guess there should be coverage...

I am using a 1nce sim btw. This is a (almost) world wide data only sim card with 500 MB and 10 years lifetime (which both can be topped up/extended). Not sure which network it uses in NL, I will look into that...

[star297]

We decided to use SIM7600E (4G) modules, slightly more expensive than 7000 but we're not sure if and how much LTE-m and NB-IOT will be available across Europe and which SIM data provider will be able to provide that service for us. I can't get a definitive answer. Also we use more data than NB-IOT would suit anyway. I did use Vodafone and Movistar SIM's in North Spain in the 7000, but non connected to LTE-m, only 2G. Also I found dead areas where the 7600 would work because it has 4G. Other than that the 7000 performance is much the same as the 7600. EMnify gave us the best SIM deal, they use all networks across Europe and these connect to 2G, 3G and 4G with no break in connection even traveling 600km across Germany, seamlessly switching network operators.

[I-Connect]

thx for the tip, I need to look into this. I assumed the Sim7000 also supported 4G.

After rereading the specs after you comment I am still a bit puzzled... very confusing all these different standards...

from the datasheets: The SIM7000 series modules support LTE CAT-M1、 LTE CAT-NB1、GPRS and EDGE the SIM7600 support GSM, WCDMA, LTE-TDD and LTE-FDD

Supported LTE bands:

The most used 4G bands in NL are 900 and 1800 which are both supported by the SIM7000 So confusing.... so which parameter defines if the module is "basic" 4G capable?

[SRGDamia1]

Has this issue been resolved?

The bands and protocols are .. confusing .. to follow. The terms 4G and LTE are often used as if they're the same, even though they're not. But, yes, the SIM700 is LTE, like the specs say, but getting it working depends on your SIM card and providers support as well.

[I-Connect]

Hi,

Not really resolved but I will probably use the 7600 in my next pcb batch.

Still my question remains, which "band" or parameter in the SIMCOM datasheet shows that it is basic 4G data compatible?

[SRGDamia1]

I don't understand what you're asking. The parts of the datasheet you quoted say the SIM7000 is LTE compatible and list the specific parts of the protocol and bands it supports. To my knowledge there isn't one universal "basic" compatibility. Each module, cellular tower, and SIM card provider has a lists of specific supported protocols and bands and you need to align all three for a data connection of any kind to work.

It can be really confusing. Here's a hand-waving example for the US:

In the USA, AT&T supports LTE-M connections primarily using band 12 (700 MHz), with possible additional support on bands 17, 14, 29, 5, 4, 2, 30. It does this by way of big towers and antenna. For a module to work on the AT&T network, it must have a SIM card authorized to be on the network, have the capability of operating within the band that AT&T has legal rights over and using the specified protocol, and be physically in range of the signals from a tower that broadcasts in that band and protocol. Not every tower supports every band or protocol that AT&T legally can use. Not every SIM card does either. No SIM card will work without the proper APN and a paid-up account. T-Mobile uses many of the same bands as AT&T, but has separate towers and SIM cards. And T-Mobile has adopted mostly the NB-IoT portion of the LTE protocol rather than the LTE-M specification. So even just looking at those two carriers in the USA, there isn't a single "basic" 4G support that any module can just use to work with both of them.

[I-Connect]

thx for your patience trying to explain it to me :-)

I get that I need the full stack to be able to have certain connectivity.

So what you are saying is that a specific band is not for a specific protocol. So Availability of a specific protocol depends on what protocol is provided by the network provider in a specific location on a specific band? That does make sense...

So if I would simplify it, is it the case that the sim7600 has better coverage just because it supports more frequency bands?

[I-Connect]

@star297 do you use both main and aux antenna in your pcb design for the 7600?

[star297]

We only use the 'main' antenna. I didn't notice any signal improvement when I tried adding an 'aux' antenna , but it may only be for 3g. We use Lynx ANT-LPL-FPC-100 antennas, we sick them inside the enclosure with excellent results.

[I-Connect]

just FYI

while just looking around I found this:

Depending on what technology (3G/4G) is used to connect to the mobile network provider, "AUX" antenna performs a different role:

When "3G" technology is used, "AUX" antenna is used as "diversity antenna" for error correction. Its effects are mostly noticeable in poor mobile signal strength areas. When "4G (LTE)" technology is used, "AUX" antenna is used both as diversity antenna and as a secondary receiving antenna, increasing data connection quality and overall mobile download speed of the device.

[I-Connect]

@star297 it's a bit off-topic but we are struggling a bit with keeping the GPRS connection alive while trying to take all kinds of exceptions into consideration... -Application layer (Blynk) looses connection to the back-end -GPRS connection fails -SIM7000 not powered on -SIM7000 going into a continues state of "unable to connect to network"

We run a task on a ESP32 that checks the connection and state of the SIM7000 every 100 ms (run method connectGprs() ) We frequently (few times a day) see the GPRS reconnecting with below code on different devices. Often the reconnect happens quickly and the application layer (with a connection timeout of 60 sec) does not even notice it but sometimes it takes a much longer time to reconnect.

Do you recognize this behavior? Any hint to how we could improve this? Do you have this kind of exception-checking implemented?

bool BlynkNodeSim7000::connectGprs() {
  bool result = false;
  if (takeGsmSerialSemaphore("connect GPRS")) {
    if (!gsmGps->isGprsConnected()) {
      blynkTask.disableWatchdog();
      if (swRestartModem()) {
        if (Blynk.connectNetwork(gprsApn, gprsUser, gprsPw)) {
          log_w("Reconnecting GPRS");
          result = true;
        } else {
          log_e("GPRS connect failed");
        }
      }
      blynkTask.enableWatchdog();
    } else {
      result = true;
    }
    giveGsmSerialSemaphore();
  }
  return result;
}

bool BlynkNodeSim7000::swRestartModem() {
  bool result = false;
  if (gsmGps->testAT()) {
    result = gsmGps->restart();
  } else {
    log_e("communication with modem failed, powercycling");
    powerCycle();
  }

  if (!result) {
    log_w("Failed to restart modem, powercycling");
    powerCycle();
  }
  return result;
}

bool BlynkNodeSim7000::powerOn() {
  bool testAt = false;

  testAt = gsmGps->testAT();
  if (!testAt) {
    #ifdef DEBUG_BLYNK
    log_d("GSM/GPS not responding, turning on...");
    #endif
    cyclePowerOnPin(1100);
    testAt = gsmGps->testAT();

    if (!testAt) {
      log_e("GSM/GPS power on failed, retrying...");
      cyclePowerOnPin(1100);
      testAt = gsmGps->testAT();
    }
  }

  if (!testAt) {
    log_e("GSM/GPS power on FAILED");
  } else {
    #ifdef DEBUG_BLYNK
    log_d("GSM/GPS powered on");
    #endif
  }
  return testAt;
}

void BlynkNodeSim7000::powerOff() {
  #ifdef DEBUG_BLYNK
  log_d("Powering down GSM/GPS");
  #endif
  cyclePowerOnPin(2000);
}

bool BlynkNodeSim7000::powerCycle() {
  #ifdef DEBUG_BLYNK
  log_d("Power cycling GSM/GPS");
  #endif
  powerOff();
  delay(5000);
  return powerOn();
}

[star297]

We check GPRS connection every 10 minutes when GPRS is idle, 100ms seems rather excessive but every application is different. Don't normally have any disconnection issues but if we do the time out is set to 20 seconds so we do not block the system for an extended period. As you say this is not normally noticed by the end user and will connect almost instantly. But if it does not reconnect within 20 seconds, we won't try again for another 2 minutes to avoid blocking the device.

-Application layer (Blynk) looses connection to the back-end -GPRS connection fails -SIM7000 not powered on -SIM7000 going into a continues state of "unable to connect to network"

Smells like Modem power supply regulation issues. We found the ESP32 TTGO PCIe devices, although good, were a little unreliable with similar problems that you mention. The Modem won't power down on its own unless it 'browns out'

I don't know what your hardware configuration is but my test devices (using SIM7600 and SIM7000) based on our PCB design below are connected 24/7 with low GSM signal and never drop out. We use three separate 2000mA dc-dc buck converters, for the ESP32, Modem and control peripherals. SIM7000 and SIM7600 have much the same GPRS performance over MQTT however the SIM7600 appears to have a more sensitive GPS(GNSS) capability in poor signal locations.
On another note, we had a few remote devices where the ESP32 locked out completely requiring a hard reset so we added a hardware watchdog IC (TPL5010DDCR) that we use in conjunction with the ESP32 system watchdog.

[I-Connect]

Hi Paul,

Thx for your open answer :-) Nice compact design!

The 100ms is the delay in the task that also executes the update with the backend (we just switched to Blynk instead of MQTT). We made it this short as we want a quick response when new data (both from back-end or from device) is available. But I will re-assess the timing on this. Although I do not see any blocking behavior at the moment when we are checking/restarting.

Btw we do not experience the SIM7000 to spontaneously power down, but we are checking for this exception and try to resolve it when it happens.

We do experience sometimes the SIM7000 going into a continues state of "unable to connect to network", this does not seem to resolve by itself, after a power cycle of the SIM7000 it works again. I have to admit that I am having a hard time designing the 50 ohms trace to the antenna connector. I measured it on the proto pcb (which we are currently testing and what my findings are about) and I think I made an error somewhere and it is not 50 ohms so I am probably also loosing a lot of signal there... and maybe this is also causing the SIM7000 going into a continues state of "unable to connect to network"

We use 2 buck DC-DC converters (AP1509) for powering ESP (3v3) and SIM7000 (3V7)

And have additional caps as described in the SIM datasheets:

A test batch for a new design is in production (with sim7600) and (hopefully) a better antenna trace design.

The RTC on this design is new (AB1815) and has a watchdog and reset capability that we did not have before, I will definitely look into implementing this.

[camp-easy]

hello everyone, so what module do you think is better for IoT application? sim7000g or sim7600g? and eventually is sim7000g standalone programmable? thx in advance :)

[I-Connect]

The 7600 supports more bands so theoretically better coverage, not sure what you mean with stand alone programmable.

[camp-easy]

hi thx @I-Connect , i mean that the 7600 module have a open Cpu and the user can flash its code to the memory of the module or not (so that eventually he doesn’t need an ecternal programmable cpu). Thx in advance