Possible to downgrade firmware?
#11
Ok, I pinged your setup using 6400 instead of 6401 and it connected.  So, I am guessing that your port is just set wrong?  Look at your screen shot that you posted, you can see the port is set to 6400, not 6401.
Reply
#12
I changed the listen port to 6401 on my WiModem and I am able to call it just fine.
Reply
#13
OK... update. I decided to enter your init string and I see the exact same problem that you are with it connecting and hanging up instantly. I need to figure out what your init string is doing.
Reply
#14
So, this is an invalid init string:

ate0q0v0&c1x1&k0&s1*b0
s0=1 s2=43

The problem here is that you have *b0 which tries to set the baud rate to 0 (invalid), and I think that the next line is going to be ignored?  I will look into this some more to see what the WiModem is actually doing.  The v0x1 disables the verbose and text modes so you get response codes as numbers instead of English text.

Update -

Ok, this is definitely going to return an error (numerical) and that probably skips the next line that enables the auto answer (that is what S0=1 does).  If that's suppose to be one long init string (and not two), then it definitely is the cause of your problem because as soon as any command that is parsed in the string generates an error it exits the parse and does not continue to process the remainder of the string.  That is the official "hayes" way of handling the strings.

I would recommend using this string:

ate0q0v0&c1x1&k0&s1s0=1s2=43

However, there does seem to be a problem with the WiModem doing the auto-answer (S0= anything but 0).  ATA works perfectly, but not the auto-answering.  I am looking into it.  You will need to fix your init string though.
Reply
#15
(01-23-2021, 09:02 PM)admin Wrote: Have you tried calling the WiModem while you are using CCGMS to see what is going on?  You should see RING, RING, RING over and over until you type ATA<RETURN> to do the answer.

I am not sure what to think.  If you go back to the previous version it should be back to the previous firmware. I did not try using something other than 6400 for the port, I will change my setup to use 6401 and see if that makes some type of difference.

The AT&F definiately resets everything except the baud rate in EEPROM to preset values.  So, your port would be reset back to 6400, not 6401.  So, if you are expecting to be using port 6401 it is definitely not going to work!
>>The AT&F definiately resets everything except the baud rate in EEPROM to preset values.  So, your port would be reset back to 6400, not 6401.  So, if you are expecting to be using port 6401 it is definitely not going to work!

I understand that and know better. I'm already forwarded on 6400 with a different modem to keep my BBS active, the same one the Wimodem ran on port 6400. I only switched the Wimodem to 6401 on a different 64 so you could test it in a terminal.

>>If you go back to the previous version it should be back to the previous firmware.

It does rollback the firmware, just not the problem that came after the update. Or at least ATI shows it's rolled back.

>>Have you tried calling the WiModem while you are using CCGMS to see what is going on?

Yes, several times and It goes, 10 (Connect 2400) and then to 3 (NO CARRIER) instantly. Never get a chance to ATA. This is why I set the terminal up for you to see. I just came in and see someone (or something) was trying to connect, there's a bunch of 10's & 3' on the screen. Calling from CCGMS with 2 different modems (non Wimodems), works flawlessly and one of them is now running the BBS until I/we can get this straightened out.
BBS: micromansion.servebbs.net:6400
Reply
#16
(01-23-2021, 09:04 PM)admin Wrote: Ok, I pinged your setup using 6400 instead of 6401 and it connected.  So, I am guessing that your port is just set wrong?  Look at your screen shot that you posted, you can see the port is set to 6400, not 6401.

The ONLY reason 6400 worked is because it's assigned to a different modem running the BBS. The WiModem IS ON 6401 intentionally and opened that port in my router. That picture was JUST BEFORE I switched it back out of the BBS and into the terminal. So forget 6400,it's no longer associated with the WiModem, 6401 is.
BBS: micromansion.servebbs.net:6400
Reply
#17
(01-23-2021, 09:55 PM)admin Wrote: So, this is an invalid init string:

ate0q0v0&c1x1&k0&s1*b0
s0=1 s2=43

The problem here is that you have *b0 which tries to set the baud rate to 0 (invalid), and I think that the next line is going to be ignored?  I will look into this some more to see what the WiModem is actually doing.  The v0x1 disables the verbose and text modes so you get response codes as numbers instead of English text.

Update -

Ok, this is definitely going to return an error (numerical) and that probably skips the next line that enables the auto answer (that is what S0=1 does).  If that's suppose to be one long init string (and not two), then it definitely is the cause of your problem because as soon as any command that is parsed in the string generates an error it exits the parse and does not continue to process the remainder of the string.  That is the official "hayes" way of handling the strings.

I would recommend using this string:

ate0q0v0&c1x1&k0&s1s0=1s2=43

However, there does seem to be a problem with the WiModem doing the auto-answer (S0= anything but 0).  ATA works perfectly, but not the auto-answering.  I am looking into it.  You will need to fix your init string though.
I'm sorry, that b0 is for the WiFly modem which is being used as baud detection. IT IS NOT in the string on the WiModem. if you look at the pic I attached in the other post showing AT&V, you can clearly see baud is set at 2400. So much information passing around, that was an error on my part.

I also just put those S registers on a separate line to make it clearer. Again, I defer you to the pic of my AT&V (reattached here).

I've been using that same string for 4yrs with no problems on all my modems, including yours.


Attached Files Thumbnail(s)
   
BBS: micromansion.servebbs.net:6400
Reply
#18
So, there is a problem with the auto-answering (ATS0), which is the same thing (but different) from manually invoking the answer by typing ATA. I am guessing at this point this problem started several versions ago, which is when I updated the Arduino libraries for the first time in years. v3.20 and v3.21 both do the same thing. I need to figure out what version I made the switch to the new libraries. I am guessing that you guys had a version older than v3.20.

Make sure you don't use that *b0 as part of the init string with the WiModem because it won't set the auto-answer at all and the incoming caller would just seeing a ringing forever.

I am looking into this issue right now. Since ATA works perfectly for answering a call, nothing in the connection code itself is at fault. It's probably some race condition that has been introduced because of the new libraries. The executable itself grew almost 100K larger in size because of the new libraries - I hate high level languages!
Reply
#19
OK, so I changed to the new libraries starting at v3.10. So, v3.10, v3.20, and v3.21 all have this issue. v3.06 is fine.

You can downgrade your firmware so you can run your BBS until I get this fixed. Type:

AT*DOWNGRADE

This installs v3.06.
Reply
#20
(01-23-2021, 11:56 PM)admin Wrote: OK, so I changed to the new libraries starting at v3.10.  So, v3.10, v3.20, and v3.21 all have this issue.  v3.06 is fine.

You can downgrade your firmware so you can run your BBS until I get this fixed.  Type:

AT*DOWNGRADE

This installs v3.06.

Ok, doing it now.

Interesting though, 3.20 was working no problem, actually all of those were up until this last update (3.21).

Keep us/me posted. Curious.

Thanks.

UPDATE: Confirming 3.06 is working and back on port 6400 running BBS
BBS: micromansion.servebbs.net:6400
Reply




Users browsing this thread: 1 Guest(s)