Scanners & Radios

Scanners & Radios · Volume 24

WiPhone

SIP/VoIP phone — radio-adjacent device that lives in the bench drawer

Contents

SectionTopic
1About this volume
2Hardware tour (open-source ESP32-based)
3SIP/VoIP configuration
4Daughter board design (it’s hacker-friendly)
5Battery + charging
6Firmware updates
7Use case fit (why it lives in the bench drawer)
8Resources

1. About this volume

The WiPhone is the oddity volume in this series. It’s not a radio. There is no LMR band, no amateur allocation, no scanner role, no DMR talkgroup, no HF propagation. It’s a SIP/VoIP phone — an open-hardware ESP32-based handset from HackEDA that connects to a SIP account over Wi-Fi and places voice calls through the internet. The reason it earns a slot in this series is the same reason it earns a slot in the bench drawer: it’s a hardware-hackable communication device, it lives among the radios because that’s where comms gear ends up, and when the rest of the lineup is busy being radios this is what you reach for when you want a phone that you can program.

Frame it correctly from the start. The WiPhone is not a competitor to the AnyTone D878UVII for amateur DMR (DMR voice is fundamentally different from SIP; one’s an RF protocol on 70cm, the other’s a packet flow over 802.11). It’s not a competitor to the cellular phone in your pocket (no baseband, no SIM, no LTE/5G modem, no PSTN). It’s not a competitor to the Yaesu VX-8DR APRS messaging (no AX.25, no TNC, no licensed band). It’s a SIP softphone that happens to have a physical keypad, a colour LCD, a real handset speaker and microphone, and an ESP32-WROOM (or equivalent) as the brain. The product category is “open hardware desk phone you can hack.” The community is small. The hardware is genuinely well-designed. The use cases in this lineup are narrow but real.

HackEDA shipped the WiPhone as a Kickstarter project in 2018-2019 and has continued small production runs since. Mid-2026 street price is roughly USD $130-150 for the assembled unit, plus shipping out of Hong Kong; bare-board and case-only options sit lower. The vendor documentation suite — the full set of seven PDFs in ../manuals/wiphone/ (Overview, Technical Details, Setting up SIP Accounts, Calls and Messages, Charge the battery, Firmware Updates, Daughter Board Design Guide) — is the v0.4rc1 documentation generation, which corresponds to a firmware revision shipped roughly 2022-2023. Jeff’s unit’s exact firmware revision is TBD — verify with Jeff against the on-device version display before assuming v0.4 behaviours match the unit on the bench.

This volume covers the hardware, the SIP setup, the daughter-board hacker surface, the battery and charging story, the firmware-update path, and the honest use-case framing. It is deliberately short-to-medium. The WiPhone doesn’t need a deep instrument treatment because it isn’t a deep instrument — it’s a programmable phone that lives in a drawer until you need it.

For the lineup-at-a-glance categorization that sits this volume next to the rest, see Vol 1 (Overview) §2 (The lineup at a glance) and Vol 1 §5 (Categorization) — the WiPhone is the single “radio-adjacent” row in the table, posture “bench drawer.”

