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.

Stuff

Jack Door still not finished. RFID reader is not good enough, max range about 2 inches max. Found a pre-built reader and 35 mm circular tags that are supposed to manage 4 inches, need to test.

Got knocked of my bike on way to work on Tuesday 10th June 2014. Static queue between me and right hand lane I needed. Chose nice large gap, was on the way through when car decided to close gap! Her front bumper hit my right ankle, knocked me over, drove up to my knee. I pulled myself out from under the bike, picked it up, started it up all whilst giving the young blonde driver a piece of my mind, then rode on to work. An hour later my leg not feeling so great, went home, long hot bath, 2 days off work, still painful and limping now.
I should have been staring into the Blondes eyes, would have seen she was playing with her phone, could have avoided it. I should have taken her details. But I didn't.
So, I've created a camera that attaches to my helmet, next time I will be prepared. For details, see here:
http://www.thingiverse.com/thing:372439

Also published a few other minor bits and bobs on Thingiverse:
Kiddies Night Light: http://www.thingiverse.com/thing:267662

Updated metric threads: http://www.thingiverse.com/thing:311031
Customizer version: http://www.thingiverse.com/thing:311919
Glasses case: http://www.thingiverse.com/thing:311976

Customizer version of Raspberyy Pi case: http://www.thingiverse.com/thing:313811
Hermesetas cap (stops em filling my pocket): http://www.thingiverse.com/thing:315102
Customizer Ashtray: http://www.thingiverse.com/thing:316440
Couple of Remote Holsters: http://www.thingiverse.com/thing:345945 http://www.thingiverse.com/thing:345952

My Dad was very much into Cine Camera, he created hours of Cine Film that spans between 1960 to 1987. Previously I transferred this to DVD. It wasn't really a great success, I bought a video camera, ran all the Cine and Video taped it, then transferred to PC and edited. I did it all in as high definition as I could, Cine had no sound, so added sound track of all the UK Top 20 at the actual time of the Cine.
Got it all completed and only then discovered that I could not convert from high definition to lower, so I was stuck with a set of 11 DVDs, made 2 copies, gave 1 to Dad, 1 to Sister.
2nd Sister recently asked for a copy, technology moved forward, now I can reduce, gave her a set of 2 DVD with everything on. Whilst at it, I transferred to Dropbox and published it to the whole family.
Appeals to my sense of humour, ancient 1960 Cine film hosted on very latest Cloud :-)

Jack Door

Monday 31st March 2014
See Introduction for pictures.

So, I have most of the Jack Door working, bit I am totally unsure of is RF ID Reader. I created the board based upon U2270 RF ID Reader chip and all the documents I could find on it.
Docs are not that good, or I'm not good enough to read them properly, too much theory, not enough practical for me. So I winged it (as usual in such cases). First attempt at making PCB was a disaster, but 2nd attempt good. Then I had to move Computer and printer into Garage while Grand Children had an extended stay. Somewhere on the way, I mislaid my test RF ID Pet tag (bought from local vet). Found this week-end.

Ok, so I put it off for a while then plugged it all together and powered it up. Lots of teething troubles, lots of re-reading specs. But eventually it was doing something. Son bought a DS203 pocket Oscilloscope some time back. Attached that, voltage pp was 30V, nice, but frequency was way off, I needed 134.2 kHz, calculated as 7.45 uS wavelength, I could adjust down to 11.4 uS before signal started to collapse. Re-visited wound Ariel (roughly 30 turns from memory), removed 1 turn, wave length lower, ended up removing about 12 turns before the frequency was low enough to adjust.
Now put scope onto output, looked like nothing but noise, played lots with software and scope before I got break through tonight. Putting tag within 2 inches of Ariel, I got close wave form, removed it, got wide wave form. Damned thing is actually working :-) Dead chuffed.
Ok, so range is bad, I'd like at least 1 metre, but 2 inches will do for development, get the thing reading, then I can do repeat reads and tune PCB properly.
The rest of tonight I spent capturing output signal and trying to decode into FDX-B format. That I now have, I am happily reading the test tag :-)
Next step is to modify software, I want to keep the reader so that I can use it to read Jack's chip, but I also want it to run as standard, power up Rf ID board, read chip, good or bad flag, power down. Rinse and repeat every second. A good read opens door (like pressing button to open), 3 bad reads in a row closes door (like pressing button to close). Keep test tag code and Jack codes in constants.
Should work, so on the way to Jack Door completion, basically just Donkey work remaining.