How to communicate to a device via serial port

[_awatts]

>> DSUM - Data check sum - add sum of all bytes in data section to the checksum seed 55 (power of 16?) << Am I right in saying that when the doc states check sum 5516 displayed next to it in a small font, the 16 refers to 16 bit? I'm learning the hard way and not even started to look at coding anything in c# yet. Andrew :confused:

Andy

[Luc Pattyn]

sorry my earlier reply got lost. I asked the CP staff whether they could recover it somehow. yes, a subscript of 16 would normally indicate hexadecimal notation, so 5516 would be 85 in decimal.

_awatts wrote:

not even started to look at coding anything in c# yet.

then IMO a serial communication app is not a good choice, as it can be tricky at the application level even for an experienced programmer. :)

Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

[_awatts]

Thanks for the reply, simply confirming 5516 represents 16bit makes this document alot clearer. If my packet structure is as follows Preamble SYNC - Word - A55A16 Packet header TYPE - Word - 010116 SIZE - Byte - (data size) DSUM - Byte - Data checksum using 5516 seed HSUM - Byte - Header checksum using 5516 seed Packet Data Start - Byte - data[0] Data - Data[...] Am I therefore looking to create an array of bytes, the first 7 bytes for the Preamble and Packet header. Therefore the first two representing SYNC [A5,5A], the next two representing TYPE [01,01], the following byte holding the value for SIZE (number of bytes taken up by data), then the byte holding the value for DSUM, then the byte holding the value for HSUM. The 8th byte will hold a 0 (start of data), any bytes from here on holding the data? If so, how do I calculate DSUM and HSUM? Regards, Andrew

Andy

[Luc Pattyn]

_awatts wrote:

how do I calculate DSUM and HSUM?

Haha, excellent question. There are hundreds of checksum definitions, some of them are standardized by ISO or by CCITT. And I could come up with a few that probably haven't been used yet... Your best hope would be it is described in the documentation. Failing that, you would have to ask the other party, or experiment by collecting a few short messages with correct checksum, then running them against all kinds of known checksum definitions until you find a match for each of the test messages. Warning: yes a word seems to be two bytes in your context, however you also need to know which byte comes first: the high-value or the low-value (known as endianness: big-endian versus little-endian). Just looking at the start of a correct message (a SYNC word) should tell you. :)

Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

[_awatts]

Many thanks for your quick response and help. Having never written a comminications program and based on your feedback I seem to be heading the right direction. I'll do what you've suggested, analyse a respose from the device in terms of packet size and structure, and try out a few different check sum methods to see which one yields the same result. That is if the device will send some data without having to raise a request to the device. Again, thanks for your help. Andrew

Andy

[Luc Pattyn]

Some more ideas: 1. You're obviously an optimist. Any small mistake you will make while implementing some checksum algorithm is bound to go unnoticed and will output a non-matching value for sure. 2. If the device doesn't give any packets by itself, you could again look in the documentation, maybe there are examples. 3. If it is a commercial device, there is bound to be some PC software for it, so using that one could get it to work, then observe the packets that are going back and forth on the cable. If such software were managed code (e.g. C#) you could even use a tool such as Reflector to peek inside it. 4. You can of course look at incoming packets and ignore their checksums if you choose to do so. The data still would be useful most of the time; the checksums are there to protect you against communication mishaps that would yield false packets. 5. You probably do need to provide correct checksums when sending data to the device, although I have met a few systems that accept an "I don't care" value too, which always has been zero in my experience. Note: I do not recommend serial communication without some kind of protection, I'm just pointing a possible and temporary approach that could get you started. Does the documentation state what the device will do when it gets a packet with a bad checksum? :)

Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

[_awatts]

>>2. If the device doesn't give any packets by itself, you could again look in the documentation, maybe there are examples<< Unfortunatley no examples. I'll try and contact the company who made the device. >>3. If it is a commercial device<< Nope. A specialist device only used within the healthcare industry. Previous version written in VB compiled as a Win32 app. I've been tasked to write a replacement without original source.

Andy

[Luc Pattyn]

_awatts wrote:

Previous version written in VB compiled as a Win32 app

So you can still run the device and observe actual good packets? That is good. BTW: you should insist on good documentation! You did pay for the device, didn't you? So demand quality docs. :)

Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

[Pritesh Aryan]

Go to this link and read the answer of that question....... I think it will solve your all problems...........

[Ganesh Kumar Kaki]

Following is the general way to interact with your COM Port

        try
        {
            sp.PortName = "COM1";
            sp.BaudRate = 9600;
            sp.DataBits = 8;
            sp.Parity = Parity.None;
            sp.StopBits = StopBits.One;
            sp.DataReceived += new SerialDataReceivedEventHandler(read\_data);//read\_data is the method fired when ever your serailport filled with some data
            sp.Open();
            sp.Write("AT" + Environment.NewLine);
            
        }
        catch (Exception ex)
        {
            MessageBox.Show(ex.Message);
        }