Skip to main content

Multi-Timeframe Data Access in Custom Indicators

Indicators

Hello ATAS Support / Developer Team,

I am developing custom C# indicators for ATAS X and need a clear technical answer regarding Multi-Timeframe data access inside a custom indicator.

Goal

I want to build one custom indicator / module system that can access finished candle data from multiple timeframes at the same time, independent of the chart timeframe.

Example:

  • Chart is set to 5 minutes

  • The custom indicator needs finished candles for:

    • 15 seconds

    • 30 seconds

    • 1 minute

    • 2 minutes

    • 5 minutes

    • 10 minutes

    • 15 minutes

    • 30 minutes

    • 1 hour

    • 4 hours

    • 1 day

The required candle fields are:

  • Open

  • High

  • Low

  • Close

  • Volume

  • Delta

  • Ticks

  • Time

  • LastTime

The important requirement is: I do not want to manually aggregate ticks or lower-timeframe candles if ATAS already provides a native API for this.

Question 1: Is there an official Multi-Timeframe API for custom indicators?

Is there a supported public API equivalent to NinjaTrader's AddDataSeries()?

For example, something like:

AddDataSeries(...) GetCandle(timeframe, bar) GetCandles(timeframe) GetHistoryData(...) RequestCandlesAsync(...)

If yes, please provide the exact class names, method names, namespaces, and a minimal working example.

Question 2: Can a custom indicator request candles from a different timeframe than the chart timeframe?

Example:

The chart is set to 5 minutes.

Can the indicator request 15-second or 1-minute candles directly from ATAS?

If yes:

  • Which API must be used?

  • Does it work for smaller timeframes than the current chart?

  • Does it work for larger timeframes than the current chart?

  • Are the returned candles updated live?

  • Are historical candles also available?

Question 3: Are these internal APIs supported for custom indicators?

During inspection of the installed ATAS assemblies, I found internal/platform types such as:

OFT.Platform.CandleCreators.SecondsCandleCreator OFT.Platform.CandleCreators.TimeFrameCandleCreator ATAS.Indicators.CandlePartSeries ATAS.Indicators.ICandleCreator OFT.Core.Candles.ICandleProvider OFT.Core.Candles.OuterCandlesRequest OFT.Core.DataProvider.Requests.CandleTypes

I tested the following approach:

SecondsCandleCreator(...) TimeFrameCandleCreator(...) new CandlePartSeries(candleCreator, DataSeriesType.Bars) DataProvider.CandlesDataSeries.Add(series)

The creator and series can be created, and adding the series does not crash, but the series remains empty (Count = 0).

Is this approach supported for custom indicators, or is CandlePartSeries not intended to load additional independent timeframes?

Question 4: TryGetCandleProvider

I also found this method:

TryGetCandleProvider( OFT.Platform.Models.Instrument instrument, OFT.Controls.Chart.TimeFrameSelector.TimeFrameParameters parameters, ref OFT.Core.Candles.ICandleProvider candleProvider )

In my tests, the method could be found and called, but it always returned false and the provider stayed null.

Is TryGetCandleProvider intended to be used by custom indicators?

If yes:

  • Which object should it be called on?

  • Which Instrument instance should be used?

  • How should TimeFrameParameters be created or obtained?

  • Is there a minimal working example?

Question 5: HistoryDataRequest / GetHistoryDataRequests

Some online/generated examples mention APIs such as:

GetHistoryDataRequests() HistoryDataRequest GetHistoryData(requestId) HistoryDataContainer GetIndexByTime(...) SecurityIdentifier RequestInfo.SecurityId PeriodTypes

However, these names do not appear in my local ATAS X API metadata dump.

Are these APIs part of ATAS X custom indicators, or are they outdated / not available?

Question 6: Official recommended architecture

If a single custom indicator cannot directly request multiple timeframes, what is the officially recommended ATAS architecture?

