While following the instructions on Get Started with Edge TPU Dev Board, I can't get past Step 2:
$ screen /dev/ttyUSB0 115200
The issue is that screen immediately returns
[screen is terminating]
I have verified the contents of /etc/udev/rules.d/65-edgetpu-board.rules, verified the dmesg output, tried different USB ports, verified that all screen instances are closed, etc.
Solution = run screen command with sudo:
$ sudo screen /dev/ttyUSB0 115200
First you should flash your iptables
Coammands:
sudo iptables -F
mdt devices
Related
$ lsusb
Bus 001 Device 014: ID 12d1:14fe Huawei Technologies Co., Ltd. Modem (Mass Storage Mode)
$ gammu-detect
; Configuration file generated by gammu-detect.
; Please check The Gammu Manual for more information.
[gammu]
device = /dev/ttyS2
name = Phone on serial port 2
connection = at
The modem is detected as mass storage. I want the modem to be detected as Modem/Networkcard
I have searched and tried and finally this worked for me
Solution 1:
- /etc/mode_switch.config and turn on the following flag:
DisableSwitching=1
Go to following folder and create the 12d1:14fe file
$ cd /etc/usb_modeswitch.d/
$ sudo tar -xzvf /usr/share/usb_modeswitch/configPack.tar.gz 12d1:14fe
Edit 12d1:14fe file and add following lines and save it
DefaultVendor=0x12d1
DefaultProduct=0x14fe
TargetVendor=0x12d1
TargetProduct=0x1506
MessageContent="55534243123456780000000000000011062000000100000000000000000000"
If you remove the USB dongle and reconnect it. You have to run following command to bring it back in modem mode
sudo usb_modeswitch -c /etc/usb_modeswitch.d/12d1\:14fe
To auto detect the USB dongle as modem when it is connected then set following rule
sudo touch /etc/udev/rules.d/huawei_e3331.rules
Then create add following rules to file and save it
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14fe", RUN+="/usr/sbin/usb_modeswitch -v 0x12d1 -p 0x14fe -V 0x12d1 -P 0x1506 -M '55534243123456780000000000000011062000000100000000000000000000'"
$ gammu-detect > .gammurc
$ sudo gammu-detect > .gammurc
$ gammu identify
Device : /dev/ttyUSB0
Manufacturer : Huawei
Model : unknown (E3331)
Firmware : 21.146.07.01.158
IMEI : 869************
SIM IMSI : 412************
$ echo "test" | sudo gammu sendsms TEXT 070*******
you will receive a test message
First of all, make sure that your mobile card has 3G permission, that is, 186 mobile phone number, and other 2G mobile phone numbers can also have 3G permission;
Anyway, it is the Unicom card of Waupaca brand;
Second, isn't there a PC Suite in the software of connecting the mobile phone to the computer? In the middle of the software installation, you will be asked if you want to install the driver, which must be confirmed. After that, if you uninstall the software, you can version it, but you can't uninstall the driver;
Connect the phone cable to the USB port of the computer. There will be an Android adapter in the computer manager, which means the driver is installed;
When the mobile phone is connected to the computer, it can't turn on the U-disk mode;
Run daily up for Android on the computer... Just click Connect right
It takes a lot of traffic
EDIT: This problem is solved! the problem was a script running on the pi, which occupied the SCL pin (in my case a script listening for a shutdown button). So it was not able to read the rtc.
I'm currently following this tutorial to connect my Raspberry Pi Zero W running Jessie Lite to the RTC DS1307.
The rtc is being recognized when running sudo i2cdetect -y 1 with "UU", so everything fine until this point.
But when entering sudo hwclock -D -r I'm getting an error:
Does anybody have any experience or hints with this error? I was researching for 1 1/2 day now, but could not find a working solution. Any help is appreciated.
Back then I was not able to answer my own question. I have already edited the main post, but to close this question:
This problem is solved! the problem was a script running on the pi, which occupied the SCL pin (in my case a script listening for a shutdown button). So it was not able to read the rtc.
I bought a Raspberry Pi 3 Model B, a microstack baseboard and a microstack GPS.
I followed the instructions written in the official documentation but I can't connect to the GPS.
Basically, the GPS led flashes so it means it has find a gps fix, but I can't see any data from the PI.
For example, if I try
cat /dev/ttyAMA0
I get always nothing. I already used raspi-config to disable kernel serial and to enable i2c and spi.
Also if I try
stty -F /dev/ttyAMA0 ispeed 4800 && cat </dev/ttyAMA0"
I get an error.
Anyone has any advice, please?
Or maybe these modules are not compatible with Pi 3?
Thanks a lot!
It's hard telling what has been done, or not done. The 'official' documentation from Microstack provides two methods of setting up the serial port. It then continues with
Automatically Starting gpsd
To automatically start the gps service when the Raspberry Pi® boots, reconfigure the GPS
daemon by typing into a terminal
sudo dpkg-reconfigure gpsd
● Choose <yes> when asked if you want to start gpsd automatically.
● Choose <no> when asked “should gpsd handle attached USB GPS
receivers automatically” .
● When asked which “Device the GPS receiver is attached to” , enter
/dev/ttyAMA0 .
● Accept the defaults for other options.
If you have configured your serial port as per instructions and configured gpsd to automagically start and pick up the device you have just setup, ...then, since the gpsd is handling the device (right?), the device will be busy and the command cat /dev/ttyAMA0 should return cat: /dev/ttyAMA0: Device or resource busy...but, it did not.
Either the serial is not configured as per instructions, or the gpsd is not running and picking up the device, or both.
The goal is not to cat your gps data, but the cat not returning an error indicates something is amiss.
Typically, it's just a typo. But it can be from skipping a step in the process, or mixing instructions from various sources so that the left hand doesn't know what the right hand has done.
Try:
sudo killall gpsd if it returns gpsd: no process found that answers one question.
If it returns with no error, follow it up with cat /dev/ttyAMA0. If it returns nothing, the direction you should look is your serial port configuration.
If sudo dpkg-reconfigure gpsd is not allowing you to reconfigure (I thought it was just me) you can modify the configuration of gpsd by using your favourite editor, e.g. sudo nano /etc/default/gpsd and entering something like:
# Default settings for the gpsd init script and the hotplug wrapper.
# Start the gpsd daemon automatically at boot time
START_DAEMON="true"
# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="false"
# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/ttyAMA0"
# Other options you want to pass to gpsd
GPSD_OPTIONS="-n -G"
You may find the -n and -G useful. Save and restart.
I finally found a solution:
On the Pi 3, there are more steps to use serial, you have to disable the BT.
Edit config file:
sudo nano /boot/config.txt
Add this at the bottom:
dtoverlay=pi3-disable-bt-overlay
Then run this:
sudo systemctl disable hciuart
This article was very usefull for me
http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/#comment-67160
and i recommand you to read it
Now on RPI3 the Serial port
ttyAMA0 is used by BlueTooth
ttySO refers to the GPIO
The Alias Serial0 refers to the GPIO both on RPI2 and RPI3.
So :
after a reinstallation of Jessie with a recent version to be sure all is clean
as usual
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo raspi-config
go to Advanced options : Would you like a login shell to be accessible over serial? response "yes" (not as in the microstack datasheet )
$ sudo apt-get install python3-microstacknode
To install the gpsd standard tools
$ sudo apt-get install gpsd gpsd-clients python-gps
edit GPSD by
$ sudo nano /etc/default/gpsd
and put the options :
START_DAEMON="true"
USBAUTO="false"
DEVICES="/dev/serial0"
GPSD_OPTIONS="-n -G"
equally
$ sudo nano /boot/cmdline.txt
remove
console=serial0,115200
and save
$ sudo nano /boot/config.txt
you must have at the end
enable_uart=1
Disable the console by
$ sudo systemctl stop serial-getty#ttyS0.service
$ sudo systemctl disable serial-getty#ttyS0.service
i have equally done $ sudo chmod 775 ../../dev/ttySO ( i dont know if it is really necessary )
and obviously a reboot
and miracle the gps works with
cgps -s
NB: you must have a fix on the GPS ( the red led flashes )
jpherrenknecht
I am trying to establish a communication b/w raspberrypi(Raspbian) and PC(Microsoft XP) through GPIO PINS 14(Tx) and 15(Rx) for sending/receiving data... , RS-232 level converter is using for connection of GPIO to PC serial COM port and Voltage conversion from 3.3V to 12V...
I install minicom (Echo ON) at raspberry side and install Teraterm(ECHO OFF) at PC side.
Whatever I typed on minicom, it successfully appear on Minicom and Teraterm but when I tried same thing on Teraterm, it only appears on Teraterm not on minicom and also blocked by minicom (/dev/ttyAMA0). After that I am not able to send data from minicom to Teraterm.
But I just check one thing more and very surprise that, when shorting GPIO PIN 14& 15 together and starting typing on minicom... it just show me one character and stop after that...
Again I repeat whole process by closing/opening minicom, again it just show character and then stop.
Can you plz guide me why it happening and how do I resolve it?
I just read from this link that someone was also facing your kind of problem but not exactly what you are facing.
It is happened because Kernel takeover the control on console so It is good and very important to disconnect the connect of console and kernal from the startup.
Now you can follow these step, I am sure you will get rid from this trouble...
Start editing this file by this command
sudo vi /boot/cmdline.txt
Originally it contained:
dwc_otg.lpm_enable=0 rpitestmode=1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
deleted the two parameters involving the serial port (ttyAMA0) to get the following:
dwc_otg.lpm_enable=0 rpitestmode=1 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
rebooted (sudo reboot) to confirm that kernel output was no longer going to the serial port. But the serial console was still available. So edited /etc/inittab:
sudo vi /etc/inittab
commented out the following line:
2:23:respawn:/sbin/getty -L ttyAMA0 9600 vt100
Finally, rebooted again and confirmed that nothing was touching the serial port anymore. Then, to test it out installed minicom on the Raspberry Pi:
sudo apt-get install minicom
And ran it:
minicom -b 9600 -o -D /dev/ttyAMA0
After, it is able to send data in both directions!
We are unclear about the functionality of the leadv command in bluez5.
After connecting to a device and disconnecting again it is impossible to reconnect to the same device. Only after calling leadv again it is possible to reconnect.
We have reproduced this behaviour with various platforms (raspberrypi, x86) and various versions of bluez5 (5.15, 5.16, 5.18, 5.21) and bt dongles from broadcom and csr.
Is it possible to reconnect multiple times without readvertising?
bluetoothd with gatt server is running
We issued the following commands
hciconfig hci0 up
hciconfig hci0 noscan
hciconfig hci0 name foo
hciconfig hci0 leadv 0
I am having the exact same issue.
Interesting is that during a disconnect 'hcidump' doesn't show any commands issued by bluez to the bluetooth controller which would indicate that it turned off the advertising.
I am using this workaround to re-enable advertising as soon as a device disconnected:
sudo dbus-monitor --system --profile | grep --line-buffered --only-matching InterfacesRemoved | xargs -n1 -I % sudo /home/pi/bluez/bluez-5.25/tools/hciconfig hci0 leadv 0
Explanations:
'--line-buffered' is needed as dbus-monitor does not flush its output
'-I %' makes xargs not appending the grep'd "InterfaceRemoved" to the executed command
It turned out that it is actually possible to reenable advertising automatically, but it only seems to work with selected bluez/kernel combinations. We finally had it working with bluez 5.21 and a raspberry pi kernel 3.16 for both broadcom and csr dongles. We haven't tried since with other combinations because we switched to custom hardware (TI CC2451) shortly afterwards.