Hello,

I've come across strange issue:

I subscribed realtime bars data using BW request via derivatives port and got:

BC,@VX#C,2019-10-22 10:29:00,16.100,16.100,16.100,16.100,13604,8,,
BC,@VX#C,2019-10-22 10:30:00,16.100,16.150,16.100,16.100,13563,3,,
BC,@VX#C,2019-10-22 10:31:00,16.100,16.100,16.100,16.100,13730,16,,
BC,@VX#C,2019-10-22 10:32:00,16.100,16.150,16.090,16.100,14938,964,,
BC,@VX#C,2019-10-22 10:33:00,16.100,16.100,16.100,16.100,15603,637,,
BC,@VX#C,2019-10-22 10:34:00,16.100,16.150,16.100,16.150,16028,338,,
BC,@VX#C,2019-10-22 10:35:00,16.150,16.160,16.140,16.150,16634,577,,


then I requested bars (HIT request) using lookup port

42,2019-10-22 10:29:00,16.150,16.100,16.100,16.150,13607,11,
42,2019-10-22 10:30:00,16.150,16.100,16.100,16.100,13783,3,
42,2019-10-22 10:31:00,16.100,16.100,16.100,16.100,13950,16,
42,2019-10-22 10:32:00,16.150,16.100,16.100,16.100,15371,1177,
42,2019-10-22 10:33:00,16.100,16.100,16.100,16.100,16036,637,
42,2019-10-22 10:34:00,16.150,16.100,16.100,16.150,16461,338,
42,2019-10-22 10:35:00,16.150,16.150,16.150,16.150,17083,593,

Lookup port data has more aggregated ticks in comparison with data from derivatives port.
Also If I request history ticks, I get more records than Level1 ticks.
Why? Is there any way to receive the same data from Level1, Lookup and Derivatives ports?

Regards

I am looking into this now, and will post an answer soon.

---

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist

any news?

Yes, I apologize for not replying until now. But I can answer your question:

The HIT function defaults to having the time label at the beginning of the interval. So in your example:

HIT,@VX#C,60,20191022 102800,20191022 103400,,,,1

2019-10-22 10:28:00,18.300,18.250,18.250,18.300,13607,11,0,
2019-10-22 10:29:00,18.300,18.250,18.250,18.250,13783,3,0,
2019-10-22 10:30:00,18.250,18.250,18.250,18.250,13950,16,0,
2019-10-22 10:31:00,18.300,18.250,18.250,18.250,15371,1177,0,
2019-10-22 10:32:00,18.250,18.250,18.250,18.250,16036,637,0,
2019-10-22 10:33:00,18.300,18.250,18.250,18.300,16461,338,0,
2019-10-22 10:34:00,18.300,18.300,18.300,18.300,17083,593,0,

The time period designated 10:29:00 is the beginning of the interval; this interval covers the time from 10:29:00 to 10:29:59.99999. It is possible to make this request such that the time period labeled 10:29:00 ends at 10:29 instead of starting at 10:29. That parameter is called LabelAtBeginning, and you have to enter a 0 there:

HIT,@VX#C,60,20191022 102800,20191022 103400,,,,1,,,,0

This will return:

2019-10-22 10:29:00,18.300,18.250,18.250,18.300,13607,11,0,
2019-10-22 10:30:00,18.300,18.250,18.250,18.250,13783,3,0,
2019-10-22 10:31:00,18.250,18.250,18.250,18.250,13950,16,0,
2019-10-22 10:32:00,18.300,18.250,18.250,18.250,15371,1177,0,
2019-10-22 10:33:00,18.250,18.250,18.250,18.250,16036,637,0,
2019-10-22 10:34:00,18.300,18.250,18.250,18.300,16461,338,0,
2019-10-22 10:35:00,18.300,18.300,18.300,18.300,17083,593,0,

The time period designated 10:29:00 is now the time period beginning at 10:28:00.0000001 and ending at 10:29:00. You can see that the time period with 11 volume is labeled 10:28 in the first example and 10:29 in the second. So you can make the timeframes of the history command match those of a watch command if you want.

Sincerely,
Gary Stephen
DTN IQFeed API Support

---

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist

Thanks for response, but time labelling is not the case.

In your example nothing changes except timestamps.

In my case volume values are completely different:

realtime:
BC,@VX#C,2019-10-22 10:32:00,16.100,16.150,16.090,16.100,14938,964,,

volume=964

history:
42,2019-10-22 10:32:00,16.150,16.100,16.100,16.100,15371,1177,

volume=1177

It doesn't look like LabelAtBeginning issue