Hi Christoph! glad to hear that you are experimenting with the sysmoBTS 1002. First, I'd concur that it could be a clock issue, you should calibrate it anyway.[1] In my experience, you can calibrate against an 850 or 1900 network, and this calibration is valid for all bands. (99.9% sure there is no issue with that, but somebody else with better knowledge of the OCXO might correct me) Although another thing that /might/ be happening is that your phone is seeing a stronger (or maybe just another) signal from a commercial network, and is as such trying to attach to (roam on) that network. That network looks at the IMSI provided (your 99970xxx...) and says, you are not allowed to attach, go away and be quiet and never try to attach to a network again (until airplane mode is toggled) I can't remember off the top of my head what the LUJ cause code is that does this, but it is an issue. You can add the PLMNs of the local networks to the SIM card's forbidden list and this should stop this procedure and you should stay on your network. Also, if it is a multi band phone, try to restrict it to 2G only, and of course, place it in manual network selection. [1] Calibration instructions are in the 1002 Manual, Chapter 13.3 If you do not have this manual, please reach out to sysmocom. On 26/08/2025 10:25, Christoph Quirin Lauter wrote:

Hello,

thank you for your answer.

I cannot use a neighbor cell (of a commercial network) I guess because I doing GSM900 here in the US, while all the commercial networks are at 850MHz. Or is this an option? If yes, would you please point me to the right config option?

I do not have the GPS clock option installed. What would it take to install the option?

Would you mind explaining how recalibration is done?

Thank you!

Christoph Lauter

Joachim Steiger wrote on 26.08.25 at 10:14:

...

Hi,

you may want to check your clock calibration. either against a neighbor cell or if installed as option the gps clock source.

clock calibration is a value stored on the device and can be overridden in config in case it drifted too far over time. this is not uncommon since the crystals age with use and time. a recalibration every few years should be enough in most cases.

the behavior of the phone sounds a lot like what happens if the phone gets confusing clock-references from the networks it can receive and at some point decides which one is 'right' and ignores whats not fitting that raster.

regards

Hello Keith, that sounds exactly like what I am observing. I will have to buy a USB SIM reader and understand how pysim works. Thanks! Christoph Keith wrote on 26.08.25 at 11:39:

On 26/08/2025 11:29, Keith wrote:

...

I can't remember off the top of my head what the LUJ cause code is that does this, but it is an issue.

LU Reject Cause #2 "IMSI Unknown in HLR"

See for example this description of the process (although this describes the problem in reverse): https://osmocom.org/projects/osmo-hlr/repository/osmo-hlr/ revisions/6b5616fd36f1d88d174a3610a1936b853e9d0981

There's also a story of this happening at a CCC event one year where all the event's Osmocom SIMs got shut down by a local MNO network. Not sure if that is publicly documented somewhere. (it may be at least mentioned in some talk that was recorded.)

BTW, You can add PLMNs to the FPLMN list with pysim, Again, not sure if there is a simple howto out there on that. Anybody?

Also try using the tool called scat or similar tools to get a pcap of the signaling between your phone and the network, it will be immensely helpful not only now but later on as well. It would immediately tell you if this theory is valid or not, because you’d see in the pcap the reject coming from the network. Cheers, Domi

26.08.2025 dátummal, 19:57 időpontban Keith <keith@rhizomatica.org> írta:



...

On 26/08/2025 11:50, Christoph Quirin Lauter wrote: Hello Keith,

that sounds exactly like what I am observing.

I will have to buy a USB SIM reader and understand how pysim works.

Before you do that, check that you do not have a SIM reader around someplace, for example, my DELL Latitude 5590 has one built right in, although it is a full (credit card sized) slot and I am a little reluctant to put in cards with the SIM reinserted into a spacer and card, in case it slips and gets stuck inside, requiring dissasembly to get it out.

