This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Does LMX9838 send RS232 control signals over bluetooth?

Hello all, before asking my question let me summarize my situation:

I am trying to interface a legacy computer system to a contemporary PC. The PC is serving as a peripheral (disk) to the legacy system. The server software on the PC side uses a COM port (real or VCP) and monitors either DSR, CTS or RI as a handshaking signal (uses only one handshaking line, when the line goes LOW the software expects a command from the legacy system). I have this working with a USB-to-Serial cable with no problems. I recently wanted to try this over wireless (blue tooth) and wanted to try it with a LMX9838.

The legacy system uses a proprietary serial port with only one handshake line (called COMMAND, which is normally high, and goes low to indicate a command is going to be sent to the peripheral on the TX line, peripherals are intelligent and only respond when addressed by the computer). The legacy system can not control the LMX9838 UART through software and could not interpret LMX9838 UART commands, so SPP profile must be used in transparent mode to send and receive everything as raw data.

I built a prototype and I am able to send and receive data over the Bluetooth link. What I am not able to do is to communicate the legacy computer's COMMAND line state to the PC. I monitored the COM port created by the Bluetooth device on the PC and seen that DSR/DTR and CTS are all pulled HIGH and they never change.

So my question is how do I connect my handshake signal to LMX9838 and send it over the bluetooth link. Is it possible with SPP transparent mode as I can not really use the Command mode?   With a USB-to-Serial cable I did this easily by connecting the line to the DSR signal that goes to the PC.

Here's a simplified diagram of operation:

Legacy  System (LS)  ---->  LMX9838  ---->     ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ))     ------> PC with BT and the Server Software (SS)

                                                   --------> SS monitors CTS (or DSR/RI depending on user preference)
                                                   --------> LS COMMAND line goes low (when using a cable it is connected to CTS line or as above)
                                                   --------> LS sends a Command frame
                                                  <--------  SS receives the command frame and sends ACK or NACK
                                                  -------->  LS sends (output) or
                                                  <--------  waits (input) for a Data Frame if ACK from SS
                                                  <-------- SS sends a Complete byte to indicate the command was processed

Many thanks

