I'm trying to write a cross-platform Xamarin Forms application (in C#) to talk to Bluetooth LE devices. I've downloaded a few packages (Plugin.BLE and Acr.Ble) and neither one works (they both scan but won't connect), so I thought I would try using the Android API directly to see if that would help me understand what's failing. BTW, I'm running on a Nexus 7 tablet running Android version 6.0.1.
I'm successfully scanning for devices:
BluetoothManager bluetoothManager = (BluetoothManager)Forms.Context.GetSystemService (Android.Content.Context.BluetoothService);
m_adapter = bluetoothManager.Adapter;
if ((m_adapter == null) || (!m_adapter.IsEnabled))
return false;
m_scanCallback = new BlueCallback (this);
m_adapter.BluetoothLeScanner.StartScan (m_scanCallback);
and I see the device I want to talk to (in this case, a TI development board MSP-EXP430F5438 in Server mode, running their SPPLE demo application). So I stop the scan:
m_adapter.BluetoothLeScanner.StopScan (m_scanCallback);
and then I connect to the desired device:
m_gattCallback = new BlueGattCallback ();
m_gatt = m_selectedDevice.ConnectGatt (Forms.Context, false, m_gattCallback);
and I pretty much immediately get a call back saying the connection failed:
BlueGattCallback.OnConnectionStateChange(gatt, status=133, newState=Disconnected)
I read this Google bug report so in my callback I tried calling Connect() directly in my callback:
if ( ((int)status == 133) && (numRetries < 10) )
{
numRetries++;
bool connect = gatt.Connect ();
Debug.WriteLine (" gatt.Connect() returned " + connect);
}
This code fails with error 133 repeatedly and quite quickly (all 10 retries take about 3 seconds).
Any idea what's going wrong here?
As this is dependant on the BLE stack which each vendor develops,
the error generally occurs on Samsung devices more than any other type, Android 6 being the most unstable.
So for anyone running into the 133 error and having many sleepless nights because of it. I would recommend using the Sweetblue
wrapper, you will however need to wrap the library yourself for use in C#.
It abstracts many of the unstable parts of BLE and provides good retry mechanisms as well as graceful degradation in certain cases.
But in the end this does not solve all problems and you will need to handle some of the instability yourself.
Related
Im currently working on a Mobile application which connects to a Ble peripheral and reads data from it. In order to test if the connection is working. I have written a small C# application that utilizes the RaspberryPi4 bluetooth via DBus with BlueZ.
Everything works except that when connecting to iOS a pairing request is issued by the raspberry, eventhough I do not have any encrypted characteristics.
I have read on the Apple forum that this is because bluetoothd is automaticly trying to read the battery level of the phone. But sadly even after the fix suggested there I get the pairing requests.
Does anyone have an idea how I could fix this?
Thanks in advance
I believe disabling this bluez config option in /etc/bluetooth/main.conf would prevent the pi from trying to read characteristics from the iOS device, if that is the issue:
# Do reverse service discovery for previously unknown devices that connect to
# us. For BR/EDR this option is really only needed for qualification since the
# BITE tester doesn't like us doing reverse SDP for some test cases, for LE
# this disables the GATT client functionally so it can be used in system which
# can only operate as peripheral.
# Defaults to 'true'.
#ReverseServiceDiscovery = true
Check the connection min and max intervals, they shall be compliant with the iOS guidelines: https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf (page 180 - 40.6 Connection Parameters).
You can tune them like this:
echo "30" > /sys/kernel/debug/bluetooth/hci0/conn_min_interval
echo "45" > /sys/kernel/debug/bluetooth/hci0/conn_min_interval
The default values worked for me: [24,40]
I'm developing Xamarin application using Visual Studio 2019. I have to connect to another device through Bluetooth and send some data and receive acknowledgement back. Tried these two samples out
https://github.com/msthrax/BLEApp
and
https://github.com/didourebai/BLEPluginDemo.
But didn't help me while scanning for nearby Bluetooth devices, since the below codes are not giving expected result respectively..
1.
listView_DeviceList.ItemsSource = CrossBluetooth.Adaptor.GetListOfDiscoveredDevices();
and
2.
adapter.DeviceDiscovered += (s, a) =>
{
deviceList.Add(a.Device);
};
Both Bluetooth and location turned on in my devices. Can anyone let me know the possibilities of problem here. I don't have any build errors in both of the above samples. Whereas, I have one surprise also. Below line is giving proper result, which is of no use for me currently.
listView_PairedDeviceList.ItemsSource = CrossBluetooth.Adaptor.GetPairedDevices();
After enabling the Location Permission for the app(earlier, I turned on Device Location, but we should allow the app to get device location), all my above problems are solved out.
I'm playing around with remote UWP AppServices in C# and I run into a very early roadblock: Getting a RemoteSystem instance.
I followed the tutorial on https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/communicate-with-a-remote-app-service with my own code and I tried out the RemoteSystems sample as part of https://github.com/Microsoft/Windows-universal-samples
Unfortunately, the result is always the same.
First I request access to remote systems:
RemoteSystemAccessStatus status = await RemoteSystem.RequestAccessAsync();
This is successful: status has the value RemoteSystemAccessStatus.Allowed.
Next, I create a HostName instance:
var deviceHost = new HostName("computer2");
Then I want to get a RemoteSystem instance:
RemoteSystem remoteSystem = await RemoteSystem.FindByHostNameAsync(deviceHost);
This throws an exception:
Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
What I tried
Searching the web doesn't bring up much at this time (remote UWP AppServices are too new)
The event log doesn't have anything interesting in it
The Windows firewall seems to be configured correctly (this seems to be done automatically by Visual Studio)
What I'm looking for
One of my computer was upgraded from Windows 7 to Windows 10, the other from Windows 8.1 to Windows 10. So there is a chance my computers are "misconfigured" in some way (I remember the unnecessary task scheduler entries for Windows Media Center...)
My question: What are recommended practices to troubleshoot these kinds of problems? Are there tools that can help me? Right now I'm now even sure where to start looking...
I'm working on simple application for windows CE to scan barcodes.
I have device: CP9700 and this document: 9700 .NET Programming
There is a simple application which implememt barcode scanner in Appendix II (pages 277 and 278).
I have prepared project in VS2008 and copied program from appendix II.
When I run it on my device I can't catch "WM_DECODEDATA" message.
Can anybody tell me what I'm doing wrong ?
First check the return value of RegisterWindowMessage (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms644947%28v=vs.85%29.aspx for details), if it is 0 you need to use Marshal.GetLastWin32Error() (from System.Runtime.InteropServices) to get an error code. The error codes can be looked up in winerror.h of the installed WMx SDK.
The basic sampe app does not check return codes :-((
YOU should check the InitReader return code (see page 22 of the doc).
Please also check if the DLLs are being copied.
The following happens when decoded data comes about,
A decode event broadcasts when the reader decodes data.
The thread waits for the decode event, and the decode data can then
be obtained.
For example,
while(true) {
dwStatus = WaitForSingleObject(handleEvent,INFINITE)
b1 = Reader.ReaderEngineAPI.GetDecodeType();
b1 = Reader.ReaderEngineAPI.GetDecodeData(ref tmp, tmp.length());
}
Reader DLLs are accessible within the OS directory at the following
paths. Before developing your applications, copy the necessary files
from the mobile computer via ActiveSync connection.
\Windows\Reader_Ce_Net.dll
\Windows\ReaderDll_CE.dll
I am developing a C# device application for Motorola MC55 devices (Bluetopia is used). This application sets the bluetooth inquiry and pairing procedure in motion (by means of the Enterprise Mobility Developer Kit) and writes down the virtual serial port #:
public void DoConnection(IRemoteBTDevice rd)
{
RemoteDevice remoteDevice = new RemoteDevice(rd.DeviceName, rd.Id.Replace(":", ""), "");
this.bluetooth.RemoteDevices.Add(remoteDevice);
this.bluetooth.RemoteDevices.Refresh();
if (!remoteDevice.IsPaired)
{
remoteDevice.Pair(rd.Pin);
}
//TODO Note serial port # (get it by means of remoteDevice.LocalComPort)
//Works smoothly, but a second process has to do this (requirement).
remoteDevice.OpenPort();
}
But as soon as a second process (e.g. another c# device application) opens that serial port, BTExplorer is launched. How do I suppress this phenomenon?
this.comX = new SerialPort(this.BluetoothPortName);
this.comX.Open();
I'm just using another Assembly: http://32feet.codeplex.com/. It works smoothly for Motorola ES400 (Microsoft Stack). After seeing this: http://32feet.codeplex.com/wikipage?title=Stonestreet%20One%20Bluetopia, I used the same code, but it doesn't work trouble-free for MC55 yet.
Thank you for your support,
Roger Huber
As I understand it, it is BTExplorer.exe that actually provides/controls the virtual COM port service, so it needs to be running when a virtual COM port is in use...
Do be sure to let know what the issues you see on your MC55 when using my 32feet.NET Bluetopia support. As I noted at 32feet.NET: Stonestreet One Bluetopia I tested on a M3 Mobile device which has a quite recent version of the Bluetopia stack. Maybe StoneStreetOne changed something between your versions... (If Bluetopia start-up fails completely then I've more logging in version 3.3 -- which I'm not too far away from releasing).
Of course if that second C# program needs to use a virtual COM port then 32feet.NET won't help -- BTExplorer is still required as discussed above. However if you could change that program to use BluetoothClient etc instead of COM ports... (Remembering of course the "Bluetopia one at a time" restriction of course).
Alan