- ago
I'm trying to implement a StreamingProvider with bybit, I made a subscription and when I receive data I send it to the handler from which I call UpdateTick. The time isn't being displayed accurately. I've meticulously checked everything using the debugger, and I'm absolutely certain that I've specified the correct date and time. However, in the graph, one minute seems to be missing, and the subsequent ones aren't being displayed accurately. The bars are mostly correct, with none missing, but the displayed time is incorrect. Do you have any suggestions?







And secondly, is there any way to obtain the current scale in the streaming provider? Or perhaps to trigger an update from the history provider? I'm not particularly fond of how the streaming provider write bars, and I would appreciate being able to redraw closed bars. Or draw only closed new bars.

P.S. All provider implementations would've been a cakewalk if there was just one open for everyone to peek at and use as a guide. :C
1
349
12 Replies

Reply

Bookmark

Sort
Cone8
 ( 21.52% )
- ago
#1
Scale is irrelevant to the Stream, and no, you can't control the display of the "ghost bar" as we've called it in the past. I'm not sure what your problem is with the closed bars (maybe you don't know about the options to customize it), but you're welcomed to create your own Chart Style if you want.

WealthLab's scaling functions require that your historical provider timestamp bars with the end-of-bar time. Most historical providers use start-of-bar timestamps, so you need to add the bar interval to those timestamps.
0
- ago
#2
Thanks for getting back to me! So, is there no way to avoid the ghost bar issue? My trouble with closed bars is that they look very similar to the provider's chart bars, but they're a bit different in values. I think it's because I'm using trading information (which only provides not 24h volume) instead of ticker data. The Binance API is very similar to Bybit (actually, they're the same), so if you could let me know which stream you connect to in your implementation, I think I could fix my problem. Other idea is: Bybit can give me the full closed kline, and I want to push that on the chart instead of the aggregated one.
0
- ago
#3
QUOTE:
WealthLab's scaling functions require that your historical provider timestamp bars with the end-of-bar time. Most historical providers use start-of-bar timestamps, so you need to add the bar interval to those timestamps.


Implemented it, and gape dissapear, now just every bar is 1 minute in future :D
0
Cone8
 ( 21.52% )
- ago
#4
QUOTE:
So, is there no way to avoid the ghost bar issue?
I know of no "issue". You only said you weren't "fond of how the streaming provider writes bars". The streaming provider doesn't write bars at all. It sources ticks (or mini bars) for the Quotes tool and for WealthLab to build bars for the selected chart interval.

QUOTE:
My trouble with closed bars is that they look very similar
Did you implement the correction for the end-of-bar interval timestamp? The only other reason it would be different is that you're getting conflated ticks, i.e., not all of them. This is typical of broker providers, and the result will not precisely match the historical bars, which are created with all the ticks.

QUOTE:
Bybit can give me the full closed kline, and I want to push that on the chart instead of the aggregated one.
You can use UpdateTicksHighLow() for that.
0
Glitch8
 ( 11.82% )
- ago
#5
WealthLab uses end-of-bar timestamps.

For example, the first one-minute bar of the US stock market is stamped 9:31 est.

Are you saying that a one-minute bar that ends at 9:31 in your adapter is now stamped 9:32?
0
- ago
#6
QUOTE:
You can use UpdateTicksHighLow() for that.

But I need know the interval first for this :C
QUOTE:
Are you saying that a one-minute bar that ends at 9:31 in your adapter is now stamped 9:32?

Yes. In first it was about only streaming bars from Update tick. Then I started adding intervals to the timestamps in barhistory. Now, every bar does that but without any gaps, from my screenshots.
0
Glitch8
 ( 11.82% )
- ago
#7
It sounds like a bug in your adapter. I can’t really offer any more help without having access to the code base. All of our adapters are working correctly so I don’t see any issue on the WL platform side.
0
- ago
#8
Okay thanks, i will check it again. What about interval, there are no chances to get current interval in SubscribeTo for example?
0
Glitch8
 ( 11.82% )
- ago
#9
The StreamingProvider class’ only job is to capture incoming ticks from a data source and feed them into the platform. The class has no knowledge or concept of who’s consuming the ticks. It might be a chart that has some particular scale or it might be some other thing like the quotes tool or order manager. I can’t see how the functionality of the StreamingProvider might change if it had that knowledge.
0
- ago
#10
QUOTE:
Bybit can give me the full closed kline, and I want to push that on the chart instead of the aggregated one.

QUOTE:
You can use UpdateTicksHighLow() for that.


To subscribe to Klines, i need to specify the interval. But I'm starting to guess that this is also the wrong way. :D

0
Glitch8
 ( 11.82% )
- ago
#11
I think I’m seeing the issue, the bars that WL is composing based on the streaming ticks aren’t matching up with what you’re getting from a historical request (klines?)

I think you’d like to be able to subscribe to a kline update and then use that as your streaming data instead of ticks. This would require some enhancements to the WL classes so I’ll tag this as a #FeatureRequest.
0
Cone8
 ( 21.52% )
- ago
#12
Let's update the Title since the original one - "UpdateTick in StreamingProvider: wrong timestamp?" - isn't going to capture any feature votes.
0

Reply

Bookmark

Sort