Project

General

Profile

Actions

Feature #4030

open

design breakout board for GTM900-B

Added by laforge over 4 years ago. Updated about 2 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
05/29/2019
Due date:
% Done:

60%

Resolution:
Spec Reference:

Description

Let's build a small 2-layer PCB design as a break-out board for the calypso/iota/rita based GTM900-B module.

It should have the following key features:

  • on-board power supply for (5V?) input
    • over-voltage + polarity protection
  • 2.5mm jack for the UART (+ TVS array)
  • expose all pins of the module on 2.54mm header
  • LED for power and modem (is there one?)
  • power button and jumper in parallel (auto-start)
  • reset button
  • SIM card slot (2FF) with TVS array

One option would also be to directly put a CP2102 or even CP2105 on the board to attach to one (or both) UARTs. This way we'd also have the option to control reset and/or power via GPIOS or serial status lines, like tsaitgaist used to do..


Files

GTM900.pdf View GTM900.pdf 1000 KB laforge, 05/28/2019 10:10 PM
GTM900_product_overview.pdf View GTM900_product_overview.pdf 994 KB Product overview (Chinese), more detailed and more schematics than in English version steve-m, 09/02/2019 09:34 PM
gtm900-audio-io-symm.png View gtm900-audio-io-symm.png 7.28 KB gtm900-audio-io-symm mschramm, 05/04/2020 06:37 PM
gtm900-audio-io-asymm.png View gtm900-audio-io-asymm.png 7.59 KB gtm900-audio-io-asymm mschramm, 05/04/2020 06:37 PM
lenovo-combo-audio-jack.jpg View lenovo-combo-audio-jack.jpg 26.2 KB lenovo-combo-audio-jack mschramm, 05/04/2020 06:37 PM
PWON_chinese-ds.png View PWON_chinese-ds.png 14.6 KB PWON_chinese-ds mschramm, 05/04/2020 06:40 PM
PWON_english-ds.png View PWON_english-ds.png 15 KB PWON_english-ds mschramm, 05/04/2020 06:40 PM
gtm900-bo_modem-side.jpg View gtm900-bo_modem-side.jpg 98 KB mschramm, 06/04/2020 03:27 PM
gtm900-bo_smt-side.jpg View gtm900-bo_smt-side.jpg 142 KB mschramm, 06/04/2020 03:27 PM
gtm900-bo_smt-side_proto-placed.jpg View gtm900-bo_smt-side_proto-placed.jpg 158 KB mschramm, 06/10/2020 08:20 PM
GTM900-breakout-schematic.pdf View GTM900-breakout-schematic.pdf 49.2 KB GTM900-breakout-schematic mschramm, 06/10/2020 08:45 PM
GTM900-breakout-schema_v2.pdf View GTM900-breakout-schema_v2.pdf 52.3 KB mschramm, 02/21/2022 07:25 PM
gtm900-bo_v2-headsetparade.jpg View gtm900-bo_v2-headsetparade.jpg 158 KB mschramm, 11/20/2023 11:23 PM
gtm900-bo_v3-freshPCBs.jpg View gtm900-bo_v3-freshPCBs.jpg 204 KB mschramm, 11/20/2023 11:23 PM
gtm900-bo_v3-freshPCBs-populated.jpg View gtm900-bo_v3-freshPCBs-populated.jpg 202 KB mschramm, 11/22/2023 09:55 PM

Checklist

  • UART A
  • UART B
  • Audio on 3.5mm jack[s]
  • power supply
  • mechanical mounting of GTM module
  • power button control via modem handshake (optional via jumper)
  • mounting holes of breakout board

Related issues

Related to OsmocomBB - Feature #4575: Build + Test CP2102 GTM900 breakout board prototypeClosedroh06/02/2020

Actions
Related to OsmocomBB - Bug #4610: OBB port on GTM900-B risks causing hw damage with fighting driver outputs on Calypso GPIO3/DTR lineResolvedlaforge06/10/2020

Actions
Actions #1

Updated by laforge over 4 years ago

The shortest 40pos 0.5mm pitch FPC available from Digikey seems to be https://www.digikey.com/product-detail/en/molex/0151660425/WM16424-ND/3281306 at 29.97mm.

Actions #2

Updated by mschramm over 4 years ago

GTM900 exposes no LED at all, so the breakout only will get a power-on LED.

Should the modem reside on the break-out PCB like on the mPCIe adapter, e.g. with hex spacer, or will this board be much smaller for only carrying the additional functionality and not the modem itself?

Actions #4

Updated by laforge over 4 years ago

  • Priority changed from Normal to Low

the modem should be mounted with spacers on the board. I typically want to have a mechanically stable configuration, without any pigtails or other fragile constructs hanging off it. That's why we have the SMA sockets on the mpcie breakout board, and why I believe we should have a similar construct here.

Actions #5

Updated by mschramm over 4 years ago

mschramm wrote:

GTM900 exposes no LED at all,

this might be not true, there are two pins with funny names and ambiguous descriptions, so likely one of them (or both?) might drive a LED (plus aditional driver):

Pin 13 is VDD (output), and its function "signal indication of normally started GTM900". The other is pin 32, LPG (output), "mainly controls the status of the indicator".

Actions #6

Updated by mschramm over 4 years ago

  • Status changed from New to In Progress
Actions #7

Updated by steve-m over 4 years ago

mschramm wrote:
Pin 13 is VDD (output), and its function "signal indication of normally started GTM900". The other is pin 32, LPG (output), "mainly controls the status of the indicator".

LPG is "LED pulse generation", basically dedicated timer circuitry to let an LED blink. Currently it is configured to have the LED always on, which works on the GTM900 on the existing breakout-board from China.

Actions #9

Updated by mschramm about 4 years ago

  • Status changed from In Progress to Stalled
Actions #10

Updated by mschramm almost 4 years ago

  • Status changed from Stalled to In Progress
Actions #11

Updated by mschramm almost 4 years ago

  • % Done changed from 0 to 70

just committed an approach for a GTM900 breakout last week, and first (internal) feedback came from laforge, who wanted the CP210x and a decent audio connection w/o pin header contacts, - which both are now in place too. Some routing is not yet done because of open questions.

  • I left in a mirrored version of the FPC receptacle representing the modem connector; it will get removed.
  • level translation on that board is made by the CP2105 USB dual UART for both serial ports (now bus-powered)
  • do we want to care about Vbackup? e.g. bringing this signal to the aux/ expansion header?
  • RESET now is a tact switch, and PWRON a jumper. Do we want momentary switches on both?
  • the initial AUX header now is gone; now we only would need it for the 2nd audio channel and the ADC input. Do we need either/both/none? THT header or test pads?

remarks on the audio section:

  • schema is similar to that in the chinese datasheet
  • I prefer the differential design, but it makes ESD design little more complicated (more TVS; TVS tbd)
  • electret biasing is derived by VCC which originates from the modem; we hence might want an LC lowpass towards the mic
  • the audio jack now is a 3.5mm TRRS, whereas the datasheet shows a RJ10 modular jack on that position - which receptacle do we want? If TRS or TRRS: what pin assignment (cause there are more than one concurrent...) ?

Let me know your feedback!

Actions #12

Updated by mschramm almost 4 years ago

  • File GTM900-breakout-schematic.pdf added

(schematic pdf will be kept updated here for convenience when changes in schema are made)

Actions #13

Updated by laforge almost 4 years ago

mschramm wrote:

just committed an approach for a GTM900 breakout last week, and first (internal) feedback came from laforge, who wanted the CP210x and a decent audio connection w/o pin header contacts, - which both are now in place too. Some routing is not yet done because of open questions.

I actually thought a CP2102 (single-port) only for one of the two UARTS, while the other one is on the normal osmocom style 2.5mm jack. But putting both UARTs ona CP2105 also seems fine to me, to be honest.

  • do we want to care about Vbackup? e.g. bringing this signal to the aux/ expansion header?

I think it may make sense if one wanted to play with the power saving features. At least have a connector, or possibly even have a footprint for a DNP battery holder?

  • RESET now is a tact switch, and PWRON a jumper. Do we want momentary switches on both?

I think reset as a button (taster) and PWRON on a jumper (defauly: on) looks good to me.

I think tsaitgaist once had a "DTR to power on calypso" device, so maybe we also have a jumper (and transistor?) to enable this mode of operation?

  • the initial AUX header now is gone; now we only would need it for the 2nd audio channel and the ADC input. Do we need either/both/none? THT header or test pads?

In general I would put all unused signals on test pads.

  • the audio jack now is a 3.5mm TRRS, whereas the datasheet shows a RJ10 modular jack on that position - which receptacle do we want? If TRS or TRRS: what pin assignment (cause there are more than one concurrent...) ?

I would definitely go for one (or two) 3.5mm jacks for the audio, assuming that people can use the kind of headsets that you would attach to audio jacks of a PC or laptop. IF a 4pin 3.5mm is used, let's use what laptop jacks e.g. of lenovo tend[ed?] to use.

Actions #14

