Getting X-Bee going on my Mac / Arduino

I got a couple of X-Bees and adapters from Adafruit. I sharpied one of the Xs black so I could tell the difference between them. I got some hints from Ashley Hughes and from the Adafruit tutorial. Both valuable!

Note the black X, and how the I2C pins line up in this orientation. Power is coming in the back

I installed Coolterm from http://freeware.the-meiers.org/ so I could run a serial terminal outside the Arduino IDE.   

I installed the FTDI drivers from http://www.ftdichip.com/Drivers/VCP.htm so that the FTDI cable would interface with my USB and behave like a serial port.

I started coolterm, picked the right port under options, connected and could get recognition of +++ [No Enter] with an OK. I started with a series of queries and responses on the black X-Bee. (With the X blacked out, same for the one with the B blacked out)

Things I Type [normally followed by Enter] that don't show up on the terminal
        Things The black X-Bee Sends Back

+++[No Enter]
        OK
AT
        OK       So the X-Bee is responding, but it will time out and need a +++ again soon
ATID
        3332      is what the PANID was set to before (out of the box default)
ATID2711
        OK        Sets PANID to 2711, could be any 4 digits, but must be the same for all units on network
ATMY
        0            This X-Bee is unit 0
ATDL
        0            The destination X-Bee is unit 0
ATDL1
        OK        Set the destination X-Bee to unit 1
ATBD
        3           The baud rate is set to 9600 and I'll leave it there
ATWR
        OK       Writes all the changes to permanent, otherwise they would disappear at power off

Disconnected, then unplugged USB and changed over to the white X-Bee. Did all the same things, except ATMY1 and ATDL0 to reverse the roles.

Then I connected the black X-Bee RX and TX to RX and TX on an Arduino (turns out they should be TX-RX, RX-TX). Something was happening, but not the right things. http://www.ladyada.net/make/xbee/arduino.html suggests the programming communications won't work to upload to an UNO (just with a Duemilanove bootloader), or that the baud rate should be higher (ATBD6 - 57600 for a newer Arduino with a '328). One problem at a time...

void setup() {              
  Serial.begin(9600);
  delay(1000);
  Serial.println("Hello World! Now to Echo");
}
void loop() {
    if(Serial.available()){
      char c = Serial.read();
      Serial.print("Another new character: ");
      delay(1000);
      Serial.println(c);
    }
}

The code above will echo characters back 1 second after they're sent. Loaded and tested over USB, then disconnected and powered the Arduino by batteries, connected coolterm to the white X-Bee on the FTDI and it didn't work. Switched the connections so that black X-Bee RX went to Arduino TX and black X-Bee TX went to Arduino RX, and things started working.

So now that I have wireless serial at 9600 baud, do I want to get wireless programming working, or just work on wireless links between Arduinos? Start with upping the speed on both to ATBD6 - 57600. And then remember to up the sketch baud rate too... and presto, it works. Up to ATBD7 - 115200 and that works too, but gets flaky, so I'll slow it down to ATBD6 - 57600. (Yes, there's a reason why this might read like a lab notebook ;-) )


Wireless programming seems like a lot more effort with the extra pins to worry about, so I'll tackle that when I need it.

Modifying a Pololu Shield for the Due

The Arduino Due is a 3 volt board all through, except for providing a 5 volt line on the same pin as the Uno. The Pololu Dual VNH5019 Motor Driver Shield for Arduino is compatible with either 3 volt or 5 volt logic, however it takes its VDD from the 5 volt pin on the Arduino headers. To make it safe for the Due I tied the 3 volt pin to VDD on the end of the card (red wire) and cut the trace from the 5 volt pin (lower right near the mounting hole). As a result the logic returns come at 3V rather than 5V, safe for the Due and still works with the Uno.

My first thought (and test) was to jump the 3 volt and 5 volt pins and cut off the 5 volt pin so the board gets all its feed that way. Problem: boards stacked on top of the driver shield may still be expecting 5 volts to drive displays, etc.

I have a feeling there are going to be a bunch of 3/5 volt challenges ahead, but on the plus side, the Due has capabilities we spent about $20K to get in our lab in 1984!

From Pololu's User Manual on 3V systems:

"Logic power at the same level as your controlling device should be supplied to the VDD pin. This will typically be between 2.5 and 5 V, but the VNH5019 motor drivers are guaranteed to treat any logic input voltage over 2.1 V as high. The only purpose of the VDD pin is to power the pull-up resistors on the EN/DIAG lines."

and

"Current sense output. The pin voltage is roughly 140 mV per amp of output current when the CS_DIS pin is low or disconnected. The current sense reading is more accurate at higher currents. (Note that while the CS voltage can potentially exceed 3 V at high currents, the current sense circuit is safe for use with 3V analog inputs. The MCU’s analog input voltage will be clamped to a safe value by its protection diode, and only a few hundred microamps at most will flow through that diode.)"

Too much on one board?

5 breakout boards very tightly packed 

I jammed a bunch of breakout boards all onto the same screwshield and managed to trash the BMP085 along the way, from either heat or static. The boards overlap to make everything fit, and the necessary wiring also made the clearances tight.

The end product has a 3-axis accelerometer, feeding 3 of a total of 8 channels of 12 bit ADC, plus one channel of 12 bit DAC. It would also have pressure and temperature if I hadn't fried the board along the way.

The DAC output, as well as the three accelerometer readouts are available on the WXYZ screw terminals.

Cuts down on the wiring mess

TFTLCD 2.8 on top of it all

The ADC are configured for I2C 0x48 and 0x49 and the DAC on 0x62. The green boxes are spring loaded quick release sockets for ground and 5 of the ADC channels. They're a little tall, but it's still possible to fit a display on top to show how the orientation of the board is changing with time.



Of course all of this may be entirely redundant as my long awaited Arduino Due walked in the door late this afternoon, with 12 ADC and 2 DAC and it will run AnalogRead() at 40us / call and 12 bits.

Using a Teensy 3.0 with Adafruit bits

I2C update: Apparently there are issues with the internal pull-up resistors and the Teensy 3.0 requires external resistors connecting both the SDA and SCL lines to logic high. I added 2K pull-ups and things went from flakey to functional.

I got a Teensy 3.0 because it seemed like a good idea, especially with the high resolution ADC. Besides, it's teensy, and that's cool, always cool!

Fired it up with the iMac, downloaded the beta 6 Arduino IDE, and things ran right away.

Attached the 2x16 LCD shield on I2C and the example ran.

Attached the MCP4725 DAC breakout on I2C and the example wouldn't compile because TWBR is not defined. It seems to have something to do with the I2C clock speed. It was only mentioned because the code wanted to change it, so I commented out the change lines in the library cpp and the triangle wave code ran fine.


void Adafruit_MCP4725::setVoltage( uint16_t output, bool writeEEPROM )
{
  //uint8_t twbrback = TWBR;
  //TWBR = 12; // 400 khz
  Wire.beginTransmission(_i2caddr);
  if (writeEEPROM)
  {
    Wire.write(MCP4726_CMD_WRITEDACEEPROM);
  }
  else
  {
    Wire.write(MCP4726_CMD_WRITEDAC);
  }
  Wire.write(output / 16);                   // Upper data bits          (D11.D10.D9.D8.D7.D6.D5.D4)
  Wire.write(output % 16) << 4;              // Lower data bits          (D3.D2.D1.D0.x.x.x.x)
  Wire.endTransmission();
  //TWBR = twbrback;
}

Attached the MPL115A2 Pressure and Temperature breakout on I2C and everything compiles fine, but the answers are way wrong, and constant. I'm not sure why, but the temperature return value is 1023, all bits set, suggesting some sort of handshake problem. The same result shows up on the Uno if you disconnect the breakout board.

It looks like there are different libraries in the internal parts of the Teensy version of the ide, so maybe the variations in the wire.h library are to blame. The adafruit code has tests on the value of ARDUINO >= 100 to determine which wire.xxx calls to use and it may be using the wrong ones. Figuring what's right would require a look at the internal wire library built into the package. (Right click view package contents) I think I'll wait for the beta software to advance a little farther.

Pressure and Temperature over I2C

I picked up the Adafruit MPL115A2 - I2C Barometric Pressure/Temperature Sensor and connected it up using I2C and ran their sample program. First thing I learned is that I really should read the data sheets. The resolution is 0.15 kPa (=1.5 hPa a unit I seldom encounter) and the absolute accuracy is 1 kPa. Thus, values that vary a lot and differ from Environment Canada shouldn't be a surprise. Here's some sample output:

Pressure (kPa): -2929.0664 kPa
Temp (*C): -12035.9 *C
Pressure (kPa): 102.2696 kPa
Temp (*C): 22.6 *C

Note that the large negative numbers are ridiculous, and I don't know where they're coming from. The reasonable numbers seem to be within spec.

So I went to the adafruit forum and looked up the product. Others were having the same problem. That made me think it was software. Following some suggestions, I started messing with the library and found the bug. I fixed it, then posted about the fix, then posted new source code (that actually got accepted) to the code repository, which may make me a geek.

Bottom line: Spend a little more and get the BMP085 Breakout that provides accuracy high enough to detect raising and lowering the board by a metre. Unfortunately it also seem to be fragile enough that I busted one soldering it into a protoboard, so be careful with heat and static.

Driving Bigger Motors

All of the docs on the Adafruit motor shield warn that it's just for low current motors. Motors on 12 V linear actuators need something more like 6 amps at 150 lbs, which is way beyond the motor shield. I'm using this Progressive Automations actuator. The red and black lines are the drive current. The other three are a position potentiometer with blue connected to the wiper.





Enter the Polulu 18v15 motor driver: http://www.pololu.com/catalog/product/755. It comes with the screw terminals and capacitor loose. I added the capacitor a little offset to make sure there's still good airflow to the chips for heat dissipation. Polulu says it's good for 15 amps without a heat sink, so it may be overkill.

I connected it up like this and ignored the fault flags - they never went on.

It works about the way I expected, except that the +5 volt line is an OUTPUT that can provide a few milliamps for additional circuitry. Initial tests set PWMH high for full speed and changed direction with 5v and no connection other than the LED.

Customizing the Logging Shield

In hindsight, two mistakes: not using stacking headers; having the meter stick up too far. Both prevent putting the shield in the middle of a stack where it could be really useful.

It is now over a year later and the RTC has lost about 8 minutes, well within the "minute a month" they advertised for the accuracy of quartz watches back when they were a novelty.

 I started out by assembling the data logging shield per instructions and doing a bunch of experimenting with programming for real time acquisition and logging. The only way to see what's going on on the card is to either watch the LEDs or have it report to the serial monitor on the attached computer, which really limits its ability to function without the computer. I also found myself regularly attaching my multimeter to various pins to see what was going on. A little time and money made the shield more self contained.

A Voltage Display

A DIP switch was added to the prototype area, with all the pins on one side tied to the input of a little voltmeter module. The other side pins connected to digital pins 9 (switch 1) and 3 (switch 2), A0 through A5 (switch 3 to 8). The voltmeter module was hot glued to the SD card housing, with a small piece of sheet plastic in-between.

This gives me switch selectable monitoring of each of the analog inputs and two of the PWM capable output pins. Be sure to set only on of the switches to be on at a time.

Interrupt Push Button

A push button was installed at the bottom right to allow momentary connection of pin 2 to +5 volts to generate an interrupt event.

LEDs for Status

The two LEDs that came with the kit were connected to pins 2 (red) and 3 (green) for additional status indication.

Installing Instrumentation for Dragon III

Circuit board mounted off to the side
of the engine compartment

Terminal block to bring all
the connections up to the bulkhead

I had some trouble with the instrumentation on the engine early in the season, and never had a tachometer, so I decided I would try to monitor them electronically as a challenge. Here's what the actual installation looked like.

The experience of hookup and testing proved interesting. I wired everything up and it worked, giving believable output for the tach, which changed as the engine speed changed in very believable ways, so I felt good. Then I disconnected the tach circuit and the Arduino kept registering the same data anyway! WTF!

Moving away from the engine reduced the indicated RPM and towards the engine increased it. With the input wire on the Arduino unterminated, there was enough electrical noise that it was picking it out of the air like an antenna, with voltages high enough to generate an interrupt. Don't let anything float - pull it high or low!

An additional wire to get the signal from the negative side of the coil.
The coil and wiring create enormous electrical noise!

Boat Instruments on the Way

The instruments on Dragon III are aging, like the boat which will be 33 this year. The senders seem pretty reliable, but some of the gauges are a little sticky and the connections a little dubious. Besides that, there never was a tachometer there, just an opportunity to guess at engine speed from the sound. Today I did a little investigating in the line of getting the temperature gauge to read again. Along the way I cleared out some spider webs and figured out several things.

The water temperature and oil pressure senders are just variable resistors, changing with temperature or pressure. They are each wired as the bottom leg of a voltage divider, grounding through the engine. Both result in around 2 to 3 volt signals that could go directly to an A/D converter.

The temperature sender is about 100 ohms at ambient and drops its resistance with increasing temperature.

The pressure sender is about 89 ohms at zero pressure and... I need to check my notes.

The negative side of the coil is easily available to provide about a 200 volt AC signal that could drive a tachometer. With help from http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1262397180 I came up with this circuit to produce countable pulses.

I hooked up a breadboarded version this afternoon and could see a rapidly flashing LED when the engine was idling. Visible flashing probably means under about 25 Hz. The Atomic 4 will fire on all four cylinders once every two revolutions (4 stroke) so 2 firings per rev. 25/2*60 = 750 rpm or less, which is certainly in the ball park. So I soldered it up on a little chunk of perfboard for some further tests.

In the mean time, I started from the Arduino demo code for interrupts and wrote a tach sketch to count rising pulses on pin 2 and convert them to RPM once a second, with a window for some damping. I tested the code with a push button (hence the debounce check) and by counting from pin 13 and both produce sensible results.


int pin = 13;
volatile int state = LOW;
volatile long last = 0;
volatile long kount[] = {0,0,0,0,0,0};
volatile long per = 1000;
volatile long sper = 0;

void setup()
{
  pinMode(pin, OUTPUT);
  attachInterrupt(0, count, RISING);
  Serial.begin(9600);
}

void loop()
{
  long rpm = 0;
  digitalWrite(pin, 1);
  delay(2);
  digitalWrite(pin, 0);
  delay(2);
  if(millis()-sper >= per){
    sper = millis();
    rpm = kount[0]*30+kount[1]*15+kount[2]*8+kount[3]*4+kount[4]*2+kount[5];
    rpm = rpm * 2 / 4;  // two rotations per power stroke for each of four cylinders
    Serial.println();
    Serial.println(rpm);
    kount[5]=kount[4];
    kount[4]=kount[3];
    kount[3]=kount[2];
    kount[2]=kount[1];
    kount[1]=kount[0];
    kount[0]=0;
  }
}

void count()
{
  // 4 cyl engine at 12000 rpm = 4*12000/60/2 = 400 Hz or 2.5 ms
  if(millis()-last >= 2){  // cancel HF noise by waiting
    state = !state;
    last = millis();
    kount[0]++;
    Serial.print(".");
  }
}

Stable Analog Output

It took me a while to remember about RC circuits. A really key thing is to avoid sourcing any current out of the circuit. Keep the power way down and keep everything that's measuring really high impedance is probably good all-round advice.

Connect a resistor to the analog output (red wire). Connect a capacitor (crimped end positive) from the resistor to ground (green wire). Measure the voltage where the capacitor and the resistor meet (yellow wire) with a high impedance device like an analog input.

The time constant tau = RC is in microseconds if the resistance is in Ohms and the capacitance is in microFarads,  so a 10K resistor and a 33uF capacitor gives tau = 330,000 us or about a third of a second for really smooth transitions. Switching down to a 2.2 uF makes it 22 ms which follows human scale pretty well while still averaging over many PWM cycles at 1 kHz. The graph below shows results for different resistor and capacitor combinations. The direct connection seems to have its frequency response compromised by the other circuits. The 2.2ms yellow squares are noisy, while the 33 ms red exes and 47 ms triangles respond quickly, yet follow closely. The 330 ms grey diamonds lag substantially. The sampling rate wasn't high enough to resolve the PWM, so connecting the dots would give an aliased apparent oscillation frequency.

If you need to drive anything with the with the analog voltage, then it will need something to isolate it from the current draw, like a transistor, or an op amp as a voltage follower.

Movin' Out

Moving upwards and outwards by installing the IDE on my iMac and (I hope) getting the files all on my dropbox account so I can see them from wherever. This gives me a chance to document the process.

Go to http://arduino.cc/en/Main/Software and download the Mac OS X software (v1.01 today). Open the zip file and move Arduino.app to the applications folder. Run it.

Open preferences and set the sketchbook location to ...dropbox/Arduino.

Go to adafruit for the individual product shields (e.g. http://www.adafruit.com/products/243) and get the relevant libraries (e.g. today I got SD, RTClib, AFMotor, and AccelStepper). Download the zip from the github site, then copy the unzipped directory into the ...dropbox/Arduino/libraries directory. Rename the copied library to its base name, e.g. ...dropbox/Arduino/libraries/SD/.

Restart the Arduino App so it can find the libraries. This would be a good time to add it to the launch bar, or wherever.

Make sure to set Tools/Board to the Arduino UNO (or as appropriate) and Tools/Serial to /dev/tty.usbmodemfd141 (or as appropriate).

Once that was done the new installation appears to be working like a charm and the screen real estate available makes the environment much more usable!

Now for the question of how to turn a PWM output into a fairly stable voltage output. I seem to remember something about RC circuits being involved, a load resistor and an adequate capacitor to smooth it. I'll puzzle it out.

http://arduino-info.wikispaces.com/Arduino-PWM-Frequency has something to say about PWM, but it looks like the suggestions mess up other timekeeping functions on the board.

Questions Remain (Answers Elude)

Answers to these questions may get added later. More questions will definitely get added. Red ones are still unresolved.


What is it about the Data Logging Shield that makes it incompatible with the Arduino MEGA? It would be really useful to have it work on that board with the additional ports. Details are now on Adafruit.

Why is the file creation time stamp on the logger not correct?   http://arduino.cc/forum/index.php?topic=72739.0 provides code to get the date right with the distributed SD library. Implemented in RWSloggerV2.

Why do so many of the examples use raw output rather than sprintf() to format? Is it a code size thing for stdio.h? BareMinimum compiles to 466 Bytes with a completely null program. Add an 80 char string and print a line to serial in setup gets it to 1996 bytes. Include stdio.h for no change. sprintf() the same test line jumps it to 2066 bytes. Put a more complicated sprintf() in the loop function and it jumps to 3674 bytes, so it doesn't seem like a big problem.

How do I create libraries of my own to use in sketches? It would make the sketches a lot less cluttered if I could put my own standard setup code in a library. It really is as simple as it looks: create a .h and .cpp file and put them in the libraries file tree.

What should be the DC voltage on the power supply to the Motor Shield? I attached a 20 volt supply from an old acer laptop and ran the hobby motors up to about 6 V PWM without letting any of the smoke out. I think the driver chips are good to 24V, but not 100% sure.

What are the voltage / current ratings on the little hobby motors that come with the starter kits?

How about the steppers labelled PF35T-48L4?   http://www.jameco.com/Jameco/Products/ProdDS/171601.pdf

Can I get the serial port window to open automatically on program start after the upload? Maybe not, but the little magnifying glass on the right at the top will open it when you push it.

The Screw Terminal Shield

Assembly went smoothly per instructions in about 15 minutes. Then the adventures began.

I didn't realize the red LED wasn't connected to anything, so I read a little farther and added a wire to link pin 13 and the LED, which snakes neatly between the pin header and the screw terminals.

I plugged it in and started using it with the Data Logger Shield, linking the 3.3 volt supply to the analog reference as suggested (green wire). This led to confusing results as the 3.3 pin was only making intermittent contact with the UNO board due to mechanical interference.

The Dremelled cutout (upper left) clears the USB port on the UNO and doesn't eat any of the proto board holes.

Adafruit recommends trimming the pins on the reset switch (lower left) but there were still clearance problems. I Dremelled the two left most pin joints flush, then cut away a bunch of the plastic from the power connector on the UNO. The package fits together much better now and the 3.3 V signal is reliably there.

Another little detail: The projecting posts from the screw terminals risk shorting to components on the breadboard when used with the Adafruit Experimentation Kit. Cutting them off short seemed like a good pre-emptive strike.

In the beginning...

I may be late to the picnic, but one of the things I'm going to do this sabbatical is figure out how to use microcontrollers for meeting a bunch of practical objectives. I'm starting out with the Arduino and got a bunch of starter stuff from Adafruit Industries. I'm going to use this space to keep notes organized and share with others when necessary. I'm certainly not expecting a big readership ;-)

The first thing I did was assemble the Arduino UNO starter kit and plug it in. Dead simple from the instructions and the software was easy to download and install on the mac from ardx.org. Went through most of the experiments from the guide and managed to get almost all of them implemented on the same breadboard and operating simultaneously (Blink8 -- I'll not the names of sketches I wrote or adapted in parentheses).

I followed that up with some soldering to assemble the motor shield, data logging shield, and screw terminal shield according to instructions. So far so good. Things I learned along the way:

Be very careful with component placement! Soldering one of those tiny capacitors into the wrong location makes it really hard to remove without tearing it apart, and really hard to get the leads of the bigger capacitor into the holes that are now full of solder. Really hard, but not impossible. It will be easier with some desoldering gear.

Clearances and connections are critical! Adafruit is correctly focussed on the electronics and I got a little caught out on mechanical clearances. When mounted on the starter kit Arduino UNO, the screw terminal board's bottom contacts come almost all the way down to the breadboard. Any components plugged into the power or ground line closest to the UNO will short to the screw terminal pins. Also, the USB socket and power connector on the UNO interfere with the screw terminal shield, preventing it from seating fully and producing glitchy connections on some of the pins. Easily fixed by Dremelling a cutout for the USB, flattening the reset PB pins, and taking some of the plastic off the power connector.

Line headers up straight! The instructions are clear about using the Arduino headers as an alignment holder when soldering the pin headers on a shield. The same approach lets you use another shield to line up the socket headers when soldering them to the screw terminal shield.

A magnifier and good light are essential for middle aged eyes! Already mentioned by Adafruit, but maybe not in big enough, bold enough letters ;-)