Potential device lockdown - Network providers

[timh]

@tealbrains I have finally spoken to Telstra.

A couple of things to note. They are suggesting that it's in trial phase and not fully rolled out to all cell locations.

• this doesn't explain why we can't connect now, unless they have disabled some towers, especially as the SIM does work in another device in the same location.

They are running traces on some of our kit, and at the moment they are suggesting they are not even seeing an ATTACH attempt. I have got some more devices being turned back on and they will also trace these to confirm.

This would suggest a change in their network - either blocking, or an incompatible (to SEQUANS) change to the network .

[tealbrains]

@timh Thanks for the update. If other modems work it is obviously something they have changed on the network side (updated towers?) which the Sequans Monarch modem is not able to deal with.

I have been able to use cat-m1 with other modems after the collapse, but not with Pycom boards.

Pycom boards seem to be working in some areas of Brisbane though...

[timh]

@tealbrains I have been working with Telstra this morning trying to trace connections (of multiple devices).

There response so far is

"I have set up the traces with this test service <mobile number>. However I am not able to see any signalling hitting to Telstra’s network so far.
I can see this device is configured correctly on the network. I believe we have to get Device manufacturer to investigate and look at this from device "

[jcaron]

@tealbrains the fact that it suddenly stopped working with no changes on the device side clearly points to a change on the Telstra side. Do you have a specific date (and time) for when it stopped working? Did they perform any updates (of the base stations or servers) at that point?

Are there multiple frequencies/bands they support(ed)? Did that change? Have you tried on other bands?

[tealbrains]

@jcaron Everything went down around Friday 15th of June. CAT-M1 here works on B28 (700MHz), 20MHz are dedicated to it.
They say no changes were made but it is pretty obvious changes were made somewhere. Ultimately Sequans and Telstra will need to discuss the matter but Pycom should at least try to by the catalyser.

[timh]

@jcaron I have confirmed with the Telstra Engineer that we need to be on band 28, in addition all connections must be access technology must be E-UTRAN

How I might achieve that I am not sure. Tried many different things today but as I pointed out earlier Telstra don't see an attempt to connect in the traces.

I will contact the engineer again tomorrow, and try and pin them down on possible network changes on the 15th. However I had gear online up to the 16th of June in Newcastle at 1:43pm WST. I can't be certain they disconnected at that point due to Telstra or our field staff turning the equipment off.

So we have a few different dates and a fairly broad window for a change to have occurred.

[tealbrains]

@timh I can't pinpoint the exact time but it definitely happened between the 15th-16th and the 18th. Things were working before the weekend: we drove around to measure the RSSI in different locations. I went back to work on Monday and that was it... no more connections were made.

[timh]

@tealbrains not having much luck with Telstra

I received this response this morning.

The INC has been closed due to the findings from WMO engineers.

The engineers resolution is as follows:

No network issue for any of the devices. We believe that the issue is the device configurations.
This is due to not being able to see the service request coming onto the Telstra Network.

[timh]

@timh I just spoke to the engineer I have reported to and they said hey isn't closing the issue.

He understands that something has changed in the Telstra network that has caused the PyCOM devices to not be able to register.

However he did say the PyCOM devices have not gone through an approval process for Telstra network.

We really need some response from PyCOM people on this issue. (There are a lot of companies reselling the product in Australia which will not work here)

[tealbrains]

@timh

However he did say the PyCOM devices have not gone through an approval process for Telstra network.

That is the bit that worries me. What does it mean exactly? I contacted Sequans but haven't heard anything back from them. No admin has chimed in, I guess Pycom is no longer an option for my current projects... I am happy to pay a premium price for hardware if we get suppport. If there is no support then...I don't know where the value is.

EDIT:
Just came across this:

https://pycom.io/state-lte-m/

So, in other words. Don't develop a commercial solution around Pycom+LTE. You'll have issues.

[robert-hh]

@tealbrains Being in Germany, one topic of this table is confusing. Pycom does not Talk to Deutsche Telekom, but is in discussion with T-Mobile, which is a brand of Deutsche Telekom, at least in Germany.
But this is just a little inconsistency. More sad: T-Mobile does sell NB-IOT SIMs only to commercial customers. The smallest package you can get is 50 SIM cards. They announced a flat rate card (10€, 10 years, x MB data) last August, but no one at T-Mobile and Deutsche Telekom Sales & Shops knows how to get it.

[micksta]

@timh

Hey timh & tealbrains, appreciate the contact & follow up with Telstra. I believe in the early day's Pycom had some chats with Telstra, hopefully they still have those contacts. I'm also on the tealbrains path & looking for a solid option for several projects. Thanks guy's - product had promise.

[daniel]

Hello,

Apologies for the lack of response. We have a new Cat-M1 firmware which should solve the issues with Telstra. This firmware will be available in a few hours on this link: https://software.pycom.io/downloads/sequans.html (FIPY_GPY_CATM1_36417.dup). In order to connect, the attach command should be as follows:

AT!="RRC::addScanBand band=28"

After that, then send (do not call lte.attach() explicitly):

AT+CFUN=1

