Wifi Cam - Stage 1

23/02/2015
Wifi Cam - stage 1

Moved into designing my own PCB, used ST32CubeMX to choose functional blocks to I can get pin-out. Ordered components, mostly laid out.
Sticking points:

I would like ESP8266 with flow control (RTS/CTS), I don't know if that is possible with SDK and broken out pin sets, need to investigate.

I am not sure enough of use of BOOT0 pin, need to figure it out, not clear from datasheet or Discovery.

28/02/2015

ESP8266 has RTS/CTS support with latest SDK, but it's on pins not available on ESP8266-01 but are available on ESP8266-03. Alter design to wire up ESP8266 instead of plug in, that way I can use any.

Sussed BOOT0 pin, just needed pull-up.

Laid out PCB, bit busy, bit tight, etched. Not drilled, not loaded, plucking up courage.
Pics:

It's just under 46 x 28 mm, bit bigger than I wanted.

15/03/2015

Ouch this is way more complex than I expected. I've made about 7 interations of the PCB, mostly problems with tracks too close together for reliable etching. Last iteration I built everything then could not get it to work. This time I've widened all gaps between tracks, used Eagle default values to check clearances etc. It still had a few shorts but all fixable, then I loaded in sections:

3V3 LDO

  Applied 5V to PCB input, tested to ensure 3V3 output ok.

Added 5V (Input) and 3V3 output capacitors.

  Applied 5V to PCB input, tested to ensure 3V3 output ok.

Added 12 MHz crystal and capacitor.

  Applied 5V to PCB, checked crystal output was OK.

Buzzed all VDD and VSS processor connections adding Vias where needed.

Added all required processor related capacitors and resistors.

  Applied 5V to PCB, checked 3V3 on all VDD processor pins.

Added LEDs and drive resistors, buzzed out circuit to processor.

Added LINK cable (for programming using ST Link / ST32F4Discovery).

Soldered on 100 pin QFP processor.

  Got some bridges (ok, I ran out of patience after 25 pins), ran out of solder wick, awaiting RS order.

  There are a few ways to solder a QFP processor:

    1) Solder paste and heat gun - out, still awaiting solder paste arriving from China (£2 from China,

        £17 upwards Farnell /RS)

    2) Hand solder very carefully - This was how I started (0.5 mm spacing is damned hard).

    3) Hand solder quickly then remove excess solder / bridges using solder wick.

One 3V3 point in Schematic was not named '3V3', so not joined to 3V3 rail - fixed PCB, linked current iteration.

Missing Gnd connection on Link - fixed PCB, linked current iteration.

 

RS Order should arrive Tuesday. Clear bridges, test whether I can program the beast. Got red, yellow and green LEDs, so I can play traffic lights.
I'm using tried and tested tool chain I used with ST32F4Discovery, so that is fairly safe.
I have created a TrueStudio project using STCube, I should be able to transfer settings / files in sections.
Once the programming works then load SD Card parts of circuit and test. Then ESP8266 (Wifi) parts of circuit then test. Then OV2640 (camera) supply components and test. Finally get OV2640 working.
Then I can do some final software.

22/03/2015

Abject failure. Programming doesn't work. This is a project milestone, so I should have treated with more respect.

I've found (and fixed) errors on the PCB:
When creating multiple supply rails in Eagle circuits, you must make sure to name all the nets the same, e.g every net connecting to a 3V3 rail must be called 3V3. every net connecting to a GND rail must be called GND. If you miss one then it all looks fine, but you won't get a routing on PCB to connect to wrongly named nets. I had 1 wrong, so 1 MCU pin and associated decoupling cap was not connected to 3V3, fixed circuit, modified PCB layout, linked PCB.
BOOT pin needed a pull down resistor, not a pull up, fixed circuit, modified layout, linked PCB.

But still no luck with programming, thought it may be use of Discovery as LINK, borrowed at known good LINK from work. Not that.

