In wall light switch node - Custom PCB

[m26872]

@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.

[Samuel235]

@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?).

[m26872]

@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.

[Samuel235]

@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

[m26872]

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

[Samuel235]

@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

[Samuel235]

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.

[m26872]

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.

[Samuel235]

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?

[Samuel235]

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

[Samuel235]

BINGO!!

We have a working coin cell powered light switch.

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.

[Samuel235]

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.

[Samuel235]

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?

[m26872]

This post is deleted!

[m26872]

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

[Samuel235]

@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?

[m26872]

@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.

[Samuel235]

@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.

[Samuel235]

@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.

[m26872]

@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.

[Samuel235]

@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.

[Samuel235]

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

[Samuel235]

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?

[m26872]

@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.

[scalz]

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

[Samuel235]

@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.

[Samuel235]

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.

[m26872]

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

[Samuel235]

@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.

[m26872]

@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.

[sundberg84]

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.

[Samuel235]

@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.

[Samuel235]

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.

[Samuel235]

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.

[mfalkvidd]

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.

[Samuel235]

@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!

[mfalkvidd]

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

[m26872]

@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).

[Samuel235]

@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.

[Samuel235]

@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.

[Samuel235]

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.

[Samuel235]

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?

[mfalkvidd]

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

[Samuel235]

@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.

[Samuel235]

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

[Samuel235]

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!

[Samuel235]

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.

[jeylites]

@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.

[Samuel235]

@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.

[m26872]

@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?

[Samuel235]

@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.

[Samuel235]

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.

[m26872]

@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)?

[Samuel235]

@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

[Samuel235]

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.

[Samuel235]

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.

[Samuel235]

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.

[m26872]

@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.

[Samuel235]

@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.

[m26872]

@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.

[Samuel235]

@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:

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

[Samuel235]

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.

[Samuel235]

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

[Samuel235]

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.

[Samuel235]

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.

[Samuel235]

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:

[Sefi Ninio]

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?

[Samuel235]

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.

[Sefi Ninio]

@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...

[Sefi Ninio]

@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?

[Samuel235]

@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.

[Sefi Ninio]

@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?

[Samuel235]

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.

[Samuel235]

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).

[Sefi Ninio]

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.

[Samuel235]

@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.

[Sefi Ninio]

@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?

[Samuel235]

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.

[Sefi Ninio]

@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:

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

[Samuel235]

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.

[Sefi Ninio]

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?

[Samuel235]

@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.

[Sefi Ninio]

@samuel235
Thanks, I'd really appreciate that!

Saw you added the gerber files, thanks for that. Could you also provide the BOM file?
a couple more questions, if you don't mind:

1. Do you know how long the battery is expected to last before it needs to be replaced?
2. Does the module support GPIO pins as well, for some sensors to be connected?

Thanks again for taking your time to help!

[Samuel235]

@Sefi-Ninio - I will get the BOM uploaded when i get home again. This full-time job really does get in the way of my 'MySensors Life' ahaha. I'm sorry, i forgot to get the BOM last night.

To answer your questions:

1. The only calculations i've done are based on Maniacs workings regarding coin cell powering the uC with an led and rf module. He worked out it should last as long as the battery does, he claimed it used less power than the battery discharge rate. So around 1 year 4 months he calculated. With my current plans for revision 3 having an external 8MHz crystal on board, it should still remain at around that length of time.

2. It doesn't unfortunately since this was designed to be a minimal sized board that fits in the most shallow socket box I work with, i'm a building (plasterer and tiler) by trade and as this is the smallest back box we generally use in the building trade i wanted it to fit in without issues. It was designed to be just a light switch, i did have enitial thoughts to be able to interface the switch with a motion detector and even a temperature sensor to feed back to the controller the temp for the room. But i have a much bigger and more productive module in the design phases at the moment to handle this for each room. I will release another thread based on this new module soon.

[Samuel235]

