Intercom / doorbell cam

[jharvey]

@s60sc I'm designing an intercom / doorbell cam. My goal is hardwire intercom for a small school. I plan to build around 5 to use as door bell cameras at my home. If that work, then the school would be the next goal. I decided to design a board, incorporating many of the features found in your project. Could / would you be interested in reviewing my draft layout below?

https://github.com/jharvey/ESP32S3_Audio_Cam_POE/

Key features include
-- camera
-- POE ethernet
-- bi-directional audio
-- push buttons
-- RC servo IO for pan, tilt, rotation, other
-- light control including White, IR, laser pointer, RGB
-- SD card
-- Current sense, so it can monitor it's energy usage
-- temperature sensor so it can selectively shutdown features noted above if it gets to hot.

Now that I have a general idea of the longer term plan, I'll get back to prototyping with my misc. off the shelf parts. Any review or comments would be greatly apricated.

[s60sc]

link gives a 404
Im a coder with a basic knowledge of electronics, so Im not qualified to review a circuit layout. I know that ground planes and trace interference can be an issue for high clock rate signals

[jharvey]

Oops, it's visibility was private. Sorry about that. I just changed it to public. You should be able to view it now. Let me know if it's not visible. I originally had it private just to prevent bad designs from getting out and causing problems. Now that I'm looking to collaborate with others it should be public.

[rjsachse]

Hi! I reviewed your KiCad board design and spotted a few areas for potential improvement:

1. SD Card Interface: You’re using SPI for the SD card, which works but is slower. Switching to MMC 1-bit mode could save one pin and boost read/write speeds for better performance.
2. I2S Audio: Full-duplex I2S audio only needs 4 pins for two-way communication. Your setup seems to use more, which might be overkill. Streamlining this could simplify the design.
3. Dual ESP32-S3: Using two ESP32-S3 modules seems excessive unless there’s a specific use case. A single ESP32-S3 or a different MCU pairing (e.g., Arduino + ESP32) might reduce cost and complexity.
4. USB ESD Protection: The USB ESD configuration looks off. I’d recommend verifying the ESD protection IC’s connections against its datasheet to ensure signal integrity.
5. PSRAM Absence: Without PSRAM, the ESP32-S3’s camera functionality may struggle due to limited memory. Adding PSRAM could improve camera performance.

I’m working on a similar ESP32-S3-based doorbell camera with an AXP2101 PMU, and I’m the author of an RTSP server library and an upcoming ONVIF server library. Our projects have some overlap, so I’m curious—why did you opt for dual ESP32-S3s and SPI over MMC?

Great work on the design, and best of luck with your project!

[jharvey]

Hello and thank you for the review. It's slow / sporadic progress, Active family life influences my progress.

1. I'll have to learn more about the SD card. I just copied a reference project which seemed to match my demo board. I don't know that much about what's happening underneath. I'll look closer at this. I've done SD stuff before, but I didn't look to closely at this part of the project.
2. I've been learning more about I2S. I understand the left and right channels better now. I need to learn more about the SPK.LRCLK signal. Perhaps I don't need that connected to the ESP32. I'm still learning this speaker chip.
3. I used the ESP32 as a port expander because I was looking to add features and running out of IO. I see the code already has the expansion capability via 232 stream. The ESP32 is reasonably low cost, so I figured use it. Longer term, the extra processing power might be handy. I'm aiming for basic intercom's to be handled by 1 ESP32, with additional features handled by the 2nd processor. Long term I want pan, tilt, rotate servos so I can point a laser pointer at bad people if they approach. Any distractions to a bad person is a good thing. As well making a laser pointer device into a strategically placed target with a safe backdrop is also valuable. My easier to obtain goals is just audio intercoms, followed by video and NVR integration. I have a long list of desired features, with incremental steps of progression.
4. Thanks for the heads up on the USB protection chip. I used another project as the starting point. I figured that project has validated this, so I didn't look closely. I'm adding it to my list to look closer at it.
5. I'm not following the PSRAM comments. I'm reasonably ignorant about PSRAM. I know I configure it in the IDE, but I don't really know what is is or how it works. I thought it was internal to the ESP32.

Pleasure to meet you. I wish I was at your level for software. I'm chipping away at this 10 minutes at a time. I'm expecting software is going to be my key obstacle. Is your project something you can share? I can offer to do a review if shared with me.

Some years ago I made the below guides to help steer the design efforts over there. I try to obtain those goals.
https://github.com/rusefi/rusefi/wiki/Dev-Hardware-Guidelines
https://github.com/rusefi/rusefi/wiki/PCB-Design-Rules

[jharvey]

I think this is operating in 1 bit mode, not SPI mode. I see in utilsFS.cpp

/* The following #defines must be declared under the relevant camera entry in camera_pins.h
   1 bit       4 bit        
   SD_MMC_CMD  SD_MMC_CMD  
   SD_MMC_CLK  SD_MMC_CLK   
   SD_MMC_D0   SD_MMC_D0    
               SD_MMC_D1     
               SD_MMC_D2    
               SD_MMC_D3 

As well

#else
 #if defined(SD_MMC_D1)
  // assume 4 bit mode
  SD_MMC.setPins(SD_MMC_CLK, SD_MMC_CMD, SD_MMC_D0, SD_MMC_D1, SD_MMC_D2, SD_MMC_D3);
  use1bitMode = false;
 #else
  // assume 1 bit mode
  SD_MMC.setPins(SD_MMC_CLK, SD_MMC_CMD, SD_MMC_D0);
 #endif
#endif
#endif
  
  res = SD_MMC.begin("/sdcard", use1bitMode, formatIfMountFailed, sdmmcFreq);

In camera_pins.h I didn't define SD_MMC_D1, so I expect it defaulted to 1 bit mode.

// Define SD Pins
#define SD_MMC_CLK 7        //
#define SD_MMC_CMD 6        // CMD/DI/MOSI
#define SD_MMC_D0 5         // DAT0/D0/MISO
// Chip select pin is GPIO4, this has 10k pull up, so non-configured pin will default to being selected, but beware that pin may be important.

Perhaps I'm missing something. I'll move along on this one for now. I think it's OK. Perhaps my notes are not as good as they could be. I added the SO and SI in my comments, which may have triggered to think it was SPI.

[jharvey]

@rjsachse Did you happen to look over the POE ETH? I really like the POE and hardwired coms. I expect software needs to be changed if POE ETH is to be added to a project. At this site https://www.waveshare.com/wiki/ESP32-S3-ETH they posted https://files.waveshare.com/wiki/ESP32-S3-ETH/ESP32-S3-ETH-Demo-V2.zip and in that zip they include the example ETH_Web_CAM.ino In that example it uses the WiFi library, which we have all grown to love, but it gets modified with ETH.begin and ETH.config to use the W5500 chip via SPI instead of the internal WiFi.

Any chance you would have interest in modifying ESP32-CAM_MJPEG2SD I can test it. I've got a ESP32-S3-ETH (non POE version). I suspect your skills will be much better about adding it then my skills. My software skills are more armature then pro.

I see your 2 way audio repo. That looks interesting. I'm not sure what it does. I think it does some kind of 2 way audio with a web socket. Do you know when I2S is in PDM mode, can it share the clock for both DI and DO, perhaps getting full duplex stereo in 3 wires?

Hmmm, I'm growing less interested in MAX98357AETE+T it seems that LRCLK signal is required and is required to toggle. Which consumes another IO on the ESP32. Do you have a chip you might suggest for the audio amplifier? I'm planning on a small 4ohm 3 watt speaker.