2. Hardware tour (open-source ESP32-based) {#hardware-tour}

The WiPhone is built around an ESP32 module — the original Kickstarter shipped with the ESP32-WROOM-32 (single-band 2.4 GHz Wi-Fi + classic BT + BLE 4.2); later production runs may use ESP32-WROOM-32E or equivalent. Jeff’s specific module variant is TBD — pull the WROOM ID off the shield can on the bench unit if it matters for firmware-build decisions. The platform implication is the one that matters: 2.4 GHz Wi-Fi only, no 5 GHz, no cellular baseband, no PSTN. Connectivity is Wi-Fi → SIP → internet → far end. If the Wi-Fi is down the WiPhone is a brick.

Around the ESP32, the hardware is purpose-built for the phone form factor:

Display. A colour LCD on the front of the case, roughly 2.4” diagonal, parallel-interface or SPI (TBD — check the schematic in the open-hardware repo for the exact controller; the v0.4 documentation references it as an ILI9341-class panel). 320×240 typical for this controller family. Not touch — input is via the physical keypad. The display is bright enough for indoor use, marginal in direct sunlight (it’s a phone, not a chartplotter).

Keypad. Twelve-key T9-style numeric keypad (0-9, *, #) plus a small cluster of softkeys, navigation arrows, and call/end buttons. Physical tactile keys with a snap dome under each; the feel is closer to a 2005-era flip-phone than a modern smartphone. This is the input surface for SIP-account configuration, dialing, contact navigation, and menu access. Jeff: the keypad is a non-trivial advantage for one-handed dialing compared with any touchscreen-only softphone.

Earpiece speaker. Small dynamic driver behind the top of the case for ear-to-handset audio. Adequate for voice, not for media playback. Coupled with the housing for some passive low-end reinforcement.

Microphone. MEMS microphone at the bottom of the case, facing the user when held in normal phone posture. The Technical Details PDF in the manuals folder covers the audio chain (codec, gain stages, anti-aliasing filter) at the level of detail an embedded engineer needs to modify it.

Optional speakerphone. Some production runs include a louder rear-mounted speaker driven by a class-D amp for hands-free use; whether Jeff’s unit has it is TBD — visible from the back of the case if it’s there.

USB-C charging. The current production runs use USB-C; earlier (Kickstarter-era) units used micro-USB. The USB port is power + firmware-flash; there’s no USB-host stack and no MTP/serial-as-modem profile. Jeff’s unit’s connector is TBD pending visual inspection of the bench unit.

Internal battery. Single-cell Li-ion, soldered or JST-PH-connectorized depending on production run. Capacity is typically 1500-2000 mAh — TBD for Jeff’s exact unit; the Charge the battery PDF documents the specific cell shipped with v0.4-era hardware. Runtime claims (talk time hours, standby days) discussed in §5.

Daughter-board expansion connector. The hacker-friendly feature. A through-hole or board-to-board connector on the back of the main PCB exposes ESP32 GPIO, I²C, UART, SPI, and power rails (3.3 V + battery + USB-5V depending on jumper config). The Daughter Board Design Guide PDF in the manuals folder documents the pinout, the mechanical envelope, and the keep-out areas. This is where the WiPhone earns its “hackable” reputation — see §4.

Case. Injection-moulded plastic shell, designed to be openable with a small Phillips driver (no glue, no clips that snap-and-die on second opening). 3D-printable replacement cases exist in the WiPhone GitHub repo (wiphone/wiphone-hardware) and on community Thingiverse/Printables variants — useful when you want a custom enclosure for a daughter-board project that doesn’t fit the stock case.

Open hardware. The full schematic, PCB layout (KiCad), and BOM are published in the HackEDA GitHub organization. This is what distinguishes it from every commercial SIP desk phone: you can read every net, look up every part, build a unit from scratch if you want to (BOM cost is roughly $40-50 in components excluding the case and battery, plus PCB fab — TBD on current LCSC/Mouser pricing for the ILI9341 and the keypad rubber mat). For an EE who wants a programmable phone, this is the bench’s answer to “I wish I could see the schematic.”

The Technical Details PDF in ../manuals/wiphone/ is the authoritative reference for any factual claim about the hardware — pin numbers, voltage rails, peripheral assignments, power consumption per state. Read it once before any daughter-board project.

3. SIP/VoIP configuration {#sip-voip-configuration}

The WiPhone is a SIP user agent (in IETF RFC 3261 terms — a SIP UA, a softphone-class endpoint) running over Wi-Fi. To make a call, it needs three things: a Wi-Fi association to a network with internet access, a SIP account (server URL + username + password), and a far-end SIP URI to dial. With those, it acts like any softphone — registers with the SIP server, places and receives calls, exchanges RTP audio in both directions.

Wi-Fi setup. The device-side configuration is via the on-device menu: SSID selection, password entry on the T9 keypad (slow, since it’s a phone keypad not a QWERTY), WPA2 personal supported. WPA3 support is TBD — the ESP32-WROOM-32 has WPA3 in newer SDK builds, but whether v0.4 firmware enables it is unknown; verify against the on-device association behaviour with a WPA3-only network. Enterprise Wi-Fi (WPA2-EAP / 802.1X) is not supported in stock v0.4 firmware. Wi-Fi-band: 2.4 GHz only, since the ESP32-WROOM-32 has no 5 GHz radio — see Antennas Vol 1 for the broader “internal Wi-Fi antenna is enough for short-range applications; no external RF necessary” framing that applies here.

SIP account setup. The procedure is documented at length in ../manuals/wiphone/Setting up SIP Accounts — v0.4rc1 documentation.pdf. The fields that matter:

  • SIP server / domain — the host the WiPhone registers against (e.g. atlanta.voip.ms, chicago.voip.ms, your Asterisk box’s hostname or LAN IP, etc.).
  • Username / extension — assigned by the SIP provider or your PBX (e.g. 1234567_jeff for VoIP.ms, 1001 for an Asterisk extension).
  • Password — the SIP password (separate from the provider’s web-portal password, in the VoIP.ms case; same as the extension secret in an Asterisk box).
  • Outbound proxy — optional, used when the SIP server is behind a NAT or when a provider mandates it; most providers don’t need it.
  • Registration interval — how often the WiPhone re-registers; default is typically 600 seconds, which is fine for any normal use.
  • Codec preference — G.711 µ-law (the universal interoperable codec, ~64 kbps), G.711 a-law (European variant), GSM (low-bandwidth, ~13 kbps, lower quality), OPUS (modern, variable rate, best quality but TBD on v0.4 firmware support — verify against the on-device codec list).

The WiPhone supports multiple SIP accounts simultaneously (the v0.4 docs reference up to 4 stored accounts, switchable per-call) — useful for keeping a personal SIP, a work SIP, and a JMP.chat SIP-to-XMPP bridge all configured at once.

Provider compatibility. Tested-good provider list from community reports:

ProviderNotes
VoIP.msThe default reference. $1.50/month per DID + per-minute or unlimited plans. Works cleanly with the WiPhone’s G.711 codec.
Twilio (Programmable Voice)Works as a SIP endpoint; Twilio’s SIP trunking adds per-call cost on top of DID rental.
OnSIPFree-tier SIP-to-SIP within the OnSIP user base, paid for PSTN.
Asterisk (self-hosted)The hacker’s choice. Run Asterisk or FreePBX in a VM or on a Pi; the WiPhone is then a desk extension on your own PBX. Zero per-call cost.
FreePBXThe GUI on top of Asterisk; same SIP semantics, friendlier configuration.
JMP.chatSIP-to-XMPP gateway; routes incoming SIP calls to your XMPP account. Niche but interesting for crossing protocols.
3CX, Sangoma PBXactCommercial PBXs; the WiPhone registers as a standard SIP extension.

Call quality. G.711 over a reasonable Wi-Fi link sounds essentially identical to PSTN — no surprises. Jitter and packet loss on a marginal Wi-Fi link cause the usual artefacts (clicks, brief dropouts, the occasional warble). The WiPhone has no acoustic echo cancellation worth speaking of in v0.4 firmware — handset use is fine; speakerphone use in a hard-walled room produces noticeable echo to the far end. The Calls and Messages PDF documents the on-device call workflow (placing, answering, holding, transferring) at the level needed for end-user training.

SMS / messaging. SIP MESSAGE method is supported on some firmware revisions for in-band SMS between SIP endpoints — TBD on Jeff’s firmware, and dependent on the SIP provider supporting it on the back end. Don’t plan around SMS as a core feature.

STUN / NAT traversal. SIP behind NAT is the classic problem (the SIP signaling carries the IP/port for the RTP media stream, which gets rewritten by NAT). The WiPhone supports STUN configuration for NAT traversal — set the STUN server (Google’s stun.l.google.com:19302 works for casual use; your SIP provider may offer their own) and the WiPhone learns its public IP/port and inserts it into SIP messages. For symmetric-NAT networks, even STUN doesn’t help — you need TURN or an outbound proxy. Most home routers do cone NAT and STUN works fine; corporate networks vary.

4. Daughter board design (it’s hacker-friendly) {#daughter-board-design}

This is the section that justifies the WiPhone’s place in this series. Every commercial SIP desk phone (Polycom, Yealink, Cisco, Grandstream) is a closed appliance — firmware, hardware, no expansion. The WiPhone has a back-of-PCB daughter-board connector that exposes the ESP32’s peripheral set, designed for community add-ons. The Daughter Board Design Guide PDF in ../manuals/wiphone/ is the authoritative reference; the summary:

Exposed signals. The connector breaks out the ESP32 GPIO that isn’t claimed by the phone’s own hardware (the display, keypad scanner, audio codec). The specific pin assignments are in the schematic, but the families available are:

  • GPIO — several free pins for digital I/O. Some are input-only (the ESP32’s GPIO34-39 series); others are full bidirectional.
  • I²C — one bus available, typically at standard 100 kHz or 400 kHz Fast Mode. Suitable for sensors, EEPROMs, RTCs, OLED displays, fuel-gauge ICs.
  • UART — a hardware UART available (the ESP32 has three; one is used by the USB-flash path, one may be used internally, leaving one for the daughter board). Suitable for GPS modules (most output 9600-baud NMEA), serial-attached peripherals, or a second microcontroller.
  • SPI — one SPI bus available, MOSI/MISO/SCK plus a chip-select line. Suitable for SD-card add-ons, additional flash, SPI-bus sensors, second display.
  • Power — 3.3 V (regulated, current-limited; check the schematic for the budget — typically a few hundred mA available before you start browning out the main board), USB +5 V (when the WiPhone is plugged in to USB-C), and battery raw (3.0-4.2 V depending on charge state, useful for direct power of higher-current peripherals).

Community daughter-board designs. The WiPhone community is small but real. Designs floated in the GitHub issues / Hackaday / GitHub gists include:

  • GPS add-on — a u-blox MAX-M10 or similar module on UART, giving the WiPhone position data; useful for a “where am I calling from” feature in a custom firmware build, or for time sync.
  • LoRa add-on — a Semtech SX1262 / RFM95W on SPI, turning the WiPhone into a Meshtastic node with a phone keypad — a genuinely interesting use case for a portable Meshtastic device with a real input surface (typing into Meshtastic on a tiny touchscreen is awful; typing on T9 keys is better).
  • NFC add-on — a PN532 on I²C or SPI for card-reading / tag-emulation; turns the WiPhone into a programmable NFC tool with a keypad and a display.
  • SD card add-on — a microSD slot on SPI for larger local storage; useful for call recording or for ringtone libraries.
  • Sensor packs — environmental (BME280 / SHT4x on I²C), motion (LSM6DSO on I²C), light (TSL2591 on I²C) — useful only if you have a specific application in mind.

Most of these are “build it yourself or port from Adafruit/SparkFun examples” — there isn’t a thriving WiPhone daughter-board ecosystem with stocked products. The advantage is the design space is open; the disadvantage is you’re on your own for the physical PCB fabrication.

Mechanical envelope. The daughter board has to fit inside the case (back panel screws on over it) or replace the back panel entirely. The Daughter Board Design Guide PDF documents the keep-out areas, the screw-boss positions, and the recommended PCB outline. For prototyping, a 3D-printed back panel with cutouts for the new I/O is the usual approach — the open-hardware case files in the GitHub repo make this straightforward.

Firmware integration. A daughter board with no firmware support is just connector access. The WiPhone firmware (on GitHub at HackEDA/wiphone-firmware, also forked at the older Hong-Kong-Districts-Info/wiphone-firmware) is open — you can fork it, add your daughter-board driver code, and reflash. The build toolchain is ESP-IDF (Espressif’s official ESP32 SDK) — see §6.

This combination — open hardware, open firmware, designed-for-expansion connector, peripheral-friendly ESP32 — is the WiPhone’s actual product story. It’s not a great phone; it’s a great hackable phone-shaped ESP32 platform.

5. Battery + charging {#battery-charging}

A single-cell Li-ion internal battery, USB-C charged through the same connector used for firmware flash. The Charge the battery PDF in ../manuals/wiphone/ is the authoritative reference; the summary:

Capacity. Production runs vary; typical is 1500-2000 mAh single-cell LiPo, soldered or JST-PH-connectorized. The v0.4 documentation references a specific cell P/N (verify against Jeff’s unit — TBD). Replacement is straightforward when the cell eventually dies — open the case, desolder or unplug, replace with an equivalent cell from a hobby supplier. Watch the polarity and the cell connector pinout; the v0.4 docs spell it out.

Charging. Standard USB-C 5V input drives a Li-ion charge controller IC (the schematic shows the specific part — typically a TP4056 or equivalent linear charger; some production runs may use a switcher). Charge current is set by a resistor on the IC; the documentation indicates ~500 mA charge current, which is gentle on the cell and gives ~3-4 hours from empty to full for a 1500 mAh pack. Trickle taper at end-of-charge is automatic.

Runtime. Vendor-quoted figures are approximate and vary by use pattern:

  • Standby (Wi-Fi associated, idle, registered to SIP server) — multiple days, typically 3-5. The ESP32’s modem-sleep mode keeps the Wi-Fi link alive on a low duty cycle; the display blanks; current draw is tens of milliamps.
  • Active call (Wi-Fi RX/TX continuous, codec running, audio chain active) — a few hours, typically 3-5 depending on Wi-Fi signal strength (a marginal signal forces higher TX power and shortens runtime).
  • Continuous display-on, browsing menus — between standby and active-call; not a meaningful operational mode but useful for development.

These are not great numbers for a “phone” comparison. A modern smartphone in standby lasts a day on a 4000+ mAh pack with aggressive power management; the WiPhone, on a 1500-2000 mAh pack with a less aggressive low-power story, doesn’t beat that. As an occasional-use programmable SIP endpoint, it’s fine.

The “is it still alive in the drawer” problem. Li-ion cells self-discharge slowly (a few percent per month) and the WiPhone’s standby draw drains the pack faster than self-discharge — a fully charged WiPhone left untouched in a drawer will be flat in roughly two weeks. If you genuinely want it as a “grab and use” tool, leave it on a USB-C charger in the drawer (the charge controller will float-charge correctly and the cell won’t be damaged). If you want it for long-term storage, take it down to ~50% charge, power it fully off (the docs cover the hold-button shutdown procedure), and check on it every couple of months.

6. Firmware updates {#firmware-updates}

Firmware on the WiPhone is open-source ESP-IDF code, published at the GitHub repos referenced in §8. The Firmware Updates PDF in ../manuals/wiphone/ documents the user-facing update workflow; the hacker-facing build-from-source workflow is in the GitHub README.

OTA (Over-the-Air) updates. The v0.4 firmware supports OTA download over Wi-Fi from a HackEDA-hosted update server. The on-device menu offers a “check for updates” option; the device fetches a manifest, downloads the new firmware image, validates it, and writes it to the secondary OTA partition. On reboot, the bootloader switches to the new partition; the prior partition remains as a rollback target. The Firmware Updates PDF documents the user-side procedure (check, confirm, wait). Vendor firmware release cadence is slow — the v0.4rc1 docs date from a generation that’s been stable for years; new releases are sporadic.

USB-C wired updates (esptool). The hacker path. Connect USB-C, put the ESP32 into bootloader mode (the documentation covers the keypad-hold-during-reset sequence, since the WiPhone doesn’t have a dedicated BOOT button — it’s keypad-decoded by the application firmware until the application hands off), and use Espressif’s esptool.py:

esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 460800 \
    write_flash 0x10000 wiphone-firmware-vX.bin

The exact offset and number of partitions depend on the firmware partition table (in the open repo). This is the path for custom firmware builds — Jeff’s path if he wants to add daughter-board support, change codecs, modify the SIP stack, or otherwise extend the device beyond stock behaviour.

Building from source. The build toolchain is ESP-IDF, the official Espressif SDK. Install ESP-IDF (the latest v5.x is fine; the WiPhone firmware may pin to an older v4.x depending on when it was last actively maintained — check the repo README), clone the firmware repo, run idf.py set-target esp32, idf.py menuconfig to set SIP credentials at build time or other configuration, idf.py build, idf.py -p COM7 flash (or /dev/ttyUSB0 on Linux/macOS).

This is a non-trivial build — ESP-IDF has a steep first-time learning curve, the WiPhone firmware has its own application architecture (real-time tasks, the SIP stack, the audio codec drivers, the display driver, the keypad scanner), and rebuilds take minutes. For one-off tweaks (changing a string, adjusting a default), it’s manageable. For deep modifications (new daughter-board drivers, new codecs, replacement of the SIP stack), it’s a project.

Forks and community firmware. Community forks exist with assorted improvements — bug fixes, additional codec support, UI tweaks, hardware variants. The Hong-Kong-Districts-Info fork (Hong-Kong-Districts-Info/wiphone-firmware) is the longest-lived community fork and is sometimes ahead of HackEDA’s mainline. Check both repos and pick the one that matches your hardware revision and your use case.

Firmware version on Jeff’s unit. TBD — verify on-device. The version is displayed in the on-device “About” menu (per the v0.4 docs) and the build commit hash is in the firmware binary itself (extractable with strings on the flash dump).

7. Use case fit (why it lives in the bench drawer) {#use-case-fit}

This is the section where the honesty matters. The WiPhone is not first-pick for anything in normal use. The cellular phone in your pocket is the first-pick for “phone.” Any radio in this lineup (Vols 2-19) is first-pick for “radio.” The WiPhone earns the bench drawer slot in three specific contexts and no others.

Context 1: Travel SIP-phone backup with no cellular dependency. When the cellular network is unavailable (international travel without roaming, a remote site with only Wi-Fi connectivity, a deliberately cellular-off posture for OPSEC reasons), the WiPhone gives you a working phone over whatever Wi-Fi is available. Register against a personal SIP account (a $1.50/month VoIP.ms DID, an Asterisk box at home, etc.) and you have inbound calls on your usual DID and outbound calls to anywhere. The handset form factor — real keypad, real earpiece, real microphone — is more usable than a softphone app on a laptop. The Wi-Fi-only dependency is also the limitation: no Wi-Fi, no phone. For most travel, this is a niche case (cellular roaming is cheap now); for specific postures it’s the right tool.

Context 2: Hackable phone form-factor for development experiments. When the project on the bench is “I want to add X to a phone” — where X is a sensor, a new codec, a different display, a custom call-routing UI, a Meshtastic bridge — the WiPhone is the only programmable open-hardware phone-shaped ESP32 device that exists. Every commercial SIP desk phone is closed firmware; every hobbyist softphone is on a laptop or a touchscreen, not a real phone keypad. The daughter-board connector (§4) plus open firmware (§6) makes the WiPhone the right base for any project where “phone form factor with a keypad and a speaker and a microphone” matters. Examples: a Meshtastic+SIP combo node; an emergency-services SIP terminal with a custom one-touch dial; a SIP phone that also reads NFC employee badges for in-call identification.

Context 3: ESP32 / SIP / VoIP learning platform. When the goal is to understand the SIP protocol, the RTP media path, the codec selection logic, NAT traversal, or the ESP32’s Wi-Fi+audio capabilities, the WiPhone is a working reference implementation you can read, modify, rebuild, and observe. The firmware repo is the curriculum. Wireshark the SIP exchange on your local network and read the firmware source side-by-side; you learn the protocol in a way that no closed appliance allows.

What it isn’t first-pick for:

  • Daily-driver phone — the cellular phone wins on every axis (cellular reach, battery life, app ecosystem, audio quality, build polish).
  • Amateur radio voice — the AnyTone D878UVII, Yaesu VX-8DR, or Baofeng F8HP wins. The WiPhone has no RF radio role.
  • DMR talkgroups — the AnyTone + a hotspot wins. The WiPhone doesn’t speak DMR.
  • Scanner / monitoring — any Uniden in Vols 10-17 wins. The WiPhone is a TX/RX endpoint, not a wideband receiver.
  • Field-day comms — any of the HF or VHF/UHF radios wins. The WiPhone needs Wi-Fi + internet to do anything.
  • OPSEC-sensitive comms — neither the WiPhone nor the cellular phone is the right tool for sensitive comms (SIP over open Wi-Fi is plaintext SIP signalling and unencrypted RTP unless SRTP is configured; even with TLS-SIP and SRTP, your SIP provider sees metadata; even self-hosted Asterisk leaves a metadata trail). For sensitive comms see the operational-posture treatment in ../../../Hack Tools/_shared/legal_ethics.md and the broader posture discussion in ../../../Hack Tools/Hacker Tradecraft/.

Posture in the bench drawer. It lives in the drawer. When the project is one of the three contexts above, it comes out. When the project is anything else, it stays in the drawer. Charge it occasionally; check the firmware version annually; redo the SIP-account setup if your VoIP provider changes their server endpoints. This is appropriate posture for a niche tool that’s nice-to-have — not a tool that’s in active rotation.

The cross-reference in Vol 1 §8 (Posture mapping) places the WiPhone in the “bench drawer items — no active posture” bucket alongside the test gear in Vol 23. Both are correct categorizations.

8. Resources

Vendor documentation (the manuals folder is the load-bearing reference for any factual claim about this device):

  • ../manuals/wiphone/Overview — v0.4rc1 documentation.pdf — high-level device tour
  • ../manuals/wiphone/Technical Details — v0.4rc1 documentation.pdf — hardware deep dive (pin numbers, voltage rails, peripheral assignments) — the most useful PDF for any daughter-board work
  • ../manuals/wiphone/Setting up SIP Accounts — v0.4rc1 documentation.pdf — SIP-account configuration walkthrough
  • ../manuals/wiphone/Calls and Messages — v0.4rc1 documentation.pdf — end-user call workflow
  • ../manuals/wiphone/Charge the battery — v0.4rc1 documentation.pdf — battery + charging procedure
  • ../manuals/wiphone/Firmware Updates — v0.4rc1 documentation.pdf — OTA + USB-C update procedure
  • ../manuals/wiphone/Daughter Board Design Guide — v0.4rc1 documentation.pdf — daughter-board pinout + mechanical envelope + design rules

Vendor and product:

SIP providers (the WiPhone’s “back end” — pick one or self-host):

ESP32 development toolchain (required for any firmware modification):

Protocol references:

Sibling cross-references in this series:

Sibling project cross-references (minimal — this device has no RF radio role):

  • Antennas Vol 1 (Overview) — for the “internal Wi-Fi antenna is enough; no external RF necessary” framing that applies to the WiPhone (and to every other 2.4 GHz Wi-Fi consumer device in the hub)
  • Hack Tools/_shared/legal_ethics.md — applies to SIP signalling metadata posture as much as to RF
  • Hack Tools/Hacker Tradecraft — broader posture and tradecraft discussion if the WiPhone is being deployed in a tradecraft context rather than a casual one