Topics created by AtomicGrog

Thanks, Didn't spot those, mainly because they looked like 5v > 3.3v in the heading. I'll maybe buy some of those plus find some of the 5V ones i see in the manufacturers spec sheet.

Minimum? Well, you need the 3 fixed SPI pins and 2 more (CSN and CE) to run the radio (at least in the normal manner). And whatever pins you need for sensors and actuators.

Still digging away here, and confused by what I see as a conflict regarding the physical layout of the ethernet shield and the documentation when used with the Mega. The physical layout (http://shieldlist.org/arduino/ethernet-v5 for example) clearly shows the range of connectivity, when combined with a mega (http://www.onemansanthology.com/images/arduino/Arduino-Mega-2560-with-ethernet-shield-1024.JPG). It's clear that the high end IO pins are not connected. The documentation however states that when combined with a Mega that the ethernet shield uses different IO pins for communication (http://arduino.cc/en/Main/ArduinoEthernetShield "Arduino communicates with both the W5100 and SD card using the SPI bus (through the ICSP header). This is on digital pins 10, 11, 12, and 13 on the Uno and pins 50, 51, and 52 on the Mega. On both boards, pin 10 is used to select the W5100 and pin 4 for the SD card" How does the shield/mega combo achieve this? or is it simply a documentation flaw? and is it potentially the reason for the hanging I'm experiencing due to misconfiguration.? I'll play around tonight with the mega stated io pins to see if it works.

Don't know if it's the same problem but I found out the hard way that it's not possible to upload something to a Nano (or maybe all boards with USB) when BOTH the USB and the serial port (directly via TXD/RXD) are connected to a computer. The IDE says amongst others that "programmer is not responding". So make sure to disconnect the TXD/RXD connection from your computer before uploading something via the USB-connection. If this is not the problem you have then I don't know what else can cause your problem...

@AtomicGrog said: Cross fingers that the latter releases open up the API (A lot...). Yeah, it's a pity they don't open up their API a bit more. The problem is that it won't allow you to keep an outgoing socket open all the time. Also no way of pragmatically create devices (the last time I looked). One solution could be to have the gateway "ping" a HC2 device when a message is available over http-api. The device then open the socket to receive the message from gateway. Hackish .. yeah I know. Yes, the protocol is the same over an ethernet socket.

Sort of does. I'll checkout the library and dig a bit further into the thread.