Hi Christoph, Which settings are shown depends on the carrier settings inside Android. There are multiple ways to change them. Most of them need a rooted phone. However an app with carrier privileges can modify these settings on an not rooted android. To get carrier privileges the app needs to be signed by a certificate that is also in the ara-m applet on the SIM card. One such app that can do this is OMNT [1]. Another one is CoIMS which is however not customizable. I think instructions are in the wiki of OMNT github. Cheers Björn Sent from mobile [1] https://github.com/omnt/OpenMobileNetworkToolkit ________________________________ From: Christoph Lauter <christoph.lauter@christoph-lauter.org> Sent: Friday, August 29, 2025 11:37:43 PM To: openbsc@lists.osmocom.org <openbsc@lists.osmocom.org>; Tomcsanyi, Domonkos <domi@tomcsanyi.net>; Keith <keith@rhizomatica.org> Subject: Re: Mobile disassociates from sysmobts 1002 after call Hello, I made some progress debugging the issue. It is an issue with my Google Pixel 9 and how it interacts with a sysmocom SIM card and MCC/MNC 999/70. I have deactivated 5G and IMS using the scripts provided with pysim. Even with 5G and IMS deactivated and 2G activated as the only technology for this SIM card (using *#*#INFO#*#*), the phone tries to access Volte and/or Voice over Wi-Fi. In the *#*#INFO#*#* menu, I see a switch from 2G to LTE for a split second. With MCC/MNC 999/70 on the SIM Card does not give me any option concerning Volte or Voice over Wi-Fi. When I switch the MNC/MNC on the SIM card to 001/01, I see an option on the phone to disable Volte and Voice over Wi-Fi. When I do disable Volte and Voice over Wi-Fi, the 2G disassociation issue goes away. When I switch to another MCC/MNC such as 310/014, I do not have access to the Volte and Voice over Wi-Fi option and the issue persists. I can stay on 001/01 for the time being to work around the issue. If out of curiosity, you want me to continue to do some debugging, I can continue to do some experiments. Thank you all for your help! Christoph Am 27. August 2025 07:42:09 UTC schrieb "Tomcsanyi, Domonkos" <domi@tomcsanyi.net>: Also try using the tool called scat or similar tools to get a pcap of the signaling between your phone and the network, it will be immensely helpful not only now but later on as well. It would immediately tell you if this theory is valid or not, because you’d see in the pcap the reject coming from the network. Cheers, Domi 26.08.2025 dátummal, 19:57 időpontban Keith <keith@rhizomatica.org> írta:  On 26/08/2025 11:50, Christoph Quirin Lauter wrote: Hello Keith, that sounds exactly like what I am observing. I will have to buy a USB SIM reader and understand how pysim works. Before you do that, check that you do not have a SIM reader around someplace, for example, my DELL Latitude 5590 has one built right in, although it is a full (credit card sized) slot and I am a little reluctant to put in cards with the SIM reinserted into a spacer and card, in case it slips and gets stuck inside, requiring dissasembly to get it out.

On 10/09/2025 08:45, Neels Hofmeyr wrote:

...

I've seen similar during own tests: phones connect to circuit-switched, but my SGSN being broken caused a packet-switched failure, and the phone would rather try another operator first. One way was to switch off mobile data on the phone.

