Back
[07:45:25] <Sandcat> thanks for all the help last night, eventually got it up and running!
[07:52:14] <LeoNerd> Does anyone know what memory technology ATmega/ATtiny chips use to implement the fuses?
[07:52:38] <LeoNerd> I've heard suggestion that they might be E²PROM or somesuch, with far fewer write cycles than the rest of the chip, being in flash
[09:14:02] <Valen> i believe it is eeprom LeoNerd
[09:14:06] <Valen> in general
[09:14:38] <LeoNerd> Hmm.. what does that imply for write cycles, then?
[09:14:50] <LeoNerd> I mean.. am I allowed tens, hundreds, ... millions?
[09:15:13] <Valen> what are you trying to do?
[09:15:26] <Valen> I'd guess in the hundreds
[09:22:38] <LeoNerd> I'm just interested to know e.g. how often I can reburn the fuses in an ATtiny to change the RESET behaviour
[09:25:24] <sstraw> Have you checked the datasheet?
[09:30:22] <sstraw> I scavenged a bunch of ATTiny SMD uCs from some gear I came across at a computer recycler. Had to put together a high voltage fuse resettter, but they work.
[09:30:52] <sstraw> Not that they'd have cost that much to buy, but it was the principle of recovering useful parts...
[09:35:29] <LeoNerd> Yes; I'm aware of fuse resetters. I'm building a complete HVSP programmer, not just a fuse resetter
[09:35:35] <LeoNerd> I actively -want- the RESET fuse disabled
[09:45:10] <sstraw> That's fine. More often, people want to erset them so that they can reprogram the device conventionally, then tweak the fuses again.
[09:46:11] <sstraw> I haven't seen any specific docs explaining what memory technology the fuse bits are actually comprised of.
[09:49:26] <spillere> I have 3 button that triggers 3 functions via interrupt. I have to detect one press or two fast presses. Any idea?
[09:53:14] <sstraw> are buttons on individual I/O pins, or multiplexed using say, resistors?
[09:53:38] <sstraw> by one press or two fast presses - are you talking same button, or different buttons?
[09:54:33] <sstraw> That is, do you need to detect A-A or A-B ?
[09:55:05] <sstraw> A-A is more difficult, because you have to implement "debounce".
[09:56:07] <sstraw> A-B is difficult only if you're multiplexing and one of the buttons is still depressed when the second one is pressed.
[09:57:03] <sstraw> Generally, if the buttons are separate I/O, set up ISRs, and set button state variables when processing the ISR.
[09:57:19] <sstraw> Then in your program loop, check the state variables and act accordingly.
[09:58:27] <sstraw> You could have a button "queue" (or ring buffer) into which the button "events" are placed, which allows for registering that "A" was detected as pressed, then "B", then "A" again, etc
[09:59:22] <sstraw> You could have a single ISR that when triggered reads the states of all the button inputs and sets variables accordingly.
[10:00:07] <sstraw> OR, you could pose a question and then not say anything afterwards...
[10:01:06] <sstraw> Yea, I'm going with that last one.
[10:03:19] <spillere> im making a programmable guitar pedal. the idea can be studies with one button. when I press the button once, it load into a digital potentiometer the value from the eeprom. if i tap twice it read the values from potentoiometer and save them on the eeprom.
[10:03:40] <spillere> oh, let me try one thing
[10:09:44] <sstraw> So "fast" isn't very.
[10:10:14] <sstraw> is it ONE button that does three things depending on how you tromp it?
[10:11:09] <sstraw> If so, then you start a button sense when the button is first triggered, and monitor it for 'x' mSec for changes.
[10:12:16] <sstraw> I multiplex a single button during initialization - if it's active at boot, then not later, I'm in one mode, active + active, another, not active, then active, ...
[10:13:32] <sstraw> Of course, you could have two switches in your pedal box - one that actuates on a light press, the other when fully mashed. When the second is pressed, it's a given that the first is.
[10:17:09] <sstraw> Not having a guitar pedal here, I can't say how difficult it would be to mod it to have a second switch (or if you can just order them up that way). I do have pedal switches, though they're just on-off.
[10:18:32] <sstraw> How usual would it be to run a pedal swich where you tap it quickly, versus holding it during the period where the effect is desired?
[10:20:05] <jeremyabel> well most pedals are on/off
[10:20:06] <spillere> sstraw the thing is that the button triggers a function in interrupt
[10:20:11] <jeremyabel> toggle
[10:20:21] <spillere> but this is a programmable pedal
[10:22:24] <spillere> http://pastie.org/9587990 the code is working
[10:23:23] <spillere> but the first press overwrites the pot position
[10:23:44] <spillere> ill try to set another array for those :)
[10:27:05] <sstraw> take 'x' time after first press to see if a second press happens. only after that time has elapsed, clear the flag that says there was a button press and go set the digital pot.
[10:27:39] <sstraw> If a second press occurs within 'x' time after the first, go do your store operation.
[10:30:08] <sstraw> went to check url, irc client crapped.
[10:30:23] <spillere> ops, sry hehe
[10:31:09] <sstraw> not your URL, my IRC client.
[10:31:19] <sstraw> What's the '0' value that's used multiple times?
[10:32:00] <spillere> I have 3 buttons, this means it will save data to the first button
[10:32:35] <sstraw> Do the buttons do the same basic operation?
[10:32:42] <spillere> yes
[10:32:48] <spillere> im using interruption on falling
[10:33:01] <sstraw> Pass the button number as a parameter to the Foot(): Foot( int FootNo )
[10:33:10] <sstraw> then use that within the code.
[10:33:29] <sstraw> unsigned int. Mo' better
[10:33:30] <spillere> attachInterrupt(0, foot(1), FALLING);
[10:33:37] <spillere> ill try that
[10:34:14] <spillere> but still have to fix the two press option
[10:34:21] <sstraw> That obviously has nothing do do with the debounce handling, but it'll result in leaner code and easier to read.
[10:34:35] <sstraw> Plus, you fix code in ONE function, not multiple copies.
[10:34:46] <spillere> i know :)
[10:34:59] <spillere> yeah it has nothing with debounce, Im using hardware debouce
[10:35:03] <spillere> debounce
[10:36:31] <sstraw> What is b1press initialized to, and why not clear it after doing your Load?
[10:37:21] <sstraw> that is, init bPress[n] = 0 during initialization (for each button).
[10:37:51] <spillere> the code starts with 0 before the loop
[10:38:17] <sstraw> then in Foot(n), if (bPress[n]), handle as a second pressing, otherwise handle as a first and initialize bPress[n]=millis()
[10:41:50] <sstraw> in your main loop, you'd need to call a related Foot function to check for button expiry. if bPress[n] is set and exceeds your delay, then it's a 1-press (and clear the bPress[n] to 0). In the Foot(n) function, you can catch the second pressing - simply if bPress[n] is non-zero, it wasn't _cleared_ at the end of the window, so it's a 2-presser.
[10:42:28] <sstraw> This isn't necessarily ideal structure - using timers would be better.
[10:44:31] <sstraw> Technically then, your uC could go to sleep between presses, and the timer only needs to be set up after a first button press, and is disabled once there are no active button operations.
[10:45:00] <spillere> yeah, let me try here. thanks :)
[10:45:26] <sstraw> Does what I laid out make sense to you?
[10:45:31] <spillere> yes
[10:45:59] <sstraw> Also, what's with the eeprom[24] ?
[10:46:40] <sstraw> use a DEFINE or constant as the base address of the eeprom for your stored settings.
[10:46:42] <spillere> its an array, which store which pedal button was pressed
[10:47:11] <spillere> im doing like: int eeprom[26];
[10:47:17] <sstraw> eeprom[BUTTONPRESSINDEX+n]
[10:48:43] <sstraw> above your code, have const unsigned int BUTTONPRESSINDEX = 24; // first location of stored potentiometer readings, one byte per button
[10:50:06] <sstraw> presumably you'd have code to read an actual pot value, because 0 doesn't look like you read it from anywhere <g>
[10:50:08] <spillere> got it
[10:50:16] <spillere> why? just to make it more readable?
[10:52:01] <sstraw> more readable, more portable to future changes, more extensible (perhaps you'll have muliple settings per button - you could make it a structure).
[10:52:27] <spillere> yeah
[10:52:31] <spillere> that was a good idea, thanks!!
[10:52:37] <sstraw> Some day, you or someone else will be updating this code, and going, "now what is the significance of this "24" value?"
[10:53:12] <sstraw> I'm a staff engineer doing embedded development. Magic numbers are a no-no.
[10:53:24] <spillere> huahhahau agreed!!
[10:53:37] <spillere> where do you work?
[10:57:15] <sstraw> Enphase Energy
[10:57:45] <sstraw> grid-tied microinverters. Has to work right, or bad things happen...
[10:58:29] <spillere> yes!
[10:59:03] <sstraw> AVR stuff though is just tinkering about at home.
[10:59:24] <sstraw> gotta go though. Have tun
[10:59:26] <sstraw> fun
[10:59:33] <spillere> thanks for the help!
[12:03:56] <sstraw> LeoNerd - I noted that the ATinyX4 datasheet made reference to "Flash fuse bits".
[12:04:23] <LeoNerd> Ah.. hmmmm
[12:04:27] <LeoNerd> A hint there perhaps
[12:06:27] <sstraw> Also, fuse bits are "0" when programmed, and "1" when unprogrammed. Flash typically formats to "FF" for byte values.
[12:07:51] <sstraw> there's a comment that the status of fuse bits is not affected by chip erase.
[12:09:12] <sstraw> Elsewhere (table 19-11) there's a minimum wait delay for flash, eeprom, erase, and fuse.
[12:09:26] <sstraw> fuse and flash are both 4.5ms, different from the other values.
[12:11:39] <sstraw> So, the implication is that the fuses are most likely based on flash technology.
[12:14:12] <LeoNerd> Mmmmm
[12:14:17] <LeoNerd> Yeah that does suggest it then
[17:42:54] <LeoNerd> Mmm.. I just made my AVR HVSP programmer a /liiiiiitttle/ bit faster.. like; about 28 times faster. :)
[17:43:16] <LeoNerd> Turns out that writing all 22 bytes out the serial port then waiting for 22 to come back is a little bit faster than operating a one-in-one-out policy
[17:43:19] <LeoNerd> Who'd have guessed? ;)
[17:43:58] <LeoNerd> (And yes; it really does take 22 bytes of control out to the Bus Pirate /per byte/ that I want to write to the AVR)
[18:03:19] <Casper> LeoNerd: usb-serial adapter?
[18:04:31] <Jartza> avr hvsp out of bus pirate?
[18:04:40] <Jartza> I just found out I have two bus pirates
[18:06:44] <LeoNerd> Casper: Mm? Bus Pirate... uses an FTDI internally yes
[18:11:32] <Casper> that is the reason why it's so slow
[18:12:29] <Casper> chance is that if you do it in 23/21 bytes (as in send 23 then send 21, for the equivalent of 2x 22) then it might just not work
[20:26:13] <mheld> anybody here use any really good gps/gsm modules?
[20:27:49] <jeremyabel> just bluetooth experience here
[20:29:29] <N1njaneer> Just GPS experience.
[20:31:05] <jeremyabel> no bluetooth N1njaneer?
[20:32:16] <N1njaneer> I will for this next project. :)
[20:33:22] <jeremyabel> if you're still shopping for modules, I can recommend this one:
http://www.microchip.com/wwwproducts/Devices.aspx?product=RN42
[20:34:28] <N1njaneer> Client has actually called out specifically what chips they want us to use :)
[20:34:40] <jeremyabel> huh, there ya go then
[20:35:00] <jeremyabel> did they make good choices, do you think?
[20:35:01] <N1njaneer> Especially because we have deep technical connections to all of the respective companies whose parts need to be used in this design.
[20:35:08] <jeremyabel> ah
[20:35:38] <jeremyabel> is that common in your field, to have a client specify which specific chips they want to use, or is this a special project?
[20:35:43] <N1njaneer> So far so good from reviewing things. Ask me in two months once I've layed out PCBs and brought them up and I'll see how much I'm cursing them. :)
[20:35:51] <jeremyabel> heheh
[20:36:12] <N1njaneer> This is very special. Normally all hardware design is up to me, and I use the stuff I know I can make work and have a good track record with.
[20:37:02] <N1njaneer> The customer is always right. Until they are wrong. Then it's VERY wrong. :)
[20:37:08] <jeremyabel> I assume the rest of the details are all secrety?
[20:37:31] <N1njaneer> Yeah, regrettably.
[20:37:37] <jeremyabel> is it a cool project?
[20:38:47] <N1njaneer> It is, yeah.
[20:38:52] <jeremyabel> that's good at least
[20:39:49] <N1njaneer> I honestly don't take on uninteresting projects. Too hard to stay motivated to do an excellent job at. :)
[20:40:20] <N1njaneer> It's easy to do crappy engineering on something you don't care aboue.
[20:40:28] <jeremyabel> it's rad that you get the opportunity to pick!
[20:40:55] <N1njaneer> And this particular project is a significant redesign of some previous crappy-rushed engineering for a deployment that was... sub-optimal. :)
[20:41:06] <jeremyabel> ahh, ok
[20:42:42] <N1njaneer> So at least the bar is very much set already for what to exceed.
[20:54:29] <mheld> anybody wanna critique my code?
[20:54:32] <mheld> it's really bad
[20:54:35] <jeremyabel> sure
[20:54:44] <jeremyabel> send 'er on over
[20:54:46] <mheld> http://pastie.org/private/pg14fb9sviajbu5mrdyewq
[20:55:03] <jeremyabel> whoa it's big
[20:55:25] <mheld> hah yeah
[20:55:42] <mheld> I *should* move stuff out into different modules
[20:56:14] <jeremyabel> yeah, a good plan
[20:57:02] <jeremyabel> use longer names for things
[20:57:09] <jeremyabel> I can't guess what TM_LTCY means
[20:57:20] <jeremyabel> the compiler will optimize names for you, you don't need to shorten them yourself
[20:57:41] <jeremyabel> are those vars at the top constants?
[20:57:52] <jeremyabel> they seem to be like, buffers you're only filling with one thing?
[20:58:04] <jeremyabel> that you aren't even using anywhere else?
[20:58:12] <jeremyabel> like PULSE_TRG is only used there
[20:58:45] <mheld> jeremyabel: so, I don't actually know what those TM_LTCY things are -- they're appendages from when I took over the project
[20:58:50] <jeremyabel> oh
[20:59:04] <jeremyabel> kill 'em, they're not used anywhere
[20:59:16] <jeremyabel> they're just defined up there and they sit, so they probably throw warnings
[21:00:34] <jeremyabel> good, proper link to the GPS data docs
[21:00:45] <mheld> that shit is magic
[21:00:54] <jeremyabel> yeah it looks it
[21:00:57] <N1njaneer> Looks pretty good to me! You can collapse the entirety of your digToAscii function to a single line, though if you wanted to make it smaller. -- "return (num >= 0 && num =< 9) ? ('0' + num) : '0';" :D
[21:01:17] <jeremyabel> jeez I'm only like 100 lines in!
[21:01:27] <mheld> N1njaneer: also magic :-P
[21:01:42] <jeremyabel> lol don't rely on code that you think is magic :P
[21:01:48] <N1njaneer> "coordenates" variable is spelled wrong :)
[21:01:53] <mheld> it's not really magic just clever
[21:01:57] <mheld> and makes sense
[21:02:05] <N1njaneer> That's not quite what I'd call magic. :)
[21:02:19] <jeremyabel> :P
[21:02:21] <mheld> N1njaneer: are those the ascii character codes?
[21:02:33] <mheld> 01 -> ASCII 1?
[21:02:57] <jeremyabel> is that in hex?
[21:02:58] <jeremyabel> 0x01?
[21:03:18] <mheld> 0x01 in ascii land seems to be different
[21:03:25] <N1njaneer> Fine -- "if(num >= 0 && num =< 9) { return '0' + num; } else { return '0'; }" -- if the trinary operator is too scary :)
[21:03:38] <jeremyabel> aw but people need to learn to love the trinary operator!
[21:03:39] <mheld> OH
[21:03:42] <mheld> that's what it does
[21:03:49] <mheld> '0' is the hex value
[21:03:49] <jeremyabel> :D lightbulb moment?
[21:03:55] <N1njaneer> If you need to convert ASCII and numerics, you can just use something like 'A' as equivalent to 65.
[21:03:56] <mheld> and it just increments by the digit
[21:03:56] <jeremyabel> 0 is a char
[21:03:56] <mheld> smart
[21:04:32] <N1njaneer> So for instance if you know your char is A-Z, you can simply subract 'A' from it to convert alphabet letter straight to a numeric. They are all ASCII on the back-end.
[21:05:50] <N1njaneer> In fact, because people were smart when they designed ASCII, if you can guarantee the digit is in the 0 - 9 range in ASCII, you can just mask the bottom four bits and convert straight to the numeric. ASCII '0' is 48 -- binary 00110000 :)
[21:06:04] <jeremyabel> oh neat
[21:06:07] <jeremyabel> never knew that
[21:06:15] <N1njaneer> Anyhow, that's just a slight side-note. But it can be useful, and sure can save a lot of space over a large switch table :)
[21:08:12] <N1njaneer> Additionally, 'A' starts at 65 and 'a' starts at 97, so again you can just mask off the upper bits to instantly handle upper and lower-case automatically, and convert them to an appropriate numeric value. Just have to make sure you have range-checking or non A-Z/a-z characters will cause unpredictable results for what you are doing :)
[21:08:52] <N1njaneer> mheld: Beyond being all in one single file, the overall code quality and style looks pretty darn good to me at cursory glance. Nice job. :)
[21:09:04] <mheld> hah
[21:09:06] <mheld> it makes me cry
[21:09:11] <mheld> but thanks
[21:09:33] <N1njaneer> It could be better organized, but it's pretty readable and easy to follow what's going on.
[21:10:39] <N1njaneer> I also like that you use leading { on the ends of the lines that start the blocks. I HATE code that goes to a nice line just to add the { to start a block, and that's the only thing the line has. Makes the program get huge in a hurry for no benefit and harder to follow by virtue of being able to view less code on the screeen at once.
[21:11:31] <jeremyabel> I add the line only in certain circumstances
[21:11:44] <N1njaneer> jeremyabel: Same :)
[21:12:02] <N1njaneer> mheld: Considering the single-file nature, this looks pretty darn clean to me.
[21:12:04] <jeremyabel> after functions, or conditionals / loops that might be like, more than 15 lines or so
[21:12:16] <jeremyabel> places I'd want to put a line break anyway just for readability
[21:12:23] <jeremyabel> classes, etc
[21:26:08] <mheld> thanks guys :-)
[21:26:15] <mheld> makes me feel less mentally challenged
[21:52:35] <N1njaneer> Sure thing. It's just the truth!
[22:09:38] * Sandcat is baffled by a function, trying to look it up leads to a #define which leads to another #define
[22:10:27] <jeremyabel> 4ewwww
[22:11:23] <Sandcat> " #define OCR1A _SFR_MEM16(0x88) " This returns two bytes of memory from address 0x88 ?
[22:12:21] <Sandcat> am I even close to understanding that?
[22:14:26] <Sandcat> wait, OCR1A is a register? I really don't know what this is supposed to do then.
[22:19:27] <jeremyabel> =yeah
[22:19:39] <jeremyabel> it defines the OCR1A keyword as the right register
[22:19:50] <jeremyabel> so then you can use OCR1A instead of that obscure MEM16 thinger
[22:22:13] <Sandcat> oh, then this function doesn't compare didly squat. It sets the value of a register.
[22:22:39] <Sandcat> It's so obvious, thats why they names it setTimer1Compare
[22:23:39] * Sandcat adds comments
[22:23:58] <Sandcat> I swear I will fully comment all my programs forever after this crap.
[22:24:05] <jeremyabel> :D
[22:33:25] <Sandcat> I've got a function that I'm modifying, but I can't figure out what calls the function. the function IS being called, It behaves differently when I change it. But it isn't triggering at the right times. However, so far as I can tell by the code, it is never called at all!
[22:35:19] <Tom_itx> called by a library?
[22:35:30] <Tom_itx> called by a macro?
[22:36:02] <Tom_itx> actually not sure you can do that
[22:36:46] <Sandcat> The only reference to it I can find outside of the function definition is this: MIDI.setHandlePitchBend(HandlePitchBend); // HandlePitchBend is the function I'm modifying
[22:36:55] <Tom_itx> that #define OCR1A looks like something that would be in the device header file
[22:36:58] <Sandcat> But I don't understand that that line is doing either
[22:37:20] <Tom_itx> c++ ?
[22:37:22] <Valen> perhaps the paticular chip had that in a weird spot
[22:37:23] <Sandcat> Tom_itx: I figured out what OCR1A is about, it's part of the built in PWM functon of the atmega328
[22:37:27] <Valen> thats happened to me a few times
[22:37:35] <Sandcat> Tom_itx: c++ yes.
[22:37:41] <Valen> or it wasn't in the lib
[22:38:07] <Tom_itx> i know what OCR1A is..
[22:39:10] <Sandcat> I didn't until 5 minutes ago.
[22:39:21] <Sandcat> sorry if that came out wrong
[22:39:21] <Tom_itx> are you reading HandlePitchBend from a SD or something?
[22:40:05] <Sandcat> SD?
[22:40:16] <Tom_itx> i never quite understood the need for c++ on �Cs
[22:40:25] <Tom_itx> secure digital card
[22:40:51] <Casper> rue_mohr: My father is converting his oil fired furnace into electric. It require 240V 75A (so 100A breaker). He plan to use some aluminium wire, but I hear it wasn't legal in home. However it seems to be fine for such big cables... Is it allowed? Also, Do you need a disconnect beside the furnace? or is it optional?
[22:41:07] <Sandcat> There are no SD cards in this system. But I'm still not sure I understood your question.
[22:41:11] * Xark notes C++ templates rock for MCUs (compile time "custom" code that is flexible). :)
[22:41:24] <Tom_itx> Sandcat the function just looked like a file handle
[22:41:34] <Tom_itx> i figured it may be reading it from a SD card or such
[22:42:13] <Sandcat> Tom_itx:
http://pastebin.com/BMiynsQa
[22:42:23] <Tom_itx> meh
[22:42:26] <Tom_itx> i'm off to bed
[22:42:29] <Sandcat> there is the function I'm looking at.
[22:42:33] <Sandcat> okay, goodnight
[22:43:12] <Sandcat> I need to have this running by friday -_-
[22:43:36] <Tom_itx> school work?
[22:43:48] <Tom_itx> are you a procrastinator?
[22:43:59] <Sandcat> no, I just got voluntold when there was only a week before the show
[22:44:47] <Sandcat> We are going to be running some singing tesla coils at the maker fair, and my friend wants the pitch bend changed, and the note range extended, and other things
[22:45:15] <Sandcat> and I'm trying to figure out how this code works well enough to modify it.
[23:26:11] <N1njaneer> Sandcat: What is your questions with regard to that code?
[23:26:14] <N1njaneer> -d
[23:26:19] <N1njaneer> blah
[23:26:24] <N1njaneer> Sandcat: What is your question with regard to that code?
[23:28:03] <jeremyabel> in regard?
[23:32:40] <N1njaneer> Oh well, guess he's idle.
[23:32:47] <Sandcat> N1njaneer: I solved that question
[23:32:57] <N1njaneer> Cool, good job! :)
[23:33:02] <N1njaneer> I am out. Night all!!
[23:33:12] <Sandcat> sorry I was talking in another room and my friend needed me to upload the next version
[23:33:26] <Sandcat> anyway I'm sure I'll run into the next obstacle in a few minutes
[23:34:48] <N1njAway> Good luck! I should be around tomorrow if I can help with anything else :)
[23:34:53] <jeremyabel> night sir
[23:39:47] <rue_mohr> Casper, yea, big power wires can be aluminum, they just up the guage, ti saves a LOT of money, and the aluminum is easier to work with
[23:40:25] <Casper> ok
[23:40:46] <Casper> so I read in that manual that I need to put a stuff on the wire.. de-ox stuff...
[23:40:58] <Casper> do you know about teck wire?
[23:42:02] <rue_mohr> yup
[23:42:13] <rue_mohr> its mineral grease
[23:42:20] <rue_mohr> its called deox tho
[23:42:38] <rue_mohr> and you have to wait AFTER tightening the wire lugs, and then tighten them again
[23:42:55] <rue_mohr> the aluminum 'flows' and gets loose right after you tighten it
[23:43:10] <Casper> what about the disconnect, is it required?
[23:45:30] <rue_mohr> yup
[23:45:40] <rue_mohr> why dont you have an electrician do the work?
[23:45:58] <Casper> #4 copper or #2 alu right for 100A breaker?
[23:46:04] <Casper> because... father is an idiot? :D
[23:46:24] <rue_mohr> why dont you have an electrician do the work? they have the materials and know how to put them togethor
[23:46:35] <rue_mohr> did you get a homeownder permitt? :)
[23:46:51] <Casper> a what?
[23:47:08] <rue_mohr> if you got a homeownder electrical permit, they will inspect it and you will know its not wrong
[23:47:12] <rue_mohr> :)
[23:47:52] <Casper> I'm sure it will be wrong, because father want to use those teck wire that he'll get from kijiji
[23:48:36] <rue_mohr> thats like the best way to start a fire
[23:48:45] <rue_mohr> 5000kw
[23:49:02] <Casper> 18kW heater
[23:49:42] <rue_mohr> yea
[23:50:48] <Casper> personally I think the main breaker will trip...
[23:50:59] <Casper> the 200A one...
[23:53:51] <Casper> but really rue_mohr...
[23:54:09] <rue_mohr> there is a calculation you do to know your capacity
[23:54:15] <Casper> if I don't do it, he'll hire a wannabe electrician that don't know the code at all...
[23:54:31] <Casper> as for the trip...
[23:55:47] <Casper> 3 wall unit thermopump, electric water heater, 18kW furnace, stove, dryer, 1 wide refrigerator/freezer, 1 bigger than standard refrigerator... refrigerator.... and another of same size that is a freezer, plus another freezer
[23:56:25] <Casper> plus 2 ceiling mounted heater