|
How is he going to measure that short of some expensive tools that can test for that type of thing? Is there an easy way to check that?
|
|
|
|
|
Unless the modem has a debug mode that shows it probably not.
You know, every time I tried to win a bar-bet about being able to count to 1000 using my fingers I always get punched out when I reach 4....
-- El Corazon
|
|
|
|
|
Rex - come back to the lounge. We miss you - honestly.
|
|
|
|
|
Here in the UK the quoted line speed is the ATM transit speed - we use PPP over ATM (PPPoA). There's overhead on top of that to actually support a DSL link. So my quoted speed of 8168kbps reported by the router is actually about 7.5Mbps usable speed. Maybe your provider is doing the same.
(I live about 100m from my telephone exchange.)
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Mike Dimmick wrote: Maybe your provider is doing the same.
Like I've already indicated, I know the reason why there's a difference between advertised and actual speed. That's not my question.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: Herein lies the question: why are they not providing a full 768K connection when it has already been proven that a 1.3M connection is possible?
I it's due to the line configuration. See if ADSL has built in overhead. I think it actually does. There may be an automatic percentage in loss simply because of the asymmetric nature of the lines. I'm not sure of this either but perhaps they run the lower speed off other equipment.
Optionally you may have spyware or malware that is using bandwidth you just cannot see. If it's rootkitting on a machine you will never know. You'll see a bandwidth hit. Have you tried doing packet capture to see? Put another device between your router and the DSL modem and make sure that device has two NICs and can do packet capture. You might be surprised but what you find.
|
|
|
|
|
It's not "noise", it's not "distance from the DSLAM". The plain and simple truth is that it's FRAUD.
The say "up to" 1.5M down, but truth in fact, you'll NEVER see 1.5M down because there is a speed overhead that they force YOU to soak up. They only say "up to" because that's what they have your connection throttled to. The same goes for cable ISPs, so don't assume that switching to another provider is going to solve the underlying problem.
The long and short of it is that we're being ripped off.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
The one that gets me angry is hard drive size. Yeah sure it says 750 gigs but once it's in and running actual size is more like 700 and generally a lot less. That's the rip-off!
|
|
|
|
|
yeah. Sitting in my junkbox I have an ancient 4.3 (4.0)GB Drive that appears to've been the last stand of the western digital engineers against the marketing drones decimal measuring.
You know, every time I tried to win a bar-bet about being able to count to 1000 using my fingers I always get punched out when I reach 4....
-- El Corazon
|
|
|
|
|
Hi, I have a problem with my computer that is shutting down immediately like disconnect this computer from the power source. I suspect that my computer have a problem with power supply. But I'm not sure whether it come from the power supply or not because when I turn on my computer around 5mn its shutdown immediately.
Does anyone know how to test the power supply to make sure it is working properly or not?
Thank in advance
|
|
|
|
|
To check voltage levels, go to the system BIOS, the voltages will be shown alongside what they should be.
If they seem normal, try disconnecting all power supply connections and reconnecting them: you may have a loose connection.
Also: my brother's laptop had a similar problem (of suddenly turning off) that was caused by overheating. Let your computer cool down for about an hour, then boot it up and leave it on the desktop with only the task manager running (on the 'performance' screen)... the CPU usage should be less than 10% average... if the usage is more than this (a program is taking more CPU than it should) and it continues to turn off suddenly, the fan cooling your processor may be running slow, or the heat-compound connecting the heat-sink to the processor may be getting dry.
Hope this helps.
Matthew Butler
|
|
|
|
|
|
Hello
I need to write an application to recognize which USB HID Mouse is using at the moment. At least two mice are connected to the PC at one time. It should work in background and show in the background window or write to file movement positions of currently moving mouse in the system.
My way of thinking is to:
1) create main application (exe or DLL) with window which will:
- detects all Raw Input HID mouses but not regist them yet
- recieve messages from its window and from hooking DLL
- detects in seperate thread which window is currently on top (Foreground)
- if new window is on top call first RegisterRawInputDevices with Handle to new window then call "CreateHook" from DLL to reset Hooks to new thread
Below the code for the thread detecting top most window:
<br />
while (Running) {<br />
Sleep(1000); <br />
hWnd_curr = GetForegroundWindow();<br />
if(hWnd_curr != hWnd_old) {<br />
hWnd_old = hWnd_curr;<br />
GetWindowText(hWnd_curr,window_name,sizeof(window_name));<br />
<br />
Rid[0].hwndTarget = hWnd_curr;
<br />
if(!RegisterRawInputDevices(Rid, 1, sizeof (Rid[0]))) {<br />
_snprintf(logevent,sizeof(logevent),"Register Raw Input Devices FAILED");<br />
Write2File(logevent);<br />
continue;<br />
}<br />
<br />
if(pCreateHook != NULL && (dwThreadId = GetWindowThreadProcessId(hWnd_curr,&dwProcessId))!=0) <br />
msgHook = pCreateHook(WH_CALLWNDPROC,hwndMain,dwThreadId);<br />
<br />
}<br />
}
Unfortunately I cannot register raw input devices to the other window than the one I created in main program.
2) create a DLL that that be using Global Hooks for all messages from the window that is on top. DLL will contains one external function:
- CreateHook - clears old hook if not NULL and sets new hook for given threadID
in the DLL there is a callback function for collecting hooked messages which are directly sent to main application
static LRESULT CALLBACK msghook(UINT nCode, WPARAM wParam, LPARAM lParam) {<br />
<br />
if(nCode < 0) {<br />
CallNextHookEx(hook, nCode, wParam, lParam);<br />
return 0;<br />
}<br />
<br />
INFO f; <br />
f.code=nCode; <br />
f.hhook=hook; <br />
f.lParam=lParam;<br />
<br />
cwpMessageParams = (PMSG)lParam;<br />
<br />
if(cwpMessageParams->message == WM_INPUT) <br />
SendMessage(mForm, messageCode, (WPARAM)(cwpMessageParams->message), (LPARAM)&f);<br />
<br />
return CallNextHookEx(hook, nCode, wParam, lParam);<br />
}
The second problem with is that this callback never gets WM_INPUT even if raw inputs are register to the window created in main application.
Any suggestions? Or maybe my way of thinking is wrong??
How is it possible to get at least the name of currently working mouse??
Thanks for any help
Maciek
|
|
|
|
|
maszup wrote: How is it possible to get at least the name of currently working mouse??
AFAIK, it's not possible to find this out. All mice are "currently" working, even if they're not moving. The "mouse move" message you're looking for in the window never have any kind of id of the mouse that sent the message. It's simply raw data on the cursor movement. There is no source information on what generated the movement.
|
|
|
|
|
But it is possible to get mouseHandle from raw data sent by notification WM_INPUT. It is working only for a window that I created.I already wrote an application that shows me last mouse that was used in my application. But if i focus on other window it stops receiving notifications. I would like to know the global movement of all mice in WindowsXP. That's why my proposal was to use Hooks but it seems to unavailable to register raw input on other windows
If it is possible to do I could init all mice at once and read position from all of them in the loop. Then just show the mouseHandle of last detected movement or click. I even tried to work with HID drivers and CreateFile function but it returns an Error: Access Denied because Windows uses the mouse in exclusive mode. Described here:
http://www.lvr.com/hidfaq.htm
Maybe it is possible to use HIDd_GetFeature and reports to read mouse position?
How would you solve that?? I have to do it till end of week.
Thank you for your interest
Maciek
|
|
|
|
|
|
I don't fully understand your answer about filter driver. Can you give me some link or examples about that?
Actually I just need to have 3 functions: Init, Read and Close and maybe the easiest solution would be:
Init - search all mice, connect to all of them and run a thread where I read position from all mice
Read - return last position
Close - close thread and mice
It should not be a service. The application should be DLL called from other programming language.
The problem is only: is it possible to init all mice and read somehow position from them?
|
|
|
|
|
First it should be known that I have never used RegisterRawInputDevices and the corresponding raw input functions. They look very intriguing and perhaps worthy of some research. However with that being said I do have experience with HID device drivers and interacting with usermode.
maszup wrote: I don't fully understand your answer about filter driver. Can you give me some link or examples about that?
There is a sample mouse filter driver included in the DDK at: C:\WINDDK\6001.18000\src\input\moufiltr which could be modified for the previously proposed behavior.
maszup wrote: It should not be a service. The application should be DLL called from other programming language.
The service I was suggesting was for interacting with a filter driver. If you continue along the usermode path then a service would not be the optimal solution.
maszup wrote: The problem is only: is it possible to init all mice and read somehow position from them?
RegisterRawInputDevices is designed for windows which mean it sends a WM_INPUT message to windows which have registered for notification. Are you suggesting that you would like to hook all window creation and override the WindowProc of each and every open window and register for this notification? It actually sounds like it may be possible although grossly inefficient.
If I were you I would research the AppInit type of DLL and hook CreateWindow and CreateWindowEx by way of IAT in each and every process. I have been reading the MSDN located here:
http://msdn2.microsoft.com/en-us/library/ms645543(VS.85).aspx[^]
All of the information there highly interests me as I have not used this type of input before. From what I am reading I do not see any reason why the method you have proposed would not be at least partially successful for well-behaved windows.
I stand by my prior statement that a filter driver would be the best way of achieving this. I am interested in a follow-up if you are successful with this hooking method. If you actially get this working please contact me and let me know.
Best Wishes,
-David Delaune
|
|
|
|
|
I only wanted to hook the window that is on top. So only one window. And then set some filter to hook only one notification. After receiving i would send it immediately to previously created (hidden) window to do something with that. But i cannot register raw input for other window and that kills my idea!
I will read about device filter and try to do something with it tomorrow.
Thank you both for help
Maciek
|
|
|
|
|
I was trying to understand the idea of creating the filter driver but the problem is over me. I didn't do anything in kernel-mode before so all this stuff is very wired to me.
I've read few articles from the codeproject about Driver Development and stopped on filter drivers. I was also trying to understand the mouse filter example from DDK but few main issues are misery to me:
1) how do i know to which driver in driver stack should i connect to get access to the HID mouse? Do I really need very low access to USB port?
2) how do i interface with the lower driver? what is the structure the lower driver offer to me? how can i know what is the context?
3) how to get the information about the position from the lower driver? from its context?
4) the example mouse filter is for hooking the PS2 mouse? is it possible to get access to a driver that doesn't distinguish to PS2 or USB mouse?
Thx
Maciek
|
|
|
|
|
maszup wrote: 1) how do i know to which driver in driver stack should i connect to get access to the HID mouse? Do I really need very low access to USB port?
I already explained this. No, all you would need to do is attach to \\Device\\PointerClass0 and all other corresponding pointing devices. You can look them up in the registry when you install the driver and iterate through all of them. They are located at:
HKEY_LOCAL_MACHINE\HARDWARE\DeviceMap\PointerClass
maszup wrote: 2) how do i interface with the lower driver? what is the structure the lower driver offer to me? how can i know what is the context?
You do not need to interact with the lower drivers. With an upper level filter driver you only need to copy the input packet and save or filter it.
maszup wrote: 3) how to get the information about the position from the lower driver? from its context?
In the 'moufiltr' example in the DDK look at the function MouFilter_ServiceCallback. You have a pointer to a MOUSE_INPUT_DATA struct which will tell you the last mouse cursor position. You need to save a copy of this. You will also need to implement a new IOCTL command which will pass a buffer to recieve it.
maszup wrote: 4) the example mouse filter is for hooking the PS2 mouse? is it possible to get access to a driver that doesn't distinguish to PS2 or USB mouse?
Although the sample documentation references PS2 it actually doesn't matter. The driver is built for a HID input device of FILE_DEVICE_MOUSE == 0x0000000f
It is exceedingly simple to modify the example in the DDK to do what you require. All you need to do is save a copy of MOUSE_INPUT_DATA each time one arrives. And add 1 more case statement to the function in the example called MouFilter_InternIoCtl() which will handle a new control command. Your usermode application can simply pass a pointer to a memory buffer and your IOCTL handler will copy the data to the usermode program or service. You can even pass the entire MOUSE_INPUT_DATA struct if you wanted.
Make sure to watch out for race conditions when you save a copy of that struct... when a HID driver locks up you sometimes cannot even get into Windows without removing it. I generally do my driver development in VMWare. When I first started developing drivers I was lock out of my computer several times, heh. Its funny now but it wasn't back then.
Anyway I would recommend reading the article by Toby Opferman about implementing an IOCTL.
http://www.codeproject.com/KB/system/driverdev2.aspx[^]
Its not as difficult as it seems. If you have any questions you can post them here or contact me via e-mail.
Best Wishes,
-David Delaune
|
|
|
|
|
Hmmm... Didn't know about the RAWxxx structures. It looks kind of promising, though you'd have to make constant use of the GetRawInputDeviceInfo function to get the name and device information for each mouse message. I can see this turning into a large problem very quickly.
maszup wrote: But if i focus on other window it stops receiving notifications.
True. The RegisterRawInputDevices function will only work on the thread that called it, aka, your application. It will not intercept messages going to other processes (other threads) since each process (in user mode) thinks it's the only process running in the system. When the input focus is moved to a different application window, those WM_INPUT messages only go to that window. They don't propogate system-wide.
The only way to see mouse messages system-wide is to implement a MouseProc and use the Windows Hooks functions (SetWindowsHook). But, in doing so, you also lose the ability to get the Raw Input data since raw isn't supported by the hook messages.
maszup wrote: Maybe it is possible to use HIDd_GetFeature and reports to read mouse position?
Mice don't have a position. The cursor on the screen has position. Mice just say how far and in what direction the mouse moved since the last movement report.
I'm with Randor on this one. It looks like the only possible way to get this to work would be a filter driver.
|
|
|
|
|
I'm looking to develop a c# basic wireless remote control with an input screen that sends and receives signals to and from a pc. For a simple example of what I mean, click here.
I've been a c# software developer for 5 years now however I've never delved into the realm of hardware and electronics. Does anyone know of any books or online tutorials I can reference to point me in the right direction towards building something like this?
Thanks.
-Goalie35
|
|
|
|
|
If you don't have much experience with hardware electronics, what you want to do will be difficult... but definately possible.
I haven't seen any pre-made remote controls about (with screens) so I am guessing you want to build your own... in which case you will need to look at using microcontrollers to do the data processing/writing to the lcd/reading button presses/sending and receiving data etc.
I would recommend looking at PIC microcontrollers, which after having used for many years, are perfect for this job... you will need a programmer/compiler for them and knowledge of either their assembly language or C (depending on the compiler). [PIC datasheets are useful here]. {I've used this PIC Link[^] regularly and it is powerful enough to run an LCD module... a look at the datasheet (instruction set) will give you an idea of what your facing}
Depending on your knowledge of circuits/electronics, you might want to start by following online tutorials for 'basic' electronics as you can (very easily I have found out in the past) damage components if incorrectly connected.
I don't know what your knowledge on electronics is like so... beginner[^], Intermediate (PIC)[^], Really relevent[^].
Also, for some ideas... IR receiver module[^], colour screens need more processing power (Monochrome display[^]), more PIC stuff link[^].
Specifically for your project, since you need two-way communication, small radio transceiver modules link[^] are available (but quite expensive)... each 'remote' would have an 'address' (eg. specified by on-board switches) which would be transmitted serially along with data... depending on the radio module... some could (with little extra components) connect directly to a serial DB9 port (where you can use the SerialPort class).
I've just recently completed my A-level elecronics project that is similar to what you want to do ('remote control' communicating with a computer etc) so if you need any advice I can help.
What you are trying to do is abmitious. Good luck.
Matthew Butler
|
|
|
|
|
Hi Matthew.
First off, thanks for the information! It's provided me with a great starting point (I've found a plethora of info just by googling and even YouTubing some of the keywords you gave me). My only concern currently is the total cost to put together one of these and I'm hoping perhaps you can offer some advice on this point.
My initial hope was to have the cost per unit at around $30 however that doesn't look likely after reviewing some of the prices of the parts you've mentioned.
I've decided to scrap the color LCD display and downgrade to black and white, which looks like I can save some money there but the kicker seems to be the radio transmitter. The ER400TS goes for around $20-$30.
So I'm just curious...do you know of anything cheaper than that particular radio transmitter that could still accomplish what I'm looking to achieve?
Unfortunately, after discussing this project with others, the general consensus seems to be that if I can't assemble each unit for $30 or less, it's going to be difficult to sell. I could possibly go as high as $40 but even that's a little high.
Thanks again for all your help so far.
Regards,
-Ryan
|
|
|
|