The goal of this thread is to calculate the probability of getting to a certain chain number in Brilliant Diamond and Shining Pearl without breaking it at a fixed amount of trials.

Poké Radar is a Key Item in Pokémon Brilliant Diamond and Shining Pearl that is used to locate special Pokémons and has a mechanism of chaining.
This mechanism of chaining is interesting as it can give more shinyness chances or guaranteed Max IVs depending on the length of the chain of encountered Pokémon.
Here is a chart of those two effects depending on the chain number found by dataminers.

However, the chain has a chance to break in the sense depending on how the battle of the Pokéradar is ended and the distance from the place where the radar was started and the grass tile that is moving (the calculation for the distance is the max between the distance in the horizontal axis and the distance in the vertical axis).
Therefore, we want to have the longest chain depending on our goal (40 for shinies and 100 for Max IVs). We want to calculate the odds of breaking the gain cumulated to reach a certain amount of chain. The model used is a Bernoulli trial model with a probability p=93% of success (implying we catch the Pokémon at the end of the battle, but the calculation can be redone easily). The probability to reach chain m with a probability p is: P(X=m) = p^m (which means you multiply the event of getting another radar roll, then another radar roll, and so on ... these events are independent so it is just the product of p, but m-times because of m events). This calculation can be found on several other websites. To give a numerical estimate, 0.93^40=0.055=5.5% which is quite low. Once the chain is maxed out, the shinyhunter can just restart the radar until a shiny patch appears which leads to getting a shiny Pokémon with an odd of 1 over 99.

Now, the problem can be expressed differently to the player's perspective that does not really care about the odds of breaking the chain but rather about the time invested. Instead of time, we will focus on the number of Poké radar encounters or more mathematically the number of Bernoulli trials and how do they relate to the global shinyhunting method. For shinyhunting, we would like to know what is the probability to get a chain of 40 or more given a certain amount of trials performed.
Fortunately, there are models to predict such quantities and can be derived from the generating functions of the Bernoulli trials.
Here is the frightening (not that scary to be frank) equation to implement in an algorithm, that is the analytical solution to our problem:


with:
- l_n, the variable length of the longest consecutive chain of Bernoulli trials at the n-th trial,
- m, the number of trials we are looking for (for example 40),
- p, the probability of the Bernoulli trials (the Pokéradar does or does not trigger after the battle) (p=93% if you catch the Pokémon),
- j, the summation variable.

After implementing the algorithm in Python, one can plot different charts for optimal methods for m = 40 (shinyhunting) p=93%, m = 100 p=93%. One can also plot the probability for different values of p, but the shinyhunter pick the best methods (note: the change from 93% to 83% is huge since it is exponentially lowered, 10% chance for 1000 Poké Radar rolls with m=40 p=83%).
The results are detailed in the charts below:

These charts should be read as follows: "Oh, I want to play a certain amount of time today, which would be equivalent to X amount of Poké Radar rolls", then look up X on the horizontal axis and at the odd that you will reach a chain length m (40 or 100) in that amount of rolls.

Then, you might notice that on the chart in which we would look for 100 Chain Number, the probability is quite low, we can expand the chart:



One can note that with 20000 trials, we barely get 60% chance of reaching 100 Chain Number (20 000 trials * 30 seconds = 7 days in a row non-stop).

A note about the implementation in Python of the code, when N/m is big, the numerical algorithm may oscillate to give a probability above 1. This is quite expected when summing small quantities that are products of other small quantities. The filter chosen was : if N>1000, raise an Error; if sum>1 and N>100 : set the sum to one; if sum>1 and N. The algorithm can be found here.