I am trying out gammu for the 1st time because I want to transfer some google contacts back to a nokia 6303i .
While the phone database section in Gammu website states that a number of bluetooth connection settings can be used with this phone, I have no bluetooth connection and will thus have to resort to a DKU2 usb cable that I have. The cable is actually a CA-101 nokia cable but according to gnokii wiki they are technically the same.
I have attempted several different connection types. from the ~/.gammurc
[gammu]
#model = NAUTO
device = 01a5:-1
connection = dku2
synchronizetime = yes
logfile = gammu0.log
logformat = text
use_locking =
gammuloc =
[gammu1]
device = /dev/ttyACM0
connection = at
synchronizetime = yes
logfile = gammu1.log
logformat = text
use_locking =
gammuloc =
[gammu2]
#model = NAUTO
device = /dev/ttyACM0
connection = fbus
synchronizetime = yes
logfile = gammu2.log
logformat = text
use_locking =
gammuloc =
[gammu3]
#model = NAUTO
device = 01a5:-1
connection = fbususb
synchronizetime = yes
logfile = gammu2.log
logformat = text
use_locking =
gammuloc =
I have managed to use the "at" connection with gammu -s 1 identify and correctly read phone info. Then I tried to copy a simple (albeit non gammu generated) vCard from those I exported from google contacts.
It was typically formatted like so:
BEGIN:VCARD
VERSION:2.1
FN:Name Surname
N:Surname;Name
EMAIL;CHARSET=UTF-8;ENCODING=8BIT:name.surname#domain.com
TEL;TYPE=CELL:+10123456789
TEL;TYPE=CELL:+19876543210
END:VCARD
What is frustrating is that from a Windows Pc running nokia PC suite I was able to correctly send that same vCard to the nokia 6303i over the same cable.
However from gammu I have -at most- been able to send the surname from the "N:Surname;Name;;;" field (the contact only shows up with the surname) and the 1st telephone number. So the email and the 2nd phone number have been omitted.
This is not enough for me , because I need all phones, all emails and notes to be transferred. I have not found any information abotu whether the "at" connection supports the "enhancedphonebook" functionality (it appears that it does not), but I apart from "bluefbus" which supposedly supported the "enhancedphonebook" in the "Nokia 6303i Cliassic" I don't know which other cabled connection supports it.
so I have tried
the variations gammu(0) , gammu2 and gammu3 as seen in the config file
but these two do not work.
The gammu and gammu3 dump the following in the log
[Gammu - 1.31.0 built 12:51:10 Jul 24 2016 using GCC 4.7]
[Connection - "dku2"] #or "fbususb for gammu3
[Connection index - 0]
[Model type - ""]
[Device - "01a5:-1"]
[Running on - Linux, kernel 3.2.29-gaze5 (#1 SMP Sat Apr 20 13:57:31 EEST 2013)]
Checking 1d6b:0002 (bus 1, device 1)
Checking 1d6b:0002 (bus 2, device 1)
Checking 1d6b:0001 (bus 3, device 1)
Checking 1d6b:0001 (bus 4, device 1)
Checking 1d6b:0001 (bus 5, device 1)
Checking 1d6b:0001 (bus 6, device 1)
Checking 1d6b:0001 (bus 7, device 1)
Checking 0421:0359 (bus 7, device 35)
Extra CDC subheader: 171
Trying to open device, config=1, c_iface=2, c_alt=0, d_iface=3, d_alt=1
Configuration change not required, unhooking only required interfaces!
Detaching kernel driver from inteface 2
Claiming USB control interface...
Configuring USB control interface...
Claiming USB data interface...
Configuring USB data interface...
Connected!
[Module - "auto"]
Getting model
SENDING frametype 0xD1/length 0x05/5
00 |01 |00 |03 |00 .....
Failed to read from usb (-99)!
Other error
Failed to read from usb (-99)!
Other error
Failed to read from usb (-99)!
Other error
and gammu2
[Gammu - 1.31.0 built 12:51:10 Jul 24 2016 using GCC 4.7]
[Connection - "fbus"]
[Connection index - 0]
[Model type - ""]
[Device - "/dev/ttyACM0"]
[Running on - Linux, kernel 3.2.29-gaze5 (#1 SMP Sat Apr 20 13:57:31 EEST 2013)]
Setting speed to 115200
Serial device: DTR is up, RTS is down, CAR is down, CTS is up
(... and it gets stuck here)
So the main question is: how can I achieve transferring the vCard (and many others) to the phone, over a usb cable???????
Thank you
Related
USB soundcard Creative X-Fi switches from USB1.1 to USB2.0 when its proprietary windows driver is used, allowing faster samplerates in its USB2 configuration. A capture of USB packets by wireshark shows several commands are sent by the proprietary driver just before the device disconnects and re-connects at USB2. I am trying to replay the commands to the device in linux, to be able to add the same feature to the existing linux usb-audio driver.
I want to use python, presumably the libusb1 wrapper around libusb-1 library. The captured packet shows the driver sends usb control request to endpoint 0x80 with wIndex 0. Please is there a way to format and send such a packet with libusb-1? I found this answer https://stackoverflow.com/a/39343813/15717902 but do not know if it still holds.
The captured packet:
USB URB
[Source: host]
[Destination: 3.5.0]
USBPcap pseudoheader length: 28
IRP ID: 0xfffffa8009ebd3e0
IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
URB Function: URB_FUNCTION_VENDOR_OTHER (0x0020)
IRP information: 0x00, Direction: FDO -> PDO
URB bus id: 3
Device address: 5
Endpoint: 0x80, Direction: IN
URB transfer type: URB_CONTROL (0x02)
Packet Data Length: 8
[Response in: 20]
Control transfer stage: Setup (0)
[bInterfaceClass: Unknown (0xffff)]
Setup Data
bmRequestType: 0xc3
bRequest: 42
wValue: 0x0000
wIndex: 0 (0x0000)
wLength: 2
I'm learning Vulkan by API spec (http://vulkan-spec-chunked.ahcox.com/ch02s09.html), and I'm little confused about how physical devices are in Vulkan. I do have only one intel physical video card device, but vkEnumeratePhysicalDevices returns count of 2. The devices are identical, but the queue flags seems differ, and the queue flags are undocumented (actually they are, but only to flag 8, in second queue I do have the flag values 16 and 32).
typedef enum VkQueueFlagBits {
VK_QUEUE_GRAPHICS_BIT = 0x00000001,
VK_QUEUE_COMPUTE_BIT = 0x00000002,
VK_QUEUE_TRANSFER_BIT = 0x00000004,
VK_QUEUE_SPARSE_BINDING_BIT = 0x00000008,
} VkQueueFlagBits;
here is the output of my vulkan code:
GPU count: 2 ( physical devices )
Physical Device 0:
Device API version: 1.0.42 - 4194346
Device Vendor Id: 0x8086
Device Id: 1916
Device Driver version: 0.0.1 - 1
Device type: 1
Device Name: Intel(R) HD Graphics 520 (Skylake GT2)
Device Pipeline UID: f557cfd4
Queue Properties:
Flags: 7
Count: 1
ts Valid Bits: 24
Physical Device 1:
Device API version: 1.0.42 - 4194346
Device Vendor Id: 0x8086
Device Id: 1916
Device Driver version: 0.0.1 - 1
Device type: 1
Device Name: Intel(R) HD Graphics 520 (Skylake GT2)
Device Pipeline UID: f557cfd4
Queue Properties:
Flags: 49
Count: 0
ts Valid Bits: 1
Someone can help me understand why there is 2 physical devices for the same real device and the missing flags ?
The count=0 of the second device is curious. More seriously, its flags and tsVB values are corrupted (49 is not an valid value for flags and 1 not valid for tsVB).
This pretty much boils down to there being one extraneous *.json file on your system.
These *.json files store informations about ICDs present on the machine. They are stored in standard location(s).
vkEnumeratePhysicalDevices+vkGetPhysicalDeviceProperties are relatively dumb commands doing nothing much else than reading said *.json file(s) and returning its contents. I think though that calling something "real" like vkCreateDevice would not work on the badly installed driver.
What exactly happened to creare this problem is up to your curiosity to explore. For starters I believe on Linux distros there is a command to map a file to its originating package. It will probably be something about bad cleanup of previous driver, or possibly bug in the installation script of the new one. At least one person had this problem before.
Based on what I explained here, I believe this is relatively benign bug. The first device should work just fine. And you can just ignore the second one. Or simply delete its *.json manifest to prevent it from showing up in vkEnumeratePD.
I am trying to establish a bluetooth serial communication link between a Raspberry Pi Zero W, running Raspbian Jessie [03-07-2017], and an Arduino (UNO).
I am currently able to write data to the Arduino using bluetoothctl.
The application requires that we are able to write data to a particular BLE Slave. There are multiple [HM-10] Slaves to switch between, the Slave needs to be chosen during the program execution.
There is no BAUD rate preference. Currently, we are using 9600 universally.
Functions have been created that automatically connect and then write data to an "attribute", this shows up as data on the Serial Monitor of the Arduino.
Python Code - using BlueZ 5.44 (manually installed):
import subprocess
from subprocess import Popen, PIPE
# Replaces the ':' with '_' to allow the MacAddress to be in the form
# of a "Path" when "selecting an attribute"
def changeMacAddr(word):
return ''.join(c if c != ':' else '_' for c in word)
# Connects to a given MacAddress and then selects the attribute to write to
def connBT(BTsubProcess, stringMacAddr):
BTsubProcess.stdin.write(bytes("".join("connect "+stringMacAddr +"\n"), "utf-8"))
BTsubProcess.stdin.flush()
time.sleep(2)
stringFormat = changeMacAddr(stringMacAddr)
BTsubProcess.stdin.write(bytes("".join("select-attribute /org/bluez/hci0/dev_"
+ stringFormat +
"/service0010/char0011" + "\n"), "utf-8"))
BTsubProcess.stdin.flush()
# Can only be run once connBT has run - writes the data in a list [must have numbers 0 - 255 ]
def writeBT(BTsubProcess, listOfData):
stringList = [str('{0} ').format(elem) for elem in listOfData]
BTsubProcess.stdin.write(bytes("".join("write " + "".join(stringList) + "\n"), "utf-8"))
BTsubProcess.stdin.flush()
# Disconnects
def clostBT(BTsubProcess):
BTsubProcess.communicate(bytes("disconnect\n", "utf-8"))
# To use the functions a subprocess "instance" of bluetoothctl must be made
blt = subprocess.Popen(["bluetoothctl"], stdin=subprocess.PIPE, shell=True)
# blt with then be passed into the function for BTsubProcess
# Note: the MacAddresses of the Bluetooth modules were pre-connected and trusted manually via bluetoothctl
This method works fine for small sets of data, but my requirements require me to stream data to the Arduino very quickly.
The current set up is:
Sensor data (accelerometer, EEG) via USB serial is received by the Pi
The Pi processes the data
Commands are then sent to the Arduino via the in built bluetooth of the Pi Zero W
However, while using this method the bluetooth data transmission would delay (temporarily freeze) when the sensor data changed.
The data transmission was flawless when using two pre-paired HM-10 modules, the Pi's GPIO serial port was configured using PySerial.
The following methods have also been tried:
Using WiringPi to set-up a bluetooth serial port on the /dev/ttyAMA0
using Python sockets and rfcomm
When attempting to use both of these methods. The Python code compiles, however, once the Serial Port is opened the data is seemingly not written and does not show up on the Arduino's Serial Monitor.
This then cripples the previous functions. Even when using bluetoothctl manually, the module cannot be unpaired/disconnected. Writing to the appropriate attribute does not work either.
A restart is required to regain normal function.
Is this approach correct?
Is there a better way to send data over BLE?
UPDATE: 05/07/2017
I am no longer working on this project. But troubleshooting has led me to believe that a "race condition" in the code may have led to the program not functioning as intended.
This was verified during the testing phase where a more barebones code was created that functioned very well.
I have an atmel UC3-L0 and compass sensor. Now I install AtmelStudio and download some demo code into the board. But I have no idea where the function printf in demo code will appear the data. How should I do to get the data?
The printf function outputs to stdout.
Usually on a "naked" processor with no operating system you need to define how a character is sent or received from a physical interface (usually an USART, console port, USB port, 4-port LCD interface, etc.). So typically you may want to use the USART port of your processor board to connect to a PC running Hyperterm, PuTTY or similar using a serial cable.
In essence you will need to
create FILE streams using the fdev_setup_stream() macro and
provide pointers to functions get() and put() that tell the printf() function how exactly to read and write from/to that stream (e.g. read/write to a USART, an LCD display, etc.).
you may have libraries - depending on your hardware - that already contain such functions (plus the correct port initialisation functions), like e.g. uart.c/.h, lcd.c/.h, etc.
In the documentation of stdio.h (e.g. here) look for the following:
printf(), fdev_setup_stream()
If you have downloaded Atmel Studio you may look into the stdiodemo.c code for further insight.
In order to use printf in ATMEL studio you should check the following things:
Add and Apply the Standard serial I/O module from Project->ASF Wizard.
Also add the USART module from the ASF Wizard.
Include the following code snippet before the main function.
static struct usart_module usart_instance;
static void configure_console(void)
{
struct usart_config usart_conf;
usart_get_config_defaults(&usart_conf);
usart_conf.mux_setting = EDBG_CDC_SERCOM_MUX_SETTING;
usart_conf.pinmux_pad0 = EDBG_CDC_SERCOM_PINMUX_PAD0;
usart_conf.pinmux_pad1 = EDBG_CDC_SERCOM_PINMUX_PAD1;
usart_conf.pinmux_pad2 = EDBG_CDC_SERCOM_PINMUX_PAD2;
usart_conf.pinmux_pad3 = EDBG_CDC_SERCOM_PINMUX_PAD3;
usart_conf.baudrate = 115200;
stdio_serial_init(&usart_instance, EDBG_CDC_MODULE, &usart_conf);
usart_enable(&usart_instance);
}
Make Sure you call the configure_console after system_init() from the main function.
Now go to tools->extension manager. Add the terminal window extension.
Build and Run your program and open the terminal window from view-> terminal window. put the correct com port to which your device is running on and set the baud to 115200 and hit connect on the terminal window.
You should see the printf statements now. (Float doesn't get printed in Atmel studio)
I was recently puzzling over this myself. I has installed Atmel Studio 7.0 and was using the SAMD21 Dev Board via an example project in which a call to printf was made.
In the sample code I saw that there was a configuration section:
/*!
* \brief Initialize USART to communicate with on board EDBG - SERCOM
* with the following settings.
* - 8-bit asynchronous USART
* - No parity
* - One stop bit
* - 115200 baud
*/
static void configure_usart(void)
{
struct usart_config config_usart;
// Get the default USART configuration
usart_get_config_defaults(&config_usart);
// Configure the baudrate
config_usart.baudrate = 115200;
// Configure the pin multiplexing for USART
config_usart.mux_setting = EDBG_CDC_SERCOM_MUX_SETTING;
config_usart.pinmux_pad0 = EDBG_CDC_SERCOM_PINMUX_PAD0;
config_usart.pinmux_pad1 = EDBG_CDC_SERCOM_PINMUX_PAD1;
config_usart.pinmux_pad2 = EDBG_CDC_SERCOM_PINMUX_PAD2;
config_usart.pinmux_pad3 = EDBG_CDC_SERCOM_PINMUX_PAD3;
// route the printf output to the USART
stdio_serial_init(&usart_instance, EDBG_CDC_MODULE, &config_usart);
// enable USART
usart_enable(&usart_instance);
}
In windows device manager I saw that there was an "Atmel Corp. EDBG USB Port (COM3)" listed under "Ports". However, the one of the "Properties" of this port was listed as 9600 Bits per second. I changed this from 9600 to 115200 to be consistent with the config section above.
Finally, I ran PuTTY.exe and set the Connection-->Serial setting to COM3 and 115200 baud. Then I went to Session, then clicked the Serial Connection Type, then clicked the Open button. And, BAM, there's my printf output via PuTTY.
I'm building an embedded device with a couple of sensors. The device will 'stream' digital data from these sensors over Bluetooth or USB.
Most of the communication will be from the embedded device to the host. The host will infrequently be sending control messages, to control the gain etc.
Since the physical and data link layers are taken care of, I'm looking for a simple message protocol that will make it easy to develop user applications to process/display data on the host computer. Does anyone have any suggestions?
A simple text protocol may be the best for this application.
Use the communication channel as a bi-directional serial pipe.
The device can stream sensor values in ASCII (text) format, separated by commas, with each set separated by the newline character. The rate is preferably set by the host.
For example,
21204,32014 (new line character '\n' - 0x0A) at the end of each line
21203,32014
21202,32011
....
This makes it easier to test, to stream the values to a file, import in to a spreadsheet etc.
Similarly commands to the device too, is best done in text.
SET GAIN_1 2 ( sent by host )
OK ( reply by device )
SET GAIN_2 4 (sent by host )
OK ( reply by device )
SET GAIN_9 2 (sent by host )
ERROR ( reply by device if it does not understand)
SET RATE 500 ( set the sensor dump rate to every 500 ms )
OK