In wall light switch node - Custom PCB


  • Hardware Contributor

    @samuel235 Yes, it's working. But you can't use some things like DS18B20s and DHTs at these low frequencies. Si7021 etc are used instead. Button switches and other simple things are exellent applications.


  • Hardware Contributor

    @m26872 - Well, I was planning on maybe having a temp sensor in there at some point, but not this revision. So if i went without that function at the moment it wouldn't be the end of the world, i would just revise even more for the next revision. I'm presuming that you have taken it to 1MHz for power saving or?

    This is the configuration i'm thinking:

    ######## settings for 8Mhz internal clock

    proMYSBL8.name=ATmega328 internal 8Mhz with MYSBootloader
    proMYSBL8.upload.tool=avrdude
    proMYSBL8.upload.protocol=arduino
    proMYSBL8.upload.maximum_size=30720
    proMYSBL8.upload.maximum_data_size=2048
    proMYSBL8.upload.speed=57600
    proMYSBL8.bootloader.tool=avrdude
    proMYSBL8.bootloader.low_fuses=0x42
    proMYSBL8.bootloader.high_fuses=0xDE
    proMYSBL8.bootloader.extended_fuses=0xFF
    proMYSBL8.bootloader.unlock_bits=0x3F
    proMYSBL8.bootloader.lock_bits=0x3F
    proMYSBL8.bootloader.file=MySensors/MYSBootloader.hex
    proMYSBL8.build.mcu=atmega328p
    proMYSBL8.build.f_cpu=8000000L
    proMYSBL8.build.board=AVR_UNO
    proMYSBL8.build.core=arduino
    proMYSBL8.build.variant=standard

    That would remove the brownout, enable SPI, and put the clock to 8MHz. What is your thoughts on this config?


  • Hardware Contributor

    @samuel235

    • You'll need low MHz for ot to work when battery runs out and voltage decreases.
    • Those fuses are for 1MHz, not for 8MHz.
    • I've never used MYSBootloader. Someone else has to confirm the settings if you use this.

  • Hardware Contributor

    @m26872

    Lower clock speed would last through the low power phase of the battery. Obviously, thank you for pointing that out! However, I'm looking at Maniacs battery testing graph and the battery is stable down to around 2.4v for around 150 hours, then it will rapidly drop off to 0v, so I'm thinking "is the lower clock speed really worth the extra 10 hours of use?".

    The fuses, although I am going off of what you suggested, i entered them into my fuse calculator and its showing up at 8MHz, with no modification needed to the speed.... I'm a little confused at this part as you have now said that those fuses are for 1MHz.

    I'm now wondering if its worth using MYSBootloader or the one you used, I can see that you used this and programmed through the Arduino IDE, from your post you said you're more comfortable with using the Arduino IDE (Which i am too, but can adapt if needed).


  • Hardware Contributor

    @samuel235: don't worry about 1mhz...there is no big difference 1Mhz vs 8Mhz at 3V in deepsleep mode. In deepsleep mode, at 3V 8Mhz internal rc, you can get 140nA. So you can't have such interesting diff.
    In other hand, if node is wake up, you are in mA range, and here it can be interesting to play between clock and voltage 😉 you can do it on the fly in sketch and it's good to know that for timing things, atmel clock and voltage are linked.
    So i would suggest you to stay with internal rc 8Mhz, BOD 1.8V and MYSBootloader. If I remember right it should be ok. Other thing good to know, you can disable BOD=0V when in deepsleepmode (this is done like this in lib I think), but it's not a good practice to disable it when wake up. Keep 1.8V limit, it can prevent some bugs..All is described in datasheet 😉

    Another thing good to know, as I see lot of peope estimation for coincell...there are lot of chance that you can't get the full coincell capacity, depending on the application, the use. A common "prevision is to plan 80% of its capacity. It's due to the rate of discharge of battery and coincell's one is small..
    There are lot of others resources on the subjects but here few links :
    https://www.dmcinfo.com/Portals/0/Blog Files/High pulse drain impact on CR2032 coin cell battery capacity.pdf
    http://www.embedded.com/electronics-blogs/break-points/4429960/How-much-energy-can-you-really-get-from-a-coin-cell-
    http://www.ti.com/lit/wp/swra349/swra349.pdf


  • Hardware Contributor

    @scalz This is the information that was much needed. Right, so my settings are going to be:

    ######## settings for 8Mhz internal clock

    proMYSBL8.name=ATmega328 internal 8Mhz with MYSBootloader
    proMYSBL8.upload.tool=avrdude
    proMYSBL8.upload.protocol=arduino
    proMYSBL8.upload.maximum_size=30720
    proMYSBL8.upload.maximum_data_size=2048
    proMYSBL8.upload.speed=57600
    proMYSBL8.bootloader.tool=avrdude
    proMYSBL8.bootloader.low_fuses=0x62
    proMYSBL8.bootloader.high_fuses=0xD9
    proMYSBL8.bootloader.extended_fuses=0xFE
    proMYSBL8.bootloader.unlock_bits=0x3F
    proMYSBL8.bootloader.lock_bits=0x3F
    proMYSBL8.bootloader.file=MySensors/MYSBootloader.hex
    proMYSBL8.build.mcu=atmega328p
    proMYSBL8.build.f_cpu=8000000L
    proMYSBL8.build.board=AVR_UNO
    proMYSBL8.build.core=arduino
    proMYSBL8.build.variant=standard

    At the moment the fuses are set using Hexadecimal notation, I'm sure that I read somewhere that to burn this using a Arduino IDE you need to use normal binary rather than Hex. Do you know if Hex is okay for Arduino IDE?

    I've got those fuses set to enable 1.8v BoD, 8MHz clock with a 65ms delay on startup. This will use MYSBootloader too. Does this sound okay to now edit my boards.txt, and burn the MYSBootloader.hex file to the chip? I'm using a USBASP device connected to my ISP connection. Am i forgetting anything at all here? As far as I'm aware of, i now plug the board and USBASP into my computer, load the .hex file into arduino IDE and burn using the board config i have put into my boards.txt file. Then i can use my FTDI adapter to then burn sketches to the board through the arduino IDE?

    I know that to some people I may be asking what seems like the same questions over and over but I'm starting to feel very confident with embedded chips now. Thank you!


  • Hardware Contributor

    no problem 🙂 yes, it sounds ok...that's how I do too. But I don't use mysbootloader, i use dualoptiboot (sensebender bootloader). for the hex/bin fuse notation, I use hexa.


  • Hardware Contributor

    @samuel235

    • You could be rigth regarding the battery. I've no coin cell experience.
    • You noticed the check mark by the 'divide clock by 8' ?
    • If you by 'program' normal ftdi flash, then yes. I didn't program bootloader with Arduino.

  • Hardware Contributor

    @scalz

    Is there a reason to use dualoptiboot over MYSBootloader or is that just something you did for no reason?

    Did you use Arduino IDE to burn your bootloader, if so then i can confirm its okay to use Hexa for my board with arduino IDE, if you didn't i will have to convert it to normal binary.

    @m26872

    I have just realised that you burn your bootloader with the check mark of 8MHz but then the board.txt is configured to set it to 1MHz, is that what you're trying to tell me? I'm not too sure on your last point, i don't get what you're trying to say if i'm honest, could you elaborate a little? Sorry.


  • Hardware Contributor

    @samuel235: yes, always good reasons 😉 I have tried both. both works well. I like the "buffer style" of dualoptiboot. plus no mysensors lib in bootloader, few others reasons...but mysbootloader is very cool too and simple. So don't worry about this 🙂 it's a matter of taste, each have their pros&cons.
    Yes, use arduino ide to burn bootloader + hexa is ok.


  • Hardware Contributor

    @scalz - Perfect. I will see how i get on with the MYSBootloader style. Soon as i get back i will burn these settings to my uC and see how i get on. I will come back with the results when i'm done. 🙂


  • Hardware Contributor

    @scalz

    • Don't know if good practice or not, but I run 328p + nRF down to 1.6V very stable. Could depend on a lot things and conditions of course. You said "some bugs" - do you know more what risks there are? Permanent damages etc?
    • Do you know if the 'Divide clock by 8" (8MHz or 1MHz) also can be changed on-fly-with code? If so, does it matter which speed set by fuse and thus used at start-up?
    • Great thanks for the coin cell info!

  • Hardware Contributor

    @samuel235 I meant that you should untick this to use 8MHz. Provided that you don't change it on-the-fly somehow.
    0_1455459198626_klipp.PNG


  • Hardware Contributor

    @samuel235 Sorry for not elaborating. I've been mobile all day until now. And my phone also seems to have a few issues with the forum.


  • Hardware Contributor

    @m26872 Ahh right okay, good job i caught your reply before burning it haha! So if i set it to 8MHz internal with 64ms delay and untick that divide by 8 option, that'll be good?


  • Hardware Contributor

    Yes. but don't forget to enable the boot reset vector.


  • Hardware Contributor

    @samuel235 I have not checked if the bootloader size and baud rate matches fuse settings.


  • Hardware Contributor

    @m26872:

    • for bod=0v, problems could be flash corruption for instance..so it's good to know (it's explained in datasheet that for instance it ensures that a flash write is completely done before reset, I think it makes sense, plus I imagine that there are some internal things with voltage levels related stuff. but I'm not a guru on this....). So my interpretation is sometimes we don't care about it for sleepmode, for instance, and sometimes in wakeup, it's important or not, depending of tasks involved...
      maybe I should have said a good practice is to know what you do, lol!
    • for prescaler, are you asking for something like this : http://www.gammon.com.au/forum/?id=11497&reply=7#reply7
    • glad to share what I learn 🙂

  • Hardware Contributor

    @scalz .

    maybe I should have said a good practice is to know what you do, lol!

    l don't fulfil that either, lol! 😃

    Thanks for the prescaler info. Seems like a yes - it can be changed on-the-fly, but for me it's a No. I won't even dare to think of consequences for the rest of the software.


  • Hardware Contributor

    @m26872 said:

    @samuel235 I have not checked if the bootloader size and baud rate matches fuse settings.

    I'm not 100% sure of what you mean here, on the fuse calculator there is not an option to specify the baud rate.... As for the bootloader size, the calculator is set to "Boot Flash section size=2048 words Boot start address=$3800; [BOOTSZ=00]". As this is the highest it can be I'm assuming it is correct, however i will try and check the size of the MYSBootloader.hex size and see if it is below 2048 words (Is this what this setting means?).


  • Hardware Contributor

    @samuel235 No, but bootloader and boards.txt must have same buad rate. I think you already have the correct though since 8MHz is pretty much standard clock speed. Slower clock would require lower buad rate.


  • Hardware Contributor

    @m26872 Is there a way to read the .hex file to see the specified baud rate before i go and brick the chip? Also, just to confirm, i have to burn the fuse settings in AVRDUDE then burn the bootloader with arduino IDE. Is there anything I'm failing to understand, i only have one more uC here at the moment and i don't want to brick several of them 😞


  • Hardware Contributor

    @samuel235 Sorry, I can't help you further. I don't know for sure about these things.


  • Hardware Contributor

    @m26872 - That is okay, I think I'm pretty safe to assume that it is correct as it is what is provided on Tekka's guide. So I'm going to attempt to burn the fuses at E2 D8 FE. Once I've done that (and it works fine), Arduino IDE should burn the bootloader onto the uC without an issue and then i can just upload a arduino sketch, right? o.O


  • Hardware Contributor

    I've just written the fuse settings and got this log report:

    avrdude.exe: set SCK frequency to 187500 Hz
    avrdude.exe: AVR device initialized and ready to accept instructions
    
    Reading | ################################################## | 100% -0.00s
    
    avrdude.exe: Device signature = 0x1e950f
    avrdude.exe: reading input file "0xE2"
    avrdude.exe: writing lfuse (1 bytes):
    
    Writing | ################################################## | 100% -0.00s
    
    avrdude.exe: 1 bytes of lfuse written
    avrdude.exe: verifying lfuse memory against 0xE2:
    avrdude.exe: load data lfuse data from input file 0xE2:
    avrdude.exe: input file 0xE2 contains 1 bytes
    avrdude.exe: reading on-chip lfuse data:
    
    Reading | ################################################## | 100% -0.00s
    
    avrdude.exe: verifying ...
    avrdude.exe: 1 bytes of lfuse verified
    avrdude.exe: reading input file "0xD8"
    avrdude.exe: writing hfuse (1 bytes):
    
    Writing | ################################################## | 100% 0.02s
    
    avrdude.exe: 1 bytes of hfuse written
    avrdude.exe: verifying hfuse memory against 0xD8:
    avrdude.exe: load data hfuse data from input file 0xD8:
    avrdude.exe: input file 0xD8 contains 1 bytes
    avrdude.exe: reading on-chip hfuse data:
    
    Reading | ################################################## | 100% 0.00s
    
    avrdude.exe: verifying ...
    avrdude.exe: 1 bytes of hfuse verified
    avrdude.exe: reading input file "0xFE"
    avrdude.exe: writing efuse (1 bytes):
    
    Writing |  ***failed;  
    ################################################## | 100% 0.09s
    
    avrdude.exe: 1 bytes of efuse written
    avrdude.exe: verifying efuse memory against 0xFE:
    avrdude.exe: load data efuse data from input file 0xFE:
    avrdude.exe: input file 0xFE contains 1 bytes
    avrdude.exe: reading on-chip efuse data:
    
    Reading | ################################################## | 100% 0.00s
    
    avrdude.exe: verifying ...
    avrdude.exe: verification error, first mismatch at byte 0x0000
                 0x06 != 0xfe
    avrdude.exe: verification error; content mismatch
    
    avrdude.exe done.  Thank you.
    

    I then checked the fuses by reading them. I can confirm it has written the Low and the High fuse but as the log says, it failed to write the extended. So I went to the calculator site and read the following (This is what i was asking about hex vs binary for):

    "Note that some numerical values refer to fuses containing undefined bits (set to '1' here). Depending on the target device these fuse bits will be read either as '0' or '1'. Verification errors will occur if the values are read back with undefined bits set to '0'. Everything is fine if the values read from the device are either the same as programmed, or the following values (undefined set to '0'): Extended: 0x06."

    I then attempted to burn the bootloader, assuming the error is fine to skip (as the fuse calculator said), but it gave me the same error of:

    avrdude: verification error, first mismatch at byte 0x0000
             0x06 != 0xfe
    avrdude: verification error; content mismatch
    

    So basically, telling me that my boards.txt is telling the IDE that the fuse should be FE, but its 06.


  • Hardware Contributor

    Looks like ext fuse is already 0x06 and you only need to change your board.txt to the same. I've never heard before that the 0xFE type of writing should work in avrdude/Arduino IDE.


  • Hardware Contributor

    I went ahead and changed my board.txt to reflect 0x06, to check. It passed through and burnt the bootloader. However, if i try to upload a sketch (using the FTDI adapter that i have, this) I get a timing error. How do i upload a sketch to the chip with the ISP connection (just to test if my FTDI pins are wired incorrectly). This is my log from arduino IDE:

    Sketch uses 12,610 bytes (41%) of program storage space. Maximum is 30,720 bytes.
    Global variables use 398 bytes (19%) of dynamic memory, leaving 1,650 bytes for local variables. Maximum is 2,048 bytes.
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x7c
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x7c
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x7c
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x7c
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x7c
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x7c
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x7c
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x7c
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x7c
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x7c
    Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
    

    "programmer is not responding" - I was asking myself "Would this mean that arduino IDE can't use avrdude for some reason?" but then i figured that it used it to burn the bootloader so that isnt right. Is it trying to find the ISP programmer and cant because i'm connected through FTDI maybe?


  • Hardware Contributor

    I have just remembered that if you go to the file menu in Arduino IDE you get the option to upload using programmer. I have just done this through my SPI programmer, it has uploaded correctly. I will now solder the nRF module onto the board and i will report back with my results. Crosses fingers


  • Hardware Contributor

    BINGO!!

    We have a working coin cell powered light switch.
    2_1455483349684_image.jpeg 1_1455483349683_image.jpeg 0_1455483349682_image.jpeg

    I will upload some decent images later on tonight or tomorrow.

    I'de just like to talk everyone that has contributed to this thread/post and enabled me to create my first of many embedded projects. I'm applying for a University course in september for Computer Science (Smart Technologies), all about embedded systems, drones, home automation etc etc. This is just the beginning!

    I'll get this project up on OpenHardware.io asap as Version 1 and we can build on this as a base plate for futher projects.


  • Hardware Contributor

    Now, the next two steps I'm interested in taking is to get this working with 2 switches (Software modification, should be simple) and then to have it report its remaining power every 30 minutes to allow me to set up notifications through openhab to alert me to change the batteries so I'm not left with no light switch.


  • Hardware Contributor

    It would appear that I'm having a timing issue with uploading via the FTDI adapter. Would this be down to the speed of the uC effecting the RX and TX connections?


  • Hardware Contributor

    This post is deleted!

  • Hardware Contributor

    @samuel235 Are you trying to upload with Ftdi serial to MYSbootloader? I think it's only for OTA uploads, if you read here.


  • Hardware Contributor

    @m26872 - Thank you for pointing this out to me. I'm unsure why I haven't stumbled across that thread/topic today of all days, been searching and reading about MYSBootloader all day >.<

    From personal experience, would you advise any other bootloader, I'm guessing you're going to tell me about the one you are using. Could you link any information for me to check out regarding your choice of bootloader?

    Am I correct in recalling you're using DualOptiBoot?
    Does DualOptiBoot need external memory/flash?


  • Hardware Contributor

    @samuel235 No, I use plain optiboot, but I couldn't find a suiteable precompiled one for you. DualOptiboot requires external flash as you say.
    It's been a while since I played with bootloaders, but I think normal 8MHz Arduino Pro Mini bootloader would work for you with internal clock as well. It's this [ATmegaBOOT_168_atmega328_pro_8MHz.hex ] and I can find it in my "C:\Program Files\Arduino\hardware\arduino\avr\bootloaders\atmega" -folder, should be about the same for you I think. Try fuse settings E2-DA-06 (Lo-Hi-Ex) and rest of the boards.txt-settings from ArduinoProMini 3.3V 8MHz.


  • Hardware Contributor

    @m26872 - Ahh the generic arduino bootloader... I will have a look into using that tomorrow. As the MYSController gets more feature rich and support i will use that setup, however i love OpenHAB way too much to switch over right now.


  • Hardware Contributor

    @m26872 - I've just spent a few minutes looking through my boards.txt and i came across:

    ######## Settings for 
    
    ATmega328 8MHz Internal clock
    atmega328bb.name=ATmega328 on a breadboard (8MHz internal clock)
    atmega328bb.upload.protocol=stk500
    atmega328bb.upload.maximum_size=30720
    atmega328bb.upload.speed=57600
    atmega328bb.bootloader.low_fuses=0xE2
    atmega328bb.bootloader.high_fuses=0xDA
    atmega328bb.bootloader.extended_fuses=0x05
    atmega328bb.bootloader.path=arduino:atmega
    atmega328bb.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
    atmega328bb.bootloader.unlock_bits=0x3F
    atmega328bb.bootloader.lock_bits=0x0F
    atmega328bb.build.mcu=atmega328p
    atmega328bb.build.f_cpu=8000000L
    atmega328bb.build.core=arduino:arduino
    atmega328bb.build.variant=arduino:standard
    

    Then out of interest I thought I would look at the bootloader that you suggested, to see what difference there would be. Turns out I was actually looking at it without knowing. I have a feeling that if I change the fuse settings to those that i am using now with MYSBootloader, I will be set to go.

    The High Fuse setting you provided enables 1024 words in the boot flash section, a couple of questions about this:

    • Is this defining the size of the area needed for the bootloader section on the built in memory (So smaller this is set to, as long as the bootloader will fit, the more room I will have for a sketch)?
    • How do i find out the 'word size' of the bootloader (if the first question is correct method) so I can determine if the 1024 is big enough? I would rather know how to work this out rather than just assuming that it is because it is specified as that as default.

    I was going to leave my fuses where they were at (E2, D8, 06 as LO:HI:EX) but if I can change the boot size setting, that would allow a bigger room for my sketches = Win Win!

    I'm still slightly confused as to not being able to burn my extended fuse. I have read somewhere (lost the page) about not being possible to burn an EX fuse on a ATmega328p, which i find very hard to believe.


  • Hardware Contributor

    @samuel235 said:

    • Is this defining the size of the area needed for the bootloader section on the built in memory (So smaller this is set to, as long as the bootloader will fit, the more room I will have for a sketch)?

    Yes.

    • How do i find out the 'word size' of the bootloader (if the first question is correct method) so I can determine if the 1024 is big enough? I would rather know how to work this out rather than just assuming that it is because it is specified as that as default.

    I don't have the tool or knowledge for that. Should be doable by removing indices and count the bytes in hex-file. But for me it's not a big deal to just use the size settings recommended for a particular bootloader. And in this case it´s stock Arduino, so why question it.

    I'm still slightly confused as to not being able to burn my extended fuse. I have read somewhere (lost the page) about not being possible to burn an EX fuse on a ATmega328p, which i find very hard to believe.

    So the '0x06'-kind of notation didn't work either? Strange.


  • Hardware Contributor

    @m26872 said:

    And in this case it´s stock Arduino, so why question it.

    I'm not questioning it, I just wanted to learn how to do it for if i ever came across a need to modify a bootloader i would then know how to record its size for the fuse burning.

    So the '0x06'-kind of notation didn't work either? Strange.

    When i set the boards.txt file to read 0x06 it worked perfect, which insinuates that it couldn't burn the chosen BoD, even though the fuse calculator says to ignore the error of the extended fuse, it should burn it even though it gives the error. I'm interested in trying to burn the extended fuse in normal binary rather than hexa. But i doubt it would work anyway.


  • Hardware Contributor

    It has just clicked inside my busy mind that 0x06 in binary is the same as 0xFE in Hexa. How embarrassed am I now after many questions and hours thinking about the extended fuse value. I'm now assuming that it returns the error because it is already set at that fuse 😳


  • Hardware Contributor

    So, i have it working using the following board.txt config:

    ######## Settings for 
    
    ATmega328 8MHz Internal clock Brown-out detection 1.8v
    atmega328bb.name=ATmega328 on a breadboard (8MHz internal clock) BoD1.8
    atmega328bb.upload.tool=avrdude
    atmega328bb.upload.protocol=stk500
    atmega328bb.upload.maximum_size=30720
    atmega328bb.upload.speed=57600
    atmega328bb.bootloader.tool=avrdude
    atmega328bb.bootloader.low_fuses=0xE2
    atmega328bb.bootloader.high_fuses=0xDA
    atmega328bb.bootloader.extended_fuses=0x06
    atmega328bb.bootloader.path=arduino:atmega
    atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
    atmega328bb.bootloader.unlock_bits=0x3F
    atmega328bb.bootloader.lock_bits=0x3F
    atmega328bb.build.mcu=atmega328p
    atmega328bb.build.f_cpu=8000000L
    atmega328bb.build.core=arduino:arduino
    atmega328bb.build.variant=arduino:standard
    

    However, no matter what I did I couldn't get it to upload via FTDI. I've tried looking at the Arduino Pro Mini settings in boards.txt to see what 'upload.tool' it uses, AVRDUDE, same as i specified. I also then went to the google docs for the boards.txt reference file, that advises everything i did too. I'm a little stumped. All that i can think of is that i have wired it incorrectly on the pcb. Whats your thoughts on this?


  • Hardware Contributor

    @samuel235 said:

    I'm not questioning it,

    I'm not saying you do, I just told how I think of it.

    I'm interested in trying to burn the extended fuse in normal binary rather than hexa.

    Why, when the result is exactly the same?
    Also, I'm not familiar with from where the "binary or hexa" comes from? They're both hexadecimal notation as far as I can see.


  • Hardware Contributor

    I'm not sure what is your problem with ftdi.maybe wirings...do you have cts to gnd, and of course dtr to dtr, only one vcc active...??? Maybe you should try to burn original arduino ide bootloader and then ftdi upload attempts. If it still doesn't work, it could be the wirings...
    for hexa vs binary..in some case binary notation can be useful, but for fuses, I prefer hexa: shorter, no possibility of mistakes by missing/miscounting one "1" or "0" bit 😉


  • Hardware Contributor

    @m26872 - I wanted to try it because i'm sure i read somewhere that the ATmega328 can't accept Hexa as fuses. But i doubt that information is valid if i'm honest with you.

    @scalz - I have dtr to dtr and cts linked to ground. I also only have one VCC pin (which obviously goes to VCC). I'll be perfectly honest with you; the boart.txt setting i posted above, i thought that was using the arduino .hex bootloader, please inform me if i'm in correct in that.


  • Hardware Contributor

    This is the board layout, if you guys can see any issues with my FTDI connections/pinout please advice me that you do, I will get that sorted for revison 3 of the board. If i'm honest, I don't mind burning the sketches with the ISP programmer everytime, so I'm very tempted to remove the FTDI, allowing a smaller board still.
    0_1455731784013_Wiring.jpg


  • Hardware Contributor

    @samuel235 How do you debug through ISP ?
    Have you tested your FTDI USB-serial converter with ArduinoProMini or something?


  • Hardware Contributor

    @m26872 - I haven't tried it out with a arduino pro mini, because i don't have one. However, tomorrow, I will get a Arduino nano out and sort some testing of my FTDI converter on that. I'm hoping that works and its just a simple wiring issue on my board.

    From your statement of "How do you debug through ISP?" I'm guessing that it isn't possible too, or was that a genuine question? If its not possible then I will keep the FTDI connectors on the board.


  • Hardware Contributor

    @samuel235
    I think you should get yourself a APM (ArduinoProMini) as a reference device. While waiting I think you could wire a DTR circuit to your Uno or Nano and see if you can get your FTDI to talk through rx/tx there.

    The "debug through ISP" is a genuine question. My guess is that it's possible if your bootloader, programmer and IDE support it.


  • Hardware Contributor

    Yea, we talked about this as well @m26872 the other night... and to make it easy I also suggest having the fdti connector - if your node is about other to use it (new members to mysensors) thats they easiest way to be able to debug.

    Its possible to debug through SPI, [1, 2 , 3] but requiers extra code in your sketch. With fdti you can just user serial.println();Also it looks like you need an second arduino acting with some code... to read and print on that second device serial.... have not read everything through... but its a bit of work it seems.


  • Hardware Contributor

    @m26872 - I'm going to get a APM sorted asap. Then i'll get to try my FTDI converter checked.

    @sundberg84 - Way too much hassle for what its worth, I will trouble shoot and sort out my existing connection for FTDI.


  • Hardware Contributor

    Current Situation Update

    The board is completely populated with correct hardware, tested for 24 hours functioning, working completely fine. There is a slight delay now and then between the switching state and the light illuminating, only sometimes, but nothing major (1/1.5 seconds). The fuse setting and the bootloader burning went unbelievably smooth, very easy once i got my head around all the different settings needed and why they were needed in certain situations. I'm currently using the default arduino bootloader (ATmegaBOOT_168_atmega328_pro_8MHz.hex), burnt with a ISP connection using AVRdudess for the software. I'm unsure if the device is sleeping between readings of the switch but that will be easily noticed soon as i get my FTDI situation fixed.

    Talking about FTDI Issues, I'm currently stuck with not being able to upload a sketch through FTDI, its hanging on the "upload" status in Arduino's IDE. I don't think it is a driver issue as my computer has always been configured to never update a driver through windows update (Just confirmed this through the advanced computer settings). The driver that I'm currently using is version 3.3.2011.11. However, if there is no issue with my wiring (shown in a recent previous post/comment above here) i'm struggling to see what else the issue could be other than soldering issues, which i can't notice from a few look over attempts using a 25x magnifier, I will give it another look over to make sure though.

    Which attempting to troubleshoot this, I have noticed that if I have the MYSbootloader on the chip and then attempt to upload a sketch (which i know wont work anyway due to MYSbootloader settings/usage rules) I get the generic message of memory allocation:

    Sketch uses 13,678 bytes (44%) of program storage space. Maximum is 30,720 bytes.
    Global variables use 438 bytes (21%) of dynamic memory, leaving 1,610 bytes for local variables. Maximum is 2,048 bytes.
    

    Where as if I use the default arduino bootloader I only get:

    Sketch uses 13,678 bytes (44%) of program storage space. Maximum is 30,720 bytes.
    Global variables use 438 bytes of dynamic memory.
    

    It completely misses out showing what space is left for the local variables. Could this shine any light onto the issue? The actual error that I am getting for the MYSbootloader version (after waiting literally over 1 minute from pressing upload), again that is expected, however the default bootloader version just hangs in the uploading state, its been there for well over 5 minutes without giving me an error now. Just to add, they both have the same 'upload.speed=57600' in their respected boards.txt config.

    The FTDI Issue is my only major issue on this board now, revision 3 will be just minor fixes, such as adding pull-up resistors between the switch and VCC, a more detailed list will be announced when revision 3's designing process starts.


  • Hardware Contributor

    Just to let everyone that is reading this thread know that it is possible to brick your uC with the simplest of mistakes. It would seem that i have bricked my uC by burning the Arduino Pro Mini bootloader to it. The file that i burnt was 'ATmegaBOOT_168_atmega328_pro_8MHz.hex' designed for the Arduino Pro or Pro Mini (3.3v, 8MHz). I will be perfectly honest and admit that i genuinely don't know why it bricked it. I just thought that as long as the uC signature matched that of the bootloader you was burning it can be any .hex file, as long as it matched that uC. Seems that for some reason this didn't like it. If someone would like to give some more in-depth information regarding this to just allow people here a little more knowledge on this subject to aid in them not making the same mistake, that would be appreciated by all.


  • Mod

    I think this is why it doesn't work: The standard Pro Mini bootloader assumes a 8MHz external oscillator. This board hasn't got one, so the mcu gets no ticks.

    I'm not sure but I think it is possible to re-orogram it.


  • Hardware Contributor

    @mfalkvidd - Oh C**P! An external OC, I completely forgot about it being a external one. Damn it! I'll get a 8MHz OC ordered and then just temp wire it into the circuit and hope it works by a huge bodge job. Do you have any thoughts on why I could upload via FTDI (as per the post above detailing everything regarding this issue)?

    @sundberg84 - From our private messages, this is one of those very simple mistakes, made here by myself. Now, see how easy this mistake is? Don't be a fool like me and do the same haha!


  • Mod

    Sorry, I have never tried rolling my own. But there's lots of clever people here, someone should have some advice.


  • Hardware Contributor

    @samuel235 I only see two possible causes. Either you changed the fuses unintentionally or you hw-bricked it with supply voltage, ESD or somehing. In the first case you'll just have to connect the external xtal ( likely 8MHz if you burned the standard APM 8MHz fuses).


  • Hardware Contributor

    @mfalkvidd - Alrighty 🙂

    Just to let people know, i think that where i went wrong here is the fuses. Even though i burnt my fuses before the bootloader to the correct fuses that i want, I think that i didn't restart Arduino IDE after i saved the boards.txt file. Just make sure you don't do this! Always restart the IDE after altering any info in boards.txt.


  • Hardware Contributor

    @m26872 - Well to be honest, the way that i was throwing around possible solutions i'm guessing that its just a silly mistake with fuses in the boards.txt file. But would this just not burn the bootloader, i wouldn't have incorrectly burnt the fuses, i took 100% care over that, i came back here to double/triple check the fuses that i wanted from a previous comment i made. I burnt those and i changed the boards.txt and didn't restart the arduino IDE i dont think. But wouldn't this just not burn the bootloader?

    Maybe if that is correct of me thinking this, then i could have bricked it with power/esd like you mentioned. Either way i have ordered some crystals to troubleshoot this.


  • Hardware Contributor

    The Arduino Pro Minis and another FTDI adapter has arrived today along with my crystals. We have news...

    • Firstly, I got the fuses and bootloaders back to the correct ones (E2 DA 06) and the arduino bootloader, no issues here.
      I then tried the new FTDI adapter - Still nothing.
    • Then it was the turn of trying an arduino pro mini with FTDI. Nothing there either. So i started to get puzzled at this point...
    • I turn my mac on, tried it on there. I installed the drivers and allowed them to be used by running 'csrutil enable --without kext' in a terminal inside of recovery mode. Logged in, it recognized the FTDI chip, but couldn't upload to the APM. It is throwing out the same error of "avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xee"

    I'm yet to start googling the error code, that will be my next step to take. Its very much looking like the adapter is not able to chat to the board and since its happening on both boards i'm thinking that i may be doing something silly.


  • Hardware Contributor

    The arduino nano that i have uses the same serial chip that the FTDI adapter does, CH340G. Please correct me if i'm wrong in saying this, if i had a broken/incorrect driver for that CH340G then i wouldn't be able to upload via USB to my arduino nano?


  • Mod

    Ch340g is not able to auto-reset the Arduino. You need to press reset manually, just after the Arduino IDE prints "Uploading". Maybe that's the problem? More information is available at http://www.avrfreaks.net/forum/how-do-i-program-arduino-pro-mini-ch340g-usb


  • Hardware Contributor

    @mfalkvidd - I was attempting this last night. I spent 20 minutes doing this, i will attempt again tonight to see if i was doing it at the correct time.


  • Hardware Contributor

    That article is regarding the CH340's that do not have the DTR pin, however mine does. Either way i have just spend another 10 minutes trying to get it to load a sketch to two APM's and nothing, I've tried pressing the reset on the adapter and the arduino when it prints "uploading..." and i've also tried holding the reset down and releasing it when it prints the updating... message too. Nothing still 😞


  • Hardware Contributor

    So with a few wiring alterations of connecting the adapter's pin GND to the GND of the APM, rather than the CTS on the adapter to the GND of the APM it works. However, it won't work going to my board, it gives me 'avrdude: error reading signature data for part "ATmega328P", rc=-3' and if i switch the gnd and the cts around on my board (which on my board design is connected together) it can't even connect to the device. I will be troubleshooting this tonight and tomorrow now. At least we're slightly further forward!


  • Hardware Contributor

    Just a quick mini update:

    I'm still having issues after several days of FTDI troubleshooting. I think I can safely assume there is an issue with my FTDI section, on my board itself. I have uploaded a binaryswitch sketch to the uC with the ISP 'upload through programmer' option, uploaded perfect like normal. I then plugged the board in with my FTDI serial adapter, i couldn't monitor the serial port, nothing in the monitor. I had enabled the debug too. So, the basic things i have done at the moment are:

    • Switching the gnd and cts pins to find a combination that works, nothing.
    • Switch Rx and Tx around, nothing.

    Once i get home from work today i will be troubleshooting to see if there are any other things that i should have included into my FTDI section that maybe i didn't do. If anyone has any input on this section, I would love to hear it.



  • @samuel235

    Nice work so far. I had a similar idea to use Binary Switch to turn ON/OFF my relays and lights but I had to discard the idea after going through several issues. Occasionally my serial gateway would fail to connect to the Vera and it would paralyze all my lightings. Essentially the Binary switches talk's to the Relays by going through the gateway. So decided to redesign the electronics to accommodate Relay with Button Actuator Sketch. If you lose the gateway, you could still bet that it would work though I wouldn't say it's 100% reliable but it gets the job done. Lately, I'm also exploring other avenues to somehow use www.Souliss.net concepts on MySensor and I was informed that My sensor Ver 2.0 Beta has got something similar by using ESP8266. I don't know how much of this is true but I'm pretty sure @hek will be able to explain.


  • Hardware Contributor

    @jeylites - I'm well aware about it crashing and just stopping all of my system from working. I'm just going to see how it functions when its the only solution to turn my lights on to be honest.

    The only thing that i can notice on my schematic/board design is that the capacitor on my DTR line is right next to the uC, not close to the FTDI header at all. Would you guys have it close to the uC or the FTDI header? I'm sure I was advised to have it close to the uC.


  • Hardware Contributor

    @samuel235 Just because ISP upload and everything else works, I would still try to rule out hw/assembling issue. What measures have you taken apart from inspection? Do you have more than one board built? Resoldered the uC? Programmed same fuses/bootloader to APM?

    Also, I didn't get the CTS thing. Did you just need to disconnect CTS to make it work on APM? Isn't CTS shorted to GND on your APM as well?


  • Hardware Contributor

    @m26872

    Do you have more than one board built?

    This is the second one of this Revision, the first had the same issue, but there was no difference between the two boards, just did this to lower the chances of any soldering problems causing issues.

    Resoldered the uC?

    I have gone around the uC with the soldering iron 'tinned' to make sure each of the pins are connected to its pads properly without too much solder there, I might go around once more just incase i didn't get enough solder to connect on some of the pins. However, i don't believe this to be an issue, but anything is possible 😉

    Programmed same fuses/bootloader to APM?

    I have programmed the APM to match this board, and it worked fine, fuses and bootloader included.

    Also, I didn't get the CTS thing. Did you just need to disconnect CTS to make it work on APM? Isn't CTS shorted to GND on your APM as well?

    Both of the boards have CTS shorted to GND. I didn't explain it correctly, i meant that if i use GND (on the USB adapter) -> GND on board, nothing happens. But if i do CTS (on the USB adapter) -> GND or CTS on board, it works for the APM.

    Now i have some progress. I made the fundamental error of not powering the board with the battery while it was connect to FTDI. I can now monitor the serial output and see my debugging messages. However, i still can't upload a sketch. To me this all points down to the DTR circuit. The ISP uses the RESET line rather than DTR, and the ISP is working fine (from what i can tell). Would you agree with me in thinking that the issue is somewhere on the RESET section/line? My initial thought was my fuses, but my E2 DA 06 settings allows boot reset vector so therefor i don't think that my fuses are to blame.


  • Hardware Contributor

    Arduino IDE has just uploaded a sketch perfectly fine with no errors to my board, for some reason. Just out of the blue (I did nothing different to what i've been doing the last week). However, i then tried it again and got errors. So just out of curiousity i uploaded the BareMinimum sketch, and got errors. I opened the Serial monitor and got nothing printed. So therefor i know that something has happened to the uC because it was running my switch sketch (through 'upload via programmer'). So i then uploaded my switch sketch and got errors again about the programmer not being in sync:

    avrdude: stk500_paged_load(): (a) protocol error, expect=0x10, resp=0x81
    avrdude: stk500_cmd(): programmer is out of sync
    

    I then opened the serial monitor, the sketch is uploaded!

    Why am i getting errors? From my limited knowledge, my two thoughts are:

    • The board is not reseting after the sketch has been uploaded and therefor the programmer is out of sync to the board.
    • The programmer is running/uploading too quickly for the uC to know or keep in time with.

  • Hardware Contributor

    @samuel235 said:

    Both of the boards have CTS shorted to GND. I didn't explain it correctly, i meant that if i use GND (on the USB adapter) -> GND on board, nothing happens. But if i do CTS (on the USB adapter) -> GND or CTS on board, it works for the APM.

    Sorry, I still don't get it. Don't you always connect all 6 pins?

    Now i have some progress. I made the fundamental error of not powering the board with the battery while it was connect to FTDI.

    Great, but you should not need a battery if you have power from the FTDI-adapter and don't have any big power consumers or shorts on the board. Do you use 5 or 3.3V ? Have you measured the current (e.g. from a battery)?


  • Hardware Contributor

    @m26872 - Both of the adapters that i purchased only came with 5 wires in a ribbon cable fashion, and me being mr gullible decided to assume that it only needed the 5. I just assumed that i only need to connect GND OR CTS. I'm now assuming that i need to connect both of them as they don't short together on the adapter itself? I have watched numerous videos on FTDI and ISP to troubleshoot this and I can honestly admit that i didn't realise if any of them had used 6 connections 😞

    I did at one point test the current, i can't remember exactly what it was. Give me an hour and I will be able to test that 🙂 - I'm using 3.3v for the VCC line, my adapter is set to 3.3v too. Does it matter what the current is or would you be checking to just see if there is any current at all? I have tested the voltages when i'm hooked up to the serial connection just to let you know, and they were fine across all of the vcc connections on the board, so there is no connections missing and the uC is definably receiving power 🙂


  • Hardware Contributor

    So i have just dropped my multimeter over the coin cell and various other positions on the board, it would seem that there isn't much of a current change anywhere across the board. It reads 2.6mA across the board. This shows that there isn't really any current draw across the board and therefor like @m26872 mentioned in the previous post, there is no reason to why it shouldn't work being powered from the serial adapter.

    When i have the board connected through the serial adapter without the battery, the current is the same across the board, the reset pin is receiving the 3v to keep it high and i get an error of:

    avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0xfc
    
    avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0xfc
    
    avrdude: arduino_read_sig_bytes(): (a) protocol error, expect=0x10, resp=0xfc
    avrdude: error reading signature data for part "ATmega328P", rc=-3
    Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
    avrdude: error reading signature data, rc=-1
    

    I don't think there errors are very helpful as they keep changing every time i try to upload it without touching the board. I think its just having general issues with getting a transmit signal. I can still view the serial monitor perfectly fine which to me indicates that i have the Rx and the Tx line correct for a start. Am I correct in assuming this?

    What is your general thoughts, would you think it has anything to do with the reset procedure or do you feel there is an issue elsewhere on the board/power?

    EDIT: I measured the current incorrectly, changed the figure in this post to reflect the correct measurement.


  • Hardware Contributor

    I can also confirm that my RESET pin is high with the same voltage as the coin cell is providing so there is no issue from the start of the process, the only thing I'm wondering is if the DTR pin is pulling the pin low when needed. This process would be much easier to see if i had an oscilloscope.


  • Hardware Contributor

    I can now rule out my previous thoughts of the capacitor on the DTR line being too far away from the FTDI connector, i just moved its placement and it doesn't change a thing. Still getting the protocol error.


  • Hardware Contributor

    @samuel235 I looked again at your board and saw that your DTR trace was routed very near Rx. Did your "move" of C7 had it's own wire from serial adapter, i.e. bypassed and unconnected to DTR trace on board?
    I also pressume you've double checked value and functionality of C7.


  • Hardware Contributor

    @m26872

    I completely moved C7 and infact i attached it to the under side of the DTR pin on the FTDI header, then ran a wire to the pad that C7 WAS attached to (the uC side). I made sure it was not shorting on anything else in its vicinity.

    I do understand the functionality and the value needed for this cap. The need for this cap is to essensially pull the RESET line low for a split second by discharging the cap and then the vcc line with the pullup resistor charges the cap back to full then pulls the reset pin high. This process then tell the uC to restart itself.

    The only thing left for me to try is increasing the size of that cap. I have a 4.7uF cap in my inventory that i will attempt to change out. But i have read that everyone uses a 0.1uF and its very very unlikely that it needs to be higher. My case might just be that 0.1% that does.


  • Hardware Contributor

    @samuel235 If you mean the Ftdi header on the board, then it was still connected to that trace. Try bypass it completely and connect straigth from your serial adapter to cap to resetpin.


  • Hardware Contributor

    @m26872 Of course it would, silly me. I have now ammended that and still nothing. I'm about to swap out that cap for a 4.7 to see if that does it. This is how i have it setup to test what you pointed out:
    0_1456766460419_image.jpg

    0_1456766531827_image.jpg

    Photographing my board under x25 magnification makes it look very amateurish and dirty 😞


  • Hardware Contributor

    Does anyone have another bootloader that works with the atmega328p-au clocked using the internal oscillator at 8MHz? I just want to double check it isnt my bootloader playing up with the clocking speeds. That or a boards.txt section for this setup. I will edit my own later but i would just like to double/triple check it with one that has been made from someone other than myself to rule out any silly errors.


  • Hardware Contributor

    Scrap that idea, my Arduino Pro Mini is working perfect with the exact same fuse settings, boards.txt entry and sketch.


  • Hardware Contributor

    So after several discussions with some atmel information being thrown around over the arduino forums i have came to the point where i have now found out that using the internal oscillator will not always allow serial connections/uploads to work properly. So, at the moment to test this, i burnt the sketch using 'upload via programmer' and then unplugged the board and re-connected using FTDI connections. I then opened the serial monitor and its working perfect. Next up is to figure out some information regarding crystals. With the whole board running on a coin cell my main point was to have the power consumption as low as possible. Could anyone give me some information or websites regarding oscillators, i would like to know if they use any extra power consumption compared to using the internal crystal of the atmega328p-au.

    I have two options for this board where i would like to take it;

    1. Add an external crystal and allow users to upload via FTDI without having to touch the ISP connection/burning a new bootloader.
    2. Keep the internal crystal in use, and instruct the users to upload via ISP with the programmer and then debug using serial connection.

  • Hardware Contributor

    I'm now sitting with two of these boards in front of me giving me an "Starting sensor (1.6.0-beta), Radio init failed. Check wiring.". As i already have experienced this, i do know that 9/10 times this is hardware related. Normally incorrect wiring. Time to troubleshoot this for the second day. I'm pretty sure that i have no shorts on the board, the only thing that i can think it could be is a broken radio, but with the two doing this i'm a little skeptical about that.


  • Hardware Contributor

    So here we have it guys, Revision 2 is now complete, tested and working perfectly! Its been a grueling process but so rewarding. I plan on making a few tiny little changes, including some headers/jumpers to allow ISP uploads while the radio is attached and pull-up resistors to the switch lines. I will get these all ironed out in the next few days and get the designs sent off to get the final boards manufactured. However, I don't feel that there is a great rush for this last board as the upgrades are very minor ones that won't effect its usability right now. The files on the original post are all up to date and relevant including the schematic. I'm yet to test the current draw, I'm trusting that it is sleeping in between the switch toggles, would this be tested via the current draw, if so where should it be measured to confirm this?

    Here are a few photographs of the final board attached to a switch plate:

    2_1457169881232_IMG_7361.JPG
    1_1457169881232_IMG_7360.JPG
    0_1457169881222_IMG_7359.JPG



  • Hi,

    I'm trying to order this PCB pre-assembled from itead.cc, but it requires Gerber and BOM files, none of which are found in the Eagle files zip...

    Any idea how can I get this PCB pre-assembled?


  • Hardware Contributor

    I'm affraid i don't have this board set up with any distributor for pre-assembly sales. The only option to get this board pre made would be for me (or anyone else willing to build the board) to build the board for you then mail to you. I can supply you with the gerber files and everything needed to purchase the board and a BOM then you can build the board yourself if thats possible.



  • @samuel235
    That is a shame, this looks like exactly what I was looking for, though the assembly is way over my head. This is why I was hoping to get it pre-assembled...

    I can handle the basic soldering of a capacitor or varistor, but not their miniature versions, not to mention the atmega chip...



  • @samuel235 said:

    I'm affraid i don't have this board set up with any distributor for pre-assembly sales. The only option to get this board pre made would be for me (or anyone else willing to build the board) to build the board for you then mail to you. I can supply you with the gerber files and everything needed to purchase the board and a BOM then you can build the board yourself if thats possible.

    I'd appreciate the gerber and BOM files, though!
    Could you add a link to them in the first post?


  • Hardware Contributor

    @Sefi-Ninio - Soon as i get home from work tonight i will get that sorted for you. However i do advise you waiting for revision 3 to come out as currently a new sketch/program can't be uploaded to the uC while the radio is attached.



  • @samuel235 said:

    @Sefi-Ninio - Soon as i get home from work tonight i will get that sorted for you. However i do advise you waiting for revision 3 to come out as currently a new sketch/program can't be uploaded to the uC while the radio is attached.

    Thanks!
    When do you think rev. 3 will come out and tested?


  • Hardware Contributor

    Depending on my full-time job workload, I'm hoping to have the designs completed and sent off for manufacturing by sunday, but then we face the 3 week wait for the shipping, and then the testing +/- a week for constant testing measures.


  • Hardware Contributor

    Other than re-designing pretty much all of my board to allow for jumpers on the SPI lines that collide with the nRF24 lines, to allow for SPI uploads, how else would you go about this?

    The other option would be to run with a 8MHz external crystal to allow my FTDI Serial header to upload sketches. Which if i'm honest, I'de rather not do due to power consumption (If it was a case of using a 16MHz crystal the power consumption would be worth the clock speed increase to get the uC back to sleep quicker, but on wake the uC only have one thing to process then it will go back to sleep anyway, it isn't like it has a lot to process before sleeping again).



  • OK then,
    But a thought: if instead of soldering the radio to the PCB, we solder female pins? That way we can easily detach the radio when we want to flush new sketch and attach again.


  • Hardware Contributor

    @Sefi-Ninio - This was a plan of mine right from the start as stated in a few of the early comments. However, to me, this is not an option due to the height restrictions on the board. I really want to keep this as thin as possible to accommodate for various 'new' style switches that take up more than normal ones in terms of the depth of the back box.

    I would turn the radio round and stack it on top of the coin-cell but i do not want to be battling with any interference, it will have enough to contend with being nested inside of a metal backbox as it is.



  • @samuel235
    While we're on the subject of switches - how is it that you are able to control the switch without a relay on board?


  • Hardware Contributor

    The light switch board itself sends a signal to my controller, that then triggers my other node (relay with button actuator node) to toggle on or off. I've attached a image of my other node that we speak about here that the one side of the relay is connected to my lighting circuit and then i have another switch connected to that node to be able to locally switch the light in case the controller goes down for some unknown reason.
    0_1457460534399_image.jpg



  • @samuel235 said:

    So here we have it guys, Revision 2 is now complete, tested and working perfectly! Its been a grueling process but so rewarding. I plan on making a few tiny little changes, including some headers/jumpers to allow ISP uploads while the radio is attached and pull-up resistors to the switch lines. I will get these all ironed out in the next few days and get the designs sent off to get the final boards manufactured. However, I don't feel that there is a great rush for this last board as the upgrades are very minor ones that won't effect its usability right now. The files on the original post are all up to date and relevant including the schematic. I'm yet to test the current draw, I'm trusting that it is sleeping in between the switch toggles, would this be tested via the current draw, if so where should it be measured to confirm this?

    Here are a few photographs of the final board attached to a switch plate:

    2_1457169881232_IMG_7361.JPG
    1_1457169881232_IMG_7360.JPG
    0_1457169881222_IMG_7359.JPG

    But here, you show the PCB connected directly to the switch, right?


  • Hardware Contributor

    Indeed this is. However I have two switches for this light setup. So, this board is essentially a slave device for the light itself. The relay module that i just posted a picture of is connected to another switch with two length of wire/cable, one connected to GND and the other connected to pin 3. The relay module itself uses the RelayWithButtonActuator sketch, then i can use the local switch and this slave board to control the lighting.



  • OK, so if I get you correctly, the wall switch, when turned on, is detected by the slave module that updates the gateway, which in turn issues a command to the relay module to turn the light on/off. And the slave module detects the switch state change because it makes or breaks the connection.
    Correct?

    That is a smart approach! But for each light you have 2 modules (slave on the switch side and relay on the lamp itself)... That can sum up to a lot of nodes for the entire property...
    More so considering a light with 4 way switch (3 different switches that can turn it on/off) - that would require 3 slave modules and a relay module.

    Also - what are the expectations for battery drain?


  • Hardware Contributor

    @Sefi-Ninio If i understand you correctly, you are correct. However, not every light needs two modules, this has two because i want two switches for this light. For a light that needs only one switch i use the locally connected switch on the relay node itself.

    I'll sort out a rough diagram later illustrating this.



Suggested Topics

0
Online

11.2k
Users

11.1k
Topics

112.5k
Posts