Category Archives: Hayes Modems

Wire up your own RS-232 WiFi modem for under $10 using ESP8266 and Zimodem firmware.

Updates:

  • 2018-03-02: Making link to separate article on installing firmware easier to notice.
  • 2018-07-28: Travis Poppe has a 3-D printed case for this you can download and print: https://www.thingiverse.com/thing:2923619
  • 2020-05-01: Reformatting for current WordPress. Renaming some images.

This is a fairly detailed guide to configuring a cheap ESP8266 WiFI module to act as a WiFi modem, then wiring it up to any computer with a traditional RS-232 port.

It can be as simple as hooking up four wires, or many more wires, or even making a breadboard prototype:

Hardware Needed

  1. ESP82660-12E NodeMCU 1.0 development module (or a NodeMCU ESP-32S module)
  2. microUSB cable and power source (either powered by a computer’s USB port, or a standalone USB power supply like a phone charger)
  3. RS-232 to TTL adapter that operates at 3.3V.
  4. Female-to-female jumper wires (or male-to-male jumper wires and a breadboard)
  5. RS-232 cable (and possibly an RS-232 gender changer or NULL modem adapter)

Software Needed

Currently, we have to download and build the special Zimodem firmware, but as soon as I figure out what it takes just to load a pre-built binary, this section will be removed.

  1. Serial Drivers for the development module you choose.
  2. Zimodem firmware for the ESP by Bo Zimmerman.
  3. ESP firmware flash tool (or Arduino IDE if you want to download and build the source code yourself).

HARDWARE

ESP Development Module

The ESP8266 is a tiny WiFi device that can also run custom code. The development module version has a built-in USB-Serial adapter that can be used for debugging and loading firmware, and also gives a convenient way to power the module.

  • I started out with a NodeMCU ESP8266-12E module from Amazon for $8.29, available with 2-day Prime shipping. I later ordered a batch of five for $25 from this e-Bay reseller (shipped from the US). You can also find them for under $4 each if shipped from China.
  • The ESP32 is also supported, like this ESP32-WROOM-32 NodeMCU 32-S module for $12.99 on Amazon. They can be also be found for under $6 shipped from China. The ESP32 adds support for Bluetooth, but the firmware we will be using currently does not make use of it. The only real reason to use it is that Zimodem for ESP32 will be built using standard RS-232 signals, while the Zimodem build for ESP8266 has inverted RS-232 signals for Commodore computers, and will require some additional setup to make work on non-Commodore machines.
  • Even an under-$2 ESP-01 will work if you are not needing full RS-232 signals like hardware flow control and carrier detect. However, you will need more hardware to program it and power it, so I just stick with one of the development boards that has USB built in. (It actually cost me more to order an ESP-1 plus the USB programming adapter than to buy one of the devkits with everything built in.)

microUSB Cable and power supply

You will need a standard USB to microUSB cable to hook the ESP to a computer so you can load the firmware. Most Android phones use this type of cable, as do things like the Raspberry Pi. If you don’t have one, you can probably buy one at the local gas station.

This cable will also provide power for the ESP module, so it will need to be hooked to a computer’s USB port, or into a USB power supply like a phone charger. Again, commonly available even at the local gas station.

RS-232 to TTL Adapter

The ones I found have a standard DB9 female connector and contain circuitry that will convert the 3.3V chip-level TTL signals used by the ESP chip to standard 12V RS-232 levels that a computer uses. These will often will come with a short 4-wire jumper cable that can be used to hook them up to the ESP module.

  • If all you want is just transmit and receive (referred to as a “3-wire” hookup), you can go with a simple one like this $7 one from Amazon (there are also ones under $6), or find them for less with slower shipping (under $1 shipped from China). These provide hookups for TX (transmit), RX (receive), VCC (power) and GND (ground). For simple uses, this may be all you need. MAKE SURE THE ADAPTER SUPPORTS 3.3V! Some only work with 5V and are not compatible with the ESP modules. WARNING: Some of the ones I tried that claimed they operated at 3.3V did not, so it may take some trial and error.
  • If you also need hardware flow control (referred to as a “5-wire” hookup), there are adapters that a add extra connections for CTS and RTS. They are usually cost just a dollar or so more. (Here is a $10 one from Amazon, but I’ve found them for under $4 on eBay.)
  • If you need full RS-232 signals, including carrier detect, I have found two sources of adapters that provide TX (transmit), RX (receive), DCD (data carrier detect), CTS (clear to send), RTS (request to send), DTR (data terminal ready), DSR (data set ready), and RI (ring indicator).
  • Pololu 23201a Serial Adapter – available asssembled for $11.50, or in a partial kit for $9.95. This adapter uses one row of 10 pins, and is breadboard friendly.  However, I have had been some issues with this part, so I cannot currently recommend it. If you try it and can get it to work, please let me know.
  • AIBANS.BREAKOUT Adapter – available through Amazon for $4.68+$3.03 shipping from California reseller MD Fly, or $3.25+$3.65 standard shipping through their e-Bay listing. (On eBay, you can get a shipping discount for ordering multiple units.) This one works great for me, but it uses a dual-row of pins so it is not breadboard friendly.

