Web-enabled Interactive Contest Experience (WICE)
During contest operation we do run a special website with a lot of online information:
- Live contest audio, listen to the signal the operators hear
- Live video. A number of webcam's are online
- Log. Actual Actual log of stations worked is shown
- CQ frequency. The current frequency is displayed during CQ
- Operator. Information is given on the current operator
- Antenne QTF. Direction of the antenna is given (only during VHF contests...)
- Chat. Visitors are able to chat with the operators
How it works
Detailed information is given how we have set up the different applications and hardware. The overal architecture is explained, used applications and how those applocations are implemented. Followed by a description of the specific components and the actual hardware implementation. An Adobe Acrobat formated .pdf containing all information can be downloaded here.
WICE is build up around an interactive Web page where all information is displayed and users can interact by the chat window. Video source (webcams) and live contest (streaming) audio are provided. Contest information (e.g. log and actual cq/s&p frequencies) as gathered by the contestlogging application is combined with antenna bearing (for VHF contests only), reformatted by the data aggregator and integrated on the webpage.
WICE is build around standard available building blocks (with the exception of the data aggregation part). Picture below is given the application architecture together with the main interfacing.
The webserver is servicing all the incoming http requests and presents the webpage. Webpage is generated dynamical by using PHP scripting. Data used is the SQL database content, holding e.g. qso, operator and radio-frequency information.
The video content is embedded in the webpage by randomly selecting one of the available video sources. Some video sources will directly upload the video content to the server's datastore or, for the USB connected camera's, using a separate application.
Real-time audio is streamed to the Icecast server. Icecast server is capable of servicing many users with the audio stream. Clients should support the streaming MP3 format, e.g. Winamp, Media Player, Real Player, iTunes, etc.
The contestlogger will send his actual data (log, operator, CQ frequency) to the data aggregator in a raw format. The aggregator extracts the relevant data, add to it rotor (QTF bearing) information and upload it to the SQL database.
Antenna bearing information is gathered by the LABJack application DLL's , corrected by a calibration routine and added to the aggregation data send to the database.
Mentioned applications are implemented on standard hardware with moderate specifications.
N1MM contest logger is installed on the "log" server and used for logging during the contest. Logger is configured as Multi-operation mode (even if the contest is single operator!). In multi-operator mode all data is send to all configured hosts (via the station name dialog). Station "0" should be the actual logserver and one of others stations the host where the data-aggregator is installed. Every logged qso, actual radio frequency (if attached to the logserver) and operator name will be send to the configured hosts.
Data-Aggregator / Listener
Data-aggregator (listener) is the application capable of
- receiving the broadcasted qso/log information from the contestlogger
- Gathering antenna position/bearing information from the attached LabJack interface
- Calibration of this antenna position
- Connecting to a MySQL database and storing the data
Listener is build as a Delphi application together with the required database and LabJack libraries.
LabJack interface will provide the voltage present on one of his inputs to the data-aggregator via the USB interface. Voltage is the voltage as measured at the rotor interface and is an indication for the antenna bearing.
The audio output from the transceiver is connected directly to the soundcard of the server running an Icecast mp3 encoder client. The encoded data is streamed to the icecast server which is colocated and has an 100Mb internet connection. This way more than 100 users can be served simultaneously with an mp3 audio stream. More info about the audio software: www.icecast.org
Video sources are some cameras, remote connected (via WiFi) directly connected via the USB interface. Some of the cameras used are able to FTP standalone the pictures regularly to the datastore of the webserver, others will be connected via the Webcam XP application. This application will perform the needed FTP upload.
Webserver is hosting the actual webserver application (Apache) and the server side scripting (PHP) needed to build the actual webpage and chatbox. Via PHP also the connection to the MySQL database is made
WICE is implemented on a number of servers located on different locations.
Web- Icecastserver: Web- and Icecast server is one box (LinuxOS, Fedora Core 2 Dell PowerEdge 2.4GHz) running Icecast, Apache, PHP and database. Connected to the internet by a 100Mbps connection and colocated approx. 100 km from the contest location.
Application server: Main application server (Laptop running Win-XP, 1GHz CPU, with plenty of RAM) at the contest location. Hosted are the data-aggregator, Webcam XP and Icecast client. Connected to this server is also the LabJack hardware interfaced via a USB interface.
Logging server: Server hosting the logger application. This is a standard laptop (Dell Optiplex L400) connected to the radio (FT1000/IC910) and Winkey (morse code generator) via standard or via virtual USB serial ports.
Application and logging server are connected via the local Ethernet network and ADSL to the main internet.
We have been running this interactive website now for some contests: cqww160cw and 2 mtrs Marconi, with splendid reactions. On one of the 160mtrs efforts we where even assisted by a remote OP (listening to the audio and communicating via the embedded hatbox) located 6.000 miles away !. Also we had numerous listeners who just listen in and provided us the needed encouragements....
At the moment a small delay is present (mainly due to Internet latency) in the audio path, interesting would be to see if that can be reduced. Also a natural shift to realtime video is foreseen instead of the still video frame captures. In addition investigations could be started to see how our listeners could provide us not only textual, but also audio or video feedback, maybe by some sort of Skype integration.