Question about modems

[alan at alanlee.org]

I think you may be over thinking this.  I suppose a system could send a 
bit-stream where the data bits + any parity bits != 8 or the parity bit 
isn't in the trailing MSB position.  However, for simplification lets 
consider only that case.  A modem will always set the local line coding 
to 8,N,1.  Any bytes received in command mode will be AND'd with 0x7f to 
strip any parity bits before being interpreted.  A modem could 
optionally detect and reconstruct the local line parity scheme for the 
purpose of stuffing the 8th bit MSB for the command responses (eg 'OK' 
etc) on the local line.  But it will always transfer the entire 8-bit 
word period to the remote end in data mode - unmodified.

I suppose you could have 7,N,x however the MSB of the 8-bit word period 
would be a stop bit and would transfer through the modulated 
transmission the same way - correctly.  The number of stop bits only 
affect the transmission side of characters on the local line - in that 
it adds extra padding between bytes to mitigate timing mis-alignment.  
My rule of thumb for RTL UARTs is transmitters should always idle for 
1.5 stop periods while receivers should always begin the start bit 
search after .5 bit-periods after the 8th data bit period.  I suppose 
this could cause problems when a line rate is 100% saturated - but so 
could oscillator mismatch over time.

My advise is always set the MCU line coding to 8,N,1 (or preferably 
1.5), strip the MSB in command RX, and manually re-add MSB parity 
stuffing for command responses only based on some algorithm that makes 
the most sense.

-A

On 2019-11-13 19:08, Jim Brain via cctalk wrote:

> 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