Posted: September 17th, 2012 | Author: admin | Filed under: Uncategorized | Tags: nanode | Comments Off
A new version of Optiboot for the Nanode is available, and you can update your Nanode with an ISP programmer. It’s built from the latest and greatest optiboot source which fixes a couple of bugs and makes some important improvements.
- Supports the Watchdog Timer
- Blinks the Nanode LED (on D6) during upload
One usage change: when using the Arduino IDE, select “Uno” as the board, not “Duemilanove”.
All Optiboot programmed Nanodes sold by Wicked Device will be using this new version.
Posted: November 7th, 2011 | Author: Vic | Filed under: Software | Tags: advanced, debug, howto, nanode, network, software | Comments Off
I want to spend a couple paragraphs writing about Networks and debugging code running on the Nanode (or Arduino Ethernet for fthat matter) that uses them. I realize this blog entry is not for everyone, and probably will get it’s share of <yawns>, but it’s super important knowledge for when everything doesn’t go your way on networks. With Arduino sketches, you are kind of stuck with
Serial.print(...) and LEDs to get insight into what’s going on, but that’s really pretty ineffective when it comes to network interactions. Honestly, for most users the network stuff better “just work” or they are going to be turned off pretty quickly. I , however, am not one to throw in the towel when the networking stuff doesn’t work, and hopefully I can shed some light onto what can be a shadowy space in the programming / debugging landscape. There’s no substitute for using the right tool for the job.
So given that printing to the console can only get you so far with network code debugging, what is a perplexed programmer to do? Well your best choice at that point is to look at what’s going on “on the wire.” In most realms, that means busting out an oscilloscope or logic analyzer, but in the networking world, we have much better / more appropriate tools available for the job. There’s an excellent, indispensible, and free(!) program called WireShark that you can download for just about any platform. WireShark allows you to capture all the traffic on any Ethernet interface (e.g. your network card) and dig into the details of the packets, which, I might add, it conveniently parses out for you for all but the most obscure protocols. You can also set up your capture with filters on pretty much anything you can imagine related to the packet contents (MAC addresses, IP addresses, whatever). And get this, you can check a box in the capture that will have your network card capture all the traffic that it sees (not just the stuff destined for it).
Here’s the rub, though. Unfortunately (or fortunately depending on your perspective) most networks today are equiped with “smart switches,” which eliminate collision domains, which means your network card only ever “sees” those packets which are legitimately destined for it (or broadcast / multicast). So while Wireshark is an awesome tool, it alone can probably not help you debug what’s going wrong with your Nanode software. To unleash the debugging power of WireShark on your Nanode, you’re going to need some “dummer” hardware, namely an Ethernet Hub. Good luck finding one at a retail store – I had to resort to the E-bay for mine, and got an 8-port hub for about $10.
A Hub is very similar to a switch in that it gives you more places to plug into your network. The big difference with a hub is that it internally connects all the ethernet wires together (well sort of) so that all the devices connected to the hub get to “see” each others packets, unfettered by the intelligent filtering of a switch. So if you plug in the ethernet cable from your computer into the hub, plug in the ethernet cable from your Nanode into the hub, connect your hub to your router, and run WireShark, both your computer and your Nanode should be able to get “on the internet.” More importantly, your computer running WireShark will be able to “snoop” on the internet traffic going to and from your Nanode! Now we’re in business. Often times you can look at what the network traffic is supposed to look like using your computer (by filtering on traffic coming to/from your computer’s MAC address for example) and all the fancy-pants network tools that come with it (especially if you’re on a linux box), then compare that to what happens when your Nanode participates in an analogous network exchange (by filtering on the Nanode’s MAC address for example).
Armed with these tools (and some practice, and some reading about protocols), you’ll be able to get to the bottom of your network problems in no time!
Posted: September 12th, 2011 | Author: admin | Filed under: Nanode | Tags: bootloader, nanode | 7 Comments »
As you may know, we have been working on a new bootloader which lets you upload sketches over Ethernet. Being able to upload a sketch from anywhere has a bunch of obvious advantages. Here is a video of an early version bootloader which goes and fetches a sketch from a TFTP server and burns it.
Ethernet Bootloader from Wicked Device on Vimeo.
It’s worth emphasizing this is an early alpha build. It currently only works over a local area network, not across the internet, and also requires you to press the reset button on the Nanode**. Still, it seems a good milestone. Next steps are to clean it up a bit, make it a little bit more robust.
** A Nanode is an ethernet enabled Arduino clone available here as a kit.
Posted: August 13th, 2011 | Author: Vic | Filed under: Wireless | Tags: nanode, pachube, sensor, software, wickedreceiver, Wireless, wNode, wReceiver | 3 Comments »
The other day I got my Nanode talking to Pachube! That in and of itself is pretty cool, and it was also pretty easy given that there are a fair number of examples out on the web and a well documented API for interacting with Pachube. I extended some of these examples to use our Wicked Node and post received data to a Pachube sensor feed. I think my biggest contribution here perhaps was a bit of refactoring of the code so that the major chunks are re-usable in future sketches. Maybe some of it can maybe even make it’s way into the EtherShield library. I’ll provide my sketch attached to this post for anyone who wants to check out the details. I also want to share some general knowledge about debugging networks and software that interacts with networks, which I’ll dedicate my next post to.
So part one – the general program flow goes like this:
1. Set Serial to 2400 baud (for radio interface)
2. Initialize the Ethernet interface with a MAC address
3. Get an IP address using DHCP (optional)
4. Initialize the IP/UDP/TCP stack with a MAC address, IP address, and WWW port
5. Set the Gateway and DNS IP addresses
6. Wait for the Gateway to recognize the Nanode
7. Resolve "api.pachube.com" to an IP address using DNS
8. Initialize the Web Client part of the EtherShield library
1. Wait for wireless sensor data to be recieved
2. When data is received populate a template string and post it to Pachube
Pretty simple, right!? Well there is an example with the EtherShield library for demonstrating DNS and a separate example for demonstrating DHCP, and another example that demonstrates Pachube (getting information *from* Pachube actually), but besides the DHCP example, nothing really tied in DHCP; the other examples just use static IP addresses and call it day. So I refactored the code in the DHCP example so as to make the acquisition of an IP address over DHCP into a function call that I could just call from setup(). I insightfully named this function
acquireIPAddress, and I’m pretty sure it will be useful in many a sketch in the future (for me and others I hope). Similarly in looking at the DNS example, it was kind of hard to see how you ended up with a resolved address, so I made another function that I think is a little more intuitive from an API standpoint that takes a null-terminated string as the address to resolves and a buffer into which it puts the resolved IP address. I decided not to get too creative and named this function
I think factoring out these two functions really makes reading the
loop functions a whole lot more digestible to the average human. As a last step I tidied up my code and moved things around so that all the configuration for the sketch is up top, including whether you want to use static of dynamic IP parameters, your Pachube API key and how you format and populate your Pachube post template. If you want to use the sketch as a basis for your own application, you’ll have to download the EtherShield library and WickedReceiver library and drop them in your Arduino libraries folder to get it all to compile.
Have fun getting your Nanode onto the internet and let us know what cool things you’re doing it!
Download the Sketch Here: Pachube_WickedNode
Check out this other blog post for a variation on the sketch that doesn’t use the Wicked Node, but instead posts ADC inputs directly from the Nanode.
Update: 12/14/2012 – The EtherShield library was retired earlier this year in favor of the EtherCard library. At some point I may get around to making another update to this post, but the EtherCard library already comes with a pretty easy to follow Cosm (the new name for Pachube) sketch. As always, feel free to post to our forum if you have questions.
Posted: July 25th, 2011 | Author: admin | Filed under: Uncategorized | Tags: Arduino, ethernet, nanode, pachube | Comments Off
The Nanode is a cool Ethernet enabled Arduino clone all in one kit for sale at $39.95, including shipping, which is a pretty good deal. It Also includes a year’s subscription to Pachube Pro, a $25 value. So all it all it is great value for money.
We have been working with Ken Boak, the inventor of the Nanode, who is based in London and worked with the London Hackerspace to create the Nanode. It has made a big impact there, and is used in projects like the Open Energy Monitor, which I’ll be blogging about in the future.
If you want to find out more about the Nanode, this website has a step by step build, application info, IRC chat and more. We’re really looking forward to doing some fun stuff with it.