MEGAphone Cellular Modem Module

Okay, so next on the list of modules that we need to make is the cellular modem carrier.

I've previously used one of these for experimenting. They work great, and I was going to order one for working on the telephony software in the meantime, but they don't have shipping to Australia as a default option. And since I need to make one of my own, anyway, I may as well do that now.

Fortunately, the board is open-hardware (CC-BY-SA), so the schematics are available, which helps to save me a bit of time as much as anything else, as the actual wiring is not particularly hard.

1. Requirements Analysis

The only requirement that relates to this is:

Requirement 2.2.1: Cellular Module Carrier board that can accept an industry standard industrial cellular modem, breaking out all pins from the connectors, and provides a SIM card slot.

I'm of two minds as to whether to put the SIM card on a separate bay, so that it can be more easily exchanged, without having to pull the phone apart, as it's not that uncommon a task to need to perform. It probably makes sense to do so. For the SIM card slot, I'm using combined SIM + microSD card slots to save space. From a previous prototyping run I have a full reel of Molex 1041681616. While they are end-of-life there are still plenty in stock around the world, if you don't mind having to buy a whole reel like I did. If you don't need a whole reel, poke me on the MEGA65 Discord server, and I'm sure we can work something out. But more the point, by putting the SD card / SIM slot on a module of its own, we can easily switch to different parts -- that's part of the point of making this thing modular!

Otherwise we just need to look at the pinout of the EC25 Cellular Modem that we are using as the reference for the Mini PCIe form-factor that we are supporting.  It's not hard to find a diagram like this:

 

Basically we have 52 pins, if we want to expose them all.  USB_DM and USB_DP should have 90 Ohm differential routing for USB signals, but the rest are relatively low frequency signals.  I'm not going to attest that USB will work for certain on this, because we don't strictly need it, although I would like to connect it to the Pi CM4 Module that I am planning, so that the Pi has direct access to fast internet in a way that Android running on the Pi will understand.

Let's now look at the EC25 Hardware Design Guide to see if there is anything special we should know for this module. Later, when we make the carrier board, there will be more things we need to care about, but for now, it's just whether we need any passives etc, and perhaps to know which pins are 1.8V or 3.3V IO domain. Okay, it looks like all pins are 1.8V IO domain, except for SIM card, which is auto-switching

In terms of main power supply, it requires 3.3V - 4.3V, designed for running directly from an LiPo cell. But as we are using LiFePO4 with a slightly lower voltage, we will be feeding it from one of the DC:DC converter modules I have designed.

Nothing jumps out as needing specific handling on this module, unless I wanted to include voltage conversion. But I don't think that's necessary, as the cellular modem will connect to the power management FPGA, not the main FPGA, and we can just set the voltage of that FPGA's IO lines to 1.8V... Except the FireAnt uses 3.3V for VCCIO, and the Efenix FPGAs can only do IO at VCCIO on a given bank.

I think it's best to leave the level conversion off the module, but I'll make a final decision as I progress. But either way I'll need to design the level conversion strategy. That strategy will differ depending on whether signals need to be bidirectional or not.

Lets look at the signals we have here, so that we can understand the requirements. These are described in this quectel document.

WAKE# - Open collector (output) used to wake host

COEX_UART_RX - Input

COEX_UART_TX - Output

UART_RX - Input

UART_TX - Output

RI - Output

UART_CTS - Input

UART_RTS - Output

DTS - Input (sleep mode control)

PCM_CLK -- Bidirectional

PCM_DOUT - Output

PCM_DIN - Input

PCM_SYNC -  Bidirectional

USIM_VDD - N/A - Direct connect to SIM card

USIM_DATA - N/A - Direct connect to SIM card

USIM_CLK - N/A - Direct connect to SIM card

USIM_RESET - N/A - Direct connect to SIM card

W_DISABLE# - Input (airplane mode control)

PERST# - Input, active low, "fundamental reset control"

I2C_SCL - Output (so this is for an I2C interface controlled by the modem, typically for talking to audio codec ICs etc)

I2C_SDA - Bidirectional

USB_DP - N/A - Direct connect to USB. Requires 90 Ohm differential signalling.

USB_DM - N/A - Direct connect to USB. Requires 90 Ohm differential signalling.

LED_WWAN# - Open collector, active low LED indication.

So tallying that up, we get:

Input only - 7

Output only - 6

Bidirectional - 3

Open collector outputs - 2

N/A - 6

Total - 24

So the single-direction signals we can likely handle with something like a TXG404x.

Those parts come in either a 2 signals in each direction or 3 in one, 1 in the other direction variant. Both have output enable lines that allow for tri-stating outputs, which can be used for managing bi-directional lines.  For the signals with fixed directions these will be super simple. For the bidirectional signals, two of those are for the PCM audio interface, and require the same direction. So having a simple way to generate inverted output enable signals for a pair going in both directions should work.  The third bidirectional signal is actually that I2C interface for an audio-codec IC, which we can ignore.

So it sounds to me like we can get away with a bunch of TXG404x's on the PCB under the cellular modem.

