OsmocomBB

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

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.

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.

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.

On 6/22/20, mschramm [REDMINE] <redmine@lists.osmocom.org> 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?

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.

• 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?

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.

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.

design has meanwhile moved over to rp2040 based design, see https://gitea.osmocom.org/electronics/osmo-small-hardware/src/branch/master/gtm900-breakout/GTM900-breakout-schema_v3.pdf

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.

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.

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

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.

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.

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.

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

laforge wrote in #note-55:

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

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

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.

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!

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

• added a related wiki page at https://osmocom.org/projects/baseband/wiki/OsmoGTM900
• allocated USB product code (0x1d50:0x6187) and updated firmwre with it

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?

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.

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