BG95-m2 UDP packets not sending

Looking for some guidance about why UDP packet never seams to send.
The at command “AT+QISEND=0,0” seams to report the same values indefinitely.

The odd bit is i can send a packet every time on qnavagator (after a modem reboot)
Happens same way on both at&t and t-mobile network. I don’t see what i am doing different

AT
AT
AT+CPIN?
AT+GSN
AT+CIMI
AT+QCCID
AT+QGMR
AT+CREG=0
AT+CPIN?
AT+QGPS=1
AT+QGPSLOC?
…Once a second until gps locks…
AT+QGPSLOC?

AT
AT+CPIN?
AT+CBC
AT+COPS=3,2
AT+CSQ
AT+CREG=1
AT+CREG?
AT+COPS?
AT+CEREG? (i wait for a 1 or a 5 hear)
AT+QICSGP=1,1,“data00.telnyx”,"","",0
AT+QIACT?
AT+QIACT=1
AT+QIACT?
AT+QLTS=1
AT+QIOPEN=1,0,“UDP”,“18.218.81.144”,5843,0,1
AT+QISEND=0 (waits for >)
TESTmessage<this is SUB character
AT+QISEND=0,0 (this loops indefinitely right now in my code once a second) i get “+QISEND: 11,0,11”

So it turns out when ever Gnss gets activated the module failed to register(sometimes) or send packets on the network.

I have tried adding
AT+QGPSEND //Turns off gnss
AT+QGPSCFG=“priority”,1,0 //sets the wireless cells as priority

After the gps commands but still don’t get a packet to send

I believe I am experiencing a similiar thing- Using BG95M2LAR02A04_01.003.01.003 firmware.
I am using the sendex command.

Has anyone of you had any luck solving this problem?

This is still happening on latest firmware.

On BG95 M2 and M6; if you use a roaming SIM on Auto operator (Cops=0).

If you use a local sim OR set an operator code on a roaming sim, the behaviour goes away.

i don’t believe it has anything to do with GPS.

Has anyone had any luck figuring this out? It’s so inconsistent.

So I was able to solve this I just don’t remember what it was exactly the fix was. I seam to recall there being an error in the udp send documentation that I figured out by going though the docs on sending a sending a tcp packet instead, and referring to some docs from other modules.

Also try shortening your packet there is a max length that is not documented that i also hit with this. that also causes this.

IF it helps here’s what currently “works” for me. Looking at it now My solution may have been to test the udp socket by sending a “ping” and waiting for a #pn response. And if it fails I recreate the socket.

AT+CFUN=1

AT+QGPSCFG=“priority”,1,0

AT+QTEMP

AT+CPIN?

AT+QCFG=“band”,0,1008,1000,1

AT+QCFG=“iotopmode”,2,1

AT+QCFG=“nwscanseq”,020301,1

AT+CBC

AT+CREG=1

AT+COPS=0

AT+COPS?

AT+CREG?

AT+CSQ

AT+CSQ

AT+CSQ

AT+CSQ

AT+CSQ

AT+QIDEACT=1

AT+QIACT=1

AT+QIACT?

AT+QIACT=1

AT+QIACT?

AT+QLTS=1

AT+QHTTPURL=46,20

https://example.com/key/soemhthing.bin

AT+QHTTPGET=60

AT+QHTTPREAD=90

+QIOPEN=1,0,“UDP”,“example.com”,5843,0,0

AT+QISEND=0

#PN

AT+QIRD=0

AT+QICLOSE=0

AT+QIOPEN=1,0,“UDP”,“example.com”,5843,0,0

AT+QISEND=0

#JSTB6OPt+zwOIGPI8JDX5HI9HCyVnSCwds70iQpNuK59TBZd3DbiIb8gm66D/EwdLoIr2IdzZK5TIvlzOuN
GWlZ5MI8cictpDcf1ABUqqqa7xo#JSTdSzESb1J7ECUdRVohG1dB2MI7dpJZS26FTJ8Np6RrWTaJ64lT
hSHO+XEff9nFu/J4Rzbev7dvfIR12U1WmSyFrDY9WP/Xsp/eo8jPyO2mzQKMpQX++iTE7qFSVb7sEHD#
JSTdSzESb1J7ECUdRVohG1dB2MI7dpJZS26FTJ8Np6RrWTaJ64lThSHO+XEff9nFu/JDbmPNRv0yjwC8
DlnxlwjjlHD+yMZtHcX8N9S6jmgO3rsX7BlfmrEGncrJHoiFr0E#END

AT+QISEND=0,0

AT+QIRD=0