|
|
This item text has been erased.
27 responses total.
This response has been erased.
Try switching to voice & see if you hear a slight echo. In any case, it is most likely a quality problem on the Spanish end. Try lowering the baud rate, and/or switch to semi-duplex instead of full dux.
This item is #224 in agora and #20 in micros.
Likely mainly poor line quality. All of the international calling I've done has been shaky, and usually there's a lot of crossover or "bleeding" of other people's signals, since the physical cables are flaky by now. I suppose some of it goes by satellite...and I suspect if you paid extra to one company or another, you could get better lines. (should be "lines") I mean, even if there's no data going through, there's still the nice screech, right? 1200 would likely be better, or maybe even 300, if it's more important you connect at all than transfer stuff quickly...
The problem you're seeing is from the linear amplification of overseas telephone lines. What you will need to do is establish a reliable connection with a *non* crc protocol, Change handshake from X/on-X/off to RTS/CTS. And now the bad news, Adjust the sinal strenght to a broader limit. I had this problem polling an account in England. And this was the only solution I could come up with. I used a Multi-Tech 696 on each end. Good luck.
This response has been erased.
Ugh. I've dealt with crud like this--it always seems to differ from place to place. I will bet that the problem is one of signal conditioning in Spain. Depending on what they do over there, the different international carriers might, just might get into the local systems there in different ways. I believe you can make an international call using the carrier of your choice using 10 288 011 34 <numbers>. Try using the different folks like MCI, RCA Globcomm, Sprint, etc. That may well help. I don't think its anything like signals getting lost.
As a last resort, you should try a pair of Telebit Trailblazer modems on both ends of the connection. Run them in PEP mode. PEP is Telebit's proprietary high-speed protocol; it divides the phone channel into 511 frequency groups, evaluates each group for signal characteristics, and then selects which frequencies to use based on this evaluation. Its abilities for getting data through, and holding a connection on truly horrible lines, are legendary. You might also see if you can enable "echo-suppressor compensation" on the modems. Echo-suppressors are commonly used on international connections, and can really screw up modems. Finally, you can try other carriers. STeve's suggestion is almost right; however, not quite. The general way of using a carrier other than your default carrier is to dial "10xxx" before the phone number, where "xxx" is the carrier access code. (Look in /u/mju/10xxx.codes for a list of carriers and their corresponding code(s).) For example, the AT&T code is "288" (which is "ATT", by an interesting coincidence...), so to dial "201-555-1212" using AT&T instead of your default carrier, you would dial "10288 1 201 555 1212". No pauses, or waits for secondary dialtone, are necessary. You may want to start out with AT&T, and then try Sprint and MCI, before trying other (smaller) companies. You can find out what carrier would be used to make a call by dialing "700-555-1414" instead of the phone number you would otherwise call; this will connect you to a recording that tells you what carrier is in use. For example, dialing "10333 1 700 555 1414" gets a recording that says "Welcome to U.S. Sprint's long-distance service.", indicating that dialing "10333 x xxx xxx xxxx" will use U.S. Sprint. [BTW, if the guy in Spain says his Zoom 2400bps V.42bis/MNP modem won't do 1200bps, he's lying. He may have to reconfigure it, unlock the interface speed, or something like that, but it *can* talk at 1200bps.]
I hate to nitpick, but that number's 1 700 555 _4141_. Although the 1414 may work with some carriers. Also, if this is being attempted from your work phone, it's possible your PBX or your company phone system may not allow 10xxx dialing. I know that's *definitely* the case where I work.
Signal strength is similar(loosely) to volume, Modems normally run with preset limits on send, around -10dBm with a variance of +/- 1dBm, and receive tolerance of +/- 7Hx, after running halfway around the world, this signal can get way out of spec. This is why you can get a connect and as soon as you try and send async, the modulation varies enough to go out of spec, the modem can't handle the variance and breaks off. By expanding these limits(generally with S register settings) you will have a much more tolerent carrier.
This response has been erased.
I'll be in on the "Coffee shop hop" tonight, If you're going we can talk then. I talk much better then I type. :)
Actually, if the guy in Spain can get ahold of a V.32 modem, it might be worthwhile to try that. V.32's modulation handles noise pretty well (I've had V32/NONE connections go thru to the Hayes BBS in Atlanta with no errors) and might do the trick. (I wouldn't bet on it, but..) I've noticed mention of a "guard tone" in modem manuals.. something to do with pesky European phone systems. Does that hold any bearing on this?
This response has been erased.
AT&G Do not generate guard tones (USA default)
AT&G1 Generate 550 Hz guard tone.
AT&G2 Generate 1800 Hz guard tone.
ATS10=x x=1/10 of a second to allow non-carrier status
ATS10=255 acts as if carrier is always present
ATpopcorn Valerie mode.
This response has been erased.
Unfortunately, changing signal strength is not usually something that can be done with S-registers. Telebit modems (and possibly others?) have a socketed resistor (yes, you read that right) that can be changed with a different-value resistor to change the output signal strength, but this isn't very easy and is a fairly techie-type thing to do. You can also wind up with a non-FCC compliant modem if you increase the signal strength too far.
The solution is not *increaseing* signal strenght, But to broaden the limits of spec tolerance. to say +/- 10Hz. This will allow for the constant flux of overseas signals. What happens is this, You call spain, You're original access goes through Atlanta or New York, While if satalite up-links are availible, they will forward your request through a series of remote stations. If that circut gets to crowded, it will switch to a less crowded net. All the while you think you on the same line. In actuality, you may have as many as 10 different circuts running your call. All this switching makes for some serious gain fluxuations. Oh, Guard tones are to secure a modem for private use. Pick a frequency and only modems set to transmit that frequency while carrier is being established, will connect. Not very secure, but what do you want for nothing? RRRRRUBBER BISCUT?
Did you make sure both modems have the same protocols? The 2400 bps. modem that you said didn't have any error correcting protocols, does however have protocols. My Supra modem manual has a separate section on international calls, saying you might have to change the protocol (from factory settings) in order to use it internationally.
At 2400bps, all modems use the CCITT V.22bis protocol. There are Bell and CCITT protocols for 300 and 1200bps (Bell 103A and 212A vs. CCITT V.21 and V.22 sound about right), but hopefully Valerie won't try to use those.
If what frf says is happening in #18 is (the constant signal switching), you are going to have real problems getting much of any modem to work. The data signal iself is phase encoded -- which means its very timing sensitive -- any sort of varying phase error is going to screw things up royally for the modem, yet may be barely noticeable to human ears. About the only thing I can think of that might survive that kind of phase distortion would be Bell 103. Definitely try different long distance carriers. One possibility is that some of them are trying to do speech compression -- if so, there isn't any way most modem will work, because most speech compression systems rely on the considerable amount of redundancy to reduce the amount of data in speech down to a very small amount of digital data (some systems can get it down to 300 bps) -- no modem protocol is going to survive that. You can certainly forget about phase encoding - something that's barely noticeable to the human ear is going to be one of the first "redundant" bits of information to be lost. It might also help to purchase one of the same kind of modem to try locally, & see if you can get it work here. That won't guarantee that the same settings will work there, but at least you'll have something a bit chearer to play with here, and you can eliminate things that definitely won't work there. You really have 2 things to worry about here -- the protocols needed to talk to the various telephone companies (signal levels, echo supressant tones, etc.), & the protocol you need between the two modems.
At times, I was able to get 2400 bd connections. It depends on what kind of connection you get. I would say 300 bd connections are what you can count on. Error correction protocols help at higher baudrates, but there is no warranty for function, they downgrade the connection to lower speeds, and then hangup if necessary. I hope your parity settings match.
This response has been erased.
I do that all the time, I didn't know both of you were on cis. If your files aren't huge, you can also tar them, scramble to some encrypting mechanism of your preference, uuencode, and e-mail them.
This response has been erased.
If they can get on some kind of datapac service, there is also some possibility of connecting thru there. I do it by uploading into my account, and they download it from the same account. That needs some trust. I wonder if you could pull this, connect to datapac and with datapac connect to merit (that is from Spain) Then call merit here and get into ip protocoll using ka9q or similar. Then have them connect to your host using your ip address and ftp the files. I think the key is if you can get an ip protocoll from merit when you come in via datapac. However, if they have a way of getting on internet in Spain, they should be able to ftp your computer with no sweat.
Response not possible - You must register and login before posting.
|
|
- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss