Packet Switched Data connection(+UPSDA) on Sara u201 gets disconnected when using Hologram SIM

This previously work (about a month or two ago), however now I am having issues.
I am using a hologram SIM & Nova(Sara-U201) and I am trying to create a Packet Switched Data(PSD) connection so that I can download directly to the storage on the Sara.

I am using PPP to connect on a Raspberry Pi. This works fine and the Pi can access the internet without issues.

This how it was previously working;
Create a PPP connection on the Pi
Once PPP is up and running on the Pi, I would log into the console(/dev/ttyACM1) of the Sara to create a PSD connection. I would use this;
AT+UPSD=0,1,“hologram”
OK
AT+UPSDA=0,3
OK

The first line above sets the APN and the second activates a PSD connection. Once this was working, I could go ahead and download directly to the file system on the Sara.

However, now…when i try this on the same Pi used above,which hasn’t had any changes (i was actually away for a few weeks). I get disconnected when I issuing the UPSDA command.

AT+UPSD=0,1,“hologram”
OK
AT+UPSDA=0,3
OK

+UUPSDD: 0

UUPSDD: 0 means that the carrier has closed the connection.

And this is what the PPP logs show on the Pi;

rcvd [LCP TermReq id=0x3]
LCP terminated by peer

I get the same result when using Optus, Telstra or Vodafone (I’m in Australia)
I forced the Sara to connected to these carriers using +COPS.

=======

I tried this with the SIM from my phone, which is an Optus SIM and it works. I used the same Pi, I did however have to change the APN in the chat script and the UPSD command.

This makes me believe that this issue is with he hologram SIM. Does anyone know what would cause the carrier to disconnect my Hologram SIM when trying to create a PSD connection?

Below are my scripts;

Chat;

ABORT 'BUSY'
ABORT 'NO CARRIER'
ABORT 'VOICE'
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'NO ANSWER'
ABORT 'DELAYED'
TIMEOUT 12
REPORT CONNECT
"" AT
OK ATH
OK ATZ
OK ATQ0
OK AT+CGDCONT=1,"IP","hologram"
#OK AT+CGDCONT=1,"IP","yesinternet"
OK ATDT*99***1#
CONNECT ''

Provider options;

connect "/usr/sbin/chat -v -f /etc/ppp/chatscripts/mobile-modem.chat -T HOLOGRAM"
# Serial device to which the modem is connected.
/dev/ttyACM0
# Speed of the serial line.
115200
ipdefault
usepeerdns
defaultroute
persist
noauth
debug
modem
dump
nodetach
kdebug 1

Is the SIM still showing as live in the dashboard?

this happens will all three Hologram SIMs I have tested.
The current SIM is live in the dashboard and I can send messages to the console

I just did another test with he above SIM, created a PPP session using Hologram SDK.

Logged into one of the other consoles on the Sara and issued AT+UPSDA=0,3. And I got the same results. Carrier closed connection, log file shows

rcvd [LCP TermReq id=0x3]
LCP terminated by peer

Below is the debug from the connect command

pi@raspberrypi:~ $ sudo hologram network connect -vv
DEBUG: checking for vid_pid: ('12d1', '1506')
DEBUG: checking for vid_pid: ('12d1', '1001')
DEBUG: checking for vid_pid: ('05c6', '90b2')
DEBUG: checking for vid_pid: ('1546', '1102')
INFO: Detected modem Nova_U201
DEBUG: checking port ttyACM0
DEBUG: [AT]
DEBUG: {}
DEBUG: {}
DEBUG: {}
DEBUG: {}
DEBUG: {+UMWI: 0,1}
DEBUG: URC! +UMWI: 0,1
DEBUG: handleURC state: 0
DEBUG: URC was not handled. '+UMWI: 0,1'
DEBUG: {}
DEBUG: {}
DEBUG: {AT}
DEBUG: {OK}
INFO: found working port at ttyACM0
INFO: chatscript file: /usr/local/lib/python2.7/dist-packages/Hologram/Network/Modem/chatscripts/default-script
DEBUG: [ATE0]
DEBUG: {ATE0}
DEBUG: {OK}
DEBUG: [AT+CMEE=2]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CPIN?]
DEBUG: {}
DEBUG: {+CPIN: READY}
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CTZU=1]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CTZR=1]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CPMS="ME","ME","ME"]
DEBUG: {}
DEBUG: {+CPMS: 1,300,1,300,1,300}
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CMGF=0]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CNMI=2,1]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CREG=2]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CGREG=2]
DEBUG: {}
DEBUG: {OK}
INFO: Instantiated a Nova_U201 interface with device name of /dev/ttyACM0
DEBUG: [AT+UUSBCONF?]
DEBUG: {}
DEBUG: {+UUSBCONF: 0,"",,"0x1102"}
DEBUG: {}
DEBUG: {OK}
DEBUG: USB modem mode: 0
INFO: Connecting to cell network with timeout of 200 seconds
INFO: Checking for existing PPP sessions
INFO: Starting pppd
DEBUG: checking port ttyACM0
DEBUG: unable to write to port
DEBUG: checking port ttyACM1
DEBUG: [AT]
DEBUG: {}
DEBUG: {}
DEBUG: {+UMWI: 0,1}
DEBUG: URC! +UMWI: 0,1
DEBUG: handleURC state: 0
DEBUG: URC was not handled. '+UMWI: 0,1'
DEBUG: {}
DEBUG: {}
DEBUG: {}
DEBUG: {+UMAT}
DEBUG: URC! +UMAT
DEBUG: handleURC state: 0
DEBUG: URC was not handled. '+UMAT'
DEBUG: {OK}
INFO: found working port at ttyACM1
DEBUG: [ATE0]
DEBUG: {ATE0}
DEBUG: {OK}
DEBUG: [AT+CMEE=2]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CPIN?]
DEBUG: {}
DEBUG: {+CPIN: READY}
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CTZU=1]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CTZR=1]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CPMS="ME","ME","ME"]
DEBUG: {}
DEBUG: {+CPMS: 1,300,1,300,1,300}
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CMGF=0]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CNMI=2,1]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CREG=2]
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CGREG=2]
DEBUG: {}
DEBUG: {OK}
INFO: Successfully connected to cell network
INFO: Adding routes to Hologram cloud
INFO: Adding system-wide default route to cellular interface
PPP session started
pi@raspberrypi:~ $

I’m not sure if you can have a PPP session up and start a PSD session at the same time. What are you trying to do there?

yes, that is what I was doing. Using the Pi to create a PPP session and then creating a PSD session.
I just found this in uBlox documentation;

Be aware that network operators could deny the activation of different PDP context with the same APN, see the section

This is what I think is happening here. This did work previously with the Hologram SIMs. Has there any changes to the APN config? is there another hologram APN I could use.

This doesnt happen if I use an Optus SIM. I can connect with PPP and PSD.

I just tested an internal PSD command without setting up PPP first on the Pi and it works.

I don’t think we’ve ever supported that and haven’t changed any settings lately so not sure what you saw. In my own experience it’s always prevented two sessions from opening.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.