Jump to content
  • Advertisement

Design a circuit for childrens electric game

Recommended Posts

Some might remember a childrens game where you have a sheet of symbols, holes in it that lead to contacts, and then you have two wires and whenever you have two symbols that match you put some cables onto those two, and a light shines that tells you, you were right. In my childhood this game was simply called "electric" and I want to create a similar game for my kids too, that doesn't fall apart as soon as you look at it.

My goal for the design were

  • Will fit into an approximately test tube sized transparent plastic tube
  • For the looks is a freeform circuit
  • Does not use anything more complex than a transistor (i.e. only three pin TO devices, no more pins or flatpacks or so)
  • When the contacts are closed, will light an LED for about 2 seconds
  • Will draw very low (ideally none) power when not active
  • LED will not go out while contacts are closed
  • LED will turn on to full brightness, and when it goes off it shall not dim, but instantly go down to zero brightness. Some not really visible brightness changes (i.e. current fluctuations) are ok though.
  • Amount of "P " transistors (PNP, PMOS) or other uncommon ones is low or zero. Ideally would be NPN only.

My design started out with some simple latching switch, adding timeout and other requirements as I went along, and what I came up with in the end is (ignore V2-V4 and S1, they are for testing the leads actions):

enter image description here

Basically around Q1 and Q4 is the latching switch, C2 is charging up until M1 causes the switch to latch off again; Q5 is there to hinder charging of C2 as long as the leads are connected.

Unfortunately that feels like too much components for this task. Also -- while the LED stays on while leads are connected -- it does not really do retriggering, at least not for very short contacts. This might be fixed by adding yet another transistor in front of Q5 to increase the current it shunts C2 to ground with, but that would mean: yet another component.

So the question is:

Can this be simplified to less components, or at least NPN only? Maybe at the same time solving the retrigger problem, or can that at least be solved without adding transistors?

Note: I might have forgot to mention some requirement because it is evident for me how the game should work, but not for you if you are unfamiliar with it. If you have the feeling that it would be the case with your suggestion, I would appreciate if you ask if "behaviour XYZ" is ok too.

Share this post

Link to post
Share on other sites

Kids learn to use touch screens pretty early in life. Please reduce trash. Besides I would strive for a RF solution, no real contacts which can corrode. Why not just use a Rasphery Pi?

Share this post

Link to post
Share on other sites
Posted (edited)

#arnero: Why on earth should he use an RF based solution for something this simple? There is such a thing as over engineering.

As for the OP, the schematic looks quite overcomplicated I must say, unless I misunderstood how you want to to work (which I might have :) )

Edit: Missed a bit in your description, anyways, I think a monostable multivibrator might do the trick, have a look on the link below. The NOR gate based solution near the bottom might be suitable?


Edited by BG109

Share this post

Link to post
Share on other sites
On 12/28/2017 at 12:43 PM, arnero said:

Why not just use a Rasphery Pi?

A single tiny AVR/PIC chip would be more than enough, and would work from a single coin cell battery (or 3 button cells), consuming some nanoamps in sleeping mode.

I wonder though why it must be a bunch of discrete elements instead of a single microcontroller. The components count is already too high for such a toy.

Share this post

Link to post
Share on other sites

I do agree with vstrakh to some extent here. The only reason I tried suggesting discreete alternative solutions is that we dont know if the OP has any experience in embedded programming, or only in analog electronics.

Also it would be interesting to know the number of connections intended, if only a few discretes might works just as fine but for a larger number than of-course a simple uC would be much better.

The only comment on the above I could add is that I would not recommend a coincell if there is supposed to be moderately strong driving current to the led or if multiple leds are driven, at least for long lifetime. Coincells typically have quite high internal resistance and as such when starting to be depleted the extra current draw when turning on the led could cause the uC to reset due to brownout

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!