Clarification about Sample Clock timing with XCP

[croohcifer]

Hi all,

I'm new to XCP and just started playing around with the DAQ list APIs.  I'm scratching my head over how XCP DAQ lists are timed and wanted to clear up my understanding.  I'm using XCP over CAN, which is an asynchronous serial protocol. 

My undestanding has been that when using a DAQ list, there was a register on the XNET board that always maintained the most recent XCP signal sample transmitted from the ECU and that there was a sample clock on the XNET hardware responsible for latching that most recent sample into a FIFO.  With a 10 ms event channel and a sample rate of 1000 Hz (1 ms period), I can indeed see that I get ~10 repeat samples at a time, which makes total sense.  However, I just realized that with "MC DAQ List Initialize.vi" I can specify an arbitrarily high (I tried up to 100 GHz) sample rate, and the XCP API doesn't error and does seem to return me data at that rate.  (I get tons of repeat samples, and the dt in the waveform reflects my selected sample clock period.)   I can't imagine that the hardware supports clocks this fast, so I'm revising my assumption of a hardware resampler to a software resampler.  I'm guessing that the hardware latches ALL incoming XCP signal samples into a FIFO with a timestamp (determined by the Timing Source property), and that in the driver/software layer, the data is resampled to the requested sample rate.  Is that an accurate statement?

[pipipi0405]

It is not possible to set hardware timed clock for XCP or CCP with ECUMC Toolkit.

There is no documentation that explicitly says so, but it can be inferred from how the description is written below:

http://www.ni.com/pdf/manuals/371601n.pdf#page=49

The reason why the samples were repeated was because DAQ Read returns the previous value until a new value reaches the CAN transceiver. 

Therefore, it is not possible to explicitly synchronize XCP reading to other hardware timed read. Sample rate is determined by software clock.

[WaldemarM]

The behavior you have described is when you use DAQ List Mode in DAQ Initialize, but there is also a TImestamped mode which returns values on every incoming frame.

[croohcifer]

---

@WaldemarM wrote:

The behavior you have described is when you use DAQ List Mode in DAQ Initialize, but there is also a TImestamped mode which returns values on every incoming frame.

---

Thanks, that helps clarify!  A couple of questions follow about the timestamps.  I'm having some trouble understanding the Timing Source property when set to ECU Timing.  This is what I expect to happen.

1. If I am in DAQ List mode, I can read my data as a Waveform data type, which has a single t0 timestamp, a single dt applied to all N samples, and N samples of Y data.  The t0 timestamp will come from the selected Timing Source option.  In other words, if I select ECU Timing, the t0 in my waveform will be the timestamp the ECU provided in the first XCP frame received after calling DAQ Read.
2. If I'm using timestamped mode, I get one timestamp returned for every sample.  Each timestamp is generated from my selected Timing Source option (Host, XNET hardware, or ECU).  In other words, every time I select ECU Timing, I receive a new XCP frame on the bus, the XNET hardware buffers both the sample and the timestamp from the frame.

This is what I expect to happen, but the help seems to suggest otherwise.  The help states that with ECU Timing, "Timestamps are taken from the ECU data. The Start Time is taken from the host, and increments are taken from the ECU."  Thus:

1. If "[t]he Start Time is taken from the host" when using ECU Timing, then when I use a DAQ List and read a Waveform data type with DAQ Read, setting the Timing Source property to Host Timing or ECU Timing should result in identical timestamping behavior.  This is because there is only a single t0 (i.e., Start Time) reported.  So selecting ECU Timing in this case is meaningless.  The only timestamp I ever get access to comes from the host.  The single dt value reported is based on my Sample Rate when I initialize my DAQ List.  Is this all correct?
2. If using ECU Timing in timestamped mode, then the first timestamp in my returned timestamp array comes from the host.  I'm confused about how subsequent timestamps are generated.  I'm reading "increments are taken from the ECU" to mean that the XNET hardware or driver uses the incoming XCP timestamps to calculate the dt between each sample and that that dt is then added to the initial host timestamp to get the timestamp array.  Is that an accurate statement?
   1. As an example, if I received three XCP messages that contain timestamps (in HH:MM:SS format) 00:00:00, 00:00:01, and 00:00:03, but my host time was 04:05:00 when the first XCP message arrived, then I should expect the three samples I read to report timestamps 04:05:00, 04:05:01, and 04:05:03 when I read in timestamped mode with ECU timing.  Right?

If I'm reading the help and interpreting everything correctly, this means that there is no DAQ Read method available for a user to read an actual timestamp in the XCP frame.  When using ECU Timing, all timestamps are either host timestamps or host timestamps + a delta between subsequent XCP frame timestamps.  Is that correct?

[timtamslam]

I have a related post. I want to make sure the information received here does not conflict. 

https://forums.ni.com/t5/Automotive-and-Embedded-Networks/XCP-DAQ-Timing-Source-ECU-and-CAN-Timing-w...

My assumption and question: 

So the host sets our 't0' and the values that correspond with each 'dt' step in the waveform are resampled based on the timestamp value provided by the ECU and NOT by the time in which the XNET HW buffered/stamped the value. Is this all correct? 

Answer from NI:

Your assumption is correct.

[croohcifer]

"I have a related post. I want to make sure the information received here does not conflict."

I could not agree more!

Here's my issue:  I'm not sure what precisely you mean by the "resampling" or how NI interpreted it when they responded.  It sounds pedantic to be specific about this, but I want a really clear answer so I can have confidence in the data I'm gathering with this API. 

To address your post directly:  In DAQ List mode, the help states that t0 is timestamped by the host, so I don't have an issue there.  I start disagreeing about the resampling statement.  I don't think there's any resampling going on that's based on timestamps.  I think every sample that comes in is assumed to be at the event channel rate (divided by the DAQ List Prescalar), and then there's a resampling based on the target dt (the reciprocal of your selected sample rate)...  That's what I gather from the help anyway, and I think that's distinctly different than "resampl[ing] based on the timestamp value provided by the ECU". 

I'm shooting in the dark here and would really appreciate a more verbose explanation or documentation from NI.

[WaldemarM]

I'm giving an example how the resampling works:

Assume, we use resample rate of 100 Hz (10 ms) and we read frames with following timestamps from the hardware:

 6 ms, 12 ms, 18 ms, 25 ms, 34 ms, 40 ms (relative to t0)

This results in outputing of the values of the following samples:

1: 0ms (default value for the signal, as no frame arrvied at this time)

2: 10ms: Value from frame at 6 ms

3: 20ms: Value from frame at 18 ms (12 ms is skipped as outdated at 20 ms).

4: 30 ms: Value from frame at 25 ms 

5: 40 ms: Value from frame at 40 ms (34 ms frame was skipped again).

The timestamps of the frames (6 ms, 12 ms..) are taken from the ECU, CAN hardware or the host, depending on the selected Timing Source.

[croohcifer]

Great, so I think that clears up the DAQ list scenario for me and confirms that in the DAQ list scenario, the user never sees an ECU timestamp.  We only see the t0 host timestamp and all subsequent timing is generated from the dt.

Can you post a similar example of how it works in the "time stamped read" mode?  Specifically, I want to know if what I wrote above is correct:

If using ECU Timing in timestamped mode, then the first timestamp in my returned timestamp array comes from the host.  I'm confused about how subsequent timestamps are generated.  I'm reading "increments are taken from the ECU" to mean that the XNET hardware or driver uses the incoming XCP timestamps to calculate the dt between each sample and that that dt is then added to the initial host timestamp to get the timestamp array.  Is that an accurate statement?

1. As an example, if I received three XCP messages that contain timestamps (in hh:mm:ss format) 00:00:00, 00:00:01, and 00:00:03, but my host time was 04:05:00 when the first XCP message arrived, then I should expect the three samples I read to report timestamps 04:05:00, 04:05:01, and 04:05:03 when I read in timestamped mode with ECU timing.  Right?

---

Thanks!

David

[WaldemarM · Accepted solution]

>>We only see the t0 host timestamp and all subsequent timing is generated from the dt.

This is correct. And dt is paced by the timing source.

Also your assumption of timestamped mode is correct.

[wade75]

You have to be careful when assuming the XNET Timestamp data is the sampling frequency of the DAQ List Data.  This time is when the Transceiver receives the message from the ECU.  Some ECUs I've found use a burst mode where it buffers data in its memory and then bursts it out on the CAN Bus at a much faster rate then the DAQ list sample rate, I'm assuming its to keep bus load at a minimum but I'm not totally sure on that.  Usually when setting up a DAQ List there is a Frame that tells the ECU to Enable Timestamp and the ECU transmit a Timestamp using the bytes 2 and 3 on the first Table (PID0) of data.  Usually a value of 0 - 2^16.  This value will eventually rollover so you would have to handle the rollover otherwise you will induce jitter.  The time stamp units would be dependant on the ECU but most times I dealt with it is in microseconds.  Hope this helps.