Jumper Wires (Female-to-Female)

Most of the RS-232 to TTL adapters I have seen come with a set of jumper wires with female ends. They slide over the pins on the board, and then slide over the pins of whatever you are connecting it to. They allow hooking up parts without needing soldering skills or even a breadboard. I find bundles of 40 of these for under $3.

This .92 cent adapter, shipped from China, came with jumper wires.

Optional: Breadboard and Male-to-Male Jumper Wires

Optionally, if you want something that is a bit more “stable” (without exposed pins and such), you can use a breadboard and male-to-male jumper wires, then plug everything up and jumper them together.

RS-232 Cable and Adapters

You will need a cable to go from your computer’s RS-232 port to the adapter. Your cable will depend on the type of RS-232 to TTL adapter you have. All the ones I have use DB-9 female connectors, but there are some that use a male connector.

For example, my Radio Shack Color Computer has a 4-pin DIN connector for the built-in Serial I/O port. Back then, cables where made that had a male 4-pin DIN connector on one end (to plug into the CoCo) and a male DB-25 connector on the other (to plug into a modem). If I could find my old cables, I could use them, but I would still need a DB-25 to DB-9 adapter to go between that cable and the smaller DB-9 connector of the RS-232 to TTL adapter.

Another common type of serial cable is a NULL modem cable, which was used to hook two computers together by serial ports. I have a NULL modem cable that has the male 4-PIN DIN connector on one end and a female DB-9 on the other. Since it is a NULL modem cable, it has the TX and RX lines swapped so it can plug directly to a “modern” PC’s serial port DB-9 male connector. To use this cable, I needed a male DB-9 to male DB-9 NULL modem adapter, which will swap the TX and RX again, making it a normal cable like the RS-232 to TTL adapter requires, and change the gender so it will plug into the TTL adapter.

I also have the Deluxe RS-232 Program Pak, which provides a full RS-232 port with a female DB-25 connector. To use that, I ordered a standard male DB-25 to male DB-9 cable from Amazon. This will plug directly from my RS-232 Pak to the RS-232 to TTL adapter.

Basically, you will need whatever serial cable your system requires and a way to convert it to plug into a DB-9 connector.

SOFTWARE

The ESP modules have their own software installed, and it includes a command mode where you can use “AT” commands (similar to the old Hayes Smartmodem standard) to do various WiFi things. But, this is not setup to emulate an old modem connection. Instead, we will use Bo Zimmerman’s excellent replacement firmware called Zimodem. He provides the source code, but you will have to download and build it, then load it into your module.

I am now maintaining a special version of Zimodem that has things set up for normal RS-232 use. (By default, the original Zimodem works in a Commodore mode for 8266, and normal for ESP32. My version works in normal mode for both.)

Serial Drivers

Most of the low-cost ESP parts use serial hardware that is not recognized by a Mac or PC (not sure about Linux). If you plug up your ESP part to your computer and it is not recognized as a serial port (Like COM5: on windows, or /dev/cu.SLAB_USBtoUART on Mac), you will need drivers.

Most sellers will provide links to where to find drivers. For the Amazon parts I purchased, they used the CP2012 chipset, and I had to download and install the drivers for it. Once installed, you can plug the ESP module up and it should show up as a new serial port device.

Firmware Flash Utilities

Because of the various methods available to install ESP firmware, I have split them out into a separate article.

Please read this article for details on how to load the firmware onto the module without needing to install the Arduino IDE, download the sources, and build it yourself.

Testing Zimodem

Once the firmware has been installed on the module, you can open up the Serial Monitor in the Arduino IDE and verify it is running. You will need to set it to 1200 baud to match the default speed used by Zimodem, and have it set to “Carriage return“. You can type “AT” and it should respond with “OK”. You can type “AT+CONFIG” and it should startup the configuration process.

Zimodem startup banner, and entering the “AT+CONFIG” command.

If you get this far, you are ready to hook it up to the RS-232 to TTL adapter and then connect it to your computer.

WIRING

Simple 3-wire hookup

For simple serial ports, all you may need to do is hook up TX (transmit), RX (receive), VCC (3.3v) and GND (ground) between the ESP module and the TTL adapter. Here is the pinout of the NodeMCU ESP8266-12E module:

NodeMCU ESP8266-12E module pinouts.

All you have to do is connect the jumper wires between the pins of this module, and the matching pins on the TTL adapter. Some TTL adapters may have TX and RX reversed, but in general you want to hook up like this:

3-wire hookup:

    TTL         ESP8266
    ===         ==================
2   RX  <------ TX  GPIO1 (TX)
3   TX  ------> RX  GPIO3 (RX)
5   GND <------ GND GND
    VCC <------ 3V3 3.3V

For one of my adapters, I found it would not work using the 3.3V pin, and I had to switch to using the Vin (voltage input) pin, which would be the 5V coming off the USB connection. *THIS IS NOT RIGHT since the I/O pins of the ESP modules are mean to handle 3.3V and not 5V, so use caution. If you absolutely can’t get it to work on 3.3V, you can do what I did, but you risk frying the ESP.* I have other adapters that work properly at 3.3V.

It looks like this (note I am using the incorrect Vin instead of VCC):

ESP8266 to “3-wire” RS-232 TTL adapter.

WARNING! Keep all the bare metal pins from touching anything else! They could cause a short if they made contact with any metal. To reduce the chance of this happening, I used some of the non-conductive packing foam that the ESP module came in, and plugged the exposed pins into it:

To protect the exposed pins, I plugged them into the non-conductive packing foam that the part came in.

There are still a few exposed pins, and on the top side of the module are lots of metal parts and solder connections, so just make sure you keep away from any metal parts!

Now I was able to hook this up to my Color Computer’s Serial I/O port and load up an old terminal program and start using Zimodem.

Zimodem via Greg-E-Term on a Radio Shack Color Computer via the bitbanger Serial I/O port at 1200 baud.

RS-232 Challenges – Carrier Detect and Flow Control

A quick tidbit on RS-232…

There are nine lines used for RS-232. They go between the computer (DTE, data terminal equipment) to the device (DCE, data communication equipment). Prepare for many acronyms!

TX and RX: You can think of most lines as one-way paths, with some lines going from the computer to the device, and others going from the device to the computer. For instance, transmit (TX) from the computer goes one way to receive (RX) of the device. On the device, it’s transmit goes one way to the receive of the computer.

CTS and RTS: Some lines are used for flow control. Each device has a request to send (RTS) output line that goes to the other side’s clear to send (CTS) input line. CTS goes to RTS, and RTS goes to CTS, similar to have TX and RX and handled. For example, the computer turns on RTS (request to send) to tell the remote device it is okay to send data. The remote device reads this on it’s CTS (clear to send) pin. The reverse is also true, with the remote device’s RTS going to the computer’s CTS. Thus, if using flow control, the computer or device only send when their CTS (clear to send) line is active.

DCD: The device may also use carrier detect (DCD). For a telephone modem, when a call is connected, the device will turn on carrier detect. The computer can read the status of the DCD line to know if a connection is in progress.

RI: There is a ring indicator (RI) that was used by modems to indicate an incoming call. I’ve never used this at all, since the RS-232 interface I had back then wasn’t even wired for it.

DTR and DSR: I am less clear on how all these could be used, but in general, DTR was set by the computer to tell the remote device if it should hangup or not. The computer would “drop DTR” and that would force the modem to hangup. DSR is set by the device to indicate it is there and ready.

