I'm handling a caller id serial device and write the following program:
serialPort = new SerialPort("COM7", 19200, Parity.None, 8, StopBits.One);
serialPort.DataReceived += serialPort_DataReceived;
serialPort.RtsEnable = true;
serialPort.Encoding = Encoding.ASCII;
serialPort.Open();
void serialPort_DataReceived(object s, SerialDataReceivedEventArgs e)
{
byte[] data = new byte[serialPort.BytesToRead];
serialPort.Read(data, 0, data.Length);
Console.WriteLine(Encoding.ASCII.GetString(data));
}
At first that I receive a call, the event fires perfectly and the result is: "A0101181456926E"
The problem is the subsequent events... next time that I make a call, the event serialPort_DataReceived fires a lot of times each one with 1 char.
Is there any property to set or method to invoke to solve this behaviour?
ps. If I comment the line serialPort.RtsEnable = true;, I don't receive any subsequent event.
As Henk mentioned, you can set the amount of bytes to be received before the DataReceived event is triggered with the property ReceivedBytesThreshold.
But in any case you have to deal with any number of bytes to be received at a time. You have to design your protocol in a way that you are able to recognize when a message is fully received.
It is normal behavior. You can change the ReceivedBytesThreshold property, but doing so means that you have to receive at least that amount, and if there are any errors in transmission, getting in sync again can be difficult.
My advice is to leave ReceivedBytesThreshold=1, and queue the received data up until you have what you need.
I have done just that what is suggested by building in a buffering mechanism to detect when I have received a full input string based on a vendors protocol. works fine. (Must say, not all protocol designs provides clear start and end sequences to work with) What I couldn't understand was why the DataReceived eventhandler was still firing although when I read the input buffer with the Port.ReadExisting() method, the string length was zero. Reading up on the SerialPort.ReceivedBytesThreshold Property on https://msdn.microsoft.com/en-us/library/system.io.ports.serialport.receivedbytesthreshold(v=vs.110).aspx I realized that even though the default of the property is 1 the handler will still fire "if an Eof character is received, regardless of the number of bytes in the internal input buffer" Maybe this is the reason why the handler fires what seems to be unnecessarily
Related
I have written code to read data as a byte array from a serial port and show it in a textbox. The code compiles fine, but doesn't work properly:
private void button2_Click(object sender, EventArgs e)
{
if (serialPort1.IsOpen == false)
serialPort1.Open();
serialPort1.WriteLine(textBox1.Text);
int bytes = serialPort1.BytesToRead;
byte[] byte_buffer = new byte[bytes];
serialPort1.Read(byte_buffer, 0, bytes);
//textBox2.Text = " ";
for (int t = 0; t < bytes; t++)
{
textBox2.Text += (byte_buffer[t]).ToString();
}
}
serialPort1.WriteLine(textBox1.Text);
int bytes = serialPort1.BytesToRead;
The bytes value will always be zero. Unless you debug this code and single-step it to slow it down. It takes time for the bytes you've written with WriteLine() to be transmitted. And it takes time for the device to process them. And it takes time for the response to be received. This adds up to many milliseconds.
You'll need to fix this by looping, repeated calling the Read() method until you get the full response. If you set the SerialPort.NewLine property correctly then you'll have some odds that simply calling ReadLine() is enough to solve your problem.
You are going about this the wrong way.
Clicking a button will open serialPort1; sure. It will then try to read the buffer. But you only opened the port in the same method!
Take a look at this tutorial: http://www.dreamincode.net/forums/topic/35775-serial-port-communication-in-c%23/
It takes you through the entirety of serial communications in C#. You certainly don't want to be opening and reading the port only on a button press event handler.
Use button2 event to send the data to the port. Put the needed code (for sending the data) into a SynchronizationContext (use SynchronizationContext.Post method).
Next, register on the DataReceived event of the SerialPort class and do the reading there (again enclosed into the same SynchronicationContext object, otherwise you'll get a timeout on serial port reading/writing)
Cheers,
I am working out with serial com port.
I have insert this code in my program.
I able to send data to the devices and fail to read data from the devices.
In debug mode, i only able to get serialport.BytesToRead = 0.
May i know why this will happen??
while (serialport.BytesToRead > 0)
{
int byte_count = serialport.BytesToRead;
byte[] buffer = new byte[byte_count];
int read_count = serialport.Read(buffer, 0, byte_count);
string echo = ASCIIEncoding.ASCII.GetString(buffer, 0, read_count);
echo = System.Text.Encoding.UTF8.GetString(buffer);
Console.WriteLine(echo);
}
First use another program, like Putty or HyperTerminal to verify that the device and connection is in working order and to double-check that you are using the correct port, baudrate, parity, stopbits and databits. If you can't get anything out of the device with such a program then it won't work either using your own code.
Next focus on the handshaking. A common mistake is to leave it at none and then not turn on the DtrEnable and RtsEnable signals. A device won't send anything when it thinks that you're offline. SysInternals' PortMon utility can be handy, it shows you what's going on at the device driver level.
When to you read from the SerialPort? Are you trying to read right after you send? In that case you might try to read before there is actually anything to read from the port.
You should use the DataReceived event to read data.
Note that this event might trigger before all data is received, so you might have to retrieve the data over several calls of DataReceived until you get all the data you are supposed to.
I'm using the pretty nifty nmeasharp project to decipher an NMEA stream I'm receiving on a serial port in c#. It all works fine out of the box, but I want to mirror the data to an IP address, and am getting stuck.
The nmeasharp package gets it's data from any stream, so I used to hook it up to the serial port stream, which worked fine:
_nmeaParser.Source = serialport.BaseStream;
Now, I want to use the serial port event to trigger my own routine, where I can redirect the data, so i remove the assignment above, and set:
_serialport.DataReceived += new serialDataReceivedEventHandler(HandleNewSerialPortData);
This event is triggered, and the method gets called. All good at this point, but the nmeasharp code is still looking for a stream to listen to, since I haven't assigned it to a stream anymore.
The following method is where I need to set up a stream to nmeasharp, and write whatever new data the serial port has just received out to that stream.
private void HandleNewSerialPortData(object sender, SerialDataReceivedEventArgs e)
{
SerialPort sp = (SerialPort)sender;
string indata = sp.ReadExisting();
this.serialDataAvailable(indata); // raise event that writes string to IP
if (_nmeaParser.Source == null) _nmeaParser.Source = new MemoryStream(840);
if (_nmeaParser.Source.CanWrite) _nmeaParser.Source.Write(ASCIIEncoding.UTF8.GetBytes(indata), 0, indata.Length);
// Unsuccessful attempts
// MemoryStream s = new MemoryStream(ASCIIEncoding.UTF8.GetBytes(indata));
// s.CopyTo(_nmeaParser.Source);
// sp.BaseStream.CopyTo(this.NmeaDataStreamFromSerialPort);
}
I've tried several variations of trying to write to the nmeasharp stream, but none work. One that showed promise was initialising a new stream every time, but that meant that the stream was closed after every DataReceived event, which truncated and missed out serial messages. The (unsuccessful) code was:
_nmeaParser.Source = new MemoryStream(ASCIIEncoding.UTF8.GetBytes(indata));
I've read lots of tutorials, read all the msdn documentation I could find, and still can't get this simple thing working. This has to be easy, right...?
Edit: I would like to keep the nmeasharp code stock if possible, as it works fine, and as the serial data isn't always ASCII, would like to keep it binary (streams) rather than sending it the data as a string. I can fix up the IP redirection for binary later.
Thanks.
I would try to create two streams. Read from the serial stream manually, and copy to both streams.
Set the nmeaParser to use one of them, and have the IP handler read from the second one.
You can look here for a good solution on how to copy streams.
I have set up a SerialDataReceivedEventHandler, with a forms based program in VS2008 express. My serial port is set up as follows:
115200, 8N1
Dtr and Rts enabled
ReceivedBytesThreshold = 1
I have a device I am interfacing with over a BlueTooth, USB to Serial. Hyper terminal receives the data just fine at any data rate. The data is sent regularly in 22 byte long packets. This device has an adjustable rate at which data is sent. At low data rates, 10-20Hz, the code below works great, no problems. However, when I increase the data rate past 25Hz, there starts to recieve mulitple packets on one call. What I mean by this is that there should be a event trigger for every incoming packet. With higher output rates, I have tested the buffer size (BytesToRead command) immediatly when the event is called and there are multiple packets in the buffer then. I think that the event fires slowly and by the time it reaches the code, more packes have hit the buffer. One test I do is see how many time the event is trigger per second. At 10Hz, I get 10 event triggers, awesome. At 100Hz, I get something like 40 event triggers, not good. My goal for data rate is 100HZ is acceptable, 200Hz preferred, and 300Hz optimum. This should work because even at 300Hz, that is only 52800bps, less than half of the set 115200 baud rate. Anything I am over looking?
public Form1()
{
InitializeComponent();
serialPort1.DataReceived += new SerialDataReceivedEventHandler(serialPort1_DataReceived);
}
private void serialPort1_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
this.Invoke(new EventHandler(Display_Results));
}
private void Display_Results(object s, EventArgs e)
{
serialPort1.Read(IMU, 0, serial_Port1.BytesToRead);
}
Did you try to ajust time latency on the USB serial converter? I had the same problem with a FTDI USB to serial converter. I use an oscilloscope to see my IN and OUT data coming from the device and I could see that the computer was always slow to respond. By default, time latency on the device is set to 16 ms. I changed it to 2 ms and it makes a big difference. Go to your USB Serial Converter in the Device Manager and in the advanced settings, change Latency time to 2 ms. It should works. Try it.
Why do you Invoke() the call to DisplayResults?
This will push it to the MessageLoop, an unnecessary delay.
It would be better if DataReceived() pushed data onto a (thread-safe) queue for decoupled processing.
I also think you could run into problems with split packages.
You could try setting ReceivedBytesThreshold = 22, which will result in the event being fired when there are at least 22 bytes to read. Note that it will be at least 22. There may be more.
I don't think I would personally do this though, because what happens if your packet size changes in the future, for example to 12 bytes? You would end up with 12 bytes in the buffer but not firing the event at all.
Far better to leave it set to 1, which will fire the event when at least 1 byte is available. Then push all received bytes into a list or a queue as Henk has already posted.
Note that the DataReceivedEvent has no knowledge of what you consider a packet of data to be of course. It just fires when there are bytes available. It is up to the developer to assemble these bytes into a meaningful message or packet.
The problem lies in the received data handler.
I ran a separate thread with a while(true) loop and serial.ReadLine(), all works perfectly.
using System.Threading;
Thread readThread = new Thread(Read);
readThread.Start();
Hope someone else doesn't need to spend 3 hours fixing this.
I have one device which sends data on COM port say on COM13. Now i want to read that data and display it in the RichTextBox or in any text control.
I have written the application with the help of IO and IO.Ports but comport.DataRecived event does not fire, even though device is sending data on that port.
I have some software on which i define the port number and it successfully display data, which insure me that data is receiving on the Port but i am unable to receive.
Is there any way i can read data?
comm.Parity = cboParity.Text;//None
comm.StopBits = cboStop.Text;//One
comm.DataBits = cboData.Text;//8
comm.BaudRate = cboBaud.Text;//9600
comm.DisplayWindow = rtbDisplay;//Null
comm.PortName = "COM13";
comm.OpenPort();
cmdOpen.Enabled = false;
cmdClose.Enabled = true;
cmdSend.Enabled = true;
public bool OpenPort()
{
if (comPort.IsOpen)
{
comPort.Close();
}
comPort.DataReceived += new SerialDataReceivedEventHandler(comPort_DataReceived);
comPort.PortName = _portName;
comPort.Open();return true;
}
This normally comes from a wrong configuration of a serial port. It is not enough to simple open a serial port and waiting for some data to come in. You have also to set all the SerialPort.Properties to a correct value for your wanted connection.
Some of the common ones are BaudRate, DataBits or Parity, but to be really sure you have to set all of them. Even such things as RtsEnable or ReadTimeout.
You have to set the all, cause the configuration state will be saved from the port itself. So if one application opens such a port, makes some changes to the configuration and closes it, the next application that opens the port starts with this configuration, till it change it.
Update
Seems to be a problem i can't see from here. ;-))
The only advice i can give you is to use a Monitor tool, to better understand what your other application really does and what comes on the wire. Additionally you can set up two virtual com ports to test reading and writing on one machine (even within the same application), to have a better control about when will which data be send.
Have you read the documentation for the DataReceived event?
From MSDN:
The DataReceived event is not guaranteed to be raised for every byte received. Use the BytesToRead property to determine how much data is left to be read in the buffer.
The DataReceived event is raised on a secondary thread when data is received from the SerialPort object. Because this event is raised on a secondary thread, and not the main thread, attempting to modify some elements in the main thread, such as UI elements, could raise a threading exception. If it is necessary to modify elements in the main Form or Control, post change requests back using Invoke, which will do the work on the proper thread.
The snippet you've posted is quite rough, but I'd set the ReceivedBytesThreshold property to one. This ensures the event firing when at least one byte is present in the incoming buffer.
Cheers
Use PortMon to capture the working software, and then capture your software; then compare the traces. Pay particularly close attention to all the configuration parameters, making sure they are the same (as Oliver mentioned).