I like to put my two cents in this since I am in fact a DSP guy and very fascinated by a free software DSP project.
First, let me explain my background relevant to this topics. I have been involved in commerical development of various FSK-based modems (v.21, bell 103), QAM-based V.34, and even did a little bit DMT (ADSL) work. I did write a generic software based V.21 modem on a Pentium Pro machine running Windows NT many years ago. I was also involved in the channel coding/decoding part of a V.34 modem.
Anyways. I think this is what people may do to get around the hundles pointed out by the previous post.
1. Certification. telcos does not let you plug anything you want in their PSTN. To get the certification is an incredibly time consuming (and expensive) process. One way to get around is to get a DAA card. When I did my soft modem, I got a card that has a phone jack and A/D, D/A with a hybrid. I don't remember the brand anymore. But one of the coworkers wrote a driver for it and I was able to use some basic "ioctl" calls to make it on-hook, off-hook, get samples and send samples. I imagine the Linux softmodem envisioned will have to do something similar. Write linux drivers for these DAA boards. Use the host to send and receive signal samples.
2. Dark magic. Yes, once you work with one of these monsters, you will appreciate the among of secret and tricks behind these thing. All ITU modem standards specifies the transmitter of the modem but not the receiver because it is a LOT harder to receive than to send. The standard also intentional obfuscates the writing. For example, the 16-D (8 QAM symbols) shell mapper describes these A, B, C, D, E, F, G, H values are actually the n-dimensional ring costs and residues. For these part, I think if you can get some DSP graduate students or working DSP hackers, you can get at least acceptable performance.
3. Patents. It took so long for these standards to come out mainly because of patents. No one wants one company to own all the patents. So, it usually works out so that each (big) company has their share of patents and everyone roughly cancels everyone else. (Lawsuit equilibrium) But as far as I understand it, as long as you DON'T make a profit of it, they cannot charge you money. I.e., if you write a soft modem, and use it to surf web instead of selling it, I don't think they can sue you for money. If you sell a soft-modem using the free source code, the seller is responsible for compensating the patent holding companies - not the guy who writes.
4. There is a TSB27A testing standard (a TIA standard?) which covers something like (24x7 = 168 loop conditions?? fuzzy about this). If you get one of those line simulator, that should be enough.
5. Lack of interface standard. This goes back 1. Find a DAA card whose manufacturer is willing provide a linux driver or support people to write one.
IMHO, it is a bit much for ONE PERSON to write a V.90/V.34 modem with all the fallback. USR, Lucent, Rockwell have an army of DSP guy, embedded guy, tester to develop these thing full time and it still took them couple years.
V.32/V.32bis is rather simply since the data rate is not that high. All the FSK modems (V.21 and etc) are no problem. I think anyone who understands communications well can write one in C in couple weeks. V.34 is much much harder. IMHO, It is the first (and arguably only) modem that for practical purpose achieves channel capacity of the channel it serves!! If memory serves me right, its symbol timing error must be under 150ppm or it should retrain. The (optional) 64-state trellis code is truly nutty thing that I think only a few modems actually support it.
But if there is a brave soul who will give this a try, I wish him good luck.
Slashdot Mirror
Hi,
I like to put my two cents in this since I am in fact a DSP guy and very fascinated by a free software DSP project.
First, let me explain my background relevant to this topics. I have been involved in commerical development of various FSK-based modems (v.21, bell 103), QAM-based V.34, and even did a little bit DMT (ADSL) work. I did write a generic software based V.21 modem on a Pentium Pro machine running Windows NT many years ago. I was also involved in the channel coding/decoding part of a V.34 modem.
Anyways. I think this is what people may do to get around the hundles pointed out by the previous post.
1. Certification. telcos does not let you plug anything you want in their PSTN. To get the certification is an incredibly time consuming (and expensive) process. One way to get around is to get a DAA card. When I did my soft modem, I got a card that has a phone jack and A/D, D/A with a hybrid. I don't remember the brand anymore. But one of the coworkers wrote a driver for it and I was able to use some basic "ioctl" calls to make it on-hook, off-hook, get samples and send samples. I imagine the Linux softmodem envisioned will have to do something similar. Write linux drivers for these DAA boards. Use the host to send and receive signal samples.
2. Dark magic. Yes, once you work with one of these monsters, you will appreciate the among of secret and tricks behind these thing. All ITU modem standards specifies the transmitter of the modem but not the receiver because it is a LOT harder to receive than to send. The standard also intentional obfuscates the writing. For example, the 16-D (8 QAM symbols) shell mapper describes these A, B, C, D, E, F, G, H values are actually the n-dimensional ring costs and residues. For these part, I think if you can get some DSP graduate students or working DSP hackers, you can get at least acceptable performance.
3. Patents. It took so long for these standards to come out mainly because of patents. No one wants one company to own all the patents. So, it usually works out so that each (big) company has their share of patents and everyone roughly cancels everyone else. (Lawsuit equilibrium) But as far as I understand it, as long as you DON'T make a profit of it, they cannot charge you money. I.e., if you write a soft modem, and use it to surf web instead of selling it, I don't think they can sue you for money. If you sell a soft-modem using the free source code, the seller is responsible for compensating the patent holding companies - not the guy who writes.
4. There is a TSB27A testing standard (a TIA standard?) which covers something like (24x7 = 168 loop conditions?? fuzzy about this). If you get one of those line simulator, that should be enough.
5. Lack of interface standard. This goes back 1. Find a DAA card whose manufacturer is willing provide a linux driver or support people to write one.
IMHO, it is a bit much for ONE PERSON to write a V.90/V.34 modem with all the fallback. USR, Lucent, Rockwell have an army of DSP guy, embedded guy, tester to develop these thing full time and it still took them couple years.
V.32/V.32bis is rather simply since the data rate is not that high. All the FSK modems (V.21 and etc) are no problem. I think anyone who understands communications well can write one in C in couple weeks. V.34 is much much harder. IMHO, It is the first (and arguably only) modem that for practical purpose achieves channel capacity of the channel it serves!! If memory serves me right, its symbol timing error must be under 150ppm or it should retrain. The (optional) 64-state trellis code is truly nutty thing that I think only a few modems actually support it.
But if there is a brave soul who will give this a try, I wish him good luck.
Henry