I'm trying to get data from a mercury analyzer (Seefelder-Messtechnik Hg Analyzer 3000) that gives output to a 9-pin R232 serial port to my OSX 10.10 laptop.
I've followed the steps described here to install the PL-2303 driver:
http://pbxbook.com/other/mac-tty.html
The device manual (http://www.seefelder-messtechnik.com/V71-3-02-21e.pdf) lists the communication protocol as "9600 Baud, 8 data bit, 1 stop bit, no log,
no parities".
I attempt to read from the device by using the 'screen' command:
screen /dev/tty.usbserial 9600
The result is a string of seemingly non-sensical characters that print to the screen in a regular interval:
�8b4����b��8b48bs��8G�8b�8���8������8����< 8�8��b��KW��\b����8b����b� �b�b����KW�K �8b��\G�� �<���8�8b�"���[��؉���bG�3�ˁ�G��\K��[W�pb�8��8ʱ�\pa���ʁ�c t��8�h¡�38b�8�q�����\�8���bS�8b8�8�q���X��8��<��£8���2�8�����ؖ�ؖ�ؖ�8bS��\�܉�ؖ����[S�8��s���fq�8�����������8fq����������S�܊��b���b�؉����\���S��K���ݎ����S��b��b��S����S�\������KS��S�؊��\S�1S�\b�S�؉�\�ذ����KS�\����S����bS�؉�����1S�؊��[����ز������؉\���ز��\����i���$\�$���\��8���$��\�\����܂�زXk�B��7��\k�\X�<��8Xkz��Yj��L�������H�\���]j�،k:��Yj�؈��
I've also tried using 'minicom' rather than screen, and get a different ("?]???ܰ??Yk??2"), but also non-sensical result. I saw that there was another SO query similar to mine that remains unsolved: weird characters displayed during serial communication OSX
Any tips? It looks to me that I'm not interpreting the output correctly, but I don't know what to try next.
The solution was to read from the machine at a higher baud rate (~57600), despite what the manual and online reference said. Reading at 57600 baud made the result plain-text and usable. Thanks for your ideas!
I've followed the steps described here to install the PL-2303 driver
I've also had occasional electrical ground problems with Prolific USB-RS232 adapters. Problem would manifest as garbled data that looked similar to a baud rate issue or what you posted.
You can check if it's a ground issue by measuring for continuity between the ground pin (pin #5) on the DE-9 (aka DB-9) side of the Prolific adapter and the ground pin of the USB side (pin #4, "far left", of the A connector). You'll probably measure infinite resistance with a multimeter. Try the same with a FTDI USB-RS232 adapter, and instead I get a dead short between the ground pins as expected.
Be sure to plug the instrument's and PC's power supplies into the same power strip.
As a last resort try grounding the instrument's chassis/case with the PC using copper wire
Related
I am a beginner to arduino and trying to follow one of the videos from youtube to make a project- Master And Slave using HC-05 modules. I followed every step from that video carefully. Here's the link to the video ->
https://www.youtube.com/watch?v=BXXAcFOTnBo
For Slave Module when I type AT commands in the serial monitor nothing shows up.
I searched in Internet for the this problem and still didn't fix it. Here's What i have done:
tired restarting my pc
tried Changing arduino, At first i used arduino nano and then uno
I tried changing the baud rate to all other values and nothing happened
And there is no change in light blink, it stays on AT command mode until power is turned off and on again.
This is how is looks
Thank You For the Answer
Your problem is not actually related to arduino in any way. This tutorial is utilizing onboard USB->UART transceiver IC. So in theory you could even remove Atmel chip from the board. Its more like using module like this FT232 converter. Anyways sorry if I confused you but you can research the subject.
But anyways to the problem. Couple of questions:
Did you press reset button on module while powerin up the circuit?
Thats the way it enters to AT command mode
Did you try to reverse RX-TX lines, don't worry connecting these guys across eatch other doesn't harm your board.
(They are so often plugged in wrong..)
Did you make sure you have connected EN pin of module also. (To arduino 3.3V not 5V)
Did you triple check all connections
Try to upload simple Sketch like blinky to Arduino to make sure you are connected to USB-UART transeiver and you have correct drivers.
Make sure you upload empty sketch or remove the chip when you try to apply tutorial steps.
Change jumper wires. Sometimes cheap jumper wires are really bad quality.
I have been sometimes scratching head for long time because of broken jumper cable.
Please let me know if you have checked all of those so we can think for next step.
I'm in a situation where we are hooking up to a device that may speak a variety of different baud rates depending on model. Some of which may be non-standard, like 10000, but that's another problem for another day.
Ideally I could use Qt to auto detect the baud rate, but from my research that's likely not possible for a few reasons, which I'm okay with. However, is there any native Linux based method to auto detect the baud rate of the connected device? Even a 3rd party open source application could suffice.
Linux serial drivers don't support autobauding, because most hardware doesn't support it, because there's no agreement on how it might work. It's highly application-specific.
If you're using FTDI serial adapters, then most of them support the bit-bang mode, and you should use them as a digital oscilloscope in such a mode to get a bitstream that's very easy to autobaud on.
On other devices, the simplest way towards autobauding is to set the device to 2-3x the highest baudrate you expect, then treat the input data like a chunked digital oscilloscope, taking account of error bits, and use heuristics to detect the baud rate. It will succeed in a surprising number of cases, but you must get the statistical model of the data source right. I don't know of any pre-canned solutions for that.
Some additional kernel support could be had to better timestamp the input from the UART (whether hardware or USB) and thus decrease the uncertainity in your data and thus the number of samples you need to take to detect baud.
Some of which may be non-standard, like 10000, but that's another problem for another day.
No biggie. I figured it out 16 years ago :) This is the answer you're looking for. If you think that the API is sick as in very, very sick, then you'd be right.
Having a couple of issues with what I was hoping to be fairly straight forward.
I've been transmitting data from my PIC to a PC via RS232 at a baudrate of 115200. I've recently got a RN-41 bluetooth module and was hoping the switch would be as simple as powering the module and connecting the PIC TX (via a max3232) to the RN-41's RX, as the online community has led me to believe.
I'm able to connect to it and pair it to the computer, I'm also able to use PUTTY/Realterm to change the parameters, like the name and baudrate. Finally, by connecting a link to the RX and TX on the bluetooth module and powering it, I'm able to ping text by sending and echoing it using PUTTY, so I'm fairly sure the module isn't broken.
However, when I try to transmit my data from the PIC to the bluetooth module, and view it using realterm (which was working fine with the wired connection) I'm getting data received, but it's not what is expected. I'm expecting a packet of 25 bytes, with a header value of 2, I'm getting around 12-15 bytes and a header of -65.
The first value, -65, is always the same, and the other data can change, which really suggests a baudrate problem, but I've tried a variety of baudrates (changed in my UART code, the bluetooth parameters, and in realterm), and the data doesn't change at all; always wrong.
What have I missed? Anything I need to change in the Bluetooth configurations? I've also checked the parity bit, stop bit, etc, all the same as each other.
The problem was the MAX3232 circuitry. It was necessary for the RS232 connection I was using prior, but when I wanted Bluetooth, which required TTL signals, I was feeding it the same RS232 data!
Making a link straight from the PIC to the Bluetooth receiver solved this problem. Hope this helps someone else in the future!
I have a telephony modem which gives voice to my interfaced application via a serial USB ttyUSB0 in 16bit PCM 8000hz. I am able to capture this data and play with audacity. I want this port to be detected as a sound device in linux (I am on ubuntu). Is it possible? Are there any other options?
I'm guessing you are using a huawei 3G modem or something similar which gives ttyUSB1 for audio. Make sure you have the serial driver binded to it. Then simply pass the port itself as a "file" for input for any program of your choice.You need root access for that.You figured out the audio settings so it must be enough.I have voice calling working in UBUNTU 11.10 with Huawei. So let me know if i can help any further.
Ok, I see it's very old question but answers helped me to get a right direction so I decided to help others.
The one way to achieve (in addition to below) what are you are
looking for is to write dynamic kernel module.
Have it register as a sound device, and check that it has a GSM
module present (which module is it exactly can be recognized in
dmesg, lsmod, or output).
Then establish communication between user space representation as a
sound card and serial usb module.
The other way is to get module that you recognized by dmesg, lsmod and extend its functionality as a sound card.
All are tricky tasks because:
in the first case you have to resolve intermodule communication at the kernel level...... which is, lets say, a little hard even if programmer has a right background in subject.
the second case is hard in that you have to deal with:
USB stack (which is little unpleasant for human beings) and
sound subsystem (which is a little burdensome because of historical issues).
Without being an experienced kernel programmer there are small chances to succeed.
Hello there I am a newbie trying to prove the working of RS 232 Full modem and also one RS 422( RX,TX,RTS,CTS)
These 2 ports are on a custom designed board and I need to prove they are working.
I am able to confirm the working at register level but I need to prove the working using softwares like Minicom or any other custom program.
How can I prove the working of these ports from one PC to a different PC using DB 9 connections and LOOP BACK too
Can someone help me with this? Do I need to use any extra hardware to prove the working of this in Linux?
The most common type of serial port test is probably a loopback test. Create a test fixture that connects output pins of the port to the input pins (TX->RX, RTS->CTS, etc). If you do not have matching input pins for every output pin, you will need to do a three-way connection.
After you create the loopback, you will need to write software that exercises the pins. If TX and RX are connected, you can send a byte and verify that it was echoed back. For the control pins, toggle them and make sure the other side of the connection saw the transition. Make sure you exercise every pin of the serial port.
Note that you should run a TX->RX data loopback at multiple baud rates. It is possible for there to be a signal integrity issue in the design that only shows up at higher bauds rates. It is also possible for there to be a bad signal connection on the board that is masked by inductance and capacitance at higher baud rates. Therefore, it is a good idea to run a data loopback at the slowest baud rate, the fastest baud rate, and 1-2 in the middle.
Another thing you should do is a baud rate accuracy test. This will prove the clock driving the UART is running at the right frequency, and being divided properly. Transmit X amount of bytes at a certain baud rate and verify they arrived in the expected amount of time. To get an accurate number, you will need to bypass any buffering in the OS serial port driver (e.g. use direct register I/O), and make sure to accommodate for any start/stop bit overhead (see comments below).
However, a loopback test is not exhaustive. It only proves the device can talk to itself. The device may still have some flaw (e.g. voltage levels) that cannot be detected locally. So, you should also run some tests with external hardware. Cable your board to another system and run a test (e.g. with minicom). Make sure they can talk to each other.
Even an external communication test can miss something. You can still have poor signal quality from your board, but it happens to be good enough for the other device. To accurately verify the signal quality/timing, you need an oscilloscope.
While you are running communication tests, connect the scope probes to the various signals and verify the signal integrity. Make sure that voltage levels are valid, that you see clean low/high bit transitions, and that the timing of the data pin appears correct for the specified baud rate. (A scope can be a more accurate way to measure baud rate than the software-based method described earlier.)