November 2023 - baseband-devel

SMS not received in mobile - Virtual layer1 (osmo-nitb + osmo-bts + osmocom-bb/mobile)
by Sebastian Stumpf 05 Jun '26

05 Jun '26

Hi, Some of my sent SMS are not received by my mobile and I try to figure out if this is a problem with my virtual layer 1, configuration or something in the layers 2+. I use: osmo-nitb: 1 subscriber in hlr (id 1, ext 017519191919) osmo-bts: virt-phy, arfcn 666, TS0=CCCH+SDCCH4, TS1=SDCCH8 MS layer23 app mobile: is the subscriber from osmo-nitb MS layer1 virt-phy: virtual gsmtap layer between bts and mobile I want: Send a sms to subscriber 017519191919. osmo-nitb VTY: OpenBSC# subscriber id 1 sms sender id 1 send Test I have 2 outcomes, first one is the failure. See https://www.dropbox.com/s/eunpfioq518t09a/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. Do not wonder about the duplicated gsmtap messages from mobile, the ones to ip 225.0.0.1 are over virt-phy layer, the ones to localhost from the gsmtap logging option from mobile. Filter them out via "gsmtap && (ip.dst != 127.0.0.1)". 602-613: RR channel establishment with RA and IA as reaction to paging in 590 627,631: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 656,684,699: I-Data frames on SAPI3 containing the sms 660,688,703: ReceiveReady's from MS (That ACK all I-frames before N(R)-1 as far as I understood) For me, that looks good and I really do not understand why the MS will not answer with the CP-ACK/RP-ACK after receiving the SMS Data in 699. The LAPDM link will stay up for some more time and be used by the network for retransmission of the sms (1149), but MS will never react to it on the SMS layer (CP-ACK, RP-ACK). Here is the console log for the mobile (https://www.dropbox.com/s/6gug5cd4up5qv7y/mobile--ms-virt--bts-virt--bsc-ni…) The paging is answered in line 378: Fri Mar 10 10:42:06 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE Second outcome is a successfully sent sms from network to ms. See https://www.dropbox.com/s/ghdn7pc0j4vifbe/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. What is different here? There is no paging, but the sms is sent within the dedicated channel used for the location update initiated by the phone started up. Why there is another outcome, I don't know. 169-181: RR channel establishment with RA and IA as part of mibiles startup routine to make location update 188,416: Location udpdate procedure on SAPI0 230,234: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 396,444: I-Data frames on SAPI3 containing the sms 400,449: RR's from MS 450: CP-ACK for BTS 482,499: RP-ACK I-Frames for Network (osmo-nitb) Again, the console log of the mobile (https://www.dropbox.com/s/cujsn40d43g6wxk/mobile--ms-virt--bts-virt--bsc-ni…) The SABM on SAPI3 on downlink is received in line 206: Fri Mar 10 11:06:13 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE The signaling looks quite similar in both cases, but one time the mobiles sms handler responds to CP-DATA msg containing the SMS, the other time not. Can someone find an error in the signaling I did not see? Is there a known Bug? To be honest, I last merged my branch with master some time ago (~ Jan 18 2017) and thus did not update osmo-nitb and the libraries since then to avoid compatibility problems. Have there been recent changes that could cause that behavior? Thank you and Kind Regards, Sebastian

4 3

Engagetted !
by Sébastien Lorquet 14 Oct '25

14 Oct '25

http://www.engadget.com/2010/12/29/researchers-eavesdrop-on-encrypted-gsm-c… Congrats!

7 7

Solid Online Nursing Class Course
by vatemiy934＠meogl.com 10 Oct '25

10 Oct '25

https://acemycourse.net/com-fpx-1250-assessment-4-written-communication-com…

3 2

OsmoDevCall on Nov 15, 2023: Calypso history: From TI to FreeCalypso to USA PSTN
by Harald Welte 15 Nov '23

