LORD-MicroStrain / LabVIEW-MSCL

A VI package that provides an easy to implement LabVIEW interface to the .NET version of MSCL.
MIT License
3 stars 0 forks source link

Not Getting Data from Nodes using Datalogging #1

Closed Ed-1138 closed 7 years ago

Ed-1138 commented 7 years ago

I've been using the LabVIEW VIs for communicating with three VLink -LXRS nodes through the WSDA-1500 gateway. I have the continuous Synchronized Sampling working and consuming the data at 64 Hz to a chart. I'm attempting to use the ArmedDatalogging, but there is no data available from the gateway. The Device Status Indicator is ON green so it appears to be logging data. However, there are no sweeps available from the BaseStation GetData VI.This is the sequence I'm using: 1) Get object to BaseStation 2) Set BaseStation command timeout to 3 seconds 3) Disable BaseStation Beacon 4) Get object to a Wireless Node 5) Do a Quick Ping to Wireless Node and set to Idle if ping failed 6) Get Wireless Node Configuration object, configure the following and Apply Configuration to EEPROM. Set dataCollectionMethod to collectionMethiod_logOnly Set samplingMode to samplingMode_armedDatalog Set samplerate to 64 Hz Enable unlimitedDuration Set dataFormat to dataFormat_4byte_float Obtain channelMask object to set all activeChannels Obtain another single channelMask object and linearEquation object to set slope and offset and unit for each channel 7) Read back configuration to confirm all are set. 8) Get ArmedDataloggingNetwork object to the BaseStation 9) Use addNode to include WirelessNode in ArmedDataloggingNetwork 10) startSampling to ArmedDataloggingNetwork 11) Execute BaseStation GetData VI in a loop to consume the data

All I get is a count of Zero for the number of sweep data available in the loop.

rwslord commented 7 years ago

The BaseStation's getData() function only retrieves data that is coming in over the air. An ArmedDatalogging network only logs to the Node's internal storage.

After datalogging is completed, or you use the Set to Idle command to stop datalogging, the data is still logged to the Node. You can then use the DatalogDownloader object to download the data from the Node (you will need to do this per each Node).

Ed-1138 commented 7 years ago

I was able to navigate through the objects/classes and was successful at pulling in the sweeps with DatalogDownloader getNextData, identify the sessions and their starts and pull in the data with the LoggedDataSweep, ChannelDataand WirelessDataPointobjects.

I haven't been able to figure out how to delete or clear the saved sessions out of memory of the node. I can only do this manually using the SensorConnect tool.

The DataloggDownloader totalSweepsalways returns 0. Is there a way to detect the number of points in each session without scanning sessionIndexand startOfSession?

It looks like there are 4 Mbytes of memory available for datalogging in the V-Link. Does it use two bytes for each point per channel or is it based on the WirelessNodeConfig dataFormatsetting? Currently it's set for dataFormat_4byte_float for enabling the LinearEquationnormalization.

The logged data appears to not use the WirelessNodeConfig, ChannelMaskand LinearEquationobjects for normalizing like synchronized sweeps does. Are there functions to use for this or must it be normalized after downloading?

Thank you.

Ed-1138 commented 7 years ago

I did just find the erasefunction to clear out the sessions.

rwslord commented 7 years ago

The DatalogDownloader::totalSweeps function has been removed from MSCL at version 5.0.0. The Labview VIs are still on an older version of MSCL, so this function is available but has issues. There is currently no way of detecting the number of points in each session without scanning like you are suggesting.

The way we use that object is to just keep calling getNextData() until complete() returns true. This will download all the data (every session). And then as the data is downloading, we perform any special work that needs to be done when a new startOfSession() is detected.

On the V-Link-LXRS node, the data that is logged internally should be based on the dataFormat setting, so it should be 4-bytes per channel in your case, with the calibration coefficients already applied to the data.

I'm not sure I understand your last statement/question. The Node should be adhering to the configuration ChannelMask, LinearEquation, etc that you set on the Node. What do you mean by normalizing?

Ed-1138 commented 7 years ago

I did find WirelessNode getNumDataLogSessions that provides the number of sessions saved on the node. This will be useful.

The datalogged data comes in as 2-byte integer data (0 to 65535) converted to float even though I have the dataFormat set for dataFormat_4byte_float. The LinearEquation slopes and offsets are saved the same as for the synchronized data sampling mode I had working before trying out the datalogging. I used the term "normalized" the same as applying calibration coefficients after the data is downloaded. So I don't understand why the calibration coefficients aren't being applied to the data during downloading with the format set to 4byte float.

Another issue appeared when I noticed the data is only logged for exactly 10 seconds; samplerate times 10 seconds plus 1 total samples. This happens regardless of what my sample rate is. For example, with 64 samples/sec I get 641 samples or sweeps. I have a one second delay between starting the Datalogging and going to idle. My understanding from the Full Documentation is that if unlimitedDuration is enabled then it ignores the numSweeps setting and starts sampling with initiating ArmedDataloggingNetwork startSampling and stops when it receives WirelessNode setToIdle command. I did check the default setting for WirelessNodeConfig numSweeps is 3000. It is unclear why it is logging for exactly 10 seconds.

rwslord commented 7 years ago

That does seem odd. Can you send me the following?:

You can email me at richard_stoneback@lord.com if you'd rather get me the details that way.

rwslord commented 7 years ago

This issue has been resolved outside of github, but for reference:

The Armed Datalogging operation uses a hard-coded 10 second interval when the Node checks for the Set to Idle operation. Since the operation being performed in MSCL was to start the Armed Datalogging network sampling, wait 1 second, then use Set to Idle, it would take the Node at least 10 seconds to actually go back to Idle. This caused it to collect 10 seconds of data.

Set to Idle in general can take a variable amount of time to actually get the Node to stop sampling. The recommended way to use Armed Datalogging for a fixed duration is to disable unlimited duration, and set the number of sweeps that you wish to sample for.