Ray

  • Hello Ray,

    If you were successful with the USB-to-Serail cable, did you try connecting the same cable to the LMX9838?  That way you have all the serial control signals available on the side you are having issues with.

    Thanks,

  • Hi greenja, I am not sure if I understand your answer correctly but  the LMX9838  interfaced to the Legacy computer's serial port is supposed to replace the USB-to-Serial cable that I am currently using, well that's at least what I expected to happen (and it does happen with the exception of signal control lines -- I can send and receive data over Tx and Rx). The whole idea is to eliminate the cable and use the BT transport and the COM port created on the PC by the LMX9838 instead.

    Again, data lines are fine but the server software on the PC side monitors the signal control line on the COM port to act upon and since the signal control line never goes LOW the software does not respond to incoming commands and data frames.

    Also the USB-to-Serial Cable I am using is a special one that I built. The end that normally has a DB9 connector has a proprietary plug that goes to the legacy computer's serial port (which outputs signals at TTL levels not RS-232 levels, so there is no need for a RS-232 level converter in this cable).

  • Hi,

    I was actually hinting at  a redundancy system to test/confirm/monitor the control signals.  You would connect another USB-to-Serial cable to the one you have and get an RS232 signal from it and interface that to the LM9838.  That would at least give you an opportunity to figure out just exactly what is going on with the control lines.

  • I am sorry if I am dumb or just not experienced enough on electronics but I don't understand that. I can understand interfacing the LMX9838 to the USB to Serial Cable that I have, but I wouldn't know how to connect 2  USB-to-Serial cables together?. If you mean connecting the second cable to the Legacy System, I should clarify that the legacy system has no USB port.

    Actually before doing any more tests I wanted to know how to interface control signals from the host (in this case the Legacy System) to the LMX9838. Docs say that  LMX9838's CTS and RTS lines should be connected to the host system for flow control between the host and LMX9838 in TRANSPARENT MODE OPERATION. I never considered the COMMAND MODE as my legacy system can not interpret commands from the BT module, so I have to use the TRANSPARENT MODE.  But I don't have two control lines on the legacy system as I explained before, I only have one line and it is normally pulled HIGH. That line goes LOW when a command is about to go out. So I connected that line to the CTS pin of LMX9838, leaving RTS unconnected. But I am not sure if the status of that  CTS line also transmitted to the remote system over the BT link. Monitoring the COM port on the remote PC reveals that control line statuses never change (they are always pulled HIGH), thus my Peripheral Emulator software running on PC never sees CTS go LOW so it never acts upon the commands coming from the Legacy System.

    So to make it real short, the question is "are the control line signals from the host system transmitted to the remote over the BT link". What it looks like to me is that control signals are only used to control the flow between the host and the BT chip but they are never transmitted to the remote over the BT link.

  • Hello Ray,

    I probably wasn't too clear with my explanation.

    The RTS and CTS lines are used for hardware handshaking.  You can disable the hardware handshacking on the PC.  That way you won't have to worry about what the COMMAND line is doing.  

    My suspicion is the the COMMAND line is by directional and my original suggestion was a way of testing to see just how the COMMAND line works.

    Thanks,

  • I guess I wasn't too clear on my explanation either. The COMMAND line on the legacy system is unidirectional (from the computer to the peripheral).

    Here's my situation again hopefuly it's more clear this time:

    The Peripheral Emulator Software (which emulates a disk drive) running on the PC serves a legacy Computer (which is an 8 bit Atari by the way). That way the Atari doesn't have to use a slow real floppy drive and can have a much faster and larger capacity drive from where it can load and run software.

    The emulator software uses a COM port on the PC to communicate to the Atari and needs one control line - a line that has to be an input to the PC like DSR/CTS or RI - and the usual Rx and Tx lines for data transmission. The Atari has a proprietary serial port called SIO (Serial I/O) and uses a 13 pin connector with TTL level signals.  The Atari SIO also has Tx, Rx and one control line called COMMAND. That control line needs to be connected to an input control line of the PC's serial port, so that when the line goes LOW, it means the Atari wants to send a command and the Emulator Software has to listen. Atari SIO works one way, it is always the computer that initiates the communication and the peripherals only answer when addressed by the computer (they are intelligent peripherals and have device IDs and they don't communicate using interrupts or control signals, they only answer when they are addressed and they have to reply within allocated time-frames)

    So I built an interface cable which takes Atari's TTL level SIO signals and feeds them into an FTDI USB-to-Serial Chip (Rx to Rx, Tx to Tx and COMMAND to CTS). And that took care of connecting two computers and everything works fine.  Then I wanted to replace that cable with a BT link. My PC already has a built-in BT device and a BT stack, the Atari however doesn't.

    So I thought a LMX9838 would do the job as it offers a "Cable replacement" mode where minimum or no software support is needed. I thought I would interface Atari's signals to the chip and run LMX9838 in "Transparent Slave" mode and it would work like the USB-to-Serial cable. Well apparently not exactly...This works fine for Rx and Tx signals but has two caveats. First the LMX9838 UART uses input/output buffers and can not do flow control with the Atari as the Atari does not have CTS / RTS handshaking lines, secondly in Transparent Mode of operation there seems to be no way to relay the Atari's COMMAND line status to the PC. In LMX9838 UART's command mode there is a command called SPP_PORT_SET_RTS which sets the CTS line status on the PC's COM port at will, but I can not use the command mode as I don't want to re-implement the serial protocol on the Atari or introduce a middleman microcontroller into the design. I just wanted a pure and simple cable replacement where all signals from one computer is simply mapped to the corresponding signal lines of the other computer.  And the only way to do this with a LMX9838 seems to be to run the chip in command mode and have a microcontroller on the host side to interface the chip to the host, which is more than I bargained for.

  • 8 bit Atari!!!

    That is not a legacy computer, that is a museum piece. LOL!

    Your best bet would be to search the archives of Bits & Bytes magazine, i'm sure there was a hack to convert their serial port to standard RS232.  Other than that, I'm out of my league here.  Sorry.

  • True it's a museum piece but you would be amazed to see how many people are still using and enhancing them with various mods. Of course just for the fun and nostalgia of it. There is already a heck to connect the serial port of the Atari to RS-232 or VCP ports and it's called an SIO2PC cable. In fact I design and sell one version of it myself. Atari serial port uses TTL level signals so a chip like FTDI's FT232RL does the job easily and nicely.  Now my hope was to replace that chip with a BT counterpart. Maybe the one I chose (LMX9838) isn't the right one. I don't need a UART communicating to the Atari and buffering input/output data (which is the case with this chip), all I need is a BT device which will take Atari's signals (after some voltage level conversion from +5V to 3.3v, which can be accomplished by a few voltage divider resistors and a 3.3v voltage regulator) and send them to the PC's COM port using the BT transport. That's all there is to it. Maybe I should look for other type of BT devices which don't incorporate a built-in UART but simply have a BT radio to transmit and receive data. I am not sure if there is such a device but I will see. Thanks for the replies anyway :-)