I've been busy working on the schematic and PCB design for a bunch of the modules for the MEGAphone lately. The first batch of those I had sent off for fabrication by PCBWay, and they have finally arrived. So let's have a look at what we have:
Well, that's a bit hard to see what's going on, so let's look at each in turn. My lighting here isn't that great right now, but it should be enough that we can identify each PCB from it's packing label.
First we have the audio jack PCB:
Then the high-efficiency DC:DC converter:
The Audio Codec board:
SIM and SD-Card carrier:
Cellular modem carrier:
MPPT Battery Charger board:
Low-current DC:DC converter module:
And finally, the MEMS microphone carrier board.
So let's look at where this gets us to in terms of the milestones:
Milestone 2.3.4 Battery management and energy harvesting module to
allow USB-C, integrated solar and external 12/24V vehicle battery power
sources, and efficient management of the integrated rechareable battery: Fabrication -- done -- see photos above
Milestone 2.5.4 Internal microphone and speaker module: Fabrication -- done -- see photos above
Let's see how this looks on the block-diagram, to get a sense of the overall progress represented by this work:
Not bad -- and as we can see, some of these modules are reused in multiple places, so we have knocked off most of the orange boxes, too.
The main difference between what was planned and how I have progressed is that I've tended to further break down some of the modules, to make their designs simpler.
From here, I'll decide whether the next step is to assemble these modules, or whether I'll do the PCB design for more of the remaining modules on the schedule. Probably a mix of the two. Certainly I can prepare the bill of materials for each of the modules I've already designed, and order those parts ready for assembly, since they will take a week or so to arrive, in any case.
This post has turned into a bit of an epic, as it turned out to have a couple of modules (solar MPPT tracker and prioritised power input selection and over-voltage and reverse-polarity protection) that took quite a bit more effort to get right.
So, we have a DC:DC regulator. Now we need a way to get energy into the battery. This module has a few more requirements, because of the different energy sources we intend to support.
1. Requirements Analysis
There are also a few requirements that we have to keep in mind, even though this module isn't directly responsible for satisfying them (in italics):
Requirement 1.1.2.3: Proof-of-concept charger module based on a given USB-C power delivery module (no need for data). Requirement 1.1.2.4: Power isolation mechanism to allow conflict-free operation of the USB-C and alternative power inputs to the MEGAphone (back-flow and over-voltage protection, for example) Requirement 1.1.1: Integrated LiFePO4 or other similarly safe and robust chemistry battery cell. Requirement 1.1.2.1: Integrated battery capacity of at least 30Wh. Requirement 1.2.2.1: Means of accepting (including connector) dirty DC power between ~9V and ~40V using a MPPT to maximise efficiency with a solar panel. Requirement 1.2.3.1: Means of accepting DC power from integrated solar panel at input voltages of 2V to 20V with a MPPT.
So, we have to accept power from USB-C, solar, and "dirty DC" -- which itself might be a solar panel. I'm going to break this down into several modules, to make my life easier.
Requirement 1.2.3.1 is a bit annoying, because the 2V I have specified is not commonly supported. We can resolve this problem by using readily available panels that have a nominal voltage of 6V, e.g.:
Those 55x70mm panels are 0.5W, and have a nominal voltage of around 6V. It should be easy enough to tile four of those on the rear, to give about 2W solar charging capacity on-board. Those could be put in two parallel strings of 2 panels to yield ~12V.
But remember that we also want to support external panels that might have higher voltages. Ideally, we'd allow upto ~40V, so that this module could also accept power from automotive sources.
So let's now look at the options for MPPT ICs. We don't need high current output, as the battery is only 30Wh, and charging in 1 hour would require 10A, so probably "a few Amps" would be tolerable -- but if we can, I'd like to support fast charging in an hour or two if a high-current source is available.
These various requirements make the design of this module more complicated. Fortunately, I'm not the first (or last) person to want to do this kind of thing.
For example, there is this video and github project for exactly the kind of thing I want:
It's even been designed using KiCad, which means I can adapt it easily. I hadn't planned on putting a little display to show the battery charge state, but I can always leave it off -- or if space and topology of the boards allow it, I could still include it.
The unit itself is fairly small. It does use an ESP32, which is possibly a bit of an over-kill, but if that's the cost of making this module more quickly, then it's probably worth it, as this is one of the most complex modules that I'll need to design.
I'd likely still redesign the board to fit the castellated module system, but that would be the only change I'd make, to minimise risk, I think. Oh, except that I'll also need to change the battery charger part of it to handle a single-cell LiFePO4.
That project uses a BQ24650, which does apparently support LiFePO4 cells. The battery charge voltage is set through a voltage divider:
This makes it super simple to change the output voltage of the charge circuit. The question is what voltage to charge to.
ChatGPT claims that 3.6V should be ok, but may lead to damage over time if that voltage is held after the battery fully charges. 3.45V -- 3.55V on the other hand should allow the battery life to be much greater, but at the loss of ~10% of the battery capacity.
As we are using a 10Ah LiFePO4 cell with a capacity of ~36Wh, that would still leave us >30Wh, which is above our requirement, so it sounds like a good trade-off.
Looking at the schematic and ESP32 firmware, it also looks like it is possible for the ESP32 to be able to turn the charger off, and also to measure the battery voltage. Thus I could in a later version update the ESP32 firmware to do that, and then allow charging to the 3.6V 100% level. But we don't need to for now.
So back to the R2 & R1 calculation, we want V_BAT=3.5V, so:
3.5V = 2.1V x ( 1 + R2/R1)
Thus 1+ R2/R1 = 3.5V / 2.5V = 1.4.
Keeping R1 at 100K in the module, we just need to change R2 to 140K. That's a standard size, so no problem there.
Otherwise the only requirement adjustment forced on us by this module is the maximum input voltage is ~28V, rather than 40V. This means that while we could easily accept 12V car power and 20V USB-C power, we couldn't safely accept 24V truck power, as the voltage on trucks typically peaks around 30V. It's pretty close, and I suspect that it would work in practice. So we'll live with it.
2. Requirement Variations
So let's summarise our requirements relaxations that we have applied:
Relaxation of Requirement 1.2.2.1: Maximum input voltage reduced from 40V to ~28V. Impact: (1) 24V truck systems may peak out of range when alternator charging. (2) Some larger solar panels may be out of spec. However, given the ~30Wh battery size, this should not be a problem. Impact acceptable.
Relaxation of Requirement 1.2.3.1: Minimum solar panel input voltage increased from 2V to 6V. Impact: Some very small panels, especially those consisting of few cells in series, no longer in specification. However, small panels (eg 55x70mm) are readily available with 6V MP voltages. Thus the impact is acceptable.
3. Solar MPPT / Dirty DC Input & Battery Charger Module
Those changes to the requirements have been recorded in the repository, so now we are good to go with adapting the module to fit one of our modules.
Let's list our planned changes:
1. Change board outline to appropriate sized castellated module.
2. Add castellated pads for VBAT and GND_BAT. This will be how battery power reaches the rest of the system.
3. Route ESP32 UART RX and TX to castellated pads to allow querying and control of the module in the future (e.g., to ask battery charge level, and charge system status).
4. Route 3.3V rail from charge source (not from the battery) to castellated pads, so that any galvanic isolation for the UART can be powered from the charge source, so that when there is no charge source, the MPPT charger is fully depowered, so that it doesn't discharge the battery.
5. Route LOAD_ENABLE and VCC_LOAD pins to castellated pads, to allow for a switchable load at VBAT. Not sure that we will need to make use of these, but it seems silly to not make them available.
6. Route charge source voltage to castellated pads instead of a terminal block.
I think that's it -- It really is a testament to Bytesizedengineering in their design of this module, that it has pretty much everything that I need (and then some). I was hoping to find something like this, as it is saving a lot of time and trial-and-error.
We will, however, also need another module to address Requirement 1.1.2.4. It looks like the LM74700-Q1 with an external MOSFET is a good approach here, as they have losses of only ~40mW on input, and disconnect the power source when current tries to flow in the reverse direction. We'll need one for each input, so three replicates of that module, which is fine -- it's another advantage of the module based approach.
Okay, so that's everything we need to know right now, and I can dive in to adapting the MPPT tracker... except that I need to update KiCad first, because it was created using a newer version.
A week or so has passed, and a few things have happened in the meantime:
1. Zach, the author of the module I am looking to adapt kindly replied to my email asking about licensing of his design, and has indicated that it's GPLv3, which is good, because that's what I'm using for this repo as a whole.
2. Zach also indicated that it has some bugs and problems. I'm hoping to learn a bit more about that, so that I can update the module if necessary. But for now, I'm working on the assumption that it works well enough for what I need.
So now I can easily play around with what size module I think I need, and if it turns out wrong, or has the wrong number of pins, I can easily generate a new one.
Okay, so I'm making some progress, and currently trying to work out how the power supply to the various ICs on this module work. There are several, and they need 3.3V, but I can't yet see where that comes from. Ah, it comes from the AP63203 that is powered from the input source, i.e., the ESP32 and friends will only power on if there is a DC source. So that's good.
Then as I've dug deeper, the ACS712 current sensors seem to need VCC=5V,
not the 3.3V they have been given in the design. But it seems that people have found them to work with VCC=3.3V. Resolving this is tricky, as it will output a signal of up to VCC, so giving it 5V will mean I need to add a level converter. Conversely, feeding it on VBAT will mean that it can go below 3.3V. But as it's only a current sensor for power input and charge output, maybe that's tolerable: It will only be able to mis-behave if VBAT is too low, but we can measure VBAT directly on the ESP32, so if VBAT is low, but the ESP32 is on, we can just make sure the ESP32 firmware tries to charge the battery in that case.
The ACS712 might be interesting to have elsewhere in the system, because it would let us measure the current draw from the battery to monitor power better, but that can wait.
So back to this module: The ACS712 can be powered from VBAT in the first instance, and if it proves to be a problem, I'll deal with it. I'll route the VCC lines for the two ACS712s to a pad on the module, so that this can be done off-module if required.
The ACS712 comes in 5A, 20A and 30A sensing versions. With VCC=5V, the 5A version will reach 3.3V on its output only at >= 4A, while for the 20A version it will be > ~7A, or for the 30A version > ~12A. So one option is that we just make sure that the thing never gets more than that level of current fed into it. But that's hard to force. But we could just put a 3.3V Zener diode to clamp the voltage at 3.3V, to make sure that the ESP32 doesn't get fried.
For the battery charge current side, we can set the charge current limit using RSR1 according to the BQ24650 charge controller's datasheet. If we limit it to 4A, then we will keep the ACS712 sensing the battery charge current <= 3.3V, which avoids the need to clamp the output of that ACS712.
Now, because the LiFePO4 battery is ~3.6V max, and assuming that the BQ24650 isn't horribly inefficient, and that it requires an input voltage on the panel/DC source >5V, then the current flowing through the input ACS712 must be lower than that of the output one. And if the output one is safe at 4A, then the input one will be, too.
So all up, this means that we can charge the battery at up to 4A, for a total charge time of ~2.5 hours in the ideal case, without needing to clamp the outputs of the ACS712. That would correspond to a charge rate of 4Ax3.5V = 14W, which feels good enough.
So the question is whether we need to provide a 5V supply for those ACS712's, or just take the chance with 3.3V. I could add an AP63205 to provide the 5V that they need. Hmm... Let's just follow the Wisdom of the Internet (tm) and run them on 3.3V, but provide a separate pad for their VCC, so that by default we can connect them together, but can separate them and provide an external 5V source if required.
I've spent the last few hours mashing everything around to fit in the module, and then dealing with design rule violations in KiCad, to make sure that I haven't messed anything up. There were a lot related to silkscreen stuff, a few of which are hard to resolve due to components with pads that intersect their own silkscreen elements. But there are less than a dozen of those now, so I can easily see if there are real problems.
Here is how it looks now:
The large oval and hole-throughs is for the ESP32 module that it uses. This also means that we need to use the cut-out to allow the hole-through pins of the ESP32 to clear the carrier board PCB. In other words, the ESP32 will sit up above the carrier board, rather than just having components in the cut-out behind the module (though it has a few components on the reverse side, too).
The presence of components on both sides of the board will make it a bit trickier for me to assemble. I'll likely reflow the main component side using a hot plate, and then hand-solder the small number of components on the rear-side. If I got a fancy reflow oven I could use high-temperature solder for the components on the main side, reflow that, and then flip it over and use a lower-temperature solder for the reverse side and reflow that below the melting temperature of the solder on the main component side, so that nothing falls off.
But before I am ready to send the board off for fabrication, I want to do my usual thing of adding component values and part names to as many of the SMD components as possible, to make it easier to field repair or scavenge for parts in the future.
In the process of that, I have found that there was no part number identified for the dual-MOSFET. It looks like one of these should work.
Okay, noted that, and added all the silkscreen annotations. Hopefully I haven't missed any. Here is the result:
4. USB-C Charge Input Module
So the next cab off the rank for this one, is the USB-C charge input module. I'm planning to use the cheap-off-the-shelf USB-C Power Delivery Boards available everywhere online, e.g.:
The exact layout of these modules seems to change with the day of the week, and the ones I have here look similar but not identical to any of those. This includes the exact positioning of the power output pads, which is really annoying.
The ones I have here are 11x17mm, with 1mm extra over-hang for the USB-C connector. But I've seen others as large as 13x27, so I should probably try to make the module allow for this variety in size, even if the actual module I design takes only the exact model I found. As there are no other parts on the module, it won't be hard for people to redesign.
Importantly, they aren't even standardised on whether the + and - terminals are on the left and right. So apart from making the module big enough, there's no real point in me trying to make it accept the different flavours of these things. But even so, I'll do something fairly simple, in that I'll make the pads for it long and wide, so that some random selection of these things will work on it. They all have hole-through for the power out, which can be fairly readily tacked down onto tinned pads on the module, so the pads on the module don't need to be precisely placed. I'll go over this more when I get it fabricated and assemble it using the modules I have here.
So apart from the topological angst, this module is super simple, as it only needs two pins: Power out and GND. There really is nothing more to it, and this is the result:
On the PCB layout the huge pads I have created are quite obvious. The white guide lines on the silkscreen are there to help get the module correctly centred and straight, so that if the USB-C port has to fit through a hole in a case, it can be lined up easily.
This actually brings up an important point for these castellated
modules, in that the ones with connectors on the edge of the PCB have to
be positioned accurately on their carrier. In practice this probably is
easiest done by inserting the edge connector through the case with the
carrier board under it, and then solder tacking one or two pins down, or
failing that, taping them together, so that they stay in relative
position during soldering. If doing it that way, I'd strongly recommend
soldering just one pin, and then making sure it's still correctly
positioned while it's easy to deal with.
5. Power Source Isolation Module
I thought I had written up some notes somewhere on how to deal with this elegantly. But apparently not. Anyway, the problem boils down to accepting power via USB-C, the solar/dirty power input (6V -- 30V) or the internal solar panel as fall-back.
After having a chat with ChatGPT about it, it looks like something like the https://www.analog.com/media/en/technical-documentation/data-sheets/ltc4417.pdf might be a good option -- it allows selection between three power sources, with separate under and over voltage thresholds for each, including prioritisation. It accepts inputs from 2.5V to 36V, so that all sounds good so far. Let's look at a typical application for this IC:
So basically the IC senses the input voltages, and then picks which external set of MOSFETs to turn on. It also provides output signals that let something else check which voltages are currently valid, and thus allow it to infer which source is being used. This will be handy for indicating charge status, and showing the user which source is being used for charging, and which other source(s) could be used for charging if required.
The IRF7324 MOSFETs that they recommend are a problem, however, as their breakdown voltage is only 20V. We need >30V, ideally >40V or higher, just to make sure.
The datasheet recommends the Si4909DY as an alternative when higher maximum voltage is required. So we should probably use that.
We do have another problem, though, in that if the input voltage spikes, e.g., from automotive power sources, then we can still fry things. A Transient Voltage Suppression (TVS) Diode can help us with short spikes, by routing them straight to GND. For longer duration spikes (and also for the shorter ones) we might want to have an N-channel MOSFET that we activate when we are over-voltage via the Zener.
For example, to keep the MPPT charger comfortably below 28V, we could use a BZX55C27 with a 10K resistor to provide 0.1mA of current to switch an N-channel MOSFET to clamp the power rail to GND, which would then cause excess current to flow, while also reducing the output voltage until something like a PPTC self-resetable thermal fuse kicks in and reduces the voltage and current that passes through it.
We should only need all that on the dirty DC / external solar input, as USB-C is well-behaved, and the internal solar panel has an open-circuit voltage <10V.
So let's start piecing the schematic together for this. I've laid out the schematic with the MOSFETs and the selector IC. But I need to work out the resistor values for the selector logic. I also need to make sure that the priority order is right. I can safely use the same resistors for all three, allowing 5V to 28V. That said, increasing the minimum voltage for the dirty DC a bit might make sense, if it is using a large panel, and gets pulled down to 6V or so, it might not be very efficient. But I think I'm overthinking things. Also, there is great advantage in having common resistor values to ease assembly etc.
The under and over voltage comparators compare to 1V, so we need a resistor ladder that results in V_UV = 1V @ 5V, and V_OV = 1V @ 28V. I ended up messing about with a little spreadsheet to find values that are close enough. It looks like R3 : R2 : R1 = 246 : 51 : 11 gets us V_UV = 1V @ 4.97V, and V_OV = 1V @ 28V exactly. So let's scale those up. 246K, 51K and 11K are all common values, so we'll simply use those.
So this is what this part looks like:
So that's that part. Let's now turn our attention back to the input spike protection on the dirty DC. We can use a Zener diode to detect when the input voltage goes >28V. If we then put a resistor below the Zener, we can feed its output into the gate on a Thyristor, which is a bit like a sticky MOSFET transistor. It we put the Thyristor between the input voltage and GND, it will crow-bar the input rail to GND if the input voltage climbs above 28V. A pull-down resistor on the Thyristor's gate will help prevent it triggering erroneously. If we then put a PPTC resetable fuse in place, when the Thyristor triggers it will activate, and everything should come to a grinding halt, instead of letting the smoke out.
Okay, except that this idea has a problem: The resetable fuses have a really slow activation time -- like ~30 seconds. So instead let's look at having an N-Channel MOSFET that allows the power in normally, then use the Zener diode to develop a gate voltage to switch the MOSFET to isolate the power from the thing. Then we just need to have a Zener and MOSFET that have the maximum voltage tolerance possible.
Annoyingly there is no model for the IFP067N20NM6ATMA1 in either digikey or snapeda. Did I mention that I hate having to make footprints and symbols myself? Fortunately mouser.com seems to have one.
Okay, so for the TVS/Zener diode, it looks like a SMM4F24A-TR should work. It has a threshold voltage around 24V, add the 3.5V gate voltage for the MOSFET, and it should start switching the MOSFET on to disconnect the power source at around 27.5V.
Well -- after all that, I've had to redesign it somewhat, when I realised that the MOSFET needs more sophisticated control. I decided to try out Grok 3 Beta in the process, and was quite impressed at its ability to look at just a photo of my schematic and critique it. It wasn't perfect, but it was a considerable help at designing the MOSFET-based over-voltage protection circuit.
Here's how the whole thing looks now:
The top-half is the prioritised input selector, while the bottom left part is the over-voltage protection for the dirty DC input, so that it can handle "load dump" conditions etc on automotive power, for example, that can spike up to 60V or so. I've designed it so that it should tolerate 200V. Basically if the voltage gets near 28V, it will disconnect the negative terminal using an N-channel MOSFET.
After that I realised that I also need to add reverse-polarity protection -- which will basically work as an inverted version of the over-voltage protection, but with a P-channel MOSFET. But this is tricky, because P-channel MOSFETs have a higher resistance when conducting, which means more heat generation. The SQJ457EP-T1_GE3 looks possible, and would generate ~0.5W of heat when 5A flows through it, and costs less than $2.
So now it's time to lay out the PCB. Getting the components laid out is the first part, then we need to know which signals we need to expose on pins, which in this case is:
So that's 11 pins. I'll make a module with a few extra pins, just to make sure, since it's a little bit of mucking about if I discover I need extras after -- but not too much, since I made the procedural module footprint generator. Then we just need to know the size of the cut-out area.
Except that as I went to look at the size, I realised that I was missing a few 3D models for components, and when I added in a couple of those, I found they were either wrong, or for parts that weren't actually available. That's the peril of using AI to help design it :/ It'll be fine, but it does mean I won't get it done tonight.
Well, it's been quite the slog, but I now have the PCB layout finalised:
6. Solar and External Power Connection Module
Whew! I'm glad that the remaining module for this set of requirements is
super simple -- just a connector for the battery (but I'll probably
throw on the connectors for the internal solar panel, as well as the
external dirty DC / solar power. I'm currently undecided on the best connector for that. Maybe I'll just make it a bog-standard DC barrel jack, the same as on the MEGA65, so that you can charge the MEGAphone using a MEGA65 power supply as well. But part of me would like to have something a bit easier to adapt a solar panel onto. But probably all the good options are a bit physically big, even for the MEGAphone.
For the DC barrel connector, I'll go for something compatible with the MEGA65 power supply, just for commonality and convenience. While I'm at it, I might have a go again at finding the connector for my Librem 13 laptop, whose connector got damaged on a flight when someone tripped over the cable. I emailed Purism to ask them the exact part number, since I'm sure it's an off the shelf component, but didn't ever get a response from them. I just opened the laptop up again now to check the part for markings -- but it has none. I did in the process, however, discover that it's the power supply plug rather than the jack in the laptop that is faulty -- so that's a much easier repair.
(I also had a look at one of the USB-C PD modules I'm planning to use for the MEGAphone, and it looks like there is space enough there, if I file out the connector cutout on the case, and file down a positioning lug for the old barrel jack, and make some other retainer for it. Tempting! But that's a squirrel that I'll be ignoring for now.)
As expected, this board was fairly quick and easy to do, because of it's simple nature:
7. Internal Battery Connector
This is an even easier one. We just need a 2-pin screw connector or similar to anchor the unterminated leads from the internal battery, which could be fairly fat copper. The main nuisance is that such screw terminals are quite tall, but we should be able to accomodate them somewhere, even if we need a cut-away on the stacked PCB above it.
There really isn't much to say about this. The board is just a convenient way to mount a connector.
8. Requirements Verification
So
that's the last of the boards that we need to satisfy these
requirements -- but let's make sure that we have everything covered off:
Requirement 1.1.2.3: Proof-of-concept charger module based on a given USB-C power delivery module (no need for data). -- Satisfied in 4. USB-C Charge Input Module Requirement 1.1.2.4:
Power isolation mechanism to allow conflict-free operation of the USB-C
and alternative power inputs to the MEGAphone (back-flow and
over-voltage protection, for example) - Satisfied in 5. Power Source Isolation Module Requirement 1.1.1: Integrated LiFePO4 or other similarly safe and robust chemistry battery cell. -- Satisfied by 7. Internal Battery Connector Requirement 1.1.2.1: Integrated battery capacity of at least 30Wh. -- Satisfied by 7. Internal Battery Connector (as it can take a massive battery) Requirement 1.2.2.1:
Means of accepting (including connector) dirty DC power between ~9V and
~40V28V using a MPPT to maximise efficiency with a solar panel. -- Satisfied by6. Solar and External Power Connection Module and 3. Solar MPPT / Dirty DC Input & Battery Charger Module Requirement 1.2.3.1: Means of accepting DC power from integrated solar panel at input voltages of 2V6V to 20V with a MPPT.-- Satisfied by6. Solar and External Power Connection Module and 3. Solar MPPT / Dirty DC Input & Battery Charger Module
In short, we have covered all of the requirements with this set of five modules -- even though they are all grouped as a single module in the milestone. Oh well. At least they are done. The MPPT and power input selector and over-voltage / reverse polarity protection circuits are actually the two modules that scared me the most in this whole project, as my expertise is really in digital systems, not this analog power-electronics world. But I guess I can't really relax until I've built them and confirmed that they work properly.
The schematics are all in the modules/ directory in the source code repository, as usual.
In the previous post I designed the cellular modem module. However, the requirements for the device include having a SIM card, which I had elected to put on a separate module, so it's time to make that module now:
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.
It shouldn't be hard to do.
It'll be an edge-mounted module, which won't be a problem since I added support for edge-mounted modules into my procedural footprint generator.
I also know the single part that needs to go on the module, i.e., the combined SIM and SD card slot. When I made the last prototypes I couldn't buy them singly, so ended up buying a whole reel of 1,200 pieces -- and I still have 1,194 of them left, so that's what I'm going to use! But if others can't source the same part, then they can design a module that takes a different part -- that's part of the benefit of this modularisation approach!
The parts I have are Molex 104168-1616's. Unfortunately SnapEDA doesn't have a model for it. Mouser does have a 3D model for it, but no footprint or symbol. I have a vague recollection that I made a footprint for it at some point, but I don't remember for sure, or where I would have put it.
Okay, I have created a PCB symbol and footprint now. The footprint I have verified against the 3D model to make sure that everything lines up, which it does:
So let's lay it out now, with the 8 pins for SD card and 8 for SIM card, and GND. So that's 17 pins, plus we'll have a dummy for power. So this is what the result looks like:
Now to pop that into the PCBWay order, if I'm not already too late.
So that closes out this requirement:
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 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:
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.
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.
In the previous post, I set about designing and laying out the high-current (2A) DC:DC converter for the MEGAphone. For draws of 10mA, that should still be 92% efficient across the plausible 2.6V to 3.6V battery voltage range. That's probably good enough.
Of course when I started looking to see if there were any options for even better efficiency at lower current levels, I found this one:
It's possibly even more efficient over the whole current range:
But what's really interesting, is that it doesn't have a thermal pad underneath it -- i.e., this thing would be way easier to hand assemble -- especially given that it also requires fewer passives. That would also allow the module to be physically smaller. They even include a sample layout, which I was silently a bit annoyed that the other one didn't:
So all up, this looks like a good option to use instead of the other design, as even at the lowest battery voltage, it should still be able to deliver ~2A, but at higher battery voltages, it can even deliver 3A or more. *sigh*
The question is whether it is worth designing a module around this right now or not.
I suspect the effort is better invested in creating another module instead... although hand-assembly is very attractive, as it would let me put off figuring out how to use the PCBWay assembly service for a bit longer.
Another option, though, is to use the same DC:DC converter that is on the MPPT module I've derived from this. Having commonality of the part is attractive for reducing the unique part count that I will need to have on hand. Also, I can in principle just replicate the circuit and layout from that one, and know that it's already been tested.
That design uses a AP63203, which, unfortunately has a minimum input voltage of 3.8V, which is above the full level of our LiFePO4 single-cell battery. Bother! I'd even gone and adapted the MPPT module down to having just this module. Oh well.
The TPS631000 looks like it will be what we will need to use. We'll also hook it up so that it can deliver either 1.8V or 3.3V, to cover the two most likely voltages we will need. I'll do this by again providing an extra resistor that goes parallel to the feedback voltage resistor ladder:
To select 1.8V output the 1V8 SEL line should be tied to VOUT (not GND, as that would _increase_ the output voltage!). To help avoid people making mistakes with this, I've added silkscreen instructions that they should be tied for 1.8V output.
I've also provided a MODE pin for pulling to GND if you have a load that is ~1mA or less, and really want to get an extra bit of efficiency. But 50% efficiency at 1mA still only means 1mA wasted, so we aren't going to bother using this in the MEGAphone. But the facility is there for those who might want it, if using this module in something else.
The module now looks like this:
So that's that one also schematic and PCB layout done, satisfying
Milestone 2.2.2 - Low-energy power-management module to minimise engery consumption of the device: Schematic
Milestone 2.2.3 - Low-energy power-management module to minimise engery consumption of the device:PCB Layout [sic]
I've already got a PCBWay order in progress, that is waiting for a 4-layer board to be fabricated, which will take 4 days more, so I can easily add this one onto the order, which I've done.
