Having troubles compiling

[xenpac]

Having troubles compiling

[Elerir]

Hello,
As described in espressif/esp-idf#6293, I managed to solve my issue by adding i2c_config.clk_flags = 0; to ESP32-CAM-Linux-Motion/components/esp32-camera-master/driver/sccb.c

Thus, in order to compile this project with a newer version (4.4) of the one you used :

• Remove #include "eth_phy/phy_lan8720.h" from ESP32-CAM-Linux-Motion/main/espcam2640.c
• Disable the other camera sensors via make menuconfig : I only kept the OV2640
• Adds i2c_config.clk_flags = 0; before i2c_param_config(SCCB_I2C_PORT, &conf); in ESP32-CAM-Linux-Motion/components/esp32-camera-master/driver/sccb.c

Hope this helps

[xenpac]

Hi elerir,
Well, i am using linux to compile these projects.
You need ESP-IDF from: https://github.com/espressif/esp-idf The crosscompiler from: https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.0.tar.gz

When downloaded, you need to clone this project to somewhere in your system.
open a terminal window.
go to the project directory.
type: (use yourpath=whats where you put the destination.)
export IDF_PATH=/yourpath/esp-idf
export IDF_TOOLS_PATH=/yourpath/xtensa-esp32-elf/bin

make menuconfig
first item, select, enter the path to your compiler.
save.

make

this should compile the project.

-....
yes, it resets after 5 retrys of connecting.
if during that period of retrys the ip address is lost(there is a timer somewhere in idf), the tcp/ip stack stops working.(not my fault)
So once the IP address is lost(timer), tcp/ip stack stops working(server), even though wifi reconnects.
This is a dilema.

it is done with 5 retrys to solve situations where you suddenly loose connection and try to reconnect.
on the other hand, yes, maybe we should set the retrys to 0.
maybe i should update that. (you would loose all custom settings then)

[xenpac]

PS. i checked the configuration value of the TCP/IP-Adapters IPaddress_lost_timer.
Its set to 120 seconds, so plenty of time for doing 5 retrys.
If after 5 retrys no connection can be established the device will reboot to try a fresh wifi connect.

It should work as it is.
If you are having trouble, please report.

[Elerir]

Hello, thanks for your answer.
I'll try this by the end of the week.
About the connection retry, increasing from 5 retries to "unlimited" was necessary for my project, since a power outage could switch off the router for more than 120sec (and even if the ESP would also be off, the router could need more than 120sec to get wifi back)

[xenpac]

Yes, if your router is down, the device will continuously reset....until it can establish a valid/configured connection.
This might be going on for ...days. Its not harmrfull.
you will see the little red LED being on in the reset/restart phase, indicating it is looking for a connection.
if device looses power the same thing applys. (it just restarts)
if you keep the "retrys" unlimited, you loose the last known IP and the server would not work any more.

[Elerir]

Okay, so the esp indeed resets after 5 failed connection retries.
Is there an advantage of trying 5 times before reseting ? I mean, we could reset the board after 1-2 retries.

[xenpac]

The IPaddress is assigned by the router to the device at connection setup.
if you loose connection, the devices IPstack will throw the IPaddress away after a while, because....its not valid any more.
it might receive a different IPaddress next time it connects.
In cases where wifi signal is week, you might get connection dropouts that last only very short.
Both, router and device, keep the last assigned IPaddress for a litle while, hoping that wifi sgnal comes back,
in which case reconnect is fast and does not need a new IPaddress assignment.
Thats what the 5 retrys are for.

But yes, you could set the rertys to 0.

[Elerir]

Yeah, but this problem would occur only if the router assigns this old IP to another device, right ?
So, setting a static IP for the ESP should work
Anyway thanks for your help I'll give it a try this week end

EDIT, reply to myself : Nah, even if the IP is not re-assigned, it would probably wouldnt work since the router's ipstack would considers the connection as failed and not anymore in "time_wait".

[xenpac]

Yes, in most cases the router memorizes the IPaddress in connection with the unique MAC address of the device.

in this software, if the IPaddress is lost, the IPstack doesnt work properly any more and the server cannt communicate.
Thats the main problem and why i then just reset the device to have a fresh start.

Configure fixed IP addresses for the Cams in your router.....for linux motion.

[Elerir]

For some reasons it was not working with this compiler version. However it almost did work with the last version.
I also had to enable some settings as described there maximkulkin/esp32-homekit-camera#57
And finally, I had to disable the other camera sensors. I only kept the OV2640... But now I'm stuck with the ethernet driver that has been changed.. I think I'll try to find why I didnt compile with your version :D
By removing #include "eth_phy/phy_lan8720.h" from ESP32-CAM-Linux-Motion/main/espcam2640.c.. it compiled... but it was certainly here for a reason... I'll try to push this to my esp this week end

[Elerir]

i got
I (2961) gpio: GPIO[32]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulld own: 0| Intr:0 E (4001) i2c: i2c_set_pin(825): scl and sda gpio numbers are the same
at camera init
I'll look at espressif/esp-idf#6293. Thanks again

[xenpac]

yeah the "eth_phy/phy_lan8720.h" is a leftover and can be removed. didnt hurt.

To see your current ESP-IDF Version, goto esp-idf directory.
type: git describe

my project was compiled towards the long term support version V3.3.1

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html
https://docs.espressif.com/projects/esp-idf/en/v3.3.3/get-started/index.html
https://github.com/espressif/esp-idf/releases

The worklow to get esp-idf for V3.3.1 :
git clone -b v3.3.1 --recursive https://github.com/espressif/esp-idf.git

get the compiler gzip file:
https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.0.tar.gz
use linux filemanager "extract here" to extract the compiler to a destination.

get the camera project:
git clone https://github.com/xenpac/ESP32-CAM-Linux-Motion.git

export IDF_PATH=/esp/esp-idf
export IDF_TOOLS_PATH=/esp/xtensa-esp32-elf/bin

cd espcam2640

make menuconfig
first item, select, enter the path to your compiler.
save...exit

make

it takes a while until everything is compiled.
when finished type:
make flash monitor

assuming you have th serial adapter at ttyUSB0 with the device.
after flashing it will reboot (or you have to manually press the reset button or powercycle.)

with serial connected, you can watch the logs in the terminal.

[user5518]

During the execution of "install.sh" in the "esp-idf"-dir, I got this error:
ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.
This fixed it:
pip install --upgrade virtualenv==16.7.9

And during "make", I got this error:
curses.h: No such file or directory
Here was the solution to install these libraries:
sudo apt-get install libncurses5-dev libncursesw5-dev

Then, I was able to compile the source-code and upload it to my ESP32-Cam.

Do you have a hint how I can include libraries like the DHT-one (https://github.com/adafruit/DHT-sensor-library)? (I want to use a DHT22 on the ESP32-Cam.)

[xenpac]

i never use "install.sh". just procedure above.
this conforms to the old style make build.

[hedgemybets]

Great project, thanks for the effort. I've been using the original binaries and decided I'd try to compile with a newer version. In my case I've installed the ESP-IDF v4.3 on Windows 10.

I found a few other issues in addition to what Elerir encountered preventing compilation in my environment:

1. Added missing closing parenthesis in .\main\CMakelist.txt on line 9.
2. Used "idf.py menuconfig" to configure accepting ESP32 RTC gpio pin definitions. This is in Component config > driver configurations > RTCI0 configuration
3. Added esp_http_server as component in .\main\CMakelist.txt.
4. Added missing source code components in .\components\esp32-camera-master\CMakelist.txt:
   conversions\jpge.cpp
   conversions\yuv.c

I'll test flashing the new binaries on a new ESP32-CAM when it comes in.

The only issue I've had with the original binaries is that intermittently (once a week or so?) I get connection errors downloading an image from the capture URL to an Ubuntu PC. The errors seem to be connection refused or timeout errors. However, when this happens I can still ping the ESP32 from the same machine, so it still seems to have WiFi connectivity. Once the errors start occurring, I have to power cycle the ESP32 and it always comes back to life. I've just put in some better error reporting in my Linux app so I may get additional clues soon. Maybe just a flaky module...

My application simply downloads a UXGA-resolution image once every five minutes using the flashlight feature for monitoring a meter in a dark and difficult to access location.

[hedgemybets]

I was able to flash the binaries to a new ESP32-CAM and I have it working! I found one additional issue. I had to adjust the fix that Elerir provided for i2c to this:
--Add conf.clk_flags = 0; before i2c_param_config(SCCB_I2C_PORT, &conf); in ESP32-CAM-Linux-Motion/components/esp32-camera-master/driver/sccb.c

[xenpac]

thanks,will update to idf 4.3 with fixes

[xenpac]

@hedgemybets
just noticed you are using the cam to read a gas/electric/water - meter.
interesting application.
yeah - using CamIP/download with flashlight enabled, you can download the iluminated image of your meter to your computer or cloud-server from the remote meter/camera-location.

[hedgemybets]

Yes, my app uses a Keras machine learning model running on a PC. I trained the model to classify images downloaded from the ESP32-CAM running your code. It determines the state of my water softener under the house. This is based on meter dial position.

BTW, your latest updates providing the ESP restart when there are connection issues solved my problem from before. Thanks!

[xenpac]

please look into the closed issues for further help ! ;)