Bluetooth rotary phone from PTT T65

[Zipdox]

I'm turning a PTT T65 into a Bluetooth rotary phone, and I would appreciate it if some people took a look at the schematic and gave me their thoughts.
https://easyeda.com/editor#id=7d0350ec43844219912695cec1a0e156

[Benta]

Ugly and unreadable, won't waste time on it.
Learn how to draw schematics. Little boxes around a device or two with labels attached are intellectual laziness. You might just as well post a spreadsheet.
Use wires in the future.

Are my thoughts OK?

[Zipdox]

Ugly and unreadable, won't waste time on it.
Learn how to draw schematics. Little boxes around a device or two with labels attached are intellectual laziness. You might just as well post a spreadsheet.
Use wires in the future.

Are my thoughts OK?

Are you saying I should connect everything with wires rather than labels?

[thermistor-guy]

Ugly and unreadable, won't waste time on it.
Learn how to draw schematics. Little boxes around a device or two with labels attached are intellectual laziness. You might just as well post a spreadsheet.
Use wires in the future.
...

Are you saying I should connect everything with wires rather than labels?

I haven't reviewed your design, but the schematic style is fine.

It helps someone unfamiliar with your project get to grips with it. I can imagine this being presented in
design review meetings.

There is a risk, with a label-centric style, you overlook missing connections, but prototype testing
will pick that up.

Use anything that helps you think clearly, about what you are doing.

[Zipdox]

There is a risk, with a label-centric style, you overlook missing connections, but prototype testing
will pick that up.

Use anything that helps you think clearly, about what you are doing.

EasyEDA throws an error in the net check if you have an unconnected label. It won't save you if you forgot a third connection to a net though.

[Benta]

Are you saying I should connect everything with wires rather than labels?

Short answer: yes.
Long answer with an example:

Let's say you have a circuit with an MCU and three I2C peripherals. Let's try to see how they're connected.
To make it easy, let's start with the MCU and the SCK output. What to do?
Well, begin in the top left corner and start scanning the schematic for the matching SCK labels. As a new reader of the schematic, you don't know that there are three peripherals. So when you find the first instance of a matching label, the risk is that you stop the search. Error!
If you start with one of the peripherals and try to find the Master, same story: begin in the top left corner and start scanning the schematic until you find the label.
I could go on, it's inefficient, time-consuming and error-prone.

With a wire, you see the connection between the parts immediately, from the branches on the wire it's easy to see how many parts are involved, and you can follow the wire in both directions. Fast, easy and error-free.

In short: readable and clear.

[pcprogrammer]

About the schematic, it can do with some improvements to make it a mix between what Benta is stating and what you made. Connecting everything with wires might make it unreadable too, due to a mishmash of wires. For this busses can be used, but labels work too.

But that aside, the capacitors you used on the switches (dial is a switch too) might be a bit high. Maybe run some tests starting with 10nf up to 100nf. The switches might also work better with more current through the contacts, so also experiment with the pullup resistors.

Another thing, the bell driver, if you are using the original bell, it depends on how high VCC is, if it will ring. If I'm not mistaken, old phones used about 90V AC for ringing the bell. You can't have your VCC this high, and even half that will be to much for the TPS5430DDAR.

But a fun project none the less. Please post some pictures of the old phone and when finished the new insides.

Edit: Also look into what the microphone and speaker in the original form need to be driven. It might not work with the modern IC you choose.

[globoy]

I don't know what you're planning to use for the software component but I successfully wrangled Espressif's bluetooth stack to provide telephony services in my weeBell project.  I did things a bit differently than you are planning to but just in case you'd like someone else's code to look at: https://github.com/danjulio/weeBell_bluetooth

The hardware my code ran on is at: https://github.com/danjulio/weeBell_hardware

I had to deal with echo cancellation which you shouldn't have to as you're interfacing separately to the handset speaker and microphone.

I second pcprogrammer's comment:  Make sure your DC input can ring the bell if you haven't already (they will ring, less loudly, on lower voltages).  Also make sure the levels into and out of your codec are ok.  The codec looks like it wants to drive a 8-16 ohm load.  Your old phone speaker might be higher impedance.  Fortunately the codec has an amp on the input for the microphone.  You might have to adjust that some however.

I think you should include a 1uF cap between EN and ground.  Espressif recommends (IIRC) a 22 uF + 0.1 uF bypass cap on the input which you more-or-less have with two distributed 10 uF caps on 3V3.  If you're running I2C at 400 kHz then I'd lower the values of the I2C pullups to something like 2.2 kohm.

Also, I'd recommend to include the ubiquitous 2-transistor auto-programming circuit using DTR# and RTS# from your USB UART (bring them out on H2) so you won't always have to be doing the BOOT/RESET button dance when you load code.

[Zipdox]

