All controller functions functional! Now I need some remote projects!

This slideshow requires JavaScript.

So I have gotten to a point at which everything for the controller works. SD card, Xbee, BT serial, Shift LCD, PS2, and NunChuck. Pretty awesome. But if all of that code is enabled at once, I would have less than 1k bytes to write actual code to interface with things. In the code I have debugging via serial, debugging via LCD (for the controllers). I do like having debugging for LCD, but there is a problem: the PS2 library takes up 5k bytes. So when I actually build the controller, I don’t think I’ll include a PS2 connector, at least initially.

Breakdown of Sizes
with SD enabled
Everything Enabled: 29024 Bytes
Only LCD debug: 27252 Bytes
Only NUN LCD debug, PS2 disabled: 22550
Only PS2 LCD debug, NUN disabled: 25900
Only PS2 & Nun, no debug: 24690
Only PS2, no debug: 24484
No ps2 or Nun: 20972
With SD disabled
Nun and PS2 disabled:13488
BT disabled + SD + NUN PS2
Xbee: 11910
Everything Disabled:
11886 bytes

I think the optimal configuration would be to use the Nunchuck with LCD debugging information, with SD, XBEE and BT, coming at a total of 22550 bytes, giving me about 7.5k to write my code for all of my interfaced devices.

This has led me to the idea, that my interfaced devices should be giving the controller, the menus it should show. I’m thinking of an initial packet that is exchanged between the two, which has a good amount of strings, that are then saved into flash on the controller, and once data starts arriving, those ‘labels’ of the data will make the data make sense. Another idea is to use the SD card to carry firmware for remote projects, and remotely flash them using the controller on the go, so I can update code for my cars without having to take my laptop down there.

Well here it is: http://pastebin.com/JudSCJNN

Continue reading

Timing tests have begun!

This slideshow requires JavaScript.

Yesterday’s problem, that riddled me for a few hours last night… was that I depended on an array stored in EEPROM to handle the menu system, and for the new AVR’s…. I didn’t initialize the EEPROM. I learned my lesson, I’ll always put a ‘List to do for new AVR’s’ at the top of my projects, so that when I am in that situation again, I’ll look at that list to make sure it works, the first time. Also save often. I was working on the below code, and had it almost finished, when my PC reset. Not fun (Ctrl + S)!

Luckily getting it working was one of the first things I did tonight, the other, was to setup both Wireless Testers (WT) for a timing experiment. They both have 16 MHz resonators, and I want to see how quickly they drift apart with time. So I have a test pin, A0 (PORT C pin 0), that is connected to both WT’s, and a single connected to 3.3V. Each has a 10K pulldown resistor. When I remove the wire from 3.3V, the test starts.

In the test, it gets the current time, compares it to the time the test started, and saves it to a 16GB SD card, and it does this every 100 ms. As I have found in my preliminary testing, sometimes a SD card write can take longer than a second. I have a flag that is set if the time hasn’t exceeded 100ms, at which point it waits until 100ms before taking another measurement. I am curious if as the file gets bigger, will it start to take longer to write to it? Can the arduino handle really big file sizes? I have it running right now, and I intend to leave it running all night.

With both systems working, both LCD’s and SDCards(If I don’t fry it tonight), I’ll start working on the design of the wireless testing plan. Contrary to this test, writing all of the data transferred to the SD card won’t be the objective, the objective will be to test the wireless modules. So a simple time stamp, as well as if the packet was received with the correct checksum, will be sufficient. I will create a simple python script to handle the data, so I won’t have to put it into excel to get the important statistics.

I am really looking forward to making the controller, and all of the little projects that are associated with it. Progress!!!

Here is a code Snippet:
Continue reading

Keep it Simple Stupid – Designing a Simple Menu with Version Control

Yes, I spilled my coffee on my notebook :/  It has mostly dried, so I think it will be okay, but my notebook is a very important tool, since it not only helps me brainstorm, but it helps me document things.

When I was trying to design this new menu system, I thought of many kinds of complicated things. After struggling for over an hour to get a concept I had to work, I took a break.  Instead of trying to answer the question “How do I make a menu system that does all of these things”, I thought of this question: “How do I make a very simple menu system?”

