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