Slashdot Mirror


Upping The Softmodem Code Bounty -- To $20,000

Alex Pilosov writes: "I've announced a bounty for completion of softmodem code (20k$) on linmodems-discuss list. If this is successfully completed, we'll have a completely universal driver for any kind of winmodem without any proprietary code which result in all sorts of kernel version problems." Here's the full text of the announcement and conditions.

9 of 234 comments (clear)

  1. Reasons why this would be interesting! by denisb · · Score: 5, Insightful

    Can't people figure out the following reasons for such a project being interesting ?

    - Low cost internet station for places out of reach of xDSL / cable modem connections.
    - Viable internet connection for legacy hardware / second hand hardware
    - Excellent solution for development countries where xDSL is faar away yet.

    The keywords here are LOW and COST.. Did you ever consider that Linux and second hand hardware might be the ultimate combination for places where they don't have as much cash as yourselves ?

    d9s

    --
    life+universe+everything=42
  2. Re:high price for a modem by Kraft · · Score: 5, Insightful

    think laptops...

    I have a thinkpad t21, and from what I have read, one of the common linux problems with this laptop is bad modem support. As I use this machine on the road from time to time, I want that modem to work (hotels, friends house etc.) and if it doesn't it will be a deterrent to install linux.

    I do think you are right in suposing that many linux fans are early adopters, but what I find interesting is the possibility of more "regular" users switching to linux, because of proper hardware support and thus: ease of use.

    --

    -Kraft
    Live and let live
  3. Re:Motivation? by Kraft · · Score: 5, Informative

    I was curious about his @pilosoft.com address, but the site is blank. However, a google search on his name revealed a personal homepage.

    One thing worth noting: he's 22 years old.. hmmm. According to his resume, he has contributed to apache, mod_perl, postgresql and freebsd.

    My personal guess is that he has convinced one of his employers to pay for this (Lazard Ferez & Co., which he works for, seem potential, but i don't know enough about them). I'll be following the bounty thread.

    Anyway, I think he is for rea and wish him good luck. Here's a picture of our hero

    --

    -Kraft
    Live and let live
  4. Bounty won't matter much. by zensonic · · Score: 5, Interesting

    Regardless of the coolness factor of this bounty, the fact still remain: A GPLed softmodem driver still requires certification by the telephone companies before any device is legally connected to the telephone network using the driver.

    My guesstimate are that it's much more difficult to obtain certifactions for the driver around the globe than it is to write the driver. The telephone companies are rather picky about what the allow onto their networks

    --
    Thomas S. Iversen
    1. Re:Bounty won't matter much. by pjrc · · Score: 5, Insightful
      A couple years ago I designed a product with an embedded modem (H8800-1 at this page). I used a rockwell chip and associated components, which is a hardware modem.

      Device is the keyword here, and the device (winmodem) has already been certified. The software driving the device doesn't need certification.

      This may not true. When we tested the H8800-1 for FCC part 68 compliance, the test was for the whole system. We had to provide ways for them to access the modem to test both originate and answer modes (though the H8800-1 only answers and never originates). We had to do this, despite the fact that the signals were all generated by the Rockwell chip.

      However, the majority of the trouble with FCC part 68 is the surge tests. The basic idea behind these tests is to apply a massive surge on the line which is certain to destroy the modem. The modem is required to fail in a manner where it does not conduct, so it looks like it's on-hook (not in use) to the phone network. This is purely a function of the hardware. The lab we sent the prototypes to did many other tests, but they were all pretty easy to pass (using the rockwell chip).

      Reading through these regularity requirement documents is a mind-numbing experience (if you can stay awake). If you're feeling maschoistic, here is the page for requesting the Part 68 technical requirements. If anyone takes the time to actually read and make some sense out of this stuff, please post your informed opinions. Part 68 applies only to the US, so repeat for whatever other countries you're interested in...

  5. Re:restrictions? by krokodil · · Score: 5, Insightful

    You MUST have background in signal processing

    Dear Mr. Torvalds,

    We could not permit your so-called "operating system" to use GNU license because you do not have proven experience in the operating system design and your background is not sufficient. In order to satisfy our customers,
    and maintain high project code quiality, we accept contributions only from candidates who have experience in the particular area and passed interview with some of our managers.

    (signed)
    Free Software Foundaiton

  6. How do we know that this is genuine? by HuskyDog · · Score: 5, Insightful
    I don't want to be rude, but how do we know that this guy will produce the money? Can anyone we trust vouch for him?

    Perhaps if he placed a deposit with some trusted third party (Mad Dog, Eric Raymond etc) people might be happier to devote the time.

  7. Re:Bountys - a great Way to fund development of OS by GigsVT · · Score: 5, Interesting

    No one has heard of

    linuxfund.org

    ?

    --
    I've had enough abrasive sigs. Kittens are cute and fuzzy.
  8. Some facts about software modems by Jamie+Lokier · · Score: 5, Informative

    Interesting; I did not see this second message from Alex. Have I been unsubscribed from the list over the weekend, I wonder?

    I'm going to answer a few questions that have been raised, and a few that haven't.

    Is anybody working on the code?

    Fabrice started first. Unfortunately, he has been quiet for a very long time, and I have no idea if Fabrice has done further work on the modem code. I hope he is still well and healthy.

    Meanwhile, I have been secretly still working on my code base (that's the one at tantalophile) all this time. It has been an on and off affair, and I've found it difficult to find the time, energy or focus what with the day job and other projects. I keep foolishly trying to improve on the standard algorithms ;-) Nevertheless, bugs have been fixed, features added, tests done, signals are processed better than ever and I have a nice set of graphs showing simulated error performance of the V.34 core under various conditions.

    In other words, there's a long way to go and please, nobody hold their breath, but there has been substantial progress and it is not on the tantalophile web site. So don't slashdot it, thanks :-) I'm making no promises about when my new material will appear, but I do promise it will be announced on the linmodems mailing list.

    About the bounty

    It's a bit of a nice surprise to see that offered. I'll be contacting Alex, but to be honest I am motivated to complete the project anyway. I don't want funding to dictate the goals of the project (which should be educational and of high quality, IMHO, as well as functional), although some influence would be understandable. It is likely to make a difference to the schedule though.

    Legal clarification and/or commercially backed negotiation on the patent issue would be invaluable, and help with testing is also very valuable.

    I didn't respond to the original $5000 request because it is not a lot of money. Considering the large amount of time, effort and to some extent resources already spent on the project, as an estimate for the remaining work, I would certainly not accept a commercial contract at that sort of rate. $20000 is rather more interesting, but I think Alex's request for V.90 is unrealistic if he wants it on a short timescale.

    One thing that would be a bit upsetting is if all my work were quickly overshadowed by someone else, suddenly motivated by cash, throwing something together. But I cannot complain as I haven't exactly been speeding ahead or keeping with the community on this. I know how the Hurd feels ;-)

    Standards compliance, approval, and "homologation"

    This is quite hard, because anyone can modify the code and thereby break any certification of the code.

    Different countries have different standards. There are differences in the energy that can be emitted, both the peak instantaneous energy and a longer term average are limited. And you don't always want to max out the energy anyway, as you're avoiding distortion.

    The relationship between voltage and current is not the same everywhere. Dialing tones, engaged tones and so on vary. V.90 coding varies because the USA operates at a lower digital bit rate than most of Europe.

    Some people have said that it is the hardware which is subject to regulation. This is not true. I believe there is a certain certification level for the hardware itself, for avoiding excessive energy input, making sure the hardware doesn't go up in flames when receiving the 100V ring pulses or a lightning bolt, that the impedance is matched, and so on.

    However, it is (theoretically) necessary to certify the software as well for many reasons. A good example: by modifying the software, you can transmit more energy on a USA telephone line, using a USA modem, than is permitted by federal regulations. That excessive energy is considered to potentially interfere with other people's telephone calls. So, you do have to get the software right.

    Fortunately we have a good example of certification in the Linux kernel. Some versions of the Linux ISDN code are certified for use on the German telephone networks, I believe. The source code is checksummed. I note with interest that it's the source that's certified, and not the binary (so the beurocracy is ignoring bugs in the compiler or the rest of the kernel).

    For myself, I am very keen to write code which certainly does conform to all the known requirements. I don't feel comfortable hacking together some "it seems to work" code of this kind and releasing it like that. It's partly a reputation thing, and partly a responsibility thing.

    On patents

    Yes, there are many patents. Unfortunately the detailed patent situation is unknown. It is possible that the patents don't apply to software implementations in most countries, but we don't know to what extent and where each patent applies.

    We don't even know which patents apply! However, there is an online list at the ITU which may be helpful.

    This is hopefully an area in which Alex Pilosov and his (possibly) commercial backing can help in a big way.

    I am of the opinion that users have, in general, already paid for their modems and so they should already have permission to use the techniques. It seems to be the case that software modem drivers for Windows are downloaded and installed with no attention paid to these matters, so it should not be any more of an issue for Free Software. It would be good to know for sure.

    The developing world

    Telephone line driver chips are cheap! For the developing world, getting an internet connection over crappy copper would be a wonderful achievement, and with full access to a software modem, you could cobble the modems together from parts.

    For this reason I think it is important that the softmodem works well over poor lines as well as good ones. And yes, I would love to code "workarounds" for when the standard algorithms don't perform well on Nepalese copper lines, or wherever. It would have to be a special variant of the code, for the regulatory reasons stated earlier, but it's a lovely thought.

    Is it still worth writing a software modem in order to use "winmodems" on Linux?

    The motivation has certainly waned, now that many previously windows-only modems are now supported on Linux by binary-only drivers from the manufacturers. Of course, you cannot use them if you're using the wrong kernel, or SMP, or if you have more than one modem, if you don't permit binary-only drivers, if you are using an Alpha or a PPC-based iMac, or if you want to run any-BSD. But hey, a lot of users are happy enough now, so that does remove some of the motivation for writing the code.

    Which leaves the educational aspect. The interior of a modern modem is not well documented, even in books about signal processing. To be sure, many of the classic algorithms are very well written up, but the details as they apply to modern modem standards are not, and there are some algorithms which V.34 and V.90 clearly require which I have yet to find any information about. (Welcome to re-inventing the wheel, but it is fun!) As Alan Cox once said, the V.90 standard is "semi secret". Read it sometime, if you don't mind paying the relatively modest fee, and you'll see what he means.

    Revealing just how a modern modem works, in the form of working code that (I hope) is readable by those who wish to study it, then, is as much a goal for me as getting winmodems working. And it's interesting because I'm still figuring it out myself :-)

    Interfacing with the hardware

    Several people pointed out, quite correctly, that a software modem won't actually work with any of the hardware "winmodem" devices. This is correct; we need device drivers too, and that is accomplished by reverse engineering the original drivers.

    I don't know Alex's exact requirements. He doesn't mention needing PCM drivers -- perhaps he has his own drivers already? But if he requires reverse-engineered PCM drivers as well then that's quite a bit more work.

    Progress on that front is being made, by several people, but it is really a separate project. It is worth noting that there's a GPL'd Lucent modem driver that can do PCM. It is actually quite old now. I have faith that the PCM driver part of this problem will be solved by eager contributors if there is a good softmodem to make use of it.

    Cheers,
    -- Jamie