Posts made by MeneerJacco

I’m trying to make a link budget overview.
From my understanding, the NB-IoT network attach procedure has different signal strength requirements compared to regular data traffic in the connected state.
Does anyone know in which 3GPP document I can find more information about the attach procedure and UE requirements?

I’m trying to figure out the timing schedule for the Coverage Enhanement levels of NB-IoT.
I can find online how this Coverage Enhancement level system works, but I cannot seem to find the exact timing for this process.

At what time after its first try to attach will a modem decide to increase the C-E level?
In case it is modem dependent, I am using the SIM7020G.

They are still running, so this seems to be the (temporary) solution.

@afzal_m

Yes, getting to the right person at SIMCom took longer than we hoped.
Nevertheless, we might have a solution for our problem (stress-tests currently running).

SIMCom is unclear as to why the previous batch did not have this issue, but they suggest that the trace width at the VBAT “line” to the SIM7020G modem is too narrow (0.254 instead of 1 mm) and can limit the current provided when modem is actively using the LTE antenna.

So, currently bypassing this VBAT trace (except for the reference design’s capacitors and TVS) and connecting the VBAT pins straight to the 3.6V battery.
We’ll see next monday if all our testdevices are still up and running.

Both batches are also booting with the same ‘active profile’.

SIM7020G: 
AT&V
ACTIVE PROFILE
E: 1
L: 0
M: 0
Q: 0
V: 1
X: 4
S0: 0
S1: 0
S2: 43
S3: 13
S4: 10
S5: 8
S6: 2
S7: 60
S8: 2
S10: 15
S12: 50
S25: 5
+CMGF: 0
+CSDH: 0
+CMEE: 0
+IFC: 0,0
+ICF: 3,3
+CNMI: 2,2,0,1,0
+CSCS: "IRA"
+IPR: 0
&C: 1
&D: 2
+CGEREP: 0
+CEER: 0
+CGPIAF: 0,0,0,0
+CPSMSTATUS: 1
+CSMINS: 0
+CMUX: 0,0,0,31,10,3,30,10,2

OK

Also ending with OK instead of ERROR.
However, I have not yet looked into the meaning of every value in this status report before. Just printing this for debugging purposes if our DEBUG mode is on (extra Serial prints in the lib).

@afzal_m

Thanks for the quick reply.
Unfortunately, I have already verified that slow clock is disabled in both batches, meaning the device should not enter any sleep mode on its own.

SIM7020G:
AT+CSCLK?
+CSCLK: 0

We are currently having issues with our new batch of NB-IoT devices equipped with the SIM7020G modem (own PCB design).
With the previous batch (100 devices) we encountered no communication issues using this exact software and hardware design, however with this batch we do seem to have a problem. Both batches are running the same FW version (Revision:1910B05SIM7020G).

Problem:
• Devices at some point become unresponsive to AT commands sent to the 7020G modem.
• When rebooting the modem using the PWRKEY we get responses to the first couple of AT commands, but after a while (several seconds) the modem stops responding (no AT echo and response anymore).

The AT commands I am sending are:

1. AT+GSV
2. AT&V
3. AT+GSN
4. AT+COPS?
5. AT+CFUN=0
   Waiting up to 30 seconds for “OK” response here.
6. AT*MCGDEFCONT=“IP”,“cdp.iot.t-mobile.nl”
7. AT+CFUN=1
8. AT+CBAND=8,20
9. AT+CBANDSL=0
10. AT+CRESET
    Short wait here for boot time.
11. AT+CSMINS?

Modem does not become unresponsive after a specific command, this varies. And at times, devices are not able to get responses from the modem at all on one day, but can run perfectly fine the day after.

I have tested with several batteries, with different antenna’s connected (U.FL) and by using different SIM cards. Am also not able to detect a voltage drop on the VCC when sending my data.

Anyone ever had any experience like this?
Again, I am using the same SW and HW as before…

@roalnd-baldin Thanks for your clear answer.
Happy to hear that the message will stay in the out-queue forever.

I was wondering how long a downlink message will stay in the network queue.
Or are messages kept there forever, if a device never sends another uplink?

I was wondering if the IMSI number can be read using the API, as it is visible in the portal.
Or do I need to read it myself on the device and send it in the payload?

@afzal_m Yes of course, I’ve sent them via PM. Thanks for the quick response!

I do not know if it is a coincidence, but all three of my devices I registered yesterday (Migration day) are not in my devices list anymore.
They are able to connect to the network and send data (!!!) (both actions visible and OK in debugger), but I am unable to see it anywhere, not even through the API. Last time seen in mySQL database where I log my data is around 15:00 on the 11th…

When I try to re-register them on the account I get: “Something went wrong while registering your devices. Please try it again.”

Can someone explain to me where my three devices are registered now ?

@Stefan-de-Lange , @Uta I am referring to the device’s RSSI and SNR. I want to be able to check signal quality, as I have some experimental asset trackers with GPS that I am currently testing with.

With LoRaWAN devices, I found it very convenient that all kinds of additional “network”-information was available in the MQTT response (JSON) from the API.

Re: RSSI van de zendmast in impact

I was wondering if this “feature” is on the roadmap anytime soon.
Am planning to collect RSSI and SNR together with the usual payload, but it would be better if the UE doesn’t need to include it of course .

Using a SIMCom SIM7020G.
Command “AT_CENG?” is able to retrieve all sorts of connection information, including RSSI and SNR.

Re: Data packet size

I was wondering if the recommended 512 bytes up- and downlink also applies to roaming devices.

I traveled from the Netherlands to Belgium with my roaming activated SIM and NB-IoT device.
This went well and I was able to collect data for the full time I was in Belgium.
The network connection was established in NL a few days before crossing the border and was still active while roaming to Belgium.

When I returned to the Netherlands, the device was unable to connect to the network (GPS device; last location update was just over the border). The device has hardcoded credentials for connecting. Rebooting the device and modem did not have any impact (tried on day 1). It was accepted by the network again (still in NL) on its own after around 2-3 days.

Is there any way my device’s SIM could have receive a temporary block from the network?
Am also curious if there are general situations where a SIM can be temporarily blocked by the network.

Hello @Ronan-Lacroix ,

That is very helpful information.
I will try that and see if it speeds up the process :).

Thank you very much

Hello @Uta,

I did not know of the Technology Cards.
I will take a look at PSM and the other topics.

Thank you very much.

Hello everyone,

I have a question regarding entering PSM mode.
I am using the SIM7020E module to send out data using UDP.
Afterwards, when instructing to go into PSM, the module responds with:

AT+CPSMS=1
OK

But the +CPSMSTATUS: “ENTER PSM” message sometimes takes a long time to appear.
In some cases this can even take more then a minute…

It looks like the timing of this command has some influece, and I was therefore wondering if there is any protocol or guideline for entering and exiting PSM mode from the network side.

What could be the case for the network accepting my PSM request so late sometimes?