Non-verbose code discrepancy
I have been doing some experimentation with the WiModem232.
It is not playing nice with my BBS.

The software sets the modem to return non verbose responses (ATV0) and therefore expects a RING response to return a value 2 and CONNECT a value 1.
I checked and this is the standard from the Hayes reference manual, found here:

However, the WiModem232 returns the RING command as 1 and the CONNECT command as 2.  I tested the response with verbose responses and it does indeed return RING followed by CONNECT, but the non verbose codes appear to be backwards.

Is this an error in the firmware?

My Hayes spec info shows RING as 1 and CONNECT as 2.  So, someone's data is wrong!  I will look into it.

::Edit::  Well... I guess I will switch my codes.  I also found that 14400, 19200, and 38400 are different from the Hayes manual you linked to.
Thanks for looking into it!
Nice to see that you're so responsive. I look forward to the results!
There are several other fixes that I have made over the last few days, so I will release a firmware update with those fixes and the new non-verbose codes to match the Hayes manual, tonight.
Thanks for correcting the non-verbose connection and ring codes.

Next question: My BBS software (GBBS 2.1) relies on non verbose codes to establish connection speed.
That is, when the modem connects to a remote client, it returns a code 1 for "CONNECT". While this is correct, I wonder if there is a way to get it to return a more descriptive code that tells the BBS what speed. GBBS assumes that a code 1 for "CONNECT" means to connect at 300 baud, so it adjusts its connection speed to 300 baud, which of course screws everything up if the modem cannot reduce its speed to match.

IT's a two faceted issue really. The first is that the WiModem's connection speed to the host computer is fixed, and I'd love it if it were autospeed like most commercial modems.
The second is that I'd prefer if there were a way to modify the connection speed message somehow. For instance communication with the host computer could be fixed at 9600 (non-verbose connection code 12) while it could negotiate a remote connection speed at whatever the remote client wants.
The auto speed detection is done by the terminal (or BBS) with extended codes turned on (ATX1) and then looking for the the text AFTER the CONNECT message, ie. CONNECT 38400.

There is no way to convey a speed when using the non-verbose codes.
Ok, but in this case the BBS is looking for a non-verbose code.
Would it not be possible to return a speed dependent non verbose code (like 12 for "CONNECT 9600 for instance) based on the speed set by AT*B9600?
This is already done using the Hayes codes.  Since the modem speed has to match the computer speed, you are going to get a connect message of the DTE always.  There is no such thing as having a modem running at 300 baud and the computer running at 9600 baud.
I understand that, but if my BBS software sees a CONNECT non verbose code of 1, it assumes that the modem has made a remote connection at 300 baud (this is the only connect speed not formally specified in the Hayes reference so the assumption is that the connection is 300 baud) and the BBS drops the serial port connection speed to the modem to 300 baud. Since the modem is stuck by AT*B1200 at 9600 baud it will not communicate with the BBS due to a port speed mismatch.

If I use the command ATX1 the message returned by the WiModem232 is still "CONNECT" not "CONNECT 9600" The non-verbose connect code returned is still 1.

What I'm asking is that a firmware option be implemented whereby the WiModem232 returns an explicit connect non verbose code (and verbose code if you'd like) describing the connect speed. This can be dependent on the baud rate set by the AT*B command, since the baud rate between the computer and the WiModem232 can't change anyway.
When you use ATX1 and verbose mode is off (ATV0), connect messages should be correct.  So, a connection at 9600 baud with ATX1V0 should give you a connect code of 12.  I will double-check this, but this is certainly how it should be.  That is the Hayes specification.

Users browsing this thread: 1 Guest(s)