This is my current setup @Sefi-Ninio. The controller is an obvious one for you. Module 1 is currently just an arduino nano connected to a SSR with a NPN transistor (serving as an amp, just to relieve the arduino from harder work than needed to turn the relay). I will at some point have this all on one board, this is designed to be placed in the ceiling close to the light itself. Depending on your needs, this can run either of the MySensors sketches, Relay or RelayWithButtonActuator. I have chose to have mine run the second, so i have a locally connected switch to this module to operate the light from upstairs, this will work whether or not the controller is alive. If you only need one switch and can run a cable/wire, this is your best bet. If not you can either use my board as a 'wireless switch' or as a slave switch for the light.

My board will enable you to control the light module through the controller, however if this controller goes offline, obviously my board will not work. So, if do only need one switch and can run a cable from the light to the switch go with my first example, if you need a secondary switch or even just a case of a wireless switch then go with my board.

[jacikaas]

@samuel235

Hello, I'm also very interested about light switch, which is connected to controller, topic. I'm freshman at MySensons comunity, so don't judge me if I have silly questions

How You was writting in Your last posts, it is possible to use same PCB like RelayWithButtonActuator sketch. Please corect me if I'm wrong. If I want to control 1 light bulb with 1 button, then I connect solid state relay (SSR) to SW1 and button to SW2.
Questions:

1. Am I right with this description?
2. SSR needs 5VDC input, so in same circuit we would need a step up from 3VDC to 5VDC. But if we were using step up, does 3V battery still have long life (about 1years and 4 months theoricaly)?

Another questions with the look ahead of same project. I think it will be interesting @sundberg84 too.
I was thinking how to put everything in one place with same priorities: safe and small as possible node.
I drew an example:

From here I have few questions too:

1. I ordered SSR G3MB-202P and in datasheet there was written that it has snubber circuit already. So do I need another snubber circuit near the thermo fuse?
2. What would be smarter if we want to make 'universal' PCB for at least 4 switches with buttons: to integrate SSR relays into PCB or make just the connections, like in already made @samuel235 PCB like SW1 and SW2?

Thanks for answers!

[Samuel235]

I'm currently attempting to find a solution to my ISP uploading with the radio attached dilemma.

My initial thought was to have 3 sets of 2pin headers with jumpers on, then remove the jumpers when you need to upload through ISP. But I'm really struggling to do this with the size of the board.

My next thought was to have 3 sets of Surface Mount header pads, then solder them together, then if i needed to use ISP, just de-solder this connection with solder wick, then solder it back together once ISP connection is complete.

The only real need that we would need to upload to this board would be to change the node ID if its set manually (which i do) or to update the sketch with more up to date solutions. The only way around this would be to use a controller such as MysController where you can do OTA uploads, but this would require me to have a crystal on board to allow the use of FTDI to get the bootloader and sketch on in the first place. Am i correct in thinking this, or is there a way to upload just a sketch to the uC through ISP where it allows a bootloader to be present on the uC, as far as i understand when you 'upload using programmer' it uses all of the uC's flash for the program you're loading.

[Samuel235]

@jacikaas

Firstly, thank you for showing so much interest!

To answer your questions:

1. Yes you're correct, in theory.
2. In my relay module i use a NPN transistor to bring the load off of the arduino/uC itself and to create a 'boost' for the SSR to properly register the switch. However, i do use a standard SSR, not a on-board style one. (this is the one i use).

Me and Sundberg have shown interest in each others projects, hopefully soon i will be moving onto a module that will incorporate in-wall powering for itself and its sensors, that i hope to work with @sundberg84 to develop a solution that i have a feeling many of people will like here.

Your next questions:

1. I'm not very confident in answering this question right now and i hope that Sundberg will assist you here with that.
2. The smart approach (Which i do plan on creating at some point) would be to create a board that has the relays on board along with screw terminals for 4 switches, so one ground and 4 digital input pins. Because these switches will be local to the relays, the board itself wont need to sleep at all, so then this means the only limit on the amount of switch you use are the amount of pins available. Right now my limit of 2 switches is dictated by the amount of interrupt pins we have on board of the ATmega328p-au. If the module sleeps to save energy the only way to have a switch work is to attach it to an interrupt enabled pin, which we only have two of.

