I tried to provision a device via Bluez and mesh-cfgclient on my Raspberry Pi.
Bluez: 5.65
Raspberry Pi: 3B+
First I am looking for provisionable devices and get:
Scan result:
rssi = -38
UUID = DDDD00000000000000000000000000DD
OOB = 0000
URI Hash = 00000000
If I am stating the provision process with:
provision dddd00000000000000000000000000dd
I get the error:
Failed to generate UUID array from dddd00000000000000000000000000dd
If I am trying this:
provision dddd0000-0000-0000-0000-0000000000dd
I get:
Requires UUID
So I don't know which UUID mesh-cfgclient like to get from me. Do someone know what I missed here.
Thanks for your help.
I'm encountering this as well. I don't know if it's a new issue because this is my first foray into BLE mesh...
My findings so far has led me to the UUID needs to comply with RFC-4122.
This is my conclusion based on downloading the bluez source (specifically 5.65), along with the ell source (specifically 0.55) and walking through add_node_setup, which led me to l_util_from_hexstring, which seemed fine.
It was l_uuid_is_valid that doesn't like the format...
It's expecting the variant (==2) and version (between 1 & 5) to be included.
Mind you, when I mention those values, they are the result of bit-shifting, so variant == 0x80, and version between 0x16 and 0x80, and this is all after the UUID we are provided is converted into hexidecimal.
I haven't done it yet, but you can probably use a uuid generator online or in linux (uuidgen).
I will say that at the moment, I don't know why ell is expecting variant to == 2.
Looking at the RFC, section 4.1.1, I'm not seeing any bit combination that equates to 2.
Actually, looking at the wikipedia for it, I see the UUID number 2 doesn't equate to the bit combination, but rather the zero-based position of the list, which is 110 ("Reserved, Microsoft Corporation backward compatiblity").
If we were to alter your dddd00000000000000000000000000dd, I think it might look like dddd00000000 40 00 80 000000000000dd.
I chose 0x40 for version 4, and 0x80 for the variant #2 mentioned earlier (bit-shifted).
Related
I am using linux 20.04 to build an image for the IMX8QXP, the image is based on kernel SUMO 4.14.98.
I am using one of the SIMCOM7600E.
I starts to dial up via NIC by using below command :
AT+CREG = 1
+CREG=1,1
return OK
AT+CGREG = 1
+CGREG=1,1
return OK
AT$QCRMCALL=1,1
return No CARRIER
I cant seem to fix the problem or figure out what is wrong. Please help me trouble shoot the problem!!
My guess would be:
The module can be registered in network, but the selected network mode may be unsuitable for data transmission (e.g. voice calls only or other). Check the preferred mode by using AT+CNMP?. The return value of 2 indicates auto.
Make sure that you have data plan available. Also remove PIN lock on the SIM card
Check if the signal quality is decent: try AT+CSQ. Its return value will be in format ,. RSSI stands for Received Signal Strength Indicator and BER for Bit Error Rate. RSSI value ranges can be in between 0 (minimum, =< -113dBm) to 31 (maximum, >= -51 dBm).
Look for more information about the operator: AT+COPS? and the network mode: AT+CPSI?
Based on the information obtained in previous steps, use an appropriate antenna or adjust its location if necessary
Don't forget about the stable power supply
If you didn't have much success with AT$QCRMCALL=1,1, try changing the USB PID of the module to 9011 (for using the modules as a RNDIS modem): AT+CUSBPIDSWITCH=9011,1,1 (the default PID is 9001)
I would flash a new firmware only as a last resort. Usually this is not necessary
Reference:
SIM7600 AT Commands manual v3.0
I made an app that discovers Bluetooth devices around me, and I'm looking into the datas I get about them. Now I'm trying to figure out the datas from BluetoothDevice.getBluetoothClass (CoD, Class of Device).
So far I've found these class codes around me:
43c
50c
704
1f00
c043c
c243c
8043c
60680
200408
240414
5a020c
About half of these I found some information for (http://domoticx.com/bluetooth-class-of-device-lijst-cod/). The rest of the codes I haven't been able to find anywhere (50c, c043c, c243c, 60680).
Does anyone know any overview with all of these codes (or at least the ones I haven't figured out)?
You can decode the Bluetooth Class of Device (CoD) yourself by first converting the above hex number to binary (for example using this link) and then checking the document below to try and find what the combination of the bits mean:-
https://www.ampedrftech.com/datasheets/cod_definition.pdf
As an example, 0x50c is 010100001100 in binary. Using the table in the document above, bits 8 to 12 indicate that the device is a peripheral:
And then bits 2 to 5 indicate that the device is a remote control
I'm not sure this would be better on Electronics Stack Exchange.
I've seen a few questions similar to this, but pre BLE 4.2 days, before it was possible to have characters of greater than 20 bytes, but these questions are outdated now.
To anyone who's not aware, from BLE 4.2 onwards, you have been able to send far more than 20 bytes in a characteristic. So, if you've not come across this, I have successfully been transferring characteristics of 240 odd bytes between iOS and a Silicon Labs device for well over a year.
I have recently set up a Nordic embedded device and knocked up a Qt GUI to transfer data between the Nordic device and the Qt app running on Linux, using the Bluez stack. It will transfer 20 byte characteristics just fine.
So, I increased the Nordic's characteristics to 40 bytes, but Qt is not playing at all with it.
I am confident things are right at the Nordic end because if I use a little Android app and query the 40 byte characteristic it reads all 40 bytes. This makes me think that the issue is at the Laptop end.
I have various unknowns:
Is my laptop really BT4.2. It's hard to know as Linux calls it an unknown device and its USB vendor and type number tell me it's an Intel device, yet the IDs seem to give me multiple possibilities.
hciconfig tells me that I am running HCI Version 4.2 and LMP Version 4.2. That, to me, suggests larger characteristics should work.
Can Linux itself cope with characteristics of greater than 20 bytes?
Can Qt cope with characteristics of greater than 20 bytes?
I am running Mageia 6 and Qt Creator 4.2.1 with Qt 5.9.4 kit.
I have no Windows or iOS device with LE new enough for larger characteristics. Also, Windows is a bit of a pain when it comes to LE...
Edit:
btmon gives this when it receives a 40 byte chatacteristic:
ACL Data RX: Handle 3585 flags 0x02 dlen 27 #1026 [hci0] 577.032058
ATT: Handle Value Notification (0x1b) len 22
Handle: 0x0010
Data: 35303120546869732069732061206c6f6e672063
This is sending out a string from the Nordic:
"%1 This is a long characterstic %1",Messno,MessNo
MessNo gets incremented every time the Noridic sends out a message. This gets truncated to xxxx This is a long
So, this suggests to me that it's getting truncated either by the BT stack on the assumption that this is what the Qt app is digesting.
You should increase the MTU size from the nordic device. It has nothing to do with Qt.
Trying to get access to a partially rooted Galaxy S2 external sd card.
The problem is that /dev/block/mmcblk1p1 does not exist on the phone. This is the device name that should allow me to put the "recovery" image onto the sdcard so that the unit will be a phone again.
Problem is, I don't know where to find the magic Major and Minor numbers for this device and I'm trying to figure out where in the kernel source I should be looking for them.
Could someone point me at the right kernel files to find this information?
Standard devices use predefined major numbers and minor numbers starting from 0 for the first instance and upward depending on how many instances there are going to be.
Look at the Linux Documentation file(devices.txt) to see the full list but the section of interest to you is:
179 block MMC block devices
0 = /dev/mmcblk0 First SD/MMC card
1 = /dev/mmcblk0p1 First partition on first MMC card
8 = /dev/mmcblk1 Second SD/MMC card
...
The start of next SD/MMC card can be configured with
CONFIG_MMC_BLOCK_MINORS, or overridden at boot/modprobe
time using the mmcblk.perdev_minors option. That would
bump the offset between each card to be the configured
value instead of the default 8.
So /dev/block/mmcblk1p1 would be major 179, minor 9.
According to hotplug.txt
Entries for block devices are found at the following locations:
/sys/block/*/dev
/sys/block/*/*/dev
So try looking in /sys/block/mmcblk1p1/dev.
EDIT:
Looking at it again I actually think that it will be in /sys/block/mmcblk1/mmcblk1p1/dev
I develop an Android application running on Motorola RAZR XT910 with OS version 4.0.4.
This application uses the Motorola_ICS_R2_sdkaddon_100 BluetoothGattService.jar and BluetoothGatt.jar libraries and communicates with Bluetooth
Low Energy Sensor Tags (TI CC2540,TI CC2541,Blue Radios Sensor Tags).
On Discovery procedure I always read the rssi value equal to 0 . I use the following code
to read the rssi value on receiving the Intent BluetoothDevice.ACTION_FOUND:
short rssi = intent.getShortExtra(BluetoothDevice.EXTRA_RSSI,(short) 0);
Also for non Bluetooth low energy devices,the rssi value i read is ok (not equal to 0).
Can anyone help me??
thanks
I found a similar issue on the TI discussion site for using the Vender Specific query for RSSI. It seems that it works for Classic BT but returns an error code of 2 for BLE.
http://e2e.ti.com/support/low_power_rf/f/660/t/289391.aspx
It might be a fundamental limit that you can't get the value. In your case, the getShortExtra might not return the error code (2) and just return a 0 as RSSI.