I have been porting my strategy from another platform (Tickblaze) to
Amibroker and am having issues getting the realtime scan execution dialed in data wise with Amibroker (v7.00.0). My data provider is IQ Feed.
This screen shot shows Tickblaze and Amibroker running on the same Azure VM running in realtime mode with IQ Feed 1 min data (symbol is DNTH on 2025/11/25). Note the red circles and Amibroker on the right where the candles do not match Tickblaze on the left.
Although IQFeed is excellent for its fast intraday backfills, it is totally worthless for RT trading with AmiBroker because of the long tails.
The long tails are the result of the unfiltered RT data feed used by AmiBroker.
Somehow, the IQFeed chart app is able to use a filtered RT data feed which AmiBroker is unable to access. I understand that the IQFeed API does not document how to access a filtered RT feed.
Bottom line: Use a different data provider for RT trading.
Tickblaze does not have the same problem processing the IQ Feed data as shown via the screen shot.
Is there a recommended data provider to use with Amibroker? I have used IB data before and it is not viable for real-time trading...too many missing bars.
I'm only aware of IB's RT data. It's a shame we can't get a filtered IQFeed data stream in AmiBroker. Tickblaze figured out how to do it, so we know it's possible.
IQFeed is a pain and I've been tolerating them for some time now. On top of the hairy data, TQQQ just split a few days ago but IQFEED does not split adjust their intraday data so I had to do it manually. The next day the data for some reason un-split adjusted, and the day after that it did the opposite. So there is huge gap up and then gap down for 2 days, which is easily fixed with a force backfill but in the meantime I missed a good trade in between.
Does anyone have recent experience with Esignal? I am strongly considering moving over to them.
i just tested in a 1min database. There the chart looks the same as your Tickblaze chart, see below. When you display a 1min chart in a tick database however, I get the same faulty chart. Might have to do with tickID's grouped together. Although with the futures I did not notice this problem.
Thanks for the reply! Is there a way to configure real-time data from IQ Feed with Amibroker so it is not "tick based" and more closely aligns to the one minute time-frame?
there is a setting in "database settings", "configure", "consolidate trades with the same TickID". But it changed nothing for me for this specific symbol. Best to have Tomasz have a look at it. So I get 2 different charts. If I open a 1min database with IQFeed I get the correct chart. If I open a tick database and then display the 1min timeframe I get an incorrect chart, same as you have shown. I do not know the reason, better let Tomasz have a look
Tick data request and minute request are SEPARATE types and different commands in IQFeedAPI and likely going from different internal DTN databases. AmiBroker displays what it receives from IQFeed. If there is a data error at the source it passes it through. The plug-in can’t fix the data received.
there is something strange going on. You can also use the IQFeed charts to check the data. Rightclick the IQFeed connection manager, then Display Apps, then Charts. You can then in "Request Details" request for tick data. Below you see the tick chart for AAPL. Inside Amibroker it looks completely different. In fact for all the stocks I checked the tick charts compared using the IQFeed App and Amibroker look different. But not for the futures. Like the symbol @NQ# shows the same tickchart inside Amibroker as well as in the IQFeed chart App. So it seems the tick data for stocks has some problem inside Amibroker
No it doesn't. Your ASSUMPTION is false. It uses 1-minute backfill request when database is 1-minute.
Come on guys such statements as yours are so ridiculous and absurd.
Do you really think that I have no brains?????? It is totally absurd to assume that ANYBODY would do such nonsense.
DO NOT ASS-U-ME because you would make an ASS from U and ME
You are NOT supposed to CHANGE "Base time interval" in database back and forth. "Base time interval" should be SET ONCE at database creation time AND NEVER CHANGED.
If you change "Base time interval" AFTERWARDS, existing data wilL STAY UNLESS YOU FORCE BACKFILL.
Plugin is DESIGNED TO CONSERVE DATA and BANDWIDTH and it requests only NEW DATA (since "last present exising bar" till "now").
There is no "automatic" "Force backfill" for all symbols BECAUSE DOING AUTOMATED repeated abusive requests IS FORBIDDEN BY IQFEED.
Abusing IQFeed service by doing such automated request would result not only in termination of YOUR account, but also termination of OUR ability to use their API.
If you want TICK DATABASE, CREATE A NEW TICK DATABASE, do not change previous "1-minute" database to something else.
Thanks for the response @Tomasz. Let me rephrase the issue without any implementation assumptions.
As a user of Amibroker and IQFeed, I need to be able to create a 1 minute database with IQFeed where I can backtest and realtime trade (running Scan on a schedule) from the same source of data (knowing there could be some bad ticks from realtime data).
Expected Results:
When creating a 1 minute IQFeed database, the realtime streaming data mostly matches (accounting for bad ticks) the data backfilled after hours or via the Force Backfill plugin menu option.
Actual Results:
When creating a 1 minute IQ Feed database, the realtime streaming data does not match (accounting for bad ticks) the data backfilled after hours or via the Force Backfill plugin menu option.
Steps To Reproduce:
Create and new database with IQFeed as the plugin and the Base time interval: 1 min.
Add some symbols to the Database.
In a new Analysis window, load any AFL formula and select Wait for backfill (slow, RT sources only).
Open a chart of one of the symbols (let run for about 30 mins). The chart should default to 1 min.
Click the IQFeed Force Backfill menu option in the bottom right corner.
You will see the Tick source data in the chart overwritten with the 1 min data from IQFeed.
Customer Impact:
It is not viable to backtest/realtime trade with IQFeed 1 min data in Amibroker due to the variance in data.
Thank you for your report. After reviewing the details provided, I would like to address the specific points raised in your post.
The comments that you made are NOT inline with what I am seeing. I am seeing that 1-minute data from real-time collection MOSTLY AGREE with data later backfilled. The only differences I see are occurring from time to time obvious BAD TICK causing "long wick".
1. Analysis of the Evidence Provided
In your report, there were no specific statistics provided regarding what data was different. The only evidence supplied was a screenshot showing "long wicks" on the price candles. While your expected results mention "accounting for bad ticks," the long wicks shown in your screenshot are, in fact, the bad ticks sent by IQFeed.
2. The Nature of the Discrepancy
The difference you are seeing between the real-time stream and the backfilled data is almost entirely due to bad tick data originating from the vendor. Despite the claim that bad ticks were accounted for, the visual variance you are experiencing is the direct result of erroneous price spikes transmitted during the live stream BY THE DATA VENDOR.
3. Why "Force Backfill" Changes the Data
You correctly noted that "Force Backfill" results in cleaner data. This occurs for two specific technical reasons:
Vendor Cleaning: IQFeed may perform data cleaning on their server side after the fact, meaning the historical data they send later is cleaner than the raw stream they sent live.
Plugin-level Filtering: Due to frequent existence of bad ticks in IQFeed data, the IQFeed plugin implements an internal ATR-based algorithm designed to filter out "obvious" bad ticks from backfill data . This algorithm relies on analyzing price data both before and after the current bar to determine if a tick is an error. This is kind of "patch band aid" because IQFeed is NOT sending clean data.
Crucial distinction: This filtering cannot be applied to real-time streaming. The algorithm requires "future" data (the ticks that happen immediately after the bad tick) to identify the anomaly. In real-time, that future data does not exist yet, so the bad tick cannot be filtered until a backfill is performed later.
4. Data Vendor Responsibility
Please understand that it is the responsibility of the data vendor (IQFeed) to deliver correct and clean data. It is not technically feasible for the software to magically "fix" incorrect data in real-time without the context of future price moves, nor should the software be expected to reconstruct a clean stream from a corrupted source.
5. Facing the facts
It is important to understand that BAD TICKS happen. There is a white paper published on BAD TICKS
that I advice you to read. Some bad ticks are unavoidable. This plus the fact that IQFeed is UNFILTERED FEED (it passes ALL BAD TICKS to the customer) causes long wicks occuring sometimes on some symbols.
Thanks for the additional information @Tomasz . I see your point regarding bad ticks.
Could you please confirm you are streaming IQFeed 1 min bars via the BW command on port 9400. Assuming you are, I will investigate other data options with Amibroker.
Connection Details
Port:9400 (This is the Streaming Intervals/Derivative Port).
Protocol: TCP/IP Socket.
Data Flow: The server will send historical bars up to the current moment, and then continue streaming the most recent bar as it forms, sending a final update when the bar closes.
Key Command: BW (Bar Watch)
The command to watch a streaming interval bar is BW (Bar Watch).
No, there was NO such command as "BW" in IQFeed API when IQFeed plugin was implemented (like 10+ years ago). ( Besides BW does not seem to stream time&sales and that is required by Level 1 display window and Tick&Sales window ).
The plugin uses HIX for historical intraday request (1minute and up), HTX for historical tick requests, HDX for historical daily requests, S,SELECT UPDATE FIELDS to define what fields should be streaming in RT, "W" to add symbol for real time stream (watch), "R" to remove, and other misc requests.
When new symbol is added TWO requests are sent: backfill (HTX,HIX or HDX) AND watch start (W) which starts streaming Level-1 data. Level 1 data are collected for all subscribed symbols and are used to build data. Any errors / bad ticks in Level 1 data inevitably land in "bars" constructed from them.
I did not use BW command because there was no such command at the time plugin was written. Maybe (that is very wild guess), IQFeed realizing how many bad ticks there are decided to filter some on their end and added this "BW" thing, so you are now getting "dissonant" data (unfiltered feed with "W" and filtered with "BW"). Again, that is a guess, otherwise it would be pointless to add another command if there was no difference.
I don't know yet. First I need to test what they did because the documentation is super-short and doesn't explain anything, about what is included in those bars and what not. Is after hours trading included, is dark pool activity included, odd-lot trades? I have seen feeds that say don't include odd-lots and that caused "questions" in the past, so I had to scratch my head and explain that I did not do anything wrong, it is just data vendor decision to NOT include something.
Even though I receive some emails from DTN from time but this "BW" command did not caught my attention and it was not advertised very much. Docs don't say much about it (few sentences), so as always all the work is left for the end developer who must "discover" what should be in fact documented.
Key Command: BW (Bar Watch)