Oh, blast. The TXG404x's are brand new, and not yet in stock anywhere. So maybe we can use an 8-channel TXV0108RGYR instead. In principal one each for the mono-directional line blocks will be sufficient -- plus some bidirectional solution for the PCM audio signals. We can actually use a 3rd one of these for that, as they have a direction control pin, so that will be nice and simple. They are only about US$1 each, so the cost is not too bad, in return for reduced BoM.

(I did also think about fixing the PCM signals in one direction, but I really want the modem to accept the signals from the FPGA, but I've seen problems with the firmware on these modems, where some modes only work if the modem generates the signals.)

Another advantage of the TXV0108's, is that they isolate when VCC is low on either side of the conversion. Thus I can use these to provide the isolation when the cellular modem is powered down, i.e., to prevent back-current. 

2. Schematic & PCB Layout

I am working on the schematic layout and PCB layout together, as the order of pins on the voltage level converters makes a significant difference to the PCB layout effort required. This is because I'm aiming to keep to a 2-layer board to minimise cost. It feels like it should be possible to achieve.  I should probably route the USB lines sooner rather than later, so that I have space etc for them to be properly differentially routed.

For the USB signals, I found this page that talks about how to do it in KiCad. Our biggest challenge that I can see for this so far, is that they should be routed over an unbroken ground plane. But the USB pins are kind of in the middle of the mini PCIe connector, and since we are aiming fora 2-layer board here, that's going to cause a bunch of routing pressure as I try to keep other signals (and power rails!) from crossing that zone.

I've managed to clear the routing for that, and also found a video that describes how to do differential routing of USB signals in KiCad:

Which pointed me to this Digikey impedance calculator, which I have then filled out with what I believe to be the right values:

So it is telling me that the traces need to be 1.3488 mm wide, if they are 0.2 mm apart, to get the required 90 Ohms resistance with a 2-layer stack-up.

That's quite wide. But apparently that's the trade-off of using a standard thickness 2-layer board:

 

The only problem is that when I tell KiCad to route the differential pair, and set that track width, it still draws the tracks with a width of 0.2 mm, rather than the 1.3488 mm I asked for.  Hmm.. With a bit of mucking about, it now seems to want to draw the correct width. But my next problem is that the pin pitch on the mini PCIe connector is much less than 1.3488 mm, so I'll need to have some very short traces to get to having enough space to have the full-width traces. 

But before I can route them, I think I need to get the module footprint organised, so that I have the opposite end of the trace to anchor the big fat traces onto, and then just do the short narrow terminations onto the mini PCIe connector. For that, we need to know the number of actual pads that we need.  We have 24 signals we identified above, plus there is power and GND and a hand-full of others, so I think I'll allow for 36 pins, just to be totally safe. There will be plenty of room for these, because the cellular modem modules themselves are quite long.

(These extra pins also allow me the flexibility to supply a power on/off signal to the module, if I decide to put the 3.3V and 1.8V regulators for the cellular modem on the board. I'm leaning towards doing this, as it will make it a simple board that can be fed from VBAT with a 3.3V power on signal, and have just 3.3V IO to otherwise talk with it. That will all make the final host board much simpler.)

So let's look at it so far, without the power regulators:

On the PCB, we can see the amazingly fat USB traces required to try to get 90 Ohm impedance on the 1.6mm 2-layer PCB:

I guess I should add in the DC:DC converters for 3.3V and 1.8V, and finish hooking it all up.  Here's how it looks with those:

Now what's missing is the footprint for the clip to hold the full-length mini PCIe modem in place, and the remaining standard silk-screening to indicate the module, its version and git repository.

For the clip, we can use something like a MM60-EZH059-B5-R650. From memory the R650 is the height that the clip stands above the board. We need to use the matching footprint for the contact end, as well, i.e., with the same height. Like one of these: MM60-52B1-E1-R650.

Okay, I have footprints and 3D models for those, so I'll substitute them in, to make sure they are exact fits for the existing connector, which looks to be the case. The main issue now is making sure I place them exactly right. It took some digging around until I found a drawing that shows the required relative placement.

Everything now looks right, and I have added all the silk-screen self-documentation, jumpers to let me cut the power from the on-board regulators if they prove to be a problem (and add pads to the edge to allow those rails to be supplied externally -- or for things off the module to use the power from this module.

Also, I've double-checked that the power supply components that sit under the module are lower than the bottom of the module:

I need to check with the EC25AU module I have here to see if it hangs below to far. If it does, I'll have to use the 850 rather than 650 height code mini PCIe connector parts.

But for now, it's all looking good, and I have it done just in time to add it to my current PCBWay order.

I'll check that this module has been approved when I get up in the morning... and it passed! And in time for me to combine with my existing order to save shipping :)
 

3. Requirements Verification

Okay, so let's just double-check that we have met all our requirements:

Requirement 2.2.1: Cellular Module Carrier board that can accept an industry standard industrial cellular modem, breaking out all pins from the connectors, and provides a SIM card slot.

Okay, so we have the mini PCIe connectors for industry standard industrial cellular modems, and we also have all pins broken out. What we don't yet have is the SIM card slot, which I'll address in another post. So we can't quite retire this requirement just yet.