Category Archives: Hardware

Stereotypical beginners electronics project pt2

I’ve got some LCM7215’s on order for a work project so I’ve got some downtime until they are due to arrive. I’m going to run through the LTSpice simulation process, and look at the alternative solutions available.

Assuming you haven’t already, you will need to download LTSpice. This is a free Spice simulator provided by Linear Technology. It’s pretty basic, but it has almost everything I needed to get off the ground. By using the following equations I managed to select starting values for my oscillator.

 

 

 

Using R = 255k, R1 = 1M, R2 = 255k, and C = 10u, we have a T of just over 11 seconds. Interestingly, when I simulated the circuit, my T was around 4.4 seconds. I am using fairly large values as I want to limit the current. The output is fairly constant, but there are a number of problems with my current circuit.

Firstly, I want  to use a single supply op-amp. This means I need to create a virtual ground or else the op-amp will be driven into an undefined state. The simplest way of acheiving this is my tying the inverting input to Vdd through a resistor equal to R1. Next, my output has a duty cycle of 50%. This is a problem as I want my device to be as low powered as possible. A reduction from 50% to 2% duty cycle would reduce my current consumption by a factor of 12. That is the battery would last 12 times longer. To adjust the duty cycle you need to include a diode in parallel withthe negative feedback loop. The idea is that the diode will all the capacitor to either charge or discharge quicker, depending on the polarity of the diode. As we want the capacitor to charge quicker we need to allow the current to flow to the capacitor quicker. Lastly, I have specced out the op-amp that I want to use. The LMC7215 is a low power single supply rail-to-rail comparitor that ticks all of my boxes. The only problem was that it is a National Semiconductor part, and LTSpice is Linear Technologies. This means that the part won’t already be contained in one of the built-in libraries.

To overcome this, National Semiconductor have released the SPICE definition for that part, and LTSpice allows you to include a SPICE directive. There are a number of options when it comes to using custom SPICE definitions, but I will only cover the one I used. I had already built up the circuit around a different op-amp, so to continue I needed to change the model. There isn’t a way to change the model, so instead you have to delete the current one and drop in the replacement. My replacement was based on the “opamp2″ model. Once the base model is inserted you need to insert the SPICE directive. This is a button on the toolbar that opens a text box. Take your downloaded SPICE definition and copy the tesxt directly into the text box. Select “SPICE directive” from the radio buttons, and click OK. Next, right-click “opamp2″ and type “LMC7215/NS” into the Value field. This is based on the SPICE line starting with “.SUBCKT” comment. Next, we need to tie together pin names and definitions. This is done by editing the “opamp2″ symbol. When you right-click on a pin, a box opens allowing you to change the “Label” and the “Netlist order”. The “Label” is the pins name and the “Netlist order” is the order at which they are mentioned in the SPICE file. In this example we have

“.SUBCKT LMC7215/NS     3  2  6  4  5″

That means the non-inverting pin is called “3” and its netlist order is 1. The inverting pin is called “2” and its netlist order is 2, etc.  Once that is set up, you can run the simulation.

With the circuit designed and simulated it is time to lay out the PCB. Unfortunately for you, I use EasyPC at work, and as that’s what I will be using to lay the PCB out in. I have given you the tools to create your own flashing light project using an op-amp as the starting point. Next article I will be laying out the PCB, and designing an enclosure for it.

Before I go, I wanted to run through the other two options. The PIC is based around the PIC18LF14K22. This is a low power device, and I happen to have some left over from my electronic dice project (still waiting for PCBs). Not much to say here. I’ve connected up the header pins for the ISCP, and using a 560R resistor I’ve connected both pins of the LED to the PIC (anode to digital pin, cathode to analogue pin – diode “points” to the analogue pin). The 555 circuit used a 560k resistor, 15k resistor, and 10uF capacitor to give a period of around 4 seconds, and duty cycle of 97%. By reversing the diode and connecting to Vdd the LED flashes briefly for 105ms, and stays off for 4 seconds. Again, the 555 is just too power hungry, and the PIC is a bit of a waste of technology. I admit, I could use a PIC10 or PIC12 and get better usage, but I left assembly behind more than a few years ago and I’m not planning on looking back.

