I'm manufacturing a device that connects to my computer using Bluetooth and then a desktop Java app uses the Bluetooth connection to send serial data to the device which is then displayed.
When I try to connect my device to windows 7 it successfully finds and pairs with it creating a Bluetooth link on a COM port. This link can then be used by a serial prompt (used for testing) or my Java application. It works initially however soon after windows drops the connection and the only way to reconnect is to delete the device within devices and printers and then reconnect.
This seems to be a known problem with windows bluetooth so I decieded to use a third party Bluetooth application. I downloaded and tried Toshiba's Bluetooth Stack and it was able to add a Bluetooth device and keep a stable connection which works great however this only works for Toshiba computers without getting a cracked version.
This device is commercial and can't be sold with cracked versions of software. Has anybody experienced the same problems or not in other operating systems and has any solutions of advice as that would be a tremendous help.
This is not a good idea/method to use the COM ports generated by Windows, it's not working fine and not reliable in any scenario ; you should use Bluetooth Sockets instead.
Using Toshiba or Widcomm or BleuSoleil won't help: under Win7, all dongles are now trying to use the Microsoft Stack, not their own implementation.
Related
Currently I'm working on a portal device, which communicates with Windows via bluetooth serial communication.
It works fine on windows 10.
But on windows 7, things get strange, the communication is not stable, sometimes it runs well for a whole day, sometimes it lose data frequently. The bluetooth driver version on two platforms is the same. I have no idea how to solve it.
Are there any reasons?
I'm looking into programming Bluetooh Low Energy on Windows 8.1 and have a few questions about its behavior on auto-reconnecting to BLE devices after the connection is termiated:
How long will this auto-reconnect feature timed out? Or is it as long as you subscribe to BLE notifications and attempt to read/write data to it?
Will it reconnect if I restart Windows and my application?
How many devices can Windows remember to reconnect? Is it as many as the number of devices my app can connect to?
Where did you read about auto-connecting algorithm for Bluetooth devices in Windows 8.1. As far as I know, it is not possible to perform any kind of auto-connection, so all connection establishment has to be done manually in Windows 8.1 Bluetooth settings.
If your device is in connected state and you restart your PC for some reason, it will still show your device in the list but as "Not Connected" state. So you manually have to remove the device, and then pair it again.
I made a test, where I connected to two devices and read notifications from them both at the same time. What do you mean by app ?. A Smartphone application or ?.
All in all there is a lack of efficiency using Windows 8.1 for BLE applications, since all scanning and connection establishment functionalities have to be done in Windows 8.1 settings rather than in your Windows application, which restricts some important algorithms like auto-connection based on RSSI values and so on.
I have a TDS Nomad running windows CE 5.0 system. It has a USB host port. I have connected to the manufacture and ask if nomad can connect to more than 1 USB devices via USB hub (can connect to 7 USB devices, designed for windows ), they said they haven't tested to connect more than one USB device. If more than one devices is connected to nomad, there mightbe resource conflict.
The nomad works well with one USB device connect to it individually.
But I have a console application debugging in nomad using visual studio2005 and active sync.
I need to talk to both USB devices. Therefore I have to use USB hub. But it doesn't work most of the time. I think the drivers of two USB devices are all correctly installed on nomad.
But what I want to ask, is that has anyone tried to connect more than one USB device to windows CE product via USB hub and both of them works well ?
I'm slightly confused. here. You say the device has USB host and you want to connect more than one client device through a hub. This is definitely supported by the OS, and I've done this with several devices from several manufacturers, though never with a Nomad. Not sure what the OEM is talking about with "resource conflicts" as the USB spec itself allows for multiple devices (kind of the whole point behind a "bus").
But you say that your second "device" is the debugger. That isn't a USB Host connection from the device perspective, that's a USB Client connection, and it typically uses completely different hardware and drivers for that connection. Can a device have both a host and a client connection? Again, yes I've done this with many devices (but not a Nomad) and the OS fully supports it.
Now maybe this is USB OTG hardware (though back in the 5.0 days I doubt it) and the OEM didn't do the design well to handle a client and a host at the same time. Maybe the physical hardware is laid out poorly or the OAL portion of their USB driver is poorly done and can't route properly through a hub properly (I've definitely seen that before). Hard to say.
A USB Analyzer would tell you a whole lot about what's actually happening and where the problem is, but it is definitely a supported scenario by both the USB spec and the OS. If it's failing, it's a manufacturer/device-specific problem.
I have an Arduino application talking over USB to an application on Windows 8 using the MAVLINK protocol. The connection appears as COM3.
Is there a Windows application that can spy on this connection and display the traffic going in both directions? Raw bytes are fine, I don't need the protocol decoded.
You could log serial port activity using Portmon. (Edit: You need to first connect to the local computer via the Computer menu, and you must start capture on the port before a program opens it.)
You may not want to log USB traffic. Such a log would include a lot of extra information relating to the USB to serial adapter which is providing COM3. Portmon would only give you the bytes transferred over COM3, and the Mavlink protocol is entirely contained within that data stream. If you're sure you want to log all USB traffic to and from that device, then I recommend SnoopyPro. In Windows 7, you need to run it as administrator.
If you can use Windows XP in your environment, USB sniff should work for you. If you need something more powerful (and are willing to pay a fee for it) then USBLyzer might be a viable option.
The answer is SnoopyPro, and you can download it at:
SnoopyPro Sourceforge
This tool allows you to get USB information and also USB communication data. I used it in the past to know how a USB device worked in order to do its driver on Linux. I used this tool as a sniffer.
Basically, SnoopyPro allows you to intercept, display, record and analyze the USB protocol and all transferred data between any USB device connected to your PC and applications. It can be successfully used in application development, USB device driver or hardware development and offers the powerful platform for effective coding, testing and optimization.
I'm developing a project that has a number of hardware sensors connecting to the deployment machine through RS232 serial ports.
But ... I'm developing on a machine without an physical RS232 serial ports, but I would like to make fake serial ports that I can connect to and output data from with the aim of faking input from hardware sensors.
Does anyone know of a way to create a fake serial port and control it on Windows XP?
If you are developing for Windows, the com0com project might be, what you are looking for.
It provides pairs of virtual COM ports that are linked via a nullmodem connetion. You can then use your favorite terminal application or whatever you like to send data to one COM port and recieve from the other one.
EDIT:
As Thomas pointed out the project lacks of a signed driver, which is especially problematic on certain Windows version (e.g. Windows 7 x64).
There are a couple of unofficial com0com versions around that do contain a signed driver. One recent verion (3.0.0.0) can be downloaded e.g. from here.
I know this is an old post, but in case someone else happens upon this question, one good option is Virtual Serial Port Emulator (VSPE) from Eterlogic
It provides an API for creating kernel mode virtual comport devices, i.e. connectors, mappers, splitters etc.
However, some of the advertised capabilities were really not capabilities at all.
EDIT
A much better choice, Eltima. This product is fully baked. Good developer tech support. The product did all it claimed to do. Product options include both desktop applications, as well as software development kits with APIs.
Neither of these products are open source, or free. However, as other posts here have pointed out, there are other options. Here is a list of various serial utilities:
com0com (current)
com0com - With Signed Driver (old version)
Yet another place for com0com with Signed Driver (Pete's Blog)
Tactical Software
Termite
COM Port Serial Emulator
Kermit (obsolete, but still downloadable)
HWVSP3
HHD Software (free edition)
I use com0com - With Signed Driver, on windows 7 x64 to emulate COM3 AND COM4 as a pair.
Then i use COM Dataport Emulator to recieve from COM4.
Then i open COM3 with the app im developping (c#) and send data to COM3.
The data sent thru COM3 is received by COM4 and shown by 'COM Dataport Emulator' who can also send back a response (not automated).
So with this 2 great programs i managed to emulate Serial RS-232 comunication.
Hope it helps.
Both programs are free!!!!!
There's always the hardware route. Purchase two USB to serial converters, and connect them via a NULL modem.
Pro tips:
1) Windows may assign new COM ports to the adapters after every device sleep or reboot.
2) The market leaders in chips for USB to serial are Prolific and FTDI. Both companies are battling knockoffs, and may be blocked in future official Windows drivers. The Linux drivers however work fine with the clones.
Another alternative, even though the OP did not ask for it:
There exist usb-to-serial adapters.
Depending on the type of adapter, you may also need a nullmodem cable, too.
They are extremely easy to use under linux, work under windows, too, if you have got working drivers installed.
That way you can work directly with the sensors, and you do not have to try and emulate data.
That way you are maybe even save from building an anemic system.
(Due to your emulated data inputs not covering all cases, leading you to a brittle system.)
Its often better to work with the real stuff.
i used eltima make virtual serial port for my modbus application debug work. it is really very good application at development stage to check serial port program without connecting hardware.