Had to go shopping on Thursday after work. So I checked that I had my paperwork, and then I went into Autistic Mode with headphones and sunglasses, indoors. I was giving out plenty of "leave me alone" messages.
Which the police actually paid attention to. There were two standing just inside the doorway checking paperwork of random people. One looked at me, then turned to talk to somebody else.
So I did my shopping in peace. Well, not exactly peace, I was listening to PPN, but able to rest in a happily noncommunicative mode.
It's a strange perceptual thing. This week was a day shorter than usual, due to Easter Monday, however by Friday it felt like a long tiring week. I spoke to some of the girls at work, and I wasn't the only one to feel this way.
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.
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>
My efforts at programming the default CameraWebServer into the ESP32-CAM module continually resulted in failure. The IDE would build it, program it, and... it failed to boot, illuminating the 'flash' LED dimly and outputting a message to the serial port that indicated that it wasn't able to load from flash.
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.
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
mode:DIO, clock div:1
ho 0 tail 12 room 4
ho 0 tail 12 room 4
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!
The image corruption is because the image resizes to be larger when I scroll down. No idea why it does this, some script trying to be too clever...
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).
I suspect at SVGA, it is sampling every other pixel for speed, and at CIF it starts to sample every fourth pixel.
- 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.
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).
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:
and then the JPEG follows. When done, the file continues:
and another JPEG follows.
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. ☺
I help to beta-test games. Now, I will make no claim to be a gamer. I suck more than the telling of it. However, I can give a perspective of a newbie clueless user, I will mash all sorts of keys, and I'll try Alt-Break (which all too often stiffs the machine!) if the programmer doesn't provide a way to give up and exit out of the game.
Plus, I'll rummage around in the source code.
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.
Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.
|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.
|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.
(Felicity? Marte? Find out!)
List all b.log entries
Return to the site index
PS: Don't try to be clever.
It's a simple substring match.
Last read at 14:55 on 2022/01/20.
© 2021 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.