So I'm trying to revive an old (late 90's) noise logger (Acoustic Research Labs EL-215 for those familiar) and I've been looking into USB-RS232 connectors. I have port settings from the original documentation which are as follows:
EIA RS-232-C
1200 - 19200 Baud
8 Data Bits
2 Stop Bits
Hardware Flow Control
(note: parity isn't specified)
I have an old Belkin F5U109 adapter, which hasn't worked so far - so I'm trying to work out how the Belkin is different to other USB-RS232 adapters. I also read that Prolific PL2303 and FTDI seem to be the leading USB-RS232 chipsets that nearly all modern USB-RS232 adapters seems to use.
What features should I look for in an adapter to give me the best chance of making it work with my hardware? Whats the main difference between the Prolific and FTDI chipsets?
I don't care which operating system I need to use as I'm proficient in Linux and can easily spin up a VM with VirtualBox or qemu if need be. Hardware uses DOS software, so could also run dosbox if required. Worst case I can reverse engineer the whole thing and write my own program to communicate with the EL-215, but I'd rather avoid that!
Any help much appreciated!
Edit: Here's what I've tried so far
That link seems to suggest that software flow control (XON/XOFF) doesn't work. I've investigated the device in trying to connect to and found that DTR and DSR are not connected, but RTS and CTS are. When I run the DOS software (through Windows XP on a VirtualBox VM, Belkin drivers installed, COM1 8,2, hardware flow control, no parity) which is supposed to connect with the device, I get connection error - it times out waiting for response from device.
I put the multimeter on the pins of the Belkin while using the DOS software. DTR goes from -9v to +3v momentarily, as does RTS. Obviously DTR is ignored by the device because its not connected, so RTS going high should trigger a CTS response from the device but it doesn't.
So I thought that the Belkin is perhaps waiting for DSR to go high before doing anything, so I bridged DTR to DSR, but still no response. I found it strange that DTR only momentarily goes high as if properly implemented it should stay high for the entire duration of the connection.
It's either the Belkin logic levels are not high enough (I think RS232 needs >3v to trigger) or it incorrectly implements hardware flow control. Belkin information about the adapter refers to connecting a PDA so maybe its a specific implementation for those devices...?
I have ordered FTDI and Prolific PL2303 adapters in the hopes that they might work better. Backup plan is to build a circuit to control RS232 pins individually with like an Arduino or something.
Related
I am involved in a project where we have some kind of IoT device. An nxp processor with an LTE modem on a PCB. The software running on it connects to the modem over a single uart interface. It will initialize the modem through AT commands, and finally made a data call to the provider (PPP).
Then, it uses lwIP (light weight IP) to open some mqtt subscriptions, and allow user code to make http get/post requests to our servers.
Every 15 minutes we want to retrieve signal strength from the modem and report this back to the server. What I do now, is put the modem back in command mode, retrieve the signal strength info, go back to data mode, and resume normal operation.
The round trip from data mode, to commando mode, and back to data mode takes several seconds (4-5 ish). This is annoying, because during that time we are not receptive for commands.
I've read about gsm mux 07.10. By following some defined protocol it allows to create virtual serial ports, over one physical uart. That sounds nice, although I realize this will go at the cost of performance (bytes will be added to each frame we send to either command mode / data mode).
The gsm mux 07.10 spec dates from 1999. I am far from an expert in mobile solutions. I was wondering: is muxing still the way to go? How does a typical smart phone deals with this for example? Do they include modems with more than one uart to have parallel access to AT commands and a live internet connection? Or do they in fact still rely on gsm mux?
If somebody would be so kind to give some insights. Also on potential C libraries that are available that implement gsm mux 07.10? It seems that TinyGSM implements it (although I can't seem to find where), and I also can find the linux kernel driver that implements gsm mux 07.10. But that driver is written on top the tty interfaces in linux, so that would mean I would have to reverse engineer the kernel driver and strip out the tty stuff and replace it with my own uart implementation.
First of all, the spec numbering is the old GSM specification numbering, so those old specs will never be updated, the new specifications with new numbering scheme will. I do not remember when the switch was made, but I do remember someone at work giving a presentation on 07.10 probably around 1998/1999, so probably a few years after that or around that time (and definitely before 2009).
The newer spec numbering scheme uses three digits for the first part.
So for instance the old AT command spec 07.07 is now 27.007, and the current 07.10 multiplex specification is 27.010.
The following is what I remember of 07.10.
The motivations for developing 07.10 was to exactly support the kind of scenario that you describe. Remember back in the mid 90's, if mobile phones had a serial interface then that was RS-232 though each manufacturer's proprietary connector at the bottom of the phone. One single serial interface.
However, in order to use 07.10 mux in serial communication you needed to install some specific serial drivers in Windows with support for 07.10 (and I think maybe there was some reliability issue with them?), and for that reason 07.10 never took of and became anything more than an rarely used solution.
Also by the end of the 90's additional serial interfaces like Bluetooth and IrDA became available on many phones, and later USB as well, which both added additional physical interfaces as well as natively multiplexing within each protocol.
So the need for multiplexing over physical RS-232 became less of an issue, and whatever little popularity 07.10 ever had dwindled down to virtual nothing.
Fast forward a couple of decades and suddenly someone asks about it on stackoverflow. Good on you :) As far as I can tell I cannot see any fundamental problems with using it for the purpose you present.
Modern smart phones that support AT commands will most likely have a code base for the AT command parsing with roots in the 90's, which most likely include the AT+CMUX command. Of course manufacturers today have zero explicit wish for supporting it, but when it is already present it will just come along with the collection of all other legacy AT commands that they support.
So if the modem supports AT+CMUX you should be good to go. I have no experience or recommendation with regards to client protocol libraries.
I have a fairly complex project done on Arduino2560, which I want to port to a standalone Atmega328. My problem is that one feature in the project is that it can communicate with my computer via serial (I made a C# program to handle it on the computer side, using the COM3 port). However, Arduino uses the USB communication for a virtual serial port, and I got a bit confused about how it could be done for the Atmega. It has the RX-TX lines, but what's next? Maybe use some serial-USB converters? What's the best approach for this? Is there anything I should be careful about?
Thanks.
Considering you mention a specific port COM3 on your computer I guess we can assume you have a native RS-232 port (one of those with the sub-D9 male connector that we were used to in the old days but are not so common anymore).
If that's the case, then you can get an RS232 level shifter. You'll just have to make the connections to RX, TX, Vcc, and GND and this device will change the RS-232 voltage levels to whatever your board requires (most likely 5V or 3.3V). Some (maybe most) high-end development boards include this kind of level shifter so maybe check yours in case you already have it (if you do you'll probably see a MAX232 IC somewhere). Or if you are crafty you can also DIY.
If you prefer to connect to a USB port (then, of course, it won't be COM3unless you explicitly change the configuration on Windows Device Manager) you can go for a USB-to-serial adaptor. On that front, you have many choices, starting from the cheapest at maybe 5$, but I'd rather choose one based on the FTDI chip, which is nowadays quite ubiquitous and has proven its reliability. This one is a good example, and at the same cost as the level shifter.
Now, are there any differences between using the native RS-232 or the USB adaptor? The answer is, for most practical purposes, no. If you go to the fine details, like buffer sizes, there will be differences, but if you need to go there you'll need to study the details in both cases to see if the port you have (or the one you're planning to add) meet your needs. For most scenarios, I would choose the USB, if only because you have it everywhere (most laptops don't have a native RS-232).
All of the above (based on RS-232 and/or USB) will work fine for cables running up to 5 meters (~15 ft.) for USB or maybe 10 to 15 meters (~30-45 ft.). This should be enough for most hobbyist or at-home projects. If you want to run longer cables you'll have to go for something like RS-485.
If you choose now the USB adaptor and you think you might need to relocate your board in the future to end up more than 20 meters (15 of RS-232 + 5 of USB) away from your computer just make sure your adaptor includes a TX Enable signal (TXEN). Most adaptors based on the FTDI chip will have this signal on a pin (like the one I linked above), and that will make your life way easier if you want to use RS-485 on a two-cable half-duplex bus.
EDIT: based on the feedback below there is new info that deserves a quick update.
First, you don't have an old school RS-232 port on your PC and second you have to design the connection on the microcontroller's side.
With that in mind it's clear you have to go for the USB solution. But you need to choose if you shift both sides to RS-232 levels or you stay at TTL. That decision depends again on the length of your bus. If it'll be really short (up to 2 meters) then you can stay on TTL, otherwise better shift to RS-232 to be on the safe side. There are many people who will tell you they have much longer serial links but how reliable they are you'll never know.
Since you have to design the board, I guess it makes sense to integrate the MAX232 and a sub D-9 connector there and get the cable you mentioned for your PC.
Or, you can add only a connector on the board and get the Sparkfun level shifter I linked above for the micro's side plus the same USB to RS-232 for your PC.
I have a Microsoft Surface Book that I've dual booted Linux Mint on. I'm writing a program that needs to read in data from a serial port, but my serial ports don't seem to be working. The behavior is consistent across Mint and Windows (Testing done through Cygwin). It gets a bit of data the first 2-5 seconds that the device is plugged in (viewing the data through screen, same thing happens if I just use pyserial to print data incoming from serial port), then nothing.
What could be happening? I think I've isolated the problem to the serial ports - the Surface Book has 2 USB ports and the same thing happens on both of them, and I've tested the hardware that I'm plugging into it on 2 other computers (One Linux and one Mac OS), and it works fine on both of those.
Your MS Surface, seemingly, has a yellow triangle exclamation mark icon (over the adapter icon) without any driver to install/download. And properties in the device status box window say This device cannot start. (Code 10) or A device which does not exist was specified. Right?
If it's so you should wait for an update from MS. It's notorious problem.
I ended up getting the computer replaced on warranty for an unrelated issue months later, and what do you know, on the new computer the serial ports work fine. That indicates to me some sort of hardware problem, given that the issue persisted across OS's.
maybe this will help:
see Arduino examples for serial port communication - search google:
arduino serial c++
arduino serial c#
arduino serial c++ linux
the point is to open port properly you need to open a file, not a port. not with usual c - assembly write to port code.
another option you are using an unintentionally bought fake USB to serial cable with a Fake PL2303 chip
then you need to install the old version of the driver.
search in google:
Fake PL2303 + your os name:
install driver Fake PL2303 windows 10
another option is maybe it conserves energy and closes the port because it feels it is unused.
in windows> device manager,> properties of a device - usually USB root hub > power management - allow the computer to turn off this device to save power - uncheck it.
https://superuser.com/questions/408683/why-my-usb-mouse-gets-suspended-after-3-seconds-of-inactivity
https://blogs.msdn.microsoft.com/usbcoreblog/2013/11/08/help-after-installing-windows-8-1-my-usb-device-doesnt-charge-or-it-disconnects-and-reconnects-frequently/
also, you could look in windows events - to see what happens. usually, failures like this are registered in the events log.
an unlikely option is it consumes too much current, like a short circuit. and the device protection circuit shuts the chip off. also probably it does not have such circuit. one possibility is to try with an external powered hub.
the most probable of these is the power saving mechanism
I was experiencing the same problem - came across the solution on another site. The USB 3 ports on Surface Book aren't compatible with something or other to do with Com Port but running the device through a cheap USB hub solved my problem straight away and it was instantly recognised by the Arduino IDE
I am trying to connect ATmega128 uart to PC using USB-to-RS232 converter so that PC can receive and transmit data from microcontroller using hyper terminal. I set the correct stop bits and baud rate in hyper terminal. It doesn't seem to work.
Can any one tell me if this is possible by USB-to-RS232 converter and if not what other options are there for serial communication between PC and microcontroller ?
You should be able to do this without any issues. I'd suggest putting your USB-to-RS232 cable in loopback mode first (if possible) to ensure you can communicate, then connect it back up to your MCU.
If you aren't seeing what you expect the first thing to look at are the settings, specifically the baud rate. Since your USB-to-RS232 cable is from a third party vendor I'd assume that your settings on the host side are OK. So you should look in to your MCU code to ensure that all your clocks are running at the proper speed and you have indeed performed the correct calculations to achieve your desired baud rate. Debugging here to ensure you are transmitting data out of the device is important.
Additionally, there are tools that can help you debug. Portmon is a tool from Microsoft that lets you look at the serial data path on the host side. I'd also recommend a USB analyzer, such as an Ellisys, that will allow you to view data going across the line from your MCU to the host.
I had a PC connected to a PLC (Mitsubishi Q Series) via a USB2RS232 cable. The cable was plugged into the PC side, which was then plugged into a Serial cable and then into the PLC. I hade the baud rate set to 19200 and everything worked fine.
My problem was that every now and then the PC would blue screen on me. When I checked through the dump files the problem seemed to be related to the driver for the USB2RS232 cable (ftdi). I update to the latest driver but still bluescreening (Pc was running Windows 7).
Anyway I replaced the PC with another which had a dedicated RS232 port. Now I keep getting communication issues which is indicated by the response by the PLC. Just by chance I lowered the baud rate down to 9600 on both the PC and PLC. The issue seems to have gone away.
My question is why would removing the USB2RS232 cable cause me to have to slow down the communication? Both devices can communicate at speeds greater than 19200 and I would have thought going from serial port (PC) to serial port (PLC) with a serial cable would be better.
EDIT: Problem maybe solved - still testing
Thanks to some of the input from you guys, I may have solved the problem. Here are the following points I went by to get the speed back up to 19200 when using straight RS232 to RS232.
Even though no noise was detected on the equipment, a shielded cable was used.
The PC program would wait 100ms between sending data to the PLC. I read somewehere that 100ms is a good approx for PLC scan time.
RS232 Communication between modern PLCs and modern computers is often a hassle. These are some things I look at what it's not working:
The cable. Lots of cables are nonstandard, and have nonstandard internal jumpers and whatnot that can increase error rates and lower throughput. It is possible that your USB converter is more advanced and is autodetecting something with your cable and compensating for it.
The OS on the PC. Windows versions newer than Windows 98 don't seem to have the best support for serial communications.
Interference. Be especially careful of drives near the comm line. If you are using unshielded cables, a drive that runs intermittently can cause exactly the problem you describe, where you get an intermittent failure, but no noise at all whe the equipment is idle and you go check.
From your description I would guess that you have your equipment in a "noisy" environment - judging from the previous blue screens and now the issues with a regular RS232.
Have you tried to run the setup elsewhere with same hardware but other environment?
See if you can get a better isolated serial cable and/or use an EMF-meter to measure electric/magnetic fields around your setup.
Also worth to check out would be to put in another RS232 card in the PC to see if you have issues there, it could be that you had bad luck and the RS232 has broken.
Edit
Are you sure the speed is higher than 9600 with the USB converter? maybe it has negotiated down the speed? (disclaimer: not sure what brand you are using and how intelligent it is).