Car stereos often have two 12V inputs. The switched (red) cable and the
constant (yellow) cable. The constant 12V is there to keep memory
settings and power the clock, etc.
> Hi Ken,
> Thanks for that, it will simplify things quite a bit :)
> I need all the help I can get being a 95% software guy.
> I will let you know how I go
> Karel
> On Wednesday, September 5, 2012 3:07:40 PM UTC+10, ken ihara wrote:
> Hi Karel,
> Use pin 2 (!Q, which is always opposite of Q) as output from flip
> flop. That pin will be high until button is pressed.
> FYI -- since you are using the set pin, the debounce circuitry you
> currently have is not necessary (though it doesn't hurt)
> Ken
> On 5/09/2012 2:51 PM, kspn wrote:
>> Hi Ken,
>> That looks like it may be exactly what I need, I take the run
>> form the switch, put it into the 'set' pin and then take the
>> 'out' pin and plug that into the RasPi.
>> I also then have a ping running form the RasPi into the Reset pin
>> to clear the switch. Nice :)
>> Thanks for that, I will just need to work out exactly how it will
>> need to plug into my setup to ensure that I don't cause issues
>> (at the moment I have GPIO 'high' until the switch is pressed, I
>> ill need to work out how to get the input into a 'low' state and
>> button push becomes 'high'.
>> This gives me a great pace to start next weekend :)
>> Karel
>> On Wednesday, September 5, 2012 2:41:16 PM UTC+10, ken ihara wrote:
>> Hi Karel,
>> Attached is a schematic for the SR implementation. I think
>> this is what Andy was talking about on Saturday. The 4013 is
>> available at Jaycar and costs $.95 each. You'll need 2.
>> Cheers,
>> Ken
>> On 5/09/2012 11:48 AM, kspn wrote:
>>> Hi Zac (#2) :)
>>> Unfortunately a 'quick' google search didn't yield a circuit
>>> diagram that I can use, do you (or anyone else) know where I
>>> could find such a diagram, then I can decide between the 2
>>> types 8-)
>>> Karel
>>> On Wednesday, September 5, 2012 11:42:06 AM UTC+10, Zac wrote:
>>> As already suggested by Luke, you could consider using a
>>> Set-Reset (SR) Flip Flop. This is basically what you are
>>> aiming to implement with the Bi-Stable 555 timer,
>>> however, it should be easier to find these in quad packages.
>>> Only problem with an SR flip-flop, is that if you are
>>> holding the button down while resetting the flip flop
>>> from the R-Pi, it will give an ambiguous output
>>> (http://hyperphysics.phy-astr.gsu.edu/hbase/electronic/setreset.html#c1
>>> <http://hyperphysics.phy-astr.gsu.edu/hbase/electronic/setreset.html#c1>)
>>> which can be fixed by using a J-K flip flop (apparently).
>>> I don't have much experience with these myself....
>>> Zac (a different one).
>>> On Wed, Sep 5, 2012 at 11:32 AM, kspn <ksp...@gmail.com>
>>> wrote:
>>> Hi Zac,
>>> I found this Wiki Page
>>> http://en.wikipedia.org/wiki/555_timer_IC#Monostable
>>> <http://en.wikipedia.org/wiki/555_timer_IC#Monostable>
>>> The Monostable looks like what you were talking
>>> about, I 'think' I can insert this into the switch
>>> line on Pins 2/3 so that the switch is on Pin 3
>>> (trigger) and the GPIO is on Pin 2 (output).
>>> In this version, press switch, chip outputs 'high'
>>> for a time period that depends on 1.1RC timeframe
>>> I could also do it via the 'bistable' variation on
>>> the 555 chip (which might be easier as it doesn't
>>> need to Cap & resister and I can send a reset signal
>>> from the RasPi once the current value has been 'read'
>>> In this version, press switch, chip outputs 'high',
>>> RasPi sends 'Reset Signal', chip sends 'low'
>>> Can I get these assumptions checked by someone with
>>> more hardware knowledge that I have?
>>> Of course I first actually need a 4x version of the
>>> 555 chip to handle the 4 switches, but that should
>>> be doable.
>>> K
>>> On Wednesday, September 5, 2012 11:09:49 AM UTC+10,
>>> Zac Watts wrote:
>>> Theres a reset pin on a 555, presumably it
>>> resets on being pulled low, but I've never used
>>> that function. the 555 wikipedia page is fairly
>>> good and would get you going, im sure googling
>>> can get you something better. A 555 calculator
>>> would be worth looking for to find the R and C
>>> for the timing you want.
>>> Others may have an alternative monostable
>>> circuit suggestion, I'm no means an expert, but
>>> this would be my solution.
>>> On Wed, Sep 5, 2012 at 10:47 AM, kspn
>>> <ksp...@gmail.com> wrote:
>>> Hi Zac,
>>> That sounds like a possibility, it would
>>> require a bit of a code
>>> change to handle it (I would have to ensure
>>> that I don't poll the GPIO
>>> twice within the 'held live' state, say
>>> 0.2/1.2) but that is certainly
>>> one option that would work :)
>>> Would that kind of circuit be able to accept
>>> a 'reset' signal?
>>> Also where would I be able to find a circuit
>>> diagram and parts list
>>> for that?
>>> K
>>> On Sep 5, 10:34 am, Zac Watts
>>> <zwa...@gmail.com> wrote:
>>> > You could use a a 555/556 monostable type
>>> circuit to go high on a button
>>> > press and reset automatically after say, 2
>>> seconds, and poll it every 1
>>> > sec.
>>> > On Wed, Sep 5, 2012 at 9:01 AM, kspn
>>> <ksp...@gmail.com> wrote:
>>> > > Hmm, turns out to be more complex than I
>>> though, I will break it down
>>> > > into 2 items (solving them one at a time :)
>>> > > First the buttons.
>>> > > As this is sitting in my car i can't
>>> really use a keyboard or anything
>>> > > like that (I tried that and it was less
>>> successful than using the GPIO
>>> > > buttons).
>>> > > Where am I likely to find a reasonably
>>> 'simple' flip-flop circuit that
>>> > > will do the job?
>>> > > I was talking to Andy on Saturday and he
>>> suggested the Latching
>>> > > solution so that I only have to poll the
>>> switches once per second or
>>> > > so (so I can update, the screen I am
>>> using mainly), as a result I am
>>> > > not 100% certain where I should be
>>> starting with the circuit. (I can
>>> > > send an image of my current setup if
>>> that would help). A quick Google
>>> > > search returns this result:
>>> >http://www.daycounter.com/Circuits/Latching-Momentary-Switch/Latching.
>>> <http://www.daycounter.com/Circuits/Latching-Momentary-Switch/Latching.>..
>>> > > However I am unsure if:
>>> > > (1) it would be easily expandable to 4
>>> buttons,
>>> > > (2) It is more complex than I really
>>> need. (I already have a
>>> > > 'debounce' circuit for my current switches)
>>> > > (3) How would I 'reset' the switch state
>>> without pressing the switch
>>> > > again (using the output from the GPIO)
>>> > > Thanks for your help
>>> > > Karel
>>> > > On Sep 4, 8:38 pm, Luke Weston
>>> <reindeerfloti...@gmail.com> wrote:
>>> > > > > 1) I have some buttons that I am
>>> using to control my RasPi (in the car
>>> > > > > playing MP3's) via the GPIO pins,
>>> the issue is that I am using
>>> > > momentary
>>> > > > > switches to achieve this and as a
>>> result then 'check' times need to be
>>> > > > > quick low in order to not 'miss'
>>> that the button has been pressed. It
>>> > > was
>>> > > > > suggested that a 'latch and release'
>>> type of circuit would be a good
>>> > > > > solution to this, however I have
>>> absolutely no idea where to even start
>>> > > > > with this.
>>> > > > > What I need assistance with with
>>> building a circuit that:
>>> > > > > - When a button is pressed
>>> 'holds' that the button has been pressed
>>> > > > > (up to 4 buttons)
>>> > > > > - Uses another GPIO output to
>>> 'release' the button press for all
>>> > > > > buttons
>>> > > > > You might use a flip-flop for this,
>>> where the pushbutton press is
>>> > > > connected to the set input of a SR
>>> flip-flop, so it turns on (and stays
>>> > > on)
>>> > > > once set, until it is reset by the
>>> Raspberry Pi with the GPIO output from
>>> > > > the Pi connected to the reset input of
>>> a SR flip-flop.
>>> > > > Alternatively, if you want to have a
>>> good number of buttons without using
>>> > > > up all your GPIOs, you might have an
>>> external microcontroller, like an
>>> > > AVR,
>>> > > > which handles the more "time critical"
>>> task of handling the buttons, then
>>> > > > it communicates the button information
>>> back to the Raspberry via UART or
>>> > > > SPI or something.
>>> > > > Or, alternatively, how about a cheap
>>> mass-market PC USB HID input device
>>> > > > such as a keyboard or touchscreen,
>>> trackpad, trackball etc, or a hacked
>>> > > > keyboard controller connected to a few
>>> pushbutton switches, connected to
>>> > > > the RPi's USB port?
>>> > > > > 2) The second circuit that I need
>>> some assistance with is a power
>>> > > circuit,
>>> > > > > as I am using the RasPi in my car I
>>> need some kind of 'trigger' curcuit
>>> > > > > that is able to (a) turn the RasPi
>>> on (apply power) using a battery to
>>> > > > > supply power (so switching the
>>> battery source on) then once the car is
>>> > > > > turned off flag (via GPIO 3v3) to
>>> the RasPi that a shutdown is
>>> > > required so
>>> > > > > that the system can be gracefully
>>> halted (I can handle the software
>>> > > side
>>> > > > > easily, it is the hardware that I am
>>> having issues with)
>>> > > > > The basic idea is:
>>> > > > > - Car Turns On --> 'Activates'
>>> the power line from the Battery to
>>> > > the
>>> > > > > RasPi (Battery charged from Car
>>> Power)
>>> > > > > - Car Turns Off --> Power from
>>> the battery remains on, GPIO signal
>>> > > > > sent to RasPi Header, RasPi
>>> Halts, 'Deactivates' Battery Power
>>> > > > > OK, so, how about we take the 12V
>>> from the car's accessories bus or
>>> > > > whatever it's called (only on when the
>>> car is running), and we use that
>>> > > to
>>> > > > set the set input of a flip-flop, with
>>> a series resistor and a zener
>>> > > diode
>>> > > > to clamp it so the flip-flop's input
>>> is protected from the 12V.
>>> > > > The flip-flop would need to be powered
>>> from the auxiliary battery which
>>> > > is
>>> > > > "always on" and powers the raspberry pi.
>>> > > > When that flip-flop is on, it turns on
>>> a P-channel MOSFET which switches
>>> > > > the 5V rail (which has to come from a
>>> decent voltage regulator) going
>>> > > into
>>> > > > the Raspberry Pi. Even when the car's
>>> accessory 12V rail is removed, the
>>> > > > flip-flop stays on until it is told to
>>> change state.
>>> > > > We also take the car's +12V accessory
>>> rail, and divide it down to 3.3V
>>> > > and
>>> > > > clamp it with a zener diode for
>>> protection, and that is connected to the
>>> > > > RPi GPIO so the RPi is aware of the
>>> state of that rail.
>>> > > > For example you might look at the
>>> schematic here, where the throttle
>>> > > > position sensor input line (which is
>>> presumably about 14V while the
>>> > > > alternator is running) is protected
>>> using a zener diode and two
>>> > > resistors.
>>> >http://siliconchip.com.au/cms/gallery/article.html?a=108207&i=5
>>> <http://siliconchip.com.au/cms/gallery/article.html?a=108207&i=5>
>>> > > > The output voltage from the voltage
>>> divider would be expected to be about
>>> > > > 14.4V * 510k / (510k + 1M) = 4.86V.
>>> > > > Since we want a 3.3V input to the
>>> microcontroller in this case, the 510k
>>> > > > resistor should be smaller so that the
>>> voltage is smaller, for example
>>> > > I'd
>>> > > > be tempted to change the 1M resistor
>>> and 510k resistor to 10k and 2.7k
>>> > > > respectively.
>>> > > > Now, you'd need to have one of the RPi
>>> GPIO pins that is set to always be
>>> > > > high when the RPi is running, and when
>>> the RPi OS halts, that GPIO pin
>>> > > goes
>>> > > > low, and we use that pin going low to
>>> reset the flip-flop via its reset
>>> > > > input. (Might need an inverter there.)
>>> > > > But that creates a problem where the
>>> flip flop would be held in reset
>>> > > with
>>> > > > its reset line asserted prior to the
>>> RPi starting up its OS and asserting
>>> > > > that GPIO pin - so the flip-flop can
>>> never be set and the RPi can never
>>> > > > turn on in the first place.
>>> > > > It's a little bit more complicated
>>> then it sounds at first - maybe,
>>> > > instead
>>> > > > of trying to do it with hardware
>>> logic, it might be easier to do it with
>>> > > an
>>> > > > external microcontroller such as an
>>> AVR, which monitor's the car's power
>>> > > > rail, controls the FET, and
>>> communicates with the RPi over serial or SPI
>>> > > or
>>> > > > whatever, and has an awareness of when
>>> the RPi has been shut down.
>>> > > > I think this can be broken up into a
>>> bunch of discrete problems which can
>>> > > > all be solved individually and then
>>> strung together.
>>> > > > - Charging the auxilary battery from
>>> the car's 12V supply.
>>> > > > - Regulating the battery voltage down
>>> to clean 5V for the Raspberry Pi.
>>> > > > - Switching the 5V rail into the
>>> Raspberry Pi using an appropriate
>>> > > > P-channel MOSFET.
>>> > > > - Connecting the car's 12V rail to the
>>> microcontroller so the
>>> > > > microcontroller is aware of its state,
>>> with appropriate protection.
>>> > > > - A little bit of logic which can
>>> either be hardwired logic or
>>> > > implemented
>>> > > > in a microcontroller.
>>> > > > - External microcontroller or logic
>>> circuit communicating with the
>>> > > > Raspberry Pi and having an awareness
>>> of when the RPi OS has halted and
>>> > > can
>>> > > > be safely powered down without corruption.
>>> > > > Hopefully that is helpful to get you
>>> started thinking about the problem.
>>> > > > Also, this might help:
>>> >http://en.wikipedia.org/wiki/Flip-flop_(electronics)
>>> <http://en.wikipedia.org/wiki/Flip-flop_%28electronics%29>
>>> > > > It's an interesting problem.
>>> > > > It would be nice to have a button
>>> connected to a Raspberry Pi that powers
>>> > > > on the machine and boots when you
>>> press the button, and when you push the
>>> > > > button again tells the OS to safely
>>> halt, and then once it is halted it
>>> > > > turns off the power. And that's a very
>>> similar problem to the problem
>>> > > we're
>>> > > > discussing above.
>>> > > --
>>> > > You received this message because you
>>> are subscribed to the Google Groups
>>> > > "Connected Community HackerSpace" group.
>>> > > To post to this group, send an email to
>>> connected-community-hackerspace@googlegroups.com.
>>> > > To unsubscribe from this group, send
>>> email to
>>> connected-community-hackerspace+unsubscribe@googlegroups.com.
>>> > > For more options,
>>> visithttps://groups.google.com/groups/opt_out <http://groups.google.com/groups/opt_out>.
>>> --
>>> You received this message because you are
>>> subscribed to the Google Groups "Connected
>>> Community HackerSpace" group.
>>> To post to this group, send an email to
>>> connected-community-hackerspace@googlegroups.com.
>>> To unsubscribe from this group, send email
>>> to
>>> connected-community-hackerspace+unsubscribe@googlegroups.com.
>>> For more options, visit
>>> https://groups.google.com/groups/opt_out
>>> <https://groups.google.com/groups/opt_out>.
>>> --
>>> You received this message because you are subscribed
>>> to the Google Groups "Connected Community
>>> HackerSpace" group.
>>> To post to this group, send an email to
>>> connected-community-hackerspace@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> connected-community-hackerspace+unsubscribe@googlegroups.com.
>>> To view this discussion on the web, visit
>>> https://groups.google.com/d/msg/connected-community-hackerspace/-/wSw...
>>> <https://groups.google.com/d/msg/connected-community-hackerspace/-/wSw...>.
>>> For more options, visit
>>> https://groups.google.com/groups/opt_out
>>> <https://groups.google.com/groups/opt_out>.
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "Connected Community HackerSpace" group.
>>> To post to this group, send an email to
>>> connected-community-hackerspace@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> connected-community-hackerspace+unsubscribe@googlegroups.com.
>>> To view this discussion on the web, visit
>>> https://groups.google.com/d/msg/connected-community-hackerspace/-/_GN...
>>> <https://groups.google.com/d/msg/connected-community-hackerspace/-/_GN...>.
>>> For more options, visit
>>> https://groups.google.com/groups/opt_out
>>> <https://groups.google.com/groups/opt_out>.
>> --
>> You received this message because you are subscribed to the
>> Google Groups "Connected Community HackerSpace" group.
>> To post to this group, send an email to
>> connected-community-hackerspace@googlegroups.com <javascript:>.
>> To unsubscribe from this group, send email to
>> connected-community-hackerspace+unsubscribe@googlegroups.com
>> <javascript:>.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msg/connected-community-hackerspace/-/hMj...
>> <https://groups.google.com/d/msg/connected-community-hackerspace/-/hMj...>.
>> For more options, visit https://groups.google.com/groups/opt_out
>> <https://groups.google.com/groups/opt_out>.
> --
> You received this message because you are subscribed to the Google
> Groups "Connected Community HackerSpace" group.
> To post to this group, send an email to
> connected-community-hackerspace@googlegroups.com.
> To unsubscribe from this group, send email to
> connected-community-hackerspace+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/connected-community-hackerspace/-/JHz....
> For more options, visit https://groups.google.com/groups/opt_out.
