There were several primary design constraints Dennis had to resolve before setting up the system to implement PPP and FTP to transfer data. First, Dennis had to develop his own FAT16 compatible compact flash drivers. Second, he could not use the onboard RAM or parallel Flash for the audio MP3 files since he knew that they could easily grow quite large (as in over 1MByte) in size. Third, he was told that the wireless link could at times be unreliable, dropping the link after only a short time.

“Engineering” FTP file transfers

To address the customers' worries about the sometimes fragile wireless connection, a special solution was needed to ensure the transfer of the often-large MP3 file recordings. His working approach segments the single MP3 file into “chunks” that can be reliably transferred via the wireless modem. Prior to the segmented file being transferred, a “header” file is sent that gives all the information needed to calculate the number of chunks that would follow. If the link dropped during this process, we would be able to restart at the next “chunk”, building on the file transfer progress to date. The files could easily be reassembled into one long file at the destination end.

Several routines were written using Dynamic C's innovative co-statements and co-functions as a means of ensuring the reliable transferring of data through the wireless modem. The primary focus remained on reliably transferring the data in as accurately as possible. A main co-function checked to see if a new audio file was ready (In file pointer ahead of the Out file pointer), and if so, started the file transfer process, continuing the process until the transfer is completed successfully. A second co-function initiated the header file transfer, followed by a number of “chunk-sized” data files. A separate co-function brought the link up if any data transfer was needed, and brought it down after a time delay when the transfer completed. This ensured that the wireless link was only brought up for the time required to transfer the data, conserving power consumption of the unit.

Setting up a server to use PPP

To test the system before delivery, a test dial-in server was set up to emulate the real-world and allow an environment for testing and final debugging the Rabbit code. The server had to have both a dial-in PPP server (to allow serial line connections for TCP/IP networking) and a FTP server (to allow file transfers).

Two systems were setup to test on both Linux and Windows platforms. First, an old PC (450 MHz, Pentium II with 256MByte of memory) ran the latest RedHat Linux open-source code, Fedora Core1 and subsequently the Windows 2000 Professional workstation ran a Windows dial-in server program. Linux came with the vsftp code for the FTP server. For the Windows system, Dennis downloaded and installed Cerberus , a shareware FTP server for Windows 2000.

Setting up a Linux Dial-in Server

The first task was to setup the test link with a linux dial-in server. There is a lot of developer community support and a number of excellent tutorials available for setting up the server. In addition, it is very easy to turn on detailed debugging information to log all transactions, and to infer what is wrong with the PPP and FTP transfer processes. Detailed information on setting up a Linux dial-in server (and more) is available at The Linux Review under the article LINUX PPP HOWTO .

Dennis feels from his experience that Linux prefers to use “outboard” modems connected via a serial port. The server, a 450MHz Pentium II, built on an Intel SB440BX motherboard, has two available serial ports, COM1 and COM2 known as /dev/ttyS0 and /dev/ttyS1 respectively. A US Robotics/3Com V.90 56K Sportster modem was used to create the dial-in server. Dennis also was sure to have a proper modem connection cable for use between the serial port and the modem. A 9-pin to 25-pin cable adapter (straight through, not “null” connected) was used to connect the modem to the PC serial port.

Available options are spelled out in the documentation referenced above for pppd. The last option specifies the IP address of the “server” from the Rabbit point of view. It will be the IP address of the FTP server to transfer to. There are other ways to use the Dial-In server as a gateway (including providing Domain Name Services and Routes) which are not covered in this article.

Setting up the Rabbit – “IFCONFIG” Revealed

The details below demonstrate the essential parts of the “SendExpect” strings needed to bring up the PPP link using the IFCONFIG Macros. The number “DIALUP_NUMBER” has been changed to a non-working number. The last line is shown wrapped – it is a portion of the “DIALUP_SENDEXPECT” string.

#define DIALUP_AUTOPPP "/AutoPPP/"
#define REMOTE_USERNAME "testman"
#define REMOTE_PASSWORD "123456"
#define REMOTE_HOST "192.168.1.51"
#define DIALUP_NUMBER "16085551212"
#define DIALUP_SENDEXPECT "ATDT" DIALUP_NUMBER " CONNECT '' ogin: " DIALUP_AUTOPPP

The ifconfig() call below has been modified to reflect a “static” definition. In our actual code, users can re-configure the DIALUP_SENDEXPECT, REMOTE_USERNAME, and REMOTE_PASSWORD strings using a simple terminal connected to the programming port. The PPP Interface is configured ONCE, near the top of Main as follows:

// Configure the PPP Interface characteristics
   ifconfig(IF_PPP1,
            IFS_PPP_INIT,
            IFS_PPP_SPEED, 38400L,
            IFS_PPP_RTSPIN, PCDR, &PCDRShadow, 2,
            IFS_PPP_CTSPIN, PCDR, 3,
            IFS_PPP_FLOWCONTROL, 0,
            IFS_PPP_SENDEXPECT, DIALUP_SENDEXPECT,
            IFS_PPP_USEMODEM, 1,
            IFS_PPP_HANGUP, "ATH",
            IFS_PPP_MODEMESCAPE, 1,
            IFS_PPP_ACCEPTIP, 1,
            IFS_PPP_ACCEPTDNS, 1,
            IFS_PPP_REMOTEAUTH, REMOTE_USERNAME, REMOTE_PASSWORD,
            IFS_END);

Later the interface can be brought up with:

	ifconfig(IF_PPP1, IFS_UP, IFS_END);          

The interface can be brought down with:

	ifconfig(IF_PPP1, IFS_DOWN, IFS_END);

Final thoughts on debugging PPP

When setting up the dial-in server, use a PC to establish a connection first. Make sure that you understand the process with computers that you know work. You can use either Linux (Fedora Core 1 provides a Network Configuration Tool to set one up) or Windows (Start->settings->Network and Dialup Connections). This will debug your “server” first, making the rest of the debugging easier. This requires you to have two modems (one on the server; one on the client) and thus, two phone lines. It is recommended to connect the modem for the server to a FAX line during testing. A laptop with a built-in modem for a Windows 2000 client will work just fine to test the linux server side.

Modems can produce surprising results. Test the modem (especially wireless modems) using a terminal program first before beating your head against the wall with your new PPP code. If necessary, get a RS232 breakout box with lights to help you through the process. It is amazing how much time you can waste getting the physical connections correct! For low-level debugging use a program such as minicom (linux) or TeraTerm (Windows). HyperTerminal (Windows) will work, though it is harder to configure and use. Terminal emulator programs let you deal with the modem directly to verify that the set up command strings are correct and to verify that the modem is in the correct mode. If you can't connect to your dial-in server with a terminal emulator and your modem, you likely won't be able to get to it from the Rabbit, either. Another useful tool is the telephone line simulator, which doesn't force you to tie up your telephone lines. Dennis recommends using either the Teltone TLS-4 or TLS-5 depending on the features that you need. These are available on Ebay.

For help in debugging TCP/IP connections once the connection is established, consider using Ethereal ( http://www.ethereal.com ). It will show detailed packet data for the interface transmissions, including all of the headers, checksums, etc.

Finally, test the configuration well on well-known data. Due to a programming error, Dennis had been intermittently sending bad MP3 data. The audio always sounded fine because the errors were masked by the MP3 encoding process, making them seem correct. The error was discovered later when Dennis was testing smaller files of data for a different application.