The background of this project came from a need. How can I have a remotely camera, with no power connection,  to be able to capture upon demand a video or picture with small solar panel and compact design. So, from a receiver, one or 2 times by day, I want to capture and display the camera image. Rest of the time, the camera is charging from solar.

Technical concept:
The solar cam I built before was different, It sends on regular basis, one time every 1 or 2 hours a picture to a server. It used quite some energy to do that and it was not "live" picture.
So, I have to find a way to ask the camera to make the picture and send it to the receiver. 
As I plan to use ESP32cam as camera, it cannot be possible to wake up frequently the CPU (every 10 sec per example) to see if need to send back the live picture. It will use too much current.

So, I made some research to find what  RF modules can have very low energy consumption, working in 433Mhz or 868Mhz (walls to cross). Many modules has emitter in low energy but receiver always need lot of current. Until, I found some RF module called CMT2119 and CMT2219B from HopeRF. They exist in 433Mhz or 865Mhz. Chip is the same just some filter on the modules are different. 
 
The idea is to have only in standby the RF receiver. When it received the right command, it wakes up the ESPCam, open video channel, send the live video through an ESPNow link. After some time, stop the video stream, and go back to deepsleep, waiting new interruption from the RF receiver module. 

The beauty of these modules is they have some internal decoding function after proper programming. The receiver ca generate an IT to the ESP32Cam only if it received predefine information like preample, synchro work and a payload. Moreover, we can define a sleep and active period to listen to the emitter. In sleep mode, it uses only 80uA, and 8mA in active (receiving). We can define the period of sleeping and active. All of this is perfect for low consumption but the dark side is very complex to understand all the working way, to program them. The documentation is not clear, many application notes without coherence.  Spent countless hours and hundreds of SW version to find some way to use them. Even some features I could not find the way to use them (like variable length of payload).
Last, beside the preample and the synchro words, a node byte can be added. In the last version, I used this node to identify which camera need to wake up. So convenient... It can have 4 cameras, with same hardware and software and only the RF module which has the right node (camera ID) will wake up the device. 
I'll put in joined documents all the information I gathered for this project about these RF modules.
Each modules uses a spring antenna for 433Mhz.

ESPNow has a branch for sending video : 
/**************************************************

 * ESPNowCam video Receiver

 * by @hpsaturn Copyright (C) 2024

 * This file is part ESPNowCam tests project:

 * https://github.com/hpsaturn/ESPNowCam

**************************************************/

I'm using that branch.

ESPnow works better with 2 conditions: Define a fix channel and send to a fix MAc address.
I made a simple Wifi analyser to find which channel is less crowdy around me (between 1 to 14). If no channel defined, ESPNow will use the channel 1.

For the MAC address, it is more complicated. I'm using now 2 Receiver screen with 2 different MAC address. Moreover, I did not find very convenient to fix the MAC address in every camera software.  S, in the payload of the RF module, I added the MAC address of the receiver screen. So, the camera, when it wakes up and read the Fifo of the RF module, find the command (Start) follow by the MAC address to send to for the ESPNow communication. Working well !

I plan to make an evolution to check with the Receiver screen which Wifi Channel is less crowdy and to send it also in the payload... 

So, to summarize:
- One main receiver display, ESP32S3 with 2.8'' touch display (One sw version can work without touch screen). This display use 2 ports to control the emitter module CMT2119.
- One ESP32Cam connected to a receiver module based on CMT2219B (be careful, A version is completely different SW... I made by mistake the first SW based on it...)

The flow is like this:
1) Main display Send repeatedly a start command from the RF CMT2119
 2) The CMT2219B wakes up regularly (every 2.5sec) check if receive  preample and synchro words. If yes, stay wake up and capture the payload. After the internal FIFO contains the payload, genrate an It to wake up the ESP32Cam from deepsleep
3) The ESP32Cam wakes up and if find wakes up from an IT, read the FIFO of the RF module. If he fins Start command, open a link with ESPNow to the main display by sending an acknowledgement with some info (battery level)
4) When the main display received  ESPNow information, stop to send Start command and open a livestream video through ESPNow
5) After some time, the main display send stop command to the camera
 6) Either after receiving the stop command or after a timer, the ESP32Cam reactivate the RF receiver module and enters to deepsleep mode.
 
 Hardware part:

Main display and emitter module:

This part is quite simple. The ESP32S3 module has already battery connector, charging circuit. The I2C connector is used for the touch screen and the CMT2119 is not standard compliant with that. So, I use 2 dedicated GPIO (2 for Data, 3 for clock) to drive it. As, on that connector, there are no power supply, another connector (the one with I2C) need to be used th the +-3.3V.

I soldered directly an RF cable (after removing an 0 ohm) for external antenna.

Camera part:

Quite complicated here as the ESP32Cam does not have enough external GPIO and some cannot be used. Waste lot of time with that. Some GPIO are used for 2 functions like one to measure VBAT and command one register of the receiver module. Or use the GPIO0 (boot button) for camera ID.

The RF modules needs 5 GPIOs: CLK and Data, register selection and Fifo selection, one IT for wake up the ESP32Cam.

The ESP32Cam is powered by a module Buck/Boost based on TPS63070. It is very low consumption (after some modifications made on the module itself).
Also, the ESP32Cam has a major defect about the power of the camera. The 3.3v to the camera cannot be switch off despite other voltages can (1.2v and 2.4v). A track cut and add one wire to correct all of this. For the solar power protection and an under battery level protection, a dual voltage detector is used.
I described in detail all these modifications in another article here. 
https://www.elektormagazine.com/labs/esp32-low-consumption-power-supply-for-lithium-battery-solar-recharge

