DTN_Gary_Stephen has contributed to 295 posts out of 20869 total posts
(1.41%) in 1,361 days (0.22 posts per day).
20 Most recent posts:
The only possibility is normal for intervals to be missing if no trading occurred during that time period. You don't mention what day you inquired about, but it's possible there were no trades between 00:00-00:01 and 18:00-18:01 on that day. If you post the request here, I can dig deeper.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
Not at that time, no. Could have been temporary conditions. Let me know if you're still having a problem.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
Yes, you would need "IQFeed RT Equity Options" as well as the "OPRA" data subscription.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
It should be correct now. We have corrected the "Split #1" in the Fundamental Message and the back-adjustment of the daily data. Thank you for letting us know.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
I will investigate what happened and post findings here.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
I was going by your statement "If you intend to ask for a 24 hour period by using 00:00:00 and 00:00:00 as BeginTime and EndTime, and you do it for two consecutive days." In this scenario, if it is an HTT request, you would get the first second after midnight as part of both requests. HIT requests will not have this problem.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
If you're requesting tick data, you should request from 000000 to 235959 (or 000001 to 000000) to get an entire 24-hour day today with no overlap. This can be demonstrated with an example:
HTT,QCL#,20230214 000000,20230215 000000 LH,2023-02-15 00:00:00.788827,78.37,1,11813,78.37,78.38,11887050,C,112,01,2,15, LH,2023-02-15 00:00:00.788827,78.37,1,11812,78.37,78.38,11887050,C,112,01,2,15,p LH,2023-02-14 23:59:53.336951,78.38,1,11809,78.38,78.39,11887046,C,112,01,2,15, LH,2023-02-14 23:59:40.433622,78.38,1,11808,78.38,78.39,11887042,C,112,01,2,15, (lots of ticks) LH,2023-02-14 00:00:25.045924,79.26,1,11300,79.26,79.27,11415859,C,112,01,2,14, LH,2023-02-14 00:00:02.727061,79.26,2,11299,79.25,79.26,11415857,C,112,01,1,14, LH,2023-02-14 00:00:00.784311,79.25,1,11297,79.25,79.26,11415852,C,112,01,2,14, LH,2023-02-14 00:00:00.784311,79.25,1,11296,79.25,79.26,11415852,C,112,01,2,14, LH,2023-02-14 00:00:00.755201,79.26,1,11294,79.26,79.27,11415849,C,112,01,2,14, LH,2023-02-14 00:00:00.755201,79.26,1,11293,79.26,79.27,11415849,C,112,01,2,14, !ENDMSG!,
As you can see, a request from 000000 to 000000 includes the first second after midnight for both days. A request from 000000 to 235959 includes up to 235959.999999, but nothing after 000000.0000000.
HTT,QCL#,20230214 000000,20230215 235959 LH,2023-02-14 23:59:53.336951,78.38,1,11809,78.38,78.39,11887046,C,112,01,2,15, LH,2023-02-14 23:59:40.433622,78.38,1,11808,78.38,78.39,11887042,C,112,01,2,15, (etc) !ENDMSG!,
Again, this only applies to tick-level requests. Bars will not overlap in this way:
HIT,QCL#,60,20230214 235700,20230215 000300 LH,2023-02-15 00:03:00,78.37,78.35,78.36,78.36,11878,30,0, LH,2023-02-15 00:02:00,78.37,78.35,78.36,78.36,11842,7,0, LH,2023-02-15 00:01:00,78.37,78.37,78.37,78.37,11833,6,0, LH,2023-02-15 00:00:00,78.37,78.35,78.37,78.36,11822,9,0, LH,2023-02-14 23:59:00,78.38,78.36,78.36,78.38,11809,19,0, LH,2023-02-14 23:58:00,78.36,78.34,78.35,78.34,11785,19,0, LH,2023-02-14 23:57:00,78.35,78.35,78.35,78.35,11761,6,0, !ENDMSG!,
The 00:00:00 bar includes only the ticks from 00:00 to 00:00.999999.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist Edited by DTN_Gary_Stephen on Feb 15, 2023 at 08:43 AM
altmany, you're right - I was conflating two things that really weren't related.
I was thinking of historical tick requests, which can include a tick in multiple time ranges. For example:
HTT,EQS,20230210 093035,20230210 093036 LH,2023-02-10 09:30:36.446,1.6800,100,200,1.5900,1.7200,808473395,C,7,3D,0,10, !ENDMSG!, HTT,EQS,20230210 093036,20230210 093037 LH,2023-02-10 09:30:36.446,1.6800,100,200,1.5900,1.7200,808473395,C,7,3D,0,10, !ENDMSG!,
The historical tick request from 9:30:35 to 9:30:36 technically includes everything from 9:30:35 to 9:30:36.999. So A tick at 9:30:36.446 is included in both time ranges.
A HIT request doesn't include the milliseconds after the stop point, because that would put the same data in multiple bars, as you point out. You can see that only one bar contains the 1.68 tick (I picked a low-volume stock for this example):
HIT,EQS,1,20230210 000000,20230210 180000 LH,2023-02-10 09:30:38,1.7200,1.7200,1.7200,1.7200,300,100,0, LH,2023-02-10 09:30:36,1.6800,1.6800,1.6800,1.6800,200,100,0, LH,2023-02-10 09:30:00,1.6000,1.6000,1.6000,1.6000,100,100,0, !ENDMSG!,
I hope I didn't make this even more confusing.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist Edited by DTN_Gary_Stephen on Feb 13, 2023 at 01:01 PM
Quicktick,
You're conflating two things that aren't really related.
"It defaults to the end" has to do with the label a bar has. A bar from 10:40 to 10:45 can be called either 10:40 or 10:45, depending on what LabelAtBeginning is set to. It just affects what time frame is represented.
No matter what label you use, all bars include everything up to .999999 of the specified ending minute and second. A bar from (start time) to (end time) will include all ticks from (start time).000000 to (end time).999999. So 10:40 to 10:45 would include 10:45:00.999999. This is a standard behavior of bars, and how it handles fractions of a second.
I hope this helps.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist Edited by DTN_Gary_Stephen on Feb 13, 2023 at 11:35 AM
I can submit a customer request, but it wouldn't be an instant change.
Historical tick and minute data isn't split-adjusted; only daily data is. The SnapQuote app tells you the time/ratio (to two decimal places) of the most recent two changes.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
By "getHistory", do you mean the legacy COM objects that start with reqHistory, as described at http://www.iqfeed.net/dev/api/docs/docs52/HistoricalviaCOM.cfm ? Or are you using the modern TCP/IP history requests, like HIT or HID?
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
JasonL, can you send an email to IQFeed support with your account info so we can investigate further? Thank you.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
Message: the afternoon of 12/21, some users began reporting that they are unable to connect with IQFeed. We believe this is an ISP-related issue, and our network team is continuing to investigate.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
You've got the right idea. Intervals assume a midnight start. 78 minutes divides evenly into a 390-minute day, but not a 1,440-minute day, and not in a way that 9:30 am is the start of a new bar. I used this, which is the same as your command:
HIT,ABBV,4680,20221213 000000,,,093000,160000,1,,,s,0 LH,2022-12-13 10:48:00,167.1600,165.6200,166.9200,166.0600,1134223,417761,0, LH,2022-12-13 12:06:00,166.0600,164.7100,166.0500,164.9850,1709943,394991,0, LH,2022-12-13 13:24:00,165.5500,164.6900,164.9850,165.0850,2106981,253186,0, LH,2022-12-13 14:42:00,165.9400,164.8300,165.0900,164.8600,2610699,323191,0, LH,2022-12-13 16:00:00,165.6500,164.6700,164.8900,164.9200,3536972,644521,0, !ENDMSG!,
I'm looking into that Open price. I don't see any ticks for 166.92 during that time frame and I'm not sure where it's coming from. Edited by DTN_Gary_Stephen on Dec 13, 2022 at 03:23 PM
If something were interfering with the HTT command (like a bug in Wine), it should be possible to confirm this via the iqconnect.txt log. Turn on "lookup requests", and the log will contain all historical requests that were sent to the IQFeed API. If something is changing the HTT command such that it fails, it will show up here.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
Quote: Does this mean I can make 50 new historical requests per second, even if the previous ones have not finished?
Yes.
Quote: do existing historical requests count in this 50 count as well?
No. The historical request limits formerly worked this way, but don't anymore. It's just 50 per second, period. It doesn't matter how many are still running.
I should clarify that the 50 per second limit is per login ID. Making multiple connections with the same login ID doesn't let each connection make 50 requests per second. It is 50 total across all connections, unless you have multiple login IDs.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
I can't imagine why the same HTT request would return data some times and not others, unless it's running afoul of the "8/180" rule.
During regular trading hours (9:30 – 4:00 US Eastern time), tick data is only available for the last 8 days, and API requests will not return anything older during that time. Outside regular trading hours, tick data requests for up to 180 days will be processed.
So if you make the same request inside and outside of those times, and it's for data more than eight days old, that would explain getting different results. Beyond that, I'd need to see the entire request.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
If you're doing a Level 1 follow, then yes - each individual option symbol counts as one "symbol" against your limit, even if they have the same root symbol.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
mkvalor,
1. Can indexes and market stats actually be consumed via an L1 Watch API call? Yes, they behave just as any other symbol would. You are correct that fields like Bid and Ask will have no meaning, so you can omit them from your message using the S,SELECT UPDATE FIELDS message as Stargazer suggested. (see http://www.iqfeed.net/dev/api/docs//DynamicFieldsets.cfm)
1A. are there any special values for any of the dynamic fields (such as "Message Contents") Not that I know of, but I'll double-check.
2. 2. Do people instead request streaming interval bars for these with an interval set as low as applicable (with a floor of 1 second)? If the old thread I referenced is correct about tick-by-tick frequency, this wouldn't take advantage of the "realtime" subscription.
You are correct that this wouldn't be very efficient - if an indicator updates once a second, then there's no advantage to streaming interval bars versus a Level 1 follow. Some people don't need tick-by-tick precision, though, so I wouldn't be surprised to learn that some people only collect the data minute-by-minute.
I guess one might simply use "last" from the OHLC values and just discard the other 3 "price" fields? See above: most market stats use only Last, and other fields are left blank, or have placeholder values.
is there an upper limit to the number of 1-second streaming bars calls I can make (currrent day only) or is this simply included in the (base) 500-symbol limit? Included in your symbol limit.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
No, that is correct. Any tick with a timestamp between 9:30:00.000000 and 9:30:00.999999 will be part of the "9:30:00" or "9:30:01" bar.
One other thing I should have mentioned in my prior post: that you can specify whether the label represents the beginning or the end of the time period. It defaults to the end, so "10:40:00" represents 10:39:59 to 10:40:00. If you set LabelAtBeginning to 1 in your HIT/HID/HIX historical request (see http://www.iqfeed.net/dev/api/docs/HistoricalviaTCPIP.cfm) then "10:40:00" will represent 10:40:00 to 10:40:01. This choice does not affect the underlying data in any way, just how it is labeled. A second will consist of ticks with timestamps between .000000 and .999999.
Sincerely, Gary Stephen DTN IQFeed Implementation Support Specialist
|