All I can think is that circuit still has some problem that I can not find (I think low probability) or I cooked the MCU.

My soldering used to be very good. 20 to 30 years ago I worked assembling PCBs, I developed over time to be quick and accurate, assembly times were monitored and I was encouraged to be faster - hence quick. Quality was monitored by QA inspection and all suspect joints were returned to me for fixing encouraging accuracy. I'm not just saying my soldering was good, that was a fact.

But at that time it was all leaded, I have only R&D experience of soldering surface mount and not much of that. As I said above, I carefully soldered 25 of the 100 pins, then blanket soldered the rest and used solder wick to remove excess, that probably cooked and destroyed the MCU.

I'm now in thinking mode:

I need to improve my surface mount skills. I have a heat gun, though it's a cheapie and I have no idea what 1-8 relates to in true temperatures, need to experiment, gun is good, but need to play. I have no solder paste, on order from China, 1 not arrived, ordered more but takes time.

These made me pretty ashamed:

https://www.youtube.com/watch?v=erb6-i54tbo

Doesn't that look quick and easy, he must have been doing that for a long time to get that practised.

Explained in more detail here:

https://www.youtube.com/watch?v=5uiroWBkdFY

But it's a sales pitch, they want you to sign up for their courses. So it purposefully leaves out the details.

All soldering irons these days are temperature controlled, but you need to set them for the temperature of the solder type you are using and the pad type. If it's linked to large copper area then it acts as a heat sink, so you need higher temperature, too low and it takes ages to heat up to get solder flowing and there is a good chance of chip damage, too high and it heats up quick but there is a good chance of chip damage, needs experience to know exactly what temperature setting and that's also linked to soldering iron. They recommend a soldering station and tip, they don't mention temperature setting or solder type.

Solder / Solder paste comes is a variety of  temperature ranges, This is done on purpose for manufacturing, you can choose to manufacture in stages, use high melting point for first stage, lower melting point for further stages. It allows things like piggy backing, you can make a chip package with pads on upper surface, this allows you to say piggy back flash or RAM on a chipset.

But this just adds complication to home users.

Ionizing is a problem, they do mention wiping pads before soldering with "isopropyl", but they don't say which, I'm guessing isopropyl alcohol rather than accetate, but I am not sure this is important.

The video quickly shows application of flux solution but it's not mentioned, I think this maybe crucial to getting the joint well made and the solder stay on the joint rather than cause bridging. Which flux solution is very difficult to determine using Google.

But I need to improve my chip soldering technique.

Do I now go back to bread board? Should I have bread boarded first? I've knocked up a quick bread board for the MCU in Eagle, but not made it.

Do I create the new fixed PCB, solder MCU first very carefully, carefully add minimum single components, supply 3V3 from bench PSU and test programming first?

The MCU chips are £7 each, I ordered 3 and I have 1 left. They only appear to be available to me via Farnell and it's minimum order £20.

So, I'm thinking and doing nothing.

Later the same day....

Eureka, bit the bullet, make the PCB.

Did it all, high quality quite happy, etched cleaned, drilled cropped.

I could not line up the MCU, checked out the library foot print, ok horizontally but lost a pin vertically, 25 pins in 24 pin space, really screwy. Then I sussed it.

I have a Samsung ML-2240 mono laser printer that I picked up off Ebay some years ago for £10.

Recently while playing, I found the advanced settings, it was on 'normal' 600 dpi, I set it to maximum 1200 dpi. Now looking it up, it is 1200 dpi horizontally and software interpolated 1200 dpi vertically!!!! Switched back to 600 dpi, printed on paper the circuit is now correct. Maybe this has been my problem all along. But wasted a PCB, ah well....

24/03/2015

Nope, no good, adjusted soldering iron down to minimum, very carefully soldered on chip, fail, short. Adjusted hot gun temperature to minimum then carefully removed chip, the soldering was dreadful.

Now awaiting stuff:

• New soldering iron tip, close as I could get to one used in videos above, chisel, 3 mm across, 45 degrees instead of 60 degrees, but close enough?
• Solder paste.
• Liquid flux.
• 20 off 0.5mm spacing FFC FPC connectors.

I'll practice lots and refine my technique then get it right.

I have a sneaky suspicion that nobody is hand soldering QFP 100 components, I think they use solder cream and reflow ovens and that is on manufactured roller tinned PCB, not bare copper self etched.

Well, anyway, that's what I'm telling myself to keep my confidence from dropping through the floor.

  

ST32F4Discovery

I'm going to use the STM32F407VGT6TR chip for my IP Camera. It has built in Camera Interface allowing up to 54 MHz pixel clock. It has built in SD Card interface. It's fast. The chip costs near £7.00 which is more than I'd like, but I need the high end functionality.

Camera Interface is not a 'standard', there are 2 types:
MIPI CSI is Camera Serial Interface, sub-LVDS very low noise, very fast serial, good luck finding this anywhere, it is protected by MIPI, you won't easily find camera modules or chipsets that support it.
Parallel Camera Interface, this is appearing more but still rare. Try searching for ARM or Cortex with Camera Interface, try searching RS or Farnell or any supplier, see if you can get a list of ARM based chips with Camera Interface. Basically I had to go through lists, pull up datasheet and check for Camera Interface for each chip.

I got bored, so STM32F407VGT6TR may not be the cheapest available, it was the cheapest I found within my boredom threshold.

-------------------------------------------------------------------------------------------------------------------------

ST produce fabulous little development platforms, ST32FxDiscovery, look them up, they are pin compatible, 1 per microprocessor family, packed with features and cheap, I bought and am using at ST32F4Discovery, £11.75 from Farnell. It has a built in 'ST-Link', which is ST hardware interface for programmin/debugging their chip sets. You can buy an ST-Link on it's own from Farnell for only £68.60!
I can use the ST32F4Discovery for development, then I can use it again in 'ST Link' mode with my own PCB design.

Ok, so ST32FxDiscovery is fabulous hardware, then you come to use it. ST do not like or support hobbyist, there is not enough profit margin in hobbyists, so they don't want to support them. The platform is for company development, not for hobbyists. There are tons of free software resources to attract companies, but they are all based around commercial IDEs, these are:

Altium: TASKING VX-Toolset: They won't actually give you a price for their IDE, you need to fill in a form then a salesman will contact you. A press release states pricing starts at $1,795.

Atolic: TrueSTUDIO: Supposedly there is a free lite version, but I couldn't find it, normal is pro for 995 Euros.

IAR: EWARM: Baseline $1295

Keil: MDK-ARM: Farnell, starts at £472.

-------------------------------------------------------------------------------------------------------------------------

But there are ways, I have Eclipse IDE plus GCC setup using Google and Internet, in 1 evening I have a project that I can flash and debug on STM32F4Discovery, though it only flashes an LED.
ST have a nice utility called STM32CubeMX, you can visually configure what you want to do then it puts together software building blocks to give you a really good head start. Only problem, it supports only the IDEs already listed :-(
Atolic TrueSTUDIO is actually Eclipse plus GCC, so I am thinking that maybe I can create software that converts STM32CubeMX output for Atolic to work in my environment.

But basically I am playing with tools when I really want to be making an IP Camera. Ah well, another challenge :-)

-------------------------------------------------------------------------------------------------------------------------

23/02/2015

Went well, got working tool chain, building and flashing ok, should be able to use Discovery as ST-Link for flashing my project, didn't do anything spectacular just variations on blinky.

IP Camera

Wednesday 24th December 2014

There are now lots of IP cameras out there, but I'm not impressed, colours are at best 'suspect', Audio out OR Audio in and cheapest is about £30, I think I can do better.

For a development platform I am using Arduino Due, nice fast ARM processor. Bought from Bangood.com for £8.