Updated by laforge almost 4 years ago

  • Checklist item UART A added
  • Checklist item UART B added
  • Checklist item Audio on 3.5mm jack[s] added
  • Checklist item power supply added
  • Checklist item mechanical mounting of GTM module added
  • Checklist item power button control via modem handshake (optional via jumper) added
  • Checklist item mounting holes of breakout board added
Actions #15

Updated by falconia almost 4 years ago

FYI, I already made my own breakout/adapter board for GTM900 modules (called MMTB1) several months ago:

ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/mmtb1.tar.gz
https://www.freecalypso.org/pipermail/community/2020-January/000729.html

But my MMTB1 is much simpler than what you are doing here; your version is more complex with built-in USB-serial and taking 5V in rather than ready-made VBAT. My MMTB1 brings out the same interfaces as FCDEV3B, but it looks like your preferences are different.

In technical terms, I see only two problems with your current version, based on your PDF schematics posted in this ticket:

1) You have the GTM900 modem's UART_RI line connected to CP2105 SUSPEND/RI_SCI. The modem's UART_RI line is actually Calypso GPIO 0, but Huawei's official firmware configures this Calypso GPIO as an output, and my FreeCalypso firmware does likewise. But according to CP2105 datasheet, pin 1 (SUSPEND/RI_SCI) acts as the SUSPEND output by default, unless you switch it to RI_SCI or some other function via OTP configuration. Having CP2105 and Calypso outputs fight seems like a bad idea to me, and I would be concerned about possibly damaging one of the chips. So if you are going to keep this wiring, you should do the appropriate OTP configuration on the CP2105 to change that pin function. Yes, it sucks that CP2105 configuration is OTP instead of EEPROM: you only get one chance to program it, and if you mess it up, you have to either throw away the board or try to replace the QFN chip, which would be a major pita. For this reason, if you are going to keep the wiring that calls for OTP configuration change, you should do the programming at your factory, rather than leave it to end users. (This OTP nonsense is one of the many reasons why I am sticking with FT2232D for my projects and have no desire to switch to CP2105, but it is obviously not my place to tell you what to do in your business.)

2) MIC- and MIC+ microphone input signals on the GTM900 FPC interface are NOT raw Iota MICIN & MICIP, instead GTM900 already incorporates capacitive coupling and ECM bias injection circuits inside the module. Therefore, your external ECM bias injection circuit is wrong and should be removed. The circuit depicted in the Chinese document resides inside the GTM900 module itself, it is not something you need to build externally. The module's VDD output is the internal V-IO power rail, produced by Iota regulator VRIO - it is a digital (thus noisy) supply rail, not for anything analog. For the ECM bias the Iota chip has a dedicated MICBIAS analog voltage output, but this Iota output is not brought to the outside of GTM900, instead that whole circuit is implemented inside the module.

Actions #16

Updated by laforge almost 4 years ago

Dear Mychaela,

many thanks for your input, it is - as always - much appreciated.

On Tue, Apr 28, 2020 at 06:45:39PM +0000, falconia [REDMINE] wrote:

FYI, I already made my own breakout/adapter board for GTM900 modules (called MMTB1) several months ago:

I am aware of this board, but indeed I found it somewhat lacking in
features for the kind of use case I have in mind. It seemed more like a
'raw breakout', i.e. a mechanical adapter fo the FPC to other
pins/connectors, than to try provide as much as possible in terms of
an environment that's easy to use without building further hardware.

This is not a complaint at all. It's just that our goals are (as it
seems customary by now) somewhat different :)

In technical terms, I see only two problems with your current version,
based on your PDF schematics posted in this ticket:

1) You have the GTM900 modem's UART_RI line connected to CP2105 SUSPEND/RI_SCI. The modem's UART_RI line is actually Calypso GPIO 0, but Huawei's official firmware configures this Calypso GPIO as an output, and my FreeCalypso firmware does likewise. But according to CP2105 datasheet, pin 1 (SUSPEND/RI_SCI) acts as the SUSPEND output by default, unless you switch it to RI_SCI or some other function via OTP configuration.

Thanks for pointing that out. I would assume we can do the OTP
programming - but we'd have to do it in a safe way, i.e. at a time
before the GTM900B is connected.

Factory pre-programming the CP2105 is not really an option for us, the
quantities are too low to rectify that. But we can of course do the
programming after component placment before ever placing the modem on
the board, and long before it ever gets into the hand of a user.

As a "plan B safeguard" I suggest we put a 0-ohm resistor into the line,
so if for some reason we are in trouble, we can interrupt the signal
without having to resort to cutting copper traces with a scalpel.

2) MIC- and MIC+ microphone input signals on the GTM900 FPC interface are NOT raw Iota MICIN & MICIP, instead GTM900 already incorporates capacitive coupling and ECM bias injection circuits inside the module. Therefore, your external ECM bias injection circuit is wrong and should be removed.

Interesting, thanks. I'll leave it to @weef to investigate and act
accordingly.

Regards,
Harald

Actions #17

Updated by falconia almost 4 years ago

laforge wrote:

I am aware of this board, but indeed I found it somewhat lacking in
features for the kind of use case I have in mind. It seemed more like a
'raw breakout', i.e. a mechanical adapter fo the FPC to other
pins/connectors, than to try provide as much as possible in terms of
an environment that's easy to use without building further hardware.

I would not call my MMTB1 a "raw breakout", instead it is an intermediate form between a raw breakout and what you are building. A true raw breakout is what Songbosi sent me originally: all 40 pins of the FPC connector wired 1-to-1 to 2.54 mm header pins. That raw breakout was truly difficult to work with, so I built my MMTB1 as a replacement. MMTB1 has an on-board SIM socket and on-board pushbuttons for PWON and RESET, so it is not just going from FPC to other connectors. And I wasn't building any further hardware, instead I simply reused the same power supply and dual UART adapter which I already had for FCDEV3B.

This is not a complaint at all. It's just that our goals are (as it
seems customary by now) somewhat different :)

Yes, of course we have different goals as usual, but if you do produce this breakout board you are currently building and make complete GTM900-B kits available in your webshop, then it would help me too: it would provide one more low-entry-barrier path for potential users to play with my FreeCalypso firmware.

Thanks for pointing that out. I would assume we can do the OTP
programming - but we'd have to do it in a safe way, i.e. at a time
before the GTM900B is connected.

Yes, that was my thinking as well.

Factory pre-programming the CP2105 is not really an option for us, the
quantities are too low to rectify that.

I didn't mean Silabs chip factory preprogramming, instead I meant your own Sysmocom small hw factory - just like my FreeCalypso hw factory is a converted bedroom where I have my CMU200 and other production test gear, I assumed that you have something similar.

But we can of course do the
programming after component placment before ever placing the modem on
the board, and long before it ever gets into the hand of a user.

Good, this is exactly what I was asking for.

As a "plan B safeguard" I suggest we put a 0-ohm resistor into the line,
so if for some reason we are in trouble, we can interrupt the signal
without having to resort to cutting copper traces with a scalpel.

Seconded!

[MIC interface]

Interesting, thanks. I'll leave it to @weef to investigate and act
accordingly.

Just to reiterate, the MIC- and MIC+ pins that come out of the GTM900 on the FPC interface are meant for direct connection of an electret condenser microphone. On my MMTB1 I have these two signals routed to a 2-pin 2.54 mm header without any extra glue components, and I can connect an ECM to those two pins exactly the same as on FCDEV3B. In the case of FCDEV3B I have copied the microphone interface circuit (ECM bias injection and capacitive coupling to Iota MIC inputs) from TI's Leonardo schematics, but GTM900 already has this exact same circuit built-in inside the module.

Actions #18

Updated by laforge almost 4 years ago

On Wed, Apr 29, 2020 at 07:27:18AM +0000, falconia [REDMINE] wrote:

Factory pre-programming the CP2105 is not really an option for us, the
quantities are too low to rectify that.

I didn't mean Silabs chip factory preprogramming, instead I meant your own Sysmocom small hw factory - just like my FreeCalypso hw factory is a converted bedroom where I have my CMU200 and other production test gear, I assumed that you have something similar.

It still is too much effort. tHat would mean we'd have to have a ZIF socket for this specific QFN package,
and remove every chip from the tape/reel, then re-reel it before passing it to the SMT house. Even if a tray
package was available, it's too much work ad no real benefit over the post-production-programming.

[MIC interface]

Interesting, thanks. I'll leave it to @weef to investigate and act
accordingly.

Actually, I meant mschramm

Just to reiterate, the MIC- and MIC+ pins that come out of the GTM900 on the FPC interface are meant for direct connection of an electret condenser microphone. [...]

understood.

Actions #19

Updated by mschramm almost 4 years ago

Thanks for remarks and input!

Audio I/O:

falconia: after I had some translated phrases on what is in section 4.6.3 of the Chinese datasheet, it became clear that this is internal circuitry...!

