SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : USRX

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Robert Graham who wrote (16392)3/24/1997 9:06:00 AM
From: Pullin-GS   of 18024
 
Bob says ????:

Its probably a good idea not to sell modems that do not support a standard.

USRX supports every async modem standard. I could spew them all, but for some reason I believe I would be wasting my breath on this particular post. Where do they not support a standard asyncronous dial-up protocol? It just happens that they have a platform that is software upgradable (I'll let you figure out the implications of that<W>). USRX also supports a 53K proprietary standard that is quickly becoming an industry standard, as many providers already support it (AOL for example...I believe they are BIG, no?). If your provider does'nt support it, your modem uses an existing 33k- standard (It's an automatic type of thing).

[If] a standard was developed, how are they going to handle their customers with their recently purchased modems that just have been outdated by the new standard modems that come out?

You ever hear of software upgradability? You really should do your research before stumbling all over yourself in this forum. You could get hurt. ;-)

dial-in end users always to go with standards and equipment that implements them faithfully

Agreed. So tell me what the 56k standard is? I believe USRX already supports all standards. So what is your point?

And I am sure this would save problems for Micron and their customers.

What problems? No standard 33.3 support? No 28.8 standard support?
Their is no standard 56k support, so why make that an issue? X2 is gravy. I'll take it any day if I can "while I wait" for a standard to be hashed out.

The benefit from 2x modems have not been proven in what can be considered a "typical" phone connection at this point in time.

Care to elaborate on what datas you are using to come up with your thesis? Do you know something that we don't?

This modem would require an unusually clean connection that is digitized at least at one end.

Again, can you put some numbers in your stats? When you question an idea (or in this case a fact), you had better bring numbers to the table. What the hell does "unusually clean" mean? That the operator has clean drawers?
And what's your point? All people I have talked with using X2 sustain reliable connectivity at 40Kbps+ to those providers supporting X2 in a metro area. That's 100% benifit from the old, poorly thought-out 33k standard.

This is not the case for a significant amount of modem users.

What do you mean by significant? Well perhaps the in-significant (the majority) can benifit. I could say the majority can't take advantage of the older V.34 standards also, no? Yes, this is the case also. Any metro area will most likely support X2 well. Many rural areas will not, nor will they support 33.3, 28.8, or even 14.4 in some (few) cases.

For that matter, line quality varies with repspect to time of day and outside temperature.

That's nice.:-) For that matter the tides are affected by the moon, and the stock market is know to follow trends.

My point is: What does that have to do with X2?
Those same line quality issues will affect V.32, V.32BIS, V.34, and any future standard we have utilizing medias (twisted copper) that are influenced by the environment. Your stretching.

I think there will be quite a few disappointed people out there

Another opinion. Well, you know the saying. Butt (punn intended) you opinion has to smell worse than everyone elses.

PRB
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext