My solution to this problem is to use an embedded device that has an 10/100 Mbps Ethernet port to connect to the LAN and a host USB 2.0 port to connect to the Toppy. This takes care of the physical connections. There are several products available on the market that could do the job electrically, but just having the right plugs is not enough. The most important part in constructing a usable solution is the ability to add some smarts to this embedded device, so that it can talk the Toppy protocol and present the PVR on the network in a user friendly and platform independent way.
I've been on the look out for a suitable device for several months. When the Kuro Box was announced, I thought I may have finally found a suitable solution. Unfortunately, the device was fairly expensive and only available in Japan and North America. Importing the Kuro Box to Australia really wasn't an option, because the built in power supply would not work in a 240V country.
As luck would have it, while researching the Kuro Box, I stumbled on information about the Linksys NSLU2. This device looked exactly like the thing I was looking for. It is available locally in Australia for about AUD$170, has two USB 2.0 ports, one 10/100 Mbps Ethernet port and runs embedded Linux. What is even better, is the fact that there is a very active developer community doing some excellent work on turning the NSLU2 into a very flexible, general purpose, embedded Linux platform.
I got involved with the NSLU2 development community and started contributing to the development even before I purchased my NSLU2. The NSLU2 is affectionately known in the development circles as the slug. While waiting for the delivery of my NSLU2, I started learning about the development environment used for Unslung and OpenSlug. I contributed the libusb packages before I got my slug. Unfortunately, the libusb library is broken in a number of ways and the released packages only appear to work superficially. The excursion into libusb source has cost me a couple of weeks in wasted effort, first trying to identify the problems, then attempting to rectify them. In the end, I decided to throw libusb out of the equation and wrote my application to work with the Linux kernel usbdevfs API directly.
While attempting to bring generic USB capabilities to Unslung 2.x, I also realised that the kernel did not have support for usbdevfs enabled. On top of that, I found an incompatibility between the NSLU2 standard kernel and the X's Drive II. The changes required to fix these problems, as well as other factors discussed in the NSLU2 community, led to the birth of a new Unslung variant named Unslung-able. With the help of rwhitby, I made some changes to the Unslung OE build process to enable a mechanism for creating distribution variants. Shortly after that, the NSLU2 development community decided to concentrate on only two variants, Unslung-standard and Unslung-able.
Once I had my NSLU2 platform configured to enable the USB communication with the Toppy, I started the development of a Toppy specific application to transfer data over USB. This is the component that replaces the Windows specific Altair application. I already had the Topfield documentation and as luck would have it, there was a Home Entertainment Expo at Darling Harbour. Topfield Australia were a major exhibitor, showing their existing product range as well as the rumoured Topfield TF7000PVRt. I turned up during the initial trade and press session, before the show was open to general public. I had a brief conversation with a couple of Topfield employees and a very long and productive chat with the general manager of Topfield Australia. I outlined to him a couple of the projects I had in mind for the TF5000PVRt and he was very supportive. He went as far as to offer to arrange for me to meet with a member of the Korean team that was going to be in Sydney later that day. Unfortunately, prior engagements prevented me from grabbing this opportunity. The good news was that I had a promise of co-operation and a personal invitation to contact the GM of Topfield Australia if I needed help with my projects. This unusually friendly and co-operative response fueled my ambition to succeed.
Over the next couple of weeks I spent most of my free time writing and debugging code for communicating with the Toppy. At one stage I ran into a brick wall with the CRC16 algorithm used by the Topfield USB protocol. I sent an email to the general manager of Topfield Australia at around 1am, requesting help. By about 3pm on the same day, I had the answer and the source code to the relevant implementation, presumably obtained directly from the Topfield engineers in Korea.
As of today, I have a proof of concept application that can:
- show the size of the Toppy hard disk and the amount of available space.
- list the contents of directories on the Toppy.
- upload files of any size to the Toppy.
- download files of any size from the Toppy.
- abort an unsuccessful upload or download.
- reboot the Toppy (untested).
I tested both uploads and downloads while using the Toppy for normal viewing. It works. I noticed dropped video frames and even rare audio drop outs during the playback of a previously recorded program, while at the same time recording two channels and also downloading a file from the Toppy. This is not really surprising because the Toppy is utilising an aggregate I/O bandwidth in excess of 80Mbps to cater for the four concurrent streams. I suspect that the biggest issue is in fact the performance of the polled USB port on the Toppy. The USB 2.0 implementation on the TF5000PVRt seems to be the weakest point of the unit.
The next steps are to get enough information together to allow others to follow in my footsteps and build on top of what I have done. I eventually expect this project to get to a state where a user can purchase an NSLU2, download a firmware image, flash the NSLU2 with this firmware image using a web browser UI and end up with a new device intended as a home network gateway for the Toppy. Eventually, I expect that this Toppy gateway will provide the user with a web interface that allows advanced operations, such as data migration of recorded files to other computers on the network, EPG data uploads and even remote user interface, to allow for such things as starting a recording from your WAP phone. While I don't expect to be building all of this by myself, I believe that putting in the ground work to provide the basic connectivity will allow others to do this.
To be continued...
No comments:
Post a Comment