• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 46 subscribers
  • Views 1268 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/ADS1261EVM: ADS1261EVM eval board control utilizing serial port communication (C++ independent program)

Freddy Pena
Prodigy 60 points
Part Number: ADS1261EVM
Other Parts Discussed in Thread: ADS1261

Tool/software: TI C/C++ Compiler

Hi, 

I was wandering if someone could help me with some guidance for using the ADS1261EVM. I am not familiar with the communication interface (protocol) used on this eval board.  I know the ADS1261EVM comes with a control GUI that allows the operation of the board. However, the GUI provided does not allow me to have the flexibility I required to use the board since I am trying to do my own software (C++) to capture the ADC data for processing. 

GOAL:

I am trying to create my own C++ program that can directly communicate to the ADS1261EVM utilizing the USB  provided on the board with any time of communication.

QUESTIONS:

How can I communicate with the ADS1261EVM when making my own C++ program/library?

Do I need particular drivers with some library to interact with the board when making my own C++ program? if so can you guys provide it?

I hope mu questions aren't to silly and that I explained the goal well enough. I have been doing some research on the board itself and I can't find much online. I went through the manual but nothing was specify there neither. At any rate, I hope to connect with something that might guide me to the right path

Regards, 

Freddy 

  • 0
    TI__Mastermind 44550 points
    Hi Freddy,

    Welcome to the TI E2E Forums!

    You are talking about writing your own code to run on the PC side (i.e. in place of the EVM GUI), correct?

    It's probably possible but not something we will be able to provide you with much support on. Since the ADS1261 is a generic USB bulk device, you'll have to find a way to interface to it. Something like libusb would probably work.

    Once you have an working interface, you could reference the EVM command list in the ADS1261EVM User's Guide to see the available commands. All of these commands are just ASCII formatted strings. Reading data might be a bit tougher since return data is not ASCII encoded, but binary encoded.

    As far as drivers go, you could use the driver included with the Delta-Sigma EvaluaTIon software or otherwise use Zadig to associate the ADS1261EVM with the WinUSB driver.

    I hope that helps!
  • 0 in reply to Christopher Hall
    Prodigy 60 points

    Hey Christopher, 

    Thank you for your input, I managed to establish a connection (made my own set of drivers for it), I successfully read and write to the registers, as well as send some of the commands provided in the ADS1261EVM user's manual..

    Now I have another problem.... When I try to use the "collect" command to acquire the raw ADC data, the data seems to be wrong or at least I am failing to understand how the data is being formatted. 

    For instance when I configure the registers, and I use the "COLLECT N" samples; where N is an arbitrary number (i.e 20) I get the following string:

    "\x00\x03\x1E\x0F\x00\x03\x1E\x8A""END\x00"

    The question:

    1) How can I extract the samples requested from the string?

    2) Are the "" part of the string, or it just specifying the beginning and end of the string?

    Regards, 

    FP

  • 0 in reply to Freddy Pena
    TI__Mastermind 44550 points

    Hi Freddy,

    1) The data is coming back as binary bytes, and you can interpret it as follows...

    "\x00" - This is just a framing byte that you can ignore. You'll see that data always starts with this byte.
    "\x__" - Not shown, but IF you enable the STATUS byte it will follow after the framing byte.
    "\x03" - The next byte is the data MSB.
    "\x1E" - The next byte is the data mid-byte.
    "\x0F" - The next byte is the data LSB.
    "\x__" - Not shown, but IF you enable CRC mode, then the 8-bit CRC of the data will be shown here.

    The above pattern will repeat for every sample that you collect. Then, after all samples have been collected you will see the "END\x00" string. So, per the above decoding, I see two samples with 24-bit values of "0x031E0F" and "0x031E8A".

    2) I'm not sure that "" represents anything in the above string...
    Most likely you are receiving two USB packets (the first being "\x00\x03\x1E\x0F\x00\x03\x1E\x8A" and the second being "END\x00").

    I hope that helps!

  • 0 in reply to Christopher Hall
    Prodigy 60 points

    Hi Christopher,

    That was very helpful, I got a string to parse properly!. However, I still have the issue that whenever I use the "COLLECT <N>" where N is the number of samples in a decimal value, I can't never get the right amount of bytes. Is there a sequence of commands that I need to send before I do the "COLLECT <N>"(beside setting the registers for the desire data rate, filter, status, etc..).

    For instance take the string I sent in the previous post. "COLLECT 20" I should expect 20 packets, however, I am only getting 2.
    However, I use the "Delta-Signal ADC Evaluation Software" and I collect let's say 1024 samples, and then I run my software and I use collect 20, I get 1024 packets, (which seems to me that I am not triggering something right).

    So the question is:
    1) It's there a particular sequence to use order to acquire a new set of data of size N? If so would provide me with it.

    Again thank you so much for you help!

    UPDATE: 

    I found the solution for the problem above, the user manual fails to explain that before using the COLLECT <points> command, a COLLECTSETUP <points> command need to be sent before.... However, for some reason whenever I read the data set I get certain undesirable characters (example the string below). It becomes very difficult to parse and some of he data really makes no sense.

    "\x00\xFF\xFF`\x00\xFF\xFFr\x00\xFF\xFFu\x00\xFF\xFFj\x00\xFF\xFFi\x00\xFF\xFFj\x00\xFF\xFF""c\x00\xFF\xFFi\x00\xFF\xFF""d\x00\xFF\xFFpEND\x00"

    Regards,
    Freddy Pena

  • 0 in reply to Freddy Pena
    TI__Mastermind 44550 points

    Hi Freddy,

    You are correct, there is a sequence of commands that need to be sent which I forgot to mention.

    Send the "COLLECTSETUP 20" command and then send "COLLECT 1".

    The argument to COLLECTSETUP will indicate the number of samples to collect. While, the argument to COLLECT is a boolean that starts the collection.

    Note: You will get some some binary data back from the EVM after sending COLLECTSETUP, but you can ignore this data. This info is used by the GUI to parse the data, but this you already know how to do.

  • 0 in reply to Christopher Hall
    Prodigy 60 points
    Hi Christopher,

    Yes, I noticed that after looking at the log from the Delta-Sigma software... But, the data is not in the same pattern you specified in the post above... (I updated my previous question)

    Both CRC and STATUS are turned off but the data stream seems different. Also in the event the CRC and STATUS are turned on, a "RESET" is required to update the registers?
  • 0 in reply to Freddy Pena
    TI__Mastermind 44550 points

    Hi Freddy,

    Freddy Pena said:

    However, for some reason whenever I read the data set I get certain undesirable characters (example the string below). It becomes very difficult to parse and some of he data really makes no sense.

    "\x00\xFF\xFF`\x00\xFF\xFFr\x00\xFF\xFFu\x00\xFF\xFFj\x00\xFF\xFFi\x00\xFF\xFFj\x00\xFF\xFF""c\x00\xFF\xFFi\x00\xFF\xFF""d\x00\xFF\xFFpEND\x00"

    It looks like you are either getting corrupted data OR for some reason your software is deciding to decode some bytes as ASCII characters. My guess is the later issue. Therefore, " \x00\xFF\xFF` " is really 00 FF FF 60, where " ` " is the character represented by \x60. By following this logic for the rest of your your string the data seems to make sense to me, assuming you are measuring a near 0V signal.

     

  • 0 in reply to Christopher Hall
    Prodigy 60 points

    Christopher,

    Actually the data was coming out corrupted from the board... something was happening when I initialized. But problem solved.. again thank you for your help.

    Happy holidays and happy new year

    Regards,

    Freddy Pena