Serial Port question(s)

Here is the situation. I have a piece of hardware that reads machine pulses and sends data to the serial port of a Windows 2000 server. I can't say that I know what to expect when I monitor this port. Eventually, I want to add records to a SQL database, based on what the serial port receives.

I found some sample code. I went to the manufacturer's site to get the configuration data

Code:

---

  With MSComm1
    'make sure the serial port is not open (by this program)
    If .PortOpen Then .PortOpen = False
    'set the active serial port
    .CommPort = 1
    'set the badurate,parity,databits,stopbits for the connection
    .Settings = "19200,N,8,1"
    'set the DRT and RTS flags
    .DTREnable = True
    .RTSEnable = True
    'enable the oncomm event for every reveived character
    .RThreshold = 1
    'disable the oncomm event for send characters
    .SThreshold = 0
    'open the serial port
    .PortOpen = True
  End With 'MSComm1

---

When I have the rate set at 9600, I get a string of unreadable characters (such as a y with line above it). Is that Uncode? When I have the rate set a 19200 I get a series of vertical bars separated by an astrisk-like character. Neither case does me any good.

I am using thsi code to read the pulses

Code:

---

Private Sub MSComm1_OnComm()
  Dim strInput As String
  With MSComm1
    'test for incoming event
    Select Case .CommEvent
      Case comEvReceive
        'display incoming event data to displaying textbox
        strInput = .Input
        Text1.SelText = strInput
    End Select
  End With 'MSComm1
End Sub

---

I have never tried this before, so I do not know what to expect to see. I was hoping to see a machine number, and a time stamp.

I'm thinking that I need to do something in the CommEvent code to translate the input.

Any help would certainly be appreciated.

Pasvorto

A shot in the dark, but would this help?

Code:

---

Dim aaInput() as Byte

---

That is, replace strInput with aaInput() in 2 places in your
code frag. Instead of getting non-printable characters,
hopefully you'll get the Ascii values of each byte.

A little tweaking of your other code may be required, but maybe it will
get you started.

Spoo

I will give it a try

Pasvorto

Just to clarify. I've used it successfully in the past
to read a file, such as a BMP or AVI file, as in:

Code:

---

    Close #1
    Open ff For Binary As #1
    Dim aaInput() As Byte
    ReDim aaInput(FileLen(ff))
    Get #1, , aaInput
    Close #1

---

Your case will be different, natch, as you don't initially
know the size to which to ReDim the array. But again,
hopefully it will give you something to start with.

Spoo

Thanks again. I will give it a shot tomorrow. I had to turn the serial port over to another program.

So, what are you seeing (anything)?

What I'd do is to add a few lines:
Dim I As Integer
For I = 1 to Len(srtInput)
Debug.Print Asc(Mid(strInput, I, 1))
Next I

Or, you could display the ASCII data for each received byte in the textbox.

At the end of the day, you may have to go to the manufacturer of the connected device to determine what embedded protocol is being used. If this is binary data, you, almost certainly, won't make any progress without that documentation. If it is text protocol, then your code would actually have displayed useful data, at least a starting point. So, my guess is that there is more involved.

BTW, I have dozens of example of this sort of thing in my book, Visual Basic Programmer's Guide to Serial Communications 4. The devil is in the details -- and seldom are the details duplicated from device to device.

It also is possible that your serial speed is incorrect. You might try 9600 or 38400 (etc.), just in case.

Dick

I checked the documentation on their site. It is 19200

What is the result of the code fragment that I suggested?

I tested it this morning. Now, I see nothing.

OK, progress. I changed the baudrate to 9600 and added strInput = ASC(.Input) and now I get a string of numbers. I just have to figure out what they mean now.

I put it top 19200 (like the documentation says) and I get a string of "1214012140..." Do you numbers mean anything to anyone?

Looking at an ascii table, I get "y(y("

????

Pasvorto

Are all characters in your string numbers (ie, "0123456789"),
or do you sometimes see any of "ABCDEF"?

If the latter, perhaps you are getting a string in hex.

Spoo

I only saw numbers. I can let it run for a bit longer and see what shows up.

All numbers

Here is a sample of the string I am getting

129140113212414012912113214041291211...

Pasvorto

OK.. I'm flat out of ideas then.
Sorry

But I am curious, how can you turn "1214012140..." into "y(y("?
Don't you parse the string in "chunks" of 3 all the time?

Spoo

121 = y and 40 = (

Just stabbing in the dark.

Quote:

---

Originally Posted by Pasvorto

121 = y and 40 = (

Just stabbing in the dark.

---

Yeah, but 121 is 3 digits, and 40 is only 2 digits.
As I asked before, don't you always parse in chunks of 3 digits?

Further, your "new" string seems to be different

Code:

---

new: 129140113212414012912113214041291211...
old: 1214012140

---

.. the point being, "new" seems to be clearly in 3-digit chunks, ie

Code:

---

new: 129140113212414012912113214041291211...

129
140
113
212
414
012
912
113
214
041
291
211...

---

Nope. Check that. :(
You get some odd ones .. 414, 912 ...
Wierd.

Spoo

I am beginning to suspect that the circuit board that is sending the data stream has some sort of proprietary format. If that is the case, I am kinda screwed.

Maybe I need to get one of those WWII code breaker devices. :-)

You need to get documentation from the hardware manufacturer. That documentation will tell you how to parse this binary data stream. For example, a fairly common pattern would be to start a data packet with a STX (StartOfText = 2), then either a number of bytes or the start of data. After however many bytes represent the actual data a ETX (EndOfText = 3), then one or two checksum bytes. The documentation will tell you the actual details -- and, normally, this is published by the manufacturer. If it is not, then actually decoding it is a nightmare.

Of course, you also have to be able to see the data stream. You most recent message indicates that it has stopped sending? If so, then you have to get that working first.

Dick

No, it is sending. I put the 3 dots there just to illustrate that the stream goes on and on.

But, I am beginning to agree with you. I have looked at the data files it creates and I can't find a matching sequence anywhere.

You need the docs, IMO. Without them, you will be lost. With them, just a few lines of code will provide the results that you seek.

I've done this (litterally) dozens of times. I don't remember actually being successful, when attempting to decode binary data, without some guidance. A few times that "guidance" came from someone other than the vendor, but not often.

If the vendor provides the packet data structure, then post it or a link, and I'll try to help.

Dick

OK. Thanks. I need to jump a few political hurdles first.

Perhaps if you post the make and model number of the sending device somebody might be able to help you. It is a long shot but worth a try.

I will see if I can find a model number somewhere