Question about modems

[Jim Brain]

On 11/13/2019 3:41 PM, Nigel Johnson via cctalk wrote:
> No. While each end might be able to communicate with the local modem 
> in command mode using different parameters, when they are in connected 
> mode the modems will not convert anything, just pass the exact format 
> along. So if one end is expecting 7E2 and the other is sending 8N1 
> there will be a 50% chance that parity errors will be received.
>
> cheers
>
> Nigel
>
>
> On 13/11/2019 16:16, Grant Taylor via cctalk wrote:
>> On 11/13/19 1:31 PM, Fred Cisin via cctalk wrote:
>>> But, stuff like commands to the modem didn't need much of that, and 
>>> needed to be able to communicate in spite of wrong parameters.  It 
>>> made sense for a modem to recognize a command, even with wrong 
>>> parity, etc.
>>
>> Okay....
>>
>> Now I'm thinking that there are really two phases / modes of 
>> communications:  1) computer to modem commands, and 2) computer to 
>> computer via modem connection data.
>>
>> I think my previous statement applies to #2.  I can see the value in 
>> #1 being more liberal in what it recognizes and accepts.
>>
>> But, I'd still be surprised if the following would work for #2.
>>
>> [A]---(7E2)---{modem}==={modem}---(8N1)---[B]
>>
>> Would A and B be able to transfer data between each other with 
>> different (local) settings?
>>
>>
>>
>
>
Jumping back in here:

Initially, tcpser's goal was to emulate enough of the "Hayes" command 
set so as to bridge old BBS applications so they could be once again 
used without modifying them and trying to make them aware of the 
Internet.  Over time, that mandate meant adding in support for S 
registers and & commands and such, since apps used those.

However, the actual line functionality of the modem was never attempted 
to be emulated, as doing so would defeat the purpose of the app.

Initially, I assumed everyone would set their BBS to 8N1, so as to 
maximize the utility of the connection (8 bit clean, etc.).

But, now, I have a Teletype Model 43 here, and it only does 7 bit ASCII. 
Fozztexx's mod helps, but it only cleans up parity while in command 
mode, which means I can atdt jammingsignal.com, but then when I connect, 
I can't log onto that Telnet BBS (that's the catchall name for such 
things) because parity gets in the way.

To be as useful as possible, I think the utility should detect parity in 
command mode, but then switch the entire data stream to that 
configuration, both command mode and data mode.

The alternative (since a PC can't sniff the serial stream like the Hayes 
did), is to allow parameters to set the specific parity and number of 
stop bits.  And, I think I'll do both.  Without parity and stop bits, 
sniff parity.  With it, lock in the parity and don't sniff.  That way, 
if folks want the purist behavior, they do tcpser -s1200,N,8,1 and 
sniffing can just do -s 1200

Jim

-- 
Jim Brain
brain at jbrain.com
www.jbrain.com