Here is a quick chart to explain them, specifically as how they are used by Zimodem:

 DTE (Comp.)        DCE (Modem)
 DB-9 Male          DB-9 Female
=============      =============
pin in    out      in    out pin
1   DCD <--------------- DCD   1
2   RX  <--------------- TX    2
3         TX  ---> RX          3
4         DTR ---> DTR         4
5   GND                  GND   5
6   DSR <--------------- DSR   6
7         RTS ---> CTS         7
8   CTS <--------------- RTS   8
9   RI  <--------------- RI    9

Some RS-232 interfaces require more than just TX and RX to be happy. The Color Computer’s RS-232 Pak, for example, uses a 6551 UART chip. This chip will not receive data unless it sees carrier detect (DCD). Old telephone modems would provide this DCD signal when a call was in progress, and drop the signal when the call ended This gave the computer a way to know if a connection was established or not. Unfortunately, this signal is not present in a 3-wire connection.

Faking carrier detect and flow control

It was possible to hook two computers together without a modem by using a NULL modem cable. These cables would swap TX and RX, so one computer’s transmit would end up at the other computer’s receive. They would also often do some trickery to force the DCD signal to be active. They did this by tying some of the pins on the RS-232 port together:

RS-232 port modification to make it operate without needing real DCD and other signals.

If we really don’t care about this missing lines (like CTS/RTS flow control, DTR/DSR, etc.), we can modify the RS-232 to TTL adapter so make it provide a fake DCD signal back to the computer.

Using the above diagram as a reference, I was able to solder a few pins together and use a short piece of wire to recreate it on real hardware:

Ugly soldering example of tying the DCD, DSR and DTR pins together, as well as CTS and RST.

This modification makes it so anytime the computer enables DTR, it will make DCD and DSR read as if they are enabled. It is creating a fake status by looping the DTR signal back into the DCD and DSR input pins.

Since this 3-wire hookup also does not have CTS and RTS, if the computer is expecting CTS (clear to send) to be active, that can never happen and thus it can never send. This modification ties the outgoing RTS (request to send) back to the incoming CTS (clear to send). When the computer enables request to send, to tell the remote device it is okay to send, it will read that same signal as if the remote device sent in it’s own request to send (coming in on the CTS line of the computer).

So much stuff.

Suffice it to say, but tying these lines together, it will fool the RS-232 device into thinking there is an active carrier detect and data terminal ready signal from the demote device anytime DTR is enabled. And, it will see a clear to send signal anytime it turns on read to send… Loopy goodness!

With that said, if you don’t want to solder, you could pick up these RS-232 jumper devices and create the connection this way. Note that in this example, I do not have CTS and RTS tied together. For my specific test, I did not need it, but other RS-232 interfaces may require it.

Minimal wiring required to get an RS-232 Pak to talk to a 3-wire RS-232 interface (TX, RX and GND).

5-wire hookup – Implementing real CTS/RTS flow control

Another option is to use an RS-232 to TTL adapter that actually provides more of these signals. For a bit more, you can find an adapter that has CTS and RTS as well:

“5-wire” RS-232 to TTL adapter, adding CTS and RTS for flow control.

By adding two more wires between Zimodem and the adapter, you can use real hardware flow control. Zimodem will only send when it sees a clear to send signal from the computer, and if Zimodem can’t handle all the data it is receiving, it will disable it’s request to send, so the computer’s CTS line indicates “stop sending me stuff!”

    TTL         ESP8266
    ===         ==================
2   RX  <------ TX  GPIO1 (TX)
3   TX  ------> RX  GPIO3 (RX)
5   GND <------ GND GND
7   RTS ------> D1  GPIO5  (CTS)
8   CTS <------ D2  GPIO4  (RTS)
    VCC <------ 3V3 3.3V

This configuration still would not work for my 6551-based RS-232 Pak. I would still need to fake the carrier detect.

Full-wire hookup – as real as it gets

The final, and best, solution is to use an RS-232 to TTL adapter that actually provides all the signals that Zimodem supports and that your RS-232 interface may require. This requires hooking up even more wires (ten total):

    TTL         ESP8266
    ===         ==================