First I wanted memory card, mmc quite often comes with a free converter, got a few kicking about, got a few 16GB mmc kicking about. I wired 1 of the converters up to Due, few wires, bit of solder, capacitor. Used standard Arduino Cardinfo example software, got it working :-)
Ok, so that was basically free and quick.

Now I discovered ESP8266, ace module, £2 from EBay. Module is 3.3v, Due is 3.3V, wired it up.
Modified code using info off Internet (good old Google).
Needed more power than USB could supply, plugged in a USB mains plug (£1 from Ebay), cured that.
Works rather well, set it up as a web server, 2 pages (config & index), can see both pages on PC and phone browsers, some things I don't understand with requests for favourites icon.
Modified so I can have debug statements over serial to PC or not (DBG flag). Turned off serial.
I now have a stand-alone Wifi web server :-)

rigged up Arduino Due

Programming port goes to PC USB for programming and debug.

Power connector goes to USB main plug.

SDIO block and orange wire connected to SDCard

Brown/blue and green/white twisted pairs go to ESP8266

The rigged up SDCard

The rigged up ESP8266 module

That is current 'state of play', what's next?

I have an Omnivision OV2640 2MP camera module, I now need to rig that up and get it working with the Due, this is a bit more tricky, camera is on a flexi with 25 pins 0.5 mm pitch.

I think I'm going to have to make a PCB for this one.

Basic plan is to get it all running on Due, I'll then know how it all needs to work. Then maybe I can get it all working with ESP8266 acting as main processor (remove the Due). I'll then have a really small, fully functioning IP Camera for around £5.

I'll update this post as I progress.

17-01-2015

PCB was a pain, I got the mmC mirrored, I got the camera mirrored, took me 4 attempts, I only bought 2 1.3V LDO, 1 broke, 1 lost, awaiting delivery. Rest of the PCB is working, pictures:

 

Left is the bare PCB, etched drilled and trimmed. Right is the loaded PCB attached to Due.
Getting there, bit slower than I'd like, but steady.

31-01-2015
This has not been as easy as I hoped.

Latest revision of PCB. Note the Micro Memory Card holder on top right. 3D printed guide in clear PLA. Almost everything is working using an Arduino sketch. Reading and writing happily from mmC, fully active on Wifi with ESP8266, control and see results over standard USB serial, I have a simple web server running on Wifi, I can happily browse on PC or phone. Currently concentrating on camera.

OV2640 is not easy, got datasheet, could not get it running with just that, it seems like you have enough information, but when you try to use it you don't get expected results. Found the OV2640 application note, now a bit clearer, there are lots of register sequences, nearly 90% of them are writes to 'Reserved' registers. But using a recommended sequence and capturing VREF signals via interrupt and incrementing counter, I can see it is streaming. So basic control is running, it is streaming, but I need to capture the frames. Sketch is a mess, not sure Arduino is up to the task.

I tried switching to Atmel Studio 6, struggling to get the easy stuff going. SD card is supported, but not for Due and docs are not got enough to easily modify for Due.

Currently thinking, either crack on with Atmel Studio 6, or back to Arduino and tidy it up by moving the OV2640 into some kind of lib.

Can the Due handle image capture? A lot of data coming dead quick. I'll try with pure interrupts (save byte per PCCLK (Pixel clock) gated with VREF, I was thinking DMA, but I'm not convinced that it can be done, I have heard that GPIO registers are memory mapped, I have data coming in on Port C low byte, so it may be feasible to DMA bytes from single address (Port C) gated by PCCLK to RAM buffer, but I have found no details on setting up DMA on Due or SAM3X in this configuration.

I will crack it.

01/02/2015

Need to expand on 'A lot of data coming dead quick'. OV2640 is a '2 Mega Pixel' camera. 2MP camera is usual for low end phones, high end phones have 5MP, some go to 8MP. Digital Cameras are usually 12 to 20 MP. Lets not discuss Nokia 41 MP. So 2 MP on the face of it is not very big.

