02/06/2019 at 15:26 •
On the main page right now (2019/02/06):
01/21/2019 at 02:55 •
Got some samples in today for the production keypad buttons. We went with dome contacts. These will be positioned over gold plated fingers on the main PCB, and they are held in position with a clear plastic overlay.
Also sent out a little mold for the keypad. This is not the production mold, just a quick/cheap one to confirm the keypad geometry works. Should arrive later this week and we can make a few samples by squirting silicone into the mold using a syringe.
10/19/2018 at 03:44 •
We've been dialing a lot of things in on the motherboard. The biggest noticeable change is the GUI. It looks much more polished now. We're almost ready to start carrying the phone around for daily use.
For complete details, read the full post on the WiPhone blog:
10/08/2018 at 10:10 •
What's an electronics project without an attempt at modularity? As part of our project goals, we want a phone that can be easily modified and expanded, but still remains something you could actually use every day. How do we balance those requirements?For complete details, read the full post on the WiPhone blog:
09/21/2018 at 09:38 •
Original post on the WiPhone blog: https://wiphone.io/blogs/blog/testing-a-capacitive-button-panel
We wanted to see if it was possible to eliminate the physical buttons on the front of the phone by using a capacitive button panel.
It has a few advantages:
- At this point in time, it's what people expect (it looks good)
- If we do it right, it could be easy to let people swap out a PCB with a different button layout, opening up the ability to adapt the hardware to different purposes.
- Potentially longer design life, due to no moving parts
- Somewhat risky. Physical button panel examples are everywhere, but you don't generally see capacitive button panels as dense as we need. There's probably a reason for that, so we expect to have issues with crosstalk/inadvertent triggering of neighboring buttons.
We made a test panel, shown above, that has buttons of approximately the size and pitch we need for the phone. Overall, the test panel works OK. It is, in fact, easy to accidentally trigger neighboring buttons. But it was interesting enough we'll go ahead and make another panel using our current button layout and see how it performs in the phone.
09/18/2018 at 12:56 •
We wanted to post an assembly video showing how the mechanical parts of the phone go together. It's already a pretty simple process, and should get even easier once we have a single-piece keypad.
At this stage it's still more of a prototye model than a production unit. The main purpose of this version is to give us something to actually use. Real world use is important for finding all the little issues that show up once a design moves from pictures on a screen to reality. Once we have a list of those we will evaluate what's possible to fix, and incorporate the improvements into the next version.
We've been playing around with the phone for a few weeks, mostly debugging electronics and software. Once we get the bug situation under control we will start carrying the phones around and collecting improvement opportunities for UI, software, electronics, and hardware.
09/07/2018 at 09:26 •
We have all the components on hand now.
Back Panel - FR4, cut to the correct profile
Motherboard - 4 layers, hand assembled
Frame - Aluminum, CNC cut and clear anodized
Front Panel - 2mm thick polycarbonate, CNC cut
Screws - M2x4, 4x
ON/OFF Button - Silicone, artisinal hand carved (OK, actually hand-snipped with a pair if dikes)
Antenna - Whip antenna, we may change to chip or trace antenna after we do some signal strength optimization
Keypad - Hard plastic, CNC cut. Eventually this will likely be a single cast silicone part.
Battery - LiPo pouch.
As the perceptive among you may have noticed, the parts have been assembled and our project pic updated. Later we will post more info, but for now we can say that everything fits with only minor issues. And the overall build looks and feels great, especially given how few revisions there have been.
08/18/2018 at 01:16 •
Some shots of the current state of the user interface. Implemented so far:
- make a call
- receive a call
- address book
- wifi scanning
- wifi credentials management
- SIP account management
- boot screen
- make a call
08/17/2018 at 01:30 •
Now with wires and little square things all over it:
08/16/2018 at 00:42 •
We recognize a few universal truths: Biological life… errr… finds a way. Every software program expands until it can check email, or dies trying. All online discussions of sufficient length end in references to Nazis and utter disdain for opposing viewpoints. And all screen-bearing hardware evolves to kill bad guys at the maximum screen rate possible. So, bowing to the evolutionary pressures that are the natural order of things, we’ve started benchmarking and optimizing our graphics performance. Also, we were really tired of debugging hardware and wanted a fun break for a bit.
Originally we were thinking to put a much smaller TFT display in the WiPhone. Something like 1.4" or 1.8" display. These screens are usually driven by an ST7735 driver over SPI.
Trouble is, nobody likes phones with tiny screens like that. They’re ugly. And killing bad guys on a tiny screen is unsatisfying. Luckily, we quickly abandoned the smaller screens and switched to a 2.4 inch screen with 320×240 pixels. But the ESP32 isn’t blessed with an abundance of extra I/O, so we are stuck with the lower bandwidth SPI bus now needing to push roughly 4x the original data out to the screen.
As you can see in our first demo video, the graphics library that came as example code with our screen was struggling to refresh even a basic phone interface. Each widget is noticeably re-drawn.
Most phones with a screen this size use a parallel 8-bit bus (a.k.a. “8080 series MCU interface”). But given the limited pins on the ESP32 and all the other things a phone needs to do, something needed to give.
Luckily, we found a beautiful and fast library called TFT_eSPI by Github user Bodmer, which is optimized for ESP32 chips. Our ST7789 driver IC was not yet supported, but an initialization routine and a pull request later we were pleasantly surprised by a 3-12x speedup!
Here we run Xark’s benchmark with our bigger screen using TFT_eSPI library, as well as the original library we developed:
NVIDIA, eat your heart out.