Hi Emil,
If the resulting histogram has only two bins, then this means that according to the default fitness model of the Bayesian Blocks method, two bins are the optimal data representation.
Just as a quick experiment, use bins=48 (i.e. regular half-hour bins) rather than bins='blocks': you'll see that there's a distinct break around 20000s (that is, about 6am) where the frequency goes from low to high - the frequency of buses is more-or-less constant on either side of this break. That's what the two bins of the 'blocks' method are telling you.
There's an added detail here: the bus schedule data is cyclical, which means the "events" fitness function is not quite correct. The code is designed to be flexible enough that if you come up with a more suitable fitness function, you can implement it and use that within the blocks function (see FitnessFunc and derived classes in the source:
https://github.com/astroML/astroML/blob/master/astroML/density_estimation/bayesian_blocks.py ) You might also check appendix C of Scargle 2012 (
https://github.com/astroML/astroML/blob/master/astroML/density_estimation/bayesian_blocks.py ) and see if any of those alternative fitness functions seem to make more sense for your data.
If you do end up implementing a different fitness function, please think about contributing it to astroML so others can use it! You can do that through a github pull request.
Another possibility is to tweak the prior of the events fitness function - it's set according to numerical simulations in the Scargle paper. I'm not sure if this quite makes sense for bus arrival times, but it would look something like this:
from astroML.plotting import hist
from astroML.density_estimation.bayesian_blocks import bayesian_blocks, Events
fitness = Events(p0=0.2) # prior calibrated to a false detection rate of 0.2
bins = bayesian_blocks(arrival_times, fitness=fitness)
hist(arrival_times, bins=bins, normed=True) # normed should be true for unequal bins
Hopefully that was helpful - good luck with your analysis
Jake