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)
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.
