Back
[01:00:16] <tomatto_> hello, please do you have rc5/sony C code receiver for atmega?
[01:02:28] <rue_house> I have code for 1 channel somehwere
[01:02:47] <rue_house> you meen std pwm servo signals right?
[01:03:21] <rue_house> I was going to make something that would recieve the whole unprocessed channel set, didn't get around to it
[01:19:56] <Kevin`> I took that to mean rc5 and sony infared protocol decoding
[01:20:27] <Kevin`> i've seen all of those, but what I needed was rc6, so I didn't look at them much ;p
[03:15:46] <vectory> a resistor doesnt need to be in circuit to measure ohms, right?
[03:18:50] <vectory> bought a dmm yesterday, wonder if i broke it already >_<
[03:55:16] <Tom_itx> you're better off measuring them out of circuit
[05:39:12] <amee2k> Tom_itx: Fen has offered to help but is apparently swamped in work in preparation for some presentation. since i still have some other details i can work out in the meantime, thats no problem for me. he said i should bug him next week or so again
[05:40:37] <amee2k> also, any good ideas for protecting TWI signal lines that have an off-board connector?
[05:41:02] <amee2k> clamping diodes to the rails comes to mind
[05:43:27] <Steffann> Transient Voltage Suppressor Diodes amee2k ?
[05:45:43] <amee2k> Steffann: do these have an advantage over fast clamping diodes?
[05:49:39] <Steffanx> I actually don't know amee2k .. i never used them
[05:49:53] <Steffanx> but they seems to be made for it
[05:50:44] <amee2k> they also make quad clamping diodes (like a tiny brige rectifier) in tiny 6-pin SOT cases specifically for protecting signal lines
[05:51:10] <amee2k> i'd just have used four shottky diodes to the rails, and maybe a small (10-47R) series resistor to the pin
[05:56:52] <Steffanx> Maybe I/someone should dig into it a once.. when to use what. PTC Fuse, TVS diodes, shottky?
[05:57:26] <Steffanx> Or maybe someone here knows :)
[05:58:22] <amee2k> i'd select shottkys for this since leakage is not very important with TWI, but the clamping action is very fast
[05:59:07] <amee2k> Steffanx: but yeah, a general overview somewhere wouldn't hurt. i've been wondering about collecting all the common "rules of various thumbs" on a web page
[05:59:30] <Steffanx> Indeed
[05:59:37] <Steffanx> That would be nice
[06:00:07] <amee2k> the two most common problem i usually have when learning something new are firstly general design decision how to go about a problem, and secondly implementation details like which parameters are important for which components
[06:00:32] <amee2k> and the internet has a way of not being very helpful with either usually
[06:01:03] <Steffanx> So how you learn these things? Trial and error?
[06:01:52] <amee2k> the steps between settling on a general layout or circuit topology, until the moment where you need to hit farnell or digikey and start compiling a parts list, are usually covered very well by random theory websites or books or wikipedia
[06:02:19] <amee2k> Steffanx: until now, pretty much. but that only works for stuff that you can build on a breadboard from generic components
[06:03:00] <amee2k> noone wants to buy a 5$ IC and etch or order boards only to find out it won't work for the project at hand
[06:03:23] <Steffanx> I do :P
[06:03:39] <amee2k> especially with smt stuff where "just swapping in a different inductor or something" is not quite as trivial as with leaded ones
[06:03:58] <amee2k> Steffanx: can i borrow your money shitting donkey sometime?
[06:04:14] <Steffanx> Ok, I don't want too, but I sometimes bought things which didn't work out very well
[06:04:47] <amee2k> but you had reason to believe they would work when you decided to get them, no?
[06:04:53] <Steffanx> Yes, ofcourse
[06:05:44] <amee2k> that is slightly different than not even beign sure that the general design is a workable solution
[06:07:04] <amee2k> the driver i selected for these LED boards i'm working on probably isn't the best choice, but this one has good documentation available so i'll keep it for the prototype
[06:08:08] <amee2k> i'll probably start looking for a different one on the second revision. more output current and a better PWM control scheme with higher resolution
[06:08:26] <Steffanx> What kind of LED Board do you make?
[06:09:39] <amee2k> a few weeks ago a friend of mine got some (pseudo) industrial LED lighting modules... a board with some power LEDs and a driver and some serial interface. they worked and we got them to run, but had some awkward issues
[06:10:27] <amee2k> so i decided to try my own take on the concept. a small board with 4 power LEDs, PWM dimmable driver and an MCU to interface with a serial bus
[06:12:04] <amee2k> so a light fixture would be easy to design from premade blocks... 24V SMP module, one or more LED modules, and optionally some control board to expose control features to the user like dimming and selectively turning on individual modules
[06:13:22] <Steffanx> Sounds nice
[06:13:56] <amee2k> :)
[06:14:23] <amee2k> the first target for replacement is the 36W fluo tube over my desk
[06:15:26] <amee2k> i'm pretty much at the end of the conceptual work now, with an almost complete preliminary schematic on paper
[06:15:45] <Steffanx> How can you even work under a 'fluo tube'. I tried at for a while
[06:15:54] <Steffanx> It gave me a headache
[06:16:16] <amee2k> this project will have a bunch of "firsts" for me too... first almost entirely SMT board, first ordered boards, first time with high current LEDs
[06:16:36] <amee2k> Steffanx: no idea, somehow i don't seem to have a problem with fluo light
[06:16:57] <Steffanx> The good old light bulbs are the best :)
[06:17:03] <amee2k> lol
[06:17:29] <Steffanx> Unfortunately they are 'forbidden' or at least they probably will be. EU stuff :(
[06:17:38] <amee2k> not entirely, no. the fluo tube is okay, but i'd die under a 100W incan lamp in summer
[06:18:06] <amee2k> no more incans is only sad because it means no more cheap PTCs :(
[06:36:00] <OndraSter_> bram1, so you are saying, that 2 layered PCB def not? :(
[06:36:13] <OndraSter_> I used your advice and rotated the IC19 and 20 by 90°
[06:36:25] <Steffanx> Go four layer OndraSter_ :P
[06:36:37] <OndraSter_> http://clip2net.com/s/1rpNB
[06:36:38] <Steffanx> iteadstudio now has a 4 layer service
[06:36:55] <OndraSter_> well pragoboard has 4 layer, 6layer even 8 layer
[06:37:02] <OndraSter_> but prices are like... up the sky
[06:37:09] <Steffanx> Oh, you want to use a local service
[06:38:46] <OndraSter_> yeah
[06:38:54] * RikusW use a 40W incandecent
[06:39:22] <RikusW> aimed at the ceiling, gives a nice soft light
[06:39:28] <Steffanx> 40W ...
[06:39:32] <Steffanx> That's not very much
[06:39:57] <RikusW> just enough when working at the pc
[06:39:57] <OndraSter_> http://iteadstudio.com/store/index.php?main_page=product_info&cPath=19_20&products_id=519&zenid=prilhqvc0noej587sboedhlvb4
[06:39:59] <OndraSter_> what is this? :)
[06:40:02] <Steffanx> I have a fancy 9W energy saving lamp here
[06:40:04] <Steffanx> Yay
[06:40:07] <OndraSter_> 5 diff boards?
[06:40:20] <RikusW> had a 15W cfl, but it blew
[06:40:35] <Steffanx> 5 times the same board OndraSter_
[06:40:39] <OndraSter_> oh
[06:41:02] <OndraSter_> hmm 25x25cm boards are +95 bucks
[06:42:11] <RikusW> vectory: it appears that atmegau2_cdc_x64.inf works on win7 x64, just tested it
[06:42:22] <RikusW> just added a few lines to it
[06:42:43] <RikusW> actually only 2
[06:42:45] <Steffanx> You have win7 x64? :D
[06:42:48] <vectory> wait, thats a different one than on your site?
[06:42:55] <RikusW> [ATMEL.NTamd64]
[06:42:56] <RikusW> %ATMEL_CDC%=Reader, USB\VID_03EB&PID_2018
[06:43:04] <vectory> Steffanx: on his mothers lappy
[06:43:05] <RikusW> I mailed it to you about a month ago
[06:43:07] <vectory> iirc
[06:43:17] <RikusW> on my brothers x64 pc
[06:43:20] <RikusW> just today
[06:43:28] <vectory> well, that didnt work :(
[06:43:51] <vectory> maybe because win7 wastn activated for me?
[06:43:54] <RikusW> this renamed one ? atmegau2_cdc_x64.inf
[06:44:08] <RikusW> why not activated ?
[06:44:15] <RikusW> not legal ? ;)
[06:44:49] <spow> Hi, i'm sorry to ask such a stupid question, but what could be the reason for a main loop not looping ?
[06:44:51] <RikusW> worked first try, win7 home premium x64
[06:45:00] <vectory> RikusW: lost the key xD
[06:45:10] <RikusW> ugh
[06:45:16] <Steffanx> spow you can share the code?
[06:45:36] <RikusW> vectory: I mailed you the file on 20/11/11
[06:45:44] <vectory> RikusW: is this up to date?
http://paste.debian.net/150461/
[06:46:50] <spow> Steffanx:
http://pastebin.com/eF8hycbb
[06:47:55] <spow> all I see that could fail is the A/D conv. but it returns the good value if I reset the µC
[06:47:58] <RikusW> vectory: no
[06:48:00] <RikusW> needs the amd64 part
[06:48:11] <vectory> well, thats my arch ^^
[06:48:17] <vectory> so thats the problem
[06:48:47] <Tom_itx> spow, is the wdt disabled?
[06:49:35] <RikusW> http://pastebin.com/YrSLCxD2
[06:50:03] <spow> Tom_itx: I don't use timers in this example, if so is the question (used to, but removed them to simplify the code until it works)
[06:50:13] <RikusW> vectory: that should work
[06:50:19] <Tom_itx> wdt runs by itself
[06:50:43] <spow> lemme check the datasheet then
[06:50:47] <Tom_itx> it's a watch dog and a mean one if let to run loose
[06:51:02] <Tom_itx> check the fuse bits
[06:51:28] <vectory> oy, thx RikusW
[06:51:37] <RikusW> it works ?
[06:51:41] <vectory> should
[06:51:44] <vectory> cant test atm
[06:52:06] <RikusW> just worked over here, so it should
[06:52:08] <amee2k> are the one/zero thresholds on TWI bus lines standardized?
[06:52:26] <Steffanx> Unless you tell the dog to stay in it's dog kennel, Tom_itx ..
[06:52:28] <vectory> will do later™
[06:52:59] <Tom_itx> well dawggon it
[06:53:28] <vectory> cant have BOD without watchdog :/
[06:53:41] <RikusW> why not ?
[06:54:31] <amee2k> i'm scratching my head over active pullup circuits. i've got one that can pull the bus lines almost all the way to the rail, but is fairly complicated
[06:54:37] <Tom_itx> default: Watch-dog Timer always on; [WDTON=0]
[06:54:47] <vectory> RikusW: thought wd times the brown out
[06:55:15] <amee2k> if i could assume the threshold is always, say <3.5V, that would give me more flexibility because i can tolerate higher compliance voltages
[06:55:41] <vectory> use a voltage regulater?
[06:55:51] <spow> Tom_itx: so I should write 1 to both WDTOE and WDE and then immediately (next instruction) write 0 to WDE ?
[06:56:08] <RikusW> vectory: BOD is seperate from WDT
[06:56:09] <Tom_itx> or set the fues
[06:56:11] <Tom_itx> fuse
[06:56:23] <Tom_itx> your way is a software disable
[06:56:33] <Tom_itx> i think
[06:57:06] <amee2k> http://ompldr.org/vYnlxbg/active-pullup.png
[06:57:08] <spow> i'll try that first
[06:57:10] <Tom_itx> i'd have to look and see how i did it
[06:57:39] <Steffanx> amee2k ?
[06:58:04] <amee2k> that is my concepts for active TWI pull-ups
[06:58:46] <Tom_itx> i use transient supressors on usb
[06:58:55] <Tom_itx> they might work on twi
[06:59:05] <amee2k> right one goes almost all the way to the rail, but has very high standby current and needs matched transistors. center one has higher compliance voltage but very low standby current and uses generic transistors
[06:59:30] <amee2k> hence my question as to whether the logic thresholds are well defined
[07:00:52] <Steffanx> Nice negative voltage of .7V :)
[07:00:56] <Tom_itx> spow, it may be disabled by default, check the data sheet again
[07:01:08] <spow> Tom_itx: yes, that was the watchdog timer screwing up :)
[07:01:09] <Tom_itx> in my case a bootloader enabled it
[07:01:17] <Tom_itx> ok
[07:01:25] <Tom_itx> what chip?
[07:01:37] <spow> any idea why my previous programs didn't fail ?
[07:01:40] <spow> atmega32
[07:01:51] <amee2k> Tom_itx: yeah, i think the ones in SOT 6-pin package that i saw were intended for USB. from what i remember it was just four low capacitance clamping diodes so it should work fine for almost any kind of bus
[07:02:05] <Tom_itx> i think normallyh it is disabled by default but apparently something turned it on
[07:02:34] <spow> well, that was another nice session of pulling my hairs out, thanks a lot :)
[07:02:45] <amee2k> Steffanx: looks like some artifact caused by the pull-down FET
[07:03:00] <Tom_L> #include <avr/wdt.h>
[07:03:03] <Tom_L> /* Disable watchdog if enabled by bootloader/fuses */
[07:03:03] <Tom_L> MCUSR &= ~(1 << WDRF);
[07:03:03] <Tom_L> wdt_disable();
[07:03:16] <amee2k> Steffanx: it goes away when i increase the rise and fall times
[07:03:24] <spow> WDTCR |= (1<<WDTOE) | (1<<WDE); WDTCR |= (0<<WDE); works too
[07:03:25] <Steffanx> Ah
[07:03:33] <Tom_itx> or use the fuses to disable it
[07:04:09] <amee2k> the current mirror pull-up also looks too ideal to be true because it seems to maintain a constant output current even below the saturation voltage
[07:04:11] <spow> i'll first need to read about fuses
[07:04:27] <RikusW> afaik if WDT is turned on with the fuses fw can't turn it off
[07:04:43] <amee2k> i tried the middle one on a breadboard and it worked. compliance voltage was ~1.5V irl
[07:06:19] <Tom_L> amee2k:
http://search.digikey.com/us/en/products/PESD0603-240/PESD0603-240CT-ND/1813513
[07:06:49] <Tom_itx> that's what i use
[07:07:11] <RikusW> and m32 doesn't seem to have any WDT fuses
[07:07:21] <Tom_itx> it should
[07:07:30] <Tom_itx> i think they all do
[07:08:34] <Tom_itx> odd
[07:08:51] <Steffanx> even
[07:09:06] * Tom_itx flips Steffanx again
[07:09:08] <Tom_itx> odd
[07:09:25] <RikusW> WDTON=$10,Watchdog timer always on
[07:09:28] <RikusW> on m32u2
[07:09:38] <amee2k> Tom_itx: they have fairly high trigger voltages. the built in protection structures of the TWI interface should trigger way before that
[07:10:00] <RikusW> for preventing fw turning off WDT
[07:20:06] <spow> can disabling the WDT screw with other timers ?
[07:20:14] <Tom_itx> no
[07:20:28] <Tom_itx> it's a separate timer
[07:39:05] <Sh4rK> Tom_itx: what is the largest integer supported on a megaAVR with gcc(AVR Studio 5)?
[07:39:18] <Sh4rK> 16, 32 or 64 bit?
[07:41:39] <amee2k> natively i think 16, but you (or the compiler) can fake longer with multiple instructions
[07:42:26] <amee2k> i'm not sure if all instructions have 16 bit variants. avr counts as 8 bit anyway
[07:43:38] <Sh4rK> I think natively 8bit only
[07:43:43] <amee2k> all depends on your performance requirements. avr can do floating point stuff too but the resulting code is huge (relative to integer or fixed point computations)
[07:43:46] <inflex> Sh4rK: with gcc you can 64 fine... but it's all in 8-bit blocks
[07:44:02] <Sh4rK> inflex: for sure?
[07:44:10] * inflex does 64-bit on some of his things, it does beef out the code a bit
[07:44:20] <Sh4rK> ok
[07:44:35] <amee2k> Sh4rK: try if it has a "uint64_t" in stdint.h. if so, it can handle it
[07:44:36] <Sh4rK> I want to use it for counting time
[07:44:49] <inflex> yep, it has uint64_t
[07:45:12] <Sh4rK> yep
[07:45:14] <Sh4rK> cool
[07:45:18] <Sh4rK> thanks
[07:45:30] <inflex> just make sureyou use ULL or UL suffix on constants
[07:45:42] <inflex> eg, foo_64 = blah *231211UL;
[07:45:55] <amee2k> i tend to always use the intX_t and uintX_t aliases... choosing data type by size is more intuitive than by naming convention of the compiler designer
[07:46:01] <inflex> else you WILL have nightmares
[07:46:48] <amee2k> except for the obligatory "int i;" i suppose, but that is tradition i suppose >_>
[07:47:00] <Sh4rK> inflex: what will it do?
[07:47:19] <Sh4rK> it should now if I assign to an uint64 that the constant IS an uint64
[07:47:21] <inflex> Sh4rK: depends on the gcc version... but invariably it'll incorrectly do the math
[07:47:34] <amee2k> i've been wondering why avr c doesn't have a 24 bit type... for lots of stuff 16 bit is somewhat cramped, but 32 is overkill. and if all longer types are fakes with 8 bit instructions anyway...
[07:47:48] <inflex> amee2k: yeah, have wondered that at times too
[07:47:56] <inflex> and 48-bit
[07:48:09] <amee2k> yeah
[07:48:32] <amee2k> i rarely use 64 bit on avr though
[07:48:38] <amee2k> it need a lot of memory too
[07:48:40] <inflex> Sh4rK: has a bad habit of treating non-pedantic specified constants as 16-bit
[07:49:03] <Sh4rK> fun
[07:49:11] <Sh4rK> thanks for pointing this out
[07:49:16] <inflex> np
[07:49:42] <inflex> give it a shot and see what happens without - just to verify - maybe they fixed it in the more recent gcc's
[07:50:35] <amee2k> specifying it explicity shouldn't hurt either way. worst case, the compiler handles it as long internally, then truncates it for the short assignment
[07:52:06] <amee2k> what would make much more sense in a portability sense too would be specifying integer types by minimum number of bits, and the compiler selects the next longer appropriate type on its own
[07:53:03] <amee2k> like "int(10)_t" or something would yield a signed type that is at least 10 bits wide
[07:55:39] <karlp> you mean like:
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html#ga17f379713bed2a28ac431760401253cd
[07:57:44] <karlp> inflex: adding the UL and ULL suffixes should only matter when the constant is so large, and at that point, the compiler will tell you need it anyway.
[07:57:58] <karlp> what sort of problems ahve you seen when it wasn't specified?
[07:58:48] <inflex> karlp: in something simple like i64 = i32 *1234567; /// result will not be correct
[07:58:56] <inflex> but put in the UL and it would be correct
[07:59:05] <karlp> huh, interesting.
[07:59:15] <amee2k> karlp: yeah, thats what i'm using most of the time. but the number of bits is the bits of the desired data type, not the _minimum_ number of bits to hold the required value
[07:59:41] <amee2k> inflex: wouldn't you need to put the UL constant first then?
[08:00:01] <amee2k> otherwise the first type is i32 so the multiplication would be handled as 32 bit too i think
[08:00:05] <inflex> amee2k: possibly, I didn't try changing the order of the items
[08:03:18] <grummund> amee2k: the order doesn't matter
[08:05:12] <amee2k> are you sure about that? o.O
[08:05:24] <grummund> yes :)
[08:05:57] <amee2k> from somewhere i remember that operands should always be ordered with the largest one first because that will be used as the return type
[08:19:22] <grummund> in fact for the example given the correct suffix would be LL
[08:19:49] <grummund> or (int64_t)
[08:30:44] <spow_> could someone take a look at this and tell me why it isn't valid please ? :
http://pastebin.com/h6y2pPE8
[08:32:49] <OndraSter_> which line?
[08:33:00] <OndraSter_> the while?
[08:33:23] <grummund> can't comment on the use of the timer, but line 10 is definitely wrong.
[08:34:06] <grummund> should be:
[08:34:08] <grummund> TCCR1B &= ~((1 << CS10) | (1 << CS11) | (1 << CS12)); // stop timer
[08:35:16] <spow_> gosh i'm so stupid
[08:35:29] <spow_> thanks !
[08:35:55] <grummund> np. one reason why i prefer _BV(...)
[08:35:59] <Steffanx> Blegh
[08:36:00] <spow_> ah no, actually it has the same behaviour
[08:36:15] <Steffanx> _BV didnt really solve this problem grummund
[08:36:20] <grummund> well probably you can't use the timer like that
[08:36:34] <spow_> I shoudln't stop the timer after I sed it ?
[08:36:50] <grummund> Steffanx: probably wouldn't have made that mistake with _BV()
[08:38:00] <norbi> hello!
[08:38:27] <Steffanx> Hi
[08:44:30] <norbi> http://www.youtube.com/watch?v=vbAVZ3BPgO4&feature=related this woman is student?
[08:44:52] <norbi> i dont even get what is this project
[09:03:46] <spow_> i'm sorry but the timer still fails. I'm pretty sure it usually works with resetting TCNT1 and then set the appropriate prescaler in TCCR1B. I set CS10 and CS12 to 1, which according to the datasheet is a prescaler r of 1/1024 which means that t 15k terations should be somewhat equal to a second, but it seems it fails and reboots the program since only the first led blinks (whereas without the timer part of the program all leds blink, one
[09:05:05] <spow_> and I don't see howI can test with a simpler code than that :
http://pastebin.com/amS9U7d4
[09:07:59] <grummund> #define F_CPU 16000000UL
[09:08:06] <grummund> #include <util/delay.h>
[09:08:06] <grummund> void wait(void) { _delay_ms(1000); }
[09:08:53] <spow_> it's a solution but I can't spend my life avoiding timers :)
[09:09:19] <spow_> plus i'm pretty confident I made it work this exact way in the past
[09:10:35] <spow_> hum ok, so the timer is _noy_ the probelm, since the delay fails the same here
[09:12:35] <grummund> #include <avr/wdt.h>
[09:12:36] <grummund> wdt_disable(); // turn off watchdog timer
[09:14:29] <spow_> grummund: ok, this way of disabling the watchdog timer makes it work... but the one I used before (from the datasheet) worked at first !
[09:14:36] <spow_> i'm getting really confused
[09:15:45] <grummund> perhaps you changed gcc optimisations?
[09:16:02] <grummund> or change the WDT fuse, or use a different chip?
[09:17:52] <spow_> the opt is 's', chip is the same and I still haven't read about fuses
[09:18:36] <grummund> dunno then...
[09:18:57] <grummund> but use the wdT_*() macros
[09:19:23] <spow_> obviously, you were right about that from the beginning :)
[09:19:40] <grummund> they exist precisely because it's not possible to guarantee the correct sequence with plain C.
[09:19:41] <spow_> thanks
[09:20:32] <grummund> time for some cake :)
[09:20:35] <spow_> yeah the part where WDE has to be set to 0 in the next 4 clock cycles is.. disturbing (if that was what you meant)
[09:20:45] <grummund> yes
[09:21:37] <spow_> thanks for your help !
[09:34:21] <amee2k> any better thoughts than an MC34063 to step 24V down to 5V? (current requirements <= 250mA)
[09:41:22] <Sh4rK> does anyone have an idea why is that when I put a little code in my program, when I trite to write it into the avr, it has an error verifying, but with that code removed, it works perfectly (no compile errors)
[09:41:32] <Sh4rK> *try
[09:41:59] <grummund> exceeded flash size?
[09:42:28] <Sh4rK> I don't think so
[09:42:34] <Sh4rK> it is a mega88
[09:42:37] <amee2k> i think avrdude at least throws an error in that case
[09:43:04] <Sh4rK> and when compiling it tells it's 1622 bytes
[09:44:17] <amee2k> does it run correctly if you just reset it after the verification error?
[09:44:44] <Sh4rK> no
[09:44:52] <Sh4rK> but I think I found why
[09:45:01] <Sh4rK> I lowered the programming frequency
[09:45:04] <Sh4rK> and now it works
[09:45:07] <Sh4rK> for some reason
[09:46:22] <Sh4rK> actually it was just by mistake
[09:46:25] <karlp> what clock are you running on?
[09:46:26] <Sh4rK> now it fails again
[09:46:30] <Sh4rK> 20 MHz
[09:46:37] <karlp> are you _sure_ :)
[09:47:07] <karlp> do you have clkdiv8? are fuses set to actually run from the clock source you intended?
[09:47:12] <Sh4rK> yes
[09:47:16] <Sh4rK> everything's set
[09:47:17] <karlp> just checking :)
[09:47:27] <Sh4rK> and now it succeeded again
[09:47:30] <Sh4rK> seems to be random
[10:08:40] <spow_> I have a behaviour I don't understand : I do an A/D conv in the main loop, but the a/d value seems to only be read at program start, I have to reset the µC to see a change in the output (based on a potentiometer)
[10:09:21] <spow_> do I have to reinitialize all the parameters each time ? (ADCSRA, ADMUX ..)
[10:16:00] <Casper> spow_: there is 2 things you can do
[10:16:15] <Casper> set it so it go in free running mode
[10:16:17] <Casper> or
[10:16:55] <amee2k> spow_: no, you only set up all the registers once usually, or immediately prior to starting a conversion
[10:16:56] <Casper> start the conversion, and restart them when you want an update (or in an interrupt)
[10:17:08] <amee2k> then start the conversion, wait until the finished flag comes up, read value
[10:17:50] <amee2k> typically you would only change the channel selection bits and maybe the reference before a conversion
[10:18:00] <amee2k> and the rest is just set up once and then left in place
[10:20:00] <spow_> mh
[10:20:19] <spow_> at the moment, I wait until ADSC is back to 0, could it be the problem ?
[10:20:44] <spow_> I don't use free-running mode, since while reading the datasheet I have seen it creates a lot of 'peculiar' cases
[10:22:07] <amee2k> no, the adsc bit is reset to 0 to indicate the conversion is completed
[10:22:23] <amee2k> but you have to set it to 1 yourself every time to start the next conversion
[10:22:48] <spow_> so it should be ok to keep polling it until it was set back to 0 to know when the conv. finished then ?
[10:23:08] <Casper> yes it's correct
[10:23:20] <Casper> and it's actually called pooling mode
[10:23:27] <amee2k> like this: int adc_read() {ADCSRA |= (1<<ADSC); while(ADCSRA & (1<<ADSC)); return ADC;}
[10:23:39] <spow_> and since i'm not in free-running mode I can set the canal right before I start the A/D conv
[10:23:56] <Casper> ASDC = 1; while (ADSC); foo=ADC;
[10:24:05] <Casper> yup
[10:24:05] <amee2k> in theory you could do something else before entering the busy-waiting loop to use the idle time. but doing stuff while a conversion is in progress may introduce noise
[10:24:13] <spow_> well, I think it's how I use it
[10:24:53] <Casper> ADMUX=foo; ADSC=1; while(ADSC); bar=ADC;
[10:25:09] <Casper> pseudo C can be so wrong....
[10:25:13] <spow_> but the value seems to be static
[10:25:36] * amee2k scratches head
[10:25:49] <Casper> are you sure that you read the right channel?
[10:25:50] <amee2k> i very very vaguely recall having a similar issue once before...
[10:26:01] <amee2k> but i can't put my finger on when, or how i got it to work
[10:26:08] <spow_> I only read one channel anyways ^^
[10:26:11] <Casper> single ended channel that's it, so channel 0-7 of admix
[10:26:19] <Casper> admux
[10:26:38] <Casper> also, be sure that your voltage do not excede AREF
[10:27:03] <spow_> this is what I wrote from various tutos/datasheet :
http://pastebin.com/vZy1rfX4
[10:27:23] <spow_> and the max voltage is that of the board itself, so it should be fine
[10:28:41] <spow_> if I turn the potentiometer one way or another, I need to reset the µC to see the actual output, but my read_adc() is in the main loop
[10:29:18] <amee2k> i'd recommend to set up the port directions when entering main()
[10:29:32] <amee2k> not in the adc setup function unless they are strongly related
[10:30:03] <amee2k> on that note, to get a high impedance input you need to set up the ADC pin as input with pullup disabled
[10:31:25] <spow_> such is the case, and I've moved the DDRx back into the main
[10:32:32] <amee2k> including the pullup disabled part?
[10:32:53] <spow_> PORTA=0x00; disables all pull-ups right ?
[10:33:19] <Casper> spow_: #22-23
[10:33:34] <Casper> replace by return ADC;
[10:33:46] <Casper> won't fix the problem
[10:33:52] <Casper> but you do not need to do what you did
[10:34:34] <spow_> oh, didn't know the avr would pre-concatenate it for me :)
[10:34:55] <Casper> avr-gcc does atleast
[10:35:09] <spow_> and now it works oO
[10:35:15] <spow_> wtf ...
[10:35:21] <amee2k> mmh, there also is some peculiarity about the order in which the low and high halves of the ADC data register are read
[10:36:16] <Casper> yeah I think it's low bits high bits...
[10:36:18] <amee2k> they are buffered so you can read them in a way that guarantees that you'll always get low and high bytes from the same conversion
[10:36:23] <Casper> which imo is an idiocy
[10:36:34] <spow_> so my way of concatenating was wrong ?
[10:37:06] <amee2k> thats why you should prefer using the macro for reading 16 bit registers, if there is something to watch out for they'll do it correctly
[10:37:19] <Casper> spow_: possibly... iirc, the bit is 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8
[10:37:22] <amee2k> Casper: registers are only 8 bit long, they can't do it any differently
[10:37:44] <Casper> amee2k: I mean how it's stored in ram, not registers
[10:37:50] * amee2k looks at Casper
[10:38:03] <amee2k> whatever you are smoking, you should stop :P
[10:38:06] <Casper> or nm me :D
[10:38:22] <Casper> but anyway, no need to mess up with that when there is no need to
[10:38:51] <amee2k> the ADC result is always 10 bit, and the register is always 16 (and split into two 8-bit memory locations)
[10:39:03] <spow_> datasheet : "When ADCL is read, the ADC Data Register is not updated until ADCH is read. "
[10:39:03] <Casper> yes
[10:39:08] <Casper> but still... anyway
[10:39:15] <Casper> spow_: btw
[10:39:29] <Casper> you might get into that trouble later so better tell you now
[10:39:36] <Casper> if you have interrupts
[10:39:42] <amee2k> there is a bit in some configuration register that determines whether the 10 bit result will be written to the top or bottom 10 bit of the 16 bit register
[10:39:54] <Casper> care must be taken when reading and writting to more than 8 bits variables
[10:40:03] <spow_> amee2k: are you speaking of left-alignment ?
[10:40:07] <amee2k> if you let it write the result to the top 10 bits, you can read the 8 MSB off the high byte register and fake an 8 bit conversion
[10:40:13] <Casper> because the main code can be writting to the ...
[10:40:15] <Casper> client brb
[10:40:17] <amee2k> spow_: exactly
[10:40:33] <amee2k> but that is about all the bit order weirdness there is
[10:40:49] <spow_> left-alignment you lose 2 bits precision
[10:41:11] <spow_> Casper: I did not get it, but I pasted it in a .txt just in case ;)
[10:41:37] <amee2k> spow_: you technically don't lose it. you can still read the other two bits off the low byte register. but assembling the 10 bit value with left alignment enabled is somewhat awkward
[10:41:58] <amee2k> it is more of a convenience thing so you can access it faster
[10:42:10] <spow_> ok
[10:42:16] <spow_> but just one thing
[10:42:26] <amee2k> left alignment allows you to discard the lower 2 bits implicitly by only reading the top 8 bits
[10:42:31] <spow_> I used this : result = ((uint16_t)ADCH << 8) | ADCL;
[10:42:57] <spow_> which fails because (possibly) datasheet says : "ADCL must be read first, then ADCH."
[10:43:36] <spow_> but I thought that in C, it was virtually impossible to tell which byte gets read first from such an operation
[10:44:09] <Casper> spow_: ok
[10:44:24] <Casper> main code start to read a 16 bits variable
[10:44:30] <amee2k> in theory, the compiler can evaluate either operand first at its own discretion. only boolean operands (&& and ||) exhibit "lazy evaluation"
[10:44:31] <Casper> it read the first 8 bits
[10:44:39] <Casper> the interrupt get fired up, stop the main code
[10:44:48] <Casper> that interrupt update the variable
[10:44:52] <Casper> and then return
[10:44:58] <amee2k> in practice i'd say 90% chance the compiler will evaluate operands in the order they are given in the code
[10:45:17] <Casper> the main code read the second part... woops... that's the NEW value
[10:45:25] <amee2k> but it doesn't have to... relying on which register is read first here would be "undefined behaviour"
[10:45:59] <Casper> so what you need to do in such case is to stop the interrupt before readin the variable, read, then reenable them
[10:46:15] <amee2k> to force it you could do "uint16_t temp = ADCL; ADCL |= ((uint16_t)ADCH) << 8;"
[10:46:20] <amee2k> err
[10:46:21] <Casper> this way you ensure that you will read the full variable without it being modified while reading
[10:46:30] <amee2k> "uint16_t temp = ADCL; temp |= ((uint16_t)ADCH) << 8;"
[10:46:34] <Casper> amee2k: wrong
[10:46:47] <amee2k> ?
[10:46:54] <Casper> the temp buffering is 2 instruction
[10:47:29] <amee2k> Casper: but it ensures registers are read in the correct order because there is a sequence point between statements
[10:47:45] <amee2k> nobody says you have to access them in consecutive cycles
[10:47:47] <Casper> amee2k: that is something else of an issue
[10:48:07] <Casper> I'm talking about the interrupt that mess up the variable while you read it
[10:48:29] <amee2k> interrupt? o.O
[10:48:46] <Casper> ... read what I wrote...
[10:49:07] <carp3> is there any open-source implementation of ftisp ?
[10:49:11] <Casper> I said I'm telling him before he ran into that issue later when he'll use interrupt
[10:49:41] <spow_> Casper: we were discussing sequence points and operation order (referring to why my prev. code failed)
[10:49:57] <amee2k> Casper: an interrupt is like a function call that comes out of the blue. it doesn't mess up your stack frame or any variables that you don't access implicitly inside the ISR
[10:49:58] <spow_> I understood the interrupt thing though :)
[10:50:26] <Casper> man.... for 3 weeks I listened to another radio station.... because I wanted some xmas music.... now I return to the fav station to be welcoked with the same few songs than before I leave...
[10:50:36] <amee2k> assembling the ADCL/H value in one statement will internally still use a temporary variable, you just can't see it anymore
[10:51:12] <Casper> but yeah, proper order of reading is important for some registers in the avr...
[10:51:18] <amee2k> and the whole purpose of buffering the ADC register is to ensure an arbitrary delay between reading the bytes won't mess up the value
[10:52:02] <spow_> thanks so much to the both of you for the very precise explanations !
[10:52:18] <Casper> spow_: btw, for the interrupt thing... avr-libc provide the atomic.h library, it's a bit messy but do take care of the code
[10:52:32] <amee2k> Casper: in some cases proper order, and in some cases also proper delay between accessing things. thats two different things, really
[10:53:02] <Casper> one function allow you to save, disable, execute then restore the state. so if there was no enabled interrupt before it won' reenable...
[10:53:03] <amee2k> thats why you'd set up the prescaler register before enabling interrupts (or temporarily disable them if you change it somewhere on the fly)
[10:53:13] <Casper> amee2k: yeah
[10:53:16] <Casper> lots of things
[10:53:23] <Casper> and tining issue is a real pita
[10:53:34] * Casper recalls when he made his lcd lib...
[10:53:35] <amee2k> but the prescaler register is only a single byte register
[10:53:57] <amee2k> so proper sequence and proper timing are two entirely unrelated things
[10:54:02] <Casper> man.... bitbanging stuff is really annoying.... specially when the datasheet of the part do not tell everything....
[10:54:16] <amee2k> haha i know how that goes >_<
[10:54:28] <Casper> the timing diagram was wrong
[10:55:37] <Casper> rs/rw, nop(), data, 4x nop(), +e, 6 nop(), -e ← proper timing
[10:56:04] <Casper> rs/rw + data, e+, e- ← timing diagram
[10:56:28] <spow_> do I need to also copy this gibberish ? ^^
[10:56:32] <amee2k> but in that case the diagram was right, no?
[10:56:40] <Casper> spow_: no
[10:56:43] <amee2k> you just violated some setup and hold times
[10:56:44] <Casper> amee2k: no
[10:57:13] <Casper> the timing diagram didn't show that you had to wait a bit between some stuff
[10:57:16] <amee2k> then i don't see the difference
[10:57:23] <Casper> however the text was saying the delay needed
[10:57:30] <Casper> amee2k: notice the nop
[10:57:38] <amee2k> timing diagrams usually only show the sequence graphically
[10:58:05] <Casper> when setting rs/rw, then you need to wait a tiny bit... a few ns
[10:58:08] <amee2k> timing constraints are either drawn separately with |<-----t0----->| kind of arrows
[10:58:14] <amee2k> or only specified in the parameter table
[10:58:48] <Casper> then you can send the data.... then you need to wait "a long time" before turning high E, then wait some time before turning it off
[10:58:58] <Casper> the E part in the timing diagram was totally wrong
[10:59:07] <amee2k> okay
[10:59:20] <Casper> they kept it high for less than the minimum requirement in the parametric table
[10:59:54] <Casper> in other words: they messed up royally the timing diagram by violating every single timing partys
[11:00:27] <amee2k> thats why i said these diagrams only show the sequence and are not drawn to scale ;)
[11:02:23] <Casper> the sequence was technically wrong
[11:03:10] <Casper> but what can you expect from those chinese...
[11:03:37] <Casper> they are good to clone IC, but not to make accurate datasheet
[11:03:56] <Casper> the fun thing is that the original controller datasheet show the proper stuff
[11:04:09] <Casper> but the datasheet for the assembled LCD is not accurate
[11:12:44] <DanFrederiksen> does a HD44780 display default to sequential 4bit data reading so you could just connect 4 pins and refresh the display sequentially?
[11:12:44] <DanFrederiksen> just lock the command and write pin to high
[11:16:19] <Casper> no
[11:16:23] <Casper> it default to 8 bits
[11:16:26] <Casper> however
[11:16:49] <Casper> the initialisation is made in such a way that the lowest 4 bits are not-care while setting the mode
[11:16:56] <Casper> but
[11:17:06] <Casper> a proper initialisation is extremelly important
[11:17:13] <Casper> initialise to 8 bits 3 times in a row
[11:17:23] <Casper> then initialise to 4 bits
[11:17:38] <amee2k> o.O
[11:17:49] <amee2k> i only initialize to 4 bit once and it works
[11:18:08] <amee2k> either you have some lingering bugs or your display modules are flaky
[11:22:09] <amee2k> but maybe my modules have different fakes :P
[11:26:01] <DanFrederiksen> so you need to control the command/data bit during init?
[11:27:25] <amee2k> only the lower four (that would be used for 4-bit mode normally)
[11:27:44] <amee2k> (or was it higher four, don't remember...)
[11:27:47] <DanFrederiksen> yes but that's not the command pin
[11:28:08] <amee2k> oh, i read that as "data bits"
[11:28:11] <amee2k> >_>
[11:28:21] <DanFrederiksen> :)
[11:28:51] <amee2k> i *think* you need the command bit too, but last time i looked at the datasheet was quite a while ago
[11:28:52] <DanFrederiksen> it should default to 4bit. then it could be controlled with only 4 pins
[11:29:11] <amee2k> it *can* be controlled with only 4 bits
[11:29:32] <DanFrederiksen> hehe only after you can controlled the RS which is a 5th
[11:29:32] <amee2k> because you can still switch between modes when you tie the unused four data lines to ground
[11:29:48] <DanFrederiksen> have*
[11:30:06] <amee2k> 4 bit mode only refers to the data bus width ;)
[11:30:22] <DanFrederiksen> but I didn't say bits..
[11:30:23] <amee2k> anyway, dinner is ready... bbl
[11:30:54] <amee2k> and i said bits != pins too :)
[11:30:56] <DanFrederiksen> is the only mode of HD44780 sequential data? or can you write individual characters?
[11:45:32] <Casper> amee2k: the 3x 8 bits is to ensure that the lcd is in sync with the uC
[11:45:47] <Casper> like if the uC reset in the middle of the transfert
[11:46:04] <Casper> the lcd can be in second nibble "mode"
[11:46:16] <Casper> and you can not communicate anymore with it
[11:46:35] <Casper> in this case, the first init is eaten up
[11:47:02] <Casper> the second init get read as the first nibble, and the third complete the nibble
[11:47:14] <Casper> then you are now in 8 bits, and assured to be in sync
[11:47:24] <Casper> now you can initialise back to 4 bits
[11:48:16] <Casper> DanFrederiksen: as for the pin numbers...
[11:48:32] <Casper> you need at a minimum 6 pins: 4 data bits, RS and E
[11:49:18] <Casper> RW is optional, but required if you want to read the busy flag, if you do not you have to assume an execution time, so use delay
[11:52:01] <Casper> amee2k: as a side note, if you don't use the 3x8 bits init... it mean you can not reset the avr in a safe way. you would need to powercycle from time ti time for the nibbles issue
[12:25:10] <amee2k> Casper: unless during development my MCUs rarely have asynchronous resets
[12:25:20] <amee2k> (or unless the firmware crashes :P )
[14:57:36] <vanquish> this is kind of a shot in the dark
[14:57:54] <vanquish> does anyone here know anytning about gnutls/ssl, or know of a channel where peopel do?
[15:01:30] <mrfrenzy> yeah
[15:01:55] <mrfrenzy> I run gnutls and openssl with inspircd
[16:47:27] <amee2k> http://www.national.com/rap/Story/WOMorigin.html << BHAHAAAAAA
[16:47:32] <amee2k> HUGE LOL at the chart
[16:47:46] <amee2k> "remaining pins vs. number of insertions" XD
[16:47:56] <amee2k> (bottom of second page)
[16:48:16] <Steffanx> lol?
[16:48:46] <amee2k> entirely
[16:49:07] <Steffanx> At least it's a joke :)
[16:49:19] <amee2k> that datasheet is hilarious
[16:49:28] <Steffanx> Would be nice to see that in a real datasheet
[16:50:18] <amee2k> gotta be careful when reading the text on the first page, there are some subtle punchlines in there too
[16:50:43] <amee2k> well, some are not very subtle in any way though >_>
[16:51:18] <amee2k> the cooling recommendations remind me of the power hungry A64 X2 cpu in my desktop
[16:52:22] <amee2k> Steffanx: or check out the clock line capacitance rating for a good one
[17:13:05] <amee2k> as a side note, anyone got thoughts on writing board spec/data sheets in tex/latex?
[17:15:13] <amee2k> so far i've been using OOo for general project documentation because it is very WYSIWYG and allows for fast drafting of pretty much anything and general brainstorming
[17:18:50] <amee2k> but if i want to write more than a quick schematic and some notes, it doesn't feel very maintainable in the long run
[17:44:12] <vectory> .oO(schematics with OOo?)
[17:45:50] <amee2k> yep
[17:46:01] <amee2k> whats wrong with that?
[18:09:43] <keenerd> amee2k: Do you mean OOo draw? Not the best vector editor, but it can work.
[18:14:06] <amee2k> yeah, draw. not the best but relatively general purpose considering non-technical requirements
[18:15:00] <amee2k> also easy to learn for me since i was allready using OOo since the staroffice days
[18:15:14] <amee2k> so all i had to do was make a basic library with component symbols
[18:25:36] <vectory> http://atmel.com/dyn/resources/prod_documents/doc8333.pdf
[18:25:52] <vectory> lol, is the pic on the 1st page a joke?
[18:34:57] <Casper> lol vectory
[18:36:04] <Casper> vectory: let me find that datasheet...
[18:38:36] <Casper> vectory: www.linear.com/docs/4120
[18:38:40] <Casper> look at the last page
[18:38:47] <vectory> hm
[18:40:17] <Casper> vectory: how do you like it?
[18:40:36] <vectory> you mean the intro? sounds terrifying :|
[18:40:45] <vectory> still funny to read tho
[18:41:06] <Casper> no, last page
[18:41:14] <Casper> page 24
[18:42:11] <vectory> :)
[18:42:42] <Casper> can you guess the surprise I got when I printed it and saw that?
[18:43:47] <vectory> yes
[18:43:51] <vectory> never heard of linear technology
[18:43:59] <vectory> admittedly im not that long around
[18:45:55] <vectory> Casper: this is not the kind of switching involved with leds, is it? perhaps a different mode for different rows of leds ...
[18:46:33] <Casper> powersupply
[18:46:59] <vectory> k
[18:47:32] <vectory> there was a diagramm of Vf vs If in a led ds, what to make of i?
[18:47:39] <vectory> it*
[18:47:57] <vectory> is Vf variable?
[18:48:35] <Casper> Voltage forward
[18:48:42] <Casper> I = current... forward
[18:49:48] <vectory> or voltage drop, in other words
[18:50:29] <amee2k> linear is kind of a big name around ee... others that come to mine are analog devices, texas instruments, atmel, microchip hm... maxim too
[18:55:28] <vectory> i dont really get the nomenclatur, anyways, i wanted to use less current than specified, like 30-50%, but i wouldnt know how to calculate new Vf
[18:56:54] <amee2k> relying on the forward voltage of a LED to be accurate and stable is a huge, huge, no-no
[18:57:03] <vectory> with forward voltage on the x axis
[18:57:53] <amee2k> that being said, if the minimum and maximum figures from the datasheet aren't sufficient as an estimation, you can use the chart too but it will only give you a "typical" value. i.e. in real life it may be anywhere
[18:57:56] <vectory> after all, it needent be precise, i just need a ballpark figure
[18:58:48] <amee2k> for a ballpark i'd check the parameter table, there should be something like "Vf - min. 3V - max. 3.5V" or something
[18:59:28] <vectory> yes there is, under condition If = 20 mA
[18:59:31] <vectory> but id like more 5-10mA
[19:00:46] <amee2k> you could check the chart too... if Vf is on the X axis, find your current on the Y axis, go across until you hit the trace, then at a right angle to the other axis and read the value
[19:01:13] <amee2k> but LEDs are, as the name implies, still diodes (even if they suck as rectifiers)
[19:01:20] <Casper> vectory: assume constant Vforward across 0-If
[19:01:29] <amee2k> so the I/V curve will be roughly exponential with current
[19:02:02] <amee2k> so for 10mA you'll be maybe 200-300mV below the 20mA spec
[19:04:00] <vectory> seems reasonable, but it seems to be codependant, unlike a tradtionial x/y-diagramm
[19:04:07] <amee2k> in either case, i'd expect the difference to be in the same order as the inherent uncertainity of the Vf ratings so it would be mildly useless for practical purposes
[19:04:13] <vectory> :)
[19:04:48] <vectory> dont have the led here, possibly till monday
[19:05:03] <amee2k> LEDs are inherently current controlled devices and relying on anything that has to do with their forward voltage or I/V characteristics is usually a bad idea
[19:06:06] <vectory> forunately i dont need to understand that, i just need it to work >_<
[19:06:59] <amee2k> mmh, when you connect a lightbulb to a voltage supply it'll just work, right?
[19:07:10] <vectory> mostly
[19:07:17] <vectory> sometimes brighter
[19:07:25] <amee2k> the bulb has constant voltage across it and that is what it was made for... what you don't see is that the current flowing will pretty much do what it wants
[19:08:01] <vectory> i mean, i have no idea what controlls the current, when it can be deployed without a limiting resistor, given the input voltage isnt to high
[19:08:23] <amee2k> it will change with temperature, slightly with voltage, have a huge surge right after applying power and drop sharply as the device warms up
[19:08:43] <amee2k> some oscillators use light bulbs for temperature compensation even
[19:08:49] <vectory> isnt switching rapidly a bad idea then?
[19:09:13] <amee2k> if the switching is slow enough to allow the filament to cool down and heat back up again, yes
[19:09:37] <amee2k> well, what i wanted to say is that LEDs are pretty much the exact opposite of that behaviour
[19:10:10] <amee2k> they expect to be supplied with constant current and, while staying in the general ballpark, the voltage will wag around like a dog tail
[19:11:13] <amee2k> driving a LED with a constant voltage supply is pretty fiddly and unreliable because you quickly get huge, unintended current swings
[19:11:53] <amee2k> same as feeding constant current to a lightbulb is a bad idea because at first it won't start, and when you get it to start in the end it'll blow out because the voltage goes through the roof
[19:12:42] <vectory> sounds wicked
[19:13:06] <vectory> the datasheet gives rates for 1kHz frequency, cant have that, more like 128 Hz
[19:13:06] <amee2k> hehe :)
[19:13:43] <amee2k> any flicker higher than 100Hz is usually invisible to *most* people
[19:14:36] <vectory> cant check for current spikes either, if theres enough time for the led too cool down. bummer
[19:14:38] <amee2k> some people get headaches or other subtle side effects, or do see it during quick movements but thats it
[19:14:52] <amee2k> LEDs are not lightbulbs ;)
[19:15:22] <vectory> oh, misunderstood
[19:15:56] <amee2k> both have peculiarities if you try to use them the wrong way. thats why i used it as an example
[19:16:49] <amee2k> heat cycling a filament will wear it out, but cooling down takes a few hundred milliseconds. thats why lightbulbs get away with only 50/60Hz mains just fine. the filament doesn't noticably stop glowing during the zero crossing
[19:17:55] <amee2k> LEDs are built more solidly so they can handle temperature swings more easily and they don't have swings of several hundred or thousand degrees
[19:18:32] <amee2k> if a high power (>1W) LED's die runs at 60-80°C above ambient, that is a lot
[19:19:29] <amee2k> the problem is they are a lot quicker so 50Hz flicker (mains with halfwave rectifier) is readily visible in many cases
[19:20:32] <amee2k> the ronja project uses LEDs for optical data transmission in excess of 10MHz. as far as a human eye is concerned (and unlike a lightbulb) they have virtually no turn-on and turn-off times
[19:21:34] <jacekowski> talking about LEDSs and optical data transmission
[19:21:36] <jacekowski> how is that going
[19:21:48] <amee2k> 128Hz PWM should work fine for most cases, but i try to go for at least 300-400 if i can
[19:21:57] <jacekowski> any working devices that can do at least 100Mbits and don't cost arm and leg
[19:22:58] <amee2k> lol
[19:23:06] <amee2k> i killed the conversation again :P
[19:23:24] <vectory> was most interesting
[19:23:43] <amee2k> you're welcome :)
[19:23:54] <vectory> thx a lot
[19:24:10] <vectory> i'll call it a night
[19:24:18] <amee2k> hehe, me too i suppose :)
[19:24:25] <amee2k> just past 2 in the morning here
[19:24:35] <jacekowski> amee2k: well, talking about 100Hz+
[19:25:02] <jacekowski> amee2k: ask any "pro gamer" he will tell you that he can tell difference between 60 and 120 and 500 fps ( on lcd screen that's doing 60Hz )
[19:25:31] <amee2k> :P
[19:25:32] <vectory> i know the type, i dont wanna disagree tho
[19:25:38] <vectory> anyway, n8 folks
[19:25:59] <amee2k> and audiophiles can tell the difference between 3GHz and 4GHz opamps when listening to bethoven
[19:26:05] <amee2k> >_>
[19:29:55] <inflex> O_o
[19:30:02] * inflex wonders if amee2k is for real
