while developing for the new Microsoft Surface Dial I noticed the device going to sleep after a few minutes and taking about 1-2 seconds to wake up again after an interaction with the device. This is insufficient for my specific use case, where the application has to give immediate feedback.
I've tried turning off the energy settings for the bluetooth device in the device manager, but the problem persists. Is there a way to turn this off, either in code or in some other way?
Unfortunately there is no way to solve the issue without a Microsoft firmware update.
The unit use a Nordic Semiconductor nRF52832 Bluetooth Low Energy SoC, is possible change that on the chip, but with a firmware update. Really sorry but is the only way.
Related
I've combed through the SDK and haven't found anything promising. I'd like to keep a Mavic Air on a "standby" mode, if at all possible. I see that I can power off the motors, but I'm not sure how significantly that will drop the current consumption. Has anyone tried to sleep a DJI programatically with the SDK?
As far as I know, the drones from DJI do not have a "standby" mode.
I'm working with a Mavic Pro and after some tedious research on the internet I've come to the conclusion that the only way to keep a DJI drone powered an arbitrary amount of time is to use an autonomous charging platform.
From my experience with Mavic Pro, the battery of the drone lasts ~1.5-2h when not flying and the motors are kept off. The remote Controller discharged faster while being kept on (~1.5h).
The Mavic Pro Remote Controller has two USB outputs, which enables connecting to the smartphone and charging simultaneously.
A related question can be found here:
Programming a complete autonomous dji drone? take off - follow a flight path - land
I'm trying to make a wireless system that detects if someone is sitting on the toilet or not.
The idea is using a NodeMCU connected to a wifi-network, updating a database with info about the state of the toiled, "busy" or "not busy".
I would like to know if NodeMCU supports low power mode via interrupts so that I could maintain the system with a battery.
Thank you in advance, :)
In low power mode nodemcu cannot be waken up via an internal event.
You have to trig it externally via a button, a sensor interrupt, etc.
So, I assume that you'll need to use a sensor like PIR for motion detection, if you got a battery friendly sensor, you can wake it up with trigging GPIO16 when it lays in deep sleep.
I am trying to use my mac (MacBook Pro (Retina, 15-inch, Mid 2014) to connect to a device for an application I am trying to write however when setting up my CBCentralManager I am always returned with The platform doesn't support Bluetooth Low Energy. If i check my system information under bluetooth it clearly says that My computer does support Bluetooth low energy by this statement (Bluetooth Low Energy Supported: Yes).
What am I missing here is this me messing something up or is this something seriously wrong with my computer?
Also what can I do to bypass this annoying only Low Energy Devices and just start scanning for peripherals, seems kinda silly that it wont let me set a property to skip Low Energy.
Thanks for your time.
Sometimes the Bluetooth hardware can get messed up. Try a reboot and if that doesn't work a PRAM reset.
I am experiencing lot of troubles detecting BLE devices with a CSR8510 chipset. I don't have much knowledge in bluetooth hardware/stack and osx systems. I made a lot of research to solve my problem but I can't find any information specifically related to my issue.
Here is all the informations about my setup :
The dongle is plugged in a Macbook Pro late 2011 (mavericks). I made all the necessary to make the dongle work :
HCI bootmode
com.apple.bluetooth.plist deletion and reboot
I used Bluetooth Explorer to change the Host Controller (default internal chipset -> CSR8510)
Now the dongle is fully recognized by the system, I can use my Magic Mouse (all functionalities work), but I am not able to detect my BLE chest belt (Runalizer blue).
When I launch a scan with the Device>Low Energy Devices panel in Bluetooth Explorer or the demo app indicated by the belt manufacturer I don't find anything.
Demo app : https://developer.apple.com/library/mac/samplecode/HeartRateMonitor/Introduction/Intro.html
To be fully exhaustive my Xperia SP works perfectly with the belt.
I tried to dig into kernel extensions and I've found in System/Library/IOBluetoothFamily.kext/PlugIns two interesting kext :
CSRBluetoothHostControllerUSBTransport.kextCSRHIDTransitionDriver
I do not know if it is relevant or if it could help me but since they start by "CSR" I thaught that it may be related.
I hope someone can help me. It is bothering me so much because I am not able to do the job I was willing to do (gather data from the belt and statistical processing).
Thanks for your attention.
In Windows XP SP3 is there a registry key or some setting, maybe even at the device level in the registry, that an EHCI USB 2.0 High Speed hub can be enumerated as a UHCI or OHCI full speed device at the host level?
I am seeing an issue where a USB 1.1 full speed device is deadlocked due to infinitely NAKd split transactions with the transaction translator buffer on a high speed hub. This only happens under certain circumstances the full speed device is connected behind a 2.0 high speed hub only in XP SP3. I have opened an issue with Microsoft and they have confirmed this is a known issue and there is no Hotfix for the issue (nor will one be developed). It has been corrected in Vista+.
If the device is connected directly to the host controller, or has a full speed hub upstream of the high speed hub the problem goes away (because there are no split transactions). So, if there is a way to force the high speed hub to enumerate as a full speed device then it may help us out.
Furthermore, the hardware design is set in stone. Systems have been developed and there is no way to insert a full speed hub chip anywhere in the design, or hook up the devices directly to the root hub. And finally, it is not an option to upgrade the OS on the systems.
After some work and research with help of Microsoft the current conclusion is that there is not a way to do this.
The workaround that we will be using is to perform a PnP reset on the bus to stop the infinite NAKs, then reopen the port to begin communication again. This is not very clean, but it will solve the problem.