Enclosure Prototype
I took the basic case I designed for gCore and tried to extend it for weeBell. I think I've run into the limits of my methods for using OpenSCAD for enclosure design. I missed some linkage in the OpenSCAD "code" describing the box and it's just a tiny bit too long. But this should be easily fixed and I'm going to also add support for a foot so the front of the box can sit at an angle.
![](https://cdn.hackaday.io/images/4352371683912431155.png)
Bluetooth Code
The first "application" for weeBell uses the Handsfree Classic Bluetooth protocol to allow POTS phones to answer or initiate calls over a linked cellphone. It currently has the unsexy name "gcore_pots_bt" but I think I'll rename it "Blue POT" like my original gadget. It is written in C using the Espressif IDF v4.4.4 and is quite functional but with a few things I'm dealing with at the moment which is why it hasn't been uploaded to a repo yet.
- I have an issue initially pairing with my iPhone. I'm using Secure Simple Pairing and configuring it so both device show a PIN with yes/no confirmation buttons to prevent man-in-the-middle attacks. However the iPhone will sometimes show a dialog box asking if I want to download contact info (which it must assume any handsfree device wants to do).
- I'm still having some issues automatically reconnecting with a cellphone which make me think I'm still not quite using the Espressif API correctly. The code can connect on power up but if the iPhone was connected and then disconnects (e.g. leaves the house) the code won't always reconnect when the iPhone comes back in range.
- I have an occasional issue synchronizing the I2S streams to and from the codec. The echo cancellation algorithm must always see data from both streams with a constant offset but unfortunately the Espressif I2S driver runs both paths, and their associated DMA engines, asynchronously and even though I go through great pains to start them at the same time and they are the only process running on one core, sometimes they get out of sync. I may have to write some low level code to replace the existing driver.
- I am having an issue with some I2C cycles failing. I think I have found a hardware bug in the NXP SGTL5000 Codec chip. It sits on an I2C bus for configuration along with the touchscreen controller and gCore's built-in power management/RTC controller. The code only really talks to the Codec at start-up when it configures it and then only if a volume level is changed. However it constantly polls the other two devices (the touchscreen controller is polled every 30 mSec and the gCore controller every 100 mSec). Once in a while when the first read data byte in an I2C read is 0x0A the I2C transaction seems to be stretched and won't complete until the ESP32 I2C peripheral times out. This only occurs when the SGTL5000 is connected to the bus even when no cycle is running to it. Unfortunately there is a particular status value from the gCore controller that is frequently 0xA.
The software GUI looks as follows. The keypad can be used to dial a number (enabling, someday I hope connection to really old phones that lacked a dial) or can be used to dial DTMF tones during a call from a rotary phone (for example to navigate automated systems).
![](https://cdn.hackaday.io/images/5356181683913754656.png)
The Mute button mutes outgoing audio from the Phone's microphone and Do Not Disturb prevents the phone's ringer bell from ringing (although the phone can still be answered).
![](https://cdn.hackaday.io/images/5340331683913767232.png)
The Settings screen allows some adjustments and pairing control. The code supports generating different dialing tones and ringer frequency/cadence so that weeBell can simulate phone exchanges from around the world. I'm currently collecting information for some various countries. The Auto Dim switch causes the display to dim way down when nothing is going on. This is because I hate gadgets that blast out a lot of light at night. A phone call or touching the screen causes the brightness to fade back up.
I hope over the next week or so to figure out the current issues and be able to release the first version of the code. I'm also making a minor spin to the PCB to incorporate a few slight changes although I'm holding off on that in the case I have to replace the Codec with a different chip.
Ultimately I'd also like to add caller ID generation to the code. This requires the implementation of a Bell 202 compatible software modem (or, for some countries caller ID DTMF tone generation).
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.