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
>