There seems to be a slight miss understanding with a few people around here on the duty of this module. This is simply a slave to a relay module because i can not round a cable/wire all the way from the desired location of my relay module, acting as a second switch as i also have a locally connected switch to the relay module, shown in my previous image/sketch.

[Samuel235]

Battery voltage measuring investigations and monitoring methods are now being discussed at http://forum.mysensors.org/topic/3398/another-battery-monitoring-thread/5. This will enable me to have the controller act accordingly when the battery is running low, even have an indicator on the switch itself to let us know when we need to replace the battery before it is too late and we can not use the light switch any more.

Please be sure to add your input on this topic to help us develop this product further.

[Samuel235]

I'm currently researching into capacitive touch sensing. I'm very tempted to create face plates from a 3DPrinter and enable it to have multiple capacitive sensors behind this plate to allow the use as a light switch. This will be an additional option, not necessary for this PCB to work. You will still be able to use a normal switch connected to the PCB. Just would be different software, potentially.

[Samuel235]

Project has been uploaded to https://www.openhardware.io/view/48/Homini-In-Wall-Battery-Powered-Light-Switch-Module

[Sefi Ninio]

@Samuel235 Any news regarding the new revision?

[Samuel235]

@Sefi-Ninio said:

@Samuel235 Any news regarding the new revision?

I'm struggling with time at the monent due to my full time job. I'm currently working on the upload issues. I feel that its the bootloader not matching the avr settings correctly with the upload speeds. @GertSanders has given a couple of bootloader examples for me to try which i will start testing tonight on that for you guys.

[Samuel235]

Currently experiencing some issues with what we speculate to be a fuse burning issue. I'll be troubleshooting further today. Will keep updates coming.

[Sefi Ninio]

Is that related to the circuit for battery level? Or something else?
What are the differences between the current rev. and what you are working on now?

[Samuel235]

@Sefi-Ninio said:

Is that related to the circuit for battery level? Or something else?
What are the differences between the current rev. and what you are working on now?

It is concerning the serial upload issues i was having. The current revision doesn't include a bootloader and then therefor we can't upload via serial adapter. This in turn makes it unable to program anything once the radio is soldered directly to the board. I'm currently in discussions with GertSanders to try and figure out the issues with my bootloaders. Once this is sorted i will be able to program and debug the node through the serial interface/monitor.

The next step will be to include a basic voltage divider method of reading the battery level i think. I did do various tests about a month ago and i will re-evaluate the situation on that. I may be a simple voltage divider solution or i may go for some exotic method. Even though the power consumption is slightly more heavy on the voltage divider method, i think i will go ahead and choose this method because of its simplicity for new users to just solder a couple of resistors on board. We will see.

I do have another project/module in the design phases and a topic thread located here.

[Sander Teunissen]

I have a problem finding the right wall switch. Normally they are all laid out for 230 volts, making them really big and requiring a lot of depth. Does anyone have experience with low voltage switches, which look nice and can be used for such projects ?
Thanks !

[Samuel235]

@Sander-Teunissen, I have these running on a coin cell battery and the sizes for the overall board are: Height: 16mm, Width: 26mm, Length: 48mm. Please note that these sizes are that of the module without insulation. My current working node has its back covered with some fabric to stop it shorting out on the metal backbox. I need to come up with a solution for this. When i order my 3D Printer i'm hoping to fashion some sort of shielding for the rear.

[Samuel235]

I'm currently waiting on some more components to get this module up and running with thanks to @GertSanders providing the bootloader. All being well we will have it completed in the next month to be running with the radio and allowing ISP and FTDI/Serial uploads with the radio all connected.

Does anyone have any feature requests for this module other than simple battery monitoring?

[jeylites]

Just wondering, any of you guys looked into touch switches like below