I am creating a program which can send test or data to Bluetooth devices. For this purpose I want to use the virtual serial ports supplied by Bluetooth software.
Q. Is there is any way to send network stream to virtual serial port like socket programming in LAN?
Q. How do I receive data form Bluetooth? Does it is in the form of Network Stream?
Q. Which is the fast method to send and receive data over Bluetooth?
Because I not only send text to the device but also Images and other type of data.
1) Not certain about Bluetooth virtual ports, but I suspect that you can just use readFile/writeFile, (or the 'Ex' asynchronous versions), to the handle returned by CreateFile(), just like a 'normal' serial port. If so, you can handle the handle, (sorry!), just like the socket handle raised in a client socket connect() or a server listener accept(). So you should be able to use a dedicated thread, an I/Ocompletion routine, or IO completion ports to communicate with the virtual port.
I have done something like this before, but with Delphi and a 'real' serial port and a client network connection. I used an IO completion routine where an 'IOhandler' class was transferred to the completion routine in the 'hEvent' field. The serial port and client socket classes were IOhandler descendants, so the same IO completion routine code worked for both. It worked OK, (eventually:). I don't know of any reason why it would not work OK in C#.
2) Again, certain about Bluetooth virtual ports. Given that many Bluetooth implementations can supply these virtual COM ports as an interface, then the transport must surely be an 'octet stream', just like TCP or a 'real' COM port.
3) On Windows? I suspect IO completion ports. Probably dosn't matter much because Bluetooth bandwidth is not that great compared with what Windows can handle.
Rgds,
Martin
might this will help you
mCore™ .NET SMS Library
Related
I'm developing a weather site, with several weather stations. Ever station uses a different method to post data to the server. They all work, except one. It's a brand new station, but uses a serial port. The company that installed the station connected the station to a Moxa Serial converter. Witch essentially sends the serial data over a specific TCP port to my remote server. Using Pccomm Terminal Emilator I can receive the data on my server. But how should I get my app to listen to this port for serial data. I tried Tcplistener, but it doesn't receive any data. Data is in NMEA format.
Thanks for the suggestions!
Without more specifics I can only give you some general hints, but here goes:
Many Serial-to-Ethernet converters include server-side software that will make the data appear on a virtual serial port. If that is the case, with the software installed you will see the virtual port listed along with the real ports in your system. You can simply open and read from that port as usual.
If that is not the case, but you are receiving data on a known TCP port and can view it using Telnet or something similar, then perhaps the Moxa converter is acting as a server and expects you to be the client. In that case you would want to use the TCPClient class rather than the TCPListener class.
The Moxa converter (you didn't give the model number) has a manual which may prove helpful.
If you need more help then you will need to post specifics about exactly how you are connecting with PComm and what you see, and exactly what you tried with TCPListener, and what happened.
gl
Does anyone know how do I check if a device is connected to a serial port? I need a sort of ping functionality so that I can ping the device and attempt to connect to it only if the ping succeeds. For instance if I don't have the COM cable plugged in, I can display the connection failed message much faster.
It just isn't quite the same problem as having to use Ping to find if a server that's located a thousand miles away is online. With serial ports you just look at the other end of the cable, you rarely have to walk more than a few feet.
There's also nothing similar to having a stateful connection like TCP. All you can really do is look at the hardware handshake signals. The SerialPort.DsrHolding gives you the state of the Data Set Ready signal. A properly implemented serial device uses that signal to say that it is powered-on. CtsHolding is an additional signal, it says that it is ready for you to send data. They normally have to be both turned on before you consider sending anything.
These handshake signals are not always properly implemented. You may well have a problem if the serial port is actually emulated by a BlueTooth or USB device driver for example. Pretty common these days with very little consistency in how closely these drivers emulate a real serial port. You'll have to try.
Preface:
I have an asynchronous socket server where we receive telemetry data, and when the remote devices do not send us data, we have the ability to send commands to request data. The listener and command processing are done on separate threads. The listener listens on one port, while the commands send on a different port.
My overall question is: Is it possible with C# to check if a socket is connected without having to call a "connect" method in the first place? Our customers device will establish a connection to the server and will remain connected always (unless service coverage drops or battery drains etc.). I'd like to avoid having to keep track of all the connected socket objects in memory if possible.
To be honest I'm not even sure if what I'm asking is feasible. I'd like to hear people's thoughts.
If you know the socket information, you could probably invoke GetExtendedTcpTable and get the state of the socket ("established" or not).
For an example of pinvoking this function, see:
http://social.msdn.microsoft.com/Forums/en-US/netfxnetcom/thread/5b8eccd3-4db5-44a1-be29-534ed34a588d/
How can I catch TCP SYNC events for particular socket in .NET?
I want to be able to fire off a method which will detect if request for SFTP data transfer is made and on completion to do some action like notification or logging.
Presuming that the socket you want to detect the open and close of is not one your program is responsible for itself, but some other process on the system is handling it, the best way may be to use the winpcap library. winpcap allows you to subscribe to a raw feed of all IP packets coming into and going out of your network interfaces. You c an also provide a filter such as "Only show me TCP packets on port 22". Your program receives the raw packets so you get the ethernet header, followed by the IP header, followed by the TCP header, followed by the data payload (payload will be encrypted for SFTP). Analyising these packets you will be able to detect the TCP handshake on connect and know the IP and port that is connecting and detect when the TCP steam is closed.
I don't use .NET myself, but I did find this winpcap wrapper for .NET on Google which should allow you to use winpcap from your .NET application.
WinPCAP.NET Wrapper
I need to Determine the serial port name connected to other machine using c#.
This is just not the way serial ports work. It is not a bus, like USB or PCI, where you can plug something in and the operating system will do the ah-ha, new hardware! discovery automatically. Serial ports are very primitive, dating from the stone age of computer hardware.
It takes a human to plug a serial port device connector. With some luck, the connector will have a label which says what COM port number is assigned to the connector. Although that luck is hard to come by these days. She'll then tell a program to establish a connection on that particular COM port. Hyperterminal is the canonical implementation of such a program on Windows.
You cannot realistically open every COM port that might be available. That prevents another program from using another COM port. You'll prevent a modem from getting used for example. Part of the stone age legacy is that only one program can open a COM port, every other program will be locked out.
So, provide your program with a UI that lets the user select the COM port(s). Save the selection in your config data, it is very likely that the device is still connected to the same port when it starts back up. You can use WMI and the Win32_SerialPort class to provide a better description for the COM port (more than just the number). Some USB serial port emulators may set the Description property to something recognizable.
SerialPort.GetPortNames() enumerates the available COM port numbers. A basic sanity test is to check the SerialPort.DsrHolding property, it should be true when the serial port device is plugged in and powered-up.
A serial port doesn't report any connection state. You can open all available serial ports on your computer (if no other application already opened it) regardless if it is connected to something or not.
To find out if a serial port is connected to another machine, you have to open up all the available port, send your initialization data and listen if something correct comes back.
Imagine you have a good old serial modem connected to your pc. To find this out you have to open up all the available ports and send a 'AT' over the wire. If a 'OK' comes back you found a modem (maybe additional tasks are necessary to check if you found the right one [maybe there is more than one device connected to your pc]).
What i just missed out: Don't forget to configure the serial port! Don't set only baudrate and stop bits. Set all settings to the values you need (even if you use default settings). Cause these settings will be saved also if you close and reopen again. All settings are still valid unless you change them. Now imagine you have some other application on your pc that also opens up a serial port and changes the settings for some uncommon feature (e.g. XOnOff). If you don't set it back on your initialization phase
you'll never be able to get a working connection!
Update
Listening to all the available ports is quite easy:
First you need a list of all com ports.
Then you create for each one a own thread (or backgroundworker)
And each thread handles its given SerialPort
That's it.
Serial communication doesn't have anything compared to that of IP which has an address and port sent with every packet. The only data that is sent over a serial cable is the bytes you send yourself.
If you control both ends you can send the port number as a part of your own protocol.