Good Morning,
i'm trying to work out the reason to weird characters being outputted in a serial console in linux.
Device:
12d1:15c1 Huawei me906s module in a WWAN to USB adapter (working for normal operations and switches modes etc
The device is connected initially with the PID 15c1 and the output of lsusb -v below:
12d1:15c1 Output
When the device is sent the AT Command of AT^GODLOAD, it switches into download mode which changes its PID too 1568. Output of lsusb -v below:
12d1:1568 Output
OS:
Ubuntu 16.10
Speed:
9600 baud as reported by stty -F /dev/ttyUSB0
Expected: Send AT Commands through /dev/ttyUSB0 with minicom or echo/cat
Result and Description:
When the device is in normal mode (15c1) the device ttyUSB0 is used to send AT Commands, this works perfectly and we can set the chip into download mode (PID 1568)
After Download mode is enabled the chip reboots and reconnects too ttyUSB0, however weird characters show up in minicom and through terminal using 'cat
The weird characters are the same in both monitors and the hex is:
7e 03 00 06 9e 4c 7e
When we send any AT command in download mode the characters show up, except for one AT command as shown in the pictures. This command is significantly larger than any other ones.
Command examples which don't work in GODLOAD:
AT+CMGR?
ATI
-Results in the weird characters ~[][][][]L~
Command which does work:
AT^SIGNVER=5,0,1234567891011121314151617181920, 8502
We have used wireshark to capture the update process on a windows machine.
I actually have screen shots of the operation, commands etc but cannot post them due to limit.
Questions:
-Does the packet size matter for serial commands sent to the module?
-Are we missing some form of a line ending, carriage return or termination to start/end the message correctly?
Thanks for your help in advance
Related
On an embedded Linux system running Busybox I am trying to receive bytes over a serial port and echo back everything received.
The system setup is like this:
Linux <-USB-> FTDI chip <-UART-> MCU
On the UART line I have a logic analyser monitoring the data between the FTCI chip and the MCU. Both the MCU and Linux have the same UART configuration.
The script I have written runs on the Linux system and is supposed to send back all data it received from the MCU.
So far I have this simple Bash script which is to receive bursts of data 62 bytes long. The timeout is set to 5 seconds as a sort of alive signal.
#!/bin/bash
# Enable debugging
set -x
# Set the baudrate of the port
stty -F /dev/ttyUSB0 1500000
while true
do
# Read 62 bytes with a timout of 5 seconds to variable RESP.
read -N62 -t5 RESP < /dev/ttyUSB0
# Print out how many bytes we received
echo ${#RESP}
# Send back the data, -n for no trailing new line
echo -n $RESP > /dev/ttyUSB0
done
There are a few problems I have with this script:
Not all bytes are received consistently. I've been testing now for some time an only seen the full number of bytes once.
It outputs only 0xFF values on the UART bus, this is observed through the logic analyser.
What am I missing here in order to receiving the correct data and send it back correctly?
Through the suggestions made by #sawdust I was able to get a working script.
In the end I stopped using the read command. I was unable to get it to work in raw mode. I could not use termios as this in to available on my Busybox system. I got a working setup using dd:
#!/bin/bash
stty -F /dev/ttyUSB0 raw
stty -F /dev/ttyUSB0 1500000
dd if=/dev/ttyUSB0 count=62 of=/dev/ttyUSB0
I have a Raspberry Pi 4 with speakers connected to the 3.5mm jack. I have no HDMI connected, but I have the standard 7 inch monitor connected. It runs raspbian.
Edit: I found out that this was normal behaviour due to an OS update, se my comment below.
If I run amixer cset numid=3 1 I get the error amixer: Cannot find the given element from control default.
If I run amixer contents there are no numid=3, I only get:
numid=2,iface=MIXER,name='Headphone Playback Switch'
; type=BOOLEAN,access=rw------,values=1
: values=on
numid=1,iface=MIXER,name='Headphone Playback Volume'
; type=INTEGER,access=rw---R--,values=1,min=-10239,max=400,step=0
: values=0
| dBscale-min=-102.39dB,step=0.01dB,mute=1
So PCM playback route with numid=3 is missing, and 1+2 say Headphone instead of PCM, that is the normal as far as I can tell from the interweb.
I can still play things with aplay and omxplayer (I'm not sure if it is mono or stereo).
But some other things fails, which I thought might be because of this. If I run espeak, and similar with pyttsx3 in python, I get screens full of errors, a few of the lines are:
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.front
Cannot connect to server socket err = No such file or directory
jack server is not running or cannot be started
And that is what I actually would want to get to work.
If that is caused by the first error I don't know. But when I search for rPi sound problems, the cset-numid=3 "solution" seems to appear everywhere, and I can't use that...
Edit: So that turns out not to be the reason, the espeak problem is still there even if I revert to the old way with options in boot.txt.
I needed three days to find out how to use it on Raspberry Pi. I created an Shell Command. When you want to use Audio via 3.5mm Jack just write. You can let the HDMI Cable connected.
sudo bash -c 'echo -e " defaults.pcm.card 1 \ndefaults.ctl.card 1" > /etc/asound.conf'
if you want to use the HDMI Audio output just change the number 1 to 0.
sudo bash -c 'echo -e " defaults.pcm.card 0 \ndefaults.ctl.card 0" > /etc/asound.conf'
I have software for communicating with a serial device that only runs on Windows 7. My host machine is running Ubuntu 16.04, with Windows 7 in virtual box.
I've managed to set it up using USB device filters in VirtualBox settings so that Windows sees and can communicate with the device.
However I'd like to capture what's being sent to and from the device. I thought something as simple as cat /dev/ttyUSB0 would work but unfortunately when I start VirtualBox I get this in dmesg:
[31199.465270] vboxdrv: ffffffffc0df4020 VMMR0.r0
[31199.653494] vboxdrv: ffffffffc0ef7020 VBoxDDR0.r0
[31199.710573] VBoxNetFlt: attached to 'wlp1s0' / 98:54:1b:04:13:48
[31199.863579] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[31199.863674] ftdi_sio 1-3:1.0: device disconnected
So I don't know which file to monitor in /dev anymore. I suppose I might be able to try listen for the communication from Windows, but if I can I'd like to know if it's possible to monitor it from my host machine.
Edit:
This answer helped me for a start. I now get some cool looking stream on the terminal, next step is deciphering it, or if anyone has a better way I'm interested - it looks like the person who answered that question still has deciphering it as a TODO :-)
The fact that it was communicating with software in VirtualBox didn't really matter. This answer got me most of the way just by (as root):
modprobe usbmon
cat /sys/kernel/debug/usb/devices|less and search for device
cat /sys/kernel/debug/usb/usbmon/7u where 7 is the number from "Bus=" in the device table from step 2
From there is was just filtering the output.
A basic way could be just
cat /sys/kernel/debug/usb/usbmon/1u |cut -d\ -f9- | grep ^\n
But the device I was working with was constantly sending lines with just 4 characters, to filter out those I got the address word from the output line, and grepped for that. In my case I only wanted to capture "C" or callback output. I was also filtering for lines that contained more than just the default "0160" that the device was constantly outputting. To try understand the hex output I put a xxd -r -p at the end which gave me:
cat /sys/kernel/debug/usb/usbmon/1u | grep -e 'C Bi:1:005:1\s0\s\w*\s=\s0160\w' | cut -d\ -f8- | xxd -r
Where the grep is
grep -e 'C <address> <someotherstuff> = <always-output-string><anycharacter>
This still gave me this indecipherable junk below, but I don't know the format so I'm stuck here. Maybe the steps to read and filter will be useful for someone
>
O�UDQN��RG_JAMS142E DEFAULT0XXXXXXX�lSTz:�RSDU�vy��������������������������z�fff=�����{6zC"z�u6zC�z�H
;�����C��Af[���RSC�b ISD�EGIN
�CG_IEW0321:0407JUN12S��Z-�$''$'''C'''
I am start learning Linux(CentOs 5.5 kernel 2.6.35.13).
When I try to install a usb wifi stick(TP-Link TL-WN823N,and "lsusb" will show ID 0bda:8178 Realtek Semiconductor Corp..)
It work fine in the window interface( ctrl+shift+F7).
But when I shift to the command window(ctrl+shift+F1),and try to start wifi connection by
wpa_supplicant -Bw -Dwext -iwlan0 -c/etc/wpa_supplicant.conf
I found it kept print logs to screen before I type the command above.
I use
ps axjf |grep wpa_supplicant
to list all related process and find
there is a process start by user "dbus" with the command
/usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log
I dont know whether is this dbus' command that lead the problem.
Below is the screen shot.
kept logging msg:(
Partly fix the problem.
There are two things that make the wifi information keep on loging on the screen.
First, if you use NetworkManager, it will automate run the command under /etc/sysconfig/wpa_supplicant, where you can find the default command write there has no -B parameter which will keep the log in the background.So you can either add an -B to that command or stop NetworkManager and start wifi connection with your own command like in the question.
Second, when you install the driver, the default run status is power saving mode, so when you transfer data with wifi, you can see the screen keeping log infomation like "get into the pw_saving","get out pw_saving" etc.
To fix this, you can shut down the power saving mode like this:
create a file /etc/modprobe.d/8192cu.conf with the following contents:
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
Or you can rewrite driver code to stop print the info to screen, which I still don't know how to do.
I am trying to access a device which is attached to a USB-serial port. The settings are 57600 baud, 8 bit, 1 stop bit, no parity. The device outputs a status line every second and accepts typed commands.
I would like to use GNU screen to initiate 2 way communications, so I am using this command:
screen /dev/ttyS2 57600,cs8
However I just get a blank screen, nothing received from the device.
The communication is fine using teraterm, and I can also do this
stty -F /dev/ttyS2 57600 cs8
cat /dev/ttyS2
to see the status output from the device.
I've tried various combinations of ixon, ixoff, crtscts, and clocal but nothing makes any difference.
How can I determine what the correct command should be?
I am using Cygwin on Windows 10.
I faced the same issue with gnu-screen, I started using plink.exe instead from the PuTTY suite. It's not optimal, but it does the job. In my case serial is just for recovery, not for everyday usage.
Start PuTTY, create a profile with your serial connection.
Name and save the connection.
From cygwin, run: '/cygdrive/c/Program\ Files\ (x86)/PuTTY/plink.exe -load SerialProfile'