I put '2 Mega Pixel' on purpose, maximum capture on OV2640 is UXGA = 1600x1200 pixels. Do the math 1600x1200=1,920,000 (not quite 2,000,000) though in raw mode there are extra pixels around border for interpolation. But that is pixels, not bytes, so we need to think of formats, typical RGB565, YUV422 are 16 bits (2 bytes) per pixel, so in those cases 3,840,000 bytes per frame. Now we need to think about frame speed (Frames Per Second - FPS). Normal video / viewfinder is 15 fps, though some do go to 30 fps.

So 15 fps UXGA = 3,840,000 * 15 = 57,600,000 bytes per second = 'A lot of data coming dead quick'.

Ok, I've reduced that by a ton, getting QVGA (320x240), I've now tried interrupts, I think the data is valid (but difficult to be sure), but I am not getting full frames, I really don't think Due can handle it.

How do phones do it, they are ARM based? I know Nokia, it isn't easy. Nokia had big problems, it was OK putting camera into first phone, it was high end, that means relatively low production, low sales. Putting it into low end phones = high volume, low cost, no single camera module manufacturer can handle producing the quantity of camera modules needed for a single low end phone. So Nokia and ST collaborated to produce the 'SMIA' (Standard Mobile Imaging Archecture) set of specifications. This means Nokia can buy SMIA compliant camera modules from a number of manufacturers and include in a phone.

Camera control is relatively low speed bi-directional handling 8 bit registers in phone, in almost all camera modules (including SMIA) this is based upon I2C (IIC, Inter Integrated-circuit Communications), I say 'based upon' as it is usually simplified, can't handle high speeds, changing speeds etc. There is usually no problem with controlling a camera.

For some unknown reason (maybe to do with language), the SMIA image data out port is called CCP (Camera Control Port, which it is NOT), the CCP port is special, it is very high speed sub-LVDS serial. It can be 2 wire (original) or these days single clock with multiple data lines, but in all cases it is fewer wires than parallel. It is sub-LVDS to make it ultra low noise to stop it interfering with phone RF (blocked channels). All Nokia chipsets have a special CCP input port block, the block includes the sub-LVDS pads and handles serial to parallel conversion as well as including a buffer, the ONLY way to get data out of this block is DMA. The size of the buffer was always a problem and always got increased in size for each chip revision.

If we were allowed to know (which we aren't), I believe you will find that the Broadcom processor built into the Raspberry Pi is actually an old obsolete design created for Nokia. It includes the CCP port block, it also includes the Broadcom Image pipeline. SMIA data comes from Camera Module over sub-LVDS to Nokia CCP block, it goes from CCP Block over DMA to Image pipeline, it then goes via DMA to RAM.

Almost all camera modules are either SMIA or can be SMIA, you are not allowed to use/view SMIA specifications unless you are a member of the MIPI alliance, you can't issue SMIA details (including data sheets that include SMIA details) unless you request an NDA. This is why it is so damned difficult to get information on camera modules. I was 'host software' support engineer during SMIA specification creation. Blame SMIA, MIPI, Nokia or me for the fact that you can't get camera module information!

There are things I can still try:

1) Simplify Pixel clock interrupt handler, make it more efficient, ditch range checking.

2) Switch to JPEG format for frames, compresses to 1 bit per pixel, if it is possible for lower size frames.

3) DMA from camera to RAM (some how).

4) External camera data receive / buffer (ArduCam uses a special chip).

1 & 2)

volatile int FrameCnt = 0; 

void CamCapture()

{

  FrameCnt++;

  //if (FrameCnt < MAX_FRAME)

  //  FrameBuf[FrameCnt++] = (byte)(REG_PIOC_PDSR & 0xff);

}

not completely repeatable, but maybe close enough, but it's not doing anything.

It I use long instead of int then it goes out the window.

For QCIF (176x144 lowest) in RGB565 I get 28170 bytes (28169 to 28173 over 10 attempts)

