I am trying to get a live option symbol for RIVN slightly out of the money. The code below returns a strike (26.5) that is not valid for that expiration date.
The current underlying price is 21.63 during market hours. With _increment = 5, and calculated strike of 25, I expected the method to return RIVN231117C25. I thought the method would resort to a "safe" strike, a multiple of 5. Did I misunderstand or can you see something I''m doing wrong? Here's the relevant code and debug output:
DEBUG
The current underlying price is 21.63 during market hours. With _increment = 5, and calculated strike of 25, I expected the method to return RIVN231117C25. I thought the method would resort to a "safe" strike, a multiple of 5. Did I misunderstand or can you see something I''m doing wrong? Here's the relevant code and debug output:
CODE:
double underlyingClose = bars.Close[idx] _increment = 5; bool weeklies = false; bool expired = false; bool exact = false; string contractSymbol = ""; DateTime curDate = bars.DateTimes[idx]; double strike = Math.Ceiling(underlyingClose / _increment) * _increment; WriteToDebugLog("Strike is " + strike, false); string OptContractSymbol = IBHistorical.Instance.GetOptionsSymbol (bars, OptionType.Call, strike, curDate, _minDaysToExpire, weeklies, expired, exact); WriteToDebugLog("***** Live initial symbol is " + OptContractSymbol, false);
DEBUG
QUOTE:
***** 10/2/2023 3:30:00 PM Get a live symbol for RIVN
Strike is 25
***** Live initial symbol is RIVN231117C26.5
Rename
When I run your example on RIVN, 30-min chart, and using 20 for _minDaysToExpire, the result is this:
So, I can't duplicate your experience. The logic even checks that the contract has traded (unless you set strikeIsPrice to true), so it's pretty strange to get an invalid contract .. unless historical data requests were failing (check the Log Viewer).. then you might end up on a strike that's just part of the chain. That would explain it.
CODE:
---Sequential Debug Log--- Strike is 25 ***** Live initial symbol is RIVN231117C25
So, I can't duplicate your experience. The logic even checks that the contract has traded (unless you set strikeIsPrice to true), so it's pretty strange to get an invalid contract .. unless historical data requests were failing (check the Log Viewer).. then you might end up on a strike that's just part of the chain. That would explain it.
I ran again this morning (with market open), and it appears to be returning multiples or 5 (valid strikes) for RIVN. Here are the logs from yesterday. There are several yellow and red flags. Could this be the cause?
QUOTE:
Timestamp Source Message Exception
"10/3/2023 13:18:18:319" "InteractiveBrokers" "2108: Market data farm connection is inactive but should be available upon demand.usfarm.nj"
"10/3/2023 13:18:18:723" "InteractiveBrokers" "Market data farm connections OK: usfarm.nj, usfarm, ushmds, secdefil"
"10/3/2023 13:18:21:739" "Dummy Broker" "Dummy Broker Broker: Welcome innertrader, you are now connected to our Dummy Broker!"
"10/3/2023 13:18:23:744" "InteractiveBrokers" "0.7 seconds difference: Local - TWS time"
"10/3/2023 13:18:23:883" "TD Ameritrade" "TD Ameritrade Broker: Connected to TD Ameritrade."
"10/3/2023 13:18:32:164" "Yahoo! Finance" "Connected"
"10/3/2023 13:18:45:442" "InteractiveBrokers" "Market data farm connections OK: usopt"
"10/3/2023 13:21:41:794" "InteractiveBrokers" "2108: Market data farm connection is inactive but should be available upon demand.usopt"
"10/3/2023 15:40:47:377" "InteractiveBrokers" "Market data farm connections OK: usopt"
"10/3/2023 20:45:17:885" "InteractiveBrokers" "2157: Sec-def data farm connection is broken:secdefil"
"10/3/2023 20:45:20:088" "InteractiveBrokers" "Market data farm connections OK: secdefil"
"10/3/2023 21:04:48:863" "InteractiveBrokers" "2105: HMDS data farm connection is broken:ushmds"
"10/3/2023 21:05:32:163" "InteractiveBrokers" "Market data farm connections OK: ushmds"
"10/3/2023 21:23:50:719" "InteractiveBrokers" "2103: Market data farm connection is broken:usfarm"
"10/3/2023 21:23:53:748" "InteractiveBrokers" "Market data farm connections OK: usfarm"
"10/3/2023 21:28:45:279" "InteractiveBrokers" "1100: Connectivity between IBKR and Trader Workstation has been lost."
"10/3/2023 21:29:36:879" "InteractiveBrokers" "1102: Connectivity between IBKR and Trader Workstation has been restored - data maintained. All data farms are connected: usfarm; ushmds; secdefil."
I can't tell. But the result you got was because it wasn't getting data, OR, that contract had not yet traded (no history).
QUOTE:
OR, that contract had not yet traded (no history)
Not that one. It was the wrong increment (2.5 was correct), so the adjacent valid strikes were 22.5 or 27.5 for that exp date.
My strategy chooses a strike based on several variables, that include Greek values. I have been developing and testing a convoluted set of methods to try to determine the available strikes in the option chain I do this by establishing an "Anchor" strike (multiple of 5 pts above or below the market price of underlying), then finding the increment for the option chain. I am ferreting out the increment by constructing symbols with strikes at various increments from the Anchor and using the available Greeks methods and to test for != null return value to find a valid strike.
What do you think of the approach I am taking? It appears to be working, with the exception of the subject of this post. But I am wondering if there is a more direct way to "expose" the option chain.
I know that IB API doesn't return a complete option chain (or it is impractical to do so),
but do you know of other available tools better to approach this problem? For example, can IB reveal the increment for the chain? Does it have capabilities such as "find next valid strike (higher / lower)?"
The problem with IB's chain is that you get all the dates and all the strikes. IB does not provide a direct method to tell which strikes are valid for a given expiry date.
So, our logic starts by finding the closest strike in the chain (or next strike up/down for call/put as specified), verifying the contract and requesting its "HeadTimeStamp", indicating that it has traded. It tries a few, checking for history, and then gives up - it's not practical to continue checking every strike.
Maybe part of the problem here is that it gives you the last symbol that it tried. It might be better to default to the first one it tried - but not necessarily. 6 of one, half dozen of another.
So, our logic starts by finding the closest strike in the chain (or next strike up/down for call/put as specified), verifying the contract and requesting its "HeadTimeStamp", indicating that it has traded. It tries a few, checking for history, and then gives up - it's not practical to continue checking every strike.
Maybe part of the problem here is that it gives you the last symbol that it tried. It might be better to default to the first one it tried - but not necessarily. 6 of one, half dozen of another.
Your Response
Post
Edit Post
Login is required