Processing Serial Data

I need the reduce the processing time in a uMicrocontroller to allow faster sampling times. This has creates a problem in the data collection routine in VB. The old system collected the analog data a converted it to a decimal format before sending it to the serial port. This data is collected and saved using Hyperterminal. The VB program would, when run, would open this file and process the decimal data by graphing it. What I need is to capture the data directly and process a binary word. All attempts to run the graph program have failed! I'm sure it's in the way I'm reading the data. I've not been able to find much information on this and am at wits end to get this program working. I have been collecting the data from MSCOMM (Data=MSComm1.input), which seem to be working fine. The problem is that I can't get the data to graph correcly with the binary data.  If someone could give me some pointer it would be greatly appreceated.

Thanks,

Ronnie



Answer this question

Processing Serial Data

  • FrannieG

    Ok, can you give me an example of how to read the port and convert the binary data into a decimal value. Here is part of the code I've written to get the data from MsComm-- it don't read any data! The uP is working as expected, I can read it using hyperterminal and get what is expected.

    Thanks

     

    Ronnie


  • The Sagi

    We just spent ~$600 for the studio.net, but if the VBE is easier I'll toss the studio. Where can I download it free
  • Achilees

    Hello Renee,

    From your last posting:

    "Where did "words" come from when we've been talking about bytes "

    Sorry, my loose terminalogy does get in the way from time to time, the uP has a 10bit ADC which was defined as a word because it required 2 bytes. However, I only need 8 bits for this application so the the converter output is left justified after the conversion and the lower byte is disgarded. The remaning byte is transmited to the PC.

    The serial protocal is 8 data bits and one stop bit but this should be transparent to how the data is passed to the VB program.

    The simple example you listed workes when a hex value is assigned to a variable within VB but when this is passed to the same variable from MsComm the value of this variable was shown by the debugger to be blank. I know the comm port is working and that the uP does transmit data. This was verified using Hyperterminal, however, the data is reprorted in unicode using hyperterminal. If you recall the old system collected the data and the uP converted the byte data into a 3 digit number 000-255 hex 00 - hex ff. This decimal number is save into a file during data collection. At the end of the data collection sequence the file is closed. To view the data we read this file and passed the decimal number to the graphing routine for analysis.

    Now, I need to collect this data and graph it in close to real time. Also, to increase the sample rate I need to collect the byte data for 8 channels, save this data in any array, and pass this data to the graphing routine in the form of a decimal #. This # has a minimue value of 0 and a maximun value of 255. There is no provision for negitive numbers.

      

    "What do you present to mscomm as a buffer Do you have to retrieve each byte or do you hand it an array "

    The old program read a file with decimal data and stored this data into an array which is then graphed.

    The new program must do the same thing basically, with one diference. That is only one sample (1 sample containing 8 bytes) is graphed at a time.

     

    Please, the parameters of the data and how you are declaring them are critical. The machine is not going to know how to handle a variant.  (I assume we are talking Vs2005 here )

    I realize this, and I belive that's the problem. I know there must be some little trick to store this data stright form MsComm I just haven't figured out what it is. Also, I should have told you I'm using VB5 enterprise edition. I recently got VB Studio but it's going to that me a while get up to speed on this software. Eventually this system will be tied to our network. I need to learn the Visual Studio before then but in the meantime I'm commited to complete this project using VB5.

    Here's a brake down of what needs to happen from start to finish.

    Operator of PC click on a start button on the control interface (VB program). This will send a 2 byte start command to the uP and open a file to save the collected data. The uP will start collecting data and will send 2 bytes to the PC to indicate the start of a sample (Frame) the next data sent to the PC will be an 8 bit byte for ch1 the next ch2 to ch8.

    After the 10th byte is collected the VB program will pass the 8 data bytes to the graphing routine.  After graphing, program control will be sent back to data collection. This will continue untill the PC operater clicks on a "Stop Button" or the file reaches it's maximun size.

    Thanks again, I look forward to hearing from you.

    Ronnie


  • Dc123

    I'm using an 8 bit AVR uP running at 14MHz and the overhead in converting the ADC output into an actual decimal number is to slow. I need to allow the client pc to do the data crunching to allow for the needed speed increase in ADC sampling rate. In a nut shell, I'd like to take the raw data from the uP, which ranges from hex 00 to hex ff, transfer this data to the serial port and collect it using the PC. This requires the graphing program to process raw data. The original program works great with very low frequencies when accessing 8 channels of the ADC. However, as the input frequency increases so does the conversion error. The problem can be mitigated by using a 16bit uP but the boards have already been designed. Changing the design at this stage will be extremely costly! So, I need to find a way to handle this with the PC allowing the uP to only collect the data... < xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

    Thanks for trying...

    Ronnie


  • MFaulk

    What I need is to capture the data directly and process a binary word.

    My guess is that you simply have a conversion issue with the data. Is there anyway you can have the uMicrocontroller put out a pre-determined value that you know with a known floating point value

    What does the new binary information look like How are you converting it

    Do you have any known outputs.  Can you feed the graphing part known pseudo information and obtain an expected graph. If you can, then the problem has to be in the data conversion from the port.

     



  • ggvw

     

    Wow.....

    Buffer is a variant I woul have expected just plain byte data in a byte array.

    Let me be sure of a couple of things. I really didn't expect you to be collecting that data in a variant. If you noticed earlier I mentioned a byte stream. By the way, I'm familiar with ADCs.

    Let's to back to basics for a moment and consider the datum itself.

    Am I to assume that the data from each channel is an  8 bit byte or is that part of the data To develop a little common terminology what consitutes a Frame   Is the data coming at you in a continuous stream Or do your trigger the sampling with a command   If the data for each channel is a single byte how is that associated with a channel number   Do you receive eight bytes representing one sample of  each of the eight channels   All of this needs to be really understood before the data can be interpretted. Does this make sense In other words I'm asking questions about the ADC protocol to the port.

     

     

     

     

     



  • Golem

     

    I've tried several ways to get the real time data without success. I started out with "Buffer" defined as a "Byte" but when I tried to display it I got a data type error which implied that "Buffer" should be defined as a variant.

    Don't worry about this AT ALL. It's premature.  What you want at first is to reliably collect bytes that accurrately reflect the output of the ADC. We can worry about data conversion later.

    Even if you have to look at the bytes in the debugger that's ok. The first objective is simply to be able to a reliable frame of data into the program.

    Let's be VERY precise. I used to use 16 bit word based machines. :)

    What are you calling a word How many bits and is it a signed or unsigned entity Integer or floating point

    Where did "words" come from when we've been talking about bytes

    What you want to be concerned is the precise parameters of the datatype you are working with.

    Ideally you'd like to have one channel Send and FF  and see that represented as a byte in the debugger. Then make sure that it not represented as a -127 because often this will be taken as a sign bit

    I checked and this will work

    Dim b(8) As Byte

    b(0) = &HFF

    Dim a As UInt16 = b(0)

    a = 255 in the debugger. I also noticed that the length of b was 9 which was a surprise.

    So let's work on reliably getting bytes into the program. Phase II will be converting those bytes into

    Something your graphics program can use.

     After that the uP will transmit eight 8 bit words each byte representing a single channel.

    What do you present to mscomm as a buffer Do you have to retrieve each byte or do you hand it an array

    Please, the parameters of the data and how you are declaring them are critical. The machine is not going to know how to handle a variant.  (I assume we are talking Vs2005 here )

    Exactly what dataype does you graphing program require

    Can you feed it known fake data... in the format you want and have it display correctly

    If so what are the parameters of that data

     

     

     



  • ekolis

    That gives me some more information. I assume you are doing the firmware for the microprocessor

    I'd set the microprocessor to put out a known midrange value and look at the byte stream and massage until to get the value you are looking for.

     



  • mpp.michael

    Ronnie,

     

    It's nice to hear from you too........

    Please before you go any further,

    Please download VB express. It's free and good for a year.

    Please......

     

     

     



  • glasssd

     

    SJ is one of the people here that I am really fond of. If you won't listen to me, listen to him.

    I had exactly the same experience. I didn't like the first two versions of .Dot et. I had them on my system but did't use them. I kept developing in vb6. One day, when I had nothing to do, I wondered what all this fuss was about so I down loaded VB Express.

    I had not developed a line in vb6 since then. I'm very discerning about software and I found VB Express to be quite comprehensive. I only missed one thing which is the call stack. I don't use it very often but when you need, you need it. It is easy and you know know I really like about it   It's pretty!!!! I love the aesthetics. One of the reasons that I didn't like the first versions was that they just were depressing to look at.

    Ronnie, I want to work with you on this until it's finished and I do that for people. If you're running vb5 though we're close to speaking two different languages and down to datatypes.

    RS-232 has always been a mess, even on mainframes in the seventies it was a mess. There are people on here all the time with RS-232 probles and I think MS needs to put out a white paper on RS-232 comm. I am very comfortable that this is going to be easily doable.

    It's going to take you a little while to spinup on VBE but when you do you'll be glad you did and it will more than worth while to have done so.

     

     

     

     

     

     

     

     



  • Steve Westlake

    I've tried several ways to get the real time data without success. I started out with "Buffer" defined as a "Byte" but when I tried to display it I got a data type error which implied that "Buffer" should be defined as a variant. I've recently just been trying to retrieve the data and view it in a text box. Maybe I'm going about this the wrong way. The code I sent is actually just for testing the uP to PC data. All it was suppose to do is grab one word and display it. I programmed an uP to output a know word that I could verify is a text box. Framing isn't being used in this. You exactly right about the protocol, a single sample represents 8 words, one for each channel. As far as framing, the sample I posted isn't looking for this. However; in the final working unit framing will be set by the reception of the hex word {01} and {61} in that order. This is of course an arbitrary chouse on my part and could be any thing as long as there is some reasonable separation between words.< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

    I plan to implement several data collection options. One will be free running: once started the data will be sent to PC continuously until stopped. 

    The second will be event driven: A sample will be requested by the PC based on a timer event with VB.

    For all cases the PC will send 2 words to the uP. The first tells the uP what type of data collection is needed. The second word from the PC will be to start the data collection process.  After that the uP will transmit eight 8 bit words each byte representing a single channel. The program will take the first word received, after the 2 framing words, and treat it as channel "a" the 2nd word as "b" and so on.

    After all the data for a frame is received it is then sent to the graphing routine where it will be displayed.

     

    I hope this has given you a better ideal of what I need to do.

     

    Thanks again,

     

    Ronnie


  • Greg Yvkoff

    I'll agree with Renee. I've been following this thread closely, since I'm an engineer in the data acquision field (and serial port comunication crops up quite a bit).

    It's hard to juggle the need to be productive (in a language you already know; VB5 in this case), and the need to learn how to use new tools - and the time needed to do so.

    I never enjoyed using Visual Studio 2002/2003. However, Visual Basic 2005 Express (and the express editions of Visual Web Developer, C++ and C#) are a much easier transition from Classic VB, and getting around the .NET framework.

    You can develop professional applications in VB 2005 Express. I highly recommend you download it and start playing.



  • UmerKhan

    Sorry I forgot to paste the code:

    Private Sub Command1_Click()
    MSComm1.CommPort = 1
    MSComm1.Settings = "115200,n,8,1"
    MSComm1.PortOpen = True
    MSComm1.InputMode = comInputModeBinary
    MSComm1.InputLen = 1

    Dim Buffer As Variant
    Dim D As Variant
                D = MSComm1.Input
    '            Debug.Print "Receive - " '& StrConv(Buffer,vbUnicode)
    '           Debug.Print "Receive - " & StrConv(Buffer, vbUnicode)
    'Buffer = Buffer '"&H0f"
    Dim c As Variant

    'D = Buffer 'MSComm1.Input
    'Text = Val("&HD")
    Text = D 'MSComm1.Input
    c = Val(D)
    'Text1 = D'Buffer

    Text2 = c 'Val(Text)
    End Sub


  • trashVin

     

    Ronnie,

     

    I have some good new for you assuning you are runing Vs2005.

    I've been looking at VB6 and at the examples. They are awful because people just did a do events and just looped on the completion property. But the specs on MSComm32.ocx shows that it has a completion event.

    This means that it can be declared as:

    Friend WithEvents smc As New MSCommLib.MSComm

    You'll noticed that I called it smc

    when I set the left windows above the theeditor to smc

    I can go to the right window above the edit and I will an OnComm event.

    Selecting that will add the following event to your program:

    Private Sub smc_OnComm() Handles smc.OnComm

     

    End Sub

    This is routine is called asynchronously upon "a communication completion"

    I think what you can do in that routine is to get the byte... discarding them until you see a new frame begin.

    When it does begin.. you set a member variable boolean saying you're in the frame and may increment a member variable byte counter.

    on the first byte save it in a byte array until you collected 8 bytes youmay choose to do your data conversion then or wait until the end of the frame.

    when you have collected eight bytes clear the flag and the counter. Ship the converted data off to your graphing program and return

    This could be really easy and fun.

     if you want to see the data in a textbox do it like this

    textbox1.text &= hex(bytevariable) & vbcrlf

    Notice that the fuller the textbox gets, it will require more and more resources so clear it frequently.

    It's easy to clear. Textbox1.text = ""

    Also any buttons or controls that start and stop the sampling should intialize the bytecounter as well as the boolean flag.

    Before this is over you'll need a little more.

    Renee

     

     

     

     



  • Processing Serial Data