For QCIF in JPEG it's around 3560 bytes, but then JPEG will not be consistent.

Ok, Interrupt no good, try DMA
Spent most of today looking at DMA, the Due does not allow DMA source trigger from GPIO, only from in-built peripheral triggers.

That just leaves option 4, maybe a PIC?
This would actually be the best solution. I want something simple but fast. Clocks in parallel data synchronized with external trigger put into on board RAM. Fast SPI slave interface to allow RAM to be read. How hard can it be?
Why is it the best solution? It would work with Arduino Due or stand alone ESP8266.

2/2/2015
Examined camera pins with scope.
VSync is not pulsing high at start and end of frame, it goes high before start, goes low after end.
Major problem is Pixel Clk, it has really nasty 50 Hz hum hiding data. Should have checked this earlier, gone over HW App Notes and SW App Notes. HW notes say that if using a single supply for DOVDD and AVDD (as I am doing) then they should be seperated by RC filter which I have not done :-(
I'll revisit circuit (again) and see if I can cure it.
Then I can retry the interrupt capture.

14/2/2015
I fixed the problem, camera was being supplied with 12 MHz clock, settings were for 24 MHz clock. Altering settings to match clock fixed the weirdness.
Then I finally admitted defeat, Due DMA can not be used to capture frame bytes and Interrupt handling is too slow, if I slow it down enough that Due can handle it then image speed will be pointless. Even if I accept really low frame rates, there is not enough RAM in Due to hold a decent frame size.
Basically, Due attempt was pointless except as a learning exercise.

So, I need something more designed to handle camera. My current favorite is STM32F407VGT6TR, it is 14x14 LQFP with 100 pins, so I should be able to create a PCB for it. It has a purpose built Camera Interface that will connect to OV2640 and it has high speed SDCard Interface. I think I can program it to DMA frames from camera direct to SD Card. It costs a bit more than I wanted at just under £7. There is a dev platform with the chip called STM32F4DISCOVERY for £12, bought one.
It seems quite hard to set this up with any IDE that doesn't cost a fortune to license, but I'm looking into it.

Katy Perry Action Figure

27/09/2011 (Saturday):
Another request from Daughter.

This is actually the most complex design I've ever done.

Found open source program MakeHuman, fabulous, allows you to create a human body.
So, I spent ages creating a figure that matches Katy Perry as close as I can get.
I discovered a few quirks, basic body works wonderfully, but add hair, teeth or any extras at all and the exported STL seems broken, or I don't know what I'm doing, which is probably nearer the truth.
But now I have figure :-)

I've heard of Oogoo, home made rubber. Wickes All Purpose Sealant (silicon) + Corn Flour.
I mix in batches, 3 tablespoons of silicon, add a little Humbrol Enamel matt 61 (flesh), mix together, add 2 tablespoons of Corn Flour, mix together. Gives rubber that makes a great skin.

So, import figure into OpenSCAD, turn it into moulds (for Oogoo) and create a skeleton.
First thing I tried was head, worked ok (colour needs work):

Got colour correct (humbrol), remade head. It's hollow, but need hair. Found nylon hair on Halloween hat and hair grips, spent ages threading hair into head using darning needle. Had to flatten it with clothes iron, but getting there:

I've managed to fill bubbles in chin and forehead with more Oogoo. Next problem is painting eyes, lips, eyebrows, eyelashes. Nothing sticks to Oogoo except more Oogoo! Mixing paint into silicon works, but a pig to paint on, it's so thick, tried using Xylene paint thinners, doesn't work. I'll have to use the thick stuff.

Best I can do (mostly Stabilo permanent pens):

Spent ages trying to get pose-able fingers, failed, but it'll do for now, will create whole Manikin, then revisit. Skeleton arm hinge not in correct place, need to adjust. Skeleton fingers pose well, but can't hold against pull of rubber and skeleton fingers too wide to allow Oogoo flow around sides. Wrist works really well, quite freaky.

