I am using visual studio 2008 and developing a windows forms application in C# using .net 3.5
I am doing serial communication and on a button click the application getting a list of all the comm ports available. I then scan for the device i am looking for by opening each port in turn, sending my custom handshake request command and waiting the reply for some number of seconds.
It all works fine on my PC (and on other 8 PCs I've tested it on) but when i run the program on a laptop my program seems to see all the comm ports and sends a requires but my device never receives it. I've tried using the hardware comm port and the usb-to-serial converters. I've also tested it on several laptops form different manufacturers. All of the them behave exactly the same.
Has anyone ran into similar problems?
UPDATE 1
The laptops seem to be able to receive data from the device, but still can not transmit. And of course no problems whatsoever with desktops.
UPDATE 2
A laptop can receive and transmit data.
Therefore that narrows the problem down to my C# software that can do serial communication on a desktop but can not do same thing on a laptop.
UPDATE 3
Solved it. The problem was caused by built in modems of my test laptops. The com port reserved by the modem (typically COM3) does not appear in the device manager, but can be seen in the windows regestry. So whenever my serial port object would ask for a list of com ports, it would get the modem port, and these modems choked on my handshake requests during the port scan.
As usual everything is stupid and simple.
Sounds like your device is picky about the voltage levels. RS-232 doesn't nail that down very well, allowing anywhere between +/- 5V to +/- 28V. Most devices are happiest with +/- 12V, a standard voltage available in desktop machines. Laptops however are always on the low end, +/- 5V typ. Not much you can do about it.
To test this theory, eliminate the possibility that this is induced by your code and make sure it works with a null modem. Connect TxD to RxD so that you receive what you send. Then use Hyperterminal or Putty. If the latter fails to see the device as well then it's a hardware problem.
Related
I've two problem when working with serial port (COM) which I cannot find any reason for it:
1-I've wrote a program in c# (wpf) to receive data from a micro-controller(micro sends some data continuously with an interval ,e.g every 100 ms) , when I run my program in visual studio it receives data but there are some delays in receiving the data; it receives the first three data then a delay and then some other data and continues this scenario without any discipline. I've tried both release mode and debug mode but no change. but when I go to Debug folder or Release folder and run the .exe from there every thing is ok and receives data continuously), I'm really confused!!
2-for connecting to micro I used usb-to-COM converter(cable with one side usb and other side COM port) . sometimes between the running of the program I disconnect the connection by pulling out the usb from my laptop(yet micro is sending) and when I connect it again to my laptop, mouse , app windows,... all move and I cannot control anything!
A USB serial port cable is actually a device (usually classified as a USB to UART bridge device, there's actually a UART in one of the cable connectors). By pulling the USB cable from your laptop, you're effectively removing the serial port device from your system, meaning your COM port no longer exists. If you do this while your program is running, I'd expect the program to crash. A connection over a serial port is a file stream connected to \\.\COM#
'#' is just a placeholder, it could be COM4, COM5, etc. depending on how many other serial port devices are active on the system. What you're effectively doing is similar to disconnecting a harddrive while your program has a file open on that drive. I would not expect it to end gracefully.
As for the data reception, serial ports are very slow by today's standards while computer programs are very fast by serial port standards. Also, while serial port input can be implemented as a blocking call, it will eventually time out. When it times out you're probably reading a 0-byte if you don't check for a time-out condition.
All I can provide you with without knowing more detail of what it is exactly you're attempting to accomplish and how you're attempting to accomplish it.
I have an embedded system running a web server that will usually be connected to an Ethernet network so users can simply enter the IP address of the device to access it.
However, I also need to make some of the same website functionality avaiable to users of the serial port on the device. It would be nice if I could reuse some of the logic I've developed for the web forms for this.
I am currently using .NET for development on my desktop and my embedded device is Linux based. Is it possible to host website content via a serial port or is there some other means by which I can pull this off?
Just a wild guess: back in the days when you connected by modem to the internet, there was a SLIP protocol: IP over Serial Line. Could you use that to establish an "internet connection" to your device?
There are a few options:
If the server is to be in windows, and you have windows 7 then windows xp mode (1) (2) will allow you to use SLIP so that you can provision over serial as you would to any IP address by mapping the serial port to an IP address.
Alternatively there is a sourceforge project called Contiki which has source code to allow the same if you fancy coding your own (the class is called uIp TCP/IP Stack).
Let me know if this is roughly what you're looking for and I can focus in on your specific requirements if you like:)
Cheers.
The first thing that comes to mind is some sort of LYNX like browser (I don't even know if it exists anymore). Maybe easier would be to just do a simple command line interface? It's linux, so you should just be able to spin up a telnet session pretty easily, right?
I believe you should be able to configure your Linux distribution to point your serial port at a terminal, and have that terminal log in with lynx as the shell.
You might want to follow directions for a Linux serial console (tutorial here) and potentially create a user account with the shell set directly to run lynx. Instruct the login prompt (/etc/issue in the tutorial) with the username and password.
Edit: If you're just looking for some sort of data entry from the console, you could just write a shell script or other program and point that user's shell to that application instead.
You could build a TCP client application on your linux device that will talk to your linux web server and redirect data to serial port, and build a TCP server application for your users that will talk to their serial port and redirect data to some TCP port (like 12345). Then all your users need to do is to set their browser to http://localhost:12345 and connect their PC to linux device via serial port cross over cable.
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.
I have a C# application running on a server, and it needs to copy files out to multiple Windows Mobile 5.0 devices. These devices are connected to the network directly via Ethernet-enabled cradles (so they are not connected to a PC via ActiveSync).
What different options do I have for doing this? I know RAPI can do this, but I'm not sure if it can copy something directly over the network like this. Also, I know RAPI uses ActiveSync DLLs and thus requires ActiveSync to be installed, and we would prefer to avoid doing this if possible.
Is WMI a possibility? Can we use ordinary File.IO if we can somehow get the IP address of each device? Code samples or general knowledge would be most welcome.
Normal file I/O isn't going to work. The devices don't have file sharing OS components, so you can't "browse" to them over the network like you might a PC.
RAPI does use ActiveSync, so not only do you have to have AS installed, the devices must also be actively connected, and ActiveSync only allows one device connection at a time, so it's not going to work for what you want.
My solution for this type of scenario has always been the same. You have to install some sort of "listener" on the devices, whether it is your deployedd app or some form of installer. Sometimes I use an autorun app on an inserted CF/SD card (all depends on your topology).
I usually have that app listen for a UDP broadcast of a "discover" packet from the PC. When they receive it, they in turn UDP broadcast out their IP address and the PC collects those. The PC then sends the files via a TCP socket to the device(s) through the listenner app.
Lately I've been doing all of the device-side pieces via a REST service hosted in Padarn to minimize the amount of comms code on the device I have to write, but you could do it all with Udp/TcpClients without too much difficulty.
I have a minor problem where my (new) computer tends to completely freeze up. Am not sure when it happens exactly but the 6 times that it did happen during the last 4 weeks, it could have been related to a very long rendering task that eats up lots of RAM. (Am actually pretty sure that this rendering engine is causing this problem.) Anyway, I don't really care about what causes the problem. I can repeat it by having the same image rendered again and waiting about 4 hours for it to finish. And I can avoid it by making a minor adjustment to the rendered image which somehow seems to solve it all. It's likely a bug in the rendering engine.
And when I say Freeze, I mean that everything stops responding. Keyboard, mouse, disks, they all just stop and the image on my screens are frozen. I don't get a BSOD or automated reboot.
I don't mind the freeze-up, but I would like to receive a warning when the system does freeze up. So I was thinking about a simple solution that should warn me when it does freeze up again. To do so, I want to use an old SmartPhone (HP IPAQ) which runs Windows Mobile 6 and connect it to my computer through one of the USB ports. It would just continue to communicate with my computer to check if it's still alive. When the computer doesn't respond for 5 minutes, it will assume the system is frozen and would have to send a signal to me. Basically, I want it to send me an SMS message to my other phone. Well, consider the SmartPhone to be a kind of lifeguard...
Anyways, I am quite familiar with software development, just don't know where to start with this application. I will be using the .NET Compact Framework and need some pointers in the right direction to do the following:
1) How to connect to a service on another PC using the USB connection and not some wireless Internet connection? (And definitely NOT any Internet over GSM options, since it's just a prepaid card that I'm using for this phone.)
2) How to send an SMS message from this phone to my other phone?
3) Are there already some existing solutions similar to this thing I just came up with, which could save me some time programming?
I used to have an iPaq pocket pc and based on what i remember when you hook them up to the pc they pick up an IP address.
That IP address is the key to your problem,
your computer could ping your pocket pc's ip as a heartbeat. that way you can be sure that you aren't going through GSM since the Desktop is calling the handheld. How to: Create a Socket Listener your socket listener would be listening on your pocket pc if it doesn't get any messages in a set period of time it would trigger the alert winch would send out your SMS.
You could also do the reverse, where your pocket pc would be pinging your desktop, just make sure that you are using the local IP to avoid traffic over GSM
Sending SMS using compact framework
Send SMS Sample
1) You can connect to a USB port as a COM port - many examples on how to do this especially around using GPS. Write an app for your pc to listen to USB for a message and respond. Write the app on the phone to periodically send a message to the PC and get a response.
2) There should be an API for the phone to send an SMS.
3) Not that I know of, the closest being anything that communicates on USB such as I mentioned with GPS-enabled devices.
Good luck - I know (since I have worked with all the technologies you are talking about) that I wouldn't have a problem making this, but for those without that experience it could get tricky.