GSB Forums - Powered by XMB 1.9.11

What do to when GSB <> TS or MC

admin - 13-5-2018 at 08:00 PM

This is the list of most common reasons.
Session time not the same.
for ES/NQ/EMD/ER we don't use the last 15 minutes.
So you must have a custom session template.
Check for human error of wrong session times, bar interval etc.
Check the data matches. Did you use local time or exchange time?
In TS/MC/GSB you cant mix instruments with different exchange time zones, and so have to use local time.
Local time for GSB users varies depending on your computer time zone.
The best policy is to add all data streams to one chart, then export to GSB. If done on separate charts, there is much more room for human error.

If you cut and paste GSB TS code into an existing strategy thats on a chart, the settings of the old TS code will be applied to the new TS code. This is a very common error. Simplest fix is to change the inputs: word to vars:
GSB can do this automatically if inputs enabled set to false. See picture below.
Not covered in this post, is debug mode can be enabled. Then the ts code will output a txt file in the same folder as GSB. Then git can compare every oscillator etc. However in 99% of cases this is not needed.

admin - 14-5-2018 at 01:21 AM

Another thing to look for if you have market on close set to true,
Check your TS/MC code is exiting at close. If not there is something wrong with the match of GSB data time zone and TS data time zone.
You can partly cover this up my adding

setexitonclose; any where in the TS/MC code.
This is automatically done if built in market on close is set to true. (see picture above)
But this issue shows there is still a underling issue.
For example you may have GSB data that has been exported from TS using local time zone, (say gmt -6) but your pc with TS is on local time gmt -5 or exchange time.
Check also the exit time under tools, contracts list.

admin - 29-7-2018 at 06:28 PM

An New issue came up, if oyur on some time zones, ie Australia. CloseD(1) doesnt work as it should. This is fixed in
GSB builds late July 2018 with change in code.
see below.
//20180716 Closed(1) replaced by closesession(1,1) to fix bug where it doesnt work on some time zones in TS

if closesession(1,1) >0 then gsb_CloseLessPrevCloseD = Close - closesession(1,1) else gsb_CloseLessPrevCloseD = 0; //Tradestation
//if Closed(1) >0 then gsb_CloseLessPrevCloseD = Close - Closed(1) else gsb_CloseLessPrevCloseD = 0; //mulitcharts

admin - 9-8-2018 at 10:48 PM

The above fix will not be default for now as closed(1) is not always the same as closesession(1,1)
There also is a rare issue where TS <>GSB when nth is used. It doesnt occur often. Hoping it will be fixed in build 48.11

petrfin - 27-3-2019 at 03:34 PM

Hello,

I am trying to solve following inconsistency GSB > TS

I built strategy using data1=NQ30 and data2=NQ60

NQ data are saved from TS in local timezone, session time 830-1500.

When I apply the code from GSB into TS I see similar trades, but sometimes the entry time in TS is shifted by one bar. I marked some differences in attachment.

The exit is correct using the same bar and price. So the data should be identical and set in correct format.

Anybody has similar experience and have any advice how to synchronize the trades?

Thank you,
Petr

admin - 27-3-2019 at 03:47 PM

Quote: Originally posted by petrfin

Hello,

I am trying to solve following inconsistency GSB > TS

I built strategy using data1=NQ30 and data2=NQ60

NQ data are saved from TS in local timezone, session time 830-1500.

When I apply the code from GSB into TS I see similar trades, but sometimes the entry time in TS is shifted by one bar. I marked some differences in attachment.

The exit is correct using the same bar and price. So the data should be identical and set in correct format.

Anybody has similar experience and have any advice how to synchronize the trades?

Thank you,
Petr

are you certain the data from the chart = whats in gsb.
Rollover, data changes etc mean ts data is 99% the same (ignore rollover offset)
Are the total performance metrics 99%+ the same?
There are ways to diagnose this exactly in GSB, but a bit time consuming.
All indicators and data are written to a file on ts and gsb. Then git is used to compare

petrfin - 27-3-2019 at 06:02 PM

I am pretty sure I have data from chart in gsb, but the total performance metrics are quite different. So there must be some mistake somewhere.

How can I compare the data?

I can see that the price data are included when I do "export to portfolio analytics" in gsb and save entire report to xml in TS.

But they are in different formats, co how can you use git to compare?

How do you decode year in .pa format?

I can see rows like:
43467,1500,Sell ,SsnDyCls,1,6464
43470,900,2580,0,0,0,317,0,h:6489.5,l:6449.75
43478,930,Buy ,Long entry,1,6669
43478,1000,2580,140,1,1,317,6669,h:6680.5,l:6658.75
43478,1030,2580,70,1,1,317,6669,h:6681.75,l:6665
43478,1100,2580,655,1,1,317,6669,h:6704.5,l:6669.25
43478,1130,2580,745,1,1,317,6669,h:6716.5,l:6701.25
43478,1200,2580,655,1,1,317,6669,h:6708.75,l:6697.5
43478,1230,2580,735,1,1,317,6669,h:6708.25,l:6699.25
43478,1300,2580,730,1,1,317,6669,h:6712.25,l:6702
43478,1330,2580,35,1,1,317,6669,h:6713.5,l:6668.5
43478,1400,2580,355,1,1,317,6669,h:6688.25,l:6656.5
43478,1430,2580,555,1,1,317,6669,h:6702.25,l:6683.5
43478,1500,Sell ,SsnDyCls,1,6709

Is is correct that the row with "900" hour has year "43470" and the following rows have year "43478"? This was copy from .pa file.
Thank you.

admin - 27-3-2019 at 06:22 PM

Quote: Originally posted by petrfin

I am pretty sure I have data from chart in gsb, but the total performance metrics are quite different. So there must be some mistake somewhere.

How can I compare the data?

I can see that the price data are included when I do "export to portfolio analytics" in gsb and save entire report to xml in TS.

But they are in different formats, co how can you use git to compare?

How do you decode year in .pa format?

I can see rows like:
43467,1500,Sell ,SsnDyCls,1,6464
43470,900,2580,0,0,0,317,0,h:6489.5,l:6449.75
43478,930,Buy ,Long entry,1,6669
43478,1000,2580,140,1,1,317,6669,h:6680.5,l:6658.75
43478,1030,2580,70,1,1,317,6669,h:6681.75,l:6665
43478,1100,2580,655,1,1,317,6669,h:6704.5,l:6669.25
43478,1130,2580,745,1,1,317,6669,h:6716.5,l:6701.25
43478,1200,2580,655,1,1,317,6669,h:6708.75,l:6697.5
43478,1230,2580,735,1,1,317,6669,h:6708.25,l:6699.25
43478,1300,2580,730,1,1,317,6669,h:6712.25,l:6702
43478,1330,2580,35,1,1,317,6669,h:6713.5,l:6668.5
43478,1400,2580,355,1,1,317,6669,h:6688.25,l:6656.5
43478,1430,2580,555,1,1,317,6669,h:6702.25,l:6683.5
43478,1500,Sell ,SsnDyCls,1,6709

Is is correct that the row with "900" hour has year "43470" and the following rows have year "43478"? This was copy from .pa file.
Thank you.

pa and gsb used to use julian date. (a function in ts)
now pa supports both, but gsb still does julian.
I will get gsb to be changed.
Best send me teamviewer details. Your going to sleep soon and I am out for most of the day. send me TV details in 22 hours or so.
There are diag features in gsb on the left side. The gsb manual has this explained in brief detail.

petrfin - 30-3-2019 at 04:24 AM

Just to summarize the solution - at the end I had some strange difference in data.
I regenerate the data and GSB works fine now.

If someone has similar problems a good way might be look on the data through diag features as Peter recommended.