For example:

  1. Run several charts/tabs with different timeframes and one sender indicator per chart?

  2. Use the built-in External Chart indicator?

  3. Use a strategy instead of an indicator?

  4. Use an official market data service from DataProvider?

  5. Use only GetCandle(bar) and manually aggregate?

Please clarify the supported and recommended way.

Summary

I need a definitive answer:

Can an ATAS X custom indicator access multiple finished candle timeframes directly and natively, independent of the chart timeframe?

If yes, please provide the exact API and a minimal working C# example.

If no, please confirm that the supported custom-indicator API only exposes candles from the current chart timeframe via GetCandle(bar).

Thank you.

Posted by Stephan ·
3 comments

Log in to comment and vote

Comments3

  • Linked to Ability to reference indicators in other chart panels

  • Yasar

    •

    Sep 23

    •

    Merged request

    •

    1 vote

    Cross-Timeframe / Cross-Chart-Type Data Access in Custom Indicators

    Hi,


    I'd like to request a native API for accessing candle data from a secondary timeframe or chart type within a custom indicator - similar to NinjaTrader's AddDataSeries() or TradingView's request.security().


    Use case: An indicator running on a non-time-based chart (e.g. RangeUS, Renko, Range) needs to read the full candle structure - e.g. Open, High, Low, Close, Wicks, Volume, Delta - of a configurable time-based chart (e.g. M1, M5, M15, H1, ...) for the same instrument, both historically and in real time.


    Historical access is essential: meaningful analysis such as deriving support/resistance zones, identifying swing highs/lows, or evaluating wick structures requires iterating over a series of past candles from the reference chart - not just the current one. Real-time access alone would make this use case impossible.


    Manual aggregation from non-time-based bars is not a viable workaround: a single range bar can span multiple time-based periods, or end partway through one - making it structurally impossible to derive correct Open and Close prices, let alone accurate wick data, from the host chart alone.


    The current SDK (docs.atas.net) has no mechanism for this - GetCandle() only accesses the host chart, and there is no AddDataSeries() or equivalent.


    A minimal API could look like:

    // Subscribe to any secondary series in OnInitialize:
var refSeries = SubscribeToSeries(ChartType.TimeFrame, timeFrame: 5);

// Access current and historical candles:
var currentCandle = refSeries.GetCandle(refSeries.CurrentBar - 1);
var previousCandle = refSeries.GetCandle(refSeries.CurrentBar - 2);
// → .Open, .High, .Low, .Close, .Volume, .Delta, ...

// Or iterate over history to find key levels:
for (int i = 0; i < refSeries.CurrentBar; i++)
{
    var candle = refSeries.GetCandle(i);
    // analyse swing highs, lows, wicks, zones...
}


    The secondary timeframe should ideally be a configurable parameter so that users can choose their reference chart freely (M1, M5, M15, H1, etc.).


    This would unlock a whole class of professional cross-timeframe and cross-chart-type indicators. Thank you!

  • Robert

    •

    Sep 23

    •

    Merged request

    •

    1 vote

    Inter-Indicator DataSeries API (public access without reflection)

    Custom indicators have no official way to read another indicator's DataSeries at runtime. The only workaround is reflection — iterating WPF visual trees and accessing private fields by name, which breaks on every ATAS update and is unsupported.

    Request: expose a public IDataSeries GetDataSeries(string indicatorName, int seriesIndex) API (or similar) on ChartInfo so one indicator can read another's output by name. This is standard in NinjaTrader (Bars.Get(), SMA(Close, 14)[0]) and would eliminate an entire class of fragile workarounds for anyone building composite indicators or automated strategies.

    • Robert

      •

      Apr 14

      Actually, The Add() composite pattern works for indicators you instantiate yourself, but there is no public API to access DataSeries from indicators already placed on the chart by the user. A GetIndicatorByAlias() or similar method would eliminate the need for reflection-based workarounds. Probably the better method.