Posts: 15
Threads: 2
Joined: Jun 2026
Howdy again.
I have found a minor annoyance. When I dial under Telix or under Putty, there is no linefeed after the carriage return. The result is that the response from the modem overwrites the dial sequence entered. Since I do a lot of free-hand dialing in terminal; it can get ugly and confusing.
If you have a mind to sometime in the future, would you please consider looking into it and tidying it up (assuming I'm not doing something incorrectly)?
Thanks.
Posts: 2,978
Threads: 149
Joined: Nov 2013
There should never be a linefeed after (or before) a carriage return, per the Hayes command protocol. Doing that would throw off every auto-dialer program out there.
Posts: 15
Threads: 2
Joined: Jun 2026
(06-19-2026, 11:19 PM)admin Wrote: There should never be a linefeed after (or before) a carriage return, per the Hayes command protocol. Doing that would throw off every auto-dialer program out there.
What I mean is that when you type ATD[number] and press enter, it doesn't move down a line but overwrites the ATD command. It this how it always was from the 1980s? Perhaps I am misremembering (very possible as I often experience CRS, lol).
Posts: 15
Threads: 2
Joined: Jun 2026
I just realized that it doesn't always do that. I just only notice when it does overwrite the line. It seems inconsistent.
I certainly don't want to break compatibility, of course, as that is the whole point of the WiModem, right?
Posts: 2,978
Threads: 149
Joined: Nov 2013
(06-19-2026, 11:43 PM)Hans13 Wrote: (06-19-2026, 11:19 PM)admin Wrote: There should never be a linefeed after (or before) a carriage return, per the Hayes command protocol. Doing that would throw off every auto-dialer program out there.
What I mean is that when you type ATD[number] and press enter, it doesn't move down a line but overwrites the ATD command. It this how it always was from the 1980s? Perhaps I am misremembering (very possible as I often experience CRS, lol).
I just looked at my source code (11 years old now). Only CR is sent by the modem in normal mode. LF is also sent if the modem is in verbose mode (AT*V1). This was not commonly used, but is supported for full compatibility.
Posts: 15
Threads: 2
Joined: Jun 2026
Yep. The modem defaults to
ATV1; verbose mode. That's exactly where the inconsistency seems to be. Sometimes it sends an LF and sometimes it doesent, or sends it in a way the terminal doesn't catch it. The result is that when you dial, the message back (
CONNECT,
NO CONNECT, etc) sometimes overwrites part of the line sent to the modem. So, when
ATDSomeRandomBBS.com:6809 becomes
CONNENCTmBBS.com:6809.
It is just a minor thing and does NOT hinder the operation of the modem in any appreciable way that I can assertain. Also, it is very possible that all or most modems faster than 1200 baud had a similar quirk, possibly due to RS-232, back in the day and I just am not remembering it. During the 1980s and 1990s, I had my head in a lot of modems daily but that doesn't mean I am recalling accurately. Seriously forcing myself to look back in memory, I seem to think some modems did this from 2400 baud and beyond... but not completely sure.
(I am simply loving this modem, BTW. I had been intending to purchase some since you first brought them to market.
)
Posts: 2,978
Threads: 149
Joined: Nov 2013
I guess this could be a flow control issue?
Posts: 15
Threads: 2
Joined: Jun 2026
I don't really know and I am at a loss for a way to diagnose that under these circumstances. I experienced it on a Raspberry Pi 500+ and on a Windows 10 box. Both are using USB to RS232. I thought I had an actual serial port system but must have 86ed all of them at some point in the past. I could purchase a PCI serial card if necessary to test.
Do you have any suggestions on how to test the hypothesis? I'm game to try.
