V6.0 FIRMWARE RELEASED!
#1
I just released a major firmware update for the WiModem family!  The new version fixes a few small issues and adds some needed features!  See the firmware history for a full list of changes.

The issue with Mystic BBS using cursor keys has been resolved.  When you press certain keys on a modern keyboard, it generates an ESCape code followed by a 2 byte function code.  The WiModem sees the first character and sends it over the air to the router, followed by the remaining characters as individual transmissions.  Router and over-air communications are very slow due to the latency.  The Mystic BBS software is expecting the ESCape code and the function codes to arrive within a few characters times (microseconds) from each other, which is simply not possible in a WiFi environment when sent individually.  There are two new options that can be tweaked in the future to resolve any potential issues related to the WiModems being too fast for their own good!  This was the issue with the Mystic BBS software.

There is now an option to have the OLED screen power itself off after so many minutes.  These displays really do not have screen burn-in issues, but some people like to have the display dark when not in use.

The packet handling code has been re-written yet again, yielding more performance for uploads/downloads.

The big new feature for the v6.0 firmware is NULL MODEM cable emulation!   You can now use two WiModem or WiModem232 units together to emulate a NULL MODEM cable!  This means that you can use a WiModem232 with a desktop computer via a standard COM port and send data to a RS232 device (like a printer or plotter) that has the other WiModem232 plugged into it!  No more cable required!  You can also connect two computers together to do super fast file transfers - typically 20% faster than just "dialing" from one computer to the other.  NOTE:  When you use the NULL MODEM mode and you return to normal modem operation, the previous router setting will be gone... so you will have to re-establish a connection to your router.
Reply
#2
Hey Jim. I'm having a real problem here after this latest update. I updated all 3 of my WiModem232's and according to the text, it went fine.

On the WiModem232 that I have on the Mega ST4 that runs my BBS, it's working fine for all *incoming* calls. There doesn't seem to be any problem on that end.

However, on the other 2 WiModem232's, whenever I use them to call *out* to my BBS, they work for so long, then it's like the WiModem232 drops back down to the initial startup mode where you can type the usual AT<whatever> commands. The call, meanwhile, is still connected to the BBS, but you can no longer give it commands. When it does this, an "OK" prompt is shown on the screen. I'm going to attach some screenshots to show what I mean. Also, and now it gets really weird, after it does this the "ATI" command says it has new firmware waiting again. Mind you, I've already updated it. I can unplug the WiModem232 and restart it and the new firmware message goes away. At least it does until I try to call the BBS again then it goes through the same cycle. I did try updating again and it reports that it's successful (again) but it didn't fix the problem.

Thanks, and sorry that I always seem to be the poster child for odd problems!   Confused


   


   
Reply
#3
Okay, more fun stuff (I'm using the word "fun" in a way most people wouldn't be familiar with).  Smile

So I was logged into DarkForce!, my BBS, calling in with Windows10 and SyncTerm. It suddenly stopped responding. I went over to the BBS (this was all in my man cave) and first off, the BBS was still "active" on the Mega ST4 itself. The WiModem232 had changed it's LED color to blue and was now scrolling the screens from the BBS on it's OLED! Weird.

As soon as the screen loaded all the way up on the BBS, it stopped scrolling on the OLED too. You can see it on the screenshots below. I powered the WiModem232 off and restarted it. For the moment, it's working again. I am clueless as to what is going on... Thanks.

   

   
Reply
#4
Try doing AT&F to do a factory reset and see if the issue stops.  There were a lot of little internal changes to the settings.  This looks like the timeout is occurring.

If that does not work, then you can always downgrade the firmware back to v5.11 (which was the previous version) by typing:

AT*DOWNGRADE


I have never seen an issue like what you are reporting and I spent a few hundred hours calling various BBS's, especially Mystic based BBS's.  So far, nobody else has reported any issues either.
Reply
#5
(03-13-2023, 03:41 AM)admin Wrote: Try doing AT&F to do a factory reset and see if the issue stops.  There were a lot of little internal changes to the settings.  This looks like the timeout is occurring.

If that does not work, then you can always downgrade the firmware back to v5.11 (which was the previous version) by typing:

AT*DOWNGRADE


I have never seen an issue like what you are reporting and I spent a few hundred hours calling various BBS's, especially Mystic based BBS's.  So far, nobody else has reported any issues either.

Thanks for the reply. I had already done the "AT*DOWNGRADE" on the WiModem232 on the Mega ST4 that runs DarkForce! and I can happily report it's back to normal there, rock solid as ever (so far anyway).

I'll try "AT&F" on the other 2 WiModem 232's and see if that fixes the problem. I'm going to assume that I will lose all my custom settings on them when I do.

I should be able to play around with them today so I'll report back later (assuming nothing blows up - watch for news reports about localized explosions in Prestonsburg, KY). Not unusual when I get my hands on things...     Smile
Reply
#6
Hey Jim. Okay, I think I've found the problem...

Basically, I've always run the buffer at 8192 using the AT*BL[x] command. That was the previous maximum. However, as of this update, it looks like you dropped it down to -> 4096 <- . However, after the update, the buffer, according to AT&V, was still showing 8192 on all 3 of my WiModem232's. Now per your advice, I did an AT&F, resetting to factory defaults on the WiModem232 on my Mega STe and then laboriously reset all my settings. I took a screenshot before resetting, BTW. After doing that and noticing that it gave me an error when I tried to do 8192 for the buffer I went back, D/L'ed the updated PDF manual and read about the change there (always, always read the instructions LAST, right?). Seeing you had changed it, I used the buffer command to set it to 4096, saved everything, then ran tests on it. It seems okay on that WiModem232 now. So...I thought, why not just try changing that on the other WiModems instead of a full factory reset. I went to my STacy and made the change there, then tested it. Boom! - seems to work okay. I just now made the change to the Mega ST4 that runs DarkForce! and so far, it seems okay there as well too.

So yeah, it looks like there's some kind of issue with the buffer if you have it set higher than the new limit you've put on it. At least, that's what it seems like because after setting all 3 WiModem232's to the new limit of 4096, everything does seem to be working okay again.

Here's a picture of one WiModem232, *after* the update, but before I changed anything. Notice the buffer limit it's showing!  Smile


   
Reply
#7
Yeah, that makes sense. I will make a change to the firmware so that when the settings are loaded and the buffer is greater than the max allowed now, it sets it to be the max allowed. That will solve this in the future. However, I almost removed this feature as it's really not needed anymore. I have it in place for testing. I can issue ATI3 and see if any of the incoming blocks of data exceeded the current buffer limit. This was letting me know really where the threshold was for high speed (230.4Kbps) data transfers. So, I could just remove the feature then I would not have to check the settings when loaded.
Reply
#8
Hmm, so am I reading that right in that you're saying you might remove the buffers altogether? Won't that affect file transfers?

Guess I'm being dense here again... Sad
Reply
#9
No, I mean just hard code the buffers at 4096 because anything higher does not improve performance at all. We don't care about wasting memory for buffers, so having it lower doesn't make any sense either. There is no longer a need to be able to change this.
Reply
#10
(03-14-2023, 01:03 PM)admin Wrote: No, I mean just hard code the buffers at 4096 because anything higher does not improve performance at all.  We don't care about wasting memory for buffers, so having it lower doesn't make any sense either.  There is no longer a need to be able to change this.


Oh, okay - I gotcha now.  Smile
Reply




Users browsing this thread: 2 Guest(s)