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.

LDC1314EVM: EVM GUI sampling time

Part Number: LDC1314EVM
Other Parts Discussed in Thread: LDC1314

Hello,

I'm using the Sensing Solutions EVM GUI to log data from the LDC1314EVM and found out that the sampling time doesn't match the actual measurement time. 

As an example, I recorded data during approx. 10.5s, but if I sum the values of the "logDeltaMs" column in the log file I get only approx. 4.9s. It means that the actual data logging time is much greater than the sampling time set in the Configuration window. 

I used single channel mode and selected the option "EVM Output rate" in the Data Streaming - Graph Configuration window.

So, how should I use the time delta columns in the log file?

Thanks,

Daniel

  • Hello Daniel, 

    The EVM Output Rate is the rate that the EVM can transfer data to the GUI and is slower than the LDC1314 can sample. Using the GUI to plot the data means that there will be some samples from the LDC that aren't included in the data. The time delta between samples is shown next to the EVM Output Rate selection option and should be around 2.59ms: 

    Best Regards, 

    Justin Beigel

  • Hello Justin,

    I got it, but my point is: how can I correlate the time delta shown in the log file with the actual measurement time?

  • Hello Daniel, 

    The 'logDeltaMs' column in the log file is the delta time between samples being updated to the graph. The only samples that are put in the log are ones that are from the graph. The rate that the LDC is sampling is determined by the register settings. The Configurations tab has a calculation for LDC sampling time. If this rate is faster than the rate the graph is updating, then any samples in between the graph updates are not recorded. 

    Best Regards, 

    Justin Beigel

  • Hello Justin,

    I guess you didn't get my point, let me try it again: if you sum all the values in the column 'logDeltaMs' you should get the total period of your measurement. The problem is the total period you get from this sum is significantly less than the actual total period. For instance, I ran the 'Data Streaming' during 30s counting it with an external stopwatch, but got only 13.9s as sum in the 'logDeltaMs' column.

    So, the point is how the 'DeltaMs' values in the log file correspond to the actual measurement time. 

    Thanks,

    Daniel

  • Hi, 

    I just found out that this problem happens if you update the firmware. I took a fresh EVM and it was logging the time correctly, than I updated the firmware to "EVM_LDC1314_RevB" and the problem appeared.

    Now an additional problem is: if you try to upload the firmware "EVM_LDC1314_RevA" after the EVM has been updated to RevB, you get no connection anymore with the EVM. Is there any hard reset or a known solution here?

    BR,

    Daniel

  • Hello Daniel, 

    You can re-flash the EVM by following these directions: 

    Q1: I have 'bricked' my LDC1312, LDC1314, LDC1612, or LDC1614 EVM during a failed firmware upload attempt. What can I do to restore functionality?

    As for the difference between measurement time and the log file, did you use a different buffer length between the two measurements you took? I know there is a slight delay between the measurements and writing to the log file so if you take data for a longer time, do you eventually get 30s worth of data in the log file? 

    Thank you, 

    Justin Beigel

  • Hello Justin,

    Good news that there is a way to reflash the EVM, but unfortunately there is no such process described in the user guide and the link you sent only shows the short connection. So, can you please give me detailed instructions for reflashing?

    I didn't notice any difference by the buffer length. Before updating the EVM to firmware RevB I got 30s worth of data in the log file.

    Thanks,

    Daniel

  • Hello Daniel, 

    It seems the guide for BSL is not currently online. Please follow the instructions on using the python firmware upgrader in the following thread: 

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/989465/ldc1614evm-connecting-and-firmware-upgrade 

    I have confirmed that this will work once the EVM is put into BSL mode. Shorting the EVM before powering it up will put it in BSL and then you can remove the short once the EVM is powered up. 

    I am looking more into the data logging differences that you are seeing and will have an update for you early next week. In the meantime, would you be able to record data for a longer time so that you have 30 seconds in the log file? Recording for about 1 min seems to work for me each time. 

    Best Regards, 

    Justin Beigel

  • Hello Justin,

    The re-flashing process was successful, nevertheless the same issue happens with the sampling/measurment time. 

    I have compared a "fresh" EVM with an "upgraded firmware" EVM, please check the attached log files. Data streaming was done in single channel mode, with 6.8ms sampling time and new data sample rate of 25ms in both cases.

    This issue is linked to the firmware file, so I have also attached it below. 

    Thanks,

    Daniel

    30s_25ms_fresh.xlsx

    30s_25ms_upgraded_firmware.xlsx

    EVM_LDC1314_RevB.txt

  • Hello Daniel, 

    I am still looking into what is causing the difference in sample rate. There is no discrepancy between the GUI and log file but it appears that the GUI is not recording data as fast as the reported sample rate with the newer firmware. If the timing of the samples recorded is critical for your testing with the EVM, it would be best to use the older firmware or a different method of collecting samples (either interacting with the MSP directly, creating your own firmware, or using an external controller). 

    Best Regards, 

    Justin Beigel

  • Hello Daniel, 

    Looking further into the differences between the firmware versions, there is a lot of dependence on the USB communication that is happening with the GUI software to determine the timing. The firmware doesn't change too much in this portion of the code and it is hard to tell exactly why the different timing is showing up in the GUI. At this time, the only solution we can provide is to use an external controller with the LDC if you need exact timing in your prototype application. 

    Best Regards, 

    Justin Beigel