How do I control Transmission Power based on certain parameters?
Do I need to use Mixim? If so, is there any tutorials on it?
OR
Is the only appropriate place to do it is in the mac1609-4 file in the TXPOWER parameter? If that's the place to do it, then how can I get vehicle position to do it? For example I want the transmission power to be 10 at point X and Y on the road.
Thanks in advance.
An application can set the transmission power for every message sent via the 1609.4 MAC layer by attaching a PhyControlMessage object (as a control message); see here for an example. Alternatively, you can alter the default transmit power via the Mac1609_4::setTxPower method; see here for an example.
An application that inherits from BaseWaveApplLayer can read the current position via its BaseWaveApplLayer::curPosition attribute.
Related
IBM's documentation on ALTER CHANNEL goes to commendable length explaining the various available alterations, but does not offer a single example -- certainly not for C++-users.
Suppose, I want to change the MCAUSER from the default (OS username) to another string, what would the function-call look like?
The documentation you link to in your question is the MQSC command reference. This is designed for scripts.
Please also note that the default value of a channel's MCAUSER field is actually blank, not the OS username. Because it is blank, then in the case of a SVRCONN channel, when a client application connects, the OS username flowed from the client, will be used for the MCAUSER for that running instance. You cannot change this behaviour using ALTER CHANNEL from your client application. I note this, in case this is the reason you are thinking to use ALTER CHANNEL.
If you want to write a program to make a change to an IBM MQ object, such as a channel, you would instead want to make use of a different, but equivalent interface called the Programmable Command Format (PCF). The equivalent command reference page is here.
There is an example C++ PCF sample here - look for SrvPCF
In short, psuedo-code, you would write a program as follows:-
MQCONN(Qmgr-name)
MQOPEN(Reply-Q)
Build PCF message for MQCMD_CHANGE_CHANNEL
with MQCACH_CHANNEL_NAME
with MQIACH_CHANNEL_TYPE
with MQCACH_MCA_USER_ID
MQPUT1(PCF Message to SYSTEM.ADMIN.COMMAND.QUEUE)
MQGET(wait for reply on Reply-Q to say whether it worked or not)
I'm looking for a way to get the Startup type of a service using c++. I am able to get the SERVICE_STATUS data from a ControlService() call, but the data does not include the startup type. I'm aware there is a way to get the Startup Type using windows power shell, maybe I should make a c++ method that makes that power shell call? Is that the best way to do it?
You need to open the service with OpenService() requesting SERVICE_QUERY_CONFIG access, and then you can use QueryServiceConfig(). dwStartType is one of the available fields of the returned QUERY_SERVICE_CONFIG structure data.
I am using Wowza Engine 4.5.0 and I am trying to change the chunk ID numbering based on incoming packet time, instead of the default sequential number that cause problems when restarting the encoder.
From something like this
...media_w112312312_b1024000_7.ts
...media_w112312312_b1024000_8.ts
to a timestamp notation where the chunks continue even after a restart
I read about the property cupertinoCalculateChunkIDBasedOnTimecode, I follow the instructions in this guide to configure it:
https://www.wowza.com/docs/how-to-configure-apple-hls-packetization-cupertinostreaming#livepropref
but it does not work or I am doing something wrong. Has anyone used the property
cupertinoCalculateChunkIDBasedOnTimecode successfully?
many thanks
I have used 'cupertinoCalculateChunkIDBasedOnTimecode' property and even if I restart my encoder, players are able to pick up the stream and play successfully.
The below page will help you in using it properly
http://thewowza.guru/how-to-set-stream-timecodes-to-absolute-time/
I am developing a tool that displays a status about various hardware components on a system we use at work. Currently, we have 16 touch screen monitors (all by 3M) plugged in to a Windows 10 box. I need to verify that any given monitor has an associated touch screen recognized by windows. This is to assess the system for any hardware malfunctions i.e. bad cable, bad USB port, bad Monitor, etc. We see this more than we would like to admit, usually where a monitor's display will be working fine but the USB controller on either end drops out and needs to be reset by unplugging/plugging back in
Unfortunately my code posting will be limited due to work constraints.
I can enumerate all of the monitors plugged in to the system via winapi's EnumDisplayDevices and EnumerateDisplayMonitors. I am able to build a list of all the HID touch screen devices using HIDApi.
From here I have no direction on where to go to link these two things together, if it is even possible. My first thought was the HID device information should have some sort of identifier shared by the results of calling the EnumDisplayDevices and EnumerateDisplayMonitors, but I have not found this to be the case. Another possibility would be to compare the coordinates/size of a monitor to a region that one of the touch controllers is responsible for. Again, not sure if that is possible.
In short, is there a way to associate a Touch device with it's corresponding monitor via c++?
I think you were just lucky that this driver suffix matched your monitor configuration. In my Windows 10 multi-monitor setup I get wrong displays when I look them up with this number in the driver entry as you described.
A reliable way for associating a HID device with a display seems to be:
Call GetRawInputDeviceList() to obtain the HID devices
Call GetRawInputDeviceInfo() with RIDI_DEVICEINFO to determine Usage and UsagePage
Call GetRawInputDeviceInfo() with RIDI_DEVICENAME to get a device string in the form \\\\?\\HID#VID_0EEF&PID_7200&Col01#6&152cc7f9&1&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Query the registry for the mapping table at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wisp\Pen\Digimon and look up the display device name. In my case the HID names are all prefixed with 20- there but the remaining part seems to match the name queried by GetRawInputDeviceInfo() exactly. As a fallback method in case there is no match, I also parse the middle part as Clay Brooks described in his answer.
Call EnumDisplayDevices() with a null pointer for lpDevice and 0 for dwFlags in a loop until the function returns zero.
Within each loop iteration, call EnumDisplayDevices() again with the current device as lpDevice and EDD_GET_DEVICE_INTERFACE_NAME for dwFlags and observe that it returns a DeviceID in the form \\\\?\\DISPLAY#ELO2243#5&607b301&0&UID24833#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
Loop until a HID <-> display match is found and take the DeviceName returned by the "outer" EnumDisplayDevices() call which should be something like \\.\DISPLAY3
After the suggestions in the comments and looking deeper into the registry, I've found a way to link Touch controllers to a monitor.
Using HIDApi, you can poll the system and find a list of all the Touch Controllers you need to monitor. I filtered by the VID of the monitors we are using. A sample return value for the path looks something like this:
"\\?\hid#vid_0596&pid_0520&col02#8&33d9e616&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}"
The bold part can be used to link to the entries in HKLM/Software/Microsoft/Wisp/Pen/Digimon. An example entry is this:
"\\?\HID#VID_0596&PID_0520&Col03#8&33d9e616&0&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}" "\\?\DISPLAY#MSY1C2B#7&1083071f&0&UID524#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}"
The first bold matches the data found through HIDApi and the second set of bolding, the monitor name and a UID, is listed in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY. Under here you can use the combination of monitor name and UID to find the Driver entry. Below is a sample driver entry:
{4d36e96e-e325-11ce-bfc1-08002be10318}\0010
The last bold number can then be used to match up with a DeviceID returned from EnumDisplayDevices(). Below is a sample DeviceID:
"MONITOR\MSY1C2B\{4d36e96e-e325-11ce-bfc1-08002be10318}\0010".
Then you can use this bolded section to match up to names of monitors returned from EnumDisplayMonitors().
I'll try to keep this as short as possible.
I have an app that has worked for years with a single mouse input. I am looking to incorporate the ability for my users to use other forms of input, such as interactive projectors, touch devices, or pretty much anything that provides WM_INPUT messages when you register for them.
The general idea I had was I would have a list of Vendor IDs and/or Product IDs that I would handle with Raw Input (which provides VID/PID, device handle and other information) for each message (WM_INPUT) received. Any devices that are not handled in the Raw Input code would be handled in the Mouse Input code (WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_RBUTTONDOWN, etc).
Ideally, I would be able to leave all of my Mouse Input code as is, or close to it. This way, if a user plugs in two mice, or a mouse and an unsupported pointing device (meaning my Raw Input code doesn't handle it based on VID/PID) the devices would both use the same system cursor. Any device that is known by my Raw Input code would be given separate cursors that exist only within my app.
The problem is simple: Mouse Input does not provide any information about the source of the message (such as WM_MOUSEMOVE, etc). Knowing that the message originated from touch helps (I have this implemented) but is definitely not enough. I need some kind of unique identifier. If I could know the source of the Mouse Input, I could only handle Mouse Input from devices that aren't on my list of known devices, and I could only handle Raw Input that are on my list of known devices.
Unfortunately, I cannot seem to find a way to achieve this.
Any ideas?
Thanks for your time sorry for the lengthy post.
TL;DR - Can you identify the source of Mouse Input (not Raw Input) in Windows? Determining whether or not the source is touch is not enough information, I need some kind of unique identifier.
Mouse Input - http://msdn.microsoft.com/en-us/library/windows/desktop/ff468877(v=vs.85).aspx
Raw Input - http://msdn.microsoft.com/en-us/library/windows/desktop/ms645536(v=vs.85).aspx
I don't know of any API for getting some sort of device id after the fact.
You could use the fact that WM_INPUT messages come before all other input messages, and when you handle WM_INPUT you could use GetRawInputDeviceInfo and a hash of the name returned by RIDI_DEVICENAME to use as a unique id. Or, you might be able to use the hDevice member of the RAWINPUTHEADER structure.
edit2: The answer to this question is "Not possible", you can't do it. Don't bother trying, but if you do and I'm wrong please explain. The fact of the matter is you can't rely on Windows to provide messages in any particular order consistently, which is what I was attempting to do. This bit me big time. Either use raw input (WM_INPUT) or use mouse messages (wm_mouse) don't try to combine the two somehow.
I never really got the answer I wanted, but I got something that works so I thought it was worth sharing.
I am working on a huge assumption, as I can't find any documentation from Windows to support this assumption (and probably wouldn't really even trust it if I found documentation from windows). To my understanding, when a mouse event is generated at the lowest level it comes through the system as a raw input message first (WM_INPUT). After the WM_INPUT message is posted, the OS gets the message and applies the ballistics and whatever else it does before a WM_*MOUSE* message is posted. The huge assumption is that this process is serial in that it is always 1 WM_INPUT message followed by 1 WM_*MOUSE* message in the queue.
With this assumption I am working with the following:
When an input message is received, store all relevant information about the source device as the "current input information"
When a mouse message is received, process it using the "current input information" as the source of the mouse message
This allows me to use n inputs in my application independently.
I'd also like to add that per Brandon's suggestion I am using the hDevice member of the RAWINPUTHEADER structure to uniquely identify each input. Since a unique device can have multiple inputs, I have yet to come up with a good way of uniquely identifying each device. VID/PID doesn't work because you can have 2 of the exact same device with multiple inputs each plugged in. I'm still working on this, see Windows HID Device Name Format
Please let me know if anyone would like me to elaborate!
edit: not marking this as the answer since I believe the correct answer is "Not possible"