As luck would have it the LCM7215’s have just arrived on my desk. And yes, the 5 SOT-23 devices did come packaged in an A4 envelope. 

Stereotypical beginners electronics project

The In-Laws have just moved house. I say move house, but what I mean is sold their old self-build, bought a field in deepest darkest Norfolk and are planning to self-build again. This is great news because it means they’ve got a blank canvas to fill with numerous eco-build projects. The first of which is a criminal deterent. I’m sure the working ip-camera will be used at some point but until then a decoy camera will have to suffice. Decoy cameras work fine so long at they remain believable, and so this decoy camera needs that little extra bit of polish; a flashing LED.

The flashing LED project is the “Hello World” for those whose programming language is solder. Any time you learn a new microcontroller, you will face the flashing LED tutorial. This is designed so that you can set up all the important registers and interface with the outside world. When you talk about flashing LED projects without using a mcu, people will generally offer the 555 timer as a solution. I’m going to look at three options, and hopefully have a working flashing light at the end.

The main design considerations are the need for a long battery life, and a fairly cheap design. I’m going to be using the LPKF Protomat C60 at work to cut the board out, and I’ll be trying to use components I have in my bits box, or can get free samples of. I am aiming for the design to fit on the back of my selected battery solution, and have a suitable mounting fixture integrated into the PCB design.

I know I need to use battery power, and once installed the batteries can’t really be changed. The build should take 2 years, and so I am aiming for more than that. I’m going to overengineer this aspect horendiously as my professional integrety is at stake. Obviously, a car battery would be a rediculous solution, and although space is not at a premium I’d still like to make the package small. My options consist of a single PP3 battery, a single CR2032, or a pair of AA batteries. The CR2032 only has a capacity of around 200mAh, with the PP3 only doubling that. The AA has to be the victor at well over 1000mAh. Thankfully, the AA battery holder is a also almost half the cost of a CR2032 holder. Lastly, is the actual flashing LED. A flashing light project without a flashing light simply isn’t. The minimum current draw I can reasonably expect to look at is 1mA. Any lower and I dont think the LED would be bright enough to see at a distance. The human visual cortex holds onto an image for about 1/15s, or approx 66ms, so I think that 100ms is a reasonable on time for the circuit.

I’ve mentioned the 555 timer as a possible solution so lets examine that a bit closer. Normally, the 555 doesn’t output a duty cycle of less that 50% which is bad for a low power design. The duty cycle issue can be addressed with a 1N4148 in parallel with the resistor between the discharge and trigger pins. Alternatively, you can reverse the LED and connect to Vdd instead of Vss, sinking current through the 555. The ICM7555 is Maxim’s low power derivative of the 555, having a typical supply current of 60uA. Assuming a battery capacity of 1000mAh, the 555 would run for 16666.67 hours (a month less than 2 years) without flashing an LED. The 555 just doesn’t cut it.

The next obvious solution would be a low power microcontroller. This is great as the LED can do more than just flash. It can reverse bias the LED to work as a light detection circuit, and the LED can do a double flash for extra realism. The PIC18LF13K22 has a low power sleep current consumption of only 460nA. This would be 34nA but I need to keep a timer running to wake the thing up. Even a draw of 460nA  gives a run time of 248 years on a 1000mA battery, which is just crazy. Adding the LED gives a battery life of 5 and a half years. With a BOM of only 5 components this ticks every box, but using a microcontroller feels like cheating. I think this will be my backup plan if the next idea falls through.

