🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Design a circuit for childrens electric game

Started by
4 comments, last by BG109 6 years, 6 months ago

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.

Advertisement

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?

#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?

http://www.electronics-tutorials.ws/waveforms/monostable.html

Currently making BorderStrain, 2D Sandbox ARPG www.BorderStrain.com

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.

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

Currently making BorderStrain, 2D Sandbox ARPG www.BorderStrain.com

This topic is closed to new replies.

Advertisement