The announcement of this blog page has created some interest. As anticipated, the questions started coming in. Here are a few answers to some of the more pertinent questions.
Is this a Linux replacement for Altair?
Yes and no. The software I wrote is targeted at Linux running on an embedded ARM processor. The target ARM platform is running in big endian mode as opposed to little endian mode used by Linux on x86. There are other portability concerns to take into consideration, such as the way the compiler packs structures. I tried to write portable code, so making the software work under Linux on x86 should be trivial, but it is only tested on the NSLU2. I'm quite happy to leave the porting effort (if any at all) to others.
The software I wrote is not exactly a replacement for Altair. It does not have a GUI or all the capabilities of Altair. The long term plan is to add all the functionality that can be supported, such as turbo mode, file renaming, file deletion, etc.
I have no plans for a GUI, since the software needs to run on a headless embedded system. I expect that at some stage a web interface will be created to allow the user to initiate transfers between any drive on the network and the Toppy.
Should I buy the NSLU2 hardware now?
I like gadgets that serve a purpose. I like gadgets that can serve several purposes even better. The great thing about the Linksys NSLU2 is that it is a pretty handy device on it's own and it can be reprogrammed to do other things. If you can use a box that allows you to attach USB hard disks to your network, then by all means go ahead. Even if this project dies tonight, you will have a device that serves a purpose.
If you are a Linux hacker and want to get involved, then I would encourage you to get a NSLU2 now. You want to make sure that you have your toy in time for Christmas.
If your only purpose for the NSLU2 is to add an easy to use Ethernet interface to your Toppy, I would suggest that you wait until the project gains momentum. I expect that eventually it will be easy enough for a Windows user with minimal skills to get going, but we are nowhere near that goal just yet.
Where should I buy my NSLU2 from?
Since I don't have any incentive to recommend one vendor over another, I won't mention any one in particular. I am quite happy to recommend a particular retailer if we can structure a mutually beneficial relationship. If I do end up recommending someone in particular, I will justify the reason for the recommendation.
Where can I get a copy of this software?
You can't just yet. I need to take care of some house keeping before I unleash the project on the general public. House keeping includes such things as choosing a licence for the source (probably GPL), finding a home for the project (probably SourceForge) and of course writing developer documentation and guidelines. House keeping is tedious. I am not looking forward to it, but the plan is to get it done before Christmas.
Most importantly, I'll have to choose a name for the project. Up until now, the project has been code named puppy and unless a better name comes out of somewhere, it will stay. Suggestions are welcome, but please don't come up with sad aberrations of words like Linux, Tux, Slug or Altair.
When will it be finished?
Probably never. I expect the project to be adopted by the community and evolve indefinitely. There will always be more features that someone will want.
Can I be a beta tester?
Not yet. I am looking for others to join in the development effort. Part of the development cycle is setting up the environment, building the binaries from the source code and testing. At this stage, getting everything set up is non-trivial and a new comer will probably require a fair amount of help. Any effort I put into helping others with set up is effort taken away from making further progress on the project. That is why I am only interested in other developers at this stage. We need to get some initial momentum, so that there are enough people putting in the effort and energy to add features, improve the software and distribution model and eventually help end users with deployment.
If you want to get involved in development, start by getting yourself a NSLU2 and an external USB 2.0 hard disk. I currently use a 6GB laptop drive in a 2.5" drive enclosure powered by the NSLU2 and have a 36GB drive in a 3.5" externally powered enclosure just waiting to be used.
30 November 2004
29 November 2004
Adding an Ethernet interface to a Topfield TF5000PVRt
The Australian Topfield TF5000PVRt owner community has shown a great deal of interest in adding an Ethernet interface to their beloved PVR. While the USB 2.0 port on the Toppy is great, it requires a computer within about 5m of the device. Furthermore, because Topfield only provide a Windows application for communicating with the device, the PC must run either Windows 2000 or Windows XP - there are mixed reports of partial success with Windows 98. Given that the Toppy is most likely to be used in the loungeroom, with other home entertainment equipment, the physical proximity of a PC is not exactly practical or even desirable.
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:
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...
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...
Subscribe to:
Posts (Atom)