My final option is an op-amp. The op-amp in question is Linear Technology’s LMC7215. By using positive and negative feedback and a crafty 1N4148, the LMC7215 can be made to oscillate with a definable peroid and duty cycle. I used LTSpice to simulate the actual circuit and can extract the predicted current draw (tutorial to follow), giving a battery life of just over 5 years. Using my parts box, I managed to get a on-time of 92ms, and a period of 4 seconds.

 

 

 

 

 

 

 

 

The op-amp circuit does give a higher parts count, but this still ticks every box, and I think it is more elegant than the PIC solution. Next article, I will be showing how to use LTSpice to come up with the appropriate values, and importing SPICE definitions into the circuit. I will also lay out the PCB in CAD, and start the enclosure design. See you then.

Free Day recap and blasted Android

This post will be a shadow of the one that I had originally composed using the WordPress for Android app that I installed last night. It had wit aplenty, but my phone decided that it had a better idea – and managed to lose every character. With that aside, let me get started.

I completed my children’s toy. I designed in about 6 games that managed to please the youngest through to eldest, and have only used around 10% of the program memory. I wasn’t affected too much by feature creep, and I’ve started looking at a NiMH charging circuit so I shouldn’t have to open the box to charge the batteries. I clearly have a lot to learn about toy design, as the power connector has broken. I used some 100 thou pitch header pins to act as the power connector, and I forgot to close the box after a late night adding the scoring functionality leading to two snapped pins. This wouldn’t be so bad apart from the fact they snapped inside the female header pins. I ran into another hitch when water got spilt on the toy. I had used some fibre washers (instead of nylon) and even once the spillage had been mopped up I still had a 7ohm short across my power rails.

Part of the design brief was to build something to teach my children about electronics in one form or another. Every time I meet up with my family, I get reminded about things I did when I was younger; including sticking coat hangers in plug sockets, taking TV’s apart, and electrocuting my little brother with my bedroom light. The response to escapades was receiving a 100-in-1 electronics workbench. Whilst this was a great idea, I didn’t learn anything from it. Not because I already knew how the circuits operated, but because I followed the instruction booklet until the circuit worked. Schools answer to electronics was Ohm’s Law and logic gates. It wasn’t until university that I began to lean how circuits worked. I don’t want this for my children. I don’t want my children to be part of the throw-away culture that I grew up during, and I don’t want them to have to put up with toys where batteries last a day because the designer had to save a penny on a power switch. I’ve designed power saving features into this toy; the PIC sleeps whenever it can, and everything sits behind a LDO voltage regulator with a shutdown pin. I’ve not worked out what the battery life should be, but they lasted a month before the pins snapped. I designed the case with a clear front, and tried to minimise the number of tracks on the bottom layer. The idea behind this was so that it was possible to see how everything connects together. Of course this led to embarrassment when the lack of sleep and a silkscreen meant that a couple of chips were soldered the wrong way round. This shouldn’t have been a problem apart from when I delaminated one of the pads and had to solder in a jumper wire.

Yes, I did say pads. This board was primarily surface mount. Despite working on PCB’s daily, I still consider myself to be a hobbyist and unlike a number of hobbyists I prefer surface mount components. I am fortunate to have access to a PCB cutting machine at work, and so UV light boxes and PCB pillar drills are a thing of the past. The board is easy enough for a child to manufacture, but I wouldn’t trust my 6 year old with hand soldering a 0.5mm pitch TQFP chip. All I have taught my children is that they can write firmware for toys. I decided to supplement this was some soldering on another product, just to hammer home that the can create usable things. Whilst growing up, my grandfather made an electronic die. I wanted to go beyond this, so foolishly bought an electronic die kit. This was only £6 from Maplins (similar to RadioShack), but it meant having the kit straight away. The circuit consisted of a PPL chip, binary counter, LEDs and a load of passive electronics. The PCB has a solder mask and so was relatively simple for said 6 year old to assemble under intense supervision. I was tempted to make a case for it, and include a power switch to make it a finished product – but I am not happy with the design.