Regards,
Daniel

[timh]

@daniel Hi Daniel

Thanks for the update.

Can you provide the full connection details. As you can see the in the other threads we spent quite a bit of time trial and error working out how to connect to Telstra.

For instance we have all been sending

AT!="RRC::addscanfreq band=28 dl-earfcn=9410"

Is that relevant now ?

Some clear repeatable instructions would be really good.

Thanks

Tim

[timh]

@daniel oh and the firmware isn't available yet (a few hours have passed ;-)

[Xykon]

@timh said in Potential device lockdown - Network providers:

@daniel oh and the firmware isn't available yet (a few hours have passed ;-)

The file is now only available.

[timh]

@xykon Awesome. Thanks

[micksta]

@timh

Telstra still no go (for me anyway'z), seems to find tower but then issues out - tried several location around town.. Some notes below.

Modem f/w --> FIPY_GPY_CATM1_36417.dup

(sysname='GPy', nodename='GPy', release='1.17.5.b6', version='v1.8.6-849-56d00234 on 2018-05-18', machine='GPy with ESP32')

I'm not calling lte.attach(), use 'AT+CFUN=1' for that --> snippet of below below was definitely working before changes to telstra network

'AT!="addscanfreq band=28 dl-earfcn=9410"' # lte frequency band - from forum

AT+CGDCONT=1,"IP","mdata.net.au"' # Aldi sim / Aldi APN (aka Telstra network)

---

FSM (loops through the below)
SCANNING
SYNCING
STOPPED

-------- e.g. --------------------------------

SYSTEM FSM

+--------------------------+--------------------+
|            FSM           |        STATE       |
+--------------------------+--------------------+
| RRC TOP FSM              |SYNCING             |
| RRC SEARCH FSM           |WAIT_SYNC           |
| RRC ACTIVE FSM           |NULL                |
| PMM PLMN FSM             |NORM_WAITCELL       |
| EMM MAIN FSM             |NULL                |
| EMM AUTH FSM             |KASME_DEFINED       |
| EMM CONN FSM             |NULL                |
| EMM TAU FSM              |NULL                |
| EMM TEST FSM             |NULL                |
| ESM BEARER FSM           |BEARER_NULL         |
| SMS MT FSM               |IDLE                |
| SMS MO FSM               |IDLE                |
| HP MAIN FSM              |IDLE                |
| HP USIM FSM              |READY               |
| HP SMS MO FSM            |IDLE                |
| HP SMS MT FSM            |IDLE                |
| HP CAT FSM               |IDLE                |
+--------------------------+--------------------+

---

DL SYNCHRO STATISTICS (loops through some of the below but random)
CELL_SEARCH
FAST SCAN
FRAME_UPDATE
MIB_DETECT
IDLE
RSRP

-------- e.g. --------------------------------

DL SYNCHRO STATISTICS

Synchro state                         : CELL_SEARCH
PPU SIB1 ACQ watchdog                 : 0
Frequency Hypothesis RF  (Hz)         : 0
RSRP (dBm)                            : -21474836.00
RSRQ  (dB)                            : 0.00
Channel estimation state (Cell-spec.) : LOW CINR
Channel estimation state (UE-spec.)   : LOW CINR
Channel estimation state (MBSFN)      : LOW CINR
Channel estimation CINR               : 5.62
Channel length                        : SHORT
AGC
AGC RX gain (dB)                      : 60.22
RX PSD BO (dBFs)                      : -23.42
RX PSD (dBm)                          : -111.79
Noise level RS (dBm)                  : -128.24
Digital gain (dB)                     : 4.78
CINR RS (dB)                          : 0.00
NARROWBANDS
Last DL NB                            : Central
Last UL NB                            : 0
AFC
Frequency offset RF  (Hz)             : -379
Frequency offset BB  (Hz)             : 0
PBCH
MIB received quantity                 : 21
MIB timeout quantity                  : 0

WITH CREG SHOWING

+CREG: 2,0

[timh]

@micksta bugger ;-( I haven't had a chance to test myself yet. Up to my eyeballs. Hoping later this afternoon.

Some my guidance on specifics from @daniel or @xykon would help a lot.

[tealbrains]

Not only it is not working for me but it is even worse now (I did not think it could get any worse but it did.)

I am not able to get a CCID from the (M2Mone) SIM card when issuing:

send_at_cmd_pretty('AT+SQNCCID')

I thought it would maybe be an issue with the SIM card itself so used a GPY that still had the previous modem firmware (FIPY_GPY_CATM1_33988.dup) with the same SIM card and it worked.

So, summarising:

• GPy on stable 1.18.0 with FIPY_GPY_CATM1_33988 -> Lost Telstra connectivity a few weeks ago but it can talk to the SIM card.
• GPy on stable 1.18.0 with FIPY_GPY_CATM1_36417 -> Can't talk to SIM card, which I believe is what is producing an ERROR response when issuing

send_at_cmd_pretty('AT!="RRC::addScanBand band=28"')

It would seem we are taking one step forward and two steps backward...

If @micksta, @timh and @Prawnhead can confirm this behaviour the problem is still there.