I'm trying to connect to a STN1110 chip via screen. Unfortunately I only get strange characters as response.
My understanding is that this is due to the wrong baud rate. I tried several baud rates I could find for STN1100 (9600, 115200, 38400) but none of them work. Am I missing something?
Thanks as always for your help.
It seems like I found the solution. Screen was not the problem and the baud rate 9600 was the right one. After checking the wiring (thanks to a tipp from a budy of mine) we noticed that the ground of the ttl to usb adapter was not properly connected to the STN1110. After I fixed the ground everything worked fine.
To use 921600 I did the following:
$ setserial /dev/ttyS0 port 0x3f8 uart 16550A baud_base 921600
$ stty -F /dev/ttyS0 921600
Then brought up "putty" and set the baud rate to 921600 connected to /dev/ttyS0.
Then executed an ST command:
st sbr 921600
Seems to work.
connect via rs232 set br:9600 (default)
and to show all program protocol
atpps
if want to new br:38400
atpp 0c sv 68
atpp 0c on
atz
the new connection are br:38400
Related
I'm trying to send files over a half-duplex interface (RS-485) between a box PC running debian (4.19) and a SBC with an im6xDL.
Thanks to this community I can successfully transfer simple data between the units using picocom or by echoing/reading.
The box PC supports half-duplex RS-485 natively and has automatic RTS functions so that you can read/send data without any issue. The SBC on the other hand needs to be toggled to change into RX or TX mode.
This turned out to be a problem when I tried to send files from the box PC to the SBC.
On the box PC:
picocom /dev/ttyUSB0 -b 9600 -fn
C-a,C-S
***file: /home/user/test.txt
Transfer incomplete
*** exit status: 128
On the SBC
picocom /dev/ttymxc2 -b 9600 -fn -et
C-a,C-r
Terminal ready
�000000
As you can see something is terribly wrong, it is like it cannot interpret the bits when a file is being transferred.
My questions:
Is it possible to send files from the command line in half-duplex systems? (The SBC needs to be in RX mode the entire time).
Is there another way to achieve this that is more intuitive?
As always, thanks for the help and support :)
/W
See here:
Pymodbus - Read input register of Energy meter over rs485 on uart of raspberry pi3
The solution I presented there using pylibmodbus should work for any hardware with UART and one or two GPIO lines accessible from user space in Linux.
If, on the other hand, what you want to do is use something like picocom or minicom then you can take a look at the hardware-only solution using a 555 timer.
Of course, if prototyping circuits is not for you, you can always buy a USB to RS485 with half-duplex support. You have many available but those based on the MAX13487 IC seem to work very well.
EDIT: The solution using the 555 timer is not in the post I linked above but here together with some more background material on half-duplex RS485 links: RS485: Inappropriate ioctl for device
Ubuntu 16.04 & MATLAB R2017a.
I'm trying to set serial port like that:
s=serial_port('/dev/ttyUSB0','BaudRate',115200,'DataBits',8,'InputBufferSize',80000)
It's working fine, but when I try to change baud rate, say 1000000.
I got this message:
Open failed: BaudRate could not be set to the specified value.
So, I have 2 question:
1) Is it possible to set not common baud rates, say 2000000?
2) I found, that 1500000 and 3000000 is working for me.
Is there maximum speed?
** UPDATE**
I know how to change the baud rate in OS, in my case (Ubuntu 16.04)
setserial is not working, so I'm using sudo stty -F /dev/ttyUSB3 3500000 (not all speed is allowed) or via asm/termios.h> -- all speed is allowed.
So, I'm using second way.
After that, I can easily listen the port like that cu -l /dev/ttyUSB0
And at the same time I cant set the speed in matlab.. (Error above)
Although this link should provide you enough information about how to manage baud rates on Matlab side, as #Cris Luengo already stated in his command, I would like to elaborate a little bit on the hardware side of the problem.
Using the following command:
stty -F /dev/ttyUSB0
you should be able to retrieve the current baud rate of the targeted device. Alternatively, the following command also retrieves that value:
setserial -ag /dev/ttyUSB0
together with other important information:
/dev/ttyUSB0, Line ..., UART: ..., Port: ..., IRQ: ...
Baud_base: ..., close_delay: ..., divisor: ...
closing_wait: ..., closing_wait2: ...
Flags: ...
OS side, you can play with the baud rate of some devices but if you want to avoid problems, you always have to set a coherent value when establishing a connection. Generally speaking, devices have a tolerance level (of, I think, no more than ±5%) on overspeed and underspeed concerning baud rate deviance... so you can try to force an arbitrary baud rate different from the current one, but you don't want to go too far from it.
I have an devive blasting some data continiously into an FTDI that's connected to my PC over USB. I want to log the data into a CSV using a simple bash script.
When I cat /dev/ttyUSB0 I'm getting some characters that I want (1023) and also some malformed random character.
How does the phy reciving the data know the baud rate?
Where are the malformed packets coming from?
Running: Debian GNU/Linux 8 (jessie) 64-bit
Screencap of output
You can set the baud rate using stty. For example to set the baudrate to 9600 do:
stty -F /dev/ttyUSB0 9600
This could because ground has not been connected between the devices. Loose connections. Noise if you use long serial wires. There could be many reasons.
I have a Ti processor AM335x on a dev board. right not there are two uart connect to processor. uart0 and uart2
by default, only uart0 was enable, and it was for console. after I enable uart2, I wired my GPS to it so that it should output something if I cat /dev/ttyO2. but there are only some garbage code shows up.
then I wired GPS to uart0, use same command cat /dev/ttyO0 everything works fine. GPS output shows up normally.
then I edit my uEnv.txt to switch my console to uart2, it works. and then I wired GPS to uart2, I can cat /dev/ttyO2 to get everything. But when I wired GPS to uart0. garbage code shows up.
I did use stty to do tty setup, make them all same, still, I can only read from the uart which I connect my console.
I run command dmesg | grep tty , this is the output
[0.000000] Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0 rw ext4 rootwait verbose debug
[0.234749] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 154m, base_baud = 3000000) is a OMAP UART0
[0.235338] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 155m, base_baud = 3000000) is a OMAP UART2
[0.824084] console [ttyO2] enabled
first and fourth would change base on which uart I put my console on.
Are there any config I missed? why I can only read precise data from the uart I put my console on. and others doesn't work.
any idea would help. Thanks.
This is how I change my code to enable uart2.
linux compile for enable uart2
It turns out that is BAUDRATE problem.
not because I didn't setup right, is because a hardware problem. as soon as I connect my GPS to uart2. the uart2 baudrate would change to 9600 and that gives me garbage output.
if I stty setup the baudrate to 115200 and start read. THEN connect my GPS. I get everything I need with correct format.
Still don't know what issue with GPS, but that's shouldn't be part of this question. so I will close this.
Thank you, #domen without you I won't double check that baudrate.
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