I know hundreds, if not thousands, of people dislike using microcontrollers to flash LEDs. An electronic die is a flashy light project, and one that is clearly doesn’t need a microcontroller. Using PLL and binary counter chips give a pretty simple circuit, but uses 30 components – and will eat through the PP3 battery. I am planning on designing a replacement circuit using the PIC18F14K22 as the brains. I want to use the minimum number of components whilst retaining the feel of a die. This means I need to use 7 LEDs as die pips instead of a single 7 segment display. The remainder of my circuit will consist of a piezo-transducer and CR2032 coin cell. As I’m powering the circuit from a 3.0v cell, I should be able to ignore the requirement for current limiting resistors on the LEDs. Failing that, it should be possible to use PWM to help limit the current. A diode and resistor are needed to protect the PIC from the voltages generated by the piezo, and a resistor is needed to bias the MCLR pin. This gives a total of 13 components.

I have no experience of cost analysis, or cost reduction. It is immediately obvious that there are fewer components. This means a cheaper PCB as the PCB is smaller and requires less processing. Smaller PCB and fewer components mean cheaper shipping. Fewer components means less warehouse utilisation and the board is quicker to assemble. On the other side, the PIC costs slightly more than the PPL and binary counter chips, and time is spent programming the device. An additional overhead cost would be the time developing firmware for the die. I haven’t touched on the “running cost” of the die as battery life needs to be considered. And finally, there is the case of perceived value, “coolness”, and appropriateness.

Functionally, the bought kit performs adequately. Once the button is pressed, a 100nF capacitor is charged and used to trigger the PLL. As the voltage decays, the PLL slows down and eventually stops. The effect is that the LEDs flash as the numbers roll round and stop on a particular value. This value is effectively random, as the numbers roll round quicker than human perception. My version would use the PIC’s ADC to convert the piezo-transducer voltage to a binary representation. Additionally, I will keep the PIC in a low-power sleep mode to be awoken by the piezo voltage spike. My chosen PIC is a 20pin device, so I don’t need to resort to Charlie-plexing to light the LEDs. Both designs would have a suitably random roll rate, but in my opinion the PIC method has an overall higher perceived value.

I want this to look like a quality product. To this end, I am considering using iTeadStudio for PCBs and some of the tools at work for an acrylic case. We will see how that turns out, but for now I’ve got to wait for my Sparkfun freebies. I say freebies, but I’ve already paid form shipping, and I’m fairly sure I’ll need to stump money for VAT. Oh the joys of living in the UK.

Excuses

I made a promise that I would have some extra info on stepper motors, and clearly this isn’t it. I got very distracted with the parallel port work. Parallel port stuff used to be easy in Win98 and earlier, but got more difficult in XP. By more difficult I mean I had to install “inpout32.dll” and do some funky stuff in C#. But to use “inpout32.dll” you have to know the I/O start address, so I started blindly running towards what I thought the solution was.

To find out your start address you can simply head to Device Manager, open up the LPT tab, and click on Resources. For me, the I/O range starts at 0378. This is not the value you want, as it is the HEX representation of the address. As it turns out the integer address is 888. To save the user from going through these steps I had to dip into WMI and extract the information from there. Now there is no one place where you can tie together “LPT” and port address, so I had to connect them together using the PnPDeviceID. This took me ages to figure out as I had never used WMI before. Long story short, I have got the stepper turning controlled from the parallel port and also from a PIC from RS232.All I need to do is write the article, and generate some usable schematics.

However, I got distracted by designing something for my kids to play with. As an engineer I can’t help but be critical of a large number of children toys. I am not including things like Mindstorms, but I guess you get what you pay for. I want to show my children that electronics isn’t magic. They all use technology in one form or another, but I don’t want them to take it for granted. I want to show how a TV remote works, and how they can use something instead of the remote to change channels.

