In an earlier blog post titled 'Develop location-aware, Metro style apps when your development system doesn’t have GPS', one option I presented for those wishing to develop high-precision location-based Windows Store apps is to hook up an external GPS to your computer. What I want to do now is explore this method in greater detail, and I’m creating a three-part series on doing so with a software application called GPSDirect from TurboIRC.COM Software & Research. In part one, we’ll introduce the GPSDirect sensor driver and learn how to use it. In parts two and three, we’ll look at connecting an external GPS recevier and an Android-based smart phone as a GPS provider.

Drivers Download; Media Download; Support Download; Dealer locator; Drivers // Download. Astra Driver Installation Instructions and Notes (PN D8159 Rev. B7585 Rev A ALLPRO Imaging ScanX Upgrade Wizard Disk. ScanX Trek (Equine) ScanX Trek Driver Installation Instructions and Notes. Allpro imaging driver download for windows.

ACS offers product customization and product development services to meet specific customer requirements. With the help of our competent and experienced engineering team, we have the capability to design and develop new products that will give you a competitive advantage. I went through this diagnostic, uninstalled the USB Composite Device, rebooted the computer, and still only my port on the left hand side works. The 2 ports on the right hand side are still dead, although it says they are working properly in Device properties. Very frustrating. Open Start Settings Devices Printers & scanners. Select the name of the printer, and then choose Remove device. To reinstall the printer, select Add a printer or scanner and then select the name of the printer you want to add. If Windows doesn’t automatically find a new driver after the printer is added, look for one on the device. It is highly recommended to always use the most recent driver version available. Try to set a system restore point before installing a device driver. This will help if you installed an incorrect or mismatched driver. Problems can arise when your hardware device is too old or not supported any longer. Garmin Support Center is where you will find answers to frequently asked questions and resources to help with all of your Garmin products.

Part 1: Introducing GPSDirect

For our GPS solutions we’ll make use of the GPSDirect NEMA Sensor Driver which was developed by Michael Chourdakis at TurboIRC.COM Software & Research. It takes any COM-connected GPS receiver and turns it into a Windows Location Sensor. Though this software was originally created for the Windows 7 Sensor API, it also works with the Windows 8 Location API for both Windows Store Apps and desktop applications. Both a 32-bit and 64-bit driver are provided.

Almost all general purpose GPS units are capable of emitting NMEA 0183 sentances over a serial port. NMEA stands for the National Mareine Electronics Association, and standard 0183 defines a communication protocol for marine devices such as sonar, echosounders, GPS receivers, and its predecessor, LORAN. The NMEA protocol is extremely simple, with messages transmitted in plain ASCII text in the form of 'sentances'. These devices emerged in the days when serial ports were the primary means of interacting with computer systems, and as such even modern devices with only USB connectors still provide NMEA output via a virtual COM port by embedding a USB-to-serial adapter internally. Nearly every USB-connected GPS receiver, commonly referred to as a GPS 'mouse', is really a serial port device.

Download Acr Port Devices Drivers

_{This USB-based GPS receiver shows up as a virtual serial port in Windows.}

GPSDirect is basically a bridge solution. It's middleware that takes a GPS device connected on a virtual COM port and connects it to the Windows Location Sensor. To date, not many manufacturers provide a true sensor driver for their GPS receivers, and GPS receivers that are integrated into tablet and ultrabook platforms are still fairly rare. For those wishing to develop precision location-aware apps-- or even just use them-- GPSDirect represents the best way to make that possible when a native GPS sensor is not available on the system. The down side is that, being middleware, you have to jump through some extra hoops to use it and you can't expect to plug in your GPS receiver and have everything just work. The rest of Part 1 discusses those hoops in detail.

Download and install GPSDirect

From the GPSDirect download page, select the 32- or 64-bit driver as is appropriate for your system. The GPSDirect download is a simple EXE file. There is no installer, nor is there a driver installation procedure (but see 'Running GPSDirect', below), however GPSDirect does unpack a few support files when it executes so I like to put it in a separate folder to keep things tidy. For this example, create a 'GPSDirect' folder inside of your Documents folder and move the executable there.

