Cool.  I thought about doing one of these, but realized it was a) still manual operation, and b) kinda silly to worry about wireless control of a machine that is already connected by a 4" diameter hose.

I designed an AC sense circuit that automatically turns on the DC whenever the table saw is on, and lets it run for a couple of minutes after the saw is powered down.

I'm keeping an eye out for powered gates so I can make it 100% automatic (I don't have enough DC to not use blast gates).

-j

Look at your data bandwidth  - you may very well find that you will fail to record important events because the wireless data speed will not allow you to sample fast enough.

-j

was thinking to split the serial-out of the equipment with a simple "Y" adapter, so that one branch goes directly to the computer and the other branch goes to a serial-to-parallel converter for the printer.  Would this work, or will I fry something?

The RS232 spec calls for one TX connected to one RX.  So multiple receivers don't meet spec.

In practice, it'll probably work, but maybe not at high speeds.

I doubt anything will fry, as long as no more than one TX is driving.

-j

Have you looked at the Ardupilot project?

The Ardupilot Mega already does this.  It uses a separate ATmega328 (i.e. and arduino processor) to decode RC receiver outputs.

The design team decided to use a separate processor for this decoding.  IIRC the reason was to increase accuracy and offload computation to make more resources available for the rest of the flight code.

-j

You only have 2k of data space in the uno so no chance.

Wrong.  You have 32kb of program flash and the PROGMEM macro, so if your program will fit in the 30k left, no problem.

-j

CrossRoads' code is a good start, but it won't work.  The data isn't a fixed 3 column field; you'll need to be able to deal with varying length numbers.

Here's some code I wrote that reads positive integers.

Code:

#define isdigit(X) (((X) >= '0') && ((X) <= '9')

int read_int()
{
  static byte c;
  static int i;

  i = 0;
  while (1)
  {
    while (!Serial.available())
    {;}
 
    c = Serial.read();
    Serial.print(c, BYTE);
 
    if (c == '\r')
    {
      return i;
    }
    if (isdigit(c))
    {
      i = i * 10 + c - '0';
    }
    else
    {
      Serial.print("\r\nERROR: \"");
      Serial.print(c, BYTE);
      Serial.print("\" is not a digit\r\n");
      return -1;
    }
  }
}

Hopefully the stratologger doesn't throw commas in there when you get >10,000'...

-j

Joule-Thomson appear to disagree with you...
http://en.wikipedia.org/wiki/Joule%E2%80%93Thomson_effect

I have first-hand knowledge that escaping hydrogen can ignite in the way I've described.

huh.

Helium and hydrogen are two gases whose Joule–Thomson inversion temperatures at a pressure of one atmosphere are very low (e.g., about 51 K (−222 °C) for helium). Thus, helium and hydrogen warm up when expanded at constant enthalpy at typical room temperatures.

OK, so there are some special cases.

I do know that the plumbing for a balloon fill connection gets cold.  We dump pretty much a whole tank of He into a balloon, going from 2200PSI to 1ATM in the process.

-j

The heat generated from pressurized hydrogen escaping

"Pressurized hydrogen escaping" is expanding.  Heat is required for said expansion; the expanding gas gets colder as it expands.

-j

Also the microcontroller being based on the classic Harvard computer architecture is probably another 'restriction'?

Wouldn't think so. About the only place this would show up would be the fact that pointers to functions are in a different address space as pretty much all other pointers (PROGMEM would be in the program address space as well). Even so, I don't see this added twist make pointers much worse than they already are.

I've actually used sprintf in a Pascal program.

Weren't you afraid you'd cause the world to end when you ran it?

-j

secure

... and that killed it for the Arduino.

There just isn't enough horsepower for TLS, SSH, etc.

-j

Enabling the pullup turns on a connection between VCC and the output pin, through a large (50k? 100k?  can't remember) resistor.

-j

How do you solder that to the inside of the Arduino female pin?

You realize this is the male part that fits the arduino socket, right?

Just solder your wires to the short end of the header pin, use some heat shrink or hot glue for insulation and strain relief, and you've got a custom cable.

-j

How about option 3, the way it's done in the real world: a solenoid valve?

Google "sprinkler valve" or "solenoid valve", or just walk down the plumbing aisle of your local borg and look for the sprinkler valves.

I'd probably look for a model that will operate on 12VDC, since that's pretty easy to come by and it's a well-documented arduino-level switching problem.

When figuring out your arduino circuit, treat it like a big relay, only for water.

-j

I am wondering (just because I am a curious type) why you would get ANY voltage on a pin that is set to input?

Is the internal pullup enabled?

BTW, don't the UNO specs say 40 mA?

Yep, the ATmega datasheet says 40mA absolute max per I/O pin, 200mA max for the device.  I mis-remembered when posting earlier.

-j