Join the 80,000 other DTN customers who enjoy the fastest, most reliable data available. There is no better value than DTN!

(Move your cursor to this area to pause scrolling)




"You have an excellent product !!!!!!" - Comment from Arely
"I had always used ******* but for the past 2 weeks have been trying DTN IQFeed. Customer support has been extraordinary. They call just to make sure your problem hasn't recurred." - Comment from Public Forum
"And by the way, have to say this. I love the IQFeed software. It's rock solid and it has a really nice API." - Comment from Thomas via RT Chat
"Previously I was using *******. IQFeed is WAY more economical, and for my charting needs is just as good, if not better." - Comment from Public Forum Post
"I've been using Neoticker RT with IQFeed for two months, and I'm very happy with both of the products (I've had IQFeed for two years with very few complaints). The service from both companies is exceptional." - Comment from Public Forum
"Thanks for the great product and support. During this week of high volume trading, my QuoteTracker + IQ Feed setup never missed a beat. Also, thanks for your swiftness in responding to data issues. I was on ******* for a few years before I made the switch over early this year, and wish I had done it a long time ago." - Comment from Ken
"I've never had DTN go out on me since switching. ******* would go down a couple times every month when I was using them." - Comment from Bryce in AL.
"I noticed that ******* quotes locked up shortly after the interest rate announcement yesterday while yours stayed stable." - Comment from Ron in Utah
"Thank God for your Data Feed as the only Zippers I see are on my pants (LOL), and no more 200 pip spikes to mess up charts." - Comment from Spiro via Email
"IQ feed is brilliant. The support is mind-bending. What service!" - Comment from Public Forum Post
Home  Search  Register  Login  Recent Posts

Information on DTN's Industries:
DTN Oil & Gas | DTN Trading | DTN Agriculture | DTN Weather
Follow DTNMarkets on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
Viewing User Profile for: quickTick
About Contact
Joined: Nov 17, 2013 11:55 PM
Last Post: Feb 16, 2023 01:13 PM
Last Visit: Feb 17, 2023 10:38 AM
Website:  
Location:
Occupation: Investing
Interests:
Avatar:
AIM:
ICQ:
MSN IM:
Yahoo IM:
Post Statistics
quickTick has contributed to 53 posts out of 21159 total posts (0.25%) in 3,753 days (0.01 posts per day).

20 Most recent posts:
IQFeed Developer Support » How to create bar from tick data Feb 16, 2023 01:13 PM (Total replies: 22)

If so, there might be a value in having a third option for LabelAtBeginning, where the label for BeginTime would be at beginning, and the label for EndTime would be at end.

IQFeed Developer Support » How to create bar from tick data Feb 16, 2023 12:44 PM (Total replies: 22)

Quote: 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.

--- Original message by DTN_Gary_Stephen on Feb 16, 2023 06:22 AM
Your example doesn't show an HIT request using 00:00:00 and 00:00:00 as BeginTime and EndTime. Only the example HTT request does so.

So far, I would expect two HIT requests for two consecutive days, using 00:00:00 and 00:00:00 as BeginTime and EndTime, to both include the 00:00:00 bar that is between these two days. I believe this according to the example in the documentation.

However within a single request that crosses midnight, I would not expect any problem within the middle of the request, as your example shows. I would not expect such a problem for HTT either. The bars within a single request never overlap. Or if they did, that would a bug and completely different. I don't think we have a bug here, just that the documented behavior is easy to misunderstand when deciding which labels to use for BeginTime and EndTime, if you actually want the first bar to be *after* the BeginTime label, and the last bar to be *before* the EndTime label, which is spresumably the case if you use 00:00:00 to 00:00:00 intending to get 24 hour period. Since then, depending on the value of LabelAtBeginning, both the first and the last bar will be either before, or after each midnight.

IQFeed Developer Support » How to create bar from tick data Feb 16, 2023 04:22 AM (Total replies: 22)

Within a single request, there is no overlap.

IQFeed Developer Support » How to create bar from tick data Feb 14, 2023 02:00 PM (Total replies: 22)

> A 24 hour period would be: [00:00:00 - 00:00:00), that is it starts on midnight,
> and includes everything up to but not including the next midnight (less than)

That actual implementation appears to be 'less than or equal' for the interval specification.

The following example is from the documentation, asking for the days between the 19th and the 30th. It includes both the 19th and the 30th:

Request: HDT,GOOG,20080919,20080930,,,TESTREQUEST,2500,0<CR><LF>
TESTREQUEST,2008-09-30,425.10,392.32,395.98,400.52,8824587,0,<CR><LF>
TESTREQUEST,2008-09-29,423.51,380.71,419.51,381.00,10764969,0,<CR><LF>
TESTREQUEST,2008-09-26,437.16,421.03,428.00,431.04,5292751,0,<CR><LF>
TESTREQUEST,2008-09-25,450.00,435.98,438.84,439.60,5026917,0,<CR><LF>
TESTREQUEST,2008-09-24,445.00,430.11,430.34,435.11,4242795,0,<CR><LF>
TESTREQUEST,2008-09-23,440.79,425.72,433.25,429.27,5206644,0,<CR><LF>
TESTREQUEST,2008-09-22,454.13,429.00,454.13,430.14,4409119,0,<CR><LF>
TESTREQUEST,2008-09-19,462.07,443.28,461.00,449.15,10008745,0,<CR><LF>
TESTREQUEST,!ENDMSG!,<CR><LF>

So, my current understanding is this:

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, you actually get the 00:00:00 interval twice.

Depending on LabelAtBeginning, you get either the interval before midnight twice, or the intervall after midnight. Although each intervall begins with .000000 and ends with .999999 microsconds. Only the unspecified values are 'less than', whereas the specified interval is 'less than or equal'.

So if you are querying for minute intervals in a 24 hour period, you need to query either
00:00 to 23:59 or
00:01 to 00:00 next day, depending on LabelAtBeginning.

Although in each case, the bar before midnight ends with 23:59:59.999999 , and the bar after midnight ends with 00:00:59.999999.

Please correct if incorrect in any detail.
Edited by quickTick on Feb 14, 2023 at 02:01 PM
Edited by quickTick on Feb 14, 2023 at 02:02 PM
Edited by quickTick on Feb 14, 2023 at 02:04 PM
Edited by quickTick on Feb 14, 2023 at 02:05 PM

IQFeed Developer Support » How to create bar from tick data Feb 12, 2023 02:21 AM (Total replies: 22)

I think my previous message needs at least one correction:

I asked: "So that at the upper end, 10:40:00 is just a shorthand for saying 10:39:59.999999, regardless of the labelling direction?"

However I now think that at the upper end, 10:40:00 is a shorthand for 10:39:59.999999 only if the labelling is at the end.

If labelling is at the beginning, it is a shorthand for 10:40:00.999999 .

Strangely that seems to mean that at the lower end, with labelling at the end, 10:40:00 stands for 10:39:59.000000 .

So labelling at the end seems very confusing if one is interested in that detail at all.

The default now seems to be "1" for labelAtBeginning.
For that, the range for the whole day appears to be 00:00:00 to 23:59:59 .
Which will include 23:59:59.999999 .

The specification 00:00:00 to 00:00:00 (next day) would be wrong in either case.

IQFeed Developer Support » How to create bar from tick data Feb 12, 2023 12:37 AM (Total replies: 22)

I'm not completely clear on this comment:
"It defaults to the end, so "10:40:00" represents 10:39:59 to 10:40:00."

The meaning of the text seems to imply that more precisely, it includes only 10:39:59.000000 to 10:39:59.999999. So that at the upper end, "10:40:00" is just a shorthand for saying "10:39:59.999999", regardless of the labelling direction?

And 10:40:00.000000 is in the interval labeled "10:40:01", if the labelling is at the end ?

The point of my question is to make sure that with labelling at the end, I'd have to ask for
"00:00:01" to "24:00:00" to get the whole day. If 24 is an allowed value, otherwise I'd have to take the next days date and "00:00:00".

I'm not quite sure I'm asking this question in the best possible way. I wonder if it's more complicated. Or more simple.
Edited by quickTick on Feb 12, 2023 at 12:37 AM
Edited by quickTick on Feb 12, 2023 at 12:39 AM

Data Questions » What's Different for Index (VIX.XO) Level 1? May 5, 2021 11:22 PM (Total replies: 2)

In case this wasn't resolved in the meantime: I've been seeing 15 sec updates for VIX.XO
today.


Thanks for letting me know!

It did come back quickly enough.
Edited by quickTick on Mar 1, 2021 at 07:57 PM
Edited by quickTick on Mar 1, 2021 at 07:57 PM


I had a SERVER DISCONNECTED and a gap of quotes today around 10:30 am. Was it just on my end or a general thing? It was shortly after @ESH21 went below 3800.

The second time @ESH21 went below 3800, around 16:00, quotes continued, however the "T" time signal went up to 3 seconds behind.
Edited by quickTick on Feb 26, 2021 at 03:32 PM

IQFeed Developer Support » KB Queued in Admin Status Message Aug 18, 2020 02:22 AM (Total replies: 6)

According to the documentation, the info about KB queued is available on the admin port, if you ask for S,CLIENTSTATS ON.

As you say, it wouldn't make much sense for it to be in the port being queued. Providing the info in the admin port assumes the admin port itself is not queued, which is in fact less likely than for other ports.


Quote: Attached is the HTT response for @NQH19.

Note that the bids do not change for 17 minutes.

--- Original message by mac on Feb 21, 2019 07:20 AM
@ mac

In your text file, the bid keeps the value it first acquires at 02:01:12.834878, at the value of 7091.75.
That's about a screen down from the beginning.
Right in the next line, the bid gets crossed by both ask and trade. Perhaps that is not a coincidence that it happens so close.

Perhaps the bid gets stuck because bid and ask cross. For example, somewhere might be code like "if ask < bid", perhaps even as a safety guard, and that code causes it to get stuck at that value. If so, bid and ask probably shouldn't cross in the first place, but that might be just a delay in the delivery of one vs the other.

Just a suggestion, since I don't see that on my own screen displaying the historical tick data for NQ, as far as I can tell.


@ aQuant

I'm not sure about which field is which, but it doesn't seem to show the beginning.
Do quotes get crossed because they are stuck, or do they get stuck because they are crossed?


A quick test: the difference between local NTP time and "T" server time indicates "T" time has a small delay in addition to half of ping roundtrip. Symbols from Chicago have another, yet small, delay on top of that, and symbols from New York a bit higher delay. As far as I can tell, nothing strange or unexpected.


There are 'T' messages giving you the server time each second. I haven't tried to use them to synch yet, however I would assume they are sent at each full second.


As of right, now, I also see the gap in the historical tick data. Or maybe that's where I saw it in the first place.

The quotes got stuck at 2707.50, trades do continue (in the historical tick data).


Today as in 2019-02-11 CST, that is.


I believe I saw it at about the same time today, for ES.

IQFeed Developer Support » Fundamental Data Message Feb 8, 2019 08:18 PM (Total replies: 3)

Quote: Not currently.

In IQFeed 6.1 we plan to release a new feature that will enable you to download batches of fundamental data by exchange/security type.
--- Original message by DTN_Steve_S on Feb 8, 2019 08:51 AM
Sounds good. Do you have an estimated time frame for 6.1 ?


Not sure what exactly the output means, but IQConnect has a configurable timeout that determines how long it waits for a client application to connect. This timeout is quite short by default, so it is good to have the client app already trying to open a connection as you issue that command. After that, IQConnect closes automatically. As I said, I'm not sure if your output indicates this situation.


Thanks for the info!

So if I load or reload an option chain maybe 1 hour before OPRA market open, there will be no need to check for updates for the rest of the day.

Regarding the listed markets, I did a quick comparison of the current list, and the one you have on your website. It seems the listedMarketID is more stable than the shortname. For example,
ARCA changed to NYSE_ARCA, yet remained at ID 11. And NMS changed to NGM, yet remained at ID 1 (although ID 21 was added).

So does the ID remain the same as long as a listed market exists?

For security types, can we expect that types 1, 2, 6, 8 and 9 will always keep their meaning, even if others are added or removed?
Edited by quickTick on Nov 7, 2017 at 11:42 AM


Time: Sun February 25, 2024 6:20 PM CFBB v1.2.0 11 ms.
© AderSoftware 2002-2003