Update: More tests proving better success. At the moment I think it's HyperTerm that's screwing me over. I'm going to try Terminator, and see how far I get with that.
I'm getting full screen transmissions, characters are going back and forth, and it's seems normal for a while, but then it just spits a load of garbage characters and sort of hangs. refusing to send or receive more characters. This does sound awfully like some sort of signal degradation, but I was doing it at 9600 baud, so that could be a factor.
Update: More tests proving better success. At the moment I think it's HyperTerm that's screwing me over. I'm going to try Terminator, and see how far I get with that.
I'm getting full screen transmissions, characters are going back and forth, and it's seems normal for a while, but then it just spits a load of garbage characters and sort of hangs. refusing to send or receive more characters. This does sound awfully like some sort of signal degradation, but I was doing it at 9600 baud, so that could be a factor.
If you use G.711 and turn off echo cancellation in the VoIP devices you can often get the modems to sync up. The problem is they won't stay sync'ed up for long unless the clock speeds at the two ends of the VoIP link (e.g. inside the VoIP terminals) match precisely, and you won't achieve that with consumer grade VoIP equipment.
The key is getting them to use slower speeds.
The key is getting them to use slower speeds.
I've been trying 9600 baud and below.
The key is getting them to use slower speeds.
I've been trying 9600 baud and below.
I’d start at 1200bps and work your way up. (It’s a pretty robust, simple encoding scheme designed during an era when the POTS network was entirely analog and the last mile connection was really poor.)
14.4k is getting near the limit of a 1980s era POTS network. (In fact, the only reason 56k even works is because it’s only analog between your house and central office; it exploits the fact that, at that time (late-90’s), most COs were connected to each other with T1s or better, so it’s essentially digital from the CO to the ISP.)
The key is getting them to use slower speeds.
I've been trying 9600 baud and below.
I’d start at 1200bps and work your way up. (It’s a pretty robust, simple encoding scheme designed during an era when the POTS network was entirely analog and the last mile connection was really poor.)
14.4k is getting near the limit of a 1980s era POTS network. (In fact, the only reason 56k even works is because it’s only analog between your house and central office; it exploits the fact that, at that time (late-90’s), most COs were connected to each other with T1s or better, so it’s essentially digital from the CO to the ISP.)
Start at 300bps if you want it to work. Anything faster requires training, and the training will be screwed up every time the VoIP buffers need to slip.
The key is getting them to use slower speeds.
I've been trying 9600 baud and below.
I’d start at 1200bps and work your way up. (It’s a pretty robust, simple encoding scheme designed during an era when the POTS network was entirely analog and the last mile connection was really poor.)
14.4k is getting near the limit of a 1980s era POTS network. (In fact, the only reason 56k even works is because it’s only analog between your house and central office; it exploits the fact that, at that time (late-90’s), most COs were connected to each other with T1s or better, so it’s essentially digital from the CO to the ISP.)
Start at 300bps if you want it to work. Anything faster requires training, and the training will be screwed up every time the VoIP buffers need to slip.
I do not believe training started until v.32/9600 came around (well, it could have been used for v.27/4800 too), as that’s when echo cancelation started being used.
More success! The issue I am facing now is transmitting, but I have a theory as to why that's buggered.
My Pentium Pro is a bit stuffed on cards, and other devices are definitely interfering with the modem, namely the mouse. It's a serial mouse, and when it's connecting I can hear it crackling to the mouse movements in the speaker.
1200 baud worked a lot better, which is strange considering I attempted that earlier to no good success, but I think it was my Obi's settings. Receiving is DEFINITELY reliable, which shows that there is definite merit to this idea. It may not be the best idea, but it's certainly not bad. I was able to get weather, and some other stuff over the BBS before the link crashed after my system sent a load of garbage characters down the line (:/)
I think now it's a matter of getting a more reliable box to do this. I love my Pentium Pro, but it's a bit of a pig in some places. I would LOVE to use my 486, as it's a machine that would have been more likely to see a proper BBS, but I need to do a lot of work to get it in a position where it can use the modem correctly. I namely need to backup my PC-DOS installation and install Windows 95, which will just take some time.
300 baud didn't work for the BTTF BBS. It only received garbage data, and I think it's just an incompatibility with the BBS. 1200 baud worked perfectly fine, however, with, as I said, the only issue being occasional bouts of garbage data being sent because of interference from other devices. All the IRQs are fine, the modem is on IRQ4, that isn't used by anything else, it's just my own setup, I'll figure it out.
Thanks for all the help, I will try to do a video to document my success, and I hope with another machine I can get this into a working state.
The key is getting them to use slower speeds.
I've been trying 9600 baud and below.
I’d start at 1200bps and work your way up. (It’s a pretty robust, simple encoding scheme designed during an era when the POTS network was entirely analog and the last mile connection was really poor.)
14.4k is getting near the limit of a 1980s era POTS network. (In fact, the only reason 56k even works is because it’s only analog between your house and central office; it exploits the fact that, at that time (late-90’s), most COs were connected to each other with T1s or better, so it’s essentially digital from the CO to the ISP.)
Start at 300bps if you want it to work. Anything faster requires training, and the training will be screwed up every time the VoIP buffers need to slip.
I do not believe training started until v.32/9600 came around (well, it could have been used for v.27/4800 too), as that’s when echo cancelation started being used.
You can usually fudge V.22/600 and V.22/1200 with a fixed equaliser, although equaliser training is needed for top class results. V.22bis is pretty hopeless without equalizer training. The start up sequence for these modems includes both patterns for timing synchronisation, and patterns for equalizer training. All modems faster than V.22bis, like V.27ter/4800, require equalizer training.
What V.32 first introduced to a PSTN modem was not training. It was echo cancellation. Of course, the echo canceller also needs training, so V.32 has multiple training steps in its startup sequence.
The key is getting them to use slower speeds.
I've been trying 9600 baud and below.
I’d start at 1200bps and work your way up. (It’s a pretty robust, simple encoding scheme designed during an era when the POTS network was entirely analog and the last mile connection was really poor.)
14.4k is getting near the limit of a 1980s era POTS network. (In fact, the only reason 56k even works is because it’s only analog between your house and central office; it exploits the fact that, at that time (late-90’s), most COs were connected to each other with T1s or better, so it’s essentially digital from the CO to the ISP.)
Start at 300bps if you want it to work. Anything faster requires training, and the training will be screwed up every time the VoIP buffers need to slip.
I do not believe training started until v.32/9600 came around (well, it could have been used for v.27/4800 too), as that’s when echo cancelation started being used.
You can usually fudge V.22/600 and V.22/1200 with a fixed equaliser, although equaliser training is needed for top class results. V.22bis is pretty hopeless without equalizer training. The start up sequence for these modems includes both patterns for timing synchronisation, and patterns for equalizer training. All modems faster than V.22bis, like V.27ter/4800, require equalizer training.
What V.32 first introduced to a PSTN modem was not training. It was echo cancellation. Of course, the echo canceller also needs training, so V.32 has multiple training steps in its startup sequence.
You’re right! (And yes, I meant the echo cancelation training.) One of the nice things about V.90 (or was it V.92?) was that it could remember line characteristics and thus cut the overall training time practically in half after the first successful connection.
One of the nice things about V.90 (or was it V.92?) was that it could remember line characteristics and thus cut the overall training time practically in half after the first successful connection.
With modems other than V.90 and V.92 the link is usually analogue at both ends, and subject to considerable variability. Even if you always call the same number, you probably wouldn't be hitting the same port each time. Nothing remembered from a previous call will help with a new call. With V.90 and V.92 you are always calling a digital port. The ports in a large bank will behave identically, and your own local analogue link probably doesn't change too much unless the temperature is very different between calls. So, there is a high chance that the training from one call to a certain number will be close to the training for the next call to that number. V.90 and V.92 start out with that assumption, and only go into full training if the assumption proves false.
@TwoOfFive-TertiaryAdjunctToUnimatrixZero:
I came across this today while searching for something modem related. He was able to establish V.90 (56k) connections over VOIP to a local ISP. He also got V.92 connections going, from Australia to the US (!!!) no less.
He uses a Linksys Analog Telephone Adapter and routes the calls through a local Asterisks Server onto a VOIP provider. Apparently using the Linksys ATA is the key, as he can completely turn off VOIP echo cancellation (modems rely on the echo being there), set jitter and delay to fixed values and force using a specific codec.
V.92 (the older V.90 and the very old 56k flex) relies on a digital telephone network, i.e. ISDN. The RAS is connected via BRIs or PRIs to the telephone network and the codec is G.722. There's also a G.722 for VoIP, usually called 'HD voice' by marketing. You have to be very lucky to get a real V.92 connect via VoIP. In most cases the maximum connect is about 24k. Back in the days of dial-in I was involved in designing and building large carrier-grade dial-in platforms, and I'm still running a Fidonet node with a POTS modem via VoIP. BTW, you can make ISDN data calls via VoIP by using RFC4040's clear channel, but only a very few telcos support that.
@TwoOfFive-TertiaryAdjunctToUnimatrixZero:
I came across this today while searching for something modem related. He was able to establish V.90 (56k) connections over VOIP to a local ISP. He also got V.92 connections going, from Australia to the US (!!!) no less.
He uses a Linksys Analog Telephone Adapter and routes the calls through a local Asterisks Server onto a VOIP provider. Apparently using the Linksys ATA is the key, as he can completely turn off VOIP echo cancellation (modems rely on the echo being there), set jitter and delay to fixed values and force using a specific codec.
V.92 (the older V.90 and the very old 56k flex) relies on a digital telephone network, i.e. ISDN. The RAS is connected via BRIs or PRIs to the telephone network and the codec is G.722. There's also a G.722 for VoIP, usually called 'HD voice' by marketing. You have to be very lucky to get a real V.92 connect via VoIP. In most cases the maximum connect is about 24k. Back in the days of dial-in I was involved in designing and building large carrier-grade dial-in platforms, and I'm still running a Fidonet node with a POTS modem via VoIP. BTW, you can make ISDN data calls via VoIP by using RFC4040's clear channel, but only a very few telcos support that.
In simpler terms, it’s basically an analog connection from the user’s modem to the central office, then it goes digital to the ISP’s modem (over one of the 64k channels of a T1, T3, OC3 or whatever). Right? Basically, it’s ISDN only with the first hop being analog.
Speaking of ISDN, V.92 made bonding two dialup connections at the ISP (for a 115k dialup link) a lot more practical thanks to Modem on Hold; it’s a shame more ISPs didn’t support either feature. Being able to take an incoming call and instantly be able to reconnect was handy and made dialup a lot more like ISDN!
Ah, the good old days of dialup. I don’t even miss it a little. Though, I do kind of miss my old ISDN setup. Cable and DSL wasn’t available in my area yet, so I did ISDN in 2000. The line itself didn’t cost much more than a normal phone line, however all outgoing calls incurred a $0.01/Minute charge, however incoming calls were free. Luckily I knew the owner of a local ISP so we were able to setup the equipment for ISDN dialback. Basically, my router dialed into the ISP, performed a normal PPP login and hung up; the ISP would immediately dial my ISDN modem back, which would answer and go through the login process again. (The outgoing call charge only started after 10 seconds, so I was never charged for the initial calls into the ISP.)
It was a clever system and worked great for 3 years, until I finally got access to cable. That ISDN had fantastic latency (I would get 15ms pings to east coast Quake III servers) and basically never went down.
In simpler terms, it’s basically an analog connection from the user’s modem to the central office, then it goes digital to the ISP’s modem (over one of the 64k channels of a T1, T3, OC3 or whatever). Right? Basically, it’s ISDN only with the first hop being analog.
That's simplifying it a little too much, because it makes it appear that beyond the line card in your local exchange, everything was predictable. That's not the case. If your line card connected to a T1 using robbed bit signalling it didn't provide a clear 64k bps channel. Until the very end, the US in particular was still installing a LOT of robbed bit signalling (RBS) on T1s, and relatively little ISDN. Countries using E1s generally had 64k bps channels everywhere. However, even on pure ISDN paths, which were 64k bps end to end, there were often weird things going on with gain adjustment, and other obscure manipulations. ISDN has modes where any manipulation like this could be disabled, but a call from an analogue line into an ISDN line card couldn't get a call into this kind of clear channel mode. So, there was actually quite a bit of funky stuff degrading even the digital sections of the path between you are your ISP's V.90/V.92 digital modem.
The early experimental X2 and K56 modems were relatively simple, but by the time they had made them robust in the face of the funky behaviour of the networks they became quite complex. V.90 was largely the result of making X2 and K56 robust and merging them into a single standard.
Yep, but in the US it's a 56k channel typically (US' PDH is based on 7 bits while EU's / Japan's is 8 bits). And the PRI for the US is a T1. T3 or OC3 are used to transport multiple T1s. The bundling you've mentioned has nothing to do with V.92, it's MPPP (Multilink PPP). MPPP allows you to join multiple PPP sessions across different lines. IIRC, the MAX TNT (the box in the telco's data center) supported up to 8 MPPP channels per user across multiple chassis. You could have done the call-back just by signaling your telephone number (a normal call, but the called number rejects the call, free of charge) and used HDLC instead of PPP for a little bit more throughput.
Yep, but in the US it's a 56k channel typically (US' PDH is based on 7 bits while EU's / Japan's is 8 bits).
With a robbed bit T1 you get 8 bits for 7 samples, then lose the LSB on the 8th sample. So, you actually get 63kbps, and for voice it sounds considerably better than a simple 7 bit 56k channel would.
Japan (along with Taiwan, HK , and a few others) used plenty of robbed bit T1s in its PDH network, but tried to reduce them a lot after the introduction of ISDN. Most of the world used E1s, and always had 64kbps channels.
RBS is a tradeoff, it introduces some new issues. If T1 links aren't synchronized well, more LSBs could be lost. So the S/N decreases and ends up not being much better than for plain 56k. And in some cases, like a 'quiet' line, you can hear a tone created by the RBS.
RBS is a tradeoff, it introduces some new issues. If T1 links aren't synchronized well, more LSBs could be lost. So the S/N decreases and ends up not being much better than for plain 56k. And in some cases, like a 'quiet' line, you can hear a tone created by the RBS.
RBS was always a bit of a botch. Most aspects of the original T1 were well thought out. The two key failings were the lack of a rock solid sync scheme, and the lack of transparent channels, equally suitable for both data and voice. A couple of years later, when E1 was being defined, they had realised the failings of RBS, and avoided them. It took until ISDN before both the T1 and E1 people faced up to the sync issue.
The bundling you've mentioned has nothing to do with V.92, it's MPPP (Multilink PPP). MPPP allows you to join multiple PPP sessions across different lines. IIRC, the MAX TNT (the box in the telco's data center) supported up to 8 MPPP channels per user across multiple chassis. You could have done the call-back just by signaling your telephone number (a normal call, but the called number rejects the call, free of charge) and used HDLC instead of PPP for a little bit more throughput.
Sorry, part of my post got deleted while editing it. What I meant is that the Modem on Hold feature of V.92 made Multilink PPP (thanks for reminding me of what it was called) a lot more practical. (I.e., you wouldn’t be totally tying up both your landlines.)
As for my ISDN, it may have very well been a rejected call and HDLC, it was 17 years ago so it’s hard to know for sure. I know the ISP guy and I spent a hours and hours getting it to work. It finally took a three way call between me, him and a Cisco technician to get it all going, so it may have been a sub-optimal setup. But it worked and I got speeds consistent with a 128k link.
I remember a place my friend worked had a T1, that was the first time I'd ever seen one. He showed me downloading something at 80kB/sec and my jaw hit the floor, being used to topping out around 5kB/sec I had never seen such blazing fast downloading before. Now I yawn as my cheap home broadband hits 3 MB/sec.
My Pentium Pro is a bit stuffed on cards, and other devices are definitely interfering with the modem, namely the mouse. It's a serial mouse, and when it's connecting I can hear it crackling to the mouse movements in the speaker.
Check which COM port your mouse is using, it's probably conflicting with the modem. On most machines, COM1/3 and COM2/4 shared the same resources.
My Pentium Pro is a bit stuffed on cards, and other devices are definitely interfering with the modem, namely the mouse. It's a serial mouse, and when it's connecting I can hear it crackling to the mouse movements in the speaker.
Check which COM port your mouse is using, it's probably conflicting with the modem. On most machines, COM1/3 and COM2/4 shared the same resources.
I believe I'm gonna use a different modem later on. My tests happen every other day when I have time I want to allocate to it.
My Pentium Pro is a bit stuffed on cards, and other devices are definitely interfering with the modem, namely the mouse. It's a serial mouse, and when it's connecting I can hear it crackling to the mouse movements in the speaker.
Check which COM port your mouse is using, it's probably conflicting with the modem. On most machines, COM1/3 and COM2/4 shared the same resources.
I'd forgotten about that, yes COM1/COM3 usually shared the same IRQ, as did COM2/COM4. There were some utilities out there that would show you what was using each IRQ, some hardware could handle sharing an IRQ and some could not. Brings back a lot of memories fooling around with IRQ, DMA and IO range jumpers trying to get various cards to get along with one another. Modern plug n play has really made life a lot easier.
I was a BBS addict. I have been sitting on the source code for PCBoard BBS software the last few years. A little work was done by another person to get it buildable, but it requires a lot of esoteric software that can only be found in junk piles or the dredges of the internet... one upside is one of the libraries it was linked against (name escapes me at the moment), the original manufacture was able to send me copies of... until they suddenly stopped responding. I assume someone finally said "no" internally.
I've been debating putting it up on github as it's been quite a while since Clark development Company went out of business... and it isn't clear to me who the copyright holder is at this point (the bank that had their leins, I imagine).
... it's riddled with assembly for OS/2 and DOS... I've spent a little time over the years updating those functions.
....and it will only compile on specific versions of Windows that aren't available on MSDN anymore....
Nostalgia is a strong addiction as I spent more than a decade trying to find a copy of their source code before succeeding.
-j
Sent from my SM-N950U using Tapatalk
