The following is not based upon any particular insider knowledge of automotive electronics but draws upon understanding of digital electronics and computing techniques used in real time control systems of many different types.

It is important to recognise that the ECU uses values of various physical parameters to monitor and control the engine. These physical measurements are represented internally as a binary number. All computers have a limited number of bits which are used to store and manipulate these numbers, known as the "word size". Word sizes vary but are most commonly multiples of 8 bits. So a computer with an 8 bit word (other values are possible, typically 16 or 32 or more) can represent values from 00000000 to 11111111. There are means to extend this range (by using two or more words to represent one value) but they involve complications which greatly increase the time it takes to manipulate such values and in real time computing these things are avoided if at all possible since the time to process them is critical (it's no good working out the correct time to fire the ignition if the computation took so long that the time is now in the past!) . So with an 8 bit word the smallest number is 00000000 or "0" in counting numbers and the largest number is 11111111 or "255" in counting numbers - that is to say there are only 256 possible different values. A common computational trick to allow representation of negative numbers would result in a range of between - 127 through 0 to + 127 (the perspicacious among you would notice that this range has only 255 different values - this is because the trick results in unique representations of both +0 and - 0).

Thinking about engine temperature for e.g we can expect a working range of (just picking reasonable values here for illustration) -40 deg C to +120 deg C. It is pointless to waste the numbers between -127 and -41 and the numbers between +121 and +127 since we would never expect to get these values nor would we want our engine management system to operate in these areas. We can get more precision by arbitrarily deciding that the internal representation of -40 is 00000000 and +120 as 11111111, so we are now representing temperature in steps of approximately 0.63 deg C for better accuracy.

The full possible range of ign timing is from -180 degrees to +180 degrees, but as in the temperature example, we really don't need many of these values as we will never encounter them in the real world so a similar trick is used to give better accuracy within the expected range of values by picking an arbitrary reference point and expression all timings of interest in relation to that arbitrary reference.

To further complicate matters there is no reason why manufacturers of ECUs would necessarily pick the same arbitrary reference so unless the diagnostic tool is specific to the type, it's interpretation of the ignition timing point is not necessarily in degrees BTDC.

To even further complicate matters there is no reason why the stored values have to be a linear representation - it is also entirely normal to use non-linear scales so that particular precision is achieved in a particularly sensitive part of the range by having less precision in less sensitive areas of the range (the sizes of the steps are not the same over all the range)

Back to your problem:

Firing after TDC is unlikely to allow the engine to run so this cannot be the correct interpretation of the OBD data.

Using a strobe to measure actual timing is also a bit tricky since you probably don't have a good TDC reference point but in qualitative terms the strobe and the OBD do agree that the timing is bouncing around.

Is the idle stable or is it lumpy or does the engine "hunt". Does the OBD/strobe show reasonably consistent timing at idle?