Put head and failed arms onto full skeleton. Skeleton is NOT firm enough, joints too loose, won't stand up under weight of those few bits. Tried using Oogoo to wrap joints to strengthen and hold joint together, no good, Oogoo does not stick to PLA. Tried wrapping joints with PVC tape, didn't make much difference.

ABS maybe better? Is more elastic, I think it's more abrasive.

I'm going to re-print whole skeleton in ABS and see. I'll try wrapping in Oogoo, see if it sticks. Probably try embedding copper wire into fingers (with hot knife) to strengthen. May try putting thin skin in moulds and letting set before adding skeleton and final Oogoo so that skeleton is not too close to surface. Will try putting Oogoo into joints during assembly (rubberise joints).

Lots of ideas, some of them have to work.

 

ABS was no better at all, dismal failure, not so hard as PLA, so not as good on joints, Oogoo doesn't stick to ABS either. Embedding seemed to work, but ABS doesn't stick to copper either. Plus ABS warps far worse than PLA. Thin Oogoo skin seems good in arm moulds, but no skeleton to go in it!

Back to PLA, re-print the lot, embed wires into PLA hands, try hot gun glue in joints (like Dexter).

Eureka!

PLA arms, hot glue on mating surfaces of all joints during assembly, kept hands (shown above) with embedded wires, but covered fingers in thin layer of hot glue. Nice, tight, stiff and strong.

PLA body skeleton printing, assemble same way, should be perfect, then on with skin.

Not sure I should publish pictures of final result, may be too realistic, nudity may offend. Perhaps make it some undies.

29/11/2014 (Saturday):

Cool, now looking at 16 inch tall nude woman!

Joining sections together in oogoo was tricky, bubbles are a pain, just gave her a massage down back side smoothing over with extra oogoo, Wait until it sets then I'll do front. May actually get it finished this week-end.

30/11/2014 (Sunday):

 

In cold light of day, decided "Nah, crap, 1 out of 10, could do better".
I can't fix the joins (well, not without a lot of messing).
It doesn't bend at joints as I wanted.
Middle sections are too squashy.
Facial details added with stabilo pens have bled into Oogoo, gives a quite pleasant eye make-up type look on lashes / brows, but eyes are horrid and lips aren't so good.

Head Mould:
Re-visit head, make face side very shallow (or separate face section), add hemi-spherical eye sockets. Make longer neck overlap.
Print eye balls, paint white then insert. make red oogoo lips and place before rest of Oogoo, same with brows. Only do lashes with stabilo. Paint irises last.
This time I'll do hair thinner.

Main Mould:
Keep torso, hip and leg moulds as is.
New separate moulds for hands.
New separate moulds for arms that will mate with torso and mate with hands.
New separate neck/head brace.
Use hot glue to join together torso, hip, leg, arms and neck/head brace as top and bottom sections.

Skeleton:

Wrists good, ankles good.

Increase size of knees and elbows. Increase thickness of bones. Increase size of hips and other joints.

Figure out hands.

Make rib, tummy and hip cages.

Assembly:

thin layer of Oogoo is plan, do both sides, let set. Once set add skeleton, then join together with Oogoo.

This may work.

Spiderman action figure.

Daughter asked for this.
There is a fabulous action figure on Thingiverse called Dexter, so I made one and added a costume:

 

 

 

Kids Night Lights

Created loads of designs, kids have 4 each here and 4 each at home, my mate Jim has 1 for his grand Daughter, my work mate has 1 for his daughter, my Son's GF's nephew has 1.
It started with my Daughter, "Can you make a moon light light?":

Next "Can you make a Mickey night light?":

Then "How about a shooting star?":

Next "Can I have a Spiderman?", "Can I have a Buzz Lightyear?":

 

Next was "Can I have Pepper Pig?", "Can I have Elsa from Frozen?". This time I created a standard night light that I could put pictures on to:

 

Of course, now I can make them easily, I got no more requests.

Still no further with Jack Door, but lots of other things created.