15 Nov '23

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: (today) November 15, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @falconia will be presenting on Calypso chipset history and development boards, from TI to FreeCalypso This meeting will have the following schedule: 20:00 meet + greet 20:10 topic as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Powering GSM MS from USB
by Mychaela Falconia 08 Nov '23

08 Nov '23

Hello fellow GSM MS tinkerers, Question: is there anyone on either ML who has any experience with powering a GSM MS from USB, or had at least thought about this problem? We all know the fundamental problem: during Tx bursts the PA in a GSM MS can suck as much as 2 A, but the current budget of a classic USB port is only 500 mA. However, that 2 A current draw has a duty cycle of 1/8 of a TDMA frame, and the total energy transfer with 1/8 duty cycle bursts of 2 A (at a given voltage) is equivalent to 250 mA continuous draw - and the latter number is well within the range of what a PC/laptop USB host port can supply. Context: I am looking into the possibility of building a new GSM MS board that would be just a little better than the one in OS#4030. The goal is to produce a low-cost modem-only (no UI as in LCD etc, host computer required for control) GSM MS using a pre-existing packaged Calypso module (FC Tango, similar to GTM900, but a little better) with a built-in USB adapter for the two Calypso UARTs - very similar goals to OS#4030, but design it in such a way that will be suitable for both firmware tastes, rather than OBB-only. My initial thought was to require a separate non-USB supply for the GSM side of this board, leaving USB power only for the FT2232H block. This approach is not a problem from the perspective of cost - I already have a large stock of 3.6V 2.2A power supply bricks that were specifically made for powering FreeCalypso dev boards, hence the least-effort and least-cost approach would be to simply include one of these AC-to-3.6V adapters with each board and be done with it. But use convenience does suffer with this approach: in addition to connecting the GSM MS board to her PC/laptop with a USB cable, the user would also have to connect the separate 3.6V power supply (and have a spare AC power outlet for it) in order to bring the GSM MS to life. The whole arrangement would be much more convenient for the user if she only needs to connect USB from her PC/laptop to the board and that's it - have this USB supply power to the GSM MS and carry the two ttyUSB channels for Calypso UARTs. But how to design it in hw so that it will work correctly is the question. My first thought in this direction is to implement a step-down regulator (ideally a switcher, but linear may be OK too) from 5V down to 3.5V as the first order of business, and then somehow deal with 2 A current spikes on the 3.5V rail. Why 3.5V? Every power consumer inside a Calypso+Iota+Rita module either uses actual LDO linear regulators (Iota and Rita) or behaves (power-wise) in the manner of a linear regulator (RF PA), thus one could actually feed 5V directly to the VBAT input of such module - but this design would shorten the longevity of components through higher heat dissipation inside Iota, Rita and PA chips. If we stick a linear regulator down to 3.5V somewhere between USB 5V power input and VBAT rail to the Calypso module, the overall current and power consumption profile stays exactly the same, but a big chunk of heat dissipation moves from delicate RF components to that external 3.5V regulator, which can have a proper heat sink. (The specific choice of 3.5V number is rather arbitrary - the idea is to make it as low as possible while staying within safe margins of "good battery" voltage.) And if we make that 5V to 3.5V regulator a switcher instead of linear, we'll have a little less current drawn from the USB host for the same current into VBAT GSM domain. But what would be the right way to support 2 A current spikes during GSM Tx bursts? I reason that a large capacitor will need to be placed on the output of the 3.5V step-down regulator, one that will store enough energy to feed the PA during that hungry burst - any thoughts as to which type and size of capacitor would be most appropriate here? And the most important question, for people with more EE experience than me, and/or people who have already considered this problem: is this capacitor solution expected to work, or is the problem intractable in the sense that a USB-powered GSM MS, with the USB host limiting to 500 mA, will never be able to produce proper GSM Tx bursts at max power without tripping overcurrent shutdown on the USB host port? I would greatly appreciate some feedback on these ideas. M~ P.S. Suggestions to move to USB Type C and USB-PD won't be helpful - the dev board MUST be usable with traditional PC/laptop USB host ports that max out at 500 mA and never switch from 5V to any other voltage.

2 1