1   DCD <------ D4  GPIO2 (DCD)
2   RX  <------ TX  GPIO1 (TX)
3   TX  ------> RX  GPIO3 (RX)
4   DTR ------> D6  GPIO12 (DTR)
5   GND <------ GND GND
6   DSR <------ D7  GPIO13 (DSR)
7   RTS ------> D1  GPIO5  (CTS)
8   CTS <------ D2  GPIO4  (RTS)
9   RI  <------ D5  GPIO14 (RI)
    VCC <------ 3V3 3.3V

Mine looks like this:

Wiring up a “full” RS-232 to TTL adapter.

If all those wires get to you, you can also do the same thing on a breadboard:

ESP8266 to RS-232 on a breadboard.

Configuring Zimodem: Commodore versus The World

Although the wiring seems complete, there is one final issue that needs to be solved.

Zimodem, when built for the ESP8266, inverts all the RS-232 signals. This is because that is how Commodore computers did it, and Zimodem was designed for Commodore users. Commodore inverts HIGH and LOW from the standard, so all signals have to be inverted in
Zimodem from their defaults. On Commodore, “HIGH” means active. For RS-232, “LOW” means
active.

What this means is even if you have the carrier detect wired up properly, Zimodem is going to send the opposite signal. When a connection is in progress, the signal will read as “no carrier” to a normal RS-232 interface. When Zimodem is ready to receive data, the request to send will look like the opposite.

This causes huge issues :)

If you are using my special build of Zimodem, you can skip this section. I already pre-configure my version as follows.

Fortunately, Zimodem is fully configurable. Using simple “AT” commands, you can change the behavior of any of the incoming or outgoing RS-232 signals that Zimodem uses. All you have to do is be able to send some commands and then save the Zimodem configuration. Here is the summary:

AT S Settings:
==============
0=HIGH is active (defualt).
1=LOW is active.
2=force HIGH
3=force LOW

Sig  SReg Default RS-232 Standard
===  ===  ======= =================
DCD  S46  0       1 (force LOW)
CTS  S48  0       1 (force LOW)
RTS  S50  0       1 (LOW is active)
RI   S52  0       1 (LOW is active)
DTR  S54  0       1 (LOW is active)
DSR  S56  0       1 (LOW is active)

You can set these commands one at a time, like:

ATS46=1
OK
ATS48=1
OK
...etc...

…but you may find that the moment you toggle one of them, you appear to be locked out. This is because the inverted defaults actually work to our advantage. On my interface, I need DCD before I can receive. Zimodem has no carrier, so it is sending out the inverted “there is no carrier” signal, which reads as “carrier detect” for me. The moment I “fix” that so it sends the normal signal, I suddenly have no carrier and can no longer receive data.

You may choose to send all the commands in one line:

ATS46=1S48=1S50=1S52=1S54=1S56=1

However, as soon as that is done, you may not see “OK”. Carrier detect is still flipped… You may be able to still send commands, but you would be typing blind if your interface requires DCD before it will receive. Because of this, I like to force DCD to be always on:

ATS46=3S48=1S50=1S52=1S54=1S56=1

That command flips everything, but makes sure DCD (S46) is forced low (3), so it appears like a carrier is always present. This lets me communicate with Zimodem at all times.

If I were running a BBS that relied on detecting carrier, I would have to leave that at S46=1 and just send commands blindly. (BUT, one of my old terminal programs, Greg-E-Term, is not coded in a way that makes this work. It seems if there is no DCD, it doesn’t let me send anything at all. Other terminal programs I have do not behave this way, so I consider it an issue with what GETerm was designed to do.)

Confusion Conclusion

With all of this said, there are probably still many omissions. A future article needs to be a summary of useful Zimodem commands and tutorials on how to use it.

I also want to cover another alternate approach to having to configure with all those ATS commands. In my case, I simple modified the source code so the version I built had them setup the normal way so I never had to do any configuration.

And I need to document how to just install a binary without using Arduino IDE.

Until then… Comments greatly appreciated.

Parsing Hayes modem AT commands, part 2

See also: Part 1

I know I am supposed to be posting my updated joystick code, which I will do as soon as I have a moment, but I wanted to share some other new stuff first so it can start getting in to the Google indexes.

