Back
[01:00:38] <composite> any good dev kits for motor control? BLDC, etc...
[01:01:40] <Casper> depend on what kind of motor
[01:06:47] <composite> i just want to demo stuff
[01:06:52] <composite> i guess i can just model it in matlab
[01:10:50] <Casper> there is lots of kind of motor
[01:10:54] <composite> dfga
[01:11:11] <Casper> dfga?
[01:19:55] <composite> sorry, i had an issue with x-chat
[01:20:00] <composite> bldc
[01:20:04] <composite> ac induction
[01:20:25] <composite> bldc sensorless and bldc non-sensorless
[01:23:06] <Casper> I'm pretty sure that there is some kit avail
[01:24:08] <composite> yah
[01:24:18] <composite> i just want someone to purchase a kit for me
[01:44:28] <composite> Casper, do you use any PICs?
[01:44:43] <Casper> no, I want to stay sane
[01:44:57] <composite> hehe, why do you say that?
[01:47:40] <Casper> the one that decided it was a good idea to use bank for the registers should be skinned alive, then dipped in alcohol, then dumped in salt, then back in alcohol and possibly throw a lit match at him
[01:49:43] <composite> they made you suffer?
[01:51:24] <Casper> and what's up with that ridiculous instruction set?
[01:54:34] <composite> yah. ok, just wanted to ask to be sure
[01:54:47] <composite> there's always this avr vs pic thing
[01:54:57] <composite> avr seems less confusing
[01:56:40] <Casper> way less
[01:56:48] <Casper> but I admit I didn't touched the pic18
[01:56:55] <Casper> and they look interresting featurewise
[01:57:03] <Casper> better ADC, feature some DAC
[01:58:00] <composite> have you ever done anything with FPGAs?
[01:58:05] <carp3> Hi, what's wrong with my code ?
http://pastebin.com/nUcFdiUk i get 2ms H and 18ms L on PORTD. but i should get 19ms L and 1ms H, ( Because Speed=0)
[01:58:47] <Casper> nope
[02:00:29] <Casper> carp3: you sure you shouln't set the port then have the delay?
[02:00:34] <Casper> and also
[02:00:52] <Casper> take into consideration that delay_us() has not been made to get the value at runtime
[02:00:59] <Casper> your delay won't be as precise
[02:01:05] <Casper> and the code is huge
[02:02:48] <Kevin`> carp3: is there some reason you aren't starting directly with a hardware pwm output or an event system?
[02:05:57] <carp3> Kevin`: because i want high precision 50Hz(+/- 5) and High resolution (1000step at least) PWM. i can get 60HZ(8Mhz int RC) and 100step (12bit) with PWM.
[02:06:02] <carp3> (sorry for my english)
[02:06:43] <Kevin`> carp3: 12bit is 4096 steps
[02:07:04] <carp3> i mean 1000 step between 10% of Duty Cycle and 20%.
[02:07:28] <Kevin`> carp3: have the timer overflow a few times before you turn the output back on
[05:09:03] <amee2k> is there an existing, robust soft-TWI slave solution that can use arbitrary pins?
[05:16:51] <amee2k> i need to get my twi away from the damn ADC pins >_<
[05:17:37] <karlp> what are you using the real twi pins for?
[05:17:44] <amee2k> ADCing
[05:18:20] <amee2k> for some reason almost all AVRs in my size class seem to have the TWI pins in the middle of the ADC pins
[05:19:06] <amee2k> i'm looking for something in the general range from tiny44 to mega48 in SOIC or QFP package
[05:27:31] <amee2k> after accounting for the TWI pins, i'm one ADC pin short and i'd hate to have to use an external ADC for just one channel >_<
[05:29:22] <karlp> are you using one of the crippled packages that is missing the 6th and 7th adc inputs?
[05:53:24] <amee2k> karlp: no, check out the tiny24 pinout... ADC pins are 6 through 13, TWI is on 7 and 9
[05:54:15] <amee2k> megaX8 is ADC on 23 through 28 and err... don't remember and TWI on 27/28
[05:54:28] <amee2k> err wait no
[05:55:10] <amee2k> mX8 is ADC on 22 through 28 and 19 and TWI on 27/28
[05:55:48] <amee2k> i've looked at a bunch of others too that have my general feature set but no cookie yet
[05:56:04] <amee2k> i'm always losing two ADC pins to TWI and i'd need both
[05:58:19] <karlp> was just thinking of the 168/328 for instance, where the dip package only has 6 adcs, but the qfp package has all 8
[05:58:42] <amee2k> no, i'm looking for SMT
[05:58:53] <karlp> I take it a different processor is out of the question?
[05:58:54] <amee2k> no point in using thru-hole if i want to order boards
[05:59:19] <amee2k> 90% of my MCU exp is with AVRs and i'm already trying a lot of new things
[05:59:31] <karlp> well, qfp _had_ the extra adcs, I was just wondering if there was similar issues across packages in some of the other lines too.
[05:59:43] <amee2k> so i'd say strong preference but not requirement
[06:00:09] <karlp> you want to be twi slave too?
[06:00:24] <amee2k> my current draft requires 7 ADC channels, so losing two of 8 means i need to reconsider some things
[06:00:25] <karlp> I don't remember seeing a software slave for twi,
[06:00:34] <amee2k> mainly slave, actually
[06:00:41] <karlp> I think I've seen a few soft masters
[06:00:52] <amee2k> master is easy enough, like SPI master in software is
[06:01:11] <amee2k> well, soft SPI slave wouldn't be too difficult either, but still
[06:01:23] <amee2k> since the interface is kinda critical i'd prefer using an existing library for that
[06:02:14] <amee2k> on the upside there isn't much timing-critical stuff going on so the TWI lib can have whatever it needs
[06:03:44] <amee2k> only making some PWM channels and the ADC readings available over TWI. the bulk of the soft features is in the protocol… i'm using a pretty fancy addressing scheme with grouping and stuff
[06:03:54] <karlp> slave is much harder, it all has to be interrupt driven when things arrive
[06:04:01] <karlp> you can't just bit bang it ina busy loop
[06:04:02] <amee2k> i know
[06:04:27] <Kevin`> um, you CAN just sit around and bit bang it in a busy loop, provided the busy loop includes polling
[06:04:33] <amee2k> also my protocol relies on the TWI style arbitration mechanism being implemented properly
[06:04:47] <karlp> Kevin`: yeah, I guess you can poll the inputs looking for the transitions.
[06:04:53] <karlp> thanks for keeping me honest :)
[06:04:55] <amee2k> that is what i have the most doubt with about doing my own
[07:11:48] <Fleck> how can i make my atmega168 to arduino device? can i do this with USB ISP programmer?
[07:15:59] <karlp> Fleck: sure, just use yourisp programmer to put the arduino bootloader on it
[07:16:26] <Fleck> ok thx, will try to do that! :)
[07:41:23] <Fleck> karlp where can i get arduino bootloaders?
[07:42:19] <eatyourguitar> there are two bootloaders
[07:42:31] <eatyourguitar> the new one is called optiboot
[07:43:13] <eatyourguitar> I think you can use the IDE to burn bootloaders if you have a USBtinyISP or another arduino with the ISP sketch loaded
[07:43:24] <Fleck> yep, saw that in IDE :) thx
[07:43:40] <eatyourguitar> I have youtube videos and shit for that
[07:43:57] <karlp> there are more than two :)
[07:44:07] <eatyourguitar> I don't really understand why optiboot is better
[07:44:18] <eatyourguitar> lots of stuff that does not work with it
[07:44:18] <karlp> https://github.com/arduino/Arduino/tree/master/hardware/arduino/bootloaders
[07:45:31] <karlp> optiboot is smaller, so leaves more space for user code.
[07:45:37] <karlp> and can be faster.
[07:55:06] <Fleck> i whant atmega168 to use usb not ftdi chip for arduino - is this possible?
[07:55:19] <amee2k> not really
[07:55:42] <amee2k> well, with v-usb but megaX8 doesn't have a built in USB interface
[07:58:44] <Fleck> ok, can i flash bootloader and code with isp programmer then? or after bootloader i need to use ftdi to flash my code?
[07:59:14] <amee2k> yeah, ISP programmer can do pretty much anything
[07:59:59] <amee2k> only way to lock out ISP is messing up the fuses, in which case only an HVPP programmer will be able to clear the MCU
[08:00:14] <Fleck> i mean my arduino code
[08:00:40] <amee2k> and it doesn't need to be FTDI specifically. from what i remember the arduino bootloader just uses the UART so you can flash the MCU from any serial port this way
[08:01:02] <Fleck> the problem is - that i dont have serial port :D
[08:01:17] <amee2k> but any cheap usb-to-serial adapter will work fine
[08:01:31] <amee2k> doesn't need to be the FTDI chip specifically
[08:01:36] <Fleck> yeah, have one of those :)
[08:02:58] <amee2k> genuine FTDI stuff is kinda expensive. i've been wondering if an AVR with suitable firmware would be a replacement (even if not pin compatible) and beat the FTDI one price wise
[08:03:15] <amee2k> say tiny44 with v-usb
[08:05:20] <karlp> if it's not pin compatib and software compat, whyw ould I buy it?
[08:05:37] <ziph> Or even actually USB. ;)
[08:05:57] <amee2k> i mean software compat, but i'm not sure if i can mimic the FTDI pinout with the tiny
[08:06:19] <amee2k> and you might want to consider it if it is half the price
[08:06:34] <karlp> if you're designing from scratch, and watn usb, use a part with usb.
[08:07:07] <amee2k> there are small and cheap ones like a tiny24 with usb?
[08:07:38] <inflex> probably still cheaper overall even if you get an overkill of a uC with it
[08:10:00] <ziph> Overkill as in actually being able to use interrupts without killing V-USB? :)
[08:23:01] <Kevin`> why do you need interrupts, just poll the uart status continuously whenever you aren't responding to a usb edge
[08:24:07] <ziph> Or use something that implements actual USB and do it however you normally would on a uC? :)
[08:24:14] <Kevin`> also, karlp is right, you can get microcontrollers with native usb cheaper
[08:24:30] <Kevin`> erm, inflex rather
[08:24:32] <Kevin`> whichever :)
[08:25:53] <Kevin`> with native usb you could have it program the chip at <12mbit over isp, why use the bootloader. actually, you could do that with v-usb too.
[08:26:45] <ziph> Yeah, I don't understand why they didn't do that with the Arduino that has LUFA and a USB AVR as well as the main AVR.
[08:27:47] <Kevin`> you could even make it behave the same way. keep the serial function, and have it either talk to the uart or work as a programmer with the usual serial interface
[08:27:50] <ziph> They could've still had the UART on the main AVR appear as a COM port and gained not having to release the COM port every time you wanted to reprogram.
[08:28:33] <ziph> Jinx. ;)
[08:28:44] <Kevin`> I think they actually juse used the usb avr because it was cheaper than ftdi. which is kind of shortsighted, but overall nice for hacking
[08:29:09] <ziph> Yeah.
[08:29:17] <ziph> They probably fear changing it at all too.
[08:29:30] <karlp> which is why people used ftdi chips in the first place.
[08:29:46] <karlp> take existing design, rip of DB9 header, add ftdi chip and usb port, done.
[08:30:38] <Kevin`> karlp: well what else would you do, a software usb bootloader?
[08:30:52] <karlp> hmm?
[08:30:59] <karlp> if I had an exsting serial design?
[08:31:00] <Kevin`> on the original usb arduino, I mean
[08:31:02] <Kevin`> how would you do it
[08:31:11] <ziph> Kevin`: We're talking about having the USB AVR program the other AVR using regular SPI.
[08:31:17] <karlp> back then was also before the usb enabled chips were beocming common and cheap
[08:31:21] <ziph> Kevin`: e.g. just sticking an AVR programmer on the same board.
[08:31:22] <karlp> I don't knwo what I would have done then
[08:31:43] <Kevin`> ziph: right, so was I
[08:31:51] <Kevin`> (before)
[08:35:18] <inflex> yeah, the FTDI's are nice
[08:36:39] <ziph> I dislike not being able to buy a JTAG adapter without finding an FTDI in it though. ;)
[08:37:19] <Kevin`> ziph: what's wrong with that? aside from being forced by the manufacturer to buy 5 of the same device
[08:37:39] <Kevin`> the 480mbit spi ones are kind of nice
[08:37:44] <ziph> The drivers are never any good, and you end up with speeds slower than RS232.
[08:40:42] <karlp> how often are you getting rs232 speeds on rs232 lnks anyway :)
[08:41:25] <ziph> 2000 bits a second is usually what you get on an FTDI JTAG adapter.
[08:41:37] <ziph> 15000 bits a second is what you get with a really good driver.
[08:42:00] <ziph> (And by driver I mean the userland JTAG interface too, not just the FTDI drivers)
[08:42:01] <Kevin`> must be using the usb 1.1 ftdi chips
[08:42:13] <ziph> Nah, the newer ones act the same.
[08:42:42] <karlp> screw jtag anyway. too many pins. SWD!
[08:42:53] <karlp> and add lines as desired for trace out
[08:43:13] <rue_mohr> you dont need jtag, you just need an led
[08:43:27] <karlp> you don't need electricity either.
[08:43:38] <ziph> I like ARM 20 pin JTAG, it has the correct number of grounds. ;)
[08:43:57] <ziph> (10 or more)
[08:44:05] <karlp> "correct" ?
[08:45:00] <ziph> Short of doing both 10 grounds and shielding it results in the best performance on ribbon cable.
[08:46:22] <karlp> yeah, but if you lose all the pins, you can stop using ribbon cable int he first place!
[08:46:30] <rue_mohr> http://hackaday.com/ yay cool!
[08:46:33] <ziph> Yeah. :)
[08:53:25] <inflex> I hate it when you get those "instructable" videos/steps on "how to wire up a LED" *sigh*
[08:54:24] <rue_mohr> hey some people need them :)
[08:54:37] <ziph> Yeah, the ones that skip past Fermi energy levels and just tell you which way to put the battery are terrible.
[08:55:02] <keenerd> When did Hackaday start using upper case? :-)
[08:58:12] <inflex> rue_mohr: it'snot that they exist that's the problem... it's that every damned joker creates their own
[08:58:56] * ziph ponders doing one that begins with a 12 part introduction to get fermi energy levels in.
[09:01:48] <keenerd> rue_mohr: Needs a link to explain hardware state machine. Unless you mean a finite state machine?
[09:02:59] <rue_mohr> yup, hardware fsm
[09:04:03] <rue_mohr> hmm maybe I should have lookup up that processor before I cut it off, it was a 12Mhz 8085 compat... oh well
[09:04:35] <rue_mohr> pretty sure I ahve more of them
[09:05:37] <rue_mohr> or not, masked rom
[09:10:12] <rue_mohr> oops 7810 is romless
[09:10:14] <rue_mohr> sigh
[09:10:36] * rue_mohr chants to himself -I'd never have used it-
[09:11:59] <amee2k> lol
[09:45:06] <eatyourguitar> whoa network split
[09:45:39] <specing> -.-
[09:46:24] <specing> nickserv is down, too
[09:52:09] <amee2k> poopnode
[09:52:34] <eatyourguitar> how often does this happen to the network?
[10:00:07] <amee2k> on a more or less irregular basis i'd say
[10:00:22] <OndraSter> mornin ladz
[10:00:37] <eatyourguitar> this is the time I have seen a split on freenode
[10:00:45] <eatyourguitar> dalnet split like everyday
[10:01:38] <eatyourguitar> I got one of these on ebay to make a programmer for DIP8
http://s17.postimage.org/pwrxidznj/ZIF16.jpg
[10:02:08] <eatyourguitar> so small, has a little handle. I like to think that it was made for elves
[10:03:59] <amee2k> not as bad i think, but every couple days
[10:04:10] <amee2k> http://pastebin.com/dtG2fTng << from my logs :)
[10:51:19] <vectory> does someone know a good external BOD circuit? possibly one that doesnt need the reset pin to be programmed?
[10:55:03] <_abc_> vectory: hmm
[10:55:54] <vectory> is that a "hm?" hm?
[10:56:44] <vectory> bod draws so much current in sleep modes, so i thought it might be possible to build a cheap one, power and cost wise
[10:57:04] <vectory> i know there are chips just for that
[10:57:31] <vectory> just asking, didnt go in the right direction on youtube
[10:58:15] <vectory> *on google
[10:58:16] <vectory> >_>
[11:02:20] <amee2k> vectory: how much ghetto style is acceptable?
[11:02:51] <vectory> as long as its working im ok with it :)
[11:02:56] <vectory> but g2g soon
[11:03:08] <amee2k> a simple one could be as simple as a pnp/p-mos keeping the reset high as long as the voltage is sufficient
[11:03:34] <vectory> hm, i see
[11:03:42] <amee2k> a BOD basically works by keeping the MCU in reset while voltage is insufficient to prevent it from doing funny stuff
[11:04:02] <amee2k> so an external one pretty much by design requires access to the reset pin
[11:04:17] <vectory> but, are transistors really giving defined levels or more like somewhat proportional to gate voltage/current
[11:04:56] <amee2k> BJTs are fairly consistent in their voltage because the B-E junction basically behaves like a diode
[11:05:39] <vectory> :S
[11:05:48] <vectory> well, gotta run
[11:05:54] <vectory> thx and bb
[11:05:54] <amee2k> lots of power supplies use that as a ghetto voltage reference... BE voltage multiplier
[11:05:59] <amee2k> k
[11:06:03] <amee2k> you're welcome :)
[11:06:06] <vectory> uhm, link?
[11:06:22] <amee2k> you know what a TL431 with voltage divider looks like?
[11:06:29] <vectory> am too late already, anyway >_<
[11:06:34] <amee2k> okay :)
[11:06:40] <vectory> nope
[11:06:49] <amee2k> highlight me when you have more time if you want more info
[11:07:10] <vectory> will do
[11:07:20] <vectory> dinner at parents now
[11:07:27] <vectory> pellkartoffeln \:D/
[11:07:42] <amee2k> nice :)
[11:21:33] <OndraSter> http://www.liveleak.com/view?i=e27_1327440153
[11:36:58] <atmega> weshalb ist eigentlich keiner von euch im Kanal ##avr-de ?
[11:39:32] <amee2k> weil deutsche pussies sind die nur ramsch von conrad kaufen :P
[11:39:41] * amee2k rennt weg und versteckt sich hinterm sofa
[12:26:01] <AuroraX> in atmega328 how can i attach an interrupt routine to pin 2?
[12:27:29] <Steffanx> Read the datasheet and try to find out how the pcint works?
[12:29:35] <AuroraX> what dtasheet?
[12:30:07] <timemage> AuroraX,
http://www.atmel.com/dyn/resources/prod_documents/doc8161.pdf
[12:30:26] <timemage> AuroraX, pin 2 has different purposes on different packages.
[12:31:20] <Steffanx> Someone who asks questions like that probably uses pdip timemage :D
[12:31:48] <timemage> Steffanx, i hope so.
[12:31:59] <Steffanx> but it's a pcint pin for all packages
[12:35:10] <timemage> yup. that's true. i hadn't bothered to look that far.
[12:36:21] * amee2k looks at Steffanx
[12:36:24] <amee2k> >_<
[12:36:50] * Steffanx looks back and wonders why amee2k looks
[12:37:35] <amee2k> are you implying that pdip is only for noobs and arduino fanboys
[12:37:54] <amee2k> (well, it is but anyway)
[12:38:35] * amee2k idly paints bl4ckb1t's bit orange
[12:39:29] <Steffanx> S:
[12:39:44] <amee2k> ^_^
[12:39:54] * Steffanx removes the paint
[12:39:59] <amee2k> awww
[12:40:04] <amee2k> don't you like orange?
[12:40:44] <Steffanx> I do, but it's just because i can
[12:41:02] <amee2k> lol
[12:41:34] <amee2k> always venturing in the name of a good cause! *nod*
[12:42:08] <timemage> amee2k, i'm not making my own boards or using surface mount either.
[12:42:49] <Steffanx> smd is nice :D
[12:43:59] <amee2k> cheap parts, expensive boards
[12:44:14] <Steffanx> Mwah, 10$ for a 5x5 board isn't tht bad
[12:44:16] <Steffanx> that
[12:44:58] <amee2k> its not 10$ anymore if you want 6x20cm
[12:45:16] <amee2k> i've seen board houses that want more like 100$ for that
[12:45:34] <timemage> Steffanx, just haven't gotten into it. also don't have anywhere to put all the crap i would need to do anything serious now.
[12:45:45] <amee2k> best price i've seen yet is 50EUR for three
[12:46:05] <Steffanx> I don't need 6x20 anyway amee2k :D
[12:46:42] <Steffanx> I probably would've tried to make it 3x5 or 6x10 or something like that
[12:46:43] <amee2k> you're welcome to port my project to 5x5 then
[12:47:29] <Steffanx> :P
[12:48:07] <Steffanx> I also get the money you save?
[12:50:14] <amee2k> since i already know it won't work, yes
[12:51:21] <Steffanx> ok :P
[12:51:28] <Steffanx> What is it for?
[12:51:38] <amee2k> power LED module
[12:51:48] <Steffanx> 6x20?!
[12:52:24] <amee2k> four 1.5W emitters in a linear array spaced 50mm apart, plus driver, plus MCU for PWM and monitoring, plus floating TWI bus transciever
[12:52:47] <amee2k> MCU with associated support circuitry, obviously
[12:53:44] <Steffanx> I still would've tried to make something like that modular
[12:54:23] <amee2k> then i'd have like 5 boards 5x5 each. thats not much better imo
[12:54:56] <amee2k> with luck three, but a pile of connections that include the main current path
[12:55:58] <amee2k> i've got the draft on my other computer, i can show you in a few hours
[12:56:23] <Steffanx> Yeah, 'pile' of connections, but .. i probably wouldn't care about that
[12:57:30] <Steffanx> No remote connection to that pc amee2k ?
[12:58:05] <amee2k> yes, but the box is powered down
[12:59:03] <Steffanx> No wake on lan?
[12:59:57] <amee2k> nope
[13:00:00] <Steffanx> Hmpf
[13:00:03] <amee2k> power strip is turned off
[13:05:41] <atmega> @ amee2k can you show me the schematic of your Power LED-Board?
[13:06:12] <Steffanx> He can't
[13:06:41] <amee2k> sure when i'm back at my desk
[13:07:06] <amee2k> it isn't complete yet though. i still have some minor design issues to work out
[13:07:07] <atmega> okay
[13:07:08] <mapee> evening
[13:07:31] <amee2k> hey there :)
[13:18:34] <fisted> hey there
[13:20:19] <fisted> i'm encountering rather weird problems while trying to do interrupt driven uart communication (rs232 with my pc) on an ATmega16
[13:20:41] <fisted> for testing i've written a simple echo program which reads data and echos it back
[13:21:16] <fisted> for rather slow transmission that works fine, however if i start sending much data the atmega eventually resets, which is odd
[13:21:50] <fisted> i've reduced it to a test case, as good as i could:
http://codepad.org/jz43HMRE
[13:22:33] <fisted> apparently only transmitting or only receiving doesn't make it reset, that's why i couldn't strip away more
[13:24:57] <fisted> oh, also the MCUSR is zero after that kind of reset or crash
[13:25:06] <fisted> i.e. not watchdog, not brownout, etc
[13:25:19] <fisted> not that anything of that would be enabled anyways.
[13:26:02] <vectory> tried with another chip, to see if this ones broken?
[13:27:12] <fisted> oh, forgot to mention that. with another chip things are even worse, i don't even need to really stress it in order to have it 'crash'
[13:27:24] <fisted> well, that was not exactly the same program tho, i better check it again, brb
[13:27:59] <pingec> ".equ UBRR = FOSC/(16*BAUD)-1" How can I check if this value is calculated correctly?
[13:29:01] <amee2k> just for clarification, you're using some kind of RS232 to TTL adapter, right? not feed the RS232 pins straight to the MCU
[13:30:16] <fisted> amee2k: yes, a max232, and yeah, the other chip crashes way earlier, after the very first few transmitted bytes
[13:30:48] <ali1234> pingec: how do you define "correctly"?
[13:30:58] <amee2k> i see
[13:31:07] <fisted> i'm a bit out of spec with the max232, using 10uf caps where i should use 1uf caps. i assume that doesn't hurt, neither do i assume it might possibly cause the atmega to crash, but just saying
[13:31:09] <pingec> I'd like to know the actual value
[13:31:39] <ali1234> pingec: disassemble the generated code... avr-objdump -D whatever.o
[13:31:40] <pingec> hmm I guess I can run inside debugger
[13:32:10] <ali1234> btw, that statement looks wrong to me
[13:32:21] <amee2k> if the crashes only happen when concurrent RX and TX operations are in progress, i'd try guarding the entire uart_recv/send functions in cli/sti() calls
[13:32:23] <ali1234> why are you multiplying by 16?
[13:32:51] <amee2k> uart oversamples by a factor of 16x (or 8x in double speed mode)
[13:33:06] <atmega> I use this:
[13:33:07] <atmega> #define UART_BAUD_SELECT_DOUBLE_SPEED(baudRate,xtalCpu) (((xtalCpu)/((baudRate)*8l)-1)|0x8000)
[13:33:26] <amee2k> so uart clock needs to be 16x the baud rate
[13:33:56] <ali1234> ah ok
[13:34:11] <amee2k> my guts tell me that the reset is happening because some pointer is going wonky, or there is some inconsistency about the rx/tx_count variables and the actual buffer state
[13:35:11] <amee2k> it is rather subtle but the prod_ind and cons_ind variables allready imply the number of bytes in the buffer
[13:35:49] <fisted> amee2k: yeah but using them would lead to races, hence the two volatile counters
[13:36:02] <amee2k> ooh
[13:36:04] <amee2k> err.
[13:36:05] <fisted> and the send and recv functions are actually implemented in a way so that ISR's may well happen without doing damage
[13:36:14] <fisted> but i tried to guard them as you suggested, can't hurdt i guess
[13:36:17] <fisted> hurt*
[13:36:24] <fisted> s/tried/try
[13:36:24] <fisted> meh
[13:36:33] <amee2k> you can still get races because the compiler may cache the prod/cons variables in registers during the uart_* functions
[13:37:06] <fisted> well there are 4 functions (2x ISR and send/recv) and 4 such variables
[13:37:10] <amee2k> so even if the *_count variables are forced to be synchronized, the prod/cons are not
[13:37:17] <fisted> each function is concerned with exactly one variable
[13:37:21] <fisted> concerned as in writes to
[13:37:33] <amee2k> iirc, if you use volatile you don't even need cli/sti to ensure integrity
[13:38:05] <amee2k> the compiler may only read it once from memory into a register, then keep using the value in the register repeatedly
[13:38:25] <amee2k> even if the memory content changes after an interrupt, it would still be using the old value after returning from the ISR
[13:38:35] <amee2k> s/after/during/
[13:38:58] <fisted> oh
[13:39:01] <ziph> Making things volatile doesn't help that all that much.
[13:39:06] <fisted> okay i check this, thanks
[13:39:53] <amee2k> i would try to share as little variables as at all possible between ISRs and regular functions
[13:40:06] <fisted> well, no, i was wrong, they aren't shared at all
[13:40:11] <fisted> in fact they all could be static local variables
[13:40:16] <fisted> (can ISR's have static vars?)
[13:41:00] <amee2k> ISRs are just normal functions. the only difference is that at some random point the regular execution flow will interrupt and a call to the ISR will "pop up" out of the blue
[13:41:21] <fisted> alright
[13:41:21] <amee2k> the compiler cannot know when and usually assumes that such things won't happen
[13:41:35] <fisted> yeah that's why i had to volatile rx/tx_count
[13:43:38] <amee2k> volatile tells the compiler that a variable's value may be changed in background asynchronously to normal execution flow
[13:43:58] <fisted> yeah i'm aware of that
[13:44:06] <amee2k> this means that it won't optimize away memory accesses by caching the value in a register
[13:44:09] <fisted> otherwise it would optimize away loops which wait for my variable to change
[13:44:12] <fisted> exactly
[13:44:28] <fisted> http://codepad.org/Typ1kND2 <- updated my code, the [rt]x_{prod,cons}_ind are now locals
[13:45:45] <amee2k> err, that doesn't make sense. where are you initializing the prod/cons variables?
[13:45:57] <fisted> they are static
[13:46:04] <fisted> i.e. they are inizialized to zero
[13:46:16] <fisted> C defines that
[13:46:17] <amee2k> okay
[13:46:42] <amee2k> i tend to always initialize variables to be sure
[13:47:03] <amee2k> assuming a variable is being initialized where it is not can result in strange things >_<
[13:47:12] <amee2k> hmm i see
[13:49:16] <amee2k> your way of handing buffer overflows isn't too nice. from what i can see it overwrites data at the beginning of the buffer
[13:49:42] <fisted> the rationale behind that is
[13:49:59] <amee2k> the usual expectation is for bytes received while the buffer is full to be skipped. not inserted into the buffer (more or less) randomly
[13:50:07] <fisted> that it is the user's problem if he configures too small buffers or too high data rate for whatever he wants to transmit;)
[13:50:44] <amee2k> true, but in some cases an overflow that simply skips bytes may be harmless
[13:50:54] <amee2k> whereas one that reorders bytes is not
[13:51:03] <fisted> yeah good point
[13:52:04] <fisted> i'm going to try
http://homepage.hispeed.ch/peterfleury/group__pfleury__uart.html
[13:52:08] <amee2k> simply having bytes dropped is also the usual expectation in case of a buffer overflow
[13:55:55] <amee2k> hmm i think i'm running out of wisdom to share at this point
[14:01:55] <fisted> :S thanks anyway
[14:02:43] <amee2k> extending the cli/sti over the whole function didn't help?
[14:03:25] <amee2k> all the array based ring buffer implementations i've written only used the start and end pointers, not the number of elements
[14:03:28] <OndraSter> I was wondering, current SSD drives use serial flash memories (and talk to them in parallel) or normal parallel flash?
[14:04:29] <amee2k> you can parallel parallel memory too to get even wider parallel memory ;)
[14:04:36] <OndraSter> yeah
[14:04:49] <OndraSter> because if you could hook up flash memory through FPGA to SATA directly, like.. FPGA receives instruction "set LBA 123456, read 1000 bytes"
[14:05:00] <OndraSter> if you could send the flash memory "set offset to 123456"
[14:05:02] <specing> Or you can parallel serial memory to get paralleled serial memory ;D
[14:05:08] <OndraSter> and then connect the flash directly to the SATA interface :P
[14:05:19] <OndraSter> with some digital voltage converter ofc
[14:06:39] <ftc> so i am playing with the 16 bit timer on an atmega328p clocked at 16 mhz. According to my calculations, the timer should only be able to count up to .008 seconds, does this sound right? or did I miss something?
[14:08:11] <ftc> maxTime = ((2^16)*2-1)/16E6 ?
[14:08:22] <amee2k> i think you missed the clock prescaler
[14:08:37] <amee2k> i'm getting just over half a second
[14:09:17] <ftc> ah yeah, I guess i should probably not set that to 1
[14:10:30] <ftc> thanks
[14:10:41] <amee2k> you're welcome :)
[14:12:07] <ftc> these chips are still a bit foreign to me
[14:14:33] <amee2k> hey, everyone was a(n avr) noob at some point :)
[14:14:55] <OndraSter> some still are!
[14:15:08] * amee2k . o O ( some will always be... )
[14:15:14] <ftc> the datasheets can be downright confusing
[14:15:18] <amee2k> i didn't think that out loud, did i? :P
[14:15:45] <amee2k> yeh, reading datasheets can be ... interresting sometimes :)
[14:15:58] <OndraSter> ftc, tell me about it
[14:17:47] <OndraSter> I have here datasheet for attiny13a
[14:17:52] <OndraSter> there are -su and -ssu
[14:17:58] <OndraSter> one is small, the other one is smaller
[14:18:06] <OndraSter> but according to datasheet, they are the same width ?!
[14:18:10] <OndraSter> although they are not
[14:18:11] <ftc> TCCR1B |= (1 <<CS10) | (1<<CS12); That should set the prescaler to 1024 right?
[14:19:12] <amee2k> small, smaller, even smaller than flyback's cock
[14:19:49] <ftc> are you referring to the same flyback that frequently terrorizes the sparkfun channel?
[14:20:26] <amee2k> i don't know about the sparkfun channel but there is only one flyback with a suitable rep on freenode that i'm aware of
[14:20:46] <ftc> yeah probably the same guy then
[14:20:56] <amee2k> >_>
[14:23:29] <ftc> woo it works
[14:23:47] <ftc> das blinkenlichten!
[14:24:03] <amee2k> \o/
[14:24:17] <ftc> only now it doesn't occupy the entire CPU while waiting
[14:24:39] <amee2k> hehe
[14:28:02] <ftc> hmm having trouble finding a datasheet for my oscilator
[14:28:19] <ftc> it says spk16.000y
[14:29:06] <ftc> alldatasheet gives me 9 different rectifiers, but i am pretty sure this is a crystal oscillator
[14:29:27] <atmega> @ ftc 16MHz
[14:30:00] <ftc> I was just curious to look at the tolerances though
[14:31:21] <ftc> is it good enough to use for a clock?
[14:32:00] <atmega> sure ... what you want to do?
[14:32:27] <ftc> I am not really trying to do anything but learn about this thing at the moment
[14:33:00] <ftc> its an arduino dumilinove
[14:34:10] <atmega> the frequency is may be 16.001MHz, if you build a clock then you must calibrate it (in this case you must subtract every second a little bit )
[14:35:24] <ftc> ah ok that makes sense
[14:35:39] <ftc> does it vary much with temperature?
[14:36:01] <ftc> would the calibration hold true if I put it in a weather proof box outdoors?
[14:36:09] <atmega> ... I will look at my datasheet
[14:36:37] <ftc> i guess i could find a datasheet for another oscillator and it would likely answer my question
[14:39:47] <atmega> frequency tolerance at 25 °C = +-50ppm
[14:40:02] <atmega> frequency temp. characteristic = +-50ppm
[14:40:20] <atmega> operating temperature = -20 °C ~ +70 °C
[14:40:43] <atmega> aging = < ± 5 ppm
[14:40:53] <ftc> so 1 ms over a day i guess
[14:40:53] <OndraSter> external RTC? :P
[14:41:40] <ftc> gps dongle? :P
[14:42:42] <atmega> you set the clock with "radio-controlled clock" then let the clock running and after one week you can compare it with the "radio-controlled clock"
[14:43:27] <atmega> this are the values of my cristal MG3A with 12MHz
[14:44:46] <ftc> well thanks for the info, i feel like i understand clock sources better now
[14:45:22] <ftc> do you use a real time clock as a clock source for the avr chip or is it something that you would pull the current time from?
[14:45:39] <ftc> ah yeah, the one i just pulled up works on an i2c bus
[14:47:32] <atmega> I don't use a RTC ... I only use a Interrup source in the AVR, and counting up the Time
[14:48:27] <atmega> you want to save energy with the RTC?
[14:48:50] <ftc> again, i don't have a project in mind right now, i am just learning for the sake of learning
[14:49:10] <ftc> can you save energy by using the RTC?
[14:49:16] <atmega> i know
[14:49:24] <atmega> yes
[14:49:28] <ftc> cool
[14:50:00] <ftc> seems like they don't work terribly well for sub second timing though
[14:50:08] <atmega> ... if you use a external RTC
[14:51:50] <atmega> I use DCF77 modules too = "radio-controlled clock"
[14:54:22] <ftc> I was on a project a while back that i seem to recall we used gps to synchronize the clocks on some sensors
[14:54:38] <vectory> external rtc chip still needs crystal in most cases, yes or no?
[14:55:03] <ftc> i would think so, unless they have the crystal built in
[14:55:03] <atmega> 32kHz
[14:56:09] <ftc> ah yeah the DCF77 only picks up the minute/hour/day/month/yr
[14:56:26] <ftc> so that would not work for synchronizing sensor measurements
[14:57:57] <ftc> would be great for this little ice tube clock kit i bought though
[14:59:20] <atmega> ice tube?
[14:59:38] <ftc> http://www.ladyada.net/make/icetube/
[15:00:02] <ftc> VFD display clock
[15:00:14] <ftc> i wanted to make one with nixie tubes until i realized how expensive nixie tubes are
[15:01:02] <atmega> oh take a 7-seg LED display
[15:01:39] <ftc> looks like someone did a gps timekeeping mod for it
[15:01:46] <ftc> http://www.ladyada.net/make/icetube/mods.html
[15:02:41] <atmega> you need high voltage ... and need muche energy
[15:03:05] <ftc> yeah but LEDs aren't nearly as retro
[15:04:13] <atmega> this Bulb is burning out:
http://www.ladyada.net/images/icetube/GPS/gpsback_t.jpg
[15:04:38] <atmega> du you see the Metal on the right side
[15:06:09] <atmega> this is not so pretty ... the dark metal on the glas surface
[15:06:49] <ftc> yeah, mine isn't burnt like that fortunately
[15:07:07] <atmega> you have buy one?
[15:07:15] <ftc> yeah
[15:07:32] <ftc> i have a weakness for odd looking time pieces :-)
[15:07:45] <atmega> :)
[15:07:57] <ftc> i also own the mechanical chronometer out of a cold war era russian MIG fighter
[15:08:11] <ftc> took me forever to figure out how to use it since its all written in russian
[15:08:43] <ftc> unfortunately its not radio luminescent
[15:09:01] <atmega> I must learn russian on school
[15:09:37] <ftc> nice
[15:09:55] <ftc> i learned german back in school then promptly forgot most of it
[15:10:03] <OndraSter> same here lol
[15:10:24] <Steffanx> They teach you russian in germany atmega ?
[15:10:59] <ftc> nowadays the only thing i remember is rock climbing phrases since I was climbing for a few weeks with some german folks
[15:11:13] <keenerd> That is common is east germany.
[15:11:37] <keenerd> Maybe not as much any more :-)
[15:14:18] <ftc> seems like everyone is learning english these days
[15:14:34] <ftc> which is quite convenient for us lazy english speaking countries
[15:15:42] <Steffanx> Uhm, when you Germans go to the Netherlands, we have to speak German
[15:15:50] <Steffanx> When we go to Germany we have to speak German :P
[15:15:56] <Steffanx> So lazy Germans
[15:15:58] <atmega> the most people of the world speak Chinese ... but it is heavy to learn
[15:16:20] <ftc> china speaks several different languages though
[15:16:33] <atmega> yes
[15:16:35] <ftc> Mandarin and Cantonese are the two big ones as i recall
[15:16:47] <ftc> i have a friend who speaks both
[15:16:53] <ftc> blows my mind how you can remember all that...
[15:19:37] <atmega> oh .. it is very late
[15:20:43] <ftc> this conversation makes me want to travel around some more
[15:22:31] <atmega> wait until the Iran war is finished ;)
[15:22:47] <atmega> good night @ all
[15:25:08] <vectory> ♫ war, what is it good for ♫
[15:25:28] <vectory> amee2k: im here now, though i dont really have time -.-
[15:26:10] <ftc> yeah kinda sick of it myself tbh
[15:26:53] <ftc> my country just passed this pretty scary bill allowing the military to indefinitely detain citizens without a charge in the name of "fighting terrorism"
[15:27:09] <ftc> frankly at this point i am more afraid of my government than the stupid "terrorists"
[15:28:11] <vectory> seeing police brutallity on demonstration its clear where the real terror comes from
[15:28:35] <vectory> "to see who came for a riot, see who comes dressed for a riot"
[15:30:26] <ftc> hmm perhaps an #avr-politics channel is in order :P
[15:30:57] <vectory> avr-politics would be politics concerning avrs, no?
[15:31:21] <ftc> or just people interested in avr talking politics
[15:31:38] <vectory> there is #politics
[15:31:59] <vectory> but im not really a political person
[15:32:15] <ftc> i have become more and more of one over the past few months
[15:32:21] <ftc> i don't enjoy it but they terrify me
[15:32:28] <vectory> i just think nonvoters should be accounted for, that way many parties would never gain the "majority"
[15:33:02] <vectory> but nvm
[15:34:11] <ftc> I actually confronted both senators in my state over PIPA
[15:34:33] <ftc> one of them canceled out his meeting with me, the other one I caught at a meeting he had in town
[15:34:47] <ftc> eventually both of them opposed it fortunately
[15:34:51] <vectory> wow
[15:34:55] <vectory> :)
[15:35:14] <vectory> so you're a yankee :D
[15:35:15] <karlp> voting should be compulsory
[15:35:34] <karlp> then people are forced to advertise on real topics, instead of just a battle to get out the vote
[15:36:08] <vectory> shut up
[15:36:11] <vectory> ;)
[15:36:17] <ftc> quiet you! :P
[15:37:08] <vectory> the whole voting process is coruppted
[15:37:13] <vectory> no need to discuss
[15:38:08] <ftc> there is a good book out there called "the rise fall and possible ressurection of science policy" its available in pdf format for free on the web, i highly recommend it
[15:38:26] <ftc> published by the federation of american scientists
[15:38:57] <ftc> i would link it but fas.org seems to be down atm
[15:39:51] <vectory> duly noted
[15:41:08] <ftc> ah here we go, mirror:
http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA524840
[15:41:41] <vectory> ok
[15:42:08] <ftc> i would put it on my own web page but i have no clue what the copyright on it is
[15:44:58] <amee2k> vectory: in the middle of making dinner, you still there in say 30 minutes?
[15:45:28] <vectory> amee2k: sure
[15:45:33] <amee2k> okay
[15:45:41] <vectory> i have no way to go
[15:45:44] <vectory> T_T
[15:45:59] <vectory> :D
[15:47:03] <ftc> can anyone recommend a good online store to buy an avr-dragon from in the US?
[15:48:52] <karlp> mouser/digikey/arrow/farnell aren't suitable?
[15:49:29] <ftc> ah mouser works
[15:49:32] <ftc> didn't realize they carried them
[15:49:40] <ftc> was using google shopping to search
[15:49:57] <karlp> google is not omnipotent. even if they wish they were
[15:50:17] <karlp> you can buy arduinos from mouser&co if you want.
[15:50:28] <karlp> they even resell olimex dev boards
[15:50:54] <ftc> cool
[15:51:11] <ftc> so the avr dragon works pretty will with the oss tools under *nix right?
[15:51:44] <ftc> looks like avrdude supports it
[15:53:16] <ftc> hmm i wonder if i should grab anything else while placing this mouser order
[16:13:14] <amee2k> so, back
[16:13:34] <amee2k> vectory: mmh we stopped at external BOD and Vbe multiplier, right?
[16:13:44] <vectory> hm
[16:13:48] <vectory> BOD, yes
[16:13:56] <vectory> vbe multiplier?
[16:14:24] <amee2k> yeah, it works the same as a TL431 circuit
[16:14:46] <amee2k> http://ompldr.org/vY2cyaw/vref.png << i suppose that doesn't help if you don't know the 431 though
[16:15:36] <amee2k> the basic idea about that circuit is that if the base voltage rises to a diode drop, i.e. ~0.6-0.7V then the base starts conducting and pulls the collector voltage down. which in turn acts to reduce base voltage too
[16:16:07] <vectory> ok
[16:16:29] <amee2k> so the circuit will stabilize at a collector voltage of Vbe * (R2+R1)/R2. hence Vbe multiplier
[16:17:04] <vectory> oh, ok
[16:17:26] <amee2k> the base emitter junction acts pretty much like a diode, i.e. it won't conduct much current until the forward breakdown voltage is reached, then it will rapidly conduct a lot of current without gaining more voltage drop
[16:18:33] <amee2k> http://ompldr.org/vY2cycg/led-cc.png << this is a simple two-transistor constant current driver for LEDs that exploits this effect. current starts to flow through R2 into the base of Q2 which starts to conduct current through the LED and out through R1
[16:19:16] <amee2k> when the voltage across R1 reaches ~0.65V then Q1 starts to conduct too and takes drive current away from the base of Q2
[16:19:50] <amee2k> so the circuit stabilizes with ~0.65V across R1, and the current through R1 is the LED current (plus neglegible base current of Q2)
[16:20:02] <amee2k> that make sense to you so far?
[16:20:24] <vectory> second example yes, to some extend :D
[16:20:35] <vectory> ment to say: using a simple transistor or a fet, that will "block" when voltage is too low doesnt do the trick?
[16:20:42] <amee2k> if you don't know the 431 forget the first one :)
[16:21:06] <amee2k> yeah, that LED circuit was just to illustrate the principle with an example
[16:22:05] <amee2k> http://ompldr.org/vY2cybQ/bod1.png << you can exploit this for a ghetto BOD like this... when the base voltage on the transistor (i.e. voltage across R2) is high enough to turn the transistor on, the reset pin gets pulled high
[16:22:41] <amee2k> R2 and R3 are just a voltage divider and the ratio will set the turn-on point
[16:22:49] <Steffanx> I should learn how to use lt spice..
[16:23:06] <amee2k> http://ompldr.org/vY2cybg/bod2.png << green trace is input voltage, blue trace is reset pin voltage
[16:23:18] <amee2k> yeah, ltspice is handy for quickly drawing schematics :)
[16:24:05] <vectory> Steffanx:
[16:24:10] <vectory> http://www.afrotechmods.com/videos/circuit_simulation_ltspice.htm
[16:24:12] <vectory> :)
[16:24:24] <amee2k> am i still making sense to you? :)
[16:24:30] <amee2k> or going too fast
[16:24:42] * amee2k has a habit of doing that
[16:25:12] <vectory> well, not a problem
[16:25:58] <amee2k> you can do all of the above examples with (enhenchment mode) MOSFETs as well
[16:26:53] <vectory> maybe with a cap from vcc pin to gnd?
[16:26:54] <amee2k> but from what i know, Vth on MOSFETs (which is kind of the analog of Vbe on BJTs) is less well controlled and varies, sometimes significantly, with the exact type and sometimes even with individual transistors
[16:27:26] <amee2k> yeah, i omitted bypassing here for clarity. you'd use this in addition to your normal circuit
[16:28:19] <vectory> why not connect that to vcc directly? would produce weird results?
[16:28:35] <amee2k> connect what to vcc?
[16:29:00] <vectory> the ghetto bod circuit :)
[16:29:10] <amee2k> i don't follow
[16:29:38] <vectory> well, does it make a difference if voltage goes low on rst or on vcc?
[16:29:43] <vectory> want to turn off rst
[16:29:51] <vectory> *maybe
[16:30:07] <amee2k> reset is active-low, i.e. the MCU will start executing code when reset is pulled high
[16:30:13] <amee2k> at least for AVRs
[16:30:18] <vectory> ye
[16:30:35] <vectory> hence the bar over the reset label
[16:30:48] <amee2k> if you have a different type that has active-high reset you'd switch the transistor for an NPN instead of PNP and exchange the rails
[16:31:01] <vectory> oi
[16:31:03] <amee2k> if that is what you meant
[16:31:16] <vectory> no, it isnt
[16:31:18] <vectory> i mean ...
[16:32:00] <vectory> if voltage goes low on vcc, the chip will start acting weird eventually, but if it drops low enough it will just stop, no?
[16:32:42] <amee2k> yes it will. but you don't know where that weird region is exactly (other than that it is below the specified minimum operating voltage of the MCU)
[16:33:27] <amee2k> so if your MCU is specified for 3V-5.5V you could use the BOD circuit on my last screenshot as-is. it releases the reset at ~3.4V which is safe
[16:34:30] <amee2k> this single-transistor circuit is safe in that regard since the transistor cannot conduct until the voltage is high enough and the pull-down resistor keeps the reset pin low otherwise
[16:35:07] <vectory> well, thats not entirely true, as is obvious from the spice diagram
[16:35:28] <amee2k> relying on some voltage to be low enough to be safe that the MCU is completely off (and without a BOD) is a bad idea
[16:35:58] <amee2k> i know, it starts to turn on slightly before that. which is one of the two drawbacks this simple circuit has
[16:36:36] <amee2k> the first one being it turns on slowly and has no hysteresis. both of which can be easily cured if you can afford a second transistor
[16:36:42] <vectory> r1 is the pull down resistor?
[16:36:46] <amee2k> yep
[16:37:31] <vectory> isnt that just acting as voltage devider?
[16:37:48] <amee2k> well, in a way. if you think of the transistor as a variable resistor
[16:38:16] <amee2k> the transistor can only pull the reset pin high, so you need a resistor like that to define a default state if the transistor is turned off
[16:38:37] <amee2k> CMOS inputs are extremely high impedance and will start doing weird things when left floating
[16:39:35] <amee2k> http://ompldr.org/vY2cybw/bod3.png << when the first transistor starts to conduct and the reset voltage rises above ~0.6V then the second transistor turns on too and puts R4 parallel to R3, slightly lowering the turn-on voltage and forcing the first transistor to turn on rapidly
[16:40:47] <amee2k> since the trip voltage is slightly lower now, it will turn off later. this is important. after registering as a brown-out the voltage needs to rise slightly above the previous voltage until the MCU is released again
[16:41:30] <amee2k> this prevents a kind of parasitic oscillation where the MCU being taken out of reset increases current draw and causes a momentary dip in the supply voltage which registers as new brownout and pulls the MCU back into reset
[16:42:54] <amee2k> the second problem that this circuit has is that, while working rather consistently, it is not very precise precise. the transistor's Vbe will change somewhat with temperature and cause proportional changes in the trip voltage
[16:42:57] <vectory> now it gets complicated for me :)
[16:43:00] <vectory> -_-
[16:43:02] <amee2k> hehe :)
[16:44:26] <amee2k> in an application where cost and simplicity are an advantage over precision, that circuit is useful. actually, lots of power supplies used the Vbe muliplier trick for regulation before dedicated reference ICs got dead cheap
[16:45:14] <amee2k> if you need more, the keyword you're probably looking for is power monitor or supervisor. these are dedicated external BODs and can cost anywhere from 50 cent to 10 bucks
[16:45:45] <Steffanx> zlog
[16:46:31] <amee2k> if you're interrested i've got an example schem of a power supply using Vbe mulipliers too?
[16:48:50] <vectory> well, im not sure i would understand it
[16:48:59] <vectory> i doubt it
[16:50:15] <vectory> i think i read sth about powermonitors on mikrocontroller.net before, in a thread with the same problem like mine
[16:50:38] <vectory> someone mentioned to build a simple bod, but not how >_< hence my question
[16:52:09] <amee2k> if it involves "simple" and "building", then i'd expect probably something along the lines of that Vbe multiplier
[16:52:37] <vectory> mentioned caps, too, iirc
[16:52:40] <vectory> the question is, if this external "bod" is saving in comparison to internal BOD
[16:53:10] <amee2k> i'd say not really
[16:53:16] <vectory> :)
[16:53:42] <vectory> how about a diode in reverse?
[16:53:55] <amee2k> mmh connected how?
[16:54:11] <amee2k> whether an external one is an advantage probably depends on how exactly the internal one is insufficient
[16:54:13] <vectory> if voltage is high enough, current will break through, if its too low, the diode blocks
[16:54:39] <vectory> now thats really a newby question
[16:54:43] <amee2k> current yes, but not voltage
[16:54:58] <vectory> voltage drops?
[16:55:09] <amee2k> a zener diode will conduct current in reverse but then the voltage drop is kinda constatn
[16:55:54] <amee2k> lemme make a quick example
[16:57:18] <amee2k> http://ompldr.org/vY2c4bg/zener.png
[16:57:18] <OndraLappy> could be zener used as a voltage limiter for AVR? Considering that the AVR takes few miliamps...
[16:57:34] <amee2k> sure. that approach is called a shunt regulator then
[16:58:37] <amee2k> above screenshot shows how this won't work for the reset pin since the output voltage always "hovers" so-many volt below the supply and doesn't snap high like with the transistor
[16:59:10] <amee2k> you can use the zener together with the transistor, but i don't see the advantage of that really
[16:59:51] <OndraLappy> I am used to use zeners for small currents
[17:00:08] <OndraLappy> usually dropping data lines (SD card anyone? :P) voltage
[17:00:16] <OndraLappy> with some series resistor and 3V3 zener
[17:00:32] <amee2k> ah okay
[17:00:44] <OndraLappy> just not sure how compared on these currents that atmega uses
[17:01:14] <amee2k> yeah, you can use the same approach for regulating supply voltage. but if you need more than a few milliamps you'll likely want a 7805 or 78L05
[17:01:25] <OndraLappy> yeah
[17:01:39] <OndraLappy> I will be probably building small wireless temperature stations
[17:01:54] <OndraLappy> 3.7V battery + attiny13a + NRFL24L01 + DS18B20
[17:02:03] <amee2k> nice :)
[17:02:11] <OndraLappy> gotta check ds for voltage for the DS18
[17:02:15] <OndraLappy> but the NRFL is 3V3
[17:02:48] <amee2k> note that the zener diode kind of regulator will always draw the maximum current from the battery
[17:02:50] <OndraLappy> wondering if I should make really small DC-DC for the battery -> 3V3
[17:02:52] <OndraLappy> yeah
[17:03:01] <OndraLappy> that's main reason for DC-DC :P
[17:03:13] <OndraLappy> most of the time it will be in idle
[17:03:28] <amee2k> that is not very convenient if your circuit spends a lot of time doing nothing because you need to size the resistor on the zener for the maximum load current
[17:03:30] <OndraLappy> I even thought about using MOSFET for disconnecting the NRFL absolutely
[17:03:45] <OndraLappy> from battery
[17:03:48] <amee2k> a 78L05 will draw less from the battery if you draw less from the regulator
[17:04:05] <OndraLappy> gotta check ds how much current will it use in idle
[17:04:09] <OndraLappy> with rx&tx disabled
[17:04:24] <amee2k> OndraLappy: that won't help unless you use a second zener
[17:05:26] <OndraLappy> some "anything to 3.3V" DC-DC will be better choice most likely
[17:05:32] <amee2k> say your battery has 3.7V (which it doesn't, but for the sake of the argument) and your output is 3.3V, so the drop across the resistor needs to be 0.4V
[17:05:38] <OndraLappy> yeah
[17:05:45] <OndraLappy> and the zener will need few mamps
[17:05:57] <amee2k> since R=U/I holds, the resistor current is constant. below the resistor, the current will divide between zener diode and the actual load
[17:06:01] <OndraLappy> constant
[17:06:06] <OndraLappy> yeah
[17:06:18] <OndraLappy> that's why I'd prefer DC-DC
[17:06:31] <amee2k> but all current goes through the resistor, so using power saving modes on the MCU or turning off peripherals is useless since it doesn't conserve battery power
[17:07:05] <amee2k> a 78L05 is a series regulator. that means it'll drop voltage but regulator current == battery current == load current
[17:07:29] <OndraLappy> yeah, I know 7805, burned my fingers few times already
[17:07:41] <amee2k> hehe, who hasn't >_>
[17:07:43] <OndraLappy> but again, it drops voltage, doesn't switch it
[17:07:54] <OndraLappy> DC-DC will have probably better efficiency
[17:08:09] <amee2k> at extremely low currents a linear regulator is actually an effective option
[17:08:34] <OndraLappy> but... won't even LDO need over half volt extra above the desired voltage? :P
[17:08:35] <amee2k> no point in using a switcher that draws 10mA for the control circuitry to feed a 2mA load
[17:09:09] <OndraLappy> atmega can go to few uAmps in idle
[17:09:18] <amee2k> a decent linear reg will have a bias current on the reference pin in the uA region
[17:09:48] <amee2k> some low current LDOs can go down to a few mV actually
[17:09:53] <OndraLappy> I could probably get away with using zener for the NRFL power & SCK & MOSI lines
[17:10:15] <OndraLappy> and switch them off when not needed through external MOSFET (the power line, the other lines just through atmega bring down)
[17:10:22] <amee2k> if the temperature sensors have low enough current you could use a GPIO pin directly to supply them
[17:10:32] <OndraLappy> and power the atmega from the battery directly
[17:10:48] <amee2k> i remember reading an appnote of some 1-wire sensor that recommended that approach actually
[17:10:53] <OndraLappy> yeah
[17:11:31] <OndraLappy> okay, power supply range from 3 to 5.5V
[17:11:33] <OndraLappy> for DS18
[17:12:01] <amee2k> if you put the zener + resistor on the GPIO pin the shunt reg will turn off along with the sensor, which is good
[17:12:24] <OndraLappy> standby for DS -> 1000nA
[17:12:38] <amee2k> nice :)
[17:12:40] <OndraLappy> well, I will make schematics 2morrow
[17:12:54] <amee2k> hmm speaking of schematics...
[17:13:18] <OndraLappy> (I hate MOSFETs for one thing.. you need some voltage difference from D/S to gate... you can't just switch it on/off anytime like relays)
[17:13:20] <amee2k> http://ompldr.org/vY2cybA/linear-psu.png << this is the concept for the linear ghetto PSU schematic with Vbe multiplier, in case anyone is interrested
[17:13:44] <OndraLappy> ghetto PSU?
[17:13:49] <amee2k> yeah >_>
[17:14:09] <OndraLappy> something like similar design but with MAA723 instead R1 and Q6? :D
[17:14:26] <OndraLappy> err, opposite
[17:14:34] <OndraLappy> with R1 and Q6 instead of MAA723
[17:14:46] <OndraLappy> linears have one problem - HEAT DISSIPATION
[17:14:53] <OndraLappy> I have got here some chinese 15V 3A
[17:14:59] <amee2k> just substituting a TL431 for Q4 would hugely improve regulation quality
[17:14:59] <OndraLappy> and it quite burns the output transistor :P
[17:15:09] <amee2k> lol
[17:15:42] <OndraLappy> oh well
[17:15:43] <OndraLappy> I am off
[17:15:45] <OndraLappy> gn
[17:15:50] <amee2k> nighty :)
[17:16:11] <amee2k> hmm and still speaking of schematics, someone wanted the draft for my LED board schematic...
[17:17:35] <ftc> what is asynchronous mode in timer/counter 2 on the datasheet?
[17:17:49] <ftc> *atmega328p datasheet
[17:18:32] <vectory> an external timer, that can still run when the core is powered down
[17:18:42] <ftc> cool thanks
[17:19:18] <vectory> not nessecarilly external iirc
[17:19:53] <ftc> quick powerdown/up... given that at max prescaling it resets every 32 ms
[17:19:55] <vectory> but it can run from async external clock source
[17:20:13] <ftc> at least on the arduino board...
[17:20:49] <ftc> i guess you could run it at a much slower clock rate
[17:21:02] <amee2k> >_<
[17:21:33] <amee2k> both Steffanx and atmega have left :/
[17:21:55] <vectory> well, its late already
[17:22:09] <chron0> waah, I've never had so much bogus highlights :)
[17:22:32] <amee2k> chron0: how so?
[17:22:47] <chron0> asynchronous, chronometer :)
[17:22:49] <amee2k> vectory: well, depends on the timezone i suppose
[17:22:57] <amee2k> ooh, err right
[17:23:21] <amee2k> i remember some dude in ##electronics by the nickname of "ohm" :)
[17:23:23] <chron0> 5th time this eveing already :)
[18:00:58] <AuroraX> EICRA |= (1 << ISC00); // set INT0 to trigger on ANY logic change
[18:00:59] <AuroraX> EIMSK |= (1 << INT0); // Turns on INT0
[18:01:06] <AuroraX> are those comments correct?
[18:01:29] <AuroraX> i tought ISC00 was to enable interruption only if INT0 (pin 2) was set to low
[18:03:59] <vectory> what chip?
[18:04:30] <AuroraX> atmega328
[18:04:57] <vectory> dont have the ds here, maybe you wanna have a look yourself
[18:05:02] <vectory> also check the erratas
[18:05:31] <vectory> no need to read lenthy chapters, search the register definition pages
[18:07:26] <AuroraX> vectory: i read it
[18:07:31] <AuroraX> and it says this:
[18:08:02] <AuroraX> http://i54.tinypic.com/243474j.png
[18:08:20] <AuroraX> where EICRA is this:
http://i55.tinypic.com/33lc803.png
[18:08:44] <AuroraX> i dont understand, i find that table contradictory to the comment about ISC00
[18:09:25] <AuroraX> vectory: i read it
[18:09:27] <AuroraX> and it says this:
[18:09:29] <AuroraX> http://i54.tinypic.com/243474j.png
[18:09:31] <AuroraX> where EICRA is this:
http://i55.tinypic.com/33lc803.png
[18:09:33] <AuroraX> i dont understand, i find that table contradictory to the comment about ISC00
[18:09:54] <vectory> no, comment is right
[18:09:57] <AuroraX> it is?
[18:10:04] <vectory> isc00 is set to one in that line
[18:10:05] <AuroraX> so i dont get the table at all
[18:10:26] <vectory> assuming isc01 is still 0 you have 01 -> any logic change trigers the int
[18:10:32] <AuroraX> from the table i understood that isc00 would interrupt if LOW detected
[18:10:34] <vectory> +g
[18:11:15] <vectory> no, you take iscx1 and iscx0 as a pair and look up the row in the table
[18:11:44] <AuroraX> hmm i see
[18:11:59] <AuroraX> what if eicra is 0x0F?
[18:13:32] <vectory> then you have int0 and int1 triggered according to the last row
[18:14:01] <vectory> rising edge that is
[18:17:15] <AuroraX> hmmm
[18:17:24] <AuroraX> eicra can have 0xff right?
[18:18:58] <AuroraX> so to see if i really understoof it, to generate a interruption when INT0 goes LOW eicra = 0x00 right?
[18:20:46] <vectory> yes
[18:21:00] <AuroraX> nice! thanks :)
[18:24:40] <AuroraX> vectory: im quite confused with other thing, if EICRA lets us set external interruptions (im assuming that they are when we have some PIN set as output and it changes its entry value), so what does PCICR do? Even knowing their full names (of EICRA and PCICR) i cant see what they do differently
[18:25:23] <vectory> sorry, no clue :)
[18:25:41] <vectory> what is the full name?
[18:25:56] <AuroraX> PCINT - PIN CHANGE INTERRUPTS:
[18:25:56] <vectory> do you mean set as input?
[18:26:10] <AuroraX> EICRA - External Interrupt Control Register A
[18:26:31] <vectory> maybe m328 can have interupts for many more pins, but only levelchange interupts
[18:26:39] <AuroraX> i want to have PIN2 set as INPUT, and i want to call an interruption every time PIN2 goes from HIGH to LOW
[18:26:51] <AuroraX> on an atmega328
[18:26:55] <vectory> dont care about pcint then :)
[18:26:59] <AuroraX> but im struggling with this for hours
[18:27:38] <AuroraX> so EICRA is what i want?
[18:29:11] <vectory> ye
[18:30:06] <AuroraX> so what does PCINT do?
[18:31:09] <impulze> isn't pcint pin change interrupt?
[18:31:29] <impulze> i.e.you can select the pins that cause an interrupt when they change
[18:31:35] <impulze> *causes
[18:31:41] <impulze> *it changes
[18:31:45] <vectory> you should read for which pins it is
[18:31:46] <impulze> *pin
[18:31:47] <impulze> :D
[18:31:55] <vectory> i suspect its not concerning pins with in1/0
[18:32:01] <vectory> *int
[18:32:21] <vectory> if im wrong, well sue me :)
[18:32:50] <impulze> will do
[18:33:17] <AuroraX> omg, im confused
[18:33:30] <AuroraX> so with eicra you can select pins to interrupt when they change
[18:33:38] <AuroraX> and with pcint you can select pins to interrupt when they change
[18:33:54] <AuroraX> this is what i understand
[18:34:02] <impulze> eicr is a register to enable interrupts and their behaviour is it not?
[18:34:34] <vectory> right, but as i said, i guess pcint and eicr for different pins
[18:34:56] <impulze> those things are well detailed explained in the datasheet
[18:35:03] <impulze> at least they always were for me
[18:35:25] <vectory> well, more or less ^.^
[18:35:40] <vectory> avrfreaks has a nice threads on errors in the datasheets
[18:37:08] <AuroraX> i read the datasheet and im confused
[18:37:09] <AuroraX> :/
[18:38:08] <vectory> about what?
[18:38:16] <vectory> maybe read a tutorial in parallel
[18:38:43] <AuroraX> yes im going to
[18:50:37] <ftc> how many bits is an int on the avr?
[18:51:03] <Kevin`> ftc: 16
[18:51:21] <ftc> thanks
[18:51:54] <vectory> why isnt it 8, it should be!!
[18:52:04] <vectory> or should i use char?
[18:52:09] <vectory> prolly
[18:52:42] <ftc> you could use a short
[18:52:56] <ftc> i think a short is half the size of an int...
[18:53:10] <ftc> at least on x86 its 16 bits instead of 32
[18:53:19] <Kevin`> uint8_t
[18:53:25] <Kevin`> be specific if you want to be specific
[18:53:44] <vectory> kk
[18:56:14] <vectory> amee2k:
http://www.mikrocontroller.net/topic/30547#new the thread i mentioned
[18:56:22] <ftc> Kevin` : is a long the same as a uint32_t?
[18:56:58] <vectory> amee2k: alsmost the same afaict
[18:57:00] <vectory> :)
[18:57:19] <Kevin`> ftc: dunno, that's why you use those defines in the first place ;p
[18:58:21] <ftc> here we go:
https://ccrma.stanford.edu/courses/250a/docs/avr-libc-user-manual-1.2.5/group__avr__stdint.html
[19:38:29] <BrentBXR_> Who wants to help design a cheap mega8 USB PDI programmer
[19:38:41] <BrentBXR_> using the USBASP hardware
[19:47:36] <Casper> already being made, if not done
[19:51:03] <ftc> doesn't the avr dragon support pdi?
[19:51:20] <ftc> looks like "only on select devices" i guess
[19:54:43] <rue_mohr> BrentBXR_, how cheap?
[19:57:01] <BrentBXR_> 5 bucks
[19:57:19] <rue_mohr> how much is the avr to make it?
[19:57:24] <BrentBXR_> dragon does; it would be nice to have an open-source pdi programmer besides vusb's
[19:57:48] <BrentBXR_> rue_mohr, a USBASP can be found for as cheap as 5 bucks
[19:57:59] <BrentBXR_> shipped
[19:58:18] <BrentBXR_> it does take a small mod
[19:58:30] <BrentBXR_> there is one extra pin on the out header
[19:58:40] <BrentBXR_> you need to connect XCK to it
[19:58:49] <BrentBXR_> actually
[19:58:55] <BrentBXR_> hm
[19:59:09] <BrentBXR_> well yea, for developing i guess
[19:59:39] <BrentBXR_> down the line it would be best to connect RX and TX to one line; and run XCK out of the newly freed header
[20:00:13] <rue_mohr> oh you want to 1:1 mod, like just the firmware
[20:00:35] <rue_mohr> ask tom what his uses
[20:00:46] <BrentBXR_> that would be nice but I dont know of any USBASP devices that output XCK
[20:00:49] <BrentBXR_> tom uses VUSB
[20:01:23] <BrentBXR_> infact i would be happy xing all that on-board usb crap and using a MSP220 or FTI232
[20:01:35] <rue_mohr> whats wrong with vusb?
[20:01:48] <BrentBXR_> then the firmware could be dedicated to just the programming and communication aspects
[20:02:01] <Kevin`> BrentBXR_: why do you need extra header pins? pdi needs less pins than isp
[20:02:22] <BrentBXR_> doesnt vusb use one of the usb enabled avrs? nothings wrong with it
[20:02:37] <BrentBXR_> Kevin`, then the USBASP can still have ISP
[20:02:42] <Kevin`> BrentBXR_: v-usb is SOFTWARE usb, the point is to let you use a cheap avr that doesn't have usb
[20:02:43] <BrentBXR_> pdi only needs two pins
[20:02:56] <Kevin`> BrentBXR_: why not use the isp pins for pdi too?
[20:03:08] <BrentBXR_> because you need USART
[20:03:16] <BrentBXR_> unless u want to make it software usart
[20:03:23] <BrentBXR_> pdi is nothing more then USART
[20:03:29] <BrentBXR_> from what i have read thus far
[20:04:09] <Kevin`> since pdi is synchronous, why not go with the cheaper option of avoiding the extra usb transceiver chip?
[20:04:17] <BrentBXR_> i perfer the other big USB for avr
[20:04:22] <BrentBXR_> cant think of its name at the moment
[20:04:45] <BrentBXR_> like i said; i would perfer to x the usb support and get a fti232
[20:05:01] <Kevin`> that will close to double the cost though
[20:05:05] <BrentBXR_> not that its that important only because i would like the source to be open source and be able the pdi capabilities
[20:05:09] <BrentBXR_> not usb
[20:05:16] <BrentBXR_> not really
[20:05:20] <keenerd> Just found an 8 pin DIP that costs $200. Only thing special is that it'll keep on working through 200°C.
[20:06:07] <BrentBXR_> sweet
[20:06:11] <BrentBXR_> buy it
[20:06:12] <BrentBXR_> :D
[20:06:18] <BrentBXR_> what is it
[20:06:38] <keenerd> Ahttp://www.analog.com/static/imported-files/data_sheets/AD8229.pdf
[20:06:51] <keenerd> Still looking at instrumentation amps :-)
[20:07:10] <BrentBXR_> oh :D
[20:07:12] <BrentBXR_> any luck
[20:07:36] <chupas> Is there any reason to believe that an optical encoder wont work at 3.3V when the data sheet calls for 5V?
[20:07:40] <keenerd> Thinking I am going to have to make my own from a high end general purpose op amp and 0.1% resistors.
[20:07:58] <BrentBXR_> there is a small reason
[20:08:11] <BrentBXR_> the datasheet calls for 5v's other then that... :D
[20:08:18] <BrentBXR_> just fuckin with ya, i have no idea
[20:08:45] <BrentBXR_> oh VUSB is the one I like;
[20:08:53] <chupas> i guess if the IR led dose not operate at that low voltage
[20:08:58] <BrentBXR_> i was thinking the one by abcmini
[20:09:00] <chupas> is the only thing i can think of
[20:09:08] <chupas> they dont make 3.3 photo cells i the problem!
[20:09:16] <chupas> err 3.3 encoders
[20:09:49] <BrentBXR_> are you sure
[20:09:56] <Kevin`> BrentBXR_: the one from abcmini (lufa) is designed to work chips that have hardware usb
[20:10:23] <BrentBXR_> ah, that was my mix up. I was thinking LUFA.
[20:11:39] <BrentBXR_> chupas, i just found a bunch of 3.3v op encoders on digikey
[20:11:44] <BrentBXR_> just use there search
[20:11:51] <BrentBXR_> parametric search
[20:11:55] <BrentBXR_> parametric?
[20:11:56] <chupas> I am! i cant find any
[20:12:00] <chupas> they are all 5 for me
[20:12:03] <chupas> what am i doing wrong
[20:12:43] <chupas> under sensors right?
[20:13:20] <chupas> right when i filter for 3.3, it ruturns nothing. Its the first thing i try to filter
[20:13:22] <BrentBXR_> maybe your right they all look to be non-stock
[20:14:27] <chupas> ill just have to get a mech i guess
[20:15:31] <BrentBXR_> chupas,
[20:15:38] <BrentBXR_> there is 1
[20:15:48] <BrentBXR_> 6.60$
[20:15:52] <BrentBXR_> http://www.analog.com/static/imported-files/data_sheets/AD8229.pdf
[20:15:56] <BrentBXR_> on mouser
[20:16:44] <BrentBXR_> anyone know that site that searches digikey, mouser, element14,...
[20:16:50] <BrentBXR_> i cant remember what its called
[20:18:08] <BrentBXR_> octopart
[20:18:09] <BrentBXR_> http://octopart.com/partsearch#search/requestData&q=optical+encoder&rangedfilters%5Bsupply_voltage_dc%5D%5Bmin%5D=2.7&rangedfilters%5Bsupply_voltage_dc%5D%5Bmax%5D=4
[20:18:10] <vectory_> http://i.imgur.com/xx4we.png offtopic, but i lol'ed
[20:18:26] <BrentBXR_> lol
[20:19:13] <BrentBXR_> chupas,
http://octopart.com/partsearch#search/requestData&q=optical+encoder&rangedfilters%5Bsupply_voltage_dc%5D%5Bmin%5D=2.7&rangedfilters%5Bsupply_voltage_dc%5D%5Bmax%5D=4 theres a few from a few differnt distributors
[20:20:31] <chupas> intresting
[20:20:49] <chupas> thanks
[20:21:40] <BrentBXR_> woop woop mah signal integrity board is almost finished
[20:22:20] <BrentBXR_> be able to use it as a nice little FPGA development board once im done testing the differnt senarios for trace issues too
[20:22:51] <BrentBXR_> FPGAs are just mean little ics
[20:23:12] <vectory_> didnt know that
[20:23:23] <BrentBXR_> rude
[20:23:27] <BrentBXR_> rude little ics
[20:23:45] <vectory_> at least with fabbed experimentation boards that should be a non issue?
[20:23:49] <BrentBXR_> im not your teacher
[20:24:01] <BrentBXR_> whats that trace issues?
[20:24:21] <BrentBXR_> if there well tested and developed right they shouldnt
[20:24:27] <BrentBXR_> but theres no guarentee
[20:24:51] <vectory_> i mean spartan boards, e.g.
[20:25:35] <BrentBXR_> oh im sure those are developed quite proper. the board im talking about was designed with multiple trace 'issues' and is a private project
[20:25:43] <BrentBXR_> not a commercial project
[20:25:54] <BrentBXR_> designed on purpose that is
[20:27:51] <BrentBXR_> the goal is i will be able to run this FPGA at any speed/other variable i wish through these placed issues to see if they affect a current project
[20:28:36] <BrentBXR_> for example if I run a 40Mhz and send SPI through traces that do not match in size, will it affect anything?
[20:29:13] <vectory_> uhu
[20:29:20] <vectory_> experimental idd
[20:29:25] <BrentBXR_> exactly
[20:29:49] <BrentBXR_> but it also has everything needed to run the FPGA including a programming interface/rom to hold the bitstream and load it
[20:30:04] <BrentBXR_> so when im not testing with it i can use it as a fpga development board
[20:30:07] <BrentBXR_> for other things
[22:21:35] <TeknoJuce> karlp, Not sure if it was you that I was asking about usb interface with the rigol on 64bit, Just got it in the mail today and it's working in Win7-64bit!
https://skydrive.live.com/#cid=54CE46589EFC4437&id=54CE46589EFC4437%21761
[22:21:51] <TeknoJuce> 2 month wait! :D
[22:26:20] <TeknoJuce> the case is really nice was expecting it to feel cheap.
[22:31:06] <Roklobsta> i am using rigol ds1052e on win64 too and it's nice. but ultrascope is cheesy
[22:31:36] <Roklobsta> look here:
http://www.cibomahto.com/2010/04/controlling-a-rigol-oscilloscope-using-linux-and-python/
[22:33:23] <TeknoJuce> meh does the job!
[22:33:55] <Roklobsta> does your lcd flicker?
[22:34:03] <Roklobsta> like a white flash every 10min or so?
[22:34:33] <TeknoJuce> do you mean all the time or just when pluged into usb and running ultrascope?
[22:34:52] <TeknoJuce> I see no flicker either way just to note
[22:35:11] <TeknoJuce> running f/w 2.06
[22:54:08] <TeknoJuce> Roklobsta if you are running 2.05 it is a known issue if not no idea why it would be doing that
[23:00:25] <Roklobsta> yeah ok so 2.06 doesn't do it. have you upgraded to 100MHz?
[23:02:05] <TeknoJuce> Yes very easy
[23:02:10] <TeknoJuce> give it a go
[23:03:05] <TeknoJuce> Roklobsta apparently you can use the higher f/w as well and make it 150MHz
[23:03:21] <TeknoJuce> they said the limit of the h/w is 170MHz
[23:04:44] <TeknoJuce> I grabbed 100MHz probs maybe I should have went with the 200MHz ones to test that out
[23:06:51] <Roklobsta> what higher f/w? 2.06 or fw for another model?
[23:06:57] <TeknoJuce> Roklobsta heres a package of all the f/w if you dont have it already
http://www.mediafire.com/?89qmofj54tgw7ak
[23:07:24] <TeknoJuce> Roklobsta, another model
[23:09:36] <TeknoJuce> any 1000E series you can swap the f/w between them.
[23:11:54] <TeknoJuce> 150 MHz DS1152E
[23:14:14] <Casper> I'ld like a rigol awg
[23:35:54] <TeknoJuce> Casper what would you use it for?
[23:36:13] <Casper> make and test circuits :D
[23:36:59] <TeknoJuce> you cant do that now with out a waveform generator?
[23:37:25] <Casper> you can, but when you do need a waveform... it's a pita
[23:38:08] <TeknoJuce> theres none that are like 1/50th of that price that would suffice?
[23:39:04] <Casper> sadly, nope
[23:39:49] <TeknoJuce> what we're you working on when you need one last?
[23:41:17] <Casper> many projects.. sure a standard one would have worked
[23:41:19] <Casper> but...
[23:41:26] <Casper> it's still 200$ for an ok one
