I'm trying to experiment with Bluetooth discovery from the command line.
I have tried:
btdiscovery from https://bluetoothinstaller.com/bluetooth-command-line-tools ( via https://superuser.com/questions/1604313/command-line-check-if-a-certain-bluetooth-device-is-discoverable )
The C code from https://www.winsocketdotnetworkprogramming.com/winsock2programming/winsock2advancedotherprotocol4j.html (via Unable to connect to Bluetooth Device using Window's Bluetooth API in C++)
Both of these, have the same problem: that when I run Bluetooth "discovery", they report one or two devices maximum, and then they exit.
However, if in Windows 10, I go to: Windows Settings/Devices/Add Bluetooth or other device/Bluetooth, so I get "Add a device" window:
... I get a while bunch of devices that are continuously updated (and some disappear, then reappear again)
Does anyone know of a ready (C/C++) example that would reproduce the same results I get in this "Add a device" window, but in the command line/terminal?
Short of that - could anyone give me any pointers on what APIs I'd need to use, in order to replicate the same Bluetooth discovery results from this "Add a device" window in a command line application? (presumably, that would be a continuous Bluetooth discovery process, that would be interrupted by Ctrl-C or similar in the terminal)
Related
I've lost my BT earphones, and am trying to determine the last time they were connected to my macbook, to narrow the time window and help the search.
How can I learn this from system logs?
I opened Console.app, and found numerous mentions of connections to BT devices, of the format:
com.apple.message.domain: com.apple.bluetooth.connect
com.apple.message.host: 05AC8290
com.apple.message.process: blued
com.apple.message.device: Unknown Name
com.apple.message.uuid: 0x001F
com.apple.message.direction: Outgoing
com.apple.message.rssi: 127
com.apple.message.pairing: LE
com.apple.message.rate: LE
com.apple.message.sco: LE
SenderMachUUID: 557AF7B3-7829-380F-83D7-684B2004E540
How do I determine which ones are connections to my BT earphones (not my smartphone)? I know the MAC addresses of both the devices that connect to this computer, but they don't seem to be mentioned in the logs.
Hold shift and option buttons at the same time and click on the Bluetooth icon:
Click on the Debug and then click on Enable Bluetooth logging. Then in the magnifier type "Console". In the search area, search for Bluetooth. You should be able to see the logs:
In order to check Bluetooth logs open the Console.app e.g. by pressing cmd + space, then typing "Console" and hitting Enter.
Inside the Console.app you can filter messages just to Bluetooth related by typing "bluetooth" inside Search field.
Tested on macOS Catalina.
I have a Bluetooth low-energy device paired to my Windows 10 machine, when an application try to use it, Windows automatically connects the paired device. I want to be able to read if the device is connected or just paired to Windows. Searching around Window's Device Manager (accessible from Control Panel), I saw that the device had the property "Is connected" under the details tab, it's value (true/false) was changing accordingly to the actual device status.
I tried to read to access this property using the SetupDiGetDeviceProperty function with the DEVPKEY_DeviceContainer_IsConnected predefined key but for some reason I get ERROR_NOT_FOUND.
Any ideas?
When debugging in Unity Editor I can see the Debug.Log() output in the Console, which is great. However, when connecting MonoDevelop to a device I don't know where to find this output. It is not in the "Application Output" window. Breakpoints, variables, stack - all works fine. Is there a way to see the debug output in MonoDevelop?
Is there anything better then this answer suggests? Debug/Trace output in MonoDevelop
1) Enable "USB debugging" on your device and connect the device to your development machine via USB cable. Ensure your device is on the same subnet mask and gateway as your development machine. Also, make sure there are no other active network connections on the device (i.e. disable data access over mobile/cellular network).
2) On your development machine, open up your terminal/cmd and navigate to the location of the ADB. You can find the ADB tool in /platform-tools/
3) Restart host ADB in TCP/IP mode with the following command:
adb tcpip 5555
This should produce the following output:
restarting in TCP mode port: 5555
This will have enabled ADB over TCP/IP using port 5555. If port 5555 is unavailable, you should use a different port.
(See http://developer.android.com/tools/help/adb.html)
4) Find out the IP address of your Android device (Settings -> About -> Status) and input the following command:
adb connect DEVICEIPADDRESS
(DEVICEIPADDRESS is the actual IP address of your Android device)
This should produce the following output:
connected to DEVICEIPADDRESS:5555
5) Ensure that your device is recognised by inputting the following command:
adb devices
This should produce the following output:
List of devices attached
DEVICEIPADDRESS:5555 device
6) Build and run your Unity application to the device. Ensure you build your application with Development Build flag enabled and Script Debugging turned on.
7) The device no longer needs to be connected to your development machine via USB.
8) Finally, while the application is running on your device, open your script in MonoDevelop, add a breakpoint, select "Run" -> "Attach to Process" and select your device from the list. (Note that it might take a few seconds for the device to appear in the list. It may not appear in the list if the application is not running or if the device's display goes to sleep).
For some more details and for troubleshooting, see the Wireless Usage section in the Android developers guide for the ADB: http://developer.android.com/tools/help/adb.html#wireless
NB:
The device sends multicast messages and the editor and MonoDevelop subscribe/listen for them. For this to work, your network will need to be setup correctly for Multicasting.
Taken From here
There are other ways also to debug your application in terminal
******************* On MacOS ***************************
Start Terminal from launchpad
First Method
Turn USB Debugging on, on your android device
Connect the android device through usb cable
Go to “platform-tools” folder in Adroid sdk folder by using “cd”
command
Connect the android device through usb cable
type “adb devices” in terminal it will print the list of devices
attached
type “adb logcat -s Unity ActivityManager PackageManager dalvikvm
DEBUG” to see logcat of only unity related stuffs
Second Method
creating an environment variable to access ADB directly
Go to your home directory by typing “cd ~”
Type touch .profile this will create a hidden file named profile
Type open -e .profile this will open the file you just created in
TextEdit
In the file, type export
PATH=${PATH}:/AndroidSdkPath/android-sdk-mac_86/platform-tools
Save file, close TextEdit, Quit Terminal, and Relaunch Terminal
Turn USB Debugging on, on your android device
Connect the android device through usb cable
type “adb devices” in terminal it will print the list of devices
attached
type “adb logcat -s Unity ActivityManager PackageManager dalvikvm
DEBUG” to see logcat of only unity related stuffs
Now you can start your app/game on the target device and Terminal will log all the activities of your app.
Solved!
Install "Visual Studio Community 2015" - Free to use
Install "VS tools for Unity" https://www.visualstudio.com/en-us/features/unitytools-vs.aspx - Free!
Add Package in Unity as explained https://msdn.microsoft.com/en-us/library/dn940025.aspx
Run, attach the debugger and look into the "Error List" window - Log message will appear there as "Messages".
Should the above does not work, check this: https://msdn.microsoft.com/en-us/library/dn940025.aspx , in particular: "Took a while but finally found a very simple thing that I was not aware of - being a newbie - There is a filter button on the error list, which didn't look like it was clickable, so I clicked that and messages are now coming through, who knew?"
I have an app installed on Android Wear Emulator that I can directly run from Start->MyApp. However when I want to start it with voice command i.e. Start MyApp, it keeps waiting for something but does not complete. What could be reason for this?
There is a limitation of the current emulator that it does not support voice actions via the keyboard, even though the text appears on the display. You will need to start the application by clicking on the display, then the red G, and then going to the start menu and picking the app from there. You can also quickly start the application using something like this from your development machine:
adb shell am start -n com.example.android.test/.TestActivity
The watch needs to be connected to a phone (device or emulator) with an internet connection for the voice commands to work.
I'm trying to use Microsoft's Remote Display Control (version 2.03, copyright 2000) to view my Windows CE device on the desktop (not only is it nice for my "regular" handheld device, because it makes the display easier to see, especially in zoom mode, but it is even more important for the other devices I have to test, whose screen is too dim for me to make out exactly what's on the screen (it's like the vision test from h311) - which is necessary for debugging, of course) but for some reason I am not able to enter key strokes on the device while it's connected to the desktop. I can enter them neither on the desktop/in RDC nor on the handheld device itself while connected via RDC.
This, of course, is untenable (no pun intended).
The .exe is created in XP Mode, copied to a "holding tank" in Windows Explorer on the Windows 7 machine, then copied from there to the handheld device.
Then I connect from the handheld device by selecting Start > Programs > cerdisp > selecting OK in the "Remote Display Control" dialog, then Connect, then OK (and I do connect), then run the app on the desktop in the "WindowsCE" window that RDC supplies. It allows me to select menu items, but the keyboard is broken/mute...???
Is this a known bug? Is there a workaround? The desktop is a Windows 7 machine.
Doing a "cold boot" of the handheld device caused it to come back to responsiveness, keyboard-wise. These devices are betimes more peckish than a put-upon puddle of Platypi.