In my last post I wrote:
"Whilst awaiting, I now have lots of very small parts, M1.6 washers and nuts, M2 washers and nuts etc. I have no place to keep such tiny components, so I'm creating a modular clip together drawer set.
Clip together is not an easy concept to make work in 3D printing."
It's now obvious to me that I know little of what people want!
I published as http://www.thingiverse.com/thing:1621667
231 views, 60 downloads, 40 likes, 48 collects, 1 make!!!!
Published last night at 12:33, this is stats from less than 24 hours!
The world is nuts!
Sunday, 12 June 2016
Saturday, 11 June 2016
Radio Control 2
Ok, cut down variables, ordered FlySky FS-i4 4 channel transmitter, I had 1 but gave to my dad for controlling his speed boats, I have a few FlySky 6 and 4 channel receivers that will work with it.
I'm concerned that AAA batteries are not good enough to drive the buggy, so I've ordered some Lipo batteries and a multi-charger.
I've added level changer to the controller PCB, made the PCB then discovered I have no PCB drills left, tried a lesser quality drill and messed up the PCB, so I've ordered some more.
Whilst awaiting, I now have lots of very small parts, M1.6 washers and nuts, M2 washers and nuts etc. I have no place to keep such tiny components, so I'm creating a modular clip together drawer set.
Clip together is not an easy concept to make work in 3D printing.
Lipo batteries arrived, multi-charger has 1 type of connector, batteries have another!!!!
Ordered some leads of each type, will make up patch leads when they arrive, but for now I can't use the batteries (sigh).
Transmitter arrived :-)
Put into Trix controller, it now appears to work perfectly on desk. I can build up the complete model, test it, get to know it, then switch to my controller and compare. Still lots of fiddling, I now need to put back all the deck hardware, set it all up, float it to get water line, paint bottom red up to water line.
I'm concerned that AAA batteries are not good enough to drive the buggy, so I've ordered some Lipo batteries and a multi-charger.
I've added level changer to the controller PCB, made the PCB then discovered I have no PCB drills left, tried a lesser quality drill and messed up the PCB, so I've ordered some more.
Whilst awaiting, I now have lots of very small parts, M1.6 washers and nuts, M2 washers and nuts etc. I have no place to keep such tiny components, so I'm creating a modular clip together drawer set.
Clip together is not an easy concept to make work in 3D printing.
Lipo batteries arrived, multi-charger has 1 type of connector, batteries have another!!!!
Ordered some leads of each type, will make up patch leads when they arrive, but for now I can't use the batteries (sigh).
Transmitter arrived :-)
Put into Trix controller, it now appears to work perfectly on desk. I can build up the complete model, test it, get to know it, then switch to my controller and compare. Still lots of fiddling, I now need to put back all the deck hardware, set it all up, float it to get water line, paint bottom red up to water line.
Put receiver into Buggy, not so good, it works perfectly off load (lifted off floor). It won't drive for long even on a flat smooth level floor. The cogs bind, probably too much play. I'll probably redesign to use worm gear drive. Again, once I get it working with standard transmitter / receiver then I can play, get to know it then switch over to my controller. Cut out all the variables.
Basically, all on-going, nothing completed yet.
I forgot how much smaller my controller is than a standard receiver, that was pleasant.
Monday, 23 May 2016
Radio Control 1
I had 2 models for testing the Radio Control unit.
Model 1: Trix:
This is a sailboat, boat itself is about 70 years old, roughly 3 feet long, 5 feet tall with sail.
It has a hatch in centre that allows access to an internal handle.
I designed an insert to take the control mechanisms, 2 servos, a simple 9g servo to control steering and a winch servo to control sails.
Model 2: Buggy:
This is a remote control beach buggy, should look like the beach buggy my father designed and built back in the 70s.
Trix had been taken down to basic shell and coated with resin to make it waterproof, so before I could start in earnest I had to prepare and paint it, so I tended to concentrate on the Buggy whilst spraying the coats of paint on Trix in background
Model 1: Trix:
This is a sailboat, boat itself is about 70 years old, roughly 3 feet long, 5 feet tall with sail.
It has a hatch in centre that allows access to an internal handle.
I designed an insert to take the control mechanisms, 2 servos, a simple 9g servo to control steering and a winch servo to control sails.
Model 2: Buggy:
This is a remote control beach buggy, should look like the beach buggy my father designed and built back in the 70s.
Trix had been taken down to basic shell and coated with resin to make it waterproof, so before I could start in earnest I had to prepare and paint it, so I tended to concentrate on the Buggy whilst spraying the coats of paint on Trix in background
This is the basic Trix shell, now painted white, I need to put back all the fittings, get the electronics working then float so I can get the water line before I can paint the red underside.
This is with the electronics module fitted.
This is the electronics module, 3D printed out of red PLA, sprayed white to match Trix. The top small box clips off to allow changing of batteries in situ. It holds 4 off standard AAA batteries.
2 nylon cords are routed through PTFE tubes from correct position on deck (for sails) to winch servo.
Power switch on top, small 9g servo for connecting to rudder.
Buggy is a fully printed new design from scratch.
Top is a photo of me in my fathers original Beach Buggy, note it's a banana, yellow with brown patches, 4 banana linked for steering wheel, green banana leaf bucket seats.
Middle is a photo of current printed model.
Bottom is a picture export from OpenSCAD.
No body (yet, half designed).
I'm really happy with the tyres, they are Oogoo set in PLA printed moulds.
Oogoo 1:1 cornflour:silicon with black printer ink added, nice rubbery texture, grip well.
The steering was surprisingly easy. The floorpan in accurately based upon the VW Beetle chassis with 12" removed as used in any full sized beach buggy. The motor is a standard MR2. I had lots of problems with the gear box, I could not get the standard OpenSCAD gear library to create gears small enough, so I used my old involute gear library I created for my failed clock. Currently 10:1 using 4 gears.
Trix is basically simple, control modules, 4 AAA batteries, 2 standard servos, but it's not something I can publish, I doubt anyone else has a boat like Trix.
Buggy is more complex but publishable, once complete I can publish to Thingiverse and anyone can build it. It has control module, 1 standard servo, 1 standard ESC, motor and gears.
Everything works on the bench. Connected up to bench PSU it all runs perfectly. As soon as I try to get it to work for real then it goes nuts. To start with I had 4 off AAA in the buggy, batteries all in series (4 x 1.1 to 4 x 1.5 = 4.4 to 6V) connected to ESC, 5V output from ESC to control and servo.
As soon as I put onto ground and try to move it then it resets. Phone appears to be really bad at handling resets, the wifi hot spot gets interrupted, so the browser no longer connects.
I tried 5 batteries, I tried 5 batteries plus 1000uF capacitors, no good.
I removed the regulator from the control and had 2 batteries into control and 3 batteries into ESC/motor. Nothing satisfactory, ordered some Lipo batteries and charger, put it on hold.
Moved to Trix, nice and simple, should be easy?
No, that doesn't work either. I think a big part of the problem is that the controller is 3V3 based.
The servos do not seem to like being powered by 6V and driven by 3V3, they make odd noises and draw lots of current.
I may try to add level conversion to control module, I may just switch to FlySky RC equipment for now and get on with turning the control module into a tiny quad copter, not sure yet.
Monday, 4 April 2016
Radio Control
Not added to blog for a while, been out of action, my Jack had crusciate ligament surgery, he wasn't allowed to jump at all, so kiddie gate on bedroom door, bed out, mattress on floor, we all lived like like in bedroom together for a year!!!!!!!!!!!
Now I'm back to playing.
ESP8266, got a few different modules, had 4 off ESP8266-03, and it's smallest with a decent amount of GPIOs, so that's the one I started with.
Fitted it to a 0.1" jig, plugged into breadboard, plugged in a USB to 3v3 TTL module, added a few resistors and LEDs.
Setup Arduino, got it programming with examples, modified examples.
Added a 3v3 regulator and a couple of capacitors.
Created a 3v3 regulator / interface board:
Now I'm back to playing.
ESP8266, got a few different modules, had 4 off ESP8266-03, and it's smallest with a decent amount of GPIOs, so that's the one I started with.
Fitted it to a 0.1" jig, plugged into breadboard, plugged in a USB to 3v3 TTL module, added a few resistors and LEDs.
Setup Arduino, got it programming with examples, modified examples.
Added a 3v3 regulator and a couple of capacitors.
Created a 3v3 regulator / interface board:
Software is a mixture of various examples.
Turn it on and it becomes a Wifi access point. Connect to it with a WiFi device (I use my Samsung mini 4 phone). Open a browser (I use Chrome), navigate to 192.168.0.1, it shows a radio transmitter:
Multi-touch, finger touching right side acts as the right joystick of a standard radio control transmitter, finger touching left side acts as left joystick.
Positions of fingers are passed back to module and it uses those values to drive up to 4 servos.
It's all fully working, it works with standard Futuba (large) servos, it works with small 9g servos, it works with an 10A ESC that I connected up.
The web page is based upon:
This includes an html page and a javascript page.
I created an MSVS 2015 project to compress these so they can be stored as static text in the main Arduino program.
The Arduino program uses ESP8266WiFi, WiFiClient, ESP8266WebServer, Servo and EEPROM libs. The program itself is stiched together from various examples.
Basically: It scans all current Access Points, chooses an unused channel. Loads SSID and Password from EEPROM, uses these to create an Access Point, it then sets up a web server.
Web server serves up main web page and javascript (as explained), it also allows 192.168.0.1\config page that allows Title, SSID and password to be changed and saved to EEPROM.
(Title is "Trix" in this instance, shown on joysticks main page).
I have a couple of ideas ready to use this module, then I can test it in anger (so to speak).
Costs: About £5 for all the components shown.
Monday, 23 February 2015
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:
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.
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:
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:
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.
Tuesday, 17 February 2015
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 :-)
-------------------------------------------------------------------------------------------------------------------------
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.
Wednesday, 24 December 2014
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 :-)
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.
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.
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.
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.
Subscribe to:
Posts (Atom)