@TD22057 : I will look at it too. I like asynchronous, often the best way ;) There is something I wanted to try but never had time yet! http://oosmos.com/intro Maybe you already know it ??? Interesting stuff too...

for grid, I would add grid pitch depends on the board density. If dense, a big pitch is not very doable ;) An important ulp : zoom_unrouted.ulp to check if you have airwire. so much things to say... Nice post :)

@lafleur said: It would be nice to have a .PDF of schematic, make it allot easier to view than to load a CAD program... Done. Added to the repository and the openhardware page.

Thanks - that makes sense. It's probably short lived - micro processors are coming with more and more memory all the time so in a few years it won't matter at all for most things. Regarding the LED's - so does that mean the "approved" way to handle that is to just go in and edit the MyLeds.cpp file? I was hoping to avoid editing anything in the MS library because it becomes very hard to track source code configurations between different builds.

There is several alternatives in aliexpress to the memory @Anticimex posted above, SPI interface, same pin distribution, only change the memory capacity and voltage input. (and good prices)

@fets No - the NRF radio has 5V tolerant inputs (you still need to supply it 3.3V on VCC, but it can handle 5V on the signal lines). The RFM radio does not - it needs 3.3V on the signal lines. So the NRF works fine w/ 3.3V and 5V arduino's. The RFM radio needs this modification when used with 5V arduino's. FYI - I found someone who build a small break out board for the radio and had an optional level shifter using a simple resistor network and said it worked great. I liked the idea, but not his board layout so I modified it and ordered some from OSHPark a few days ago. The original board is here. My modified board (no 3.3V regulator or flash support) is here. I wanted minimum width in order to mount the board on the side of a box (thickness dimension). Warning: I haven't tested this yet (order arrives in 2 weeks) so I haven't published schematics or anything else for it yet so I wouldn't order it if anyone is interested. There are tons of RFM69 breakout boards with various features (including one that plugs into an NRF 2x4 socket) if you search for them on OSHPark.

I've been planning on using JST PH (2.0 mm pitch) connectors on my custom PCB's to connect the external connectors (GX12, 3.5 mm headphone jacks, 5.5 mm power sockets) from the sensor case to the board. They're nice in that they're fairly small, polarized, and cheap. But - you need to buy a good crimper - the pins are incredibly tiny. I almost decided to by the plugs with wires attached because they're so hard to crimp. None the crimpers I own was small enough so I ordered the (Engineer PA 09)]http://www.ebay.com/itm/Engineer-PA-09-Mini-Molex-Amp-JST-Crimp-Tool-Wire-Terminal-Crimping-Pliers-/252030460510?hash=item3aae2fa25e] which seems to be the cheapest "good" option. Another option on the board (I wouldn't use these on the sensor case) are Dupont 2-pin connector. These "Dupont" connectors require a female pin (which is also really cheap) and push on to standard 0.1" pitch pins on a PCB (like the 4x2 NRF radios). They have the advantage that they use less space than the JST connectors but are not polarized. Search for "Dupont connector" on ebay to find tons of options. I can't decide if the easier crimping and less board space are worth the risk of mounting connectors backwards and potentially wrecking components.

Ok, patched the inversed behaviour and fixed the new config option. https://github.com/mysensors/Arduino/commit/cb83bfbdb3ed32ef57040cff9954b390ec9a2528

@hek said: @TD22057 Because defines declared in the sketch isn't visible in the cpp files. The Arduino build system isn't exactly the best on the planet. FYI: I found a trick here: http://gammon.com.au/forum/?id=12625 that allows for more normal C/C++ development while still using the Arduino IDE for builds. Basically you create an empty .ino file with any external library include files in it. The IDE will happily rewrite that file and pick up those libraries. Then you can put the regular code (loop(), setup(), etc) in another .c or .cpp file and it will work properly. So you can put #defines or definitions ahead of include files and they work since the IDE only rewrites the .ino file. I've started using this for a sketch I was writing because I needed an enum in the prototype of local functions which the IDE kept screwing up. Works great and still allows the IDE to be used for building/uploading. As far as MySensors goes, this would allow you to define the SOFT_SPI macro locally in the sketch and then include the files that use it which makes it a lot easier to maintain your code. Especially when I come back to this in a year and have to remember how I built everything.