Back
[00:00:03] <rue_shop3> or you blew the transistors
[00:00:24] <rue_shop3> the input connector wasn't all the way in
[00:00:47] <rue_shop3> there were aliens in a ship over hte house pranking your sound system
[00:00:57] <Casper> nope, and I don't think the output transistors are blown. and nope, and nope
[00:01:05] <rue_shop3> your sound system was really a wireless keyboard stroke logger
[00:01:15] <rue_shop3> ah
[00:01:16] <Casper> nope again
[00:01:19] <rue_shop3> what brand?
[00:01:36] <Casper> yamaha ampli, omage subwoofer
[00:01:40] <rue_shop3> sony? telemechinique?
[00:01:48] <rue_shop3> yamaha...
[00:02:05] <rue_shop3> is the output stage a potted module then?
[00:02:23] <Casper> line level out to powered sub
[00:02:25] <rue_shop3> thick something...
[00:02:38] <rue_shop3> the power amp module
[00:02:51] <rue_shop3> thick film something something
[00:03:07] <rue_shop3> its a sip brick, expensive, hard to find
[00:03:30] <Casper> nope
[00:03:41] <Casper> do you give up?
[00:03:41] <rue_shop3> its discrete transistors then?
[00:03:44] <Casper> yeah
[00:03:47] <rue_shop3> cool
[00:03:56] <rue_shop3> test all the little transistors behind them
[00:04:12] <Casper> the problem ended up being visible
[00:04:22] <rue_shop3> they tend to short the collector to the base, which burns up all the small stuff driving them
[00:04:27] <Casper> (that is an huge clue!)
[00:04:35] <rue_shop3> wire wasnt in the sub?
[00:04:40] <Casper> nope
[00:04:54] <Casper> common fault in today's world
[00:05:05] <rue_shop3> the mute was on?
[00:05:13] <Casper> if only, more common than that
[00:05:24] <Casper> and affect about all electronics device
[00:05:28] <rue_shop3> ID10T error?
[00:05:44] <Casper> (that's another big clue!)
[00:05:52] <Casper> nope, real fault
[00:06:00] <rue_shop3> someone not plugged in?
[00:06:09] <rue_shop3> I'm gonna go make supper
[00:06:11] <Casper> so I checked the output from the yamaha: appear to be right
[00:06:32] <Casper> plugged my iphone to the sub, all weird, so the issue is with the sub
[00:06:48] <Casper> the issue: faulty caps!
[00:07:03] <Casper> the +60V cap in the psu section failed
[00:07:32] <Casper> the 2 caps on the driver board, on the same +60V rail failed. The yellow glue on one of them is now black
[00:07:49] <Casper> btw, the sub have a smps psu
[00:08:02] <Casper> +75V +60V -60V
[03:29:41] <neionz> is gcc-avr any ood?
[03:29:44] <neionz> good*
[04:48:59] <Jartza> neionz: is that different from avr-gcc? :)
[04:49:03] <Jartza> avr-gcc is good, yes.
[04:52:49] <neionz> :p
[04:52:59] <neionz> does anyone have the atmel ISP?
[04:53:03] <neionz> the atavrisp2
[04:53:31] <Jartza> I guess quite many do.
[04:53:37] <Jartza> I have a clone, though
[04:53:46] <Jartza> and usbasp clone also
[04:55:17] <neionz> Jartza: the ISP (atmel isp clone). Do you just connect it to the chip, or do you have to apply an external power supply to the chip as well?
[04:55:49] <Jartza> both of my programmers also supply power
[04:56:05] <Jartza> so no external power necessary (although, it can be used, if vcc pin is not connected)
[05:00:24] <neionz> omg, the official atmel ISP programmer only support 8 bit MCUs
[05:01:07] <neionz> so I can't use it for 16 bit CPUs?
[05:01:10] <neionz> MCUs*
[05:25:59] <Jartza> which 16-bit mcu?
[05:26:58] <Jartza> you mean xmega?
[05:29:23] <neionz> Jartza: atmel doesn't really make 16/32 bit mcus, do they?
[05:44:05] <bitd> Jartza, sure they do.
[05:45:30] <bitd> AT32UC3L016
[05:45:31] <Jartza> neionz: there are 8/16 bit xmegas, and atmel also makes 32 bit cpus
[05:45:56] <bitd> Sorry Jartza that comment should have been directed at neionz
[05:46:56] <bitd> Dont know how much linux based tooling there is around for the 32 bits though.
[05:47:38] <bitd> Haha nevermind, Atmel has those as well :P
[05:47:42] <Jartza> with a bit of hacking you can use usbasp to program xmegas
[05:47:54] <Jartza> but they use PDI, not ISP
[05:48:40] <Jartza> and you can get usbasp programmers from ebay with less than $3
[05:49:33] <Jartza> http://www.ebay.com/itm/321509199187
[05:49:40] <Jartza> http://szulat.blogspot.fi/2012/08/atxmega-programmer-for-050.html
[05:49:41] <bitd> I've seen that the programmers for the 32 bit mcu's are quite expensive though.
[05:49:41] <Jartza> :)
[05:58:35] <DO9XE> hmm, just thinking. In the LUFA Examples a at90usb1287 is used on a usbkey-board. If I change the crystal from 8 to 16 MHz and the FCPU in the makefile, is FUSB still equal to FCPU?
[05:59:08] <DO9XE> or do I need to set an extra value?
[06:07:16] <Jartza> bitd: hmm. atmel has "atmel ice" which is $85 iirc
[06:07:37] <Jartza> that can program basically all atmel chips
[06:08:19] <Jartza> and if you can make your own cables, it's $49
[06:08:30] <Jartza> I'm not sure if that's "quite expensive" :)
[06:08:42] <Jartza> http://store.atmel.com/PartDetail.aspx?q=p:10500377;c:100112
[06:09:20] <Jartza> Supports JTAG, SWD, PDI, TPI, aWire, SPI and debugWIRE interfaces
[06:18:48] <neionz> are AVRs a niche for a "smaller elite" of 10k people or a big market?
[06:27:08] <bitd> Jartza, haha, thats "quite cheap" actually :P
[06:27:11] <bitd> Did not know that.
[06:29:12] <Jartza> neionz: well... all arduinos are AVRs...
[06:34:44] <Lambda_Aurigae> neionz, I have at least 4 mass produced devices within reach of me that have 8bit AVR microcontrollers in them.
[06:35:05] <bitd> Same here. Quite popular :)
[06:35:05] <Lambda_Aurigae> including a rechargable USB battery pack and TV remotes.
[06:35:30] <bitd> And then there's microchip :P
[06:35:41] <Lambda_Aurigae> Jartza, arduinos are not ALL AVR....there are some ARM arduinos out there now.
[06:35:54] <Lambda_Aurigae> bitd, yeah. more PIC chips in small devices than AVR.
[06:35:55] <Jartza> Lambda_Aurigae: well... "arduinos"
[06:36:21] <Lambda_Aurigae> http://arduino.cc/en/Main/arduinoBoardDue
[06:36:30] <Lambda_Aurigae> that's an official arduino that is arm based Jartza
[06:37:00] <bitd> All arduino's are atmel based :P
[06:37:21] <Lambda_Aurigae> closer I guess.
[06:37:37] <Lambda_Aurigae> I would say the most popular 8bit processor out there is still the 8051/8052 series.
[06:37:45] <Jartza> oh
[06:37:55] <Lambda_Aurigae> not so popular in the hobby world but in the commercial world they are everywhere.
[06:38:00] <Jartza> hadn't noticed the arduino due
[06:38:11] <Jartza> but well.. all arduinos aren't atmel based either :)
[06:38:15] <Lambda_Aurigae> I found 3 of them in a new xerox copier a while back.
[06:38:45] <bitd> Cheap, well known, if you dont need more power, why would you use anything else.
[06:38:50] <Lambda_Aurigae> there is a spinoff system called pinguino that is pic and pic32 based...but that's not real arduino as they have rewritten a lot of the code.
[06:39:00] <Lambda_Aurigae> bitd, yup.
[06:39:20] <Jartza> there was at least this one chinese chip that was "mostly avr compatible"
[06:39:33] <Jartza> and someone made an arduino (at least clone) out of it
[06:39:39] <Lambda_Aurigae> yeah.
[06:40:12] <Lambda_Aurigae> they did the same with pic and scenix sx chips and the basic stamp boards back in the day.
[06:41:02] <Jartza> can't remember what p88 or something like that the chip was called
[06:41:24] <Jartza> sorry, LGT8F88A :)
[06:41:33] <Jartza> "mavr core"
[06:44:35] <Lambda_Aurigae> looks like a nice chip if it is good and stable and does what they claim.
[06:45:23] <Jartza> no experience on that
[06:45:29] <Lambda_Aurigae> two things I have on my wishlist for AVR though.
[06:45:35] <Lambda_Aurigae> neither of which will ever happen.
[06:45:45] <Lambda_Aurigae> at least, not for 8bit avr
[06:45:54] <Lambda_Aurigae> execution of program from external memory
[06:45:55] <Lambda_Aurigae> and
[06:46:32] <Lambda_Aurigae> self update of fuse bits
[06:48:09] <Lambda_Aurigae> external program space is the prime reason I still use 8052 chips.
[06:48:39] <Lambda_Aurigae> hmm...number 3 wishlist item...almost forgot about this one...usb hardware in a dip package chip!
[06:48:46] <Lambda_Aurigae> but that's just crazy talk.
[06:49:10] <vsync__> i wonder if anyone has built a reflector and glass on top of an eink display to use with a led or two
[06:49:17] <vsync__> or how feasible this idea is in the first place
[06:49:36] <Lambda_Aurigae> vsync__, I saw an acrylic overlay with LED for an eink display once.
[06:49:47] <Jartza> hmm... how does kindle do it then?
[06:49:58] <vsync__> leds placed on the sides?
[06:50:12] <vsync__> i think kindle doesn't do backlight, yeah?
[06:50:22] <neionz> what do you have an arduino for? (if for development, there are simulators)
[06:50:31] <Jartza> I have kindle with backlight
[06:50:33] <vsync__> oh
[06:50:41] <vsync__> well, take it apart then!
[06:50:50] <Jartza> called kindle paperwhite
[06:51:22] <vsync__> well, i think it has to be done with some kind of an overlay
[06:51:35] <vsync__> that's used as a reflector...?
[06:51:44] <vsync__> how even is the light distribution?
[06:52:06] <Jartza> "Paperwhite guides light towards the display from above instead of projecting it out at your eyes like back-lit displays, thereby reducing screen fatigue. You can adjust your screen's brightness to create a perfect reading experience in all lighting conditions, from bright sunlight to bedtime reading."
[06:52:11] <Jartza> very even.
[06:52:28] <vsync__> well, um. That's PR talk
[06:52:32] <Jartza> sure
[06:52:42] <vsync__> because BACK-lighting is impossible for e-ink, afaik.
[06:52:55] <Jartza> http://www.nytimes.com/interactive/2012/12/26/technology/light-reading.html?_r=0
[06:53:27] <vsync__> oh. yeah. that's exactly what i was thinking
[06:54:52] <vsync__> i'm thinking of replicating something like this, just wondering if anyone knows of a DIY that's already been done
[06:55:04] <vsync__> pretty much comes down to the reflector material i suppose
[06:55:05] <Jartza> http://rs2img.memecdn.com/impossibru_o_302535.jpg
[06:56:05] <bitd> rofl.
[06:56:07] <bitd> So true <.<
[06:56:29] <vsync__> Jartza well, it's because the display in itself is opaque
[06:56:46] <vsync__> you cannot simply light it from the bottom
[07:00:51] <bitd> Got a job interview for junior embedded software engineer next week. Anyone got any tips? <.<
[07:01:20] <vsync__> yeah
[07:01:56] <vsync__> a little remark for you to make for them, or a suggestion if you will... that they ought to drop the engineer from the title and replace it with something more appropriate
[07:02:18] <bitd> Oh good, thats not useful at all :P
[07:02:25] <bitd> <.<
[07:02:40] <vsync__> should net you great notoriety within the software... fiddlers
[07:03:16] <bitd> Oh fiddlers are we :P
[07:03:29] <Lambda_Aurigae> neionz, I don't have any arduinos...no need for them...but people use them for learning and prototyping and such.
[07:04:03] <bitd> Lambda_Aurigae, artist use them for "products" all the time. But those are artists..
[07:04:06] <Lambda_Aurigae> I've seen people try to use arduinos for small run production things like the reprap.
[07:05:07] <Lambda_Aurigae> I find the arduino "ide" and abstraction libraries to be rather,,,unusable.
[07:05:19] <vsync__> there's no necessity to use the ide really
[07:05:22] <Lambda_Aurigae> but, I also started with AVR using command line tools in linux.
[07:05:24] <bitd> The ide is just down right horrible.
[07:05:40] <vsync__> arguably you can do a breakout and add an ftdi if you will quite easy...
[07:05:43] <Lambda_Aurigae> vsync__, yeah, true.
[07:06:04] <vsync__> and fit it in a much smaller space
[07:06:09] <bitd> If you want it easy, you can just use ino.
[07:06:20] <bitd> vim + ino works just fine.
[07:06:22] <Lambda_Aurigae> if I want it easy I use vi.
[07:06:33] <vsync__> and also to drop in a smps
[07:06:35] <bitd> ino is to program the arduino :)
[07:07:03] <Lambda_Aurigae> if I want easy I don't bother with arduino myself.
[07:07:14] <bitd> So what do you use?
[07:07:32] <Lambda_Aurigae> I write my own code for the most part.
[07:07:47] <vsync__> also you could drop in a rectifier and transformer to run it straight off 110 or 220 ac, profit
[07:07:53] <Lambda_Aurigae> or procyon avrlib on occasion if I want some advanced libs.
[07:07:56] <bitd> Same here, still using the trusty stk500 to program the mcu.
[07:08:09] <Lambda_Aurigae> vsync__, why not loop a cable around the 7.2KV line outside?
[07:08:13] <bitd> and just avr-gcc works fine.
[07:08:40] <Lambda_Aurigae> bitd, for programmer hardware I use either my old trusty 74ls244 based parallel port programmer or the usb programmer I bought from Tom_itx
[07:08:40] <vsync__> there's an idea
[07:08:51] <vsync__> it's probably what's used for the control loop at the power plant itself
[07:08:55] <bitd> You normally write C or C++ Lambda_Aurigae?
[07:08:57] <vsync__> an arduino
[07:08:58] <Lambda_Aurigae> C
[07:09:02] <Lambda_Aurigae> I hate C++!
[07:09:15] <Lambda_Aurigae> and can't see any need for it on an 8bit AVR anyhow.
[07:09:27] <vsync__> i use node.js personally
[07:09:35] <vsync__> and python
[07:09:37] <Lambda_Aurigae> but, I learned C in the 80s
[07:09:58] <bitd> I wasnt born then <.<
[07:10:06] <vsync__> who'd have thought
[07:10:16] <bitd> I grew up with all these new flashy languages.
[07:10:20] <Lambda_Aurigae> before C++ became popular.
[07:10:22] <bitd> Like go :P
[07:10:37] <bitd> vsync__, play nice man haha.
[07:10:50] <twnqx> i still think that the overhead of C++ makes it a bad choice for 8bit micros
[07:10:57] <vsync__> i'm tryna, 's a hard life
[07:11:10] <twnqx> all the expensive indirect jumps through vtables
[07:11:26] <twnqx> unless all your objects are static
[07:11:44] <Lambda_Aurigae> twnqx, there isn't any real overhead problem with C++ on AVR the way the compiler handles it...it is possible to quickly overload an AVR with instantiated objects and all but that's just silly to use.
[07:11:48] <twnqx> all the expensive memory copying and init following a new() call
[07:12:19] <bitd> Its weird cause I keep hearing about people not using C++ in most mcu's, but all the "embedded software" books I read, promote the absolute crap out of C++.
[07:12:38] <LeoNerd> If you're writing C++ entirely without virtual, and doing everything static, then you're not /really/ writing C++ anyway.. you're just writing C but using a C++ compiler to build it
[07:12:53] <LeoNerd> bitd: My advice: stop reading books
[07:13:00] <twnqx> you still have the compile time access right checking
[07:13:05] <bitd> Well thats.. interesting :P
[07:13:07] <twnqx> and data encapsulation
[07:13:16] <twnqx> and the one thing i'd use c++ for... namespaces :P
[07:13:31] <Lambda_Aurigae> what is namespaces and why should I use it?
[07:13:34] <twnqx> not sure if those are in c11/c13
[07:14:08] <twnqx> you know what a namespace is - even if just gloval vs. function local
[07:14:18] <Lambda_Aurigae> I have no clue what it is.
[07:14:20] <Lambda_Aurigae> looking it up.
[07:14:42] <twnqx> c++ allows you to put your code into a namespace, so you can reuse e.g. variable names without collision
[07:14:51] <twnqx> instead of prefixing them
[07:15:15] <twnqx> so you might end up with uart::init, instead of prefixing all uart functions with uart_
[07:15:38] <Lambda_Aurigae> so just another way to prefix and bundle things.
[07:15:53] <twnqx> in principle yes, but a more convenient one IMHO
[07:16:08] <Lambda_Aurigae> I'll stick with C...
[07:16:13] <twnqx> sure, if you close your source files properly and put everything static in it you might not really need it
[07:16:17] <twnqx> me too :P
[07:16:43] <bitd> LeoNerd, you kind of caught me off guard, but could you please elaborate?
[07:16:44] <Lambda_Aurigae> only been programming in C since 1987
[07:17:07] <Lambda_Aurigae> bitd, knowledge is dangerous...and books are subversive and teach you things you shouldn't know.
[07:17:13] <LeoNerd> bitd: To a large extent, published ink-on-paper books are going to be very out of date, opinionated, commercialised, and outright wrong in places.
[07:17:28] <Lambda_Aurigae> everything you ever needed to know you can learn from google and wikipedia.
[07:17:35] <LeoNerd> I own a total of, hmmm.. I think three paper books about computer programming in total. And two of those are the C89 and C99 specs.
[07:17:51] <Lambda_Aurigae> I own 2 books on programming..
[07:17:57] <Lambda_Aurigae> both the same title
[07:17:59] <twnqx> i own more \o/
[07:18:05] <twnqx> one is algorithms and data structures
[07:18:15] <Lambda_Aurigae> just different editions....
[07:18:15] <twnqx> pascal version, 'cause that's what i used back then
[07:18:17] <LeoNerd> Computer programming moves /far/ too fast for ink-on-paper books to keep up with.
[07:18:32] <Lambda_Aurigae> "The C Programming Language" by Kernighan and Ritchie.
[07:18:42] <bitd> I have that one as well.
[07:18:45] <LeoNerd> Mhmm.. I have K&R, and the ISO:IEC 9899:1999 hardcopy
[07:18:56] <bitd> Along with great titles such as RUP.
[07:19:05] <Lambda_Aurigae> my first edition K&R C book is signed.
[07:19:07] <Lambda_Aurigae> by both.
[07:19:15] <twnqx> and then i have "design patterns"
[07:19:23] <twnqx> which is actually meant for oop
[07:19:28] <twnqx> but useful on its own, imho
[07:19:30] <bitd> And all kinds of agile books, which now that I have graduated, I am going to throw in the trash.
[07:19:35] <LeoNerd> Ohwait I have four books. I also own the "GNOME programmers' guide"... a book mostly about GTK+ 1.2, that I bought -just- before GTK2 was officially released.
[07:19:36] <LeoNerd> Oops :)
[07:19:50] <twnqx> and i have "learning perl"
[07:19:51] <twnqx> :D
[07:19:57] <twnqx> and one book on verilog
[07:20:12] <Lambda_Aurigae> ok...must go to work and break copiers now.
[07:20:14] <Lambda_Aurigae> laters all.
[07:20:18] <twnqx> and lower level stuff
[07:20:30] <neionz> do 8-bit avr MCUs typically fit into a bread board?
[07:20:41] <LeoNerd> At one point I considered writing a book, but I'm not sure now... the things I'd write about are all fluid and change over time anyway; half of the book would be out of date before I finished writing it
[07:20:42] <twnqx> the DIP ones directly
[07:20:47] <LeoNerd> And the other half probably not long afterwards
[07:20:51] <twnqx> other are often available on breakout boards
[07:21:12] <LeoNerd> neionz: The only AVR I know of that doesn't, is the tiny841, because it doesn't (yet?) come in a PDIP form. But there's solutions to that
[07:21:45] <LeoNerd> BotThoughts sells a tiny841 breakout board, and I sell a generic SOIC14-to-PDIP14 socket adapter
[07:22:17] <bitd> good luck with that Lambda_Aurigae
[07:22:24] <LeoNerd> I wonder if Atmel will ever fix that, or if we're doomed forever to only have it in SOIC
[07:23:10] <twnqx> who cares
[07:23:13] <twnqx> soic is nice
[07:23:16] <twnqx> DIP is so huge...
[07:23:41] * twnqx recently stared at a chip and thought"damn, that huge pin spacing.. must be 2.54mm"
[07:23:43] <LeoNerd> Well... sometimes it's nice not to have to mount Every Single Chip Evarrr onto a (custom) breakout board before you can breadboard it
[07:23:46] <twnqx> turns out it only was 1.27
[07:23:59] <twnqx> i don't breadboard :X
[07:24:00] <LeoNerd> Though admittedly the breakouts can be convenient as they tend to label the pins, unlike a bare chip :)
[07:24:12] <LeoNerd> It's nice to have PA0, PA1, ... neatly labeled
[07:24:16] <twnqx> or at maximum with number wires between modules for testing
[07:24:22] <twnqx> jumper wires*
[07:24:23] <twnqx> lol
[07:25:18] <LeoNerd> Hrm.. now I wonder who will be the first boardhouse to offer multicoloured silkscreen printing
[07:25:27] <LeoNerd> I'd love to label GND in black and VCC/etc.. in red
[07:25:37] <twnqx> expensive
[07:25:44] <twnqx> that's one silkscreen layer per color
[07:25:54] <twnqx> i bet hackvana could do it
[07:25:57] <LeoNerd> Eh.. as I understand it these days "silkscreen" printing is just done by inkjet
[07:26:03] <twnqx> really?
[07:26:15] <LeoNerd> It's the final stage of the process anyway, so the house could easily just do multiple runs at not much extra cost/time
[07:26:40] <twnqx> depends, if it's really just printing like that, no biggie i guess
[07:26:46] <twnqx> if it's phototransfer
[07:26:49] <twnqx> it will be bad
[07:27:04] <LeoNerd> I doubt someone like OSHpark use phototransfer for the tiny runs of 3 boards...
[07:27:11] <twnqx> they panelize
[07:27:20] <twnqx> i thoguht
[07:27:24] <twnqx> but hey, ask hackvana
[07:27:24] <LeoNerd> Sure
[07:27:34] <twnqx> he would definitely know :)
[07:27:37] <LeoNerd> But regardless of size; phototransfer for just three boards ever seems excessively wasteful
[07:28:06] <twnqx> well
[07:28:16] <twnqx> i would not be sure about that
[07:28:39] <twnqx> it's just a matter of laserprinting with the "right" laserprinter and toner
[07:29:11] <twnqx> put it would surely be an interesting approach to just print everything
[07:29:23] * twnqx files a ptent
[07:29:25] <twnqx> patent*
[07:34:57] * bitd facepalms
[07:35:14] <bitd> forgot to pull-up the reset on my pcb.
[07:35:34] <Tom_itx> i bet it let you know too
[07:35:41] <LeoNerd> What chip? The AVRs have internal pullup on RST
[07:35:43] <bitd> Haha yes.
[07:35:53] <bitd> ATTiny84.
[07:36:03] <bitd> Ignition coil triggers the reset now.
[07:36:08] <LeoNerd> In fact if you -do- add an external pullup it gets in the way of HVSP
[07:36:10] <bitd> Under normal conditions its fine.
[07:38:39] <twnqx> noone does hvsp unless you accidently broke the reset fuse
[07:39:30] <bitd> Weird, all the example schematics I look at have a pull-up to reset.
[07:39:55] <Tom_itx> well, it should have one
[07:40:33] <twnqx> bitd: but i'd think your problem is not the reset pin
[07:40:38] <twnqx> you'll need more bypass caps.
[07:41:06] <Tom_itx> you may need a large filter cap on your avr supply voltage too
[07:41:26] <bitd> Already have those Tom_itx
[07:41:31] <Tom_itx> how big?
[07:41:33] <bitd> I read grumpy mikes tutorial :P
[07:41:49] <Tom_itx> 1000 uf could be in order
[07:41:55] <bitd> One 47uF, one 100nF
[07:42:00] <bitd> Good lord, that big? <.<
[07:42:04] <twnqx> 100nF per vcc + avcc pin
[07:42:11] <bitd> Yep, have that :)
[07:42:24] <Tom_itx> i had to put one that size on a sonar to keep it from resetting when it ping'd
[07:42:33] <twnqx> with your high voltage stuff i'd go with small ferrites before the avr as well
[07:42:35] <bitd> Rofl.
[07:42:36] <bitd> I see.
[07:42:52] <bitd> Have those as well, haha :P
[07:43:13] <bitd> This is design #3.
[07:43:31] <twnqx> and then probably i'd add 1µF+10µF to check for harmonics, + 470µF-100µF behind the voltage regulator
[07:43:49] <twnqx> 470-1000*
[07:44:35] <bitd> Cleaning up the power supply really isnt that much of an exact science, is it :P
[07:44:38] <twnqx> just a simple electrolytic bulk capacitor
[07:44:48] <twnqx> no
[07:45:01] <twnqx> mostly because consumption is not static
[07:45:33] <twnqx> you have all kinds of consumption spikes in all kinds of frequency (cpu core, adc, IO, ...)
[07:45:37] <twnqx> + external noise
[07:45:51] <twnqx> + if you use a switching regulator, its own frequency
[07:45:56] <bitd> External noise being my major foe at this point.
[07:46:11] <bitd> I use a linear one.
[07:46:18] <twnqx> where you possibly have to filter it's input so it doesn't resonate and drop
[07:46:41] <twnqx> heh, in ye olde 7805 days you'd just put 470µF on both sides of it :P
[07:47:11] <twnqx> most of my circuits have excessive places for caps
[07:47:30] <twnqx> i never had stability issues, rarely even needed to put the huge bulk caps
[07:47:58] <twnqx> but i like to massively oversize my power supplies :d
[07:48:02] <bitd> Try powering a 16mH 3ohm ignition coil with 3 amps :P
[07:48:20] <twnqx> mh
[07:48:59] <twnqx> i have the parts here for a 12V, 40A supply i want to build for some time
[07:49:35] <bitd> 40A continuous? O_O
[07:49:38] <twnqx> yes
[07:49:58] <bitd> What are you trying to power, a small car? <.<
[07:50:00] <twnqx> 10x 470µF output caps
[07:50:27] <twnqx> 195A n-channel mosfets
[07:51:04] <bitd> Any usage plans?
[07:51:22] <twnqx> just experiments with higher output current
[07:52:01] <twnqx> i have a few 55V/12A PSUs here
[07:52:11] <twnqx> from telco stuff
[07:54:17] <bitd> I would like to build a homemade electric motorcycle someday. Dont have anywhere near the required skills yet.
[08:11:05] <STS_Patrik> I want to build an active rear spoiler for my car
[08:12:24] <bitd> Yeah mean active in regard to position?
[08:12:33] <STS_Patrik> yup
[08:12:48] <bitd> You would do that based on speed or airflow?
[08:13:27] <STS_Patrik> speed i guess
[08:14:37] <STS_Patrik> with pedal & steering angle sensors
[08:15:51] <bitd> Hmmm, some cars already have those sensors built in.
[08:16:10] <bitd> Not sure if thats something you could access via OBDII.
[08:17:54] <STS_Patrik> im actually already working with development of a standalone sensor network for cars
[08:30:11] <STS_Patrik> not sure which type of pistons to use though
[08:30:23] <STS_Patrik> they need to be somewhat fast and still strong
[09:01:47] <LeoNerd> Hm. I think I've -finally- found a use for the tiny2313s I happen to have lying around
[09:02:31] <LeoNerd> I want to use it to decode an LED matrix scanner on my dishwasher
[09:03:20] <LeoNerd> Needs tonnes of IO pins for all the rows/columns, but hardly any program code or memory state
[09:13:11] <LeoNerd> Basically just a slightly more advanced thing than an SPI readable shift register; one that is aware of rows and columns and maintains state of each matrix cell
[09:18:50] <bitd> I thought you where planning to use a SPI shift register for that?
[09:19:47] <bitd> s/shift register/spi device
[09:20:39] <LeoNerd> Hrm?
[09:20:54] <LeoNerd> What part of my statement contradicts that?
[09:21:06] <LeoNerd> "ATtiny2313 acting as an SPI slave" == SPI device, surely?
[09:21:18] <bitd> Oh right, misread, yeah got it now :P
[09:21:31] <LeoNerd> Hrm. though if I use I2C instead I get two more pins...
[09:21:55] <LeoNerd> power, gnd, reset, sda, scl... leaving 15 spare for matrix scanner and button pressing
[09:22:21] <bitd> Can you re-use pins like mosi/miso?
[09:22:31] <bitd> Never read into that.
[09:22:59] <LeoNerd> You can use any pin as a GPIO pin if the other peripheral(s) behind it aren't using it
[09:24:50] <LeoNerd> Most of the peripherals will not yet be enabled on POR, so usually you get all of them. Give or take such things as XTAL1/XTAL2 if the fuse bits are set to enable the crystal osciliator, or RESET if you don't have RSTEN
[09:25:28] <LeoNerd> .oO( That said I -still- want an AVR chip with arbitrary pin assignments, like prettymuch all the PICs and tiny ARMs do these days )
[09:26:33] <bitd> Yeah sometimes the pinout just doesnt fit the requirements.
[09:27:03] <LeoNerd> The tiny841 has a 'remap' register where you can move a couple of the peripheral ports onto an alternate location, but that's nowhere near as flexible
[09:27:34] <LeoNerd> On a PIC18, all the pins of the device are just numbered, and there's a bunch of configuration registers where you can literally map /any/ peripheral port onto any of those pins
[09:28:06] <LeoNerd> You can even do fancy things like mapping two different peripheral inputs to use the same hardware pin, or two different hardware pins to come from the same peripheral output
[09:28:48] <LeoNerd> Or route the output of one peripheral directly into the input of another.. e.g. maybe you want to use a fast timer output pin as the clock pin of SPI? No problem.. just wire it up
[09:28:53] <LeoNerd> internally. in "software"
[09:29:24] <bitd> Hah, that actually sounds really useful indeed.
[09:29:31] <LeoNerd> It's massively helpful
[09:29:53] <bitd> Even correct pcb booboo's in software <.<
[09:30:17] <LeoNerd> It means you don't have to do such stupid board layouts, also. Place your other chips and connectors around the PIC, wire up traces wherever is most convenient, then afterwards work out what peripherals need to map to which pins
[09:30:38] <LeoNerd> On my tiny841 board, there's a couple of awkward traces where I have to reach around some pins to get at the one I need.. on a PIC18 that wouldn't happen
[09:30:41] <bitd> Yeah, that would make life a lot easier.
[09:30:57] <bitd> Always looks a bit silly as well.
[11:02:12] <MarkX> hi
[11:18:04] <megal0maniac> Lo lo!
[11:19:00] <megal0maniac> Quick question. I have a 10W 12V LED. I want to drive it with an AVR using PWM. It will be at 100% duty cycle most of the time - any suggestions for a run-of-the mill, cheap and easy to get transistor or component to do this?
[11:19:12] <megal0maniac> I feel the PN2222 might not cut it this time ;)
[11:19:38] <LeoNerd> I'd use some sort of FET
[11:19:57] <megal0maniac> That's what I thought
[11:20:10] <megal0maniac> BUT I don't know enough about fets to know anything more than that
[11:20:33] <LeoNerd> FETs are entirely voltage-controlled... the channel conductivity is all about the voltage on the gate, relative to the source/drain channel
[11:20:53] <LeoNerd> The trick you'll have is whether the AVR at (5V?) will be good enough to control it
[11:22:23] <LeoNerd> If that doesn't work, then you'll want to control the gate voltage via a second transistor, an NPN controlled by the AVR to pull the gate voltage down; when that second is off, let the gate have a weak pullup to +12V
[11:23:53] <megal0maniac> Eugh. Can I not just use a bigger BJT?
[11:24:05] <megal0maniac> I'm aiming for low component count
[11:24:23] <LeoNerd> You could, though those tend to have a much larger voltage drop across them
[11:24:57] <LeoNerd> 12V at 10W suggests about an amp of current
[11:25:12] <megal0maniac> Correct
[11:40:52] <bitd> LeoNerd, The reset line has an internal pull-up resistor, but if the environment is noisy it can be insufficient and reset can
[11:40:52] <bitd> therefore occur sporadically. Refer to datasheet for value of pull-up resistor on specific devices.
[11:40:52] <bitd> Connecting the RESET so that it is possible to enter both high-voltage programming and ordinary low level reset
[11:40:52] <bitd> can be achieved by applying a pull-up resistor to the RESET line.
[11:41:40] <LeoNerd> I find a 10k pullup from RESET to VCC on an attiny841 breaks HVSP
[11:41:50] <bitd> They recommend 4.7k
[11:42:13] <LeoNerd> Then I imagine 4.7k would be even worse
[11:43:08] <bitd> Indeed, weird stuff.
[12:03:36] <vsync__> err...
[12:20:56] <tats> hi, i have a quick question. when using the internal voltage reference on an atmega (i'm using atmega1280) is there any precaution to take to avoid short-circuiting? i don't fully understand how it works.
[12:21:50] <LeoNerd> What situation do you imagine would shortcircuit it?
[12:22:52] <tats> from what i read if there's an external voltage connected to the aref you can short-circuit it. in my case the aref is connected to the vcc.
[12:32:12] <hypermagic> hello my friends
[12:40:19] <Jartza> 'allo
[12:40:24] <tats> ok i found my answer here:
http://www.avrfreaks.net/forum/atmega16-aref-pin-connection
[12:40:44] <tats> seems the best way is to connect aref to gnd with a 10nF-100nF cap between them
[12:45:48] <hypermagic> what's up?
[12:46:20] <hypermagic> yes i think you destroy it if you short circuit it
[12:46:39] <hypermagic> reference is fragile
[12:46:53] <tats> thanks hypermagic
[12:48:04] <hypermagic> well if you do not connect to anything external, then you will probably not s/c it
[12:48:08] <Jartza> hmmh
[12:48:31] <hypermagic> also you can connect to vcc and let it be vcc
[12:48:32] <Jartza> maybe I could get attiny85 to talk to 8192 baud uart using 4,194304MHz osc
[12:48:40] <Jartza> and some timer interrupts
[12:50:01] <Jartza> and blurt out some messages from i2c
[12:51:02] <hypermagic> oh yea tats i connected a 100nf-1uf ceramic decoupling cap to ref - agnd too to filter some noise
[12:51:13] <hypermagic> but it will work without
[12:51:50] <hypermagic> i saw reference design with RC lowpass filter on aref, or LC lowpass filter
[13:10:52] <tats> also I was wondering: if i'm using an internal reference (say of 1.1V) and I have some voltage higher than 1.1v connected to an analog pin do i risk breaking something?
[13:32:02] <hypermagic> it should be ok upto vcc, but why not connect a resistor in series ? 1k-10k will hurt?
[13:58:34] <LeoNerd> So... the tiny13 's internal RC osc. runs at 9.6MHz, unique among all the ATtiny chips, most of the others do 8MHz. Anyone know why?
[13:59:09] <LeoNerd> The 13 lacks UART, USI, SPI, I2C,... any sort of serial bus that would otherwise suggest a useful division
[13:59:21] <LeoNerd> It has a single timer, ADC on all the pins,.. and that's it
[14:03:10] <twnqx> dunno
[14:03:21] <twnqx> i think the 13s make great ne555 replacements
[14:03:57] <LeoNerd> Hmm... though, a loop of 83 1/3 instructions per bit does make a nice soft-UART
[14:04:05] <LeoNerd> at 115200baud
[14:21:09] <LeoNerd> Hrm.. it seems the 13 uses 9.6MHz because it wants to an upgrade/replacement of the 12, which is 1.2MHz
[14:21:16] <LeoNerd> Which doesn't reeeeally explain it
[14:36:26] <LeoNerd> Hrm.. I have no spare breadboards.. I wonder if I can squash something up. Wanna play with a tiny13 + WS2812 LED
[15:05:25] <Jartza> LeoNerd: you can run attiny85 in t13 compatibility mode :)
[15:05:32] <Jartza> it also runs at 9.6MHz then
[15:05:47] <LeoNerd> .. hah.. really? Whatwhat?
[15:05:51] <LeoNerd> How does that work?
[15:06:35] <Jartza> sorry, attiny15 compatibility
[15:06:59] <Jartza> so it must be 6.4MHz then
[15:07:35] <Jartza> remembered wrong
[15:10:36] <Jartza> ohh... nope. the system clock runs at 6.4MHz, but with 4x divider :D
[15:10:41] <Jartza> so 1.6MHz. d'oh
[16:29:55] <LeoNerd> Well, that was exciting. Playing with my new I2C pressure+temperature sensor. How do I know it's working? Simple.. I put sensor + Bus Pirate in the freezer and watch the temp go down :)
[16:30:36] <Thrashbarg> or touch your soldering iron on it :P
[16:30:44] <LeoNerd> I'd rather not :)
[16:31:12] <Thrashbarg> we did that with transistors at TAFE to show the current vs temperature relationship
[16:31:51] <LeoNerd> Heh... this is a bit fancier than that ;) A 16-bit I2C register holds the temperature in units of 1/16th of a degree C
[16:32:02] <Thrashbarg> cool
[16:45:54] <malinus> Thrashbarg: lol'd
[16:46:11] <malinus> LeoNerd: is it really that precise though?
[16:46:48] <malinus> I mean, is it as precise as that resolution? Or is the precision only like 0.5C?
[16:47:00] <LeoNerd> Mm.. dunno
[16:47:10] <malinus> 1/16 would be really impressive, no?
[16:47:40] <Thrashbarg> 0.0625% resolution with 5% accuracy
[16:47:54] <malinus> :D
