Need Help with Arduino Uno Sketch to Create ASCII Characters

[Electro Fan]

Hi,

I'm using an Arduino Uno as a pulse generator to create some ASCII characters which are outputted from the Uno to an oscilloscope that in turn decodes the square waves as specific ASCII characters.

In the sketch below I can make a series of pulses that the scope decodes as capital U characters but this is just because it is a repeating square wave.  I think I might need to account for a start bit sequence or something else but I can't quite figure out what I'm missing.

// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

// the setup routine runs once when you press reset:
void setup() {               
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);     
}

// the loop routine runs over and over again forever:
void loop() {


  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(5);               // wait for a second
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(5);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(5);               // wait for a second
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(5);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(5);               // wait for a second
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(5);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(5);               // wait for a second
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(5);               // wait for a second 
  }

Any suggestions on how I can adjust the sketch to generate specific ASCII characters with the UNO?

Thanks!

[David_AVD]

So you're trying to "write text" to the oscilloscope ?

The posted code is simply toggling the LED on and off.

[mariush]

I think he's trying to send  BITS  (1 or 0 ) and have the oscilloscope decode these bits into a series of 1 and 0.

There are normally two wires used to transmit data, because one wire acts as a "clock", meaning whenever there's a "tick" on this wire, the device at the end of the wires knows there's updated data on the other wire. This way, the delay between new bits on the data wire can vary and the device will only read the new bit when it detects a tick on the clock wire.

With just one wire, you have to agree on a sort of start sequence which will tell you a new sequence of bits is going to be transmitted. This can be something as simple as going LOW for 10 ms and then going HIGH for 5 ms  (001 or 110) - as soon as you see that on the oscilloscope, you know your product should set a series of bits.

Some devices like remote controls by their nature use a "1 wire" protocol.. basically sending a series of pulses through the air. There's several protocols but most remote controls use a very common one.
Dave actually did a video about such remote controls and reading the data on Arduino and oscilloscopes, have a look :

[Hideki]

Electro Fan, you describe a lot of the details, show us a program, but completely and uttery miss the most important thing: What protocol do you want use?

Assming it's a single serial UART line, and typical 8N1, then you need to send _ten_ bits at a time. First a start bit (always LOW), then eight data bits, which can be whatever you like, and last, but no less important, you send the stop bit (always HIGH).

[Electro Fan]

Sorry, I should have pointed out that I'm just emulating a RS232 port card (UART) protocol.

I revised the Arduino sketch to add the start bit (always LOW) and stop bit (always HIGH) - thanks Hideki.

// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

// the setup routine runs once when you press reset:
void setup() {               
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);     
}

// the loop routine runs over and over again forever:
void loop() {

  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(5);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(5);               // wait for a second
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(5);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(5);               // wait for a second
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(5);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(5);               // wait for a second
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(5);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(5);               // wait for a second
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(5);               // wait for a second
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(5);               // wait for a second   
  }

Looks like we are now rocking and rolling.  Using the sketch seems to allow the ability to create specific ASCII characters.  Thanks for the help - much appreciated!  EF

PS, New Question:  why does the counter show 83.2Hz and 78.8Hz in the two samples when the frequency shows 100 Hz?  Thanks

[hamster_nz]

Any suggestions on how I can adjust the sketch to generate specific ASCII characters with the UNO?

Thanks!

Here's the "loop()" code for 8 bits, one stop bit, idle state of "high", sending LSB first. I actually run it up, but it "verifies" in the Arduino GUI:

Code: [Select]

static char message[] = "hi there!";

// the loop routine runs over and over again forever:
void loop() {
  int a;

  // Some Idle time
  digitalWrite(led, HIGH);
  delay(5);               // wait for a second
  delay(5);               // wait for a second
 
  for(a = 0; a < sizeof(message); a++)
  {
     // start bit
     digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
     delay(5);

     // LSB Bit 0
     digitalWrite(led, (message[a] & 1) ? HIGH : LOW);   
     delay(5);

     // Bit 1
     digitalWrite(led, (message[a] & 2) ? HIGH : LOW);   
     delay(5); 

     // Bit 2
     digitalWrite(led, (message[a] & 4) ? HIGH : LOW);   
     delay(5);

     // Bit 3
     digitalWrite(led, (message[a] & 8) ? HIGH : LOW);   
     delay(5);

     // Bit 4
     digitalWrite(led, (message[a] & 0x10) ? HIGH : LOW);   
     delay(5);

     // Bit 5
     digitalWrite(led, (message[a] & 0x20) ? HIGH : LOW);   
     delay(5);

     // Bit 6
     digitalWrite(led, (message[a] & 0x40) ? HIGH : LOW);   
     delay(5);

     // Bit 7
     digitalWrite(led, (message[a] & 0x80) ? HIGH : LOW);   
     delay(5); 

     // stop bit
     digitalWrite(led, HIGH);    // turn the LED off by making the voltage LOW
     delay(5);   
  }
}

You want to change "delay(5)" to be whatever your per-bit time is (e.g. 1/9600th of a second for 9600 baud).

[Electro Fan]

You want to change "delay(5)" to be whatever your per-bit time is (e.g. 1/9600th of a second for 9600 baud).

Thanks for the help but I'm still trying to get the timing sorted out.  Changing the "delay(5)" to a lower value (such as 1) will speed up the transmission (changing from 5 to 1 changes the frequency from 100Hz to 500Hz).  At 500Hz the counter changes to 275 Hz.  Separately, the scope requires the user to select a user setting for the baud rate.  As the baud rate changes so does the decoder results.  What is the relationship between the frequency and the counter and the baud rate (that should be selected to get proper decoding)?  Thanks again

[hamster_nz]

I understand what you are saying, but just can't get it in a useful context where I can give you a direct answer, so here's some background.

To decode RS232 running at 'n' bits per second most hardware over-samples the incoming data line at maybe 4n.

When the falling edge which is the the 'start' bit is seen (ie the last two samples were "1" for the oldest, and "0" for the most recent) the receiver assumes that the next sample is synched close enough to the center of a bit to be valid.

It will then take every 4th sample as being a valid data bit, up to and including the stop bit.

So over the 10 bits for each byte the receiver can drift about a quarter of a bit-time out of sync with the sender before an error will occur (assuming no noise and so on), or about 2.5% -

Because one end can be running fast and the other can be slow your timing should be within 1.25% for reliable operation.

300 Buad needs 3.33ms per bit, +/- about 0.04 ms.

9600 Baud needs 104us per bit, +/- about 1us

The upshot is that bit-bashing RS232 at high speed is not every easy - you are best off using a hardware UART.

Mike

[Electro Fan]

I understand what you are saying, but just can't get it in a useful context where I can give you a direct answer, so here's some background.

To decode RS232 running at 'n' bits per second most hardware over-samples the incoming data line at maybe 4n.

When the falling edge which is the the 'start' bit is seen (ie the last two samples were "1" for the oldest, and "0" for the most recent) the receiver assumes that the next sample is synched close enough to the center of a bit to be valid.

It will then take every 4th sample as being a valid data bit, up to and including the stop bit.

So over the 10 bits for each byte the receiver can drift about a quarter of a bit-time out of sync with the sender before an error will occur (assuming no noise and so on), or about 2.5% -

Because one end can be running fast and the other can be slow your timing should be within 1.25% for reliable operation.

300 Buad needs 3.33ms per bit, +/- about 0.04 ms.

9600 Baud needs 104us per bit, +/- about 1us

The upshot is that bit-bashing RS232 at high speed is not every easy - you are best off using a hardware UART.

Mike

Thanks - I am studying your reply and trying to absorb it.  I sense that some type of drift is occurring.  I'm going to experiment with a few variables and see if I can find some sort of pattern as to what causes what .

Setting aside baud rate, any thoughts on why the counter and the frequency measurement on the scope don't seem to agree?  Sometimes they are close (within 1% or so) and sometimes they are off by 2x.  Is this a combination of drift (1%) and sampling issues (2x) also?  Thanks again

[David_AVD]

Using delay routines in an Arduino sketch to do comms timing is not likely to yield a useful result.  If you want to send serial data, use the UART hardware.

[Electro Fan]

Using delay routines in an Arduino sketch to do comms timing is not likely to yield a useful result.  If you want to send serial data, use the UART hardware.

eh, the UART hardware...?  is that a reference to a feature built into the Uno or a shield or something else?  Thx

Update:

perhaps this is what you were suggesting:

Used for communication between the Arduino board and a computer or other devices. All Arduino boards have at least one serial port (also known as a UART or USART): Serial. It communicates on digital pins 0 (RX) and 1 (TX) as well as with the computer via USB. Thus, if you use these functions, you cannot also use pins 0 and 1 for digital input or output.

[hamster_nz]

Arduinos have a built in UART - Have a look at Examples/Communicaitons/ASCII table in the Arduino GUI.

You can monitor over either the host port or this over pins D0 (RX) and D1 (TX).

[psycho0815]

You should generally use the hardware uart if possible. If that's not an option you could also use the Arduinos SoftwareSerial Library. If you insist on doing it yourself that's also were i would start. have a look at the library see how they do things. No need to reinvent the wheel.

One more general thing: clean up your code. it looks like you based it on the basic blink sketch and just copy and pasted some stuff including the comments, which no longer  fit what is happening in your code. Now i realise that this is just some experimental code, but that sort of thing can really come back to bite you so you should just try to get used to doing it right from the start. In this particular case, i would actually go ahead and just delete most of the comments, since they add absolutely no information to you code.

[dannyf]

That's pretty simple,  isn't it?

Code: [Select]


//send a char's ascii bit form
//msb first
//pin idles high
#define ASCII_PIN 2 //ascii pin
#define ASCII_DLY  5 //delay between bits

void ascii_putc(unsigned char dat) {
  unsigned char mask = 0x80; //mask of bits to be sent, msb first

  //send start bit(s) here
 
  //send the ascii char
  do {
    if (dat & mask) digitalWrite(ASCII_PIN, HIGH); //send '1'
    else digitalWrite(ASCII_PIN, LOW); //send '0'
    mask = mask >> 1; //shift to the next bit
    delay(ASCII_DLY); //waste some time
  } while (mask); //till all bits are sent

  //send stop bit(s) here

  digitalWrite(ASCII_PIN, HIGH); //ascii_pin idles high
}

You can then write a routine to send a string

Code: [Select]


//send a string
void ascii_puts(unsigned char * str) {
  while (*str) ascii_putc(*str++);
}

And your user code would be something like

Code: [Select]

  ascii_putc('U'); //send 'U'
  ascii_puts(aBuffer); //send a string in aBuffer

...

Learn a little bit C would be quite helpful to you.

[Electro Fan]

Electro Fan, you describe a lot of the details, show us a program, but completely and uttery miss the most important thing: What protocol do you want use?

Assming it's a single serial UART line, and typical 8N1, then you need to send _ten_ bits at a time. First a start bit (always LOW), then eight data bits, which can be whatever you like, and last, but no less important, you send the stop bit (always HIGH).

Hideki, hamster_NZ, and everyone, thank you for your patience and help.

I have attempted to clean up the comments as psycho0815 suggested.

Below is a sketch that produces a Capital A ASCII character with the decoder.  The decoder displays the bits in Binary as 01000001 (this is how the bits are rendered from left to right on the scope screen with the decoder set to LSB).

I could be mistaken but the Start bit is not only the starting bit but it is also the first data bit.  That leaves the next seven bits as the remaining bits in an eight bit byte.  Clearly, this sequence produces the Capital A as expected based on the ASCII table.  This leaves two more bits (bit #9 is a 1 (LOW) - which I'm not sure of, and bit #10 which is a 0 (HIGH), which presumably is the Stop bit.

So, this conforms pretty closely to what you (Hideki) prescribed in your post (the first bit is the LOW start bit and the last bit is the HIGH Stop bit, and there are 8 data bits (including the Start bit), but what is the 9th bit?  I am guessing that it could be a Parity bit - I have my scope set to "None" for parity which conforms to your 8N1.

Also, is the 8th bit (as shown in the sketch below) the MSB (Most Significant Bit)?

Comments?  Thanks!

/*
ASCII Generator, Create Capital A
 */
 
// Pin 13 has an LED connected on the Arduino board.
// give it a name:
int led = 13;

// the setup routine runs once when you press reset:
void setup() {               
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);     
}

// the loop routine runs over and over again forever:
void loop() {


  digitalWrite(led, LOW);    // make the voltage LOW (turn the voltage off) 1 = Start bit
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);   // make the voltage HIGH (turn the LED on) 0
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);    // make the voltage HIGH (turn the LED on) 0
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);   // make the voltage HIGH (turn the LED on) 0
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);    // make the voltage HIGH (turn the LED on) 0
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);   // make the voltage HIGH (turn the LED on) 0
  delay(1);               // wait for a second
  digitalWrite(led, LOW);    // make the voltage LOW (turn the voltage off) 1
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);   // make the voltage HIGH (turn the LED on) 0 = MSB?
  delay(1);               // wait for a second
  digitalWrite(led, LOW);    // make the voltage LOW (turn the voltage off) 1 = Parity bit?
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);   // make the voltage HIGH (turn the LED on) 0 = Stop bit
  delay(1);               // wait for a second   
  }

[Electro Fan]

Electro Fan, you describe a lot of the details, show us a program, but completely and uttery miss the most important thing: What protocol do you want use?

Assming it's a single serial UART line, and typical 8N1, then you need to send _ten_ bits at a time. First a start bit (always LOW), then eight data bits, which can be whatever you like, and last, but no less important, you send the stop bit (always HIGH).

Hideki, here is another sketch. This one is for a Capital B ASCII character.  You can see that the binary code is 01000010.  It would seem that the Start bit is now a 0 which is a HIGH.  I probably have something goofed up, but this seems to be at odds with the notion that the Start bit is always LOW.  Thanks, EF

(It seems that the Start bit is also the LSB (Least Significant Bit) as simply incrementing up from the 01 to 10 end of the byte toggles the code from A (as shown in the previous post) to B (as shown below).  Yes/No?  Thanks)

/*
ASCII Generator, Create Capital B
 */
 
// Pin 13 has an LED connected on the Arduino board.
// give it a name:
int led = 13;

// the setup routine runs once when you press reset:
void setup() {               
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);     
}

// the loop routine runs over and over again forever:
void loop() {


  digitalWrite(led, HIGH);    // make the voltage HIGH (turn the LED on) 0 = Start bit = LSB?
  delay(1);               // wait for a second
  digitalWrite(led, LOW);   // make the voltage LOW (turn the LED off) 1
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);    // make the voltage HIGH (turn the LED on) 0
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);   // make the voltage HIGH (turn the LED on) 0
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);    // make the voltage HIGH (turn the LED on) 0
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);   // make the voltage HIGH (turn the LED on) 0
  delay(1);               // wait for a second
  digitalWrite(led, LOW);    // make the voltage LOW (turn the LED off) 1
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);   // make the voltage HIGH (turn the LED on) 0 = also MSB?
  delay(1);               // wait for a second
  digitalWrite(led, LOW);    // make the voltage LOW (turn the LED off) 1 = Parity bit?
  delay(1);               // wait for a second
  digitalWrite(led, HIGH);   // make the voltage HIGH (turn the LED on) 0 = Stop bit
  delay(1);               // wait for a second   
  }

[Dago]

You should be using the UART for this kind of serial communication. You can do it in software but there's no point if you have an UART.

[psycho0815]

Have a look at the UART spec. the stop bit is suppossed to be a logic high i.e. 0 V.
I edited you comments to reflect what you're actually sending.

Code: [Select]

// the loop routine runs over and over again forever:
void loop() {


  digitalWrite(led, HIGH);    // make the voltage HIGH (logic 0) =  LSB
  delay(1);             
  digitalWrite(led, LOW);   // make the voltage LOW (logic 1)
  delay(1);             
  digitalWrite(led, HIGH);    // make the voltage HIGH (logic  0)
  delay(1);               
  digitalWrite(led, HIGH);   // make the voltage HIGH (logic  0)
  delay(1);             
  digitalWrite(led, HIGH);    // make the voltage HIGH (logic  0)
  delay(1);             
  digitalWrite(led, HIGH);   // make the voltage HIGH  (logic 0)
  delay(1);             
  digitalWrite(led, LOW);    // make the voltage LOW  (logic 1)
  delay(1);             
  digitalWrite(led, HIGH);   // make the voltage HIGH  (logic 0)  MSB
  delay(1);               
  digitalWrite(led, LOW);    // make the voltage LOW  (logic 1) stop bit
  delay(1);             
  digitalWrite(led, HIGH);   // make the voltage HIGH (logic 0) = Start bit
  delay(1);             
  }


The reason your scope can decode that is probably mostly luck and some clever logic in your scope

[David_AVD]

For typical async comms, the format is 8N1.  This means 8 data bits, no parity bits and 1 stop bit.  There is also the start bit at .. well... the start !

So, that's 10 bits all up.  (1 start bit, 8 data bits and 1 stop bit)  Unless you get this right, you won't get any sense when decoding it.

[Hideki]

This really isn't as hard as you're trying to make it be

1. The signal is assumed to idle at HIGH when no data is being sent. You have to start out with this condition, or everything below will fail. Do this in setup and not inside the loop. One thing to watch out for is that you may have to actually let it stay HIGH a little while before you start sending anything, or the receiver may miss the first start bit (it actually looks for the signal going from HIGH to LOW).

2. The first thing you do when you want to send a byte is to send the start bit... at the start! That makes sense, doesn't it?
Since the start bit is LOW, the receiver will detect this HIGH to LOW transition and get ready for receiving your new byte.

3. Then you send your 8 bits. The standard for UART is the Least Significant Bit first, so you send bit 0 to bit 7 in order.

4. After all 8 bits the byte is done and you send a stop bit. This bit is always HIGH.

After the stop bit is done you have sent 10 bits in total, and we are back at the initial state from step 1. The signal is HIGH, and you can stay that way forever, or immediately send another byte by going to step 2.

psycho0815: Please don't confuse everyone by saying that logic high is 0 V. That isn't even true for RS-232, which uses different signal levels than plain UART from an arduino output.

[Electro Fan]

Hi EEVers,  Thanks for the previous advice.

I'm thinking about approaching my ASCII generating/decoding experiments with a different set of test tools other than the Uno.

Just checking to see if you have any thoughts on the utility of a few options.

The goal is to have the ability to generate test signals that are effectively ASCII characters while having control over the amplitude and pulse durations and maybe the underlying clock frequency on which the pulses ride.

So, here are the possibilities:

1. Rigol 832 DC Programmable Power Supply - not sure if it will provide enough control from the front panel or probably better yet from a PC to generate start bits, data bits, and stop bits.  Seems like this should be doable, but maybe at a fixed "clock" frequency.  Probably overkill for just this experiment but it would of course be a good DC power supply for lots of other uses.  (An additional concern is whether the various feature issues that surfaced during Dave's testing have been sufficiently resolved.)  My guess is that this won't be the best of the 3 options.

http://eu.rigol.com/download/Oversea/DP/User_guide/DP800_UserGuide_EN.pdf

2. Rigol  DG4062 Arbitrary Waveform Generator

While this seems to offer the ability to generate arbitrary waveforms it isn't clear from reading the manual whether this will provide sufficient flexibility to generate ASCII characters, but maybe...  (Also overkill for this experiment, but hey, who wouldn't want a reason to own a nice arb generator?)

www.tequipment.net/assets/1/26/Documents/Rigol/DG4062/dg4062_doc_3.pdf

3. USBee-SX Logic Analyzer with built-in Signal Generator

This seems to have some limitations in terms of voltage levels but might have the best flexibility and ease of use for creating bit patterns. This option is the least expensive of the three and would provide a Logic Analyzer as a bonus.

http://www.usbee.com/sx.html



http://www.usbee.com/sx.html#Signal

Or maybe there are better ways to accomplish the goal?

Thanks!

[dannyf]

maybe there are better ways to accomplish the goal?

Yeah. Like knowing what you are trying to accomplish, planning out your tasks ahead of time and possessing the necessary skills to get it done.

[Electro Fan]

maybe there are better ways to accomplish the goal?

Yeah. Like knowing what you are trying to accomplish, planning out your tasks ahead of time and possessing the necessary skills to get it done.

Sounds a little condescending but maybe I'm just reading that into your reply.

As mentioned above: The goal is to have the ability to generate test signals that are effectively ASCII characters while having control over the amplitude and pulse durations and maybe the underlying clock frequency on which the pulses ride.

Let us know if you have any comments on the three options presented or any helpful suggestions, or if you want to take some other shots.

[SL4P]

If you actually know what you're doing in the hardware and software domains, including the requirement for variable bit amplitude etc, then to achieve what you want in code is going to be tricky but not impossible, while maintaining the sharp rise and fall times of the tx data.

Use the UART or software bit-bashing on a CPU with as fast a clock as you can get (gives you more time to do things *between* tx bits).  Hook up whichever TX pin you use back to an interrupt on change .

Put a variable gain amp on the outbound TX data, amplitude driven from another port.
Then you can use the interrupt to identify when each bit has been sent (interrupt on change), and you can ramp or modify the slew rate in between each bit.
If you want to vary the bit timing - you may be able to fiddle the TX clock divisor, or use software bit-bashing to manage each bit like you are already.

It ain't going to be a walk in the park - but I think it's possible - and quite interesting to consider !

[Electro Fan]

If you actually know what you're doing in the hardware and software domains, including the requirement for variable bit amplitude etc, then to achieve what you want in code is going to be tricky but not impossible, while maintaining the sharp rise and fall times of the tx data.

<snip>

It ain't going to be a walk in the park - but I think it's possible - and quite interesting to consider !

Ok, I’m starting to think this is going to be more difficult than I had expected.  Not sure exactly why yet, but I’m getting the message.

Clearly, given my very beginning skills the Arduino didn’t give me enough control over something – I suspect it had something to with timing but I’m not sure.  Perhaps it's doable with the Arduino and I just couldn't make it happen.  Without a doubt I don’t have more than very beginning software coding and super beginning hardware design skills, I get that.

What I have to work with is just a basic understanding of amplitude and frequency.  When I get to components I’m good to Ohm’s Law (sort of) and after that I’m in heavy figure-it-out mode.  So, what I’m not trying to do is to create pulses by building a circuit board with components. 

The idea for this project has been to use some reasonably affordable piece of test equipment (if not the Arduino, maybe a programmable DC power supply or an Arb generator) or other tool (like the USBee Logic Analyzer that seems to double as a generator) so as to gain enough control over pulse generation to sequence out HIs and LOWs.  The goal is to create the 1s and 0s patterns found on the ASCII chart so they can be captured and decoded on a scope.  This lets me visually inspect the waveforms and study things.  Small potatoes I realize, but interesting for a guy who is just figuring out lots of stuff from the very beginning at the hands on level. 

I’m coming at this backwards from most EEs I think.  I use some basic test equipment to see and learn rather than to design and debug.  All I want to do for now is consolidate my understanding of the relationships between analog signals and the digital data riding on (represented by) the signals.  The more control I can have over amplitude, frequency, duty cycle, etc. the better.  FWIW, I have a hunch that your advice about getting “a CPU with as fast a clock as you can get” is great advice.  I think the Uno was very close to the right tool for what I have in mind except that I couldn’t find a way to better manage the clock and maybe the clock was too slow (not really too slow, I just couldn't control the increments with enough granularity).  Just a hunch, I could be wrong.

The Rigol DC programmable power supply and the Rigol arb generator would maybe not be useful for such a project?  Maybe the USBee generator could do the trick?

Thanks again, EF