I'm developing a C# application that logs data coming in on a USB serial-port. I'd like to be able to run it on a laptop, and have it continue to operate even when Windows 10 turns off the screen to save power.
I've already taken several steps to make this happen:
(1) Call SetThreadExecutionState(EXECUTION_STATE.ES_CONTINUOUS | EXECUTION_STATE.ES_SYSTEM_REQUIRED | EXECUTION_STATE.ES_AWAYMODE_REQUIRED) when the port is opened - see e.g. this answer. This seems to work, preventing Windows from going to sleep and keeping the application running.
(2) Disabled "USB Selective Suspend" in Windows' "Power & sleep settings" -> "Additional power settings" -> "Change plan settings" -> "Change advanced power settings" -> USB, for both "On battery" and "Plugged in".
(3) From Device Manager, disabled "Allow the computer to turn off this device to save power" in the "Power Management" settings of the USB-serial device.
And yet... when the "Screen turn-off" power-saving timeout elapses and the laptop screen goes dark, the serial-port closes! My program handles this as "device unplugged", but clearly it hasn't been. I've run Wireshark and used the "USB PCAP" feature to monitor the relevant USB bus, and I don't see any SUSPEND occurring.
So is this an undocumented feature of Windows Power-Management, or of the C# SerialPort class? Or is there a trick I've missed?
False alarm! My function that detects Win32_DeviceChangedEvent was not discriminating exactly which device had changed. Modified it to check "serialPort1.IsOpen" property, and only shows "Device unplugged" if the port has been closed.
Related
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)
I am trying to install and run my Windows Store app on a real Surface RT device. I have installed the Remote Debugger for ARM and its running, with no authentication on 4018.
Visual Studio fails to see the device, fails to connect and deploy.
In Windows on the desktop, I cannot ping and my port-query tool says 4018 is down, the host is unreachable.
What can I do? Why didn't they just use USB like Windows Phone development?
Microsoft don't tell you this, but you need to configure some firewall rules for the device to become visible on the network. Of course, you won't find anything by searching for "firewall" from the Start screen, but it can be found as a Snap-in for MMC.
You could turn the firewall off for the Private Profile, i.e. your local, private home network, since your home router already has a firewall and the one in Windows is just there to annoy people; cause family members to call and interrupt your dinner while they struggle to get things working on their budget new Windows 8 laptops (with no touch screen), or you could set the right rules manually.
However there's an easier way, turn on the oh-so-discoverable - especially on a tablet that's not even supposed to even have a desktop - "Network discovery and file sharing" by opening Windows (file) Explorer and clicking on the Network node on the left. A bar will pop up to remind you that Windows is getting in the way and that you can click it to make stuff work again; this configures the firewall for you.
Note that turning on "Network discovery..." via the option under Control Panel > Network Sharing Blah > Instantly-forgettable Name doesn't work. No one knows why.
By now you should be able to ping you device and the port is open, just in time for your battery to have gone flat.
Important Edit
Today, its not working again and pop-up doesn't appear again so I cannot try the same trick. My port query tool says the port is not open (it was the other day).
So I tried this, but its not working for me.
# Elevated Command Prompt #
netsh advfirewall firewall add rule name="RemoteDebugger" dir=in action=allow protocol=TCP port=4018
That says 'Ok.' but the port isn't open.
So I went into MMC and added the Firewall snap-in and its enabled itself again for the Private profile.
Then I noticed that it doesn't turn off. If you flip it to Off and hit Apply, it does nothing!!
There are now two inbound rules for the Remote Debugger, the one I setup and another for the executable. Still, doesn't work.
This thread:
http://answers.microsoft.com/en-us/windows/forum/windows_rt-networking/possible-windows-firewall-bug-on-surface-rt-blocks/caa8b40c-dacc-4d19-a751-7a04f8ef00e4
There's an answer stating:
Open Control Panel -> Administrative Tools -> Windows Firewall with Advanced Security.
Click "Windows Firewall Properties" in the main frame
In each of the three tabs of Domain, Private and Public Profile:
1) Note that: If you change "Firewall state", or change "Inbound connections" to "Allow" (inbound connections that do not match a rule are allowed), it is not going to work. The change is immediately lost after you click "OK" or "Apply" to close the dialog box.
2) What you need to do is: click Protected network connections: "Customize", it will show another dialog box, in which you can deselect some network connections. In this case, you can uncheck "Wireless" and leave "Bluetooth" on.
Once you finish step 3, Action Center will pop up an alert, saying Windows Firewall is off or not using recommended settings. You can ignore this alert, or turn it off in "Change Action Center settings".
Though someone on that thread confirm it had worked, it hasn't for me.
Luke
I'm using windows WLAN APIs (Windows Desktop not Metro Apps) to scan WiFi networks.
I'm curious what will be the behavior of the WiFi scan when Airplane mode is enabled before the scan is completed?
I'm trying to create such scenario but it very hard to catch such timing.
Any ideas?
Technically speaking, "Airplane Mode" Takes the Radio Transmitters in your iPhone and changes their frequencies of transmission to frequencies that are sympathetic to Aeronautic Instrumentation, such as Guidance Systems for example.
Due to the frequency change, if you're scanning Networks and then you change the properties of the Network adapter, the adapter has to restart. So, your Scan will be temporarily interrupted.
Test it on your iPhone, download something from App Store and switch modes during the download, see what happens. The Icon will suddenly stop and will display "SEARCHING" and will then re attempt to pick up the connection again.
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.
Is it possible to emulate a device sleeping and waking using the Microsoft-supplied device emulators?
Yes, but you have to generate your own emulator image with a modified kernel (changing OEMPowerOff). Bruce Eitman blogged about it here. You didn't detail your needs, so it's hard to say, but you might be able to provide some form of simulation by manually setting the named power management events.
This is an old thread, but in case anyone else stumbles across it, you can make the Windows Mobile emulators 'sleep' and wake up, though not with the debugger attached.
Close the emulator window while your application is running and save the state. Or, configure power management to sleep the emulator at the desired time; the emulator will close and save its state automatically. If the debugger is attached, it will lose its connection and stop debugging.
Open Device Emulator Manager and click Refresh until the emulator shows up as disconnected (no icon next to it). Right-click on the emulator name and select Connect.
Emulator wakes up and reappears. If your application is listening for the wake-up notification, it will be signaled at this point.
You can also wake up the emulator using Debug > Attach to Process, though this does not always succeed. Either way, by the time the debugger attaches, the wake up sequence will already have executed. If you can get by with debug statements, though, this is easier than modding the emulator image.