Similarly, I have an iPhone 5c that simply will NOT stay on 4G/LTE and then goes into locked down mode until toggling aeroplane mode. Then it will sometimes camp on 2G, but if it goes to 4G, shortly after going idle, (for example, if I ping it it'll stay) it will lock down again - I assume it is going off looking for VoLTE or something else on another carrier and getting told to shut down, but who knows...

...

When I switch the MNC/MNC on the SIM card to 001/01, I see an option on the phone to disable Volte and Voice over Wi-Fi. When I do disable Volte and Voice over Wi-Fi, the 2G disassociation issue goes away.

Availability of those options is due to the "carrier config", which is part of Android OS, IIUC, supplied to Goo by the industry, and subsequently part of AOSP. But seeing as how this is a pixel, you can use an "app" called Pixel IMS, along with shizuku, (so you don't need actual "root" or other mods) to set the carrier config to whatever you like; enable/disable IMS reg with VoLTE/VoWifi. This will reset on OS update BTW - I use GrapheneOS, of course, (hard to think of a reason not to use Graphene if you are lucky enough to have a pixel!) so OS updates are rather regular. :-) You can even decide whether "4g" should be called "4g" or "LTE". wow.. One /could/ use that app with any SIM card in the phone and modify the config for your carrier. (In Mexico, my Google Pixel actually works fine with VoLTE on Altan Networks, after changing the carrier config. (ok, yeah, as far as I can see, and I cannot see network side.) Current Pixel Models are now being sold in shops in late 2025, so maybe there's official support for VoLTE on 334140 now. I understand by law you can't sell any handset in Mexico that is not compatible with that network. Anecdote: Altan is somewhat unusual in that it does not run any CS network. (I don't know where else this may be the case?) and originally they got around this by having a "Voice" app that runs on non VoLTE phones. I heard bad things about the performance of this app, but never used it. I guess it is essentially some kind of SIP VoIP thing with IMS compatibility; a "user space" app that suffers from all the imaginable battery drain and availability issues. Since political changes and the state rescuing Altan from bankruptcy, other carriers are now obligated to allow "roaming" on their networks, but if one were to lock their phone onto another carrier's 2G network for CS service, the SIM will eventually be barred. It won't CSFB from Altan LTE to another carrier 2G of course, but incoming CS will work if already camped on 2G. At some point I guess, there won't be many non VoLTE phones around.

Hello Keith, that you for your help. I will try to figure out the calibration against a 850 or 1900 network. If you have a sequence of commands or a how-to to give me, that would be great. I do not have the manual. My phone is a dual-sim phone. The one SIM is a sysmocom SIM that attaches naturally to 999/70. The other one is a commercial SIM. The phone does not have a 2G only mode. There are two other 2G networks visible to phones at my place: T-Mobile GSM US (which will go away in a couple of months) and Telcel GSM from Mexico. There are 3G, 4G and 5G networks visible as well. If possible, I would prefer to install a GPS option. I am using GPS for E1 TDM anyway so I would really prefer this. I have a GPS controlled VCO (Leo Bodnar) laying around, if that helps. Thanks! Christoph Keith wrote on 26.08.25 at 11:29:

Hi Christoph! glad to hear that you are experimenting with the sysmoBTS 1002.

First, I'd concur that it could be a clock issue, you should calibrate it anyway.[1] In my experience, you can calibrate against an 850 or 1900 network, and this calibration is valid for all bands. (99.9% sure there is no issue with that, but somebody else with better knowledge of the OCXO might correct me)

Although another thing that /might/ be happening is that your phone is seeing a stronger (or maybe just another) signal from a commercial network, and is as such trying to attach to (roam on) that network. That network looks at the IMSI provided (your 99970xxx...) and says, you are not allowed to attach, go away and be quiet and never try to attach to a network again (until airplane mode is toggled)

I can't remember off the top of my head what the LUJ cause code is that does this, but it is an issue.

You can add the PLMNs of the local networks to the SIM card's forbidden list and this should stop this procedure and you should stay on your network. Also, if it is a multi band phone, try to restrict it to 2G only, and of course, place it in manual network selection.

[1] Calibration instructions are in the 1002 Manual, Chapter 13.3 If you do not have this manual, please reach out to sysmocom.

On 26/08/2025 10:25, Christoph Quirin Lauter wrote:

...

Hello,

thank you for your answer.

I cannot use a neighbor cell (of a commercial network) I guess because I doing GSM900 here in the US, while all the commercial networks are at 850MHz. Or is this an option? If yes, would you please point me to the right config option?

I do not have the GPS clock option installed. What would it take to install the option?

Would you mind explaining how recalibration is done?

Thank you!

Christoph Lauter

Joachim Steiger wrote on 26.08.25 at 10:14:

...

Hi,

you may want to check your clock calibration. either against a neighbor cell or if installed as option the gps clock source.

clock calibration is a value stored on the device and can be overridden in config in case it drifted too far over time. this is not uncommon since the crystals age with use and time. a recalibration every few years should be enough in most cases.

the behavior of the phone sounds a lot like what happens if the phone gets confusing clock-references from the networks it can receive and at some point decides which one is 'right' and ignores whats not fitting that raster.

regards

Hi there, In general, your problem as you describe it is not a known issue. sometimes odd problems show up from a bad clock. if your bts has not been calibrated in a long time, calibrate it; like one thing less to worry about. A sysmobts clock is generally good, no need to worry about GPS. Though once i had a broken ocxo, but then the bts did nothing much at all anymore. Calibration is a special tool you run once to determine the best value for your oscillator (oven controlled). So you tale your cell offline and then you can calibrate against any band your sysmobts supports. update the config with the new value and back to operation. it is described in the sysmobts manual. The uplink measurements should not be related to your phone's idle status. I would look at first the bssmap traffic and then the abis_rsl around the end of that call, with wireshark... you could record that and share it, e.g. attached to an osmocom.org issue. Also interesting are the bsc and then bts logs to see if anything times out or errors around such event. it's hard to say from the distance. pcap and logs might let us help you better. ~N