Networking the Sound
Digitizing Device

October 20, 2002

Lansing, Michigan

The networking portion of the prototype Sound Digitizing Device installation is explained in the following text. Our goal included working within the operational confines of the existing network architecture, currently supporting previous envirosonics related research. The existing network included a Satellite feed via a DirecPC two-way communications Internet link and a two-way communications Internet link via a local cable modem service. See the network diagram below:

 

The desired method of communications to the MSU server was through the DirecPC satellite system to best emulate a field installation. However, the satellite system was not designed to provide the generic network connectivity we needed. The satellite system we were working with was designed to work with a standard desktop PC running proprietary satellite networking support software through a USB interface. The satellite system supported the sound capturing PC being used as office level model for this research, and could not be disturbed. The network IP from the satellite feed is also a non-routable private IP address, so getting to the Sound Digitizing Device system for updates and changes would not be easy. Networking the Sound Digitizing Device prototype on the satellite feed would be a difficult and messy networking job, further complicated by the satellite feed line to the PC being based on a USB link rather than Ethernet.

To provide the digital audio data to the satellite, we would have to dual home the win 2000 PC and utilize an Ethernet network card to provide a network link between the win 2000 system and the Sound Digitizing Device. See Below:

 

This was the network topology after our first visit to Lansing to install the SDD. It provided the connectivity between the SDD and the Envirosonics PC. However, it did not provide access from the Internet to the SDD directly.

The flow of sound data starts at the SDD at the lower right. The sound is recorded digitally and stored locally on the SDD utilizing a program called LAME to rip files from the live-ice generated stream. The sound data is also provided as a live audio stream that can be monitored on the Envirosonics PC using a program such as WinAmp. However, the recorded file stored locally on the SDD is transferred to the Envirosonics PC via the network link provided by two Aironet 2.4 GHz ISM band DSSS radios. Both the Envirosonics PC and the SDD connect to the Aironet radios via Ethernet. The file is transferred and named according to a scheme, which denotes the day and hour, but is completely configurable. A copy of the ftp'd file is then transferred from the Envirosonics PC to the Internet through the DirecPC satellite to an MSU server via FTP. A unique program, existing in the Unix environment for many, many years called "Expect" is utilized to mimic a user typing command line arguments into a program interface. In other words, "Expect" is a programmed virtual user inside the SDD that interacts with the ftp program to initiate the ftp session to the Win 2000 machine. An expect script is quite simple;

Send "FTP 192.168.0.1"
Expect "login"
Send "MyUserName"
Expect "password"
Send "MyPassword"
Expect "ftp >"
Send "bin"
Expect "binary"
Send "put stream10-21-1230"
Expect…

The expect program is able to interact with a great many programs, making it a very powerful tool to perform house-keeping within a computer system, special tasks, such as we are using, and can even perform decision making in many forms.

The network path of the sound files transferred via ftp is shown below.

A few problems remain after the implementation shown above:

· No remote access could be provided through the DirecPC Satellite connection for updates or adjustments.
· No streaming outside of the Envirosonics PC could be accessed.
· Win 2000 machines do not make the best Internet gateways, especially when one interface is a USB port talking to a satellite via proprietary means.
· The IP addresses used within the DirecPC network are not routable from outside the DirecPC network. This could be alleviated via a virtual tunnel to a trusted remote machine.

To alleviate the problems as easily as possible, we looked at the Cable Modem side of the network. Our solution to the problem was to install a gateway system that does NOT route packets, but rather has access to both networks. The gateway system chosen was an IBM Thinkpad system running Redhat Linux 7.3, using two Ethernet interfaces. One interface would connect to the Satellite network, and the other interface would connect to the Cable Modem network.

If you follow the yellow arrows, you will see the path used for remote management of the SDD, which allows connections from one network to the other network, but not in a routed fashion. You must log into the laptop acting as a gateway between the two networks to access the other network. If you follow the maroon arrows, you will see the ftp path for the audio files discussed earlier.

Yellow Arrows: Remote Management
Maroon Arrows: Audio File Transfer Path

To provide an added security measure, both the laptop in the middle of the picture above and the Sound Digitizing devices utilize Secure Shells (SSH). The secure shell is accessed via a program called "Putty" which exists in the public domain and runs under Windows. You open up the SSH program "Putty" and select the SSH connection to the appropriate IP address. After authentication, the SSH program allows access to the system as if it were a telnet session. Most other sockets or ports on the Thinkpad laptop and the SDD have been shut down to provide fewer opportunities to be hacked.

The laptop was picked for the gateway for several reasons, such as:

1) Linux is known to run well and install easily in the IBM Thinkpad systems, and since this was a remote install with a time crunch, things needed to go smoothly.
2) A laptop has automatic battery backup when the 110V AC power fails.
3) The size is small and the CPU power more than adequate for the intended use, as well as possible future streaming use.
4) Linux is very network friendly, easily configured multi-network operating system, so this provides a reliable access method in a true multi-user environment.

The SDD system provides several functions over and above the command line interface. Since the typical biologist is not a network guru, we have provided a "point & click" interface via a web-based tool. This tool is called "Webmin" which is easily configured to provide a point & click interface to many lower level Linux programs. From this interface you can manipulate IP addresses, or which programs run or listen to sockets, configuration of programs, configuration of users, etc. It makes Unix administration as easy as that of a Windows based machine. Webmin has the added ability of being changed when something does not do what you would expect, or you could write your own simple tool to provide the manipulation of some parameter not readily offered in the pre-packaged Webmin interface.

Another web-based interface is provided by the streaming software. By accessing a specific port on the SDD via a standard browser, you can look at the history of recorded digital sound tracks previously transferred to the server system. This interface can provide another way to access the data recorded by the SDD for use other than the routine use it was designed for. You can also force a recording if an event was happening in the area that would provide interesting data, such as the sound of a storm, a migration of birds, or man made sound events.

Keep in mind the complexity of the network shown in the previous network diagrams does not reflect a field deployment of a SDD, but rather to fit the SDD prototype within the confines of an existing network. The actual network implementation should be designed in advance to facilitate the needs of the device and all humans that will support the system, while targeting simplicity for a main goal. Below are two examples of what a field deployment might actually look like:

Example 1: Using "Smart Sensors" with IP all the way to the sensor:

Below, using "Less Smart - Smart Sensors" in a very cost effective deployment:

In the design immediately above with "Less smart - smart sensors", another not-so-obvious parameter was alleviated: *Power*. By using very simple circuits as the acoustical sensors, and the digitizing done in only one place, the need for fairly large amounts of power is greatly alleviated. To follow this power reduction effort even further, a far more simple SDD could be designed such that the digitization takes place within a DSP (Digital Signal Processor) Integrated Circuit (IC) programmed to perform this function and requiring far less power than any off-the-shelf device we have available to us at this time.

Conclusion:

The network additions performed to facilitate this prototype installation were quite creative and reaching for opportunities to manipulate the network as passively as possible, while providing the connectivity desired. The operational design from the SDD viewpoint reflected a desire to provide capabilities we would like to have in a true field installation designed for envirosonics research. We achieved all of the goals for the prototype, some of which were formal requirements, and others which were "would it be neat if…." desired modes of operation. We have shown several network designs, with examples of what would be far more simplistic in implementation, along with ideas of the next generation Sound Digitizing Devices that would facilitate envirosonic research completely.

Michael Willett
Senior Technical Assistant and Collaborator

 

PREVIOUS