But this means that we
  • either have an audio-out as shown in gtm900-audio-io-symm.png (incompatible with a Lenovo Combo audio ("AHJ/CTIA") requested by laforge; in this case we should strip the TRRS jack and bring those four wires to a pin header)),
  • or try an asymmetrical approach (gtm900-audio-io-asymm.png), which might work on a CTIA TRRS headset (in this case the TVS array should be reduced to two discrete diodes)
    For the latter, we might want to introduce a AGND area covering the receptacle, connected w/ a ferrite or a 10R.. to GND.
SUSPEND/RI_SCI on modem's UART_RI:

The CP2105 can be programmed before the FPC towards the modem is mounted / inserted into both receptacle. Question remains whether the CP2105 needs the VIO input from the modem during programming.
Also, as we don't need the VDD_3V45 from the CP2105, we could strip the two buffer caps there - or just leave them in place and bring VDD_3V45 to another test pad.

PWON control via modem handshake (optional via jumper):

The english and the chinese datasheet differ in the display on how PWON needs to be used (see images PWON_chinese-ds.png and PWON_english-ds.png): for powering on, a 10ms LOW on that line switches on, while bringing it LOW for 2 to 3 seconds, switches off the modem. We hence shoud not short this signal with a jumper to GND. I now used a tact switch as for RESET, and a non-inverting buffer w/ a tristate output fed by the UART_DTR signal (I should add a 0R resistor on that buffer's input, or maybe the mentioned junmper... ;) )

mechanical mounting of GTM module:

Out of the four drills in the GTM900 we should only use three (one is a halved on an edge), drills take 2mm screws. We should take hex SMT spacers for 2mm and screws similar to those on the M.2/NGFF PCBA.

Actions #20

Updated by mschramm almost 4 years ago

  • File deleted (GTM900-breakout-schematic.pdf)
Actions #21

Updated by mschramm almost 4 years ago

  • File GTM900-breakout-schematic.pdf added

(schematic pdf updated)

Actions #22

Updated by falconia almost 4 years ago

Hi mschramm,

falconia: after I had some translated phrases on what is in section 4.6.3
of the Chinese datasheet, it became clear that this is internal
circuitry...!

Glad we are on the same page now.

But this means that we
  • either have an audio-out as shown in gtm900-audio-io-symm.png (incompatible
    with a Lenovo Combo audio ("AHJ/CTIA") requested by laforge; in this case we
    should strip the TRRS jack and bring those four wires to a pin header)),

This is the approach I would favor, including the pin header part - it
is the approach implemented on my MMTB1, simple and trustworthy.

  • or try an asymmetrical approach (gtm900-audio-io-asymm.png), which might
    work on a CTIA TRRS headset (in this case the TVS array should be reduced to
    two discrete diodes)

I don't know enough audio-fu to tell if this approach will work or not
- proceed at your own risk.

For the latter, we might want to introduce a AGND area covering the
receptacle, connected w/ a ferrite or a 10R.. to GND.

Ditto regarding the unknown.

The CP2105 can be programmed before the FPC towards the modem is mounted
/ inserted into both receptacle.

Yes, this is what I am hoping you will do on your end before shipping
these boards to webshop customers.

Question remains whether the CP2105 needs the VIO input from the modem
during programming.

To be honest, I rather dislike the entire idea of using the modem's
V-IO output to power the VIO supply on the USB-serial converter side.
Instead the proper approach would be to implement a dedicated LDO
regulator on the USB side, powered from USB VBUS and putting out 2.8V,
and use that non-modem-sourced regulator to power the USB-serial
chip's VIO supply. If you are going to keep your current arrangement
of abusing Calypso V-IO for powering CP2105 I/O buffers, then you are
going to have the following two potential problems:

1) You won't be able to use any CP2105 GPIO outputs to command a modem
power-on: while the VRPC block in the Iota chip in the modem is in the
switched-off state, the chip's VRIO regulator is fully off, and there
is no voltage put out on the V-IO rail - a chicken and egg problem.

2) If the Calypso+Iota chipset is allowed to go into superdeep sleep
(my made-up term for the sleep mode in which not only is the Calypso
put into deep sleep with the VCXO stopped, but the Iota ABB sleep mode
is also activated), the maximum current that can be drawn from the
VRIO regulator is reduced to just 1 mA, in contrast with the 100 mA
allowed in Active mode. The modem's internal circuits are designed so
that this 1 mA sleep mode limit is never exceeded, but I can only
reason that your CP2105 can easily exceed that very tight limit.

PWON control via modem handshake (optional via jumper):

The GTM900 modem's PWON control input is wired directly to the
same-named signal on the Iota ABB chip, thus its behaviour is governed
100% by TI's Calypso+Iota chipset design, not by anything from Huawei.
The only way to understand it properly is to read and thoroughly
understand section 4.10 (Voltage Reference and Power Control) of TI's
TWL3025 datasheet:

ftp://ftp.freecalypso.org/pub/GSM/Calypso/TWL3025_SWRS021.pdf

Pages 40 through 44 of this datasheet cover the VRPC block.

The english and the chinese datasheet differ in the display on how PWON
needs to be used (see images PWON_chinese-ds.png and PWON_english-ds.png):

Independent of Huawei's recommendations, the actual hardware reality
inside the Iota chip is that when the VRPC state machine is in the OFF
state (the initial power-on condition after application of VBAT to
module pins 1-5), any instantaneous sampling of a LOW on the PWON line
will initiate the switch-on sequence, causing the Calypso processor to
boot. Regardless of what happens afterward (PWON being quickly released
or staying low forever), any further state transitions can only be
commanded by Calypso firmware.

for powering on, a 10ms LOW on that line switches on, while bringing it
LOW for 2 to 3 seconds, switches off the modem.

These are firmware conventions, not hardware - there aren't any such
timers anywhere in that modem hw.

We hence shoud not short this signal with a jumper to GND.

At least with FreeCalypso fw (not sure about Huawei's original fw),
having PWON permanently grounded with a jumper is OK but suboptimal:
the firmware is smart enough to recognize that no power-off request is
being made in this situation, but the downside is that Iota sleep mode
(what I call superdeep sleep) cannot be entered: a LOW on PWON is an
unconditional wakeup request to Iota VRPC.

On my FCDEV3B I provide a PWON pushbutton switch and a two-pin header
wired in parallel with it: using the pushbutton switch is preferable,
but a jumper may also be installed for unattended operation where no
human is available to press the button.

I now used a tact switch as for RESET,

This one is good. Please note that your pull-up resistor R11 is
unnecessary, although harmless - PWON is internally pulled up to VBAT
inside the Iota chip itself.

and a non-inverting buffer w/ a tristate output fed by the UART_DTR signal

This one is more problematic: Huawei's UART_DTR signal is wired to
Calypso GPIO3 internally (following TI's C-Sample and D-Sample
reference boards where GPIO3 was wired as DTR), TI's TCS211 reference
fw implements logic for CSD call hang-up per AT&D, and I assume that
Huawei's fw does likewise. Users should be able to wiggle DTR however
they like to play with AT&D logic in the firmware, without accidentally
commanding a power-off or preventing the modem from going into
superdeep sleep. Please pick a different CP2105 GPIO output: you have
all of the GPIOs associated with the other UART currently unused.

I would also strongly recommend following Openmoko's reference for how
to control PWON with a GPIO coming an application processor:

ftp://ftp.freecalypso.org/pub/GSM/GTA02/GTA02_Schematic_MB_A5_1220.pdf

See page 16, the circuit around Q1000.

Two additional concerns:

1) The RST signal which GTM900 provides on pin 31 is a very non-trivial
beast. As I discovered by reverse eng of this GTM900 module, it turns
out that Huawei replicated the XDS_RESET circuit from TI's Leonardo
development board:

ftp://ftp.freecalypso.org/pub/GSM/Calypso/Leonardo_rev05.pdf

Look on page 3, the JTAG block depiction along the top of the page,
the transistor circuit (Q308A and Q308B) between Iota nTESTRESET and
JTAG connector pin 2. This Q308 dual transistor is also present on
the GTM900, and Huawei's FPC connector pin 31 is wired exactly the
same way as JTAG connector pin 2 on TI's reference boards (and on my
own FCDEV3B too, which also has this exact same circuit). Some while
ago I wrote a detailed document explaining all of these quirks:

https://www.freecalypso.org/hg/freecalypso-docs/file/tip/Calypso-test-reset

Given that the RST signal you are manipulating is really XDS_RESET,
your pull-up to VBAT (R12) is wrong - it would leak the much higher
VBAT voltage into the modem's V-IO rail through the internal resistors
built into the prebiased transistor package. Having a pushbutton
switch shorting XDS_RESET to GND is OK (although not ideal because of
contact bounce, as explained in my article linked above) - but because
the reset signal is XDS_RESET rather than raw Iota nTESTRESET, you
could drive it with another GPIO from your CP2105.

2) What are you doing with the Calypso SIM_CD line which GTM900 brings
out on pin 24? Right now it looks like you are leaving it unconnected,
which would be bad as it would be a floating CMOS input on the Calypso.
On TI's Leonardo reference schematics, on Openmoko GTA02 and on my own
FCDEV3B this SIM_CD signal is connected to Calypso V-IO, and I recommend
that you do the same. Alternatively, connecting it to GND will probably
be fine too - it looks like most firmwares ignore it, as long as it
isn't left completely floating.

I hope that my feedback will be taken to heart - while I prefer my own
MMTB1 for my own playing with GTM900 modems, I am interested in your
competing GTM900 breakout board because if you end up offering it in
your webshop and it is designed correctly, it would provide one more
low-entry-barrier route for people to play with my FreeCalypso firmware
on cheap and readily available hw. But it would be a real shame if
you design your breakout board in such a way that it would be usable
only with your primitive OBB firmware and not with richer firmwares
like FreeCalypso or Huawei's original.

Actions #23

Updated by laforge over 3 years ago

prototype PCB received (no parts yet to assemble).

The first problem I see is the SMT (soldered) spacers on the bottom side to mechanically mount the module. This would require a second reflow just for those four SMT spacers. which will make the product more expensive to assemble. It's the only bottom mounted part..

Soldering those by hand is very likely also quite a bit of effort - and you'd have to be super careful not to get any solder on the thread of the spacer.

So I guess we should go back to a more classic mounting option with regular, screw-mounted spacers (which may require more clearance)

Actions #24

Updated by mschramm over 3 years ago

I don't quite understand; we never had these types of problems when assembling the SMT spacer (manually) on the prototypes for e.g. NGFF breakout or OctSIM. Manual soldering ist very easy and takes place from the modem side, not the SMT placement side. So no thread gets into danger by solder.

Actions #25

Updated by laforge over 3 years ago

On Sat, May 30, 2020 at 10:13:21PM +0000, mschramm [REDMINE] wrote:

I don't quite understand; we never had these types of problems when assembling the SMT spacer (manually) on the prototypes for e.g. NGFF breakout or OctSIM. Manual soldering ist very easy and takes place from the modem side, not the SMT placement side. So no thread gets into danger by solder.

ok, good to hear.

However: Dong this for (few) prototypes by hand is one thing - assuming
that the mass produced units are reflow soldered. But manually
soldering 4 spacers on e.g. 100 boards is a bit of a different story.

I would have assumed it's faster/cheaper to simply use screw/nut mounted spacers.

Actions #26

Updated by laforge over 3 years ago

  • Related to Feature #4575: Build + Test CP2102 GTM900 breakout board prototype added
Actions #27

Updated by laforge over 3 years ago

  • Status changed from In Progress to Feedback
  • Assignee changed from mschramm to roh
Actions #28

Updated by mschramm over 3 years ago

Images from building 1st PCBA prototype

Actions #29

Updated by roh over 3 years ago