Running GPSDirect

GPSDirect is a desktop application which includes a user mode driver that installs itself upon demand. Double-click to execute the binary. Windows 8 may ask you to enable location services as shown in the screenshot below. If so, click on 'yes', since location-based applications won't work without the location service.

You will then be presented with the GPSDirect user interface window, a portion of which is shown below. Before the driver can install itself, it has to know which COM port your GPS is connected to, and at what speed it communicates. These parameters are set in the main user interface.

Note that drop-down menu for the connection speed only goes up to 19200 baud, but you can type any value in there. I have used external GPS data loggers that communicate at 115200 baud successfully with GPSDirect. In addition to COM ports, GPSDirect can also communicate with a network-connected GPS device. In this case, enter an IP address for the NMEA source and a port number in the Baud Rate/Port Number box. GPSDirect also includes a simulator mode which sets a random latitude, longitude, and altitude, and then changes them slightly every second.

Select the COM port that your GPS is attached to, provide the baud rate, and then hit 'Install' to install the driver. This step will require administrator privileges since this is the point where the driver is actually installed on your system. If this is the first time you have run GPSDirect, you will also be presented with a Windows Security dialog, asking if you want to install the sensor device. To prevent this dialog from coming up again in the future, you can check the box to always trust software from the author.

Once the driver installs, the GPSDirect driver will start showing up as a location sensor in Device Manager.

Monitoring GPSDirect

When you first run GPSDirect, meaning after you have set your port settings and hit 'Install', you may not see much output. Until your GPS device has started tracking satellites, in fact, it may not appear that GPSDirect is doing anything at all but once your receiver starts acquiring signals the display will update.

The upper right window lists the satellites that have been found by the device, showing their almanac information (satellite number, azimuth, and elevation), and the strength of the signal being received. The lower frame shows the time reported by the GPS receiver, and once a fix is obtained it will display:

• latitude and longitude in decimal degrees (X and Y)
• altitude in meters (Z)
• speed in knots
• bearing in decimal degrees
• DOP (Dilution of Precision, mathematical limits on accuracy due to the current satellite geometry)

It will also periodically print one of the NMEA sentance that was received from the device.

The GPSDirect window will contnue to update as long as the GPS receiver is on and active, though if signal reception is lost it may blank out again until satellite signals can be reaquired.

You do not need to keep this window open. You can close it using the red X (there is no 'close' button) and if you later want to monitor your device, you can simply run GPSDirect again. The driver will remain active until you explicitly uninstall it.

Stopping GPSDirect

Stopping GPSDirect really means uninstalling the driver, and that is done with the 'Uninstall' button. When you press this, GPSDirect closes the COM port, uninstalls the driver, and exits.

Things to keep in mind

• As with any system where an external device is connected to a computer, the stability of the system is dependant on the stability of the connection. If a cable comes out, the GPS receiver powers off, or if the computer goes to sleep, GPSDirect may or may not be able to seamlessly continue. It may be necessary to explicitly uninstall the driver and reinstall to get things working again.
• COM ports do not support multiple connections. If GPSDirect is using a COM port, other software will not be able to, and visa-versa.
• Your virtual COM port will change if you move your USB-connected device between ports. Always verify in device manager that your device is attached to the port that you think it is.

In Part 2, we'll hook up an external GPS using GPSDirect.

§

A minidriver or a miniport driver acts as half of a driver pair. Driver pairs like (miniport, port) can make driver development easier. In a driver pair, one driver handles general tasks that are common to a whole collection of devices, while the other driver handles tasks that are specific to an individual device. The drivers that handle device-specific tasks go by a variety of names, including miniport driver, miniclass driver, and minidriver.

Microsoft provides the general driver, and typically an independent hardware vendor provides the specific driver. Before you read this topic, you should understand the ideas presented in Device nodes and device stacks and I/O request packets.

Every kernel-mode driver must implement a function named DriverEntry, which gets called shortly after the driver is loaded. The DriverEntry function fills in certain members of a DRIVER_OBJECT structure with pointers to several other functions that the driver implements. For example, the DriverEntry function fills in the Unload member of the DRIVER_OBJECT structure with a pointer to the driver's Unload function, as shown in the following diagram.

The MajorFunction member of the DRIVER_OBJECT structure is an array of pointers to functions that handle I/O request packets (IRPs), as shown in the following diagram. Typically the driver fills in several members of the MajorFunction array with pointers to functions (implemented by the driver) that handle various kinds of IRPs.

An IRP can be categorized according to its major function code, which is identified by a constant, such as IRP_MJ_READ, IRP_MJ_WRITE, or IRP_MJ_PNP. The constants that identify major function code serve as indices in the MajorFunction array. For example, suppose the driver implements a dispatch function to handle IRPs that have the major function code IRP_MJ_WRITE. In this case, the driver must fill in the MajorFunction[IRP_MJ_WRITE] element of the array with a pointer to the dispatch function.

Typically the driver fills in some of the elements of the MajorFunction array and leaves the remaining elements set to default values provided by the I/O manager. The following example shows how to use the !drvobj debugger extension to inspect the function pointers for the parport driver.

In the debugger output, you can see that parport.sys implements GsDriverEntry, the entry point for the driver. GsDriverEntry, which was generated automatically when the driver was built, performs some initialization and then calls DriverEntry, which was implemented by the driver developer.

You can also see that the parport driver (in its DriverEntry function) provides pointers to dispatch functions for these major function codes:

• IRP_MJ_CREATE
• IRP_MJ_CLOSE
• IRP_MJ_READ
• IRP_MJ_WRITE
• IRP_MJ_QUERY_INFORMATION
• IRP_MJ_SET_INFORMATION
• IRP_MJ_DEVICE_CONTROL
• IRP_MJ_INTERNAL_DEVICE_CONTROL
• IRP_MJ_CLEANUP
• IRP_MJ_POWER
• IRP_MJ_SYSTEM_CONTROL
• IRP_MJ_PNP

The remaining elements of the MajorFunction array hold pointers to the default dispatch function nt!IopInvalidDeviceRequest.

In the debugger output, you can see that the parport driver provided function pointers for Unload and AddDevice, but did not provide a function pointer for StartIo. The AddDevice function is unusual because its function pointer is not stored in the DRIVER_OBJECT structure. Instead, it is stored in the AddDevice member of an extension to the DRIVER_OBJECT structure. The following diagram illustrates the function pointers that the parport driver provided in its DriverEntry function. The function pointers provided by parport are shaded.

Making it easier by using driver pairs

Over a period of time, as driver developers inside and outside of Microsoft gained experience with the Windows Driver Model (WDM), they realized a couple of things about dispatch functions:

• Dispatch functions are largely boilerplate. For example, much of the code in the dispatch function for IRP_MJ_PNP is the same for all drivers. It is only a small portion of the Plug and Play (PnP) code that is specific to an individual driver that controls an individual piece of hardware.
• Dispatch functions are complicated and difficult to get right. Implementing features like thread synchronization, IRP queuing, and IRP cancellation is challenging and requires a deep understanding of how the operating system works.

To make things easier for driver developers, Microsoft created several technology-specific driver models. At first glance, the technology-specific models seem quite different from each other, but a closer look reveals that many of them are based on this paradigm:

• The driver is split into two pieces: one that handles the general processing and one that handles processing specific to a particular device.
• The general piece is written by Microsoft.
• The specific piece may be written by Microsoft or an independent hardware vendor.

Suppose that the Proseware and Contoso companies both make a toy robot that requires a WDM driver. Also suppose that Microsoft provides a General Robot Driver called GeneralRobot.sys. Proseware and Contoso can each write small drivers that handle the requirements of their specific robots. For example, Proseware could write ProsewareRobot.sys, and the pair of drivers (ProsewareRobot.sys, GeneralRobot.sys) could be combined to form a single WDM driver. Likewise, the pair of drivers (ContosoRobot.sys, GeneralRobot.sys) could combine to form a single WDM driver. In its most general form, the idea is that you can create drivers by using (specific.sys, general.sys) pairs.

