Rick's b.log - 2023/03/26
It is the 24th of November 2024 You are 18.118.255.51, pleased to meet you!

Hailstorm

...I went to feed furball at about 6.30am, which was pitch black as it was half five. This stupid hour change gets on my nerves.

It was drizzling lightly. No big deal. As I was walking, I heard a weird noise. I briefly wondered what bizarre agricultural machine would make such a noise.

No sooner than I had greeted Anna, she turned and fled as the heavens opened with a violently strong southerly wind meaning being under the shelter of the stable was... actually barely any shelter at all.

I popped the food into her bowl, and then decided that I'd have to make it back to the house. My bottom half was getting wet, and since it wasn't particularly warm I had a winter coat on so that would keep me dry.

By the time I made it to the end of the field, I was drenched from the waist down, a mixture of hail and torrential rain. By the time I made it to the front door, the hail was about an inch deep.
It carried on for another few minutes, adding another inch to the hail, before turning to rain which helped to melt away the hail, but not in a hurry as the temperature nosedived to 5°C.

I took my soggy clothes off, put on something dry, made a tea, then went back to bed. Hell with that!

Though, as I write this it's half seven in the evening and the sun is out. I don't regret having the extra daylight in the evening, especially when I come home from work.

ESP32-Cam fiddling

Anyway, a pile of fiddling later (I hate the dev environment so much, it's painfully slow), I have made the following changes to the default (original) camera server.

• Now handles more concurrent sessions. So hopefully it won't be quite so prone to falling over with the browser saying the server sent back a blank response.
• If a connection cannot be made to the primary access point, it'll try a secondary one. If it still cannot connect, the device will reboot and keep on looping like this.
  This is to cater for my setup where when I'm in my room, the Vonets has a better signal than the Livebox, that the crappy little built-in antenna on the ESP32-CAM often fails to capture.
  The looping reboots are to cater for power cuts. Eventually the Livebox will have started. ☺
• Now makes use of the little red notification LED around the back. It's on as the board boots, flashing while connecting to WiFi, and off unless there's a capture (on while sending JPEG), or request for index, status, or stream (it'll flash quickly at the end of each).
• Moved the buttons for getting a still and for streaming MJPEG to the top, out of the menu panel so the settings can be closed with the useful buttons still accessible.
• Removed the icky gzip encoded bytes of the served HTML and replaced that with a literal string holding the html. Slightly larger, but now it can be edited.
• Pulled out all of that face detection rubbish. It doesn't work on the standard ESP32 because it takes far too long, needs the improved S3 version. Also, it only works at low (like CIF and below) frame sizes. So... yeah...
  This made a huge difference. Before, the firmware used 2,114,351 bytes (67%) of the 3MB "huge app" program storage, with the variables using ~52K (16%) of the 324K RAM.
  Now? The firmware uses 797,254 bytes (25%) of the storage space. This means that it is actually now possible to build it for different allocations, such as 1MB app + 3MB SPFFS (no OTA), though I still have it running as a huge app because I don't need SPFFS. But it's nice to have the option. Also pulling the face detection out drops the variables to around 48½K (15%). Not a big change, but any gain is welcome.
• A lot more trace information sent to the serial port, so it doesn't print a startup message and then sit there in silence from then on. This is only of use if things don't work. ☺
• Changed the camera startup to allocate much more memory to the image buffer, so the camera no longer chokes if a JPEG exceeds the usual 384,000 byte limit. It looks good up to around 720K. Much above that, the camera will fault being unable to get the frame on time.
• Because of a lack of finesse with the quality slider, it constrains the quality to not go below 5 if the image size is UXGA. This ought to be good enough for most scenes.
• Added an extra config option "forcequality" which will set any quality without clipping in UXGA mode. Because, you know, you always need a way. ☺
• Note: This will cause my ESP32Cam application to crash. It allocates 412K for the frame buffer, as the standard build of the camera cannot cope with images that are more than 380K. I'll fix it "soon".
• The status data now includes "access_point":"xxxx" where the xxxx is the name of the current access point.

Here's the new slimmed-down interface, once the control panel has been hidden. The image is noisy because I bumped the ACG right up as it was sunset. The camera itself is old tech (from around 2005?) so it doesn't cope particularly well with low light conditions.

The ESP32Cam web page.

Looking from the other side, you can see the notification LED letting me know that images are being sent.

The ESP32Cam in action.

There are more things I'd like to add. As is usual, it's pleasing to get the little ESP32 board to do my bidding, and just taking some random pictures here, there's a clear difference in file size between a quality of 10 (182K) and a quality of 5 (574K).
I don't think taking a snapshot of my screen and clipping a bit in the middle of each survived the conversion to the blog's 680 pixel standard.

Spot the difference. ;)

Your comments:

No comments yet...