i have one assembled prototype now (#4575) and am a bit unsure what config exactly to program into the cp2105.

this is the current (default) settings as read by this tool https://github.com/DiUS/cp210x-cfg

sudo ./cp210x-cfg
ID 10c4:ea70 @ bus 002, dev 057: CP2105 Dual USB to UART Bridge Controller
Model: CP2105
Vendor ID: 10c4
Product ID: ea70
Name: CP2105 Dual USB to UART Bridge Controller
Serial: 00D750E8
Flush buffers: 33
SCI/ECI mode: ffff

any suggestions about different tools or ways to make sure my 'mode' is correct are welcome.

Actions #30

Updated by laforge over 3 years ago

roh wrote:

i have one assembled prototype now (#4575) and am a bit unsure what config exactly to program into the cp2105.

I would have hoped that we can do PCB validation without having to program anything beyond the initial defaults. Please coordinate with mschramm what he thinks should be programmed.

Keep in mind it's a real OTP, so if you program something wrong, you need to re-work/replace the CP2105.

Actions #31

Updated by mschramm over 3 years ago

laforge wrote:

I would have hoped that we can do PCB validation without having to program anything beyond the initial defaults.

Not, as long is R24 (0R) is placed: this connects !SUSPEND/RI_SCI and modem's UART_RI, and as USB suspend output is default, this and RI should not be connected w/ an unprogrammed cp2105 beforehand. Additionally, depending on default unprogrammed states of the respective cp2105 pins, R7, R8 and R20 (base resistors on reset- and PWON driver stages) might need to be unpopulated for this first modem tests w/o programmed cp2105.

Please coordinate with mschramm what he thinks should be programmed.

In terms of GPIO mode vs. Modem mode, I think SCI shall be in modem mode, and ECI in GPIO mode.
GPIO.0_ECI and GPIO.1_ECI shall be push-pull outputs.

Saying this, I obviously forgot to switch LDO's EN input via a GPIO.. ok, v2, which GPIO, none left?

Main LDO on picture gets another package, too; this one will work for testing on first prototype.

Actions #32

Updated by mschramm over 3 years ago

  • File deleted (GTM900-breakout-schematic.pdf)
Actions #33

Updated by mschramm over 3 years ago

(schematic pdf updated)

Actions #34

Updated by falconia over 3 years ago

mschramm wrote:

In terms of GPIO mode vs. Modem mode, I think SCI shall be in modem mode, and ECI in GPIO mode.

Looks correct to me.

GPIO.0_ECI and GPIO.1_ECI shall be push-pull outputs.

Are there also bits that configure the default initial state of these outputs? If so, you would want them to be LOW initially by default, which would be the inactive state per your current schematics.

Saying this, I obviously forgot to switch LDO's EN input via a GPIO.. ok, v2, which GPIO, none left?

What is wrong with having this LDO always on whenever USB power is present? You won't be able to control it with a GPIO, as it is your I/O voltage supply for your CP2105 - chicken and egg problem.

Other bugs I see on your current schematics:

  • Why is the right side of R25 (CP2105 RST pull-up resistor) connected to the modem's VDD instead of your locally generated VIO?
  • The "high" side of your SIM card presence detect switch exhibits the opposite bug.
Actions #35

Updated by falconia over 3 years ago

Please also see bug #4610 - yes, your current breakout board is affected by it.

Actions #36

Updated by roh over 3 years ago

falconia wrote:

  • Why is the right side of R25 (CP2105 RST pull-up resistor) connected to the modem's VDD instead of your locally generated VIO?

i just checked the DS and i think this should be VDD_3V45 in our schematic, not VIO.
i can rework R25 to get VDD from C22/23 near it.

  • The "high" side of your SIM card presence detect switch exhibits the opposite bug.

so R4 needs to connect to VDD instead of VIO_2V8 ? i guess USIM_VCC would be wrong since detecting presence needs to work even when the simcard-vcc is off?

Actions #37

Updated by falconia over 3 years ago

roh wrote:

  • Why is the right side of R25 (CP2105 RST pull-up resistor) connected to the modem's VDD instead of your locally generated VIO?

i just checked the DS and i think this should be VDD_3V45 in our schematic, not VIO.

Hmm, I looked in the CP2105 DS and the two reference schematics given there show it pulled up to CP2105 VIO, which is still not the same as the Calypso+Iota chipset's separately-generated VIO, where you have it pulled up currently. If you are seeing otherwise, please tell me exactly where and exactly which revision of the datasheet you are looking at.

i can rework R25 to get VDD from C22/23 near it.

Or you can just depopulate R25 - the CP2105 DS says this pull-up is optional to improve noise immunity.

  • The "high" side of your SIM card presence detect switch exhibits the opposite bug.

so R4 needs to connect to VDD instead of VIO_2V8 ?

Yes, because the signal which you (and Huawei unfortunately too) are calling VDD here (not CP2105 VDD!) is actually called V-IO in the Calypso+Iota chipset docs - it is the output of Iota LDO regulator VRIO. The signal which you are calling USIM_CD but which was originally just SIM_CD goes directly to the Calypso chip, it is a regular digital input, referenced to the Calypso+Iota chipset's V-IO, which Huawei also brought out as VDD for uses like the present.

Using a differently-sourced 2.8V rail here like your current VIO_2V8 (sourced from an LDO from USB rather than from Iota) shouldn't cause any harm in practice (at least none I can think of on the spot), but it is still philosophically wrong.

i guess USIM_VCC would be wrong since detecting presence needs to work even when the simcard-vcc is off?

Definitely wrong, as in wrong voltage level - it is a Calypso digital input referenced to the chipset's internal V-IO, NOT referenced to level-shifted SIM interface voltage.

Please also note that most designs do away with this switch altogether: on Openmoko GTA02 this Calypso SIM_CD input is tied directly to Calypso+Iota V-IO (well, OK, going through a 0R), ditto on TI's own Leonardo reference board from which Openmoko copied this bit, and on my FCDEV3B which works very well. My MMTB1 adapter for GTM900-B modems also has this FPC pin connected directly to Huawei's VDD, which is actually Calypso+Iota V-IO.

Actions #38

Updated by mschramm over 3 years ago

  • Related to Bug #4610: OBB port on GTM900-B risks causing hw damage with fighting driver outputs on Calypso GPIO3/DTR line added
Actions #39

Updated by mschramm over 3 years ago

falconia wrote:

roh wrote:

  • Why is the right side of R25 (CP2105 RST pull-up resistor) connected to the modem's VDD instead of your locally generated VIO?

It goes to modem's VDD which is clearly a mistake.

i just checked the DS and i think this should be VDD_3V45 in our schematic, not VIO.

Hmm, I looked in the CP2105 DS and the two reference schematics given there show it pulled up to CP2105 VIO, which is still not the same as the Calypso+Iota chipset's separately-generated VIO, where you have it pulled up currently. If you are seeing otherwise, please tell me exactly where and exactly which revision of the datasheet you are looking at.

i can rework R25 to get VDD from C22/23 near it.

Or you can just depopulate R25 - the CP2105 DS says this pull-up is optional to improve noise immunity.

datasheet says that the /RST can withstand 5.8V (if CP2105's Vio > 2.2V, which is the case), so we even could connect VBUS to R25; so VIO_2V8 would do as well as VDD_3V45 and VBUS would do.
We can of course test w/o R25, but disregarding that the note says 'for better noise imunity', I'd like to have those parts placed or at least have the unplaced footprint for respective environments. Let's select a proper PU voltage supply rail for R25; it shouldn't be modem's VDD as it is now.

  • The "high" side of your SIM card presence detect switch exhibits the opposite bug.

[...]

Using a differently-sourced 2.8V rail here like your current VIO_2V8 (sourced from an LDO from USB rather than from Iota) shouldn't cause any harm in practice (at least none I can think of on the spot), but it is still philosophically wrong.

Disregarding that VIO_2V8 here would work: agreed, SIM_CD's PU voltage should go to modem's VDD.

from an update before:

Saying this, I obviously forgot to switch LDO's EN input via a GPIO.. ok, v2, which GPIO, none left?

What is wrong with having this LDO always on whenever USB power is present? You won't be able to control it with a GPIO, as it is your I/O voltage supply for your CP2105 - chicken and egg problem.

You got me wrong here (while me not being precise enough): not the VIO_2V8 LDO was meant, but the main MCP1827.

Actions #40

Updated by falconia over 3 years ago

On 6/22/20, mschramm [REDMINE] <> wrote:

You got me wrong here (while me not being precise enough): not the VIO_2V8
LDO was meant, but the main MCP1827.

OK, and still the question remains: what is wrong with having this
main MCP1827 LDO always enabled?

Actions #41

Updated by roh over 3 years ago

ok

i have reworked:
  • R25 to VDD_3v45
  • R4 to VDD

on all 3 boards now.

Actions #42

Updated by mschramm over 3 years ago

Just reviewed some application notes and btw the errata sheet for the cp2105, and the latter contains an important mistake which impacts our current design. They call this error "CP2105_E101", it is about the voltage level of VIO during programming:

The data sheet incorrectly indicates that VDD must remain at 3.3 V or higher to successfully write to the configuration ROM. Instead,
the voltage on the VIO pin must remain at 3.3 V or higher when writing to the configuration ROM.

As VIO and VDD is not connected in our design (by intention), this error ist crucial; U3 must not be in place when in-circuit programming the cp2105, and VIO must be connected to VDD during programming.

Actions #43

Updated by roh over 3 years ago

CP2105_E101 verified sigh see https://osmocom.org/issues/4575#note-18

Actions #44

Updated by falconia over 3 years ago

Looking at the notes in #4575, it looks like your design decision to use CP2105 as your USB to dual UART adapter chip instead of FT2232x (a design decision with which I always strongly disagreed) has come back to bite you - it looks like you are having very major difficulties getting that chip's OTP configuration memory programmed in a way that your board requires.

If you would be willing to drop that horrible CP2105 chip and replace it with FT2232x (either D or H, whichever you prefer), I have put together a detailed document explaining exactly how one can build a properly working solution consisting of FT2232x and GTM900:

https://www.freecalypso.org/hg/freecalypso-docs/file/tip/GTM900-design-guide

If you would be willing to go the FT2232x route and would like further guidance beyond what I wrote in the article above, I will gladly help you further to the best of my ability.

Actions #45

Updated by laforge over 3 years ago

  • Status changed from Feedback to Stalled

waiting for completion of the prototoype, see #4575

Actions #46

Updated by mschramm about 2 years ago

  • File GTM900-breakout-schema_v2.pdf added
  • Status changed from Stalled to In Progress
  • Assignee changed from roh to mschramm
  • Priority changed from Low to Normal
  • % Done changed from 80 to 60

After another year, it's high time to continue here. There could be better times for new designs in terms of e-parts procurement possibilities, and this will reflect to some of the current design suggestion for a version 2 PCBA.

state of the onion v1

The CP2105 is not procurable anymore (except of course HK..), which is no problem for us, - as it meets the fact that we needed to get rid of it anyway. The downsides of this USB double UART in this use case were too demanding to hang on with that part, even if there was stock of it anywhere in quantites.

We had several problems by current leakage, so that a real modem in PCBA showed several weird side effects.

The bare start-up behaviour was not satisfying as we always needed to press the !PWON tact button. No auto-start up worked as intended.

Several circular dependencies also had to get solved, for example the supply/power rail assignment of some pull-up R's. Some of them have not been able to get seperated because of direct connections on e.g. QFN pads.

planned improvements for v2

  • We decided to have one CP2102 on the PCBA serving the main GTM900 UART, and have an OsmoSer 2,5mm jack for the secondary UART. That promises only advantages over a CP2105 solution:
    • there is no programming cycle needed to initially do something usefull with the PCBA
    • even the 'odd' baud rates can be achieved as described (e.g. HardwareCP210xTutorial) w/o fiddling in the CP2105's OTPROM
    • neither burst_ind nor CalypsoBTS need RTS/CTS hs, so not using these lines on this PCBA also means no need to set reasonable power-on defaults for those lines in the USB-UART IC
  • As noted #4575 (let's rather stay in this ticket w/ design-related stuff), using a (74HC)4066 for isolating signals worked: for the first time we could operate the GTM900 in a decent way. Still, it needed a manual power-on button press to start. A 4066 is ok, but this time we want to use a proper level shifter with tristate IO. * an SN74AVC4T245 has been proven to be the right part for these purposes, we'll use it here too. Its two power rails will be CP_VDD (for VDDA) and VIO_2V8 (for VDDB; see schema).
  • The auto-start never worked: we ever had to press !PWON, even after all the reworks. So, a delayed start signal is mandatory.
    • a voltage detector/reset IC (NCP303) was selected, this series features a pin for an additional timing capacitor. According to the GTM900 DS, the trip point is ~3.3V, when a 10ms delay should start, so we'd select an NCP303 voltage type close to that value (and depending on availability). The !PWON tact button stays in place for manual on/off.

DTR of the 1st UART now switches both LDOs and hence can power-cycle the modem. It can be overridden with JP4, which disables DTR-controlled modem power, as auto power-on is default (if R11 is in place (default)).

What can't get realized with that configuration:
  • besides RxD and TxD (level-shifted) and DTR (used for powering the modem), no other signal of the USB UART is used (except that they'll be brought to test points), no GPIOs on CP2102. Hence, the GTM900 'only' has RxD and TxD to and from host

misc

  • powering of CP2102 can be discussed (its default w/o programming is "bus-powered, 100mA") * VBUS on host VBUS is understood * REGIN on LDO_IN (jumper for VBUS or barrel conn DC input, after Schottky series diode, as on v1) will always act as 'bus-powered' for CP2102. The absence of either supply on REGIN or VBUS is tolerated by the IC, so no lock situation is expected here even for an initially unfitting JP1 setting. * REGIN and VBUS tied together could go to host VBUS too (like in v1)

trivials

Part procurement situation will stay as a problem for the time being. It is understood that the introduced footprints shall remain when there is an alternative (aka procureable) part w/ the same footprint and pin/pad assignment. OTOH, if another sourceable part fulfills requirements, for the v2 redesign it is a right moment

  • my beloved NCP303 fades out to NRND or even obsolete, so we'll likely use a BU4235 here for IC1
  • the main LDO (MCP1827) isn't available until somewhen next year, so this likely will be populated w/ a LP38502
  • the level shifter/HiZ buffer 4T245 should be in a TSSOP16 or VQFN16 (already have the Eagle libraries for them), but SOIC16 might give some advantages here, if we have the PCB space
  • !xOE signals of level shifter might better go to CP_DTR or even CP_VDD instead of GND - if we don't want to rely on this IC's "Ioff" feature to gain HiZ I/O state (see 4T245 ds)
  • the FFC socket FH12-40S-0.5SH(55) is not available anymore, we'll take FH12S-40S-0.5SH(55)

pending lab tests before v2

A BU4235 voltage detector has been ordered to prototype the planned new auto !PWON .


So, please see the attached schema for the details. - remaining PCB layout changes continue when we finish v2 discussion here.

Actions #47

Updated by laforge about 2 years ago

I see the PDF attached here, but I don't see any update to osmo-small-hardware.git?

Please always make sure changes are committed before generating any output files like PDF
renderings, this way we are sure the latest state is always in the repo.

Actions #48

Updated by laforge about 2 years ago

some review comments, in random order:
  • VCC could need some kind of better name (like VCC_4V2) or at least some kind of label/documentation text in the schematics about what voltage it is really.
  • particularly as the RTS/CTS is not going to be used now, I suggest to have all those unused modem signals on a header, not just test pads
  • similarly, the unused CP2102 could be on a header.
  • CP2102 seems to use the NRND QFN-28 package (expensive for > 5 EUR / unit) while the QFN-20 package variant appears to be available for < 2 EUR / unit.
  • R6 = 330R (like R19) for 4.2V (is that the VCC level?) VCC seems too low, maybe more 470-680 Ohms?
Actions #49

Updated by mschramm about 2 years ago

  • File deleted (GTM900-breakout-schema_v2.pdf)
Actions #50

Updated by mschramm about 2 years ago

design files in current state committed to git.

laforge wrote in #note-48:

  • VCC could need some kind of better name (like VCC_4V2) or at least some kind of label/documentation text in the schematics about what voltage it is really.

Affirmative. Actually, its name is now VCC_4V1.

  • CP2102 seems to use the NRND QFN-28 package (expensive for > 5 EUR / unit) while the QFN-20 package variant appears to be available for < 2 EUR / unit.

It is not the package: CP2102 w/o 'N' suffix is NRND (though no EOL PCN yet). They of course want everybody to use their CP2102N series in QFN-20/24/28.

As discussed in IRC, the N versions support uncommon baud rates, the 'baud rate aliasing' feature of the non-N versions seems not to be needed. We ordered a CP2102N minimum eval kit / breakout board and will check this.

Choosing a QFN28 footprint would give the possibility to use either N or non-N type which are pin-compatible (except the batt charger and GPIO pins which are 'NC' on the non-N type), whereas the newer N type also comes in QFN-24 and QFN-20 packages.

After all, the procurement situation will decide. In order to react faster here, a rework of the former ugly QFN28 library part (and forking a 'N' version for it) as well as a QFN20 N part has also been done.

  • particularly as the RTS/CTS is not going to be used now, I suggest to have all those unused modem signals on a header, not just test pads
  • similarly, the unused CP2102 could be on a header.

OK, but I think there is no space for a 2,54 pin header of that size except after increasing PCB size. Additonally, we would need VIO_2V8, GND and maybe also CP_VDD on that header (for e.g. external level shifter) and hence three pins more. Even with the QFN-20 package and only two GPIO on that pinheader, we would need 11 pins (w/o supply rails).

  • R6 = 330R (like R19) for 4.2V (is that the VCC level?) VCC seems too low, maybe more 470-680 Ohms?

12 mA (@4.1V) is also value we got in the v1 prototypes, there the LEDs were not too bright. Let's check this in the v2 prototype, preferably with the those LED parts a designated contract manufacturer stocks.


other changes done after last update:

  • possible use of N types of CP2102 requires a voltage divider of IC's VBUS input (for non-N types, it can easily ommitted with a series 0R or even letting the divider in place)
Actions #51

Updated by laforge about 2 years ago

On Mon, Feb 21, 2022 at 07:40:35PM +0000, mschramm wrote:

  • particularly as the RTS/CTS is not going to be used now, I suggest to have all those unused modem signals on a header, not just test pads
  • similarly, the unused CP2102 could be on a header.

OK, but I think there is no space for a 2,54 pin header of that size except after increasing PCB size. Additonally, we would need VIO_2V8, GND and maybe also CP_VDD on that header (for e.g. external level shifter) and hence three pins more. Even with the QFN-20 package and only two GPIO on that pinheader, we would need 11 pins (w/o supply rails).

there is no strict constraint about the PCB size, is there? So if it's a moderate size increase, I think we can deal with it.

If it's easier routing-wise to have two or three smaller headers rather than one big one, also fine with me.

Actions #52

Updated by mschramm almost 2 years ago

mschramm wrote in #note-46:

pending lab tests before v2

A BU4235 voltage detector has been ordered to prototype the planned new auto !PWON .

BU4235 has been successfully attached to one prototype: 15nF for Ct gives about 80ms PWON delay (by DS diagram; not osci'scoped yet), which appears to do the job of reliably starting the modem after power supply attached; so, auto-PWON is solved.

Actions #54

Updated by falconia 3 months ago

The schematic drawing in that PDF looks incomplete. Where is USB connection to RP2040? Where is the serial flash chip for that MCU? And if these pieces are obviously missing, there may be other missing pieces too that aren't as obvious.

Commenting on aspects that are visible, though:

  • Iota audio output EAR- appears to be shorted directly to ground with a 0R at R38. This arrangement is likely to damage the Iota chip inside the GTM900 module: its earpiece output is differential, with both legs driving, and it is most certainly not designed to have either leg shorted to ground.
  • On the subject of analog audio, I have a custom headset design that was specifically made for Calypso devboards - I got a large batch of them custom-made for me two years ago. It is called FC-HDS4, originally commissioned for FC Venus project, and I have 100 of them in stock - and can easily make as many as needed. If you would like to make your board compatible with this headset, the jack needs to be 2.5 mm (not 3.5), TRRS type, wired as follows: Tip = EAR+, Ring = MIC+, Ring2 = EAR-, Sleeve = MIC-. (This pinout came from iWOW devboard, covered in 2023-11-15 OsmoDevCall.)
  • I see that you have a connection from RP2040 GPIO to GTM900 PWON control - good. Please add another such GPIO connection to GTM900 RST control. Both GPIOs will need to be configured as open drain outputs (OD emulation really, via output enable) in RP2040 firmware.
  • UART connections: I see data lines from both UARTs, plus Modem UART RTS & CTS - good. However, GTM900 has DTR, DCD, DSR and RI modem control signals too, implemented via Calypso GPIOs, with the first two (DTR and DCD) following the tradition from TI themselves. These extra modem control lines are currently not connected to RP2040 GPIOs in your design - hence a regression from TI & FreeCalypso devboards. If you are unwilling to add these connections, someone will have to do a little RE on GTM900 PCB to determine if there is a built-in pull resistor in either direction on GPIO3/DTR input. If there is no in-module pull-up or pull-down, you will need to implement one on your board - otherwise standard fw will see a floating input there. This floating input will be extra-bad with fw versions that configure it as an edge-triggered interrupt to Calypso, like TI's "pure" TCS211 fw does.

Naming: the board you are designing is NOT a mere breakout, hence calling it such is disingenuous. I propose that you call it SysmoCalypso or SysmoGTM900 or something along those lines. Your board design involves very significant original innovation beyond GTM900: you got your RP2040, your set of decisions as to which signals will be connected or not, your extremely ambitious design with audio codec chip (which I don't feel qualified to comment on) - far more than just a breakout. Furthermore, whenever controversial design decisions are involved - and the present design clearly involves highly controversial design decisions, as you got at least one senior Calypso engineer disagreeing with them - the name of the product should clearly reflect the identity of the party who made those controversial design decisions. Which is why your gadget here should be called Sysmo-something, reflecting the reality that it is a Sysmocom design with only you exercising authority over all design decisions.

Actions #55

Updated by laforge 3 months ago

falconia wrote in #note-54:

The schematic drawing in that PDF looks incomplete. Where is USB connection to RP2040? Where is the serial flash chip for that MCU? And if these pieces are obviously missing, there may be other missing pieces too that aren't as obvious.

See https://www.raspberrypi.com/products/raspberry-pi-pico/ for all the plentiful information about the Raspberry Pi Pico (a kind of SoM for the RP2040).

  • Iota audio output EAR- appears to be shorted directly to ground with a 0R at R38. This arrangement is likely to damage the Iota chip inside the GTM900 module: its earpiece output is differential, with both legs driving, and it is most certainly not designed to have either leg shorted to ground.

According to mschramm this was working fine in the v2 of the board. Admittedly, we don't know if there is a chance for damage to the output drivers over extended period of time. Did we check for excess current consumption with/without that connection? Is there an easy alternative?

  • On the subject of analog audio, I have a custom headset design that was specifically made for Calypso devboards - I got a large batch of them custom-made for me two years ago. It is called FC-HDS4, originally commissioned for FC Venus project, and I have 100 of them in stock - and can easily make as many as needed. If you would like to make your board compatible with this headset, the jack needs to be 2.5 mm (not 3.5), TRRS type, wired as follows: Tip = EAR+, Ring = MIC+, Ring2 = EAR-, Sleeve = MIC-. (This pinout came from iWOW devboard, covered in 2023-11-15 OsmoDevCall.)

Is that pinout identical to those commonplace TRRS 2.5mm headsets used with mobile phone in the early/mid-2000s? If yes, we should migrate to it. If your pinout is different to those connonplace headsets, then we shouldn't implement something specific to just your headset. In the worst case, we can have multiple connectors in parallel and/or as placement options.

  • I see that you have a connection from RP2040 GPIO to GTM900 PWON control - good. Please add another such GPIO connection to GTM900 RST control. Both GPIOs will need to be configured as open drain outputs (OD emulation really, via output enable) in RP2040 firmware.

I agree, the RST signal should be routed to a GPIO in the next board version

  • UART connections: I see data lines from both UARTs, plus Modem UART RTS & CTS - good. However, GTM900 has DTR, DCD, DSR and RI modem control signals too, implemented via Calypso GPIOs, with the first two (DTR and DCD) following the tradition from TI themselves. These extra modem control lines are currently not connected to RP2040 GPIOs in your design - hence a regression from TI & FreeCalypso devboards.

We intentionally didn't want to add all those lines to keep the design simple. We do not aim to create a fully-fledged replacement for other existing boards.

If you are unwilling to add these connections, someone will have to do a little RE on GTM900 PCB to determine if there is a built-in pull resistor in either direction on GPIO3/DTR input.

I think we should do that (maybe roh?) and the add that pull-up or not.

Naming: the board you are designing is NOT a mere breakout, hence calling it such is disingenuous.

I agree the existing name is misleading/imprecise. We typically know of that distinction and for example differentiate our sfp-breakout from the sfp-experimenter board.

The board will not be called sysmo* as it is an OSHW design and hosted under the osmocom umbrella. Like SIMtrace or ngff-cardem, or the above-mentioned SFP boards.

My suggestions are:
  • Osmocom GTM900 evaluation board
  • Osmocom GTM900 experimenter
  • Osmocom GTM900 IO board
  • Osmocom GTM900 application board
  • Osmocom GTM900 USB adapter board

I don't have any strong suggestions either way.

Actions #56

Updated by falconia 3 months ago

laforge wrote in #note-55:

See https://www.raspberrypi.com/products/raspberry-pi-pico/ for all the plentiful information about the Raspberry Pi Pico (a kind of SoM for the RP2040).

Existence of docs about RP Pico changes nothing about the fact that your published PDF schematic drawing is incomplete and cannot correspond to a physically buildable board - hence if you do have a physical board built, then your published schem is not a complete corresponding source for it.

  • Iota audio output EAR- appears to be shorted directly to ground with a 0R at R38.

Is there an easy alternative?

If what you seek is a single-ended output, as opposed to differential, why do you need to connect anything to the EAR- leg at all? Just leave it unconnected, and use only EAR+ output leg, pretending that it is a single-ended output. You will get half the voltage swing of the originally intended differential output, but you won't be able to do anything better if you seek to drive a physical headset that expects a single-ended output. (My FC-HDS4 headset in contrast natively takes differential EAR output.)

[...] It is called FC-HDS4, [...] the jack needs to be 2.5 mm (not 3.5), TRRS type, wired as follows: Tip = EAR+, Ring = MIC+, Ring2 = EAR-, Sleeve = MIC-. (This pinout came from iWOW devboard, covered in 2023-11-15 OsmoDevCall.)

Is that pinout identical to those commonplace TRRS 2.5mm headsets used with mobile phone in the early/mid-2000s?

Please define "commonplace". I am not aware of there being any kind of universal standard in those days, instead different manufs adopted different pinouts. Motorola had one pinout (which is TRS, not TRRS), Openmoko extended it to stereo output with TRRS, but iWOW had a different TRRS (4-wire) pinout that is NOT stereo, but instead gives differential (rather than SE) output to the monaural earpiece. I adopted/copied iWOW's pinout for FreeCalypso.

If you are unwilling to add these connections, someone will have to do a little RE on GTM900 PCB to determine if there is a built-in pull resistor in either direction on GPIO3/DTR input.

I think we should do that (maybe roh?) and the add that pull-up or not.

In the case of iWOW TR-800, we know that there are no built-in pull resistors in either direction on any of exported I/O lines - but to find this answer, I had to fork over somewhere around $1200 (I don't remember the exact amount. it was back in 2020 summer) to the Chinese PCB RE company. But in the case of GTM900, we don't have any authoritative knowledge (guesses don't count) as to presence or absence of built-in pull resistors. Needless to say, I am not in a position to make a similar spend on GTM900 PCB RE - but if you would like to do such (because you seem to like that GTM900 so much better than TR-800), I can give you contact info for the Chinese PCB RE company I used.

The board will not be called sysmo* as it is an OSHW design and hosted under the osmocom umbrella. Like SIMtrace or ngff-cardem, or the above-mentioned SFP boards.

My suggestions are:
  • Osmocom GTM900 evaluation board
  • Osmocom GTM900 experimenter
  • Osmocom GTM900 IO board
  • Osmocom GTM900 application board
  • Osmocom GTM900 USB adapter board

I don't have any strong suggestions either way.

As long as the name begins with "Osmocom GTM900", I suppose it doesn't matter which of your suggested suffixes you use. I will probably refer to it as OsmoGTM900 for short, when contrasting it against FC boards. If you don't like OsmoGTM900 short name, please suggest a different short name that makes it easy to contrast your design against competing designs that are based on different design decisions and a different controlling party making such.

Actions #57

Updated by laforge 3 months ago

On Thu, Nov 16, 2023 at 06:32:30PM +0000, falconia wrote:

Existence of docs about RP Pico changes nothing about the fact that your published PDF schematic drawing is incomplete and cannot correspond to a physically buildable board - hence if you do have a physical board built, then your published schem is not a complete corresponding source for it.

I will not further respond to such comments here. You very well know about the existance of SoM - system on a module - boards in the industry for decades. Not only is that SoM in this case well-documented, but it also its full schematics are available.

If you believe that in your universe every SoM schematic shall be exploded into the schematic of the board
incorporating it, fine. But then please don't try to push such strange requirements on other people.

In the same line of thought you could require that somebody includes the GTM900 module schematics, which is
equally wrong. I've neve seen anyone incorporating 3rd party SoM / module internal schematics in an overall
schematic of the carrier of said SoM/module.

Please define "commonplace". I am not aware of there being any kind of universal standard in those days, instead different manufs adopted different pinouts. Motorola had one pinout (which is TRS, not TRRS), Openmoko extended it to stereo output with TRRS, but iWOW had a different TRRS (4-wire) pinout that is NOT stereo, but instead gives differential (rather than SE) output to the monaural earpiece. I adopted/copied iWOW's pinout for FreeCalypso.

After some digging I guess I'm referring to the OMTP headset pinout, see https://pinoutguide.com/HeadsetsHeadphones/omtp_headset_pinout.shtml - which is compatible to many Nokia, Motorola, Blackberry and Samsung phones. It seems that most other pinouts were 3.5mm and not 2.5mm?

I think we should do that (maybe roh?) and the add that pull-up or not.

In the case of iWOW TR-800, we know that there are no built-in pull resistors in either direction on any of exported I/O lines - but to find this answer, I had to fork over somewhere around $1200 (I don't remember the exact amount. it was back in 2020 summer) to the Chinese PCB RE company. But in the case of GTM900, we don't have any authoritative knowledge (guesses don't count)

You may seek authoritative knowledge, many others can probably live with a less authoritative answer obtained by more primitive means.

As long as the name begins with "Osmocom GTM900", I suppose it doesn't matter which of your suggested suffixes you use. I will probably refer to it as OsmoGTM900 for short,

fine with me.

Actions #58

Updated by falconia 3 months ago

laforge wrote in #note-57:

I will not further respond to such comments here. You very well know about the existance of SoM - system on a module - boards in the industry for decades. Not only is that SoM in this case well-documented, but it also its full schematics are available.

I sincerely apologize for failing to take the time to look at that RP Pico product more closely. In my error, I failed to realize that it is a SoM - I simply assumed that it was a "regular" development or reference board, and somehow thought that you were merely using that existing design as a reference, but actually putting an RP2040 chip on your own board. To me it somehow looked like your schem depicted a design where you were going to put the RP2040 directly on your board, but the process of design was left unfinished, with the unfinished schem published... I now see that I totally misunderstood the reality - I do see now that you are using the SoM as a component, and that your schem actually calls for such. Again, please accept my sincere apology.

Actions #59

Updated by falconia 3 months ago

laforge wrote in #note-57:

After some digging I guess I'm referring to the OMTP headset pinout, see https://pinoutguide.com/HeadsetsHeadphones/omtp_headset_pinout.shtml - which is compatible to many Nokia, Motorola, Blackberry and Samsung phones. It seems that most other pinouts were 3.5mm and not 2.5mm?

The pinout you linked to is for a stereo headset interface, with assumptions of (1) the active device puts out separate L and R audio channels and (2) the headset being plugged in has separate L and R earbuds. But a Calypso+Iota module or any other GSM-only device without music functions only has a monaural output, and the most appropriate physical headsets are those with only one earbud, usually inserted in the operator's right ear. (Why right ear? Neuroscience gives the answer: the speech processing center is strongly lateralized to the left hemisphere in most people's brains, which is connected to the right side of the body - hence the right ear has a more direct connection, with lower latency and lower BER, to the brain's speech and language processing center than the left ear.)

When I had my FC-HDS4 headset custom-made for FreeCalypso, I had to specifically ask for a monaural headset with just one earbud, plus an inline microphone. When mainstream manufs made Calypso phones in the past (Motorola C1xx, Pirelli DP-L10), they also officially supplied headsets with a single earbud - but they had TRS plugs, not TRRS, i.e., they worked with single-ended earpiece output. But the main EAR output from Iota is differential - hence a non-standard headset design with the monaural earpiece connected as a bridge-tied load across two pins is preferable. It appears that iWOW engineers back in 2004-2005 in Singapore had the same thoughts when they designed their DSK development board, as it came with just such a headset. I simply copied their design and their pinout, on the basis that it is the best option out of all pre-existing ones. But it is not compatible with what you are doing here...

Actions #60

Updated by Hoernchen 3 months ago

laforge wrote in #note-55:

I agree, the RST signal should be routed to a GPIO in the next board version

I really do not understand why a board that
  • can currently power cycle the modem using the mcu
    • unless that feature is bypassed via jumper
  • has a manual rst button

Now additionally needs rst by mcu, too?!

I would get rid of all of that except power cycle by mcu and that's it. The primary ngff experience was that reset was kinda completely useless there, too. No one needs 15 weird ways of maybe resetting something if one reliable way exists.

Actions #61

Updated by laforge 3 months ago

On Fri, Nov 17, 2023 at 01:46:01PM +0000, Hoernchen wrote:

I really do not understand why a board that
  • can currently power cycle the modem using the mcu
    • unless that feature is bypassed via jumper
  • has a manual rst button

Now additionally needs rst by mcu, too?!

You have a point. Let's keep it as-is.

Actions #62

Updated by mschramm 3 months ago

I'd really like to stop the headset/earphone discussion, as we have a working solution since over three years; see the various ticket updates above at all that time. Breakout version 2 has a working headset i/o.

Tested three different brands (see image), only one of them is somewhat branded (it came w/ an HTC HD2). All of them worked on the GTM900-breakout v2 as they do on T420 and X230 thinkpads, and with at%nfv=4 you can not stand a at%ctone=4 (authentication call tone) for a second and have pull off the headphones. It is still the same TRRS scheme as suggested and incorporated years before.

I don't see any point for leaving that solution.

Iota audio output EAR- appears to be shorted directly to ground with a 0R at R38.

You can find that detail already in version v2 since three years (its name there is R27). This is merely a footprint, its value is not adjusted to the real world.

This arrangement is likely to damage the Iota chip inside the GTM900 module

With R27=0R populated on v2, it didn't do so since ever brought into service; the EAR- was able to drive an earpice after R27 removal (and patch wires).

If what you seek is a single-ended output, as opposed to differential, why do you need to connect anything to the EAR- leg at all?

Because you want to load it with a same or similar load as on the used leg. Clearly a 0R is too much, let's take e.g. a 27R (or 47R or similar already in BOM).

some more on the audio path:

  • implementation of an audio CODEC IC is the lowest priority on that PCBA, only to ever allow digital audio on USB for firmware which can't do it itself
    • there is not the simplest passive audio mixer there
    • when the CODEC is placed, attaching a headset will change many impedances and hence audio levels at once, sources will source against each other
    • right now, either the headphone/mic socket or the CODEC can be populated w/o interfering each other unwanted
    • any code for CODEC support will gain from mainline Linux kernel code, but would be huge effort after all anyway

The first two or three v3 prototype PCBAs will get the 3,5mm TRRS socket placed and all resp. passives, and not the CODEC and theirs.

(1/2; I'll update on the i/o remainders)

Actions #63

Updated by mschramm 3 months ago

First two PCBAs of v3 populated

Actions #64

Updated by laforge 3 months ago

FYI, I've just imported an existing MIT licensed dual-USB-UART-firmware into the rp2040-playgorund.git/osmo-gtm900 code:

commit f4ab7935a9b5e9702216d76e5327731efda25f00 (HEAD -> master)
Author: Harald Welte <laforge@osmocom.org>
Date:   Wed Nov 29 13:58:00 2023 +0100

    osmo-gtm900: Import/merge dual-USB-UART code

    This is really just merging the codebase from
    https://github.com/Noltari/pico-uart-bridge/tree/master
    into the skeleton firmware we had for modem power on so far.

So if roh and/or mschramm want to test if that does something useful: go ahead!

Actions #65

Updated by laforge about 2 months ago

laforge wrote in #note-64:

So if roh and/or mschramm want to test if that does something useful: go ahead!

unfortunately it seems nobody had time for this so far, so I gave it a try. It works out of the box, as far as I can tell:

[1074074.932624] usb 1-2: new full-speed USB device number 7 using xhci_hcd
[1074075.085971] usb 1-2: New USB device found, idVendor=1d50, idProduct=aaa1, bcdDevice= 1.00
[1074075.085978] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1074075.085982] usb 1-2: Product: osmo-gtm900
[1074075.085985] usb 1-2: Manufacturer: sysmocom - s.f.m.c. GmbH
[1074075.085987] usb 1-2: SerialNumber: E661AC886328A127
[1074075.092709] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[1074075.093273] cdc_acm 1-2:1.2: ttyACM1: USB ACM device

ttyACM0 contains some kind of trace format, it seems:

RVT: Lost Message 04000035RVM: Created task nb  0x00000001RVM: Resumed task nb  0x00000001RVM: Resumed SWE  0x00010002RVM: SWE initialization successcreate_RVtasks: RVT (0x00010002) startedRVM: SWE START REQUEST 0x000A0004rvm.SweHndlr.resolve_t2_grouping(), SWE Not type 2:  0x000A0004RVM: SWE list built successRVM: trying to launch SWE 0x000A0004RVM: SWE memory bank allocation successRVM: SWE set info functions calledRVM: Created task nb  0x00000002RVM: Resumed task nb  0x00000002RVM: Resumed SWE  0x000A0004RVM: SWE initialization successcreate_RVtasks: FFS (0x000a0004) startedRVM: SWE START REQUEST 0x000A0010rvm.SweHndlr.resolve_t2_grouping(), SWE Not type 2:  0x000A0010RVM: SWE list built successRVM: trying to launch SWE 0x000A0010RVM: SWE memory bank allocation success
                                                                                                                                                  SPI : spi_set_info: try to init GLOBAL INFO SPI structure ... RVM: SWE set info functions calledRVM: Created task nb  0x00000003
                                                              SPI_task: InitializationRVM: Resumed task nb  0x00000003RVM: Resumed SWE  0x000A0010RVM: SWE initialization successcreate_RVtasks: SPI (0x000a0010) startedRVM: SWE START REQUEST 0x000A0020rvm.SweHndlr.resolve_t2_grouping(), SWE Not type 2:  0x000A0020RVM: SWE list built successRVM: trying to launch SWE 0x000A0020RVM: SWE memory bank allocation successRVM: SWE set info functions calledRVM: Created task nb  0x00000004RVM: Resumed task nb  0x00000004RVM: Resumed SWE  0x000A0020RVM: SWE initialization successT3PROXY TACHE DE DEV 0x00000003create_RVtasks: LCC (0x000a0020) startedRVM: SWE START REQUEST 0x000A0008rvm.SweHndlr.resolve_t2_grouping(), SWE Not type 2:  0x000A0008RVM: SWE list built successRVM: trying to launch SWE 0x000A0008RVM: SWE memory bank allocation successRVM: SWE set info functions calledRVM: Created task nb  0x00000005
                                                          KPD: InitializationRVM: Resumed task nb  0x00000005RVM: Resumed SWE  0x000A0008RVM: SWE initialization successcreate_RVtasks: KPD (0x000a0008)

while /dev/ttyACM1 is the AT command interface:

AT
OK
ATE1
OK
atI0
HUAWEI
GTM900

OK
at+cgsn
G26RAB1852202028

OK
at+cimi
999700000103010

OK

Actions #66

Updated by laforge about 2 months ago

Actions #67

Updated by mschramm about 2 months ago

laforge wrote in #note-65:

It works out of the box, as far as I can tell:
[...]

great, thanks!

A possible HW flow control has already been adressed in the USB serial library - OK.
Now, for burst_ind speeds, is it only a matter of another fractional divider?

Actions #68

Updated by fixeria about 2 months ago

laforge wrote in #note-65:

ttyACM0 contains some kind of trace format, it seems:
[...]

FYI, this is RVTMUX, which is well documented here:

https://www.freecalypso.org/hg/freecalypso-tools/file/tip/doc/RVTMUX

This repository has some tools to parse those RVTMUX traces and even send some debugging commands:

https://www.freecalypso.org/hg/freecalypso-tools/file/tip/doc/Rvinterf-tools
https://www.freecalypso.org/hg/freecalypso-tools/file/tip/doc/Rvinterf-logs

We may want to add references to this repository to the wiki page you just created.

Actions #69

Updated by laforge about 2 months ago

On Thu, Jan 04, 2024 at 08:11:36PM +0000, fixeria wrote:

FYI, this is RVTMUX, which is well documented here:

ah, thanks. It's not really very important to us, as we primarily want to use the GTM900 with OsmocomBB.

We may want to add references to this repository to the wiki page you just created.

It's a wiki and you have write permissions, so certainly feel free to add any information we have
there (to the Huawei GTM900 page, not to the OsmoGTM900 page, as it's part of the modem, not our
carrier board).

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)