Thank you Mark - more or less what I figured, but you confirmed it. I will use them that way, only because I need a VERY fast way to detect a rapidly rising voltage (e.g. short-circuit detection.) Your confirmation will now guide my design.

I am monitoring a voltage on digital pin 2 for a value in excess of a preset limit.
I can set that limit, but it depends on what Arduino thinks is a HIGH. I thought
that was supposed to be 3V or is that not quite accurate.

You cannot double-count current that way.
However, series-wiring the CT's may give incorrect values since currents are out of phase by 180⁰.
Presumably that would place CT voltage outputs out of phase and canceling.
The way I'd do that is to send each CT to a separate adc and then let Arduino add up the conversions.

Rogowski's are used routinely by power co's - operating at 60Hz in North America.
I am trying to use one fed directly to the adc; the coil produces a derivative of the
current; for a sine wave that's a cosine wave. Looks the same, 90⁰ out of phase.
Just having trouble getting the spec - it produces ".404 mV/A" which is a useless fact because
that can be peak volts, peak-to-peak or rms.

DCB: your code works! But it has to be used at 57600 baud on Arduino-0021 for Atmega328p. Don't know how to override the uploader's speed. It looks like that may be built-in via boards.txt at bootloader burn time. Or it's used in some arcane fashion by the avrdude.
Good job.

You have groundbreaking code - it's exactly what's needed to program-load a network of Arduino's, where each may have different code depending on what its function is, and where only some may have to be re-loaded. I already modified Andrew Rapp's famous Xbee libraries to remove RxTx and replace it with an encrypted socket handler. I'd like to do the same here.

When I try it against 3 different 328p's I do get timeouts or "invalid response" though. It would be nice if somebody could verify that.
I am looking at the bootloader source code to find out what's missing. There are control tables in there that are chip-specific, and
it's going to be a long haul. A few hints from the powers that manage that code would be nice...

Now that I have mind-melded with avrdude a bit more I might take this project in a slightly different direction; reinventing the wheel is not a good idea - I think all I need is a -P <tcpip port> option on avrdude.
Thanks for the parse pointer though - never know which way the chips will fall.
 

Ahhhhhh thanks - I was trying to be too logical - so the format is
first character is a byte, all following are hex pairs forming a byte.

I need to build a program loader that plays with the standard bootloaders but operates over a TCPIP network (encrypted or cleartext.)
The first steps indicate a mismatch between the IDE-generated hex files and the Intel hex format they presumably follow.

Fade.hex:

3A 31 30 30 30 30 30 30 30 30 43 39 34 36 31 30 30 30 43 39 34 37 45 30 30 30 43 39 34 37 45 30 30 30 43 39 34 37 45 30 30 39 35 0D 0A 3A 31 ...

Intel load format:

Record mark | Rec. length | offset | rectype | info/data | cksum
1-byte       1-byte       2-bytes 1-byte    n-bytes     1-byte
Each record begins with a RECORD MARK field containing 03AH, the ASCII code for the colon(':')

Notice that 0x31 is a record length (byte 1), but the next record starts earlier (next 0x3A).
I hope I'm wrong instead of the format and somebody can point out the error.

In this project I'm trying to stay away from specific hardware, but the basic foundation is a serial tunnel device such as the Ethernet shield.
I am testing some code borrowed from http://arduino.cc/forum/index.php/topic,46486.0.html
and it indicates that there are different bootloaders floating about - mucking about with the standard bootloader may just kill this project. I get different responses depending on whose 328p board I use.

I am visualizing a large network of several hundred arduinos (328p) connected over TCPIP and Xbee's.
I need to find a solution to program these remotely by addressing each node and sending it a modified
hex file. The network control language is Java.
From what I have seen so far it seems I may have to invoke Avrdude from inside Java and give it the
tcp port to transmit over; the Java program would ensure the stream is directed to the appropriate
XBee-connected Arduino. However, the Avrdude docs state that TCP port addressing is not supported
under Windows. That seems to break my strategy. Any other ideas, anybody, please?
I suppose since I'm on Java I could move to 'Unix' or Mac instead.

Looks like this may be a problem with the display instrumentation.
If I remove CLK from the display I don't see the glitches any more.
Thanks for the comments everybody. I will talk to the guys that
built the MSO19 I'm using.  
OTOH the MSO19 is attached to a 2.4 GHz dual processor Windows server and the fast
sample/display may be more than ol' Windows can handle on that machine.
Will try on an XP asap.

I noticed during SPI testing that there is a weird glitch in the SS line. Maybe it's my fault - would be glad to hear that.
Here's my code:

Code:

#include <SPI.h>

const int sspin = 10;
const int mosipin = 11;
byte val = 0x18;

void setup()
{
// Digital pins are: SS=10, MOSI=11, MISO=12, SCK=13
pinMode (sspin, OUTPUT); // must be guaranteed to be output
pinMode (mosipin, OUTPUT);
SPI.setClockDivider(SPI_CLOCK_DIV32); // => 500 KHz
SPI.setBitOrder(MSBFIRST); // endian
SPI.setDataMode(SPI_MODE0); // clock idles low
SPI.begin(); // => SCK and MOSI low, SS high
}


void loop()
{
digitalWrite(sspin, LOW); // enable slave
SPI.transfer(val);
digitalWrite(sspin, HIGH); // disable slave
}

And here's the trace - notice the quick bursts in the SS line
Can~t insert image - attached instead (however that works)

Thanks to both of you! The problem was that the default constructor also needed an initialization for Nss  --> softxbee::softxbee() : Nss(2,1)
so I gave it pins 1 and 2 as a default.

My own problem is that I've been doing Java for so long that stepping back into the medieval world of C++ with all its contrived artifacts is a serious drag for me. However, I do recognize we'd need at least a 100MHz Arduino to support Java.

Thanks, Cr0sh - changing the include doesn't affect the problem.
I'm just trying to instantiate a NewSoftSerial object when the softxbee constructor is called.Maybe you could find a similar line in your code.
Will try some more. Found:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1211645129

but his solution doesn't seem to help me here.

I am converting the Xbee library to use both Serial and NewSoftSerial, so it can be used in conjunction with USB access to the mcu. But I'm not sure why I'm getting this error:

softxbee.cpp: In member function 'void softxbee::begin(long int)':
softxbee.cpp:23: error: '((softxbee*)this)->softxbee::Nss' does not have class type

.h:

Code:

#ifndef softxbee_h
#define softxbee_h

#include <WProgram.h>
#include <inttypes.h>
#include <../NewSoftSerial/NewSoftSerial.h>

class softxbee {
public:
      softxbee();
      softxbee(uint8_t, uint8_t);

      uint8_t _rxpin, _txpin;
      boolean _usingsoftserial;
      NewSoftSerial& Nss(uint8_t, uint8_t);
      void begin(long baud);
};

#endif //softxbee _h

.cpp:

Code:

#include "softxbee.h"
#include "WProgram.h"
#include "HardwareSerial.h"
#include <../NewSoftSerial/NewSoftSerial.h>


softxbee::softxbee(){
      _usingsoftserial = false;
}

softxbee::softxbee(uint8_t rxpin, uint8_t txpin){
      softxbee();
      _usingsoftserial = true;
      _rxpin = rxpin;
      _txpin = txpin;
      Nss(rxpin, txpin);
}

void softxbee::begin(long baud) {
      if (!_usingsoftserial)
            Serial.begin(baud);
      else
            Nss.begin(baud);
}

My sketch to test this:

Code:

#include      <softxbee.h>
#include      <NewSoftSerial.h>

softxbee xbee;                                                // coordinator
 
void setup()
{
Serial.begin(9600);
xbee = softxbee(8,9);
xbee.begin(9600);
}

void loop()
{
}