baseband-devel

baseband-devel@lists.osmocom.org

2 participants
1984 discussions

OsmoDevCall on Nov 15, 2023: Calypso history: From TI to FreeCalypso to USA PSTN

by Harald Welte

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 year, 11 months

Powering GSM MS from USB

by Mychaela Falconia

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.

1 year, 11 months

Re: baseband-devel Digest, Vol 82, Issue 1

by Alen Jungen

Hi! I am finishing an app in c++ for A5/3 rainbow tables on cuda. Is somebody interested in sharing nvidia GPU for generating or costs for cloud? Regards! пон, 23. окт 2023. у 14:04 <baseband-devel-request(a)lists.osmocom.org> је написао/ла: > Send baseband-devel mailing list submissions to > baseband-devel(a)lists.osmocom.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > baseband-devel-request(a)lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of baseband-devel digest..."Today's Topics: > > 1. Powering GSM MS from USB (Mychaela Falconia) > > > > ---------- Forwarded message ---------- > From: Mychaela Falconia <falcon(a)freecalypso.org> > To: baseband-devel(a)lists.osmocom.org, community(a)freecalypso.org > Cc: > Bcc: > Date: Sun, 22 Oct 2023 15:40:49 -0800 > Subject: Powering GSM MS from USB > 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. > _______________________________________________ > baseband-devel mailing list -- baseband-devel(a)lists.osmocom.org > To unsubscribe send an email to baseband-devel-leave(a)lists.osmocom.org >

1 year, 11 months

Open Source Software Stack for 3G

by 200207094＠kocaeli.edu.tr

For my thesis research, I am looking for a 3G protocol stack that enables users can call each other and make data connections. If I can, I need to establish 7-8Mbps for downlink in lab environment. Is it even possible, I don’t know yet? Besides, I am sure you know if I can make a call connection between 2G and 3G users via Osmocom. This is my another possible research subject. Thank you very much in advance for your answers. Best Regards,

2 years

Open Source Software Stack for 3G

by 200207094＠kocaeli.edu.tr

Hello, I am a student at Kocaeli University. I am looking for open source software stack for 3G like OpenAirInterface for 5G or Osmocom for 2G for my work. (Osmocom has partial support for 3G) I request you to direct me to the right resource that may know. Thanks for your time and interest. Kind regards,

2 years, 1 month

GSM MS boards on clearance: FC Caramel2

by Mychaela Falconia

Hello GSM MS communities, I have a large inventory of FC Caramel2 boards that are in need of loving homes. I mean these boards: https://www.freecalypso.org/members/falcon/Caramel2/c2-fully-assembled.jpeg For those who are familiar with FCDEV3B, Caramel2 boards are very similar: all FreeCalypso tools work exactly the same (even with the same -h fcfam target selector option), firmware functionality works exactly the same (fcdev3b and tangomdm fw builds are made from the same source, just minor electrical diffs between the two boards which the fw needs to know about), same AT command interface, same rvinterf, same everything. Vadim (fixeria) recently told me that he found FC to have better CSD support than any other commonly available commercial GSM modem - this aspect will work exactly the same on C2 as on FCDEV3B. And for those who have an irresistible need to be naughty boys and run naughty software, OBB can run on Tango/Caramel2 hardware too: https://gerrit.osmocom.org/c/osmocom-bb/+/34297 The main diff between FCDEV3B and Caramel2 is that C2 came out a little worse in terms of quality: * FCDEV3B analog audio circuits (loudspeaker and mic) came out very clean despite no special effort at design time: I never hear any "buzz" from rectified GSM RF in FCDEV3B analog audio. OTOH, with C2 the audio is dirty by default, and to get it mostly-clean, I have to insert a long coax between the antenna connector on the board and the actual antenna, to move the radiating element away from the analog audio circuits. * LEDs: the single green LED on FCDEV3B indicates 100% reliably if the chipset is switched-on or switched-off, but Caramel2 board LEDs sometimes exhibit erratic behaviour as a result of wayward current paths, as I explain in the Status Report and User's Guide document: https://www.freecalypso.org/pub/GSM/FreeCalypso/Tango/Caramel2-SR-UG-v1.2.p… Seeing that Caramel2 design is flawed, I won't be making any more of them: *if* I decide to produce another board in the future with similar functionality, it will need to be a new design, adding LVC buffers for proper PPD support (partial power-down) and reworking the audio circuits. In this light, the existing inventory of C2 boards needs to be put on clearance - they are just gathering dust right now, but they should be perfectly suitable for more casual users with less stringest quality requirements. I have enough stock to supply 12 complete kits consisting of: * Caramel2 main board; * FT2232D-based DUART28 adapter board; * Power adapter from universal AC (worldwide voltage and frequency range) to 3.6 VDC; * Possibly FC-HDS4 headset and quadband GSM antenna. Once again, this board is a *clearance* item - no more will be made, but the already-made ones are looking for loving homes. *IF* there is any community interest in these boards, I would be happy to ship a few to Sysmocom, to be further distributed via the webshop. It would also be helpful if those who are interested in these clearance boards (if any) could state what they would consider to be a fair price for a full kit as described above. M~ P.S. If anyone still does CalypsoBTS hacks, these boards would NOT be a good choice for it, as the Rx SAW filters are totally inaccessible to rework - all 4 SAW filters (for full quadband Rx) are integrated into a monolithic chip-like module from Epcos, which is then embedded into the TR-800 module which is not amenable at all to rework. However, if you merely wish to see what's inside that TR-800 module, without modifying it, we have published results of a complete PCB reverse eng job on it: https://www.freecalypso.org/pub/GSM/iWOW/TR800-reverse-eng-gerbers.tar.bz2 https://www.freecalypso.org/pub/GSM/FreeCalypso/Tango/FC-Tango-netlist.tar.…

