I've got 2 different implementations in 2 applications performing Bar Watches (BW) without any problem. But I'm having trouble with a new, 3rd implementation, and I'm looking for clues.

1. I'm connecting to the Derivative port 9400.
2. IQFeed returns "S,SERVER CONNECTED" in the socket's callback
3. Example: "BW,IBM,60,,,,,,req1,,,0
... and then nothing else is returned in the callback. No errors, nothing.

I've played around with the optional fields in the BW message, but nothing changes. Any ideas?

Your command is correct and should return data. Port 9400 doesn't need the S,SET PROTOCOL command. Are you sending /n/r at the end of your command?

---

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist

Oh my gosh, thank you. You hit the nail on the head!

In these initial tests, I'm watching just 2 symbols, AAPL and TTD, at 1 minute intervals. Very commonly, I'll see AAPL update 1 or 2 seconds after the end of interval (good), but TTD's update for the same bar interval will come maybe to 60 seconds later (not good). I'm just looking at the Debug prints from the callback, so I'm not sure how my program could create that delayed effect. Does that sound like something to expect?

I actually think I see what's happening. TTD doesn't print it's complete interval until a full lot trade occurs in the next interval. There's got to be a way around that, right?

Set a non-default UpdateInterval parameter in your BW command to get interim bars.
See http://forums.iqfeed.net/index.cfm?page=topic&topicID=4341 and http://www.iqfeed.net/dev/api/docs/Derivatives_StreamingIntervalBars_TCPIP.cfm

---

Yair Altman
IQML - IQFeed-MATLAB connector
https://UndocumentedMatlab.com/IQML

I am not a DTN employee; my post reflects my personal opinion

Thanks for the link. Now I understand BU much better, because that was unclear too. (If I had requested 15 second updates, I was expecting updates at :00, :15, :30 and :45 seconds every minute, which is not how that works either.)

Quoting Tim Walter from your first link, "The answer, due to the impossibility of syncing all clocks involved and the random latencies between connections, was to say that a bar complete message is only sent when a new message, with a time that is outside of the current bar, is received. So that is why BC messages are not timely."

It's understandable that DTN wants the data to match perfectly, but it sure doesn't seem like a good design decision based on the tradeoffs that require the consumer to use a work-around that is even less perfect and that still doesn't provide a timely bar without building one ourselves using updates. IQFeed already provides a TimeMessage that we use as a heartbeat to "close" intervals precisely on time so that strategies can be executed. We've used this design for 20 years in streaming charts and sure seems like an easy solution to implement for a "BC" message too. If the 99% of the user base expects this, what's the problem?

Our solution may be to toss the whole concept and simply subscribe to hundreds of streams instead. That's worse for the user's cpu and has gotta be worse for the DTN backend.

Here's what the UpdateInterval parameter does in the BW command: it gives you something to check for to ensure that your most recent message is current. If it's turned on, you'll get an incomplete BU message whenever a new tick has a trade in it. If you're watching a symbol, and no such new message has come in, you'll know that the most resent BC message is the most recent one. Or you can use the contents to update.

But yes, the interval bars work as described in the Tim Walter message, even I think he was talking about historical bars in general and not the BW feature. A new bar is not sent until completed, unless you turn on UpdateInterval and look for new data before the bar has been finalized.

---

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist

If it's turned on, you'll get an incomplete BU message whenever a new tick has a trade in it.

.. but you'll get that message only after the Update Interval. Sure, we can put that at 1 second and have at most a 1 second delay, which is acceptable, but it certainly complicates the adapter. Instead of just passing along the final result when it arrives, we'll have store the last BU message, and, if the BC message doesn't come in before 1 second after the interval, we use the last BU data, and, later have to ignore the next BC message. Not joy, but it is what it is.