I have created the first part of some quick-n-dirty code to handle Hayes modem “AT” commands. For a bit of background on the Hayes modem command set, check this Wikipedia entry:

http://en.wikipedia.org/wiki/Hayes_command_set

For some more specific details, check out this Wikibooks entry:

http://en.wikibooks.org/wiki/Serial_Programming/Modems_and_AT_Commands

The Hayes modem company needed a way for the controlling system (user, terminal program, BBS, whatever) to switch the modem from Data Mode (where bytes come in, and bytes go out) to Command Mode, where the modem could be controlled (dial a number, hang up, configure how many rings to answer on).

To get in to Data Mode, a series of three characters is sent – the default being “+++” – with a one second pause (called the “guard time”) before and after them. That way, if the string “+++” appears in normal data being transmitted (like this article), the modem doesn’t respond to it. It would take a pause, then the “+++”, then another pause, and the modem would stop sending and receiving data and present the host system/user with an “OK” prompt and then accept commands.

My code was designed to be used in the main loop() where data would be processed. Code would check for incoming data from the remote device and handle it (such as seeing bytes come in over a modem or serial port), and then look for local input (like the user typing, or a program sending data out). If it was a dumb terminal program, that loop might look like this pseudo code:

loop()
{
    char ch;

    ch = readIncomingData();    // Get byte from remote system.
    Serial.write(ch);           // Print byte to local screen.
    ch = Serial.read()          // Get byte from local input.
         writeOutgoingData(ch); // Print byte to remote system.
}

This, of course, is not working code. A few more lines would be needed to check for valid data and such, but hopefully you get the idea. The loop would continuously run, reading data if it were there, or moving on to the next instruction.

My code is designed to plug in to that loop, after each byte is read from the local user:

loop()
{
    char ch;

    ch = readIncomingData();                      // Get byte from remote system.
    Serial.write(ch);                             // Print byte to local screen.
    ch = Serial.read()                            // Get byte from local input.
         if (cmdModeCheck(ch) == true) cmdMode(); // ADDED
    writeOutgoingData(ch);                        // Print byte to remote system.
}

The idea is to let me code inspect each character that comes from the host system, and then see if there has been a pause of at least “guard time” since the previous character, and if so, start evaluating the characters to see if they are the “+++” escape sequence. If three plusses are seen in a row, it then sees if “guard time” has elapsed and, if so, return a true value to let the calling function know it is time to switch in to Command Mode.

According to the Hayes modem standard, the character used for the escape sequence (“+”) is configurable, as is the guard time. Because of this, I use two global variables for these, so the user can modify them and affect my cmdModeCheck() function:

// Define the escape sequence.
#define ESC_GUARD_TIME 1000 // Seconds required before/after escape sequence.
#define ESC_CHARACTER  '+'  // Default escape character.

// For Command Mode.
unsigned int escGuardTime = ESC_GUARD_TIME; // Delay before/after esc sequence.
static char  escCharacter = ESC_CHARACTER;  // Escape character

I am just using the #defines for default values. A function will be written later that will let the user set them, like setCmdModeCharacter(‘?’) to make it “???” or setCmdModeGuardTime(2) to change the guard time to two seconds.

Not much here so far, so let’s look at the actual function. I will insert some comments

// Magic numbers.
#define ESC_TIMES 3 // Number of escape characters ("+++").

boolean cmdModeCheck(char ch)
{
    static unsigned long escCheckTime = 0; // Next time to check.
    static byte escCounter = 0;            // Number of esc chars seen.

    // If no character is being passed in, we are just doing a check to see if
    // we are in a "wait for end guard time" mode.
    if (ch == 0)
    {
        // See if we are waiting to enter command mode.
        if (escCounter == ESC_TIMES)
        {
            // Yep, we have already found all the escape sequence characters.
            if ((long)(millis() - escCheckTime) >= 0)
            {
                // And the pause has been long enough! We found an escape sequence.
                escCounter = 0;
                escCheckTime = millis() + escGuardTime;

                return true; // Yes, it is time for Command Mode.
            }
        }
    }
    else // if (ch==0)
    {
        // If there has been a pause since the last input character...
        if ((long)(millis() - escCheckTime) >= 0)
        {
            // Check to see if it's an escape byte.
            if (ch == escCharacter)
            {
                // Move to next character to look for.
                escCounter++;

                // Are we out of escape characters to check for?
                if (escCounter >= ESC_TIMES)
                {
                    // Set after delay to signify end of escape sequence.
                    escCheckTime = millis() + escGuardTime;
                }
            }
            else
            {
                // Reset. Not an escape character.
                escCounter = 0;
                escCheckTime = millis() + escGuardTime;
            }
        }
        else
        {
            // Reset. Not an escape character.
            escCounter = 0;
            escCheckTime = millis() + escGuardTime;
        }
    } // end of if (ch==0) else

    return false; // No, it is not time for Command Mode.
}

