It is nice that it seems doable for ~$200 USD, but the results aren't super encouraging, anyone know of a setup to get better results in a backyard setting?
> Another shot at curve fitting in Excel brought these results closer to expectations, but they were still somewhat off.
Is the raw data available? It would be nice to see the fits and understand why they changed so much. [My unsupported guess is that you must not fit the bigger bump, but a smaller bump on the side.]
The graph has no error bars for the data of the author. I guess the vertical error bar are big...
> Experiments aiming my horn antenna at an Inmarsat geostationary satellite revealed that the angular resolution of my little radio telescope is about 20 degrees.
... and the horizontal error bars are huge.
> Fortunately, you only have to care about the cloud that’s receding the fastest—the one with the largest redshift, in astronomer-speak.
Is it possible to point the device to the other side and analyze the ones with the largest blueshift? This doubles the data points without additional hardware.
The last few are suspiciously accurate. I guess the author is adding the velocity of the Sun/Earth to the data. It would be nice to have that horizontal line in the graph too.
The author’s raw data doesn’t appear to be published, but you can reproduce this exact measurement from public survey data: the LAB HI survey (Kalberla et al. 2005) gives calibrated 21 cm spectra for every galactic longitude, and extracting terminal velocities via the tangent-point method gives you the flat rotation curve with real error bars. I maintain an open, tested Python pipeline that does this end-to-end (github.com/joebarbere/jansky-research see the the hi module; MIT, pure NumPy/astropy) alongside a teaching course that derives the method (github.com/joebarbere/jansky). And yes, according to Claude, you can double the data points from the fourth quadrant using the largest blueshift; the method is symmetric, it’s standard practice in the professional surveys.
I expect the raw date to be something like figure 2. In the bottom subfigure, they mark the rightest gaussian with a center in 13, but I see another in 16 that is not drawn, I'm not sure why. And there are very small bumps in 25 and 32 that are probably noise.
The problem is selecting which one is the rightest. It the author of the press article used excel, it's possible that he fit something similar to one of the noise bumps. I used solver in excel a lot, and it's very sensitive to the initial parameter and it's very hard to be sure what is noise and what is signal.
My guess is that the is overestimating the difference of speed and that make the points in the graphic too low. If he repeat the measurement in the other direction, I expect the difference of speed to go in the other direction and make the points in the graphic too high instead.
I think it's a nice experiment, but it's the setup is too noisy to see the effect of the dark mater in the rotation of the milky way.
---
PS: Looking at your github profile, you have a somewhat similar setup. Do you have a blog post with more technical details and photos of the hardware. It may be a nice post for HN.
Sadly Claude overwrote a lot of the papers with synthetic numbers due to a bug, it will probably take a few days to rerun with the actual data. The HI paper should be corrected already though.
Regarding picking the right bump, the pipeline avoids Gaussian fitting and just takes the highest velocity where the signal is still clearly above the noise floor (fixed 2 K cutoff). Less clever than fitting, but avoids the solver wandering off and the noise bumps disappear. Claude picked that heuristic when building the module, and mentioned that it reads a few km/s high compared to proper spectral fitting (McClure-Griffiths & Dickey 2016, apparently) but it’s always high in the same direction.
I’m hoping to do a write up as soon as my Discovery Dish arrives and it sees first HI light.
It is nice that it seems doable for ~$200 USD, but the results aren't super encouraging, anyone know of a setup to get better results in a backyard setting?
> Another shot at curve fitting in Excel brought these results closer to expectations, but they were still somewhat off.
Is the raw data available? It would be nice to see the fits and understand why they changed so much. [My unsupported guess is that you must not fit the bigger bump, but a smaller bump on the side.]
The graph has no error bars for the data of the author. I guess the vertical error bar are big...
> Experiments aiming my horn antenna at an Inmarsat geostationary satellite revealed that the angular resolution of my little radio telescope is about 20 degrees.
... and the horizontal error bars are huge.
> Fortunately, you only have to care about the cloud that’s receding the fastest—the one with the largest redshift, in astronomer-speak.
Is it possible to point the device to the other side and analyze the ones with the largest blueshift? This doubles the data points without additional hardware.
The last few are suspiciously accurate. I guess the author is adding the velocity of the Sun/Earth to the data. It would be nice to have that horizontal line in the graph too.
The author’s raw data doesn’t appear to be published, but you can reproduce this exact measurement from public survey data: the LAB HI survey (Kalberla et al. 2005) gives calibrated 21 cm spectra for every galactic longitude, and extracting terminal velocities via the tangent-point method gives you the flat rotation curve with real error bars. I maintain an open, tested Python pipeline that does this end-to-end (github.com/joebarbere/jansky-research see the the hi module; MIT, pure NumPy/astropy) alongside a teaching course that derives the method (github.com/joebarbere/jansky). And yes, according to Claude, you can double the data points from the fourth quadrant using the largest blueshift; the method is symmetric, it’s standard practice in the professional surveys.
Clicky https://github.com/joebarbere/jansky-research
Very interesting. Do you have the generated images?
I took a look at the paper they cite in the article https://www.ioa.s.u-tokyo.ac.jp/~sofue/papers/sofcomp/2025-p...
I expect the raw date to be something like figure 2. In the bottom subfigure, they mark the rightest gaussian with a center in 13, but I see another in 16 that is not drawn, I'm not sure why. And there are very small bumps in 25 and 32 that are probably noise.
The problem is selecting which one is the rightest. It the author of the press article used excel, it's possible that he fit something similar to one of the noise bumps. I used solver in excel a lot, and it's very sensitive to the initial parameter and it's very hard to be sure what is noise and what is signal.
My guess is that the is overestimating the difference of speed and that make the points in the graphic too low. If he repeat the measurement in the other direction, I expect the difference of speed to go in the other direction and make the points in the graphic too high instead.
I think it's a nice experiment, but it's the setup is too noisy to see the effect of the dark mater in the rotation of the milky way.
---
PS: Looking at your github profile, you have a somewhat similar setup. Do you have a blog post with more technical details and photos of the hardware. It may be a nice post for HN.
The figures are in the zip attached to the latest release (see hi/main.pdf for the rotation curve): [https://github.com/joebarbere/jansky-research/releases/tag/v...](https://github.com/joebarbere/jansky-research/releases/tag/v...) or you can regenerate them yourself, python -m jansky_research.hi re-downloads the survey data and rebuilds the plot.
Sadly Claude overwrote a lot of the papers with synthetic numbers due to a bug, it will probably take a few days to rerun with the actual data. The HI paper should be corrected already though.
Regarding picking the right bump, the pipeline avoids Gaussian fitting and just takes the highest velocity where the signal is still clearly above the noise floor (fixed 2 K cutoff). Less clever than fitting, but avoids the solver wandering off and the noise bumps disappear. Claude picked that heuristic when building the module, and mentioned that it reads a few km/s high compared to proper spectral fitting (McClure-Griffiths & Dickey 2016, apparently) but it’s always high in the same direction.
I’m hoping to do a write up as soon as my Discovery Dish arrives and it sees first HI light.