In wall light switch node - Custom PCB
-
Good morning guys, just to keep the topic updated with the latest info on this project;
I'm still currently designing the board, trying to move parts around and route the traces. Because of everything being so cramped I'm having a real hard time getting this done. I'm having a couple of issues here where i can't get traces from certain points (top left corner) out and around the through-hole components so i will need to be moving some things around again, but I'm constantly pushed on a cramped space to physically get this into the light switch. One of the biggest issues i have is the terminal block, I may remove this and just end up soldering the switch cable directly to the board. The other issue i have is a software issue with eagle and ITead manufacturer, I'm creating routes with >8mil thickness (the website says that 6mil is minimum), then using their checking DRC file, and its throwing back errors relating to the trace width, however if i create the traces in 10mil its fine. However, there is just no way at all i can get away with 10mil :(
Today's agenda:
-
Remove screw terminals.
-
Relocate the micro controller under the nRF board, not under the antenna section though.
-
Relocate some of the components around the top of the board to allow traces through.
If i could get some feedback from you guys on the following, it would be appreciated.
-
Do you think I might be able to route/trace on the bottom layer under the antenna section (Antenna will be sitting about 2-5mm above the top layer) without receiving interference.
-
What do you think about my DRC Check errors? ITead say >6mil but i get errors on 8.5/9mil.
-
-
hi @samuel235 Check the rules spacing between traces. Trace width needs to be minimum 6 mil, but space between traces also has a minimum, maybe this is set higher ? I have used this DRU file and so far always had good boards from manufacturers.
Gert_Sanders.dru
Maybe this helps your tracing issue. -
hi @samuel235 Check the rules spacing between traces. Trace width needs to be minimum 6 mil, but space between traces also has a minimum, maybe this is set higher ? I have used this DRU file and so far always had good boards from manufacturers.
Gert_Sanders.dru
Maybe this helps your tracing issue.Good evening @GertSanders - There is nothing else on the board, I'm literally testing this on a clean board file, nothing on it at all. Just 1 wire. So there for there is essencially nothing to make a spacing issue around the wire. I have just tried to do it on any other layer than top or bottom and it doesn't create an error.... Is there any area of the DRC checks that only apply to the width of the top/bottom traces?
-
hi @samuel235 Beats me, if there is only 1 wire then maybe you have a conflict between the net class and the DRU. But I do not know what would be the issue without trying the same DRC check on your board file.
-
hi @samuel235 Beats me, if there is only 1 wire then maybe you have a conflict between the net class and the DRU. But I do not know what would be the issue without trying the same DRC check on your board file.
@GertSanders - I have just tried your DRU file, its doing it for that too.... Your minimum width and spacing is set to 6mil, i've ran my routes in 8 and 12.
EDIT: Turns out you were correct in advising the net class conflict, i went into the net class editor and it is set to 12mil so i changed this to 6 to double check, and it works perfectly. Can i leave this at 6 without any issues or is it there for a specific reason? I'm going to have a little research on these net classes because i honestly don't understand their purpose when they are set to a value above that of a custom DRC check.
-
hi @samuel235 The netclasses allow you to differentiate trace widths and spacing automatically when using the autorouter. If you do nothing, then all traces are routed by the autorouter according to the DRU. In the Netclasses you can overrule the default trace width and spacing to be respected by the autorouter.
When you check a trace (checking it's attributes) you can see to which net class it belongs. It is mentioned at the bottom.
Why different netclasses ? For example if you use power lines on your board, you could want them to be wider and have more clearance from other wires. To be able to check that the extra clearance is respected, you can define extra clearance in a net class called "power" and then make those wirelines for the power net member of the net class "power". If you use the autorouter, and you defined a width of 20mil for the power net, then the autorouter will make those traces 20mil wide. If you defined a clearance of 15mil for the power net, then all traces different from that power net need to be routed at least 15mil away from the power trace (e.g. Vcc signal or GND signal). If you trace by hand, then sometimes one could be tracing a signal line too close to a power line, and when doing a design rule check, the net class limitations are taken into account.
-
hi @samuel235 The netclasses allow you to differentiate trace widths and spacing automatically when using the autorouter. If you do nothing, then all traces are routed by the autorouter according to the DRU. In the Netclasses you can overrule the default trace width and spacing to be respected by the autorouter.
When you check a trace (checking it's attributes) you can see to which net class it belongs. It is mentioned at the bottom.
Why different netclasses ? For example if you use power lines on your board, you could want them to be wider and have more clearance from other wires. To be able to check that the extra clearance is respected, you can define extra clearance in a net class called "power" and then make those wirelines for the power net member of the net class "power". If you use the autorouter, and you defined a width of 20mil for the power net, then the autorouter will make those traces 20mil wide. If you defined a clearance of 15mil for the power net, then all traces different from that power net need to be routed at least 15mil away from the power trace (e.g. Vcc signal or GND signal). If you trace by hand, then sometimes one could be tracing a signal line too close to a power line, and when doing a design rule check, the net class limitations are taken into account.
@GertSanders I think I explained incorrectly, i understand that the net classes are for the autorouter and how you can tell the auto route to do different classes for different instances. But what i don't understand is why if i have manually routed everything, why is the drc checker using the values on net classes, is it just as simple as changing the net classes to the board houses specific requirements?
Also, would there be a way to create different profiles for the net classes for each board house, just like how you can create different drc files for different needs?
-
@samuel235 If a DRU file species that two signals need to be a minimum of 6mil apart and the net class requires that different signals need to be 8mil apart, then the larger spacing is what counts. If your default net class has a larger spacing minimum then the DRC of a board house, then you need to follow the net class definition when doing manual routing. Autorouting takes into account the most stringent requirement automatically.
You can have several DRU files, but I do not know if you can link them to specific netclasses.
-
@samuel235 If a DRU file species that two signals need to be a minimum of 6mil apart and the net class requires that different signals need to be 8mil apart, then the larger spacing is what counts. If your default net class has a larger spacing minimum then the DRC of a board house, then you need to follow the net class definition when doing manual routing. Autorouting takes into account the most stringent requirement automatically.
You can have several DRU files, but I do not know if you can link them to specific netclasses.
@GertSanders Ahh okay, that makes complete sense now. So the default is set to Width: 10mil, Drill: 20mil, Clearance: 10mil. ITead specify Width: 8mil, Drill: 0.3mm, Clearance: 8mil, I took these figures from here.
So I am safe to change my net classes to those of the board house to run the checks and then revert them back once i generate my gerber files? Or have i miss understood?
-
@samuel235 You can change the defaults to the values of the boardhouse and leave it at that. When generating the GERBER files, the DRU or net class values are no longer important. You only need the values when checking against design rules.
-
@samuel235 You can change the defaults to the values of the boardhouse and leave it at that. When generating the GERBER files, the DRU or net class values are no longer important. You only need the values when checking against design rules.
@GertSanders said:
@samuel235 You can change the defaults to the values of the boardhouse and leave it at that. When generating the GERBER files, the DRU or net class values are no longer important. You only need the values when checking against design rules.
Awesome! I shall get it checked and posted here in a minute and hopefully I'll get it ordered tonight :)
-
And the final designs are shown below. As you can see the one on the left is without the ground planes and the one on the right is with them. If anything is jumping out in terms of errors or discrepancies, please don't hold back, let me know ;)
-
UPDATE!
Just a little update to keep you all posted; I have sent my Gerber files off, they have been confirmed to be of the correct format and my boards are now being produced. I ordered the parts last night, enough for backups/errors, soon as everything arrives i will get this made up and give you another update on the situation of the board. The only thing i wasn't comfortable with was the price of the screw terminal and the fact i used a through hole capacitor for the 100uF (C7). The next revision of the board i will be using a surface mount 100uF capacitor for this, now i managed to find it. The terminal for the switches, I'm looking at maybe having a crimped push connector on the switch that just slots onto some sort of header pin on the board instead of a screw terminal.
Either way, Homini Light Switch Node Version 1.1 Revision 1 is on its way!
-
I have just received confirmation that the board house has released the PCB's. Lets see how long these take to get here! Itching to get this module on the move again. I will be back soon as they get here, don't go anywhere!
-
UPDATE!
I have just received all components for the boards, we're just waiting on the boards themselves to arrive from ITead Studios.
Time to get this project moving!
-
While waiting for my boards to arrive i decided to create a housing for my gateway including flashing status LEDs. Its in no means a finished product, but i feel its enough to house the gateway components while i'm building my network to save any incidents destroying the parts. Within the next few days i will get a guide up with images and maybe a video of the LEDs and their function up on a hardware guide topic.
-
So then, we have another update!
UPDATE!
The boards ave arrived safe and sound, i have populated one of them with everything apart from the nRF module. So, its time to get the bootloader burnt. This is the daunting task for me, i have no idea what i am doing here, so if you guys feel like you could give me some helpful pointers in the right direction I would really appreciate all the help you can offer.
-
Hi! Depending on which bootloader you want, but why not go with the MySensors with OTA updates by tekka?
http://forum.mysensors.org/topic/838/windows-gui-controller-for-mysensors/75If you want the original arduino bootloader: https://www.arduino.cc/en/Hacking/Bootloader?from=Tutorial.Bootloader
-
Hi! Depending on which bootloader you want, but why not go with the MySensors with OTA updates by tekka?
http://forum.mysensors.org/topic/838/windows-gui-controller-for-mysensors/75If you want the original arduino bootloader: https://www.arduino.cc/en/Hacking/Bootloader?from=Tutorial.Bootloader
@sundberg84 - I was reading that exact post from tekka as you posted this. However, i'm probing around on my board and found for some reason my 3v line is 0.24v. So I have to do some investigation work on that this morning. Hoping the bootloader will be a piece of cake once the hardware is working as should be.
-
Hi! Depending on which bootloader you want, but why not go with the MySensors with OTA updates by tekka?
http://forum.mysensors.org/topic/838/windows-gui-controller-for-mysensors/75If you want the original arduino bootloader: https://www.arduino.cc/en/Hacking/Bootloader?from=Tutorial.Bootloader
@sundberg84 So i have my hardware issue corrected now. Am i reading Tekka's instructions correctly, this new board is to be connected through serial to my gateway and then programmed essentially by the gateway through MYSController which is connected to my gateway via ethernet? Does that sound correct?