I should explain that, in order for this function to work, it needs to be called often enough to determine if the guard time (1 second) has elapsed between incoming data. If the input is idle, the function still must be called, but with ch=0 (no data) which is why, at the top, it looks for an incoming character of 0 then it will handle timing stuff.

The way it works is by keeping a count of how many escape characters in a row we have seen so far. I use static variables so they maintain their values between calls to the function. Since I do not use them anywhere outside of this function, I saw no reason to make them global.

“escCounter” starts out at 0. If we get a “ch=0” value, we want to see if we are waiting on the ending guard time. i.e., have we gotten as far that we’ve seen 3 escape characters in a row, and are now looking for a 1 second pause? If escCounter is 3 (ESC_TIMES), we use a nice timing rollover routine from the Arduino.cc Playground to see if it’s been at least guard time with no other characters coming in. If it has been that long, we reset out escCounter back to 0, and make a note of some future time (representing now + guard time in the future). More on this in a moment, but by returning “true” at this point, we have reported back that we have seen “(pause)+++(pause)”.

Ideally, I should have explained the previous code after explaining this next bit first, since it is setting some things up we haven’t discussed yet. Hang in there and things should become clearer…

At the else, we handle a situation if “ch!=0” (i.e., if we were passed in a character from the host system/user). When we initialized this function, there was an “escCheckTime” variable set to 0. In this loop, we test to see if the time difference between now “escCheckTime” to see if we have gone past it. The very first time this runs, that will be some number minus 0, which will always be greater than 0, and thus always look like it’s been that long. Since we are just starting up, we always want to consider the first character we see. Subsequent calls will be using an “escCheckTime” that is generated based on “now + guard time”, so we are really checking to see if we have passed that future moment in time.

As you will see in a moment, every time a non escape character comes in, or anything else comes in during our guard time wait period, we just reset everything since it’s clearly not an escape sequence.

BUT, if the character we receive IS our escape character (“+”), we increment our “escCounter” to indicate how many of them we have seen in a row. It would go from 0 to 1 this first time.

If the counter gets up to 3 (ESC_TIMES), we have seen three of the escape characters in a row without being reset, so we set our escCheckTime to be “now plus guard time”. If you go back a few paragraphs, you will see we check this in the “nothing to do here, move along” function, so it can say “oh, it’s been at least guard time, AND we have seen our escape character sequence. Must be Command Mode time!”

But if it was NOT our escape character (else), we reset escCounter back to 0, and reset our check time yet again to “now plus guard time” to start the whole process over.

The next else is from the “has it been longer than guard time” if statement, and if we got a character before our guard time elapsed, we know it’s not an escape character so reset everything (just like the previous paragraph).

I hope to clean that up a bit so it doesn’t have to do it in two places like that.

At the end, we return false, because if we got there, we are in the process of either normal data, or scanning through a potential escape character sequence.

When I return, I will provide a full code example, and hopefully have some enhancements to the above function. Until then… I have to get back to packing. My rent is going up and it looks like I will be moving soon.

Parsing Hayes modem AT commands, part 1

2014-03-03: Latest source code is on GitHub.

Several of my Arduino plans involve the old 1980’s Radio Shack Color Computer (CoCo). I have previously discussed plans to use modern USB mice, joysticks and keyboards with this old home computer, as well as going the other way and allowing old CoCo joysticks to be used on modern PCs.

That seemed like an easy first step, and one I hope to find time for some time before I retire. I haven’t had time to touch any of this for awhile. That, however, does not stop me from planning even more projects.

