DocScrutinizer05 changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
larsc has quit [Remote host closed the connection]
sb0 has joined #qi-hardware
atommann has joined #qi-hardware
viric has quit [Ping timeout: 256 seconds]
viric has joined #qi-hardware
fengling_ is now known as fengling
xiangfu has joined #qi-hardware
<whitequark> hey wpwrak_ DocScrutinizer05
<whitequark> so there's a circuit like this: https://pbs.twimg.com/media/B8aAls9CEAIlrhs.png:large
<whitequark> when SW1 is closed, the MCU input connected to SW2 (normally open) trips spuriously
<DocScrutinizer05> hmm
<whitequark> the solenoid at the right is actually a pinball machine flipper
<DocScrutinizer05> (sorry, sick. maybe there's some old slivers where my brain should be)
<whitequark> what I don't really understand is,
<whitequark> even if the high transient currents in the wiring to the solenoid induce voltage elsewhere
<DocScrutinizer05> ooh pinball, now you got my full attention
<whitequark> it shouldn't happen to a wire that is essentially floating
<whitequark> and pulled down on the MCU side (10k on-chip resistor)
<DocScrutinizer05> it will
<whitequark> how'd that even work? you do not have a closed path
<whitequark> i mean, there's probably some parasitic capacitance between that wire and MCU ground
<whitequark> a few dozen pF at most
<whitequark> and it IS pulled down, not just floating
<DocScrutinizer05> actually EOS is to force high current through solenoid until it moved to end position. Then the contact opens to reduce current flowing through solenoid
<whitequark> yep, that much I gathered
<whitequark> it should consume 8A@30V for a few ms
<DocScrutinizer05> (unrelated mostly to the problem here)
<DocScrutinizer05> :nod:
<whitequark> the layout is
<whitequark> gnarly
<whitequark> but i guess that's inevitable
<DocScrutinizer05> yep
<whitequark> so, any ideas what can be done to fix the spurious SW2 trips?
<DocScrutinizer05> have the pair(!) of wires from MCU to sw2 twisted, keep them away from other high current wires. Increase load (inside MCU) to 1k or less, add a RF capacitor and naybe a ferrite bead
<whitequark> ok, so what i suggested to her wasn't wrong...
<DocScrutinizer05> that's RF interference, not capacitive phantom current
<whitequark> hmm
<DocScrutinizer05> SW1 creates lots of RF noise
<DocScrutinizer05> actually EOS switch, not sw1
<whitequark> putting a snubber on EOS switch also didn't do anything to mitigate this
<whitequark> apparently
sb0 has quit [Quit: Leaving]
<whitequark> RF capacitor where?
<whitequark> across the solenoid?
<DocScrutinizer05> bead and 47pF on MCU input
<whitequark> right
<DocScrutinizer05> also consider the magnetic field of solenoid
<DocScrutinizer05> whitequark: what is sw1?
<DocScrutinizer05> I assumed it was related/mounted to flipper solenoid. Maybe it's not at all?
<DocScrutinizer05> err sw2, sorry
arhuaco has quit [Remote host closed the connection]
<whitequark> sw2 is a button on the photo
<DocScrutinizer05> ?
<whitequark> so it's not mounted on solenoid
<DocScrutinizer05> which button?
<whitequark> see the red wire at bottom?
<DocScrutinizer05> yes
<DocScrutinizer05> well, "wire"
<whitequark> it closes red/green (ignore blue, it doesn't exist)
<whitequark> and so switches on the solenoid
<DocScrutinizer05> sw2?
<whitequark> sw2 yes
<DocScrutinizer05> and what's sw1 then?
<whitequark> another unrelated switch elsewhere
<DocScrutinizer05> err
<DocScrutinizer05> so how does sw2 switch on the solenoid?
<whitequark> crap\
arhuaco has joined #qi-hardware
<whitequark> i mixed these up
<whitequark> SW1 is the red button on the photo
<whitequark> SW2 is a switch elsewhere
<DocScrutinizer05> where?
<whitequark> sec
<DocScrutinizer05> make sure neither of both contacts of SW2 has connection to any GND or huge metal area
<DocScrutinizer05> make sure the wiring from MCU to SW2 is twistet pair
zacaj has joined #qi-hardware
<whitequark> DocScrutinizer05: so, this is zacaj's pinball machine
<DocScrutinizer05> also make sure MCU and solenoid don't share GND wiring
<whitequark> zacaj: where's SW1 located?
<whitequark> er SW2
<whitequark> the one connected to MCU input
<zacaj> there's a whole bunch,\ all over the playfield
<DocScrutinizer05> roll over buttons?
<zacaj> my MCU and my solenoids need to share GND at some point so that I can control them via MOSFETs
<DocScrutinizer05> or taget or sth
<zacaj> yes, rollovers, targets, etc
<DocScrutinizer05> sure connect GND, but don't share wiring
<zacaj> I have them connected at one point near the PSUs
<DocScrutinizer05> star topology
<zacaj> no, not shared
<zacaj> just wanted to clarify/make sure
<zacaj> yep
<DocScrutinizer05> good
<DocScrutinizer05> you built MCU?
<DocScrutinizer05> or at least know it?
<DocScrutinizer05> what's the input ?
<zacaj> what do you mean?
<DocScrutinizer05> GPIO with nothing else? opto coupler? relay coil?
<DocScrutinizer05> GPIO with added pull down resistor?
<zacaj> it's just the wire running from the switch to the GPIO, with an internal pulldown
<DocScrutinizer05> eeek
<zacaj> I tried adding a 10k external pulldown, and it didn't affect it at all
<DocScrutinizer05> add a 500R pulldown, and proper clamping diodes to + and GND, and from that a 10k to GPIO
<DocScrutinizer05> or 4k7
<DocScrutinizer05> GPIO are not made for that sort of input signals, really
<DocScrutinizer05> you need to add some protective and impedance matching gear
<DocScrutinizer05> ideally use opto couplers
<DocScrutinizer05> actually the contacts of SW2 *need* a certain minimum current to keep them clean
<zacaj> so this level of spikes and interference from the coils is standard, (eg best I'm going to get) and I should be attempting to smooth it off in various ways at the inputs, instead of trying to lower the source of the interference?
<DocScrutinizer05> yes
<zacaj> alright.. some of my inputs go through a shift register, and they seem to work fine, so for the inputs I guess I could just re-route all my GPIO ones through that.
<DocScrutinizer05> honestly I strongly recommend using opto couplers for this. Particularly for this environment
<DocScrutinizer05> otherwise I wouldn't take bets on how long your chip will live
<zacaj> I'm also having trouble with my LED driver chips 'randomizing' sometimes when I flip, is there anything besides sticking some decoupling capacitors on I could do for that?
<DocScrutinizer05> it deteriorates from the harsh input signals you encounter in a high current + solenoids environment like this one
<DocScrutinizer05> generally try going low impedance design
<DocScrutinizer05> use capacitors everywhere to clamp high frequencies (on digital signals)
<DocScrutinizer05> use termination resistors in the range <1k on all inputs
<DocScrutinizer05> design for mechanical switches like SW2 at least dealng with 20mA load
<DocScrutinizer05> i.e. even lower termination resistors
<whitequark> hm, clever
<zacaj> alright, thanks. I'll give some of that a shot
<DocScrutinizer05> and check about "self cleaning current" of contacts. I dunno if I vcan find the right wiki article right away. generally open contacts need a certain minimum current they have to switch, so any oxide etc will "burn away". Otherwise they eventually start failing
<DocScrutinizer05> "open" as in "not sealed"
<DocScrutinizer05> a reed contact in a glass tube with inert gas has few requirements like those. The contacts you deal with in your pinball cabinet need some tens of mA at least to stay "fresh"
<DocScrutinizer05> oooh, btw: those glitches on sw2 even might be triggered by mechanical vibration, particularly when the contacts have insufficient load as elaborated in lines above. This would be a typical problem of contacts building up issues without self cleaning
<DocScrutinizer05> you might test the conductivity (Ohms) of SW2 and see if it has some increased R_closed already
<DocScrutinizer05> this would be a noisy effect seen every now and then, so a single short time test may not tell much, you need to probe the thing several times, opening and closing it slowly and gently. Ideally using a scope to see excessive bouncing etc
<zacaj> I tested with SW2 disconnected completely from the GPIO and I'd still get glitches
Haswell has joined #qi-hardware
<DocScrutinizer05> ((trouble with my LED driver chips 'randomizing')) use proper 47pF 22nF supply voltage buffering next to the chips. Consider shielding of the whole circuit, eg. with a alu coated carton you place on the soldering side of PCB and connect the ALU to GND
<DocScrutinizer05> ((still glitches)) ooh on MCU?
<DocScrutinizer05> i.e. the MCU glitches even on GPIO that are not connected to any wires?
<zacaj> yes
<DocScrutinizer05> if yes, you need to test of it still does when you short the input to GND
<DocScrutinizer05> and you should consider proper shielding of your MCU PCB
<zacaj> short the switch, or the GPIO?
<DocScrutinizer05> and make sure your power supply is clean: place some huge ferrite bead on VDD wire, next to the MCU, and a buffer capacitor behind that
<DocScrutinizer05> you said the GPIO is not connected to any wires and still gets glitches. So short to GND the PCB connection point where wire would go
<DocScrutinizer05> that's the brute force low inpedance design ;-) When it still sees glitches even when GPIO grounded, we face another problem
<DocScrutinizer05> if grounding fixes the problem, it's clearly cause by electromagnetic interference and can get fixed by appropriate measures
<DocScrutinizer05> like low impedance termination, i.e. a 470R from GPIO input to GND
<DocScrutinizer05> 220R maybe, to give the contacts something to work with (self cleaning)
<DocScrutinizer05> assuming this 3.3V in that drawing is correct
<zacaj> yeah, 3.3v
<DocScrutinizer05> in addition you want a 47pF and a 100nF parallel to that 220R. And optimum would be a 10kR from all that to the real GPIO
<DocScrutinizer05> hmm, rather place the 100nF parallel to SW2
<DocScrutinizer05> close to sw2
<DocScrutinizer05> iow at far end of the twisted pair wire
<zacaj> 'real GPIO'?
<DocScrutinizer05> but still such design has a lot of "antennas" feeding all sort of noise to your MCU GND
<DocScrutinizer05> CHIP GPIO <-10kR-> C-toGND, R-to-GND <---wire------
<DocScrutinizer05> (noise to MCU GND) or to VDD 3V3 in your case
<zacaj> k, that's what I thought
<DocScrutinizer05> opto couplers are a sure bet to fix all issues of such design
<DocScrutinizer05> just use "separate" GND and VDD for external side of couplers
<whitequark> and same solution for MOSFETs
<DocScrutinizer05> ideally yes
<zacaj> k, thanks. I'm off to bed
zacaj has quit [Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150108202552]]
tumdedum has quit [Ping timeout: 264 seconds]
tumdedum has joined #qi-hardware
archang has quit [Ping timeout: 264 seconds]
archang has joined #qi-hardware
atommann has quit [Ping timeout: 240 seconds]
jekhor__ has joined #qi-hardware
atommann has joined #qi-hardware
sb0 has joined #qi-hardware
xiangfu has quit [Remote host closed the connection]
fengling has quit [Ping timeout: 244 seconds]
fengling has joined #qi-hardware
atommann has quit [Ping timeout: 264 seconds]
wej has quit [Ping timeout: 272 seconds]
atommann has joined #qi-hardware
wej has joined #qi-hardware
atommann has quit [Ping timeout: 276 seconds]
atommann has joined #qi-hardware
pcercuei_ has joined #qi-hardware
jekhor__ has quit [Ping timeout: 265 seconds]
pcercuei_ is now known as pcercuei
wolfspraul has joined #qi-hardware
lars_ has joined #qi-hardware
lars_ is now known as larsc
jekhor__ has joined #qi-hardware
whitequark has quit [Ping timeout: 272 seconds]
whitequark has joined #qi-hardware
xiangfu has joined #qi-hardware
fengling has quit [Quit: WeeChat 1.0]
xiangfu has quit [Remote host closed the connection]
jekhor_ has joined #qi-hardware
jekhor__ has quit [Ping timeout: 264 seconds]
Haswell has quit [Quit: Saliendo]
atommann has quit [Ping timeout: 264 seconds]
lars_ has joined #qi-hardware
jekhor__ has joined #qi-hardware
jekhor_ has quit [Ping timeout: 252 seconds]
atommann has joined #qi-hardware
methril has quit [Ping timeout: 245 seconds]
<wpwrak_> nicksydney: cute ;-) and even open hw. btw, you should make a kickstarter project to create a taxonomy of all those little boards :)
<nicksydney> wpwrak_: heheheh.....no need http://www.cnx-software.com/ already have the list :)
<wpwrak_> but you could format it nicely :) break it down into tables comparing features, etc. that's more work that one may think
methril has joined #qi-hardware
kyak has quit [Quit: Lost terminal]
wolfspraul has quit [Ping timeout: 264 seconds]
<nicksydney> wpwrak_: maybe i should start a wiki page for that
<nicksydney> will do that in qi-hardware website later
wolfspraul has joined #qi-hardware
pcercuei has quit [Ping timeout: 276 seconds]
pcercuei has joined #qi-hardware
atommann has quit [Quit: Leaving]
methril has quit [Ping timeout: 252 seconds]
methril has joined #qi-hardware
methril has quit [Ping timeout: 252 seconds]
methril has joined #qi-hardware
sb0 has quit [Quit: Leaving]
sb0 has joined #qi-hardware
porchao has quit [Quit: Leaving...]
<kristianpaul> sb0
<sb0> "optionally, could support a Si Avalanche Photo-Diode (APD)"
<sb0> are those going to be less expensive?
<kristianpaul> dont know
jekhor_ has joined #qi-hardware
jekhor__ has quit [Ping timeout: 256 seconds]
jekhor__ has joined #qi-hardware
jekhor_ has quit [Ping timeout: 246 seconds]
wej has quit [Ping timeout: 245 seconds]
wej has joined #qi-hardware
sb0 has quit [Quit: Leaving]
pcercuei has quit [Ping timeout: 272 seconds]
kyak has joined #qi-hardware
kyak has joined #qi-hardware
shinobi has joined #qi-hardware
Jay7x has quit [Read error: Connection reset by peer]
pcercuei has joined #qi-hardware
jekhor__ has quit [Ping timeout: 256 seconds]
shinobi has left #qi-hardware ["Konversation terminated!"]
wolfspraul has quit [Quit: leaving]
pcercuei has quit [Ping timeout: 265 seconds]
pcercuei has joined #qi-hardware
jekhor__ has joined #qi-hardware
Jay7 has joined #qi-hardware
methril has quit [Quit: Leaving]
FDCX_ has joined #qi-hardware
porchao has joined #qi-hardware
roh has quit [Ping timeout: 252 seconds]
roh has joined #qi-hardware
larsc has quit [Remote host closed the connection]
larsc has joined #qi-hardware
larsc has quit [Ping timeout: 264 seconds]
larsc has joined #qi-hardware
jekhor__ has quit [Ping timeout: 256 seconds]
wej has quit [Ping timeout: 250 seconds]
wej has joined #qi-hardware
FDCX_ has quit [Ping timeout: 245 seconds]
wej has quit [Ping timeout: 245 seconds]
Textmode has joined #qi-hardware
pcercuei has quit [Ping timeout: 276 seconds]
wej has joined #qi-hardware