abijahkaj

Yes, the Quectel EC25-EUX supports VoLTE natively on the modem baseband, and from the board's perspective the audio path is identical: the modem handles the IMS/SIP registration and AMR codec internally and outputs standard 1.8V PCM digital audio to the RP2040 whether the call is over VoLTE or 2G/3G fallback.

I put that caveat in the README because VoLTE support in practice depends on carrier whitelisting and having the right carrier MBN profile loaded on the Quectel module (AT+QMBNCFG), not on the rest of the PCB. Here in Europe, 2G/3G is still up for a few more years, and major carriers have MBN profiles in the standard EC25-EUX firmware, so testing both VoLTE registration and CSFB fallback will be part of bring-up when the board lands.

yeah it's raw output from the router i'm coding without a trace smoothing pass yet, so it draws ugly jagged steps. looks bad to a human layout engineer, no argument there. either way it won't stop it from working, the electrons don't care how ugly the bend is at 2 MHz. just want to see if it boots when the jlcpcb parcel lands.

edit: idk why my comments are being [flagged], i've written to hn but the issue is apparently still there

I mentioned in the top comment that Koppar generated the board and that the first batch is about to be ordered, so no detective work needed there.

I'm just as skeptical of blind AI hardware output as you are, which is why I audited every net against the datasheets and put all the flaws in REVIEW.md in the repo before ordering: - The 0.33 mm RF trace came out to ~35 Ω instead of 50 Ω and hopped layers through vias (I included Pi-matching pads to tune it on the bench). - The 3.8 V buck converter was placed too far from its inductor, and the 1.37 mm power trace is narrower than Quectel's 2 mm recommendation (~100 mV drop at 3 A). - The SIM socket (J2) is oriented inward, which is annoying mechanically.

5 bare boards + 2 PCBA units are currently being ordered at JLCPCB, and I'll order the EC25-EUX modules separately to hand-solder onto U8 since JLC was out of stock.

Since the KiCad files are in the repo, if you spot a specific net or pinout error that will brick bring-up, let me know so I can bodge-wire it next week.

I wanted a real phone line on my computer: calls and texts on a physical SIM, answered through my headset at my desk, or by a script or an AI agent when I'm away. Cloud numbers get treated as VoIP, and old Android phones give you no clean way to get call audio in and out over USB.

So this is a 4-layer USB-C board around a Quectel EC25-EUX. Behind a USB hub, the computer sees an LTE network adapter, the modem's AT serial ports (caller ID, SMS, answer), and an RP2040 acting as a USB sound card. The RP2040 bridges the modem's 1.8 V PCM audio through a level shifter. There's a 3.8 V buck sized for the 2 A GSM bursts, and no battery.

I wrote the spec as one page of text, and Koppar, the tool I'm building, generated the schematic and the board. Then I reviewed it against the datasheets. The review found a 35 Ω antenna feed that hopped layers, a buck 60 mm from its inductor, and a SIM socket facing into the board. The parts matching would have bought an 18 µH inductor for a 4.7 µH slot. REVIEW.md in the repo has all of it with the numbers.

Status: the boards aren't built yet. The repo is the design as I'm ordering it: KiCad 10 project, Gerbers, JLCPCB BOM and placement files. Bring-up and the sound-card firmware come next.

Happy to answer anything about the audio path or the power design, and I'd like to hear what you'd change before the first bring-up.

Interesting read, is there a method that protects privacy? I think as you mentioned, changing the hashing algorithm won't fix the issue.