About the schematic, it can do with some improvements to make it a mix between what Benta is stating and what you made. Connecting everything with wires might make it unreadable too, due to a mishmash of wires. For this busses can be used, but labels work too.

I'll take it into consideration.

But that aside, the capacitors you used on the switches (dial is a switch too) might be a bit high. Maybe run some tests starting with 10nf up to 100nf. The switches might also work better with more current through the contacts, so also experiment with the pullup resistors.

I plan to do some debouncing tests with the switches before I finalize the design.

Another thing, the bell driver, if you are using the original bell, it depends on how high VCC is, if it will ring. If I'm not mistaken, old phones used about 90V AC for ringing the bell. You can't have your VCC this high, and even half that will be to much for the TPS5430DDAR.

The bell already works with 10V. I tested it with a DRV8833 I had on hand at 12V and it's plenty loud. VCC will be 12V.

But a fun project none the less. Please post some pictures of the old phone and when finished the new insides.

Edit: Also look into what the microphone and speaker in the original form need to be driven. It might not work with the modern IC you choose.

I also already tested the microphone. It's a carbon microphone. I tested it with a 1k resistor and 3V bias supply. The output signal is pretty strong, so I'm pretty confident that it'll work. As for the speaker, it's 100 ohms, so I might need to look into that. Maybe using the speaker output instead of the mono output is a good idea.

I don't know what you're planning to use for the software component but I successfully wrangled Espressif's bluetooth stack to provide telephony services in my weeBell project.  I did things a bit differently than you are planning to but just in case you'd like someone else's code to look at: https://github.com/danjulio/weeBell_bluetooth

The hardware my code ran on is at: https://github.com/danjulio/weeBell_hardware

I had to deal with echo cancellation which you shouldn't have to as you're interfacing separately to the handset speaker and microphone.

Thank you for the link, I'll definitely look into that. I already did some research regarding Bluetooth capabilities, and saw that many ESP32 variants don't support Bluetooth classic, only Bluetooth LE. So I successfully avoided a possible disaster of HSP/HFP not being possible. As a side note, have you considered using a hybrid transformer instead of echo cancellation in your device?

I second pcprogrammer's comment:  Make sure your DC input can ring the bell if you haven't already (they will ring, less loudly, on lower voltages).  Also make sure the levels into and out of your codec are ok.  The codec looks like it wants to drive a 8-16 ohm load.  Your old phone speaker might be higher impedance.  Fortunately the codec has an amp on the input for the microphone.  You might have to adjust that some however.

Yeah I'll look into the datasheet. I might end up using the speaker output rather than the mono output.

I think you should include a 1uF cap between EN and ground.  Espressif recommends (IIRC) a 22 uF + 0.1 uF bypass cap on the input which you more-or-less have with two distributed 10 uF caps on 3V3.  If you're running I2C at 400 kHz then I'd lower the values of the I2C pullups to something like 2.2 kohm.

The reset button and pullup resistor will be right next to the enable pin of the ESP32 module on the PCB, are you sure that's necessary. Espressif doesn't mention this practice in the datasheet either. As for the I²C pullups, I think I'll use 3.3k so I don't add another BOM entry. The line won't be long anyway.

Also, I'd recommend to include the ubiquitous 2-transistor auto-programming circuit using DTR# and RTS# from your USB UART (bring them out on H2) so you won't always have to be doing the BOOT/RESET button dance when you load code.

I don't even know if I have a USB-UART adapter that has those pins. I've been pressing boot and reset on my dev boards for ages anyway, and I'd like to save on board space and number of different components.

[Benta]

About the schematic, it can do with some improvements to make it a mix between what Benta is stating and what you made. Connecting everything with wires might make it unreadable too, due to a mishmash of wires. For this busses can be used, but labels work too.

That's normally not a problem if the parts are placed intelligently.

[globoy]

As a side note, have you considered using a hybrid transformer instead of echo cancellation in your device?

The entire reason echo cancellation came about was because telephone systems starting having significant latency and the hybrid transformers didn't work anymore.  Bluetooth/cellular connections have lots of latency...   One place you can read about it is at https://en.wikipedia.org/wiki/Telephone_hybrid.  There's also lots of interesting history about the development of EC on the innerwebs if you care.  I used a SLIC because it made the audio interface and impedance matching easy and could generate ring voltages for more than one telephone on a 2-wire interface.  Plus they're cheap.

But hacking an existing phone to get all 4 wires to the handset definitely makes the problem easier.

The reset button and pullup resistor will be right next to the enable pin of the ESP32 module on the PCB, are you sure that's necessary.

Look at Espressif's ESP32 design guidelines.  They claim EN needs to go high after power stabilizes and recommend a 10k/1uF combo.  The 1uF is definitely necessary if using the auto-programming circuit but I think it is a good addition even without it.

https://docs.espressif.com/projects/esp-hardware-design-guidelines/en/latest/esp32/esp-hardware-design-guidelines-en-master-esp32.pdf

