• Resolved

FDC1004QEVM: LabVIEW 2010 Interface for FDC1004EVM, FDC1004QEVM and FDC2214EVM

Part Number: FDC1004QEVM

Attached is a copy of the LabVIEW modules that Yibo provided to several users in this thread .

However, thanks to Evgeny's response in this thread

I updated the read register module to accommodate all 3 EVM boards.

I cannot confirm its operation on the FDC2214EVM board but assumed it originally worked prior to my updates.

Join the dark side!

LabVIEW2010.zip

  • The files are provided as is. The user should assume all responsibility and risk in using these files.

    Regards,

    Yibo

  • Hello,

    I combined a couple of the VI files and put them into one file. Outside a while loop, I write the registers (based on a setup for a test I am running) and tell the FDC2214EVM to start streaming. Inside the while loop, I read back from the EVM, then I perform the calculations to get the sensor capacitance and I graph this information. For each data point I receive in Y (capacitance), LabVIEW plots this in X as a series of increasing integers.

    When using the TI GUI, the data is sent to a CSV file as Y(capacitance) and X(time) instead of a series of increasing integers. My question is how do I get the time component along with capacitance when taking a read  - (Samples/second/channel is set to 829.694 in this instance)? When the data is in a while loop, it will loop as fast as it can to get data reads. If a timer is introduced, data points will be lost. Is there a way to have an accurate time output from VISA?

    Please note: Attached files are the responsibility of the user.

    Tester.zip

  • In reply to James Mannion:

    Hello James,


    I cannot open your vi (no LV2016 on my machine), but if it's based on the source given above in this thread, then it uses a legacy protocol, for which timestamp in the data packet is not available.


    The FW implements this old legaxy protocol as well as a newer protocol with the time stamp, which TI GUI uses. We are working on documenting this protocol, and will likely provide LV wrappers as well.

    In the meanwhile you can use LV timestamp in your while loop to get the time. Not as accurate as MCU timestamp, of course, but do you really require that kind of precision? moreover, if I recall correctly, the legacy prtocol does not support streaming faster than 1kS/s anyway.

    With best regards,

    Evgeny Fomin

    Pr. Systems Architect

    SSP PSP SVA

  • In reply to Evgeny Fomin:

    Hi Evgeny,

    I have attached a saved VI in LabVIEW 10 version (hopefully). The reason I am looking to get the timestamp data with the capacitance is because I am trying to get the frequency of the oscillation of capacitance back from the board. I am not able to get the loop data to give me timestamp data that works for this purpose.

    To get the time data, I would need to issue a different set of commands from another protocol set? Is there a rough draft of the new protocol available currently?

    Thank you for your help,

    James Mannion

    New Tester.zip

  • In reply to James Mannion:

    Hello James,

    I would organize your VI differently.

    In 1 loop, I would collect 32 bytes from port, get LV timestamp  right after data is collected, and send all to another loop which will be processing the data.

    As it is implemented, it takes a long (and unpredictable) amount of time to update the front panel.

    The new protocol is implementation is shown in C:\ti\Sensing Solutions EVM GUI-1.9.1\PC GUI\node_modules\SspEvmNodeJS\SensingSolutionsEvm_Protocol_0v1.js

    Open the file with something like notepad, and you will see the format.

    With best regards,

    Evgeny Fomin

    Pr. Systems Architect

    SSP PSP SVA

  • In reply to Evgeny Fomin:

    Hi Evgeny,

    I tried what you suggested and I believe the issue is that I am not getting the data out of the board fast enough in Labview. When setting it up, it appears as though the maximum read rate that I can achieve is approximately 95Hz no matter what I do. I had read that taking multiple sample reads in one loop and then passing them to another loop may speed things up. I have attached the vi in which I take 320 bytes in one loop and pass it to another loop, the result is the same as just taking 32 bytes, the sample read is no greater than 95Hz.

    Would you happen to have any idea what may be wrong with my implementation? I took the board configuration from the register screen in the TI GUI where I configured a value of approximately 830 samples/second/channel.

    Thank you in advance for your help,

    James Mannion

    Tester3 Folder.zip

  • In reply to James Mannion:

    Hi James,

    Apologies for the delayed answer, I was out of town.

    I see the issue now.

    Please change the Interval to something smaller. In your code it's set to 2904.

    You should read this value as LSB 1st, i.e. it's 0x0429. It's a tide delay between transaction, scaled by MSP clock.

    I ran your code and also have seen SPS ~100. Once I changed the value to 0x0100 (You enter 1 into the control) or 0x0050 (5000 in control) I got expected data rate.

    With best regards,

    Evgeny Fomin

    Pr. Systems Architect

    SSP PSP SVA

  • In reply to Evgeny Fomin:

    Hi Evgeny,

    Thank you so much for your suggested answer. I tried the interval change and it worked as you said it would. 

    Could you please tell me what the other parts of the start streaming command are responsible for and what the options are?

    • PID - currently set to 01
    • Stream Option/Packet Format 3 - currently set to 04
    • The other one is untitled at the end of the command 302A

    Thanks again for your help, it has solved the issue

    James

  • In reply to James Mannion:

    Hello James,


    Welcome, glad to help!

    To answer your questions:

    1) PID. The protocol supports multiple streams, PID will be the ID of a particular stream. I have never seen any use for it in real life.

    2) Packet format:

    Packet Format:

    Value (Decimal)

    Packet streamed out

    0

    Header + Data + CRC

    1

    Header (no error code) + Data + CRC

    2

    Header (no dev num, no error code) + Data + CRC

    3

    Data + CRC

    4

    Data only

    3) x302A: 30 - is the specific command to stream DATA from FDC (as opposed to stream something else). 2A is the I2C address of the FDC.

    With best regards,

    Evgeny Fomin

    Pr. Systems Architect

    SSP PSP SVA

  • In reply to Evgeny Fomin:

    Hi Evgeny,

    Thank you once again for the reply, I have everything I need now for my project.

    Your help was most appreciated,

    James