There is an Arduino Ethernet shield currently available for $17.99 from Sainsmart in China. They ship free to the USA, but it takes awhile. For a bit more, you can buy it from Amazon and have it shipped 2nd day via Amazon Prime.

These shields provide an Ethernet port for the Arduino, and library code is provided to do basic things such as make a TCP socket connection. Samples exist showing how to go retrieve a web page, FTP put/get a file, or even serve up web content so you can create an HTML interface to interact with the device. With the Arduino doing the physical interfacing to the wire, and heavy lifting of the TCP/UDP/IP protocol stack, this might be an easy way to bring internet connectivity to the CoCo.

Over a decade ago at the 2001 Chicago CoCoFEST! convention, Minnesota-based Cloud-9 Tech announced plans for the “Superboard” hardware add-on. It would be a secondary I/O board that would connect inside a CoCo case and bring all kinds of hardware add ons, such as a hard disk interface. The product has yet to be completed, but many spinoff items have been released during development.

One of the proposed features of the Superboard was the addition of an iChip from ConnectOne. This chip implemented TCP/IP as well as common internet protocols like FTP, Telnet and mail. Small devices could talk to the chip via serial (like talking to a modem) and send commands, then the chip would go do the actual work via a dialup ISP or ethernet link. I thought this was the killer feature, and started referring to this project as the “Internet CoCo.”

I even looked in to making an RS232 adapter that would have an iChip in it, so you could plug a cable from an RS232 pak on the CoCo to this adapter, then to a modem and get all the features that way. But, at the time, I didn’t have the money to invest in the ConnectOne reference platform (a modem with iChip built in) to work on it.

Well, today the iChip is still made and only cost $25 in single unit quantities. I still think this adapter would be a great idea, but perhaps there is another way…

It would be relatively trivial to write Arduino code that would do this. A CoCo (or any device with RS232) could send commands to the device to establish network connections and then the data could be passed back as serial data. The only tricky bit would be allowing multiple socket connections (FTP, for instance, uses two at a time). For that, some form of serial multiplexing (using one serial line with a protocol on it to act as multiple lines) could be used.

Side Note: There is an absolutely amazing thing called DriveWire created by a former coworker of mine, Boisy Pitre. He created a serial protocol to allow a PC to host disk files for a CoCo via the bitbanger serial port. Over the years, the protocol has evolved and gained many features well beyond virtual disks. It’s truly amazing.

Well, today, the DriveWire server already implements much of what I am talking about doing, including multiplexing serial ports so a CoCo, connected by a single serial cable at 115Kbaud, can have multiple virtual serial ports, MIDI ports, disks, hard drives, etc. DriveWire even runs on a $25 Raspberry Pi, so one could do this without even needing a full PC nearby…

…but that won’t stop me from learning and experimenting. In fact, after I started my current job almost a year ago, I got access to a Raspberry Pi which I hooked up recently for the first time. I expect whatever I develop for Arduino I will also port to Raspberry Pi. Perhaps I can even make the Arduino code speak some of the DW protocol for virtual serial ports and such.

We shall see.

But I digress.

The real focus of this posting is to share my code for a Hayes modem “AT” command parser. In olden days of dial up modems, there were certain “smart” modems that could dial the phone on their very own. Amazing. On power up, these modems were in “command mode” and you could type commands to them like “ATDT 555-1212”. This mean “(At)tention. (D)ial using (T)ouch tone. 555-1212”. “ATH” was the hang up command. Various other commands existed for things like telling the modem if it should auto-answer the phone after a certain amount of rings, or specify how fast the touch tone dialing should be.

The “AT” command set was created by the Hayes Modem company, and other manufactures had their own system for interacting with their modems, but eventually the Hayes command set won out and became a standard. (There’s a great Wikipedia article on this.)

Since the iChip (and pretty much everything else, including modern cell phone modems) makes use of a Hayes-style command set, I thought I would implement something similar myself.

So, coming up soon, I will share code that handles the basics of this, and then will start piecing things together to interface it to the Arduino Ethernet port so you could do something like “ATDI 127.0.0.1:80″ (Attention, dial over the internet to IP address 127.0.0.1 port 80”.

Sounds fun. If I can find the time.