"To ensure the correct power-up and reset timing, it is advised to add an RC delay circuit at the CHIP_PU pin. The recommended setting for the RC delay circuit is usually R = 10 kΩ and C = 1 μF. However, specific parameters should be adjusted based on the characteristics of the actual power supply and the power-up and reset timing of the chip."

[Zipdox]

That's normally not a problem if the parts are placed intelligently.

I'm perceiving your posts to be slightly hostile/passive-aggressive to be honest. This leads me to be slightly apprehensive about taking your advice. I think pcprogrammer's more nuanced comment is more reasonable.

[Benta]

I'm perceiving your posts to be slightly hostile/passive-aggressive to be honest. This leads me to be slightly apprehensive about taking your advice. I think pcprogrammer's more nuanced comment is more reasonable.

I apologise if they read that way, and admit that my first post comes over like that when rereading it.
I'm trying to be helpful. But helpful also means telling someone he/she is going down the wrong path.

Drawing schematics is a bit like writing a book: people need to be able to read it. Decades have passed and standards have been decided on how to write good documentation and draw readable schematics, so that people seeing a circuit will be able to understand and read it immediately.

I explained in a post how to do a better schematic, I hope that at least was helpful.
You need to think about the reader. That applies to both authors and designers.

[PlainName]

About the schematic, it can do with some improvements to make it a mix between what Benta is stating and what you made. Connecting everything with wires might make it unreadable too, due to a mishmash of wires. For this busses can be used, but labels work too.

That's normally not a problem if the parts are placed intelligently.

I'll just add that using schematic symbols that show pins grouped by functionality, rather the 'same as footprint' used here, helps enormously with schematic wiring.

[Zipdox]

I'll just add that using schematic symbols that show pins grouped by functionality, rather the 'same as footprint' used here, helps enormously with schematic wiring.

Sadly I don't think I have that luxury with EasyEDA.

[Benta]

Why not install KiCAD?

[PlainName]

That's normally not a problem if the parts are placed intelligently.

I'm perceiving your posts to be slightly hostile/passive-aggressive to be honest. This leads me to be slightly apprehensive about taking your advice. I think pcprogrammer's more nuanced comment is more reasonable.

He's not being too diplomatic because the issue you demonstrate is quite common, and getting worse as new designers follow the existing crap examples.

How about an example. Attached is something I am working on, so essentially it's just things (mostly!) placed without any editing of the parts yet. There are no pretty boxes saying what each thing does, no labels to scan and try to match to some other label. You may think it now as pretty as yours (obvs! - it's a work in progress, but it still won't be at the end, probably). But you don't need any of that stuff because you can see easily how everything connects, what they do and to what they do it. Nothing hidden, no searching. Things flow from left to right.

[Zipdox]

Why not install KiCAD?

I do have KiCAD, and I use it for other projects, but I couldn't be asked to make all the custom symbols and footprints in KiCAD.

[Benta]

Why not install KiCAD?

I do have KiCAD, and I use it for other projects, but I couldn't be asked to make all the custom symbols and footprints in KiCAD.

Seriously? Your EasyEDA thing doesn't have a lot of symbols not available in KiCAD (I didn't find any except for the screw terminals). And making a new symbol takes at most 5 minutes (if it's really complex).

[Zipdox]

Seriously? Your EasyEDA thing doesn't have a lot of symbols not available in KiCAD (I didn't find any except for the screw terminals). And making a new symbol takes at most 5 minutes (if it's really complex).

There's probably a way to do it but I'm lazy. This is more of a gimmick project.

[pcprogrammer]

I'll just add that using schematic symbols that show pins grouped by functionality, rather the 'same as footprint' used here, helps enormously with schematic wiring.

Sadly I don't think I have that luxury with EasyEDA.

Making your own symbols in EasyEDA is simple. I do it for most of my projects when I feel the provided ones do not suit my needs.

But about the schematic and the use of labels, I do not agree with the others. Yes it is becoming more common and makes it less readable on paper or image. With a PDF though it often is possible to search and the labels become highlighted. Dividing schematics parts in functionality is nothing new. In old schematics it is often done across multiple pages, each labeled with a name indicating what the section is for.

Also if it is just a private schematic to be used for making the PCB and not for use in a company, who gives a shit that it is just labels.

With proper chosen label names it can be obvious as to where to look for the other side of the connection.

In my opinion it is best to think about a careful balance between using wires, busses and labels.

As an example close to this project, in the schematic the pullup resistors for the I2C bus are right next to the ESP32 symbol. Here definitely wires should be used instead of having the two extra labels.

So conclusion, sure pointing out that a schematic is not super readable and can be improved is ok, but don't be aggressive about it. A single post with some pointers on how to improve will do. Benta's first post indeed comes across as aggressive and is not helpful at all.