Cannot Read HM-10 After Connecting with Bluez - raspberry-pi

I am hoping you can help me figure out how to use Bluez to read from an HM-10 BLE module. Why is this a problem for me? I cannot get read or write to work correctly, and I my end-goal is to use Ian Harvey's bluepy library, built on top Bluez stack. Any help is appreciated. Thank you!
The HM-10, connected to an arduino nano, will say "Foobar" , wait one second, say "Barfoo", wait one second, and repeat.
My iOS Bluetooth Serial App (named "Serial" on app store) picks this up correctly.
Hardware: Raspberry Pi ZeroW
Kernel: 4.9.68+
Bluez: 5.50 (released 3 June 2018)
Main Problem
I am unable to use bluetoothctl to read "Foobar" and "Barfoo."
pi#raspberrypi:~ $ bluetoothctl
[bluetooth]# power on
[bluetooth]# connect 34:15:13:87:98:37
[DSDTECH HM-10]# menu gatt
[DSDTECH HM-10]# select-attribute 0000ffe1-0000-1000-8000-00805f9b34fb
[DSDTECH HM-10:/service0010/char0011]# read
[CHG] Attribute /org/bluez/hci0/dev_34_15_13_87_98_37/service0010/char0011 Value:
34 15 13 87 98 37 4....7
34 15 13 87 98 37 4....7
BtMon shows that I am receiving "Foobar" and "Barfoo," though
In fact, using btmon ( $sudo btmon in another terminal), I can see that my raspberry pi zero W is seeing these values. The below entries repeat every other second.
> ACL Data RX: Handle 64 flags 0x02 dlen 15 #278 [hci0] 339.880027
ATT: Handle Value Notification (0x1b) len 10
Handle: 0x0012
Data: 426172666f6f0d0a
> ACL Data RX: Handle 64 flags 0x02 dlen 15 #279 [hci0] 340.292455
ATT: Handle Value Notification (0x1b) len 10
Handle: 0x0012
Data: 466f6f6261720d0a
426172666f6f0d0a = Barfoo (hex2ascii)
466f6f6261720d0a = Foobar (hex2ascii)
Not getting readings from the other attributes
If you know HM-10, you know that ffe1 is what you are supposed to use for uart data transfer. I encoded ffe1 in my homebrewed android application, which works as a master to pair with the HM-10. But, I wanted to check what the other attributes give me.
[DSDTECH HM-10:/service0010/char0011]# select-attribute 00002902-0000-1000-8000-00805f9b34fb
[DSDTECH HM-10:/service0010/char0011/desc0013]# read
[CHG] Attribute /org/bluez/hci0/dev_34_15_13_87_98_37/service0010/char0011/desc0013 Value:
00 00 ..
00 00 ..
[DSDTECH HM-10:/service0010/char0011/desc0013]# list-attributes
Primary Service
/org/bluez/hci0/dev_34_15_13_87_98_37/service000c
00001801-0000-1000-8000-00805f9b34fb
Generic Attribute Profile
Characteristic
/org/bluez/hci0/dev_34_15_13_87_98_37/service000c/char000d
00002a05-0000-1000-8000-00805f9b34fb
Service Changed
Descriptor
/org/bluez/hci0/dev_34_15_13_87_98_37/service000c/char000d/desc000f
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
Primary Service
/org/bluez/hci0/dev_34_15_13_87_98_37/service0010
0000ffe0-0000-1000-8000-00805f9b34fb
Unknown
Characteristic
/org/bluez/hci0/dev_34_15_13_87_98_37/service0010/char0011
0000ffe1-0000-1000-8000-00805f9b34fb
Unknown
Descriptor
/org/bluez/hci0/dev_34_15_13_87_98_37/service0010/char0011/desc0013
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
Descriptor
/org/bluez/hci0/dev_34_15_13_87_98_37/service0010/char0011/desc0014
00002901-0000-1000-8000-00805f9b34fb
[DSDTECH HM-10:/service0010/char0011/desc0013]# select-attribute /org/bluez/hci0/dev_34_15_13_87_98_37/service0010/char0011/desc0014
# I could not get the uuid to work after selecting 00002902, and do not know how to exit out of an attribute.
# This corresponds to uuid 00002901
[DSDTECH HM-10:/service0010/char0011/desc0014]# read
[CHG] Attribute /org/bluez/hci0/dev_34_15_13_87_98_37/service0010/char0011/desc0014 Value:
77 77 77 2e 6a 6e 68 75 61 6d 61 6f 2e 63 6e www.jnhuamao.cn
77 77 77 2e 6a 6e 68 75 61 6d 61 6f 2e 63 6e www.jnhuamao.cn
[DSDTECH HM-10:/service0010/char0011/desc0014]# select-attribute /org/bluez/hci0/dev_34_15_13_87_98_37/service0010
[DSDTECH HM-10:/service0010]# read
Unable to read attribute /org/bluez/hci0/dev_34_15_13_87_98_37/service0010
[DSDTECH HM-10:/service0010]# select-attribute /org/bluez/hci0/dev_34_15_13_87_98_37/service000c/char000d
# This corresponds to uuid 00002a05-0000-1000-8000-00805f9b34fb
[DSDTECH HM-10:/service000c/char000d]# read
Failed to read: org.bluez.Error.NotPermitted
[DSDTECH HM-10:/service000c/char000d]# select-attribute /org/bluez/hci0/dev_34_15_13_87_98_37/service000c/char000d/desc000f
[CHG] Attribute /org/bluez/hci0/dev_34_15_13_87_98_37/service000c/char000d/desc000f Value:
02 00 ..
02 00 ..
I seem to be reading manufacturer data value
Interestingly, this is the same response as manufacturer data vale, as seen with the info command.
[bluetooth]# info 34:15:13:87:98:37
Device 34:15:13:87:98:37 (public)
Name: DSDTECH HM-10
Alias: DSDTECH HM-10
Paired: no
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Unknown (0000ffe0-0000-1000-8000-00805f9b34fb)
ManufacturerData Key: 0x4d48
ManufacturerData Value:
34 15 13 87 98 37 4....7
ServiceData Key: 0000b000-0000-1000-8000-00805f9b34fb
ServiceData Value:
00 00 00 00 ....
RSSI: -56
TxPower: 0
When I use a different nano/HM-10 combo, this value is a different gibberish of #|...x , both for the info/manufacturing data and for the read of uuid ffe1.
Additionally, when I initially connect to the device, btmon shows
# MGMT Event: Device Found (0x0012) plen 57 {0x0001} [hci0] 67.415544
LE Address: 34:15:13:87:98:37 (OUI 34-15-13)
RSSI: -62 dBm (0xc2)
Flags: 0x00000000
Data length: 43
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Company: not assigned (19784)
Data: 341513879837
Service Data (UUID 0xb000): 00000000
16-bit Service UUIDs (partial): 1 entry
Unknown (0xffe0)
TX power: 0 dBm
Name (complete): DSDTECH HM-10
341513879837 = 47 (hex2ascii) (there are four squares, which I cannot get to display properly. These line up with the four periods)

btmon logs show that the data coming from your HM-10 device are in the form of notifications. In BLE you have three ways to data transfer; read, write and notify. Read is that a GATT client (in your case Bluez) reads data from a service characteristic or from service descriptor of GATT server, provided that read operation is permitted on those respective characteristic or descriptor. Write operation is that a GATT client sends data to GATT server (HM-10) by writing to its service characteristic or descriptor.
The only way by which GATT server sends data to GATT client by itself is by notifications. But the GATT client need to enable notifications on GATT server after establishing connection. Enabling notification can be done by writing to Client Characteristic Configuration Descriptors (CCC) of GATT server. CCC is a special GATT service defined in Bluetooth Core specs.
Once notifications are enabled you will see data from GATT server. With Bluez you can do all BLE operations using gatttool. Below is a example:
For example if the Bluetooth device address of HM-10 is 03:0F:45:65:43:FF and your device hci interface address is hci0, below sequence of commands enables notifications:
gatttool -i hci0 -b 03:0F:45:65:43:FF -I
[03:0F:45:65:43:FF][LE]>connect
Attempting to connect to 03:0F:45:65:43:FF
Connection successful
# lists all other primary services
[03:0F:45:65:43:FF][LE]> primary
attr handle: 0x0001, end grp handle: 0x0005 uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x0006, end grp handle: 0x0009 uuid: 00001801-0000-1000-8000-00805f9b34fb
# lists all characteristics
[03:0F:45:65:43:FF][LE]> characteristics
handle: 0x0002, char properties: 0x02, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb
handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb
# 2902 is UUID of CCC service
[03:0F:45:65:43:FF][LE]> char-read-uuid 2902
handle: 0x0009 value: 00 00
handle: 0x0019 value: 00 00
# Enable notifications
[03:0F:45:65:43:FF][LE]> char-write-req 0x0009 0100
Characteristic value was written successfully
[03:0F:45:65:43:FF][LE]> char-write-req 0x0019 0100
Characteristic value was written successfully

I know nothing about Bluez, but what you receive is the advertising data, and not the Tx data from the HM10.
To read the data, you must use the service: "0000ffe0-0000-1000-8000-00805f9b34fb" and the
characteristic: "0000ffe1-0000-1000-8000-00805f9b34fb".
You must write the notification descriptor to this characteristic.
To get the data you don't have to do a read, the data is in the notification-payload and you read it in the characteristic-changed event,
or what this is called in Bleuez.

Related

OpenOCD multiple STLinks

I need to be connect to 2 STM32s over 2 ST-Links at the same time. I found this issue described here.
However, solution doesn't work for me.
ST-Link ID1: 55FF6B067087534923182367
ST-Link ID2: 49FF6C064983574951291787
OpenOCD cfg file:
source [find interface/stlink-v2.cfg]
hla_serial "55FF6B067087534923182367"
source [find target/stm32f4x.cfg]
# use hardware reset, connect under reset
reset_config srst_only srst_nogate
I get:
$ openocd.exe -f stm32f4_fmboard.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'
I do not know if solved but:
pi#raspberrypi:~/prog/bootloader $ st-info --probe
Found 1 stlink programmers
serial: 363f65064b46323613500643
openocd: "\x36\x3f\x65\x06\x4b\x46\x32\x36\x13\x50\x06\x43"
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x0000
descr: unknown device
this tool shows serial of st-links and there is option called openocd. When I put hla_serial "\x36\x3f\x65\x06\x4b\x46\x32\x36\x13\x50\x06\x43" in file then it works for me. Your way does not. It also does not work in command line given as argument. It works only as I described in cfg file
The format of the configuration file seems to have changed recently. The following applies for Open On-Chip Debugger 0.10.0+dev-00634-gdb070eb8 (2018-12-30-23:05).
Find out the serial number with lsusb, st-link, or with ls -l /dev/serial/by-id. The latter yields (with two STLink/V2.1 connected):
total 0
lrwxrwxrwx 1 root root 13 Nov 30 14:31 usb-STMicroelectronics_STM32_STLink_066CFF323535474B43125623-if02 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Dec 30 23:55 usb-STMicroelectronics_STM32_STLink_0672FF485457725187052924-if02 -> ../../ttyACM1
The specification on the .cfg-file is now plain hex. Do not use the C string syntax any longer. For selecting the latter device, simply write:
#hla_serial "066CFF323535474B43125623"
hla_serial "0672FF485457725187052924"

Can't use CAIDA Dataset with tcpreplay to simulate network traffic in network

I have a server and I need to simulate real network traffic. I've been asked to do this using a CAIDA Dataset. I have downloaded the public Dataset which can be found here:
CAIDA Public Dataset
I also need to rewrite the source ip address in the .pcap file to be the one of the server. I tried doing it the way it's described at the end of this page: tcprewrite wiki
I run:
tcprewrite --infile=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --outfile=oc48-mfn.dirA.20020814-160000.UTC.anon_rewrite.pcap --dstipmap=0.0.0.0/0:10.101.30.60 --enet-dmac=00:0c:29:00:b1:bd
And I get:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
Fatal Error: From ./plugins/dlt_hdlc/hdlc.c:dlt_hdlc_encode() line 255:
Non-HDLC packet requires --hdlc-address
So after some tries like this I finally run these to get an error free tcprewrite:
tcpprep --auto=bridge --pcap=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --cachefile=cache1.cache
Which gives:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
And then I run:
tcprewrite --infile=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --outfile=oc48-mfn.dirA.20020814-160000.UTC.anon_rewrite.pcap --dstipmap=0.0.0.0/0:10.101.30.60 --enet-dmac=00:0c:29:00:b1:bd --cachefile=cache1.cache --hdlc-control=0 --hdlc-address=0xBF
And I get:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
So it seems like a success, except the warning that shows up in every command.
I open the new .pcap file with tcpdump to check that the destination IP addresses have changed to the one of the server and it has been done.
So then I run tcpreplay:
tcpreplay -i ens160 --loop 5 --unique-ip oc48-mfn.dirA.20020814-160000.UTC.anon.pcap
And I run tcpdump on the server to see the traffic from the .pcap file, but the traffic looks like this:
13:30:50.194780 05:8c:55:6f:40:00 (oui Unknown) > 0f:00:08:00:45:00 (oui
Unknown), ethertype Unknown (0x3406), length 60:
0x0000: ed11 f484 7785 f477 0d79 0050 0487 007c ....w..w.y.P...|
0x0010: e7d5 d203 c32b 5010 27f7 aa51 0000 4854 .....+P.'..Q..HT
0x0020: 5450 0000 0000 0000 0000 0000 0000 TP............
I have tried the smallFlow.pcap from the sample captures of tcpreplay: Sample Captures
and it worked just fine.
So any suggestions on how to properly use the CAIDA .pcap files?
Your stated goal is "I need to simulate real network traffic", but you're using pcaps where "the payload has been removed from all packets" (per the CAIDA web page you linked to).
These two statements are in conflict with each other. All your packets are literally no larger then 48bytes which is merely enough for the TCP/IP header (and then even so, may not be sufficient in all cases). This is what the warning is telling you. You can't put the data back.
You'll need to find a new source of pcaps.

pymodbus on RasPi read_holding_registers Returns none From Simulator

I'm trying to read holding registers from a Modbus simulator, but when I print the value in Python, I get a "none" object. The simulator does send a response, but Python seems to not receive it.
I've googled for a day and have tried everything I've found: including unit number, different Python modbus clients, different simulators, etc. No luck.
Any ideas or suggestions are very welcomed!!Please let me know if there is any information I should supply to help.
I can successfully write to the holding registers, and the simulator sends the transmission below:
"RX:01 03 00 00 00 01
RX:84 0A
Read Register from 0 for 1
TX:01 03 02 00 05 78 47"
Simulator Transmissions
Simulator Registers
The Python output that I get is:
"Connection:True
None"
If I try the print(result.registers), I get the error: "Error: ('NoneType' object has no attribute 'registers')"
Version Info:
Python: 3.4.2
Modbus: pymodbus3
Simulator: MOD_RSsim Version 8.20
USB-to-Modbus converter: UTEK Model:UT-890A (connected to RasPi)
USB-to-RS232 convertor: ATEN Model: GUC232A (connected to laptop)
import pymodbus3
from pymodbus3.client.sync import ModbusSerialClient
client = ModbusSerialClient(method='rtu', address=1, timeout=1000, port="/dev/ttyUSB0", bytesize=8, stopbits=1, baudrate=9600, parity='E')
connection = client.connect()
print ('Connection:{}'.format(connection))
write = client.write_registers(0, 5, unit = 1)
time.sleep(0.3)
result = client.read_holding_registers(address=0x00, count=1, unit = 0x01)
time.sleep(1)
print(result)
I thought this is a bug if you installed pymodbus3 by pip.
Here is a issue link: pymodbus3 issue.
I suggested you use pymodbus since it support python3 now Just a Note : Pymodbus for python3 is officially supported, or you can install pymodbus3 by pymodbus3 master branch source code.

How can I access GPIO with physical address?

I have a requirement that is accessing GPIO with ubuntu 14.04LTS.
Below information is my device information:
OS:Ubuntu 14.04 LTS 64bits
CPU:Intel® Celeron(R) CPU J1900 # 1.99GHz × 4
And bleow link is datasheet and driver code
code and datasheet here.
First I was checked the chip is it8785, and GPIO port is 32 to 39.
PIN of port GPIO 32 is 117, so I type the command:
echo 32 > /sys/class/gpio/export
and
echo 117 > /sys/class/gpio/export
but both show the error "bash - echo: write error: invalid argument"
I don't have any idea for this, so I contect with manufacturer.
They told me that if i want access GPIO, I must direct access CPU address like :
GPIO PORT Adderss
32 0xfed0e388
33 0xfed0e368
34 0xfed0e318
35 0xfed0e378
36 0xfed0e308
37 0xfed0e398
38 0xfed0e328
39 0xfed0e3A8
I have googled for a while, quantity of data are rarly.
It's thanksful for any advice.
Can you try and use sudo while exporting and see if the gpio could exported.
As the manufacturer has provided with register address you can map them to user space and access. On how to access them in user space you can have a look at dev2mem. Hope that helps.

how to record an ir signal from an AC remote using LIRC in raspberry pi?

i had already used the LIRC of the raspberry pi to record and use the IR signals of a samsung TV remote. the recording process was fine. i used this site for reference.But now i am unable to record the IR signals from a bluestar AC in the same method. After 1-3 dots (not always the same number), irrecord exits with the following error message:
irrecord: could not find gap.
irrecord: gap not found, can't continue
then i tried recording the AC remote signals using mode2 and routing it to a text file and manually modified the lircd.conf file to include the raw code as shown in the link
How to use irrecord with 2ms timing instead of the default 5ms?
but then i get the error that
irsend: command failed: SEND_ONCE /etc/lirc/lircd.conf KEY_POWER
irsend: unknown remote : "/etc/lirc/lircd.conf"
Possibly lircd doesn't accept all characters (e.g. slash) for the remote name. Try changing the:
name /etc/lirc/lircd.conf
in the .conf file to a different name (e.g. MY_REMOTE), then invoke the irsend like:
irsend SEND_ONCE MY_REMOTE KEY_POWER
The air conditioning controls send more bits than the television ones for example. You have to configure the lirc.conf header as:
begin remote
name IRAIR1
bits 48 #Configuración para 48 bits
flags SPACE_ENC
eps 30
aeps 100
header 3388 1678
one 430 1257
zero 430 412
ptrail 428
gap 108399
begin raw_codes
name KEY_POWER
3478 1676 500 1218 501 388
472 ..................................
end raw_codes
end remote
I think exactly what 48 bits are sending. This guy explains it: http://absurdlycertain.blogspot.com.es/2013/03/lirc-raspi-remote-control-configuration.html
Do not forget to restart the device, with me it does not work if I do not.
Sorry for my English