Function pointers in driver pairs

In a (specific.sys, general.sys) pair, Windows loads specific.sys and calls its DriverEntry function. The DriverEntry function of specific.sys receives a pointer to a DRIVER_OBJECT structure. Normally you would expect DriverEntry to fill in several elements of the MajorFunction array with pointers to dispatch functions. Also you would expect DriverEntry to fill in the Unload member (and possibly the StartIo member) of the DRIVER_OBJECT structure and the AddDevice member of the driver object extension. However, in a driver pair model, DriverEntry does not necessarily do this. Instead the DriverEntry function of specific.sys passes the DRIVER_OBJECT structure along to an initialization function implemented by general.sys. The following code example shows how the initialization function might be called in the (ProsewareRobot.sys, GeneralRobot.sys) pair.

The initialization function in GeneralRobot.sys writes function pointers to the appropriate members of the DRIVER_OBJECT structure (and its extension) and the appropriate elements of the MajorFunction array. The idea is that when the I/O manager sends an IRP to the driver pair, the IRP goes first to a dispatch function implemented by GeneralRobot.sys. If GeneralRobot.sys can handle the IRP on its own, then the specific driver, ProsewareRobot.sys, does not have to be involved. If GeneralRobot.sys can handle some, but not all, of the IRP processing, it gets help from one of the callback functions implemented by ProsewareRobot.sys. GeneralRobot.sys receives pointers to the ProsewareRobot callbacks in the GeneralRobotInit call.

At some point after DriverEntry returns, a device stack gets constructed for the Proseware Robot device node. The device stack might look like this.

As shown in the preceding diagram, the device stack for Proseware Robot has three device objects. The top device object is a filter device object (Filter DO) associated with the filter driver AfterThought.sys. The middle device object is a functional device object (FDO) associated with the driver pair (ProsewareRobot.sys, GeneralRobot.sys). The driver pair serves as the function driver for the device stack. The bottom device object is a physical device object (PDO) associated with Pci.sys.

Notice that the driver pair occupies only one level in the device stack and is associated with only one device object: the FDO. When GeneralRobot.sys processes an IRP, it might call ProsewareRobot.sys for assistance, but that is not the same as passing the request down the device stack. The driver pair forms a single WDM driver that is at one level in the device stack. The driver pair either completes the IRP or passes it down the device stack to the PDO, which is associated with Pci.sys.

Example of a driver pair

Suppose you have a wireless network card in your laptop computer, and by looking in Device Manager, you determine that netwlv64.sys is the driver for the network card. You can use the !drvobj debugger extension to inspect the function pointers for netwlv64.sys.

In the debugger output, you can see that netwlv64.sys implements GsDriverEntry, the entry point for the driver. GsDriverEntry, which was automatically generated when the driver was built, performs some initialization and then calls DriverEntry, which was written by the driver developer.

In this example, netwlv64.sys implements DriverEntry, but ndis.sys implements AddDevice, Unload, and several dispatch functions. Netwlv64.sys is called an NDIS miniport driver, and ndis.sys is called the NDIS Library. Together, the two modules form an (NDIS miniport, NDIS Library) pair.

This diagram shows the device stack for the wireless network card. Notice that the driver pair (netwlv64.sys, ndis.sys) occupies only one level in the device stack and is associated with only one device object: the FDO.

Available driver pairs

Download Acr Port Devices Driver Tp-link

The different technology-specific driver models use a variety of names for the specific and general pieces of a driver pair. In many cases, the specific portion of the pair has the prefix 'mini.' Here are some of (specific, general) pairs that are available:

• (display miniport driver, display port driver)
• (audio miniport driver, audio port driver)
• (storage miniport driver, storage port driver)
• (battery miniclass driver, battery class driver)
• (HID minidriver, HID class driver)
• (changer miniclass driver, changer port driver)
• (NDIS miniport driver, NDIS library)

Note As you can see in the list, several of the models use the term class driver for the general portion of a driver pair. This kind of class driver is different from a standalone class driver and different from a class filter driver.

Download Acr Port Devices Driver Ed

Related topics