2 years, 1 month

Osmocom discourse as alternative to mailing lists

by Harald Welte

Dear Osmocom community, while many people with a long history in FOSS development have no issues at all with mailing lists as primary form of engaging with their community, they have undoubtedly fallen out of fashion in favor of various chat/messaging systems or web based forums. In Osmocom, we've just launched an installation of the discourse forum software available at https://discourse.osmocom.org/ providing an alternative to our traditional mailing lists at https://lists.osmocom.org/ We're looking forward to see whether this web-based approach will facilitate more and/or other people to engage with the Osmocom developer/contributor community. Feel free to join and get the discussions started. If there's a need for more categories or sub-categories, just let one of the moderators know and we can help with that. The old mailing lists will continue to remain available for those who prefer them. -- - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 2 months

Re: New attack ?

by Mychaela Falconia

Bastien Baranoff wrote: > Hello all, the attack : you generate the rainbow tables for each possibles ki > with a given rand set, send this rand (which is not random ;) the phone > respond with sres you make the operation for 3 or 4 rand and meaningly > decrease the possibility of ki. Do you think it is realisable ? Someone please correct me if I'm wrong on this detail, but it is my understanding that no mainstream commercial operator today (outside of personal enthusiast tinkerers in Osmocom and similar communities) issues native 2G SIM cards any more - instead all of their current SIM cards are actually USIM/ISIM, and if GSM 11.11 SIM operation is supported at all, it is only provided as a backward compatibility mode. I reason that these "modern" SIMs must be using Milenage in their native 3G/4G mode, thus their secret key material is not classic Ki, but K/Ki (128 bits) plus OPc (another 128 bits), for a total of 256 bits of secret key material. What happens when these "modern" SIMs are accessed via GSM 11.11 SIM protocol, or when 2G authentication is requested in a USIM session? I find it doubtful that they switch to COMP128 (any version) in this mode, instead I reason that they use 2G mode of Milenage, which still uses both K/Ki and OPc - thus the secret key material used even for 2G Kc and SRES generation from RAND is still 256 bits rather than 128. Again, someone please correct me if my reasoning is wrong here. M~

2 years, 4 months

failure in Transceiver startup

by Sally Regenbogen

Hello, I am new to this Project and I am having a Problem with running the Transceiver. I hope you can help me out. When i start the Transceiver on 2 Phones with this commands ./osmocon -p /dev/ttyUSB1 -m c123xor -s /tmp/osmocom_l2 -c /root/osmocom/osmocom-bb/src/target/firmware/board/compal_e88/trx.highram.bin ./osmocon -p /dev/ttyUSB2 -m c123xor -s /tmp/osmocom_l2.2 -c /root/osmocom/osmocom-bb/src/target/firmware/board/compal_e88/trx.highram.bin and sudo ./transceiver -e 1 -2 -a 47 -r 99 it throws an error which i can not solve. Maybe i am blind or something, but it doesn't work. I tried to kill the process but i can't find anything. The CLI gave me this error: ~/osmocom/osmocom-bb/src/host/layer23/src/transceiver# sudo ./transceiver -e 1 -2 -a 47 -r 99 47 41 1 <000c> l1ctl.c:77 Tx Reset Req (1) <000c> l1ctl_link.c:171 Sending: '0d 00 00 00 01 00 00 00 ' <000c> l1ctl.c:77 Tx Reset Req (1) <000c> l1ctl_link.c:171 Sending: '0d 00 00 00 01 00 00 00 ' Aborted Even when i try to start it with only 1 Phone, it doesn't run. There is a Problem, but i can't figure out what it is... I hope you can help me out for running my Transceiver or give me some hints. Thank you very much Sally

2 years, 10 months

[Job Opening] Cyber Security Engineer @ ZTE CyberSecurity Lab in Dusseldorf

by WHID We Hack In Disguise

Hi guys, First of all, I want to reassure all the ML members that this is an isolated pseudo spam post and I asked in advance for permission from Harald to post it. Said that... I just wanted to let you know that ZTE is opening a CyberSecurity Lab in Germany and they are looking for Security Engineers passionate about Telco Security. *Position: * Cybersecurity Engineer *Location:* Düsseldorf, Germany *Responsibilities**:* 1. Testing the the security performance (at least but not limited to penetration testing) of ZTE products. Drafting documents and reporting testing results to stakeholders. 2. Participating in security research activities and projects in the Telecommunication field. Study and use cutting-edge security technology/tools for test and research. 3. Participating in product security risk analysis and security requirements collection. 4. Participating in lab operations. 5. Participate in the product security incident response, trace the attack, and give rectification plans. 6. Assisting in security certifications, support security vulnerability verification and rectification of products. 7. Assisting in communicating security-related matters on products across multiple departments *Link for applications:* https://www.linkedin.com/jobs/view/3361789707/ In case of questions, feel free to ping me here or reach me on LinkedIn [1] Cheers Luca [1] https://www.linkedin.com/in/lucabongiorni/

2 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel