I'm trying to build a simple Qt based Bluetooth Server (rfcomm) that just prints in the console the text that is sent by the client. I've noticed that when I'm using QCoreApplication(this is what I need) instead of QGuiApplication or QApplication, I'm not able to receive any message and I'm not notified when a client is connected (SLOTS are not called).
The entire code can be found here. The server can be tested with Qt Bluetooth Chat example and the entire code of my server is extracted from the example. It could be something related to the event loop but I don't know what. I'm running the server on OS X El Capitan with Qt 5.6.1.
According to the Qt team response on this reported bug Bluetooth I/O related functionality needs a running loop which is not available through QCoreApplication.
Qt 5.7 has a workaround for this - using Core Foundation event dispatcher.
To activate this event dispatcher you'll need to set the 'QT_EVENT_DISPATCHER_CORE_FOUNDATION=1' environment variable.
Related
All,
I am attempting to communicate, over an SPP profile, with an RN4678 Bluetooth chip connected to a microcontroller.
I never have a problem with the Android app. I can always pair (if not paired), connect, send messages to the chip, and disconnect. An example session is below:
%CONNECT,AB9876543210%
%RFCOMM_OPEN%
%TEST% <-- Message sent using the keyboard ("Byte Stream Mode" option)
%RFCOMM_CLOSE%
%DISCONN%
With the iOS app, I can always pair (if not paired), connect, and disconnect. However, if I cannot send a message to the chip. An example session is below:
%LCONNECT,499B107AB1B5,1%
%LSECURED%
<-- Here I try to send a message, but it is never received
%DISCONN%
The funny thing is that if I first connect/disconnect using the Android, and then I connect using the iPhone/iPad, reception is successful !!!!
%LCONNECT,499B107AB1B5,1%
%LSECURED%
%TEST% <-- Yeah !!! Microcontroller receives the message
%DISCONN%
As far as I know, that path for the processing is the same ... In other words:
if(msg equals "RFCOMM_OPEN" or msg equals "LSECURED")
go to state that monitors incoming messages
I, therefore, kindly ask the following:
1 - Have you encountered anything similar? Do you have any hints? What could the Android App possibly do that the iPhone app is not doing? What am I overlooking or not understanding?
2 - Are you aware of an app that works for both iOS and Android? What I mean, designed by the SAME guy/company?
If you need more info, please ask. I simply did not want to be too 'verbose'.
Thank you for your assistance.
Sincerely,
Vincenzo
All,
At my job we have been playing with two RN modules: the RN4677 (we started with this module) and the RN4678.
The module allows the user to enter (and exit) a command mode. The RN4677 allows bidirectional communication with a manager while still in command mode. The RN4678 does NOT allow bidirectional communication with a manager while still in command mode.
All I needed to do was exit command mode (by issuing the command '---\r'). Now both modules work with Windows/Android/iOS ...
To summarize:
command "$$$\r" to enter command mode
various commands, requests for settings, ...
command "---\r" to exit command mode (a must for RN4678)
Everything will now work fine for both modules
I must say ... that was painful to troubleshoot ...
Sincerely,
Vincenzo
I have a problem with testing my application on Android platform. I have functional application on x86 architecture. This application can connect to Bluetooth LowEnergy device and communicate with it. BT device is HM-10 module - serial line.
But when I try the same application, but just compiled for Android, I'm not able to receive any data back. On the other hand I can see on remote device that all data from mobile terminal are sent.
What I suspect as a possible problem is that signal QLowEnergyService::characteristicChanged is not emitted. In the documentation http://doc.qt.io/qt-5/qlowenergyservice.html is written that you should register for changes, but at least on PC it is done automatically somehow.
Would anyone please help me ?
You have to do some magic
QLowEnergyDescriptor notification = _characteristic.descriptor(
QBluetoothUuid::ClientCharacteristicConfiguration);
if (!notification.isValid()) {
qDebug() >> "QLowEnergyDescriptor not valid";
}
connect(_service, &QLowEnergyService::characteristicChanged, this,
&Device::onCharacteristicChanged);
_service->writeDescriptor(notification, QByteArray::fromHex("0100"));
I have a bluetooth hid device that I need to communicate with. Target platform is Android 5.x+. Currently testing on Nexus 7 2013 tablet.
My code works fine on android 5.x, I am able to receive, send and set reports on Android 5.x.
On Android 6.x, I am only able to receive reports sent by device, but I am not able to send or set reports. It looks like my set/send report requests are silently ignored by HID/BT stack.
The code that talks to /dev/hidraw* nodes runs as a native daemon as root.
Are there any new requirements to be able to set/send reports to Bluetooth hid devices on Android 6.x? Is there any changes I could make to AOSP to allow this to work?
[Update]
Logcat says:
05-17 11:22:56.085 2455-4061/com.android.bluetooth E/bt_btif: uhid_event: Invalid size read from uhid-dev: 4108 != 4
I do not understand how reading from uhid will return only 4 bytes! First 4 bytes are supposed to contain only the type of event. Is there any scenario that will result in a read() of less than sizeof(struct uhid_event) bytes?
Could this indicate a bug in uhid driver?
I checked available kernel sources and found that hidraw driver does not contain usable source to feed reports to /dev/hidraw* nodes
I also found that Bluedroid correctly receives and sends reports internally.
Simplest method to get/set/send reports I found was to modify bluedroid to communicate directly with my App for vendor-specific reports. I integrated my daemon into Bluedroid directly.
I am experiencing a bad behavior of Pubnub in the following scenario:
Pubnub SDK for Python as a subscriber
Python 3+Django on Ubuntu 14.04
Ubuntu machine hosted on Azure
Android Pubnub client as a publisher
It seems to be that, at a certain point, the Pubnub connection on the server side becomes stale, that is, any message sent from the client is not received by the subscriber.
I have noticed that there are some errors on the log related to pubnub connection:
WARNING 2015-09-30 17:21:24,778 connectionpool 26551 139638563919616 Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after connection broken by 'ReadTimeoutError("HTTPConnectionPool(host='pubsub.pubnub.com', port=80): Read timed out. (read timeout=320)",)': /subscribe/.../.../0/...?uuid=...&auth=...&pnsdk=PubNub-Python/3.7.3
After about 5 minutes, the message is received and correctly processed.
I guess that the root of the problem lays in the way Azure manages long http connections, as:
The problem does not arise on my local machine, which has the very same OS version and the same stack
There is an obscure 'azure' parameter in the Python SDK. I tried to activate it without any noticeable difference
As a test I added two more subscribers on my pc and they both receive messages instaneously
Thanks.
It seems to be that the root cause is the fact that Azure cuts HTTP connections above 4 minutes (https://azure.microsoft.com/it-it/blog/new-configurable-idle-timeout-for-azure-load-balancer/).
On the other hand, though, Pubnub creates connections with 5 minutes timeout (320 seconds, see https://github.com/pubnub/python/blob/master/pubnub.py#L1881).
Unfortunately, the Pubnub 320 seconds timeout can not be changed, whereas the Azure timeout seems to be modifiable only via Powershell scripts (uncomfortable, especially if you do not have a Microsoft Window machine).
All in all, I changed the Pubnub source code with a 120 seconds timeout and now everything is going pretty well.
It would be advisable to:
Document that on Pubnub side
Modify Pubnub so that the 320 seconds timeout can be changed
Improve the Azure interface in order to change the timeout parameter without using Powershell
If there is anything that can be done from the PubNub SDK, look at this:
Azure flag on init
https://github.com/pubnub/python/blob/master/pubnub.py#L2112
https://github.com/pubnub/python/blob/master/pubnub.py#L2141-L2146
Linux platform
And this should be getting called if Azure is running on linux:
- https://github.com/pubnub/python/blob/master/pubnub.py#L69-L77
Let me know if that helps any.
For some work I'm doing, I want to have an emulated GSM modem which will communicate with an Android-x86 virtual machine over a Unix socket. The VM should see the emulator as a real modem and use it to send SMS (as the first pass of functionality).
So far, I've put something together which handles some AT commands and just replies "OK" to all the rest. For some commands, like "AT+CRSM", I just have a table of responses gathered from running the official Android emulator and looking at the radio log. For others, I maintain some state and construct answers; those commands include:
CFUN?
CPIN?
CGREG?
CGREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CGSN
CIMI
CSQ
Android will boot, and send commands to my emulated modem, which answers, however it doesn't seem to be fully functional. Android doesn't detect any radio signal strength, for instance, just showing an "x" in the signal bar.
Does anyone know of a similar project, or just what AT commands are absolutely necessary to get some basic functionality?
Well, I'll answer another of my own questions, it's easier that way.
I ended up implementing an emulator which maintains a little bit of state, such as whether or not unsolicited CREG and CGREG messages are enabled, the network registration status & network name format (for the COPS command), and a message reference counter for SMS.
It supports the following commands:
CFUN?
CPIN?
CGREG?
CREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CMGS=
CGSN
CIMI
CSQ
All other messages just get an "OK" response.
With the stock AOSP Android source running in an emulator with the "-radio unix:/tmp/phone" switch, I can send SMS messages and decode the binary PDUs into real messages. I will continue to add functionality so SMS messages can be injected back to Android, and hopefully open-source the code at some point.