06/28/2019 at 14:25 •
We finally got to the bottom of some audio issues that had us running in circles for a while. This was a tricky one because there were actually 2 separate issues and we added a codec and changed our audio library at the same time we started noticing them, so we wasted a while thinking it was our stuff, or the new audio library (spoiler: the one that had us spinning our wheels the longest was an ESP32 issue).
Issue #1 was the clock source for the audio codec. Originally it was coming from a separate oscillator, but apparently the right way to handle it is to drive it from the same source as the I2S.
Solution: delete the external oscillator and add a jumper the existing boards to use a pin from the ESP32 as the clock signal.
Issue #2 we originally called the drunken codec because we noticed it around the same time we implemented G.711 and it seemed like that was the source of the weirdness. It make you sound drunk. Funny, but hard to debug. Andriy spent quite a while trying to see if we had some sort of endianness problem or a math mistake in the codec, but everything looked right. Shortly after that we added an audio library so that we could play MP3s, and that sounded great. Yay! We fixed it. Except, no, actually it only sounded good for audio playback. Calls still were still coming from someone who had been at a drinking establishment for quite some time. So we started looking at the network stack and audio buffers used for calling. A lot of debugging later and the audio pipeline for calling is simplified considerably, but the issue remains.
So eventually we tried recording audio in various situations and noticed something weird:
For a 16kHz sample, it looked like high frequency (around 8 kHz) noise was overlaid on the signal. Except there was no noise when the input level was low. And we also noticed that what sounded "drunk" at 8kHz sounded like sort of a buzzy robotic voice at 16kHz. Strange.
Now that we had some real observations to play with, the issue quickly unraveled itself as the following:
- The ESP32 was doing it.
- "It" being chronological swapping of every other audio sample.
- But only for mono. Stereo came through as expected.
One of the things that made it so hard to debug (apart from all the other changes we made clouding the issue near the time we noticed it), was it only happened in calls since that was the only time we used mono. And it only happened when the call was between a WiPhone and something else (not between WiPhones) since the error self corrected if the audio got sent to and processed another ESP32.
Anyway, now you will only sound normal instead of drunk or robotic during calls.
06/21/2019 at 07:28 •
The bank situation is resolved. We managed to pay some vendors yesterday. Hoping to switch banks ASAP once I'm back in the States. No sense in wasting any more words on an inefficient system with no hope of influencing changes.
So, moving on to things we can have a positive effect on:
Upcoming Board Revision
Hoping to send out the next PCB revision within a week or so. This is the first production candidate (likely there will be at least one more revision).
- New speaker sounds better, but it's too thick. The actual part dimensions of the sample didn't match the drawing.
- Also got a new vibrator motor sample.
- Switched to a locking style SD card holder
- Looking into why boot takes so long (bootloader + loading data from the external flash takes around 3 seconds)
- Changed the I/O to eliminate screen flashing on boot
- Started work on an automated tester/programmer
- Added a dialing screen.
- Ongoing call quality debugging.
06/17/2019 at 16:35 •
Stuck in China due to Chase Bank simultaneously fucking the project in the ass and being a giant bag of limp, helpless dicks.
Their fraud detection algorithm locked our account and now the WiPhone project can't move forward until Chase unlocks it again. Which apparently requires buying a plane ticket and fly half way around the world. Which requires money that's currently locked in the account. And time that could be more productively spent doing practically anything else.
And a twitter thread with Chase here. Feel free to join in and let them know what a bunch of helpless incompetents they are:
06/11/2019 at 12:49 •
We Shipped! (...technically)
The first evaluation units are on their way to the early testers. These are closer to beta hardware than the final version, but it's a good milestone regardless. Looking forward to as much constructive feedback as we can get, and hopefully some cool projects.
The Ongoing Keypad Saga
Extracting the keypads from our current (soon to be previous) vendor was a bit of an adventure, and I'm pretty unhappy it took so long... we really need to be iterating, but that's near impossible if the vendor drags their feet over a month getting the samples made. Luckily the samples we have now work reasonably well and we did learn a good deal about what needs to change in the next revision. The main takeaways are the area around the button needs to be more flexible for easy actuation, and the membrane that supports the dome contacts seems to require surprisingly precise alignment to make button actuation reliable. We will look into this more later and if alignment is as important as it seems to be, figure out what can change on the design to make alignment accuracy less important.
The backlights also work now:
It's kind of a cool process how keypads like these are made. They start out as white translucent compression molded silicone, then the black layer is sprayed on, and the lettering is etched by laser. Under the keypad there are a few LEDs on the PCB, that provide the backlight.
Aamir has been hard at work rooting out bugs and he has a pretty impressive collection of dead ones at this point:
- backlight brightness improved with correct resistor value
- audio codec running on appropriate clock now, audio is sounding quite good
- software shutdown circuit debugged (software shutdown allows the phone to close the SD card connection before shutting down, so as to avoid SD card corruption)
- ongoing power testing to maximize battery life and overall power system reliability
- found a surface mount mic and a spring mount speaker to replace the previous ones that had wire leads
- testing with a 2W loudspeaker (the phone likely won't ship with a loudspeaker, but the hardware currently supports adding one and we want to make sure it would work well)
- switched to a GPIO expander with PWM functionality. This lets us control the LCD backlight brightness, keypad brightness, and vibration motor without running out of processor pins.
- testing adding an extra mic on the back of the phone so people can do things like echo and noise cancellation.
- updated code to handle the new audio clock source (MCLK of I2S is now synchronized with ESP32 directly instead of an independent crystal, fixing audio quality issues)
- added a simple MP3 player app and MP3 ringtone
- store multiple SIP accounts (use one at a time)
- back up of critical config files to non-volatile storage (WiFi networks, SIP accounts)
- added querying of the in-memory save-file (this is how large message threads could be handled later)
- fixed multiple minor UI/UX bugs, like improved input of special symbols
- a sample graphic app: ported Fairy-Max chess engine
I think we are actually still on track to start shipping the Pro versions in August. However, we have ate up most of our schedule margin and we haven't started the injection mold yet because there are a few mechanical design considerations that need to be resolved before we should jump into making tooling. So while it's likely that the Pro versions can still start shipping in August if we continue to track our current schedule (since they are made by CNC the lead time isn't so long), because we haven't started the tooling the regular ones won't.
A major unresolved issue right now is bonding of the clear face to the frame. We really don't want those coming off later, and it's going to take some longer term testing to prove any particular adhesive is going to work well from both durability and asthetic standpoints. I'm actually considering making the plastic version of the phone as a unibody design (join the frame and front face), and do it entirely in clear material. Then we can paint the outer frame and completely sidestep the bonding issue, at least on the regular model. Before we start the tooling we also need to have keypads that feel super-sexy-silky, and right now it's more like the fumbling around that happens at a highschool dance: sometimes amazing and sometimes just awkward. As I mentioned before, miles better than the stuff on most hobby-type hardware, but we don't want to be operating at that level. We also need to make sure the antenna and mounting arrangement are exactly what they need to be, nail down the tolerances on the PCBA assembly and mating features with the phone frame, and a few other details. So we're going to make sure that's all good as we can get it before starting tooling, not after.
We're also gearing up to start the certification process, so there's still some room for SNAFUs there as well. But we've been through that before so it won't be completely blind.
Open Issues and Current Tasks
- simplified API for handling audio
- headphone jack detection
- audio issue during calls (other sounds and music playing sound great, but we're still sorting out audio in calls after the recent clock change)
- diagnostics app (to streamline testing and troubleshooting of newly assembled WiPhones. Should also be useful for users later)
- start a tester/programmer for the electronics
- start certifications
03/22/2019 at 07:36 •
Feedback appreciated... please let us know if you see something that could be improved, or clarified.
Hoping to launch next week.
Can also check out the Kickstarter preview page here (the campaign won't be live until next week):
02/28/2019 at 15:32 •
We added an Instagram account and will probably be posting more of the "finished product" type pics there. Some uploaded already as we get ready for crowdfunding.
Nerd pics still go here :).
02/21/2019 at 15:51 •
Our prototype keypad mold arrived and we made some test parts, and also learned a few things about handling silicone.
Some pics of the mold:
This mold is a very simple clamshell type that's only going to be used for manual testing. We just want to figure out if the keypad geometry is correct before moving to a production mold, and also get a few parts to use in the latest batch of testing phones. We will fill it by hand using a syringe.
Views of the inner surfaces. One side for the buttons, and the other side makes the inner features, including the little pips that push the dome contacts and close the electrical circuit.
We also had some silicone compatible dye on hand, so later pours were tinted blue. The keypad will probably be black in production, but we didn't have any black dye.
Before using the dye in a casting we made a few small test batches to make sure it would cure correctly. The supplier said it should work, but since we bought the dye and silicone from different places we wanted to test it first.
The silicone is a 2 part condensation cure type. The first rubber hardness we tried was Shore 50A, which turned out to be too soft.
We also learned a few tricks to make the process go smoother.
This particular mold has some critical features on both sides that form natural bubble traps. Button surfaces tend to trap air on the outside, and the pips that press the dome contacts trap air on the inside. So we have to be careful when filling to mold to eliminate bubbles. Since the silicone is thick and not prone to running, we could fill the bubble trap areas using the syringe before closing the mold and pouring the reminder through the main sprue. There were likely still a few bubbles caused by this method, but they all end up in areas we don't care about.
Another trick was to vacuum degas the syringe after loading it with silicone. It's almost impossible to mix silicone by hand without introducing bubbles, but the degas step pulls them back out.
The pour process:
This first one was not degassed. As you can see, there were lots of bubbles:
Next pour went better. We degassed, were careful to fill the critical areas of the mold, and used the blue dye we had tested earlier:
Some shots of the keypad in the prototype phone:
The buttons weren't pressing the dome contacts enough to easily make the electrical contact, so we added some foam underneath. With the foam it works better, but is still a little soft. Later we will try some harder silicone. We will also need to modify the shape of the mold to add more silicone near the dome contacts so that the production parts make better contact.:
Result after using the blue dye:
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: