Jump to content
IGNORED

MSS-100/Rverter connection help


Dropcheck

Recommended Posts

I realize there are several threads dealing with the Lantronix MSS-100 ethernet connection to a 850 or P-R device and thence to the Atari. As usual I'm trying a different approach. I am so close to getting it working, but .....

 

Here's my setup:

 

1088XEL AUX SIO Connection with a direct to board MTR-CTL signal connection.

 

A board with this schematic implemented:

 

Rverter2Schematic.jpg

 

 

 

Normal DB9 to DB25 Serial cable

IDC 10 pin to DB9 Serial connector

Lantronix MSS-100 acting as the modem

Ethernet connection to my internal network

 

I can access the Lantronix MSS-100 internal configuration server, so it is properly configured as far as an IP address is concerned and I can make changes to and reboot the MSS-100 through the web server. I have the modem portion set to go into modem mode when the letter 'A' is entered.

 

With Bobterm and the Rverter handler loaded I am getting the high pitched squeal that disappears as I reach the MSS-100's configured baud rate.

 

When I power cycle the MSS-100 I am getting the boot process messages displayed in Bobterm's terminal screen, so there seems to be at least one way communication from the MSS-100.

 

I am running into a similar situation that I had with the ESP-01 module. I can enter any AT command, but I'm not getting a response from the MSS-100. I have tried the CTRL-J/CTRL-H key press and still no response.

Link to comment
Share on other sites

I have tried the CTRL-J/CTRL-H key press and still no response.

CR/LF would be CTRL-M then CTRL-J.

 

Have you tried running a null modem over to a serial port on a PC? Then you can confirm sending/receiving data & typing back and forth between the two terminals. You can also get a serial tester with LED's to see the levels of each of the lines. ie: https://www.ebay.com/itm/253915670328At low baud rates like 300bps is easy to see the TX/RX LED's as you type too. You can also try connecting it to an actual external modem with LED's and trying basic AT commands and seeing if you get a response. Most 14.4K modems and faster are very good at baud rate detection, and a big part of the "AT" command was detecting the baud rate of the terminal.

 

Edit/Add: Maybe one of the DSR/DTR/RTS/CTS lines are not set correctly. (hardware flow control)

 

The computer should be outputting DSR and RTS to indicate it's 'online' and 'able to receive data'. Most modems should still respond to AT commands with DSR low as its a hardware method to hang up a call, and you need to be able to send AT commands to make a new call, but RTS low could prevent the modem from sending data to the terminal at all.

  • Like 1
Link to comment
Share on other sites

been playing these 'guessing games' forever. cutting to the chase...

 

before we blindly confuse you to the point you can never recover from...

 

We need to see your mss configs.

 

You should save your bobterm config so you don't need to change it at every boot

 

in ascii mode you don't need to do control key anything... return key works perfectly

 

You should change your mss to operate at 9600 or 4800 to start for most BBS connections. 1200 or 2400 for Plato....

 

You should turn off telnet padding in the mss

 

You should turn flow control off on the mss

 

after you have all this done and it is working then you can progress to mucking about with hardware flow control on your experimental devices.

 

if there is difficulty in setting up the mss, I could remote in and look it over for you at some point.

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

the schematic is missing a control line and the one that is shown might be miss labled

the control line that stops data flow coming from the modem can be driven from motor control line...since no data should flow during other I/O

almost no terminal programs are hardware flow control aware. They only use motor control to pinch off rx and tx etc to avoid sio interference..

since this means all data sent from the modem to the computer is lost while that happens... it should do two things instead of one, shut down sio and drop the control line to stop the modem from sending it's data. This same mistake continues going on forever... to be honest the fastest responding sio line should really be used to drop the device coupling and control lines together but I forget all that is involved there is some discussion about this on one of these forums...

some discussion involved having the line direct to the stop line and then a buffer or rest of the device connected after that so the stop of flow would occur before the lines are cut so as to prevent any loss.

 

The device you are showing was a work in progress. it will need to be combined with others or modified as I suggest. It's close but needs a reworking and possible driver modification.

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

depending on MSS firmware if you do not have the padding toggle, you can select a raw or telnet port to deal with the issue to a degree

the bbs serving an Atari should give a choice of connection port either raw or telnet and if 8 bit specific should have padding off, or must strip the padded nul

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

I see you have dynamic access set,

this can cause the mss 1000 to not respond to AT commands.... I have posted about this, probably in bbs thread,

for testing purposes you should select the other mode, I am trying to get by the fog in my brain to remember command. I will have to dig out an mss and smack some key to remember.

dynamic mode requires you to select via keyboard which way the mss wishes to function. command, remote, local.... let me think and I will remember...

 

It came to me... ATC LOGOUT

 

that means AT COMMAND LOGOUT

 

when you type A again it will switch to local

when you tape ATC LOGOUT it switches to remote

 

this allows to make as well as take calls...

 

and now I remember some post

 

http://atariage.com/forums/topic/174831-atari-8-bit-related-bbss/?p=3883248

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

I spotted another issue.. DTR WAIT is for modem mode... not modem emulation... this is for when you use dtr as carrier detect with a lantronix to modem cable...

modem emulation is to make pretend mss is a modem...

 

modem mode is to control real modems..

the was often used to get local dialing from a network connection in some town to avoid long distance calls and other such things, also to handle other serial devices remotely but that's another story

 

 

don't forget this uses a NULL modem cable...

 

also posted somewhere... there are about 4 wrong ones and a couple correct ones... because you have to go from Atari 9 pin serial to rs232 null serial

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

I guess it's time to dig it out verify my remembery - I've got just about every one of the devices and have had them all work... BBS, upload, download, irc, etc etc... while they are all similar, they are just enough different to require a guide for each, which I've never consolidate into one...

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

So my understanding is that the Rverter circuit is functioning as a serial port (DB9 in my case) on the computer, the normal Serial cable converts the DB9 signals to DB25 and finally the MSS-100 functions as a modem. Instead of putting signals on a phone line it puts it on the ethernet/Internet line.

 

If that is true, why would I use a null serial cable? I'm not going computer to computer. I'm going computer serial port to 'modem' device.

 

I'm just asking, because it appears the MSS-100 can be setup multiple ways. My understanding could be wrong.

Edited by Dropcheck
  • Like 2
Link to comment
Share on other sites

correct and the emulated modem in this case encapsulates your bits into tcp packets either raw or in telnet protocol. (though it can also do UDP)... it buffers them unpacks and regulates output at desired baud rate.

the reverse to send...

 

the devices can handle more than this though.... true port functioning skips all the crap and does direct control of much more. but never messed with that in the 8 bit world... x86 world another story

Edited by _The Doctor__
Link to comment
Share on other sites

So my understanding is that the Rverter circuit is functioning as a serial port (DB9 in my case) on the computer, the normal Serial cable converts the DB9 signals to DB25 and finally the MSS-100 functions as a modem. Instead of putting signals on a phone line it puts it on the ethernet/Internet line.

 

If that is true, why would I use a null serial cable? I'm not going computer to computer. I'm going computer serial port to 'modem' device.

 

I'm just asking, because it appears the MSS-100 can be setup multiple ways. My understanding could be wrong.

 

It is a DTE vs DCE thing. Data Terminal Equipment vs Data Communications Equipment. There are two main standards for Serial devices. They're both just as good, just wired a little differently. Rx -> Tx, Tx -> Rx, DTR -> DSR, DSR -> DTR, RTS -> CTS, CTS ->RTS. vs straight through connection.

 

Think of Printer vs modem. It's only a wiring issue.

 

No big deal.

  • Like 2
Link to comment
Share on other sites

Okay.

 

With the Bobterm program settings the same, the MSS-100 port settings changed to only modem emulation checked and a NULL MODEM adapter inserted between the MSS-100 DB25 connection and the straight serial cable I tried power cycling the MSS-100.

 

This time the screen was nearly filled with almost every character the Atari has on it's keyboard, but none of it readable as English.

 

Without the NULL MODEM adapter power cycling the MSS-100 created a very readable progress report on the Bobterm terminal display.

 

In neither case was I able to get a response with a AT command.

 

There is a section in the manual about wiring requirements that I'm not quite understanding. Let me see if I can copy/paste the section.

 

Here we go:

 

Wiring Requirements

Serial signals work differently when the MSS is in modem mode. First, the MSS will enable DTRWait and will not drive DTR until a valid connection is made with the ATDT command (see Modem Mode Commands). Second, the MSS will drop DTR whenever the TCP session is disconnected. DSRLogout is enabled implicitly. The intent is that the MSS DTR signal will be used as a simulated CD signal to the attached serial device.

 

If you are using an MSS with a DB25 connector, you will need to change the way you wire the DB25 adapters.

 

The serial device's DTR goes out to BOTH its own DSR in and the MSS DSR in. When the device asserts its DTR, it will see its DSR asserted. That way the device thinks that the "modem" (the MSS) is ready to accept commands all the time, and the MSS can log out the serial port when the device disconnects.

 

The MSS DTR out goes to the serial device's CD in. That way the MSS can signal the serial device that there is a valid connection, and the serial device will know it can send data to the remote device.

Edited by Dropcheck
Link to comment
Share on other sites

no you are confusing modem mode with modem emulation again, this is why we end up with two different wiring scenarios.

Best way to put this

ATARI,(850,MIO,PR:,Rverter) to (lantronix,modem)

Lantronix to modem

these are wiring

 

you should be doing this

sio to middlebox (which is proprietary to every middlebox) to lantronix

You can not use pc 9pin assignment to lantronix as your rverter should follow Atari serial assignment if using a 9 pin wire to 25 rs232 pin wire.

The off the shelf 9 to 24 wire in the pc realm are not the same as off the shelf Atari 9 to 24 wires

 

You can use off the shelf cables from any Atari vendor (they sell both modem and terminal cables)

 

The pin-out is listed on the schematic you need choose one or the other for your needs.

Your problem sound like you are using a pc9 instead of an Atari 9 in your wiring. The schematic is for SIO to middlebox to modem only

Edited by _The Doctor__
Link to comment
Share on other sites

OMG

no you are confusing modem mode with modem emulation again, this is why we end up with two different wiring scenarios.
Best way to put this
ATARI,(850,MIO,PR:,Rverter) to (lantronix,modem)
Lantronix to modem
these are wiring

you should be doing this
sio to middlebox (which is proprietary to every middlebox) to lantronix
You can not use pc 9pin assignment to lantronix as your rverter should follow Atari serial assignment if using a 9 pin wire to 25 rs232 pin wire.
The off the shelf 9 to 24 wire in the pc realm are not the same as off the shelf Atari 9 to 24 wires

You can use off the shelf cables from any Atari vendor (they sell both modem and terminal cables)

The pin-out is listed on the schematic you need choose one or the other for your needs.
Your problem sound like you are using a pc9 instead of an Atari 9 in your wiring. The schematic is for SIO to middlebox to modem only


So isn't the purpose of the Rverter circuit to convert Atari SIO signals to the bare minimum RS232 signals needed. According to the schematic it puts the correct RS232 signals on the correct standard DB9/DB25 connector pins. It does not however generate all RS232 signals, especially the handshaking signals. Nor does it buffer or manipulate those signals beyond the initial conversion to RS232 signal levels.

Here is the schematic again and the standard COM port pinouts A DB9 to DB25 adapter cable will simply transition the signals from the DB9 side to the correct DB25 pins.

Rverter2Schematic.jpg

cabling_dcc8.png

 

 

 

 

Why is this mythical middlebox needed?

  • Like 1
Link to comment
Share on other sites

Your rverter circuitry is the middlebox as is an 850 or a mio or whatever mythical unicorn we have all been using since 198x

 

You keep using the computer side for your pinouts, you need the modem side.... they are not the same...

 

modem side...

25pinMdm 9pinAtari

20 to atari9 side 1 dtr

8 to atari9 side 2 crx

2 to atari9 side 3 xmt

3 to atari9 side 4 rcv

7 to atari9 side 5 grnd

6 to atari9 side 6 dsr

4 to atari9 side 7 rts

5 to atari9 side 8 cts

 

you could put a null modem adaptor combo gender bender on the 25 pin side only

 

com1 db9 is not an atari db9 and it matters which end goes where and the gender.

 

how about instead of being flip you go to the BBS thread and pick one of the working wiring diagrams I and others have posted.

since they worked for everyone else they should work for you.

 

Now if you want to post a picture were we can see exactly what you wired up maybe we can see what is wrong.

 

The Idea was to get you to wire up two standard Atari db9p to rs232 cables- normal and null, you could then wire up a standard Atari db9 to the r:verter... whenever you needed a modem or terminal cable you could switch them out at will, you could also use that cord with an 850 or any other Atari based serial device. You keep choosing to make the PC cable choice. All of these serial cables are one way cables in the sense you can not reverse them or put a garden variety null modem adapter etc. on the db9 computer end, you can only put such adapters on the 25 pin device end

 

I am of the school we make known good cables and connections first... verify it's all good and then sort the other science projects out. since we know it's all good we can figure out where the interface has gone wrong. Posting pinouts for the pc does nothing

 

a look at your pc pinout you insist on following that is computer side and not device side

2 rd-rcv

3 td-xmt

4 dtr

now consider the atari db9p serial interface pin out (you will see why using a pc cable will only get you half way there)

2 crx

3 td-xmt

4 rd-rcv

it is a very simple cabling issue that always gets blown out of proportion- I suggested you draw out a seventh line if you were going for hardware flow control for the incomplete interface you are working on. If you are putting a db9 on the interface you don't want to use a pc style com port since almost any atari user will grab an Atari cable when ordering from best or b&c or one that is with their atari equipment already

 

hmm mythical creature on the way

 

Edited by _The Doctor__
  • Like 2
Link to comment
Share on other sites

the mss pins l-r top 1-13 bottom 13-25 from the book may be incorrectly drawn in it's pdf provided online as follows

1 tx

2 rx

3 rts

4 cts

5 dsr

6 gnd

7 dcd(in) thats from a modem

18 cd(out to computer)

20 dtr

 

when I saw that in the pdf I thought to myself... hmmm I think they are shifted 1 pin more likely it would be correct as follows

2 tx

3 rx

4 rts

5 cts

6 dsr

7 gnd

8 dcd

18 cd

20 dtr

so I will verify my hand made cable I created some years back..

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

atari 9 mss100 25

1------------6,8

2------------20

3------------3

4------------2

5------------7

6------------8,6

7------------5

8------------4

9- not connected

dsr 6 and dcd 8 are tied together 25pin side on this old cord this also effectively ties atari db9 pins 1 dtr and 6 dsr together as well... but the cable works... I will revisit the cord as it's probable it was wired to allow this to work with more than one mss variant.

 

so fig 7-2 of the pdf is wrong for mss100

fig 7-6 of the pdf is correct for mss100

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

wiring is correct as posted in

http://atariage.com/forums/topic/284097-mss-100rverter-connection-help/?p=4137815

 

Verified with a meter and called some BBS's

Was able to upload and download files both super large all the way to very tiny...

 

CD was detected

 

Hardware hang up worked on DTR drop

 

it is indeed a cable constructed to work with several different console servers..

 

- tied together pins can be removed depending on your needs.

 

Flow control was not active for uploads or downloads as almost all such protocols have their own form of software control built in as a matter of crc error checking and acknowledgement

 

*** calling different BBS we saw the hearts(nulls) appeared on some depending on their telnet settings, so I hung up. the remedy-

ATC CHANGE TELNETPAD ENABLE

*** simply toggle that setting as needed if you see control m heart control j is happening and it will fix it- only then will you be able to see all atascii graphics screens and be able to upload as well as download.

 

all worked as it should.

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...