getChart delay


I am trying to subscribe to 300 Ticks chart. All I require at the end of the day is latest 3 candles (300 Ticks) at the moment. I also want to know when a new candle is formed (As soon as it is formed. Quicker is better).

What I tried:

  1. Subscribed to Real Time using md/getChart and kept receiving data using ws.recv at regular intervals of 1 second. Here, ws is created using “create_connection” from “websocket” library of python. This gives delay in receiving the ticks. In real, 300 ticks pass quickly and ws.recv takes one tick at a time. The delay adds up slowly so that I get delays of over a minute within first few minutes of my script.

  2. I then tried to subscribe and get historical candles (3 candles) and send “cancelChart” at the same time and a new request to getChart with similar details. What I am trying to achieve is, get latest 3 candles from historic data and then cancel that subscription right away when I get “eoh”:True. Then subscribe again to get latest 3 candles from historic candles and so on. The issue here is that when I cancel and send new subscription request, it takes more than 10-20 seconds to take effect. Cancellation of old realTime data takes time and I keep receiving ticks through ws.recv(). This also makes the script useless.

Can you share a better alternative for this implementation? All I need is latest 3 candles (300 Ticks) and need to find distinctly when an ongoing candle has been formed completely and new one is started to Form (Need to know that as soon as the event occurred. An event based solution can work).

Looking forward to your responses.



3 candles of 300 ticks or 3 candles of 100 ticks? When you start asking for groups of ticks they register as bars, so they get grouped and have open, close, high, and low values. You may be looking for 3 100t candles.

When you get eoh this means historical data is loaded, you want the latest data though. What is happening is that you’re unsubscribing before you start getting the real-time data if you unsubscribe as soon as you get an eoh.

While you’re receiving live candle data, the timestamp for the bar will not change until there is a new bar. So to know when a new candle has formed, you can watch for the timestamp on the bar to change. Remember that every time you get a packet from the market data WS using charts, you’re getting an update of the latest bar (or a new bar). This should be treated as a replacement of what was formerly seen as the last snapshot of the latest bar, not as an addition to the latest bar.

Hope that helps a bit

1 Like

Your information certainly helped. Eventually solved the accumulating delay by changing the architecture of websocket. I am now using the webSocketApp from websocket library of python and using it’s on_message event to capture the data. This causes no delay and charts stay updated even after a full day of trading.

Following is just a small excerpt of this new architecture.

import websocket,
                              on_message = self.on_message,
                              on_error = self.on_error)

Thanks and Regards,