At the moment I have specced out some features, and it has already suffered from significant feature creep:

  • Fit inside a dual gang back box (850x1470x35mm)
  • Clear acrylic lid to show electronics
  • Attempt to route everything on top layer
  • 16 red/green LEDs
  • 16 tactile switches
  • 16×2 LCD display
  • Rotary encoder
  • Powered from 4 rechargeable batteries
  • Small prototype area

I want to make sure this will grow as they do, and have features so it will entertain all of them (20months – 6 years). There is little doubt that it will remain interesting for all of 5 minutes, but that is no different from any of their toys. Currently I am deciding whether I should include any IR LEDs for controlling the TV, or  Sparkfun’s 3-axis gyroscope. I’ve even got a small touchscreen digitizer that could make its way inside. And of course there is always room for a little speaker.

Clearly, there is some more feature creep to go.

 

Hello Caller, You Are Through To The Helpdesk Part4

If you remember my last post, I had finished sorting out the hardware, and had just taken the plunge with fishing around for working embedded software. I’ll be honest, it didn’t take many attempts to find a “working” solution, but each attempt felt like an age due to the switching between programs to use XMODEM. For some reason RealTerm doesn’t support XMODEM, and TeraTerm simply wouldn’t send the data. I found ClearTerminal, which although managed absolutely fine with XMODEM there were issues with interrupting the boot process of the camera; a necessary step when dealing with experimental Linux images. 

I hit various brick walls, including the camera having a “Kernel panic”, and numerous I2C errors. The Kernel Panic was due to a completely incompatible firmware, and the I2C error seemed to be triggered by some “missing” hardware. Missing in that the camera would support it, but it simply wasn’t included in this model.

On the forth attempt I tried software designed for the HooToo camera – and not only had the camera booting up, but I also had a web interface to use. This wasn’t the nicest interface in the world, but at least I could see the video stream and control the camera. The hardware was fixed, some software was running; job done, or so I thought.

This camera originally came with some software that when installed prompted the user to enter the camera’s serial number. This serial number is used to tie together the camera and a DDNS service. DDNS stands for Dynamic Domain Name Service, and once set up it allows you to view the IP camera from anywhere in the world. The HooToo software has an unknown DDNS hard coded, or allows you to specify a different DDNS service. Unfortunately, this was restricted to DynDNS.org and a couple dodgy Chinese services that my browser warned me against visiting.After some digging around I realised that the DDNS information is held in the romfs.bin file, and that it might be possible to use parts of my original extracted romfs.bin file to overwrite HooToo’s default DDNS service information.

At which point it struck me, I already had a working webui.bin and romfs.bin as it was just my linux.zip file that the camera had decided it didn’t need anymore. So I reflashed my original working files and the working linux.zip from HooToo and … it didn’t work. Well, that is not strictly true. The camera was working, and I could use an additional piece of software to control the camera, and get its video feed, but the website was a pink background with “Page not found” plastered on it. I assume there are some checks in the implementation of that uCLinux that checks the versions of romfs.bin and webui.bin.

For me, the challenge had been won with the HooToo firmware. I had traced the problem back to some shorted pins, and theorised that the problem was with the position of the ARM processor relative to the mounting hole of the camera. The camera was now in a usable state, and the intellectual challenge was over.All that was left was to brute force the firmware issues. I emailed StorageOptions on the off chance that they would take me at my word, and not think of me as a backstreet manufacturer too lazy to play with embedded software. They have yet to reply to me, so I have resorted to creating a table of every possible combination of linux.zip, romfs.bin and webui.bin to find other working combinations. If nothing, this will be some potentially useful information to feed back into the community.

And now, I stalled again. I made the mistake of sharing my progress with the customer (i.e. my father-in-law), and he was so impressed that I’d brought his camera back from the dead that he wanted it back. The website and DDNS functionality weren’t working, but he is fine with that at the moment as you can still view the stream and control the camera from an additional piece of software. I would be surprised if a mobile app wasn’t in existence or in progress, and the DDNS issue can be resolved by remembering your home’s IP address. So it is with a heavy heart that I bid farewell to the camera. It has been fun.