I made a PCBA for this part, which can be put into a waterproof "GoPro" style camera enclosure.

The ESP32Cam is using also an embedded Flash LED. To be able to reuse this GPIO, I remove the base resistor of the transistor which drives this flash LED.

To program the ESP32Cam, I made a connector which is connected to an USB-TTL board when it is needed.

Software:

These modules are not hobby friendly. They planed to be industrial use. There are some tools to configure them then to flash this configuration internally. But I cannot find the way to make it.
The second way, which is not clearly detailed, is to define the configuration needed through a free tools called RFPDK_V1.63 (my current version). 
=> After selecting the right chip, enter the configuration (like frequency, modulation,  preample, syncrho, sleep mode, etc.. for the receiver. 
=> Then, export all the parameters to a text file. This text file will contain a table with register adress and data to write in it.
=> Convert this file to a .h file, and transform manually these data to a "C language" table
=> Include this file in the main software
=> At init, create a loop to read all the table, address first then the data to write

That is working. With all the dozen or hundreds test done, I keep one .h file and begin to comment it with some modification which can be done, just by comparing the text file generated.

Overall, I use GFSK modulation. I started with OOK but the results were soso. The speed is 2400bps. 

The RF module: Emitter CMT2119:
First, as explained before, the chip needs to be initialized with the configuration file .h.
A loop will read the table and program the chip. 

This module is quite straight forward. He receives bits and he sent it. The speed of 2400bps need to be adjust it by software. 

#define SPEED 2400 // 2.4Kbps

#define TIME_BETWEEN_BIT 416 // us 416 for 2400 => 8 bits is 3ms in 100ms => 33 cars...

At switch on or after a screen tap (wake up from deepsleep), a standby screen. When we want to receive a picture we select the camera ID (1-4). 
A payload is build with Preample byte :
#define PREAM_VAL 0xAA

Synchro words: 2DD4A55A
#define LONG_VAL 1

#define SYNC_VAL1 0x2DD4

#if LONG_VAL

#define SYNC_VAL2 0xA55A

#endif

A Node byte is added for the Camera Id to wake up (1-4)

Then the full payload, 32 bytes, starting by the length of the use data:
"start"+ 0+ MAC Address
Or "stop"

Main Screen Receiver software:

ESPNow is already started when the start command is sending. Until there is an abord from the user or we begin to receive data from ESPNow, it is endless sending start command.
When we receive information from ESPNow, it's contain the battery level of the camera. This is stored in a table as well as the RSSI level (stored in a table too ).
After that, we move to the receive video function. This is displayed few frame by second. After 10 sec, we send stop command to the camera or earlier is user abord it. 

Last, come back to the home screen with possibility to see evolution of the cameras batteries or the last RSSI level. A sleep icon put the module in deepsleep, waiting a tap on the screen

 

Camera Software and RF module receiver:

Like before, the RF module needs to be program with the .h file as explained before. As the camera is in deepsleep, only in the case it's wakeup from an IT, the chip will not be configure (to not loose the Fifo data). 
During the init process (RF_Init()), many macro were created to read the chip status, or change his status, to configure the interruption state, etc... 
 
The battery level will be measured several time due to the use of larges resistors (200k) and avoid noise.  

If the wake up is from an Interruption, we checked if the fifo is full (the chip is program to generate It only when the fifo is full).

If the fifo return is not Start or stop, the camera return to deepsleep, waiting the next RF frame.
 
If the Fifo contains the start command, we read the MAC address of the sender, open the ESPNow channel and begin to send the images from the camera. 
 
The camera here can be 2Mpx or 5Mpx. 3Mpx has some issues. On my cases, I only use 5Mpx. I made countless tests on the camera configuration and the best one to match with the 320*240 receiver screen for me is:

    .pixel_format  = PIXFORMAT_JPEG,

    .frame_size    = FRAMESIZE_QVGA,  //QVGA|CIF|VGA|SVGA|XGA|SXGA|UXGA

    .jpeg_quality  = VALUE_JPEG,

    .fb_count      = 1,

    .fb_location   = CAMERA_FB_IN_DRAM,

    .grab_mode     = CAMERA_GRAB_WHEN_EMPTY,

 Overall implementation:

The receiver screen is put in a casing printed with a 3D printer. 2 RF SMA plugs on the top, one for the 433Mhz antenna, one for the 2.4G. I'm not completely happy yet with that. I'm afraid about too many losses. here. This part is powered by a 3000mAh Lithium battery, 10mm thick.

The ESPcam + RF module are on a PCB designed the a Gopro style waterproof enclosure. Only the small solar panel has wire outside. I was using a FPC antenna for the ESP32cam but many tests re still on going for the antenna part.

The overall consumption of the camera is reasonable, average 1.4mA. It is not yet as low as expected but I'm working on it. The main part is link to the cycle of sleep and wake up from the RF module. I think I can optimize some part on the power supply. One solution I'm working on is:
- Power the RF module with a buck dc-dc 2.4v
- When IT to wake up the camera, switch on the main DC-DC buck-boost to completely switch on the ESP32cam
- Keep the power on by the ESP32cam (but no GPIO available yet)

Feb 16th 2026. To be continue...

Laurent