It won’t be as simple as the code bits from the last post suggested, but I do believe it will be easier to work with.  All of the menu things are in the main .ino file, and the only thing that is in the “Library” are the functions to handle the buttons (from an ADC channel, to button pressed).

I’ll go ahead and post what I have now here, although later I will make a repository for it.  And it’s not even done, I still have some work to do on it, but I think it is a step in the right direction, towards simplicity. I’ll be using this menu system to organize functions that I’ll use for the wireless testing.  I’ll also do SD card management on it as well (maybe reading from the SD card and showing it on the LCD :P)

An important note: Throughout my development on this, I use version control (Mercurial) so that once I got to a good space, I could quickly make a commit, and have a place where I can go back to, which I had to on several occasions. Commiting is so easy, that you’ll want to do it often (as you should).

Continue reading

Working on Wireless Comparison Boards – Need a better menu, ironically

This is the main board for my wireless testing experiment. It has 3 buttons, microSD card, 3.3V voltage regulator, and a 20×4 3.3V LCD. I setup the backlight to only illuminate if a button is pressed, since it apparently uses 180 mA to run (I really should have looked at the data sheet before buying these). The idea is that I will mount the wireless device under test (DUT) onto a non-conductive foam next to this, and perform the tests. My menu system will need to be redone, since it not only is hard to work on, but it has been a pain to upgrade to a 20×4 dimensions.

I designed the AdvMenu in hopes that it will help me to create menus quickly.  But in order to create a menu, I have to follow a 5-6 step guideline, which can be annoying if you have a lot to change.  Plus, since you have to modify the library, it can’t be called a true library then, since libraries typically don’t need to be modified.

So I’m going to completely change the AdvMenu.  I’ll be making it into a true library, where your menu system, and functions, will be in your main arduino INO file.  Imagine creating scrollable menus like the following:

AdvMenu.mainMenu(0,(__FlashStringHelper *)PSTR("Option 1"));
AdvMenu.mainMenu(1,(__FlashStringHelper *)PSTR("Option 2"));
AdvMenu.subMenu(0,0,(__FlashStringHelper *)PSTR("Under Option 1, sub 1"));
AdvMenu.subMenuFxn(0, &fxnPtrToAFunction);

All of the menu stuff would happen behind the scenes, which includes being able to call functions if you select an option. This init would need to be run everytime you startup (it will need to be in the setup), but you’ll be able to dynamically update menus just by making the corresponding call. Of course, the final product may be something totally different, but this is what it is looking like so far.

The first version helped me get something done and out the door, but I see now that it needs to be redesigned. Which is great news, since I should end up with something wonderful.

Wire wrapping is one tool that should always be in your toolbox

This slideshow requires JavaScript.

I see so many people reaching for the soldering iron to make simple cables, when one of the simplest, and strongest, ways of joining two metal posts, is by wire wrapping.  Wire wrapping is a technique of wrapping the bare conductor of a wire around a metal post and has been in use for over 50 years.  It is used extensively in avionics and the space industry for its superior ability to handle vibrations and stresses.  A simple wire wrapping tool can be picked up at a local Radio Shack, as well as a spool of wire wrapping wire (cheapest place for both that I have found).  Here is an interesting PDF on the history of it, and why you should consider learning more about this easy way of making solderless connections.

That in itself deserves a post, but I’ve discovered what I’ll be working on for the next few weeks: Ultimate Wireless Showdown!  I’ll be putting 6 wireless modules through a gauntlet of tests to try to determine which has the best bang for the buck, when it comes to wireless transmission of data using an Arduino/ATMEGA328.  I’ll be testing the XBee Pro Series 1 60mW, XBee Series 1 1mW, RFM12B, Bluetooth Serial, nRF24L01+, and RF2400P modules.

I have outlined the test setup here, so read up on it if your interested, or on any of the other projects I have in the works.  By actually comparing these modules in real world situations, I’ll be able to see which module I should base my future robotic projects on.  So tomorrow I’ll start to get the two boards assembled, sporting a lovely 3.3V LCD and microSD card, with a few buttons for fun.  Which is why I felt it was necessary to improve my serial cables, as shown in the pictures 🙂  Future, here I come!