Fipy LTE connection working with Telstra

[IOAg]

@daniel below calls sequence allows me to connect to LTE Telstra and keep connection open:

Yesterday, I downloaded latest fipy firmware v 1.17.2.b1; making use of new LTE attach(band=28) does not allow me to attach. Looking into modlte band setting, I cannot connect using below setting:

Do you mind confirming with Telstra what setting is correct?

[nathanh]

@timh @IOAg I am not sure how you guys have been going with the LTE stuff but after 2 days of testing I am still finding it very flaky.

I tried your earfcn settings and find that the unit finds a cell tower much quicker and consistently but still would not attach. I then updated to the latest FiPy firmware and then updated the Sequans firmware as per (https://forum.pycom.io/topic/2902/cellular-radio-firmware-release-sqn3330-for-both-cat-m1-and-nb-iot). I then found I started to be able to attach and connect.

However, saying that, it is still inconsistent. I have had my device in the same spot for two days and I will get periods where it will connect almost every time, then hours where I get nothing. I also still have the modem crash when it is connected after a short period of time and then have times when it won't recover (lte.reset fails and machine.reset does not work either) with the only solution to perform a complete power cycle of the FiPy unit. Also it does not always attach/connect first go and I need to reset/attempt to attach in a cycle a few times.

So while, when it does work, it connects more often there is no way I can consider my FiPy/The LTE modem as a reliable device. Pretty much at my wits end with this and looking at moving to a new platform. Would be interested to see if your results are similar or you feel you have a complete stable solution you would use as a commercial product?

[timh]

@nathanh on that topic.
We have many devices also currently using an existing platform. So I don't want to introduce any additional external services.

Yes they have a REST api as well, but to date we have found MQTT extremely reliable for what we do especially for bi-directional (and not having to poll for messages).

We are moving down to smaller devices without a local broker acting as a bridge so MQTT may in fact be the wrong choice.

I am just using bits of the specific AWS MQTT library to connect to Losant as the normal mqtt library seems a close port to the Arduino libs which leaves a lot out.

I need to test to see where we go. The main problem is resetting the modem on loss of connection at the moment rather than MQTT ;-)

Cheers

T

[nathanh]

@timh

@timh said in Fipy LTE connection working with Telstra:

Having got a connection I moved onto trying to get mqtt working.
However there seems to be a few issues with the pycom mqtt lib when using userd/passwd. Kept getting short response.

So not to go too far off topic, I don't bother with mqtt or other IoT "protocol" gimmicks as I find it is all half baked, half complete and flaky side projects. I run all my data through stock standard web api using JSON for data xfer and sending simple socket connections as a post request has been working fine for me (when it does connect).

Given it seems you are working with AWS.. Why not just use an intermediary service in AWS (even a simple EC2 web server) that can take a post/socket/tcp connection and transform it back to the mqtt server which might get you ahead quicker than relying on Pycom.

[timh]

@ioag To be honest, I think both work. Too many moving pieces and I had upgraded firmware this morning.

(sysname='GPy', nodename='GPy', release='1.17.3.b1', version='v1.8.6-849-83e2f7f on 2018-03-19', machine='GPy with ESP32')

Having got a connection I moved onto trying to get mqtt working.
However there seems to be a few issues with the pycom mqtt lib when using userd/passwd. Kept getting short response. Quickly grabbed bits of the AWS MQTT lib and used the core to connect to losant, (over wifi) and now going back LTE.

Yes heading off topic here. My requirements are MQTT over LTE. So the pieces are falling together.

I am finding if I lose the LTE connection it appears I need a hard reset to get it back.

Will report further on this, and exactly what combinations of APN and earcfn do in fact work.

Thanks for all your help.

[IOAg]

@nathanh @timh both APN (telstra.m2m or telstra.internet) work for me, hence I was not thinking it would make a difference to Tim's connection. Telstra should be answering why?

[IOAg]

@timh awesome you are connecting at last :)

[nathanh]

@timh said in Fipy LTE connection working with Telstra:

@nathanh @IOAg

Ok, just found a problem in my code and your solution - should have looked more closely (must wear my glasses ;-( . I was using an APN of telstra.m2m and then just noticed @IOAg your using telstra.internet.

And now it connects.

That is a big improvement.

Just to confirm, does using telstra.internet still work without setting the earfcn before calling attach? Since attached resets the scan frequencies anyway? Or maybe once the device is attached to a cell, resetting the scan frequencies does not force it back into a scan mode until you reset power functionality or it loses connection to a cell. Would be interesting to see what happens once you move around and need to swap towers.

For what it's worth my SIM supplier says you can use either telstra.m2m or telstra.internet but default to m2m. (https://www.m2mone.com.au/faq/). It would seem odd the combination of an earfcn + apn would be required since neither are really reliant on each other in a normal network setup. It would only be if Telstra are doing some really specific network isolation. All very interesting though, looking forward to getting back and testing it.

[timh]

@nathanh @IOAg

Ok, just found a problem in my code and your solution - should have looked more closely (must wear my glasses ;-( . I was using an APN of telstra.m2m and then just noticed @IOAg your using telstra.internet.

And now it connects.

That is a big improvement.

[nathanh]

@timh @IOAg

@timh said in Fipy LTE connection working with Telstra:

Note the lte_attach source shows any call to lte_attach performs a clearscanconfig followed by a series of addscanfreq re-adding "AT!="RRC::addscanfreq band=28 dl-earfcn=9435"" which seems to be the problem.

I was wondering how this would work as well. From reading I imagine you get a Cell Acquired after you set the power functionality to 1 but as soon as you hit lte.attach() you are losing any custom scan freq settings. You would need to change and compile your own firmware to retain the settings.

Saying that, good work @IOAg on getting that earfcn, I tried a couple of different settings I had (albeit they were for when band 28 was for 4G proper and not cat-m) and met with no success

[timh]

@ioag

Here is one showphy, buts is cycling rapidly between DRX START, DRX RESTORE CONFIGURATION and an occasionaly FAST SCAN and CELL ACQUIRED. I had never seen a CELL ACQUIRED prior to using earfcn=9410

DL SYNCHRO STATISTICS
=====================
	Synchro state                         : CELL ACQUIRED
	PPU SIB1 ACQ watchdog                 : 0
	Frequency Hypothesis RF  (Hz)         : 0
	RSRP (dBm)                            : -115.74
	RSRQ  (dB)                            : -25.71
	Channel estimation state (Cell-spec.) : LOW CINR
	Channel estimation state (UE-spec.)   : LOW CINR
	Channel estimation state (MBSFN)      : LOW CINR
	Channel estimation CINR               : 0.00
	Channel length                        : SHORT
  AGC
	AGC RX gain (dB)                      : 58.81
	RX PSD BO (dBFs)                      : -25.70
	RX PSD (dBm)                          : -109.04
	Noise level RS (dBm)                  : -102.62
	Digital gain (dB)                     : 15.76
	CINR RS (dB)                          : -13.12
  NARROWBANDS
	Last DL NB                            : 6
	Last UL NB                            : 1
  AFC
	Frequency offset RF  (Hz)             : -502
	Frequency offset BB  (Hz)             : 0
  PBCH
	MIB received quantity                 : 28
	MIB timeout quantity                  : 0

OK

Lastly CEREG

 >>> print(lte.send_at_cmd("AT+CEREG?"))
 +CEREG: 2,0 
 OK
 >>>

the attach method is looking for CEREG: 2,1 and isattached() never returns True

So I have a bit of a way to go ;-(

T

[IOAg]

@timh your sequence works for me, so all good there.

earfcn was given by tech staff at Telstra :)

Here is my output showphy if that helps you to compare with yours:

lte.send_at_cmd('AT!="showphy"')
'
DL SYNCHRO STATISTICS
=====================

Synchro state                         : IDLE
PPU SIB1 ACQ watchdog
: 0
Frequency Hypothesis RF  (Hz)         : 0
RSRP (dBm)                            : -21474836.00
RSRQ  (dB)
             : -23.87
Channel estimation state (Cell-spec.) : LOW CINR
Channel estimation state (UE-spec.)   : LOW CINR

Channel estimation state (MBSFN) : LOW CINR
Channel estimation CINR : 0.00
Channel length
: SHORT
AGC
AGC RX gain (dB) : 60.29
RX PSD BO (dBFs) : -26.82
RX PSD (dBm)
: -106.53
Noise level RS (dBm) : -112.50
Digital gain (dB) : 11.77
CINR RS (dB) : -5.39
NARROWBANDS
Last DL NB : Central
Last UL NB
: N/A
AFC
Frequency offset RF (Hz) : -239
Frequency offset BB (Hz) : 0
PBCH
MIB received quantity : 89
MIB timeout quantity : 0

OK

[timh]

@ioag Yes

>>> import os
>>> os.uname()
(sysname='GPy', nodename='GPy', release='1.17.3.b1', version='v1.8.6-849-83e2f7f on 2018-03-19', machine='GPy with ESP32')
>>> from network import LTE
>>> lte = LTE()
>>> lte.send_at_cmd('AT+CGDCONT=1,"IP","telstra.m2m"')
'\r\nOK\r\n'
>>> lte.send_at_cmd("AT!=\"RRC::addscanfreq band=28 dl-earfcn=9410\"")
'\r\n\r\nOK\r\n'
>>> lte.send_at_cmd('AT+CFUN=1')
'\r\nOK\r\n'
>>> lte.attach()
>>> lte.isattached()
False

Note the lte_attach source shows any call to lte_attach performs a clearscanconfig followed by a series of addscanfreq re-adding "AT!=\"RRC::addscanfreq band=28 dl-earfcn=9435\"" which seems to be the problem. Other people have been able to occasionaly connect with dl-earfcn=9435 but I have never.

What I have observed is a series of status not seen before in showphys after an addscanfreq with earfcn=9410

Where did you find 9410 ?

Thanks

T

[IOAg]

@timh are you following same calls sequence or only changed earfcn?

I no longer have problem connecting with LTE; now chasing reliability in long run...

[timh]

@ioag Yes, however I still can't connect ;-)
So it was more an observation about useability of send_at_cmd. (Sorry a bit off topic).

[IOAg]

@timh said in Fipy LTE connection working with Telstra:

'AT+COPS=?'

I no longer use 'AT+COPS=?', as far as I can see it can cause established connection to drop out, and that's not the only one!

[timh]

@timh Also why we are at it,

attach() has some specific timeouts, I think you should be able to specifiy longer ones. (Especially with the send_at_command). Sending 'AT+COPS=?' almost never completes before the timeout if it's found a cell. (mind you that was with earfcn=9435

[timh]

@ioag I also got further using earfcn=9410

showphy output new states I have seen before., such as CELL ACQUIRED.

It would seem an issue to be encoding specific earfcn's in the attach() method. Surely they won't be the same world wide for band 28, or for that matter the earfcn could be different for different bands.

Also the docs should probably be updated to include how you may need to send 'AT+CGDCONT= command for various providers.

I would not have gotten anywhere withouth reading through the forums.

Thanks

Tim