PRL list & Roaming | Telit Cinterion IoT Developer Community
January 3, 2017 - 11:19pm, 6691 views
We are using the PVS8 cdma cell modem on one of our devices. We are experiencing some roaming issues where our devices sends data while connected to a roaming tower, but we don't recieve any data. After updating the PRL list we experience more losses in some areas.
There is a AT command, AT^SCFG, that allows the modem to select which frequencies to choose from in the PRL list. Under the <AutoAB> parameter we can select either:
“autoa“ Acquire the available system only from System A.
“autob“(D) Acquire the available system only from System B.
“any“ Acquire any available system according to PRL.
I can't find any info on what any of these options actually mean.
Can you please provide any more info for what selecting one of these systems means for the PVS8?
Hello,
Verizon has forced to split the frequency band BC0 into two parts: System A nad System B. The default setting on the module is System B. Please try to set AT^SCFG="CDMA/AutoAB",“any“.
Regards,
Bartłomiej
When we changed to "any" is when we noticed this issue. Do you have any more info as to what or where these systems are? i.e. Do diff parts of the country use system A or B?
Internet searches have left me empty handed.
Hello,
It is described in the 3GPP2 document C.S0057-E. You can find it here: http://www.3gpp2.org/Public_html/specs/index.cfm
Could you write more details about the problem and configuration? Does it mean that there was no problem with the default setting System B?
Maybe the source of the problem is the poor network quality or some interference while using the System A?
Regards,
Bartłomiej
We are experiencing PRL issues as well, but of a different sort. While camped on a home network EVDO tower, some devices update successfully to Sprint 44060 (which seems to be the latest), whereas other devices either refuse to update (issuing manual PRL command states PRL Update Started, but then does nothing), or they have a PRL that starts at 55***. Begs several questions:
1) Why would PRL update fail when camped on home network tower?
2) What is the latest Sprint PRL supported by Gemalto PVS8?
3) Why would some devices have vastly different PRL numbers?
4) Is there a way to get the latest PRL file via PC so it can be loaded manually?
Hello,
1. There may be many reasons: connectivity problems due to bad coverage or high interference level, Sprint update server problems etc.
2. There is no version limit – all new PRLs should be supported
3. There can be several reasons for that: UEs activated in different geographic area seem to get different PRL more suitable for this area. Sometimes Sprint knows that particular MEID range belongs to devices of specific kind (routers and data-only devices seem to get different PRL than voice) so they assign different PRL
4. Yes, once you get the PRL file it can be uploaded via at^sbnw=prl,file_size over modem port. See AT spec for details.
Regards,
Bartłomiej
Hi Bartlomiej.
Thank you for your fast response....
Three things:
1) Regarding item #3 above, I am referring to devices which are of the same model, using the same firmware, from precisely the same location and running the same Android code. Some devices update successfully to 44060, whereas other devices seem to be "stuck" on a PRL which starts at 55*** (and was part of the initial default factory delivered modem) and won't update. I would expect all devices to update in an identical fashion, but they don't. The 55 devices either end up not activating on the carrier network, or taking over 24 hours to do so, whereas the 44 devices activate instantaneously.
2) I see that there is an available OMALOG AT Command. Where is that LOG stored, and is it possible to retrieve it via another AT command? Does it show anything different than the URC's one gets during an OMADM process?
3) Finally, can you confirm the latest firmware and RIL version for the PVS8?
Thanks!
Hello,
The PRL version depends on the operator. But if all the devices have the same subscription then theoretically they should get the same PRL.
It still might be possible that there is a problem with a certain frequency - the CDMA network disposes the devices evenly across the whole band and if there is an interference on a certain frequency the device that was assigned to that frequency might have a problem with updating. There's not much you can do in such case, you could try to reset the device. You can also try to set at^prefmode=2 or at^prefmode=4 for the device that has problems and observe what happens then.
The log is not stored on the module or you have no access to it, you can copy from the terminal only.
The latest firmware is rev03300_arn0100006. The RIL version is 1.7.0.0.
Regards,
Bartłomiej
Still having issues. We have confirmed with the carrier (Sprint) that the latest PRL we should be receiving is 44060, which has a GUIname of MVNO PRL 44060 and is for both LTE and EVDO/1x. The units are we are having problems with appear to be pre-loaded from the factory with 55025, which is an older version of a PRL with GUIname of PRL AWM 55061 which is an Advanced World **** PRL that includes GSM references and is not appropriate for MVNO use. We have been working with the carrier, who can see the devices activating, but then can also see that they are not loading the PRL. Is this possibly a case whereby, because the modem has a higher number PRL, it is refusing to load a lower number? If so, is there a workaround?
Hello,
How about the devices that updated successfully - what was the initial PRL version, was it different than that on the devices that don't update? The module should not refuse to load the lower number. I think that the interference hypothesis might still be true. You could try to change the prefmode.
The best workaround would probably be to load the file with AT command.
Regards,
Bartłomiej
That's what I'm getting at. The initial PRL version for those modems that successfully update is always start with 44***, whereas those that don't have 55***. We are using AT+PRL=2 to try to force an update, the units accept the command with OK, but then the 55*** units just sit there with no further activity. Units with 44***, even those with the most current 44060 PRL, subsequently show PRL "Write" URC's and then a PRL success message. Prefmode had no effect.
I see there is a way to manually load a physical PRL file if you know it's length via AT^SBNW. What isn't clear from the documentation (PVS8_atc_03001c.pdf) is where it actually pulls the file from when the command is used. The documentation merely says "local memory." We are using an Android environment, so it isn't clear where the source file should reside when the AT^SBNW command is kicked off. Do you know where we should put the file in an Android use case?
Pages