Posted: February 4th, 2013 | Author: admin | Filed under: AQE, Software | Tags: Air Quality Egg, AQE, software | Comments Off
Over the weekend I worked on making the color expressions of the Air Quality Egg more… well, expressive. The update is on Git-Hub so feel free to update your software (howto videos) for the Remote and Base units. This is the 1.03 version of both baselines (version number gets printed to the serial console).
As the Eggs have been reaching their destinations, feedback from users indicated that the setup process had some significant holes in diagnostic feedback. The most important of these was that the outcome of the pairing interval was invisible to the end user; the only way you knew that pairing succeeded was that the system started working a couple minutes later. If the system didn’t start working, you were left scratching your head and trying again. So I added an acknowledgement to the pairing behavior, and now there’s clear feedback about the outcome of the pairing interval: after the yellow pulses that signify pairing in progress, three magenta blinks indicate “pairing was not acknowledged” and three cyan (light blue) blinks indicate “pairing was acknowledged.”
The second feedback notable feedback confusion was related to Cosm provisioning. The previous behavior was to indicate solid green when provisioning succeeded, but *only the first time* after that you would never see green again. So now, if provisioning has previously succeeded, you get three green blinks.
In summary, the colors the Egg expresses now come in three “flavors”:
- Pulsing colors are used to indicate normal activity and progress (I know some people find this annoying, but I’m erring on the side of more feedback)
- Blinking colors are used to signify status
- Solid colors are used to indicate conditions that result in a restart
- Blinking/Solid green, blue, and cyan are used as “positive” indicators
- Blinking/Solid red and magenta are used as “negative” indicators
The following flowchart describes the feedback behavior of the 1.03 baseline.
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: 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: June 7th, 2011 | Author: admin | Filed under: Uncategorized | Tags: Arduino, Hack, interrupt, software, timer | Comments Off
I think there are probably a lot of Arduino users out there who either (a) don’t know about interrupts, or (b) don’t know you can use them in the Arduino environment. I will almost certainly be using the Timer Interrupt capability of the ‘duino in an upcoming project that uses Charliplexing (get excited!). I found the following to be an excellent overview and reference in that respect: http://www.uchobby.com/index.php/2007/11/24/arduino-interrupts/
For more “advanced” Arduino users, it helps to keep in mind that at the end of the day, all your source code gets compiled using avr-gcc, so in principle you can do anything with an Arduino that you could do by targetting an ATMega328 (or ATMega168) using vanilla avr-gcc (i.e. use any of the chip’s hardware). For some things it’s harder than for others because the core Arduino libraries implement some of the interrupt handlers (ISRs), but for some things, like Timer2, it’s open season! Other than that you just have to make sure you are not trampling over some other (Arduino) function of the hardware resource you want to hijack . Have fun!
Posted: December 31st, 2010 | Author: Vic | Filed under: Uncategorized | Tags: Arduino, daycounter, software | Comments Off
Happy New Year! I recently decided it was high-time, here at Wicked Device, that we started making some of our “stand alone” products (even more!) accessible to the Arduino community. So for my first trick, I decided to take our Day Counter product and make it easily usable as a general purpose 7-segment display for an Arduino. In the process, I also ended up making a separate library for dealing with the trusty 74HC595 shift register used in the Day Counter project. All I had to do was read the tutorial on the Arduino website, remember how to write C++ classes, and port a bunch of code I had already written for the ATTiny85 for the Day Counter. I was actually really impressed, it wasn’t that hard at all.
The result is some really powerful capabilities for end-users with a neat public interface. Using the new libraries lets users use the Day Counter for whatever they can imagine without having to worry about the details of the Arduino/DayCounter interaction. As a user, all you really want to be able to say is:
- I’m using Arduino pins 5, 7, and 10 (or your favorite pins)
- I want to display the number 57
Read the rest of this entry »
Posted: December 13th, 2010 | Author: Vic | Filed under: Uncategorized | Tags: development, software, tools | 1 Comment »
Have you ever come across a code snippet you really wanted to try out but you weren’t near a compiler? Believe it or not, that happens to me sometimes. It turns out there is a pretty neat free web-based compiler out there called ideone (i.e. Integrated Development Environment One). It lets you paste code (supports 40 programming languages!) into the browser window, compiles and runs it, and gives you the output. It even syntax highlights it for you.
So it’s a great tool for getting your feet wet in a new language or trying out a code fragment and printf’ing its output. Basically it’s a fun place to hack in a sandbox. I like to use it as a lightweight testing environment during prototyping. Check it out, I figured I’d share the love .
Posted: November 15th, 2010 | Author: Vic | Filed under: Uncategorized | Tags: fun, software | Comments Off
I recently stumbled across this really cool way to pass time. It’s basically a “battle bot” simulation environment. You can define your own logic for a robot. Your robot has a “radar,” a “gun,” and a “body.” You can rotate the radar and the gun separately from one another, and move your robot around within the limitations of the environment and its “physics model.” You can write your robot as a Java class (and use Eclipse as your IDE1), or you can use C# .NET if you have some sort of freaky Windows fetish. They give you a bunch of good example robots that do some of the “basic” things you might want to do, like target other robots, evade, and shoot. I recommend reading the Wiki tutorial if you want to get started, I got it all installed and running my own robot class in less than 15 minutes. Hope you find it as entertaining as I do, happy battling!