Rick's b.log - 2021/04/11
It is the 21st of November 2024 You are 18.223.213.76, pleased to meet you!

Thursday shopping

This weekend

So I came home on Friday and it tipped down for about five minutes. Then the sun came out. Due to the wind or something, the grass wasn't actually that wet. Barely even damp. One look at the weather forecast and I fired up Marte.

Mowing.

This turns out to have been a good call. On Saturday we were on yellow alert for Pluie/Inondation (Rain/Flood). It didn't rain that much, but it did rain for most of the day. The pretty pink Saxifrage looked flattened. That's the thing about this place, and why the ditches along the sides of the roads are at least half a metre deep - it doesn't rain "all day" like it often did in southern England. Our rain is fairly brief, but rather hard. So a "rainy day" is not endless rain, but bursts of heavy rain passing through.
And pass they did yesterday.
And today... <sigh>

ESP32-CAM

It seemed to me that the best explanation for this would be that the supplied ESP32-CAM board was duff. However, there was also the question of perhaps this is simply because my ESP32 setup was too old? I had the board definitions 1.0.4, so I decided to update to 1.0.6.

Big mistake.

This undid the custom patches that I had put in to use Python 2.7 (the supplied executables don't work on my older system). I had a look at the settings file and it is laid out differently. I'm not sure where/how to patch in the references to the standalone build of Python.
After persisting for several hours, most of this time waiting for the bloody compiler, I eventually decided to revert to the 1.0.4 setup. At this point the Arduino IDE, which deleted the 1.0.4 stuff when upgrading to the newer (and I note the bug where it deletes all the files and then complains about all the missing header files), installed 1.0.4 alongside 1.0.6. This confused the hell out of things, leading to all compilation failing because the board type was unknown.

So I deleted the entire ESP32 directory and manually reinstalled 1.0.4 and then reapplied my Python patches once again.

Clearly I was not in the best of moods by this time. I had, to test the system, set up a very simple program that prints a message to the serial port as the system starts up, and then every two seconds in the main loop.

This took about ten minutes to build, leading to an absolute disaster that looks like this:

Building a really simple program.

Seriously, the system is aware when the board settings change (the camera is the Wrover module, my NetRadio is a standard ESP32) and it rebuilds everything in that situation. So why the hell does it rebuild everything all the time? This is probably why the system is so unbelievably slow. It really shouldn't take that long and that many resources in order to build such a simple thing.

I got myself a cheap replacement ESP32-CAM module from Amazon, so after the failure of the original board, I tried the replacement. And, sadly, despite absolutely no changes to the code, the thing insisted upon a complete rebuild.
I went and put the kettle on, made tea, took the cats for a walk and a meat stick each (because they weren't impressed by the rain). When I came back, it was still chugging away.

The firmware built and burned into the new ESP32-CAM, boot was more promising:

   ets Jun  8 2016 00:22:57

   rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
   configsip: 0, SPIWP:0xee
   clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
   mode:DIO, clock div:1
   load:0x3fff0018,len:4
   load:0x3fff001c,len:1216
   ho 0 tail 12 room 4
   load:0x40078000,len:9720
   ho 0 tail 12 room 4
   load:0x40080400,len:6352
   entry 0x400806b8

   Starting up
   Initialising camera
   Initialising WiFi
   .
   WiFi connected
   Starting server
   Starting web server on port: '80'
   Starting stream server on port: '81'
   Camera Ready! Use 'http://192.168.1.28' to connect

The exact same thing programmed into the original board failed, with the boot failure as given in the log at the beginning, and the lamp illuminated weakly. Whatever, it doesn't work.

Both ESP32-CAM boards.

It had been allocated the IP address of 192.168.1.28, so dropping that into my browser opened with a screen containing a ridiculous number of options.
Now we're cooking with gas!

Camera UI.

The camera, taped to the front window, worked pretty well for a cheap and simple camera module.

ESP32-CAM taped to window.

Image sizes vary from QQVGA (160×120) up to UXGA (1600×1200).
It appears that, internally, the camera has three modes of operation. These pictures have been taken at the same time, with all default settings except the saturation has been set to +1 (it gives a more pleasing picture at full resolution).

• Image sizes above 800×600 have nice colour and definition.
  
  UXGA capture (scaled to 680px width).
• 640×480 and 800×600 have colours that seem a little washed out with over-emphasised greens.
  
  SVGA capture (scaled to 680px width).
• 400×296 and below have very washed out colours.
  
  CIF capture.

To give some context, here is a full-size snippet of the UXGA image.

Snippet from UXGA image.

The camera itself was the world's first ¼ inch two megapixel camera with 2.2 micron sized pixels. It was originally released in 2005, and discontinued in 2009. It is still found quite a lot these days, even though it doesn't compare with the likes of modern cameras on smartphones and such, because it offers three things that are very useful. Firstly, it is cheap. Secondly, it has a fairly simple parallel interface (DVP) which is easier to interface than interfaces such as MIPI. Thirdly, it has an onboard hardware JPEG encoder, so a lot of the grunt work (and required memory) can be offloaded to the camera module itself rather than whatever microcontroller it is connected to - including the Arduino!
To put this into context, extracting a full size RGB565 image will require around three and a half megabytes, plus whatever workspace and processing power is necessary for encoding the image. The same thing as a JPEG is already processed and will be somewhere around a quarter of a megabyte (depending on what it is an image of, and the quality settings in use).

In terms of speed, with a quality of 10 (higher is better), it can manage around 2fps at full resolution. XGA gets about 4fps. The 'default' of CIF (400×296) runs at around 15-16fps. 25fps is possible at HQVGA (240×175).

Oddly, sizes 1 and 2 are not defined in the UI. Size 2 is 176×144, and size 1 is 128×160 - some sort of anamorphic?

By playing with the quality setting, it is possible to trade image quality for speed. At a quality of 40, SVGA can run at around 10fps, rather than around 4fps.

These figures should be taken with a pinch of salt, however, as quality settings above 30 (higher is worse) do little to the framerate but have a big impact on speed. I suspect the camera module may have hardware JPEG encoding, and the limiting factor here is not so much the encoding but how fast the data can be sent via WiFi. The camera module itself claims to be capable of 15fps at UXGA and 60fps at CIF.

It is possible to set quality options lower than 10 (lower is better). Less than 5 may result in incomplete images.

How do I do these things behind the back of the UI?

By talking to the camera directly. Assuming your camera's IP address is 192.168.1.28...

http://192.168.1.28/capture will create a JPEG of what the camera currently sees, using the current settings.

http://192.168.1.28/status will return an XML file with JSON format data giving the current settings.

http://192.168.1.28/control?var=<what>&val=<how> is the magic incantation to alter the settings.
To change the image size, for instance, the 'what' would be framesize and the 'how' would be a number such as 10 (UXGA, maximum), 7 (SVGA), or 4 (QVGA), etc.
For adjusting the image quality, the 'what' is quality, and the 'how' is a number from 1 to 100 (higher is better).

I don't know what Raw GMA means, however it seems to me that the images may be better when it is disabled. It seems to overly brighten the images (with a side effect of enhancing noise). Set 'what' to raw_gma, with 'how' to 0 to disable, or 1 to enable.

The stream is available at http://192.168.1.28:81/stream - note that we're using port 81. This can be viewed in Firefox and the like, but it cannot be seen in NetSurf or the likes of VLC or MPlayer. Why? Because it is sent as a sequence of JPEGs with MIME headers in between each of them.
The file begins like this:

  Content-Type: image/jpeg
  Content-Length: 95801

  --123456789000000000000987654321
  Content-Type: image/jpeg
  Content-Length: 104810

Apparently FFPlay can handle this, though I haven't managed to get it to do so.

Note that the video stream may be rather noisy with visible image corruption, which is more pronounced in lower resolution modes. I suspect that the WiFi broadcasts are interfering with the unshielded camera and/or the thin ribbon cable connecting the camera to the ESP32.
There is no obvious interference when taking single shots, as demonstrated in the above pictures, because WiFi isn't active at the exact moment data is being received from the camera.

SVGA capture (scaled) with visible corruption.

Oh FFS... I had the PC on while I was writing this, so I decided to just rebuild the CameraWebServer and dump it onto the original ESP32-CAM so I could get a record of what it actually said as it booted.
What it says now? Can't find the camera module.
What?!? So now it decides to work?

I've ordered a camera module from Amazon. Coming from China, it'll be here before June, I hope. ☺

Games

The first game is from somebody well known in the RISC OS games world. That is all I shall say about this game, as I notice that there's nothing on the ROOL forum, so this project shall be considered to be "under covers" for now.

The second game has been mentioned. It's a game called Exeria94 by SoftRockSoftware, aka Vince Hudd. Who has not updated his blog in ages. The way things are in Modern Times and no updates? God (or whatever) is handing out a reality so utterly messed up that Charlie Booker largely failed to satirise it in his special "Death to 2020". There's so much one could talk about. Vaccines, Bill Gates and trackers, politics, Brexit in the midst of the maelstrom in the toilet bowl...

But we're getting off topic. The topic is Exeria Ninety-Four 😜 which is an interesting take on the classic PacMan formula.

Essentially, you're a little yellow dude. And you have to collect shiny diamond things while avoiding... I suppose they're meant to be ghosts. They look more like spike proteins to me. So, it's simple right? Collect this while avoiding that?

Not so fast.

Exeria (scaled down from FullHD)

You see there are some red boxes? You must collect all of the red crystals to unlock those red boxes. And you must collect the orange ones to unlock the orange boxes. Ditto for the yellow, then the green, and finally the blue to collect the final (white) crystal to exit the level.
Not so fast. Apparently you are leaving an invisible trail. Normally the ghosts/proteins are deterministic to the point of being rather dumb. but once the blue crystals are unlocked, the ghosts turn blue and gain the ability to be able to follow your trail. If you're a hopeless player like me, death soon follows.
Something that can be a real boon, or a hindrance if you don't stop in time and run into a ghost, is that you are not bounded by the screen. You see the bottom line of red crystals? How to get to the right hand side. It's easy. Move to the left, and keep going. You'll wrap around to the right. Thankfully the ghosts can't do this. Or, at least, not yet.

A nice touch is that your little yellow guy starts off reasonably content with life , clearly oblivious to the danger. But as you lose lives, (s)he starts to lose patience...
Yes, the game character is passing judgement on your playing skills.

It was almost a disappointment to see a generic "Game over" message. I was expecting something like "My grandma could play better than you and she's dead". ☺

It's quite a fun game, and requires a bit more skill than is immediately obvious. I like that it remembers what screen you were playing, so you can start from that level. With no points, of course, but you're not right back to the beginning.

Apparently the sound effects are a bit OTT. I cannot say. I was listening to my NetRadio (currently playing Tarja's "Serene"...and now "Unchain Utopia by Epica). So I was playing it without sound effects.

Visually, I like the style and presentation. It's interesting to see what BASIC is capable of on modern machines.

Your comments:

Rick, 12th April 2021, 18:33

Fixed the mobile version. I had accidentally uploaded the entire version that I use here when writing, which begins with "base href" so the live images appear when I'm viewing locally.  Turns out that this confused the hell out of the DOM parser, which just gave up and returned emptiness.  Oops. 😉

VinceH, 13th April 2021, 00:40

October. Yeah. That's a few months ago... it's about time I posted something.    I have a folder full of notes for things to post but I just haven't sat down and turned the notes into anything complete, ready for upload. Contenders include Virgin Media's daftness (a saga about a telephone line they didn't install, and when trying to contact me about it, they apparently kept trying to do so via that line), my ludicrously high BP (found some paperwork from the hospital recently), a replacement tribute page to my dog Jenna (1993-2004), some additional pandumbic entries, mailing list users who persistently try to use a mailing list as a web forum, old badly drawn adverts of mine, and a few other things.    There are also some things I soooooo want to write (moan) about but I'd be better doing either anonymously, or waiting until certain circumstances in my life change.    And I think a little history of Escape from Exeria might make a good addition to the list as well.    I'll try to get something up soon.