Victor Boesen

Thank you Steve!! Still got some work to do with the noise spikes removal. No need to apologize for not testing it yet! I do my observing besides multiple apartments in the city so far from ideal. Parameters used are the following: "DSP Parameters": { "number_of_fft": 50000, "resolution": 11, "median": 10 } Victor

I managed to do some testing of my new rewritten software. After seeing @ZiHao using Astropy I decided to try and switch to astropy from pyephem, which made things easier when correcting for radial velocity. Here are three observations from today and a comparison to the same area from the H-line survey. And from H-line survey. Note that it's just mirrored since they plot it as a function of increasing radial velocity, whereas I plot mine as a function of increasing frequency. Next target: And final target which greatly shows the correlation between my spectrum and theirs. Look at the peak which is basically centered at 0 in both cases. Annoyingly, the noise spike is just inside the filter I apply when searching for the hydrogen line peak, so next thing on my todo-list will be removing these large spikes! This will, however, be a lot easier to work on now that I have some debug files I can test on I was also able to test out the new UI, which I really liked, and everything worked as it should. Therefor, I have merged the rewrite branch with the main branch on GitHub https://github.com/byggemandboesen/H-line-software Victor

Well, guess I need to do some more reading Definitely do so!! I've become quite a big fan of using GitHub for my coding projects. Great for when you need to look at some old code you suddenly find out you needed but deleted long ago!

Alright, thank you. I think I understand it now 😅 So, the barycentric_rv = rv + v_correction just corrects for the Earth's orbital velocity around the sun, whereas the LSR considers the Sun's motion relative to the observed area. In my case, developing my software, I am only interested in the barycentric radial velocity since the LSR velocity must depend on the distance to the area. For the majority of users (including myself) this is unknown for the most part. Thanks for sharing your resources on here! They are very helpful Do you have a GitHub account by any chance where I can have a look at some of your stuff?

@ZiHao Am I correct in assuming that the radial_velocity_correction function returns the Earth's velocity in the direction of the observed area? In the sketch above the radial_velocity_correction would then return "-velocity correction"?? Victor

That is not my impression. However, I did find that it can't be set to 0 for some weird reason. So this is how I initialize the SDR in my code: # Return a physical serial SDR client def rtlClient(self): client_sdr = RtlSdr() client_sdr.sample_rate = self.SAMPLE_RATE client_sdr.center_freq = self.CENTER_FREQ client_sdr.gain = 'auto' # For some reason the SDR doesn't want to set the offset PPM to 0 so we avoid that if self.PPM_OFFSET != 0: self.sdr.freq_correction = self.PPM_OFFSET return client_sdr

I'm not by my PC right now so can't try myself. However, have you tried Microsoft ICE?

I have two RTL SDR's and both of them are accurate within 2PPM (probably even lower). However, you can definitely try to calibrate in on a known signal anyways.

Very interesting stuff ZiHao!! Is that astropy? It looks excellent for this kind of stuff. I might have a look at astropy instead of PyEphem. It's my impression that it's better suited for astronomical data processing.

Not so sure... Looks like an APOD to me

1+ from me too! In fact, I think I will get one more to make a pair for future binoviewing;) Both for H-alpha and wide field DSO observing.

Highly agree with this! I am using a Quark, which extends the eye relief quite far out. I've used this eyepiece from TS quite a lot: https://www.teleskop-express.de/shop/product_info.php/info/p1428_TS-Optics-40-mm-1-25--Superview-Okular-mit--T2-Gewindeanschluss-fuer-Kameras.html It has an adjustable extension to the main lens (see the small locking screw in the third image). They also do a 32mm which I haven't tried. However, I'm sure this will probably be too low magnification with a SS60?

It looks cool though!! Definitely see a lot of potential in your idea. Could make a very interesting map!!

I'm not so sure actually. Shouldn't be too much different for the fourth quadrant (270-360deg longitude). However, the outer quadrants are a little tricky, hence the huge error bars you see on this image for areas further away than the sun.

Yes, it is. You can only use the radial method, I believe it's in one of the papers you shared, for galactic longitude between 0-90 degrees (in reality more like 20-75 because of the galactic bulge and etc). Radial method above. Victor

If you're only using the debug file and processing that yourself then you'd need to perform a slight modification to your own stuff. The data which the software plots is the "SNR Spectrum" as a function of the "Frequency list". The new version even includes the doppler and SNR in the debug file as well under "Observation results". Hope that answered you question! Please correct me if I misunderstood your question Victor

Very interesting plot! It looks correct to me. It's a little difficult to comment on the questions you have comparing the paper to your plot though😅 Even equatorial coordinates can be hard to interpret/understand sometimes, so galactic coordinates are even more difficult! I have some good news! I've just been testing the new rewrite of the software and compared it to the current software. I have managed to get a pretty consistent performance increase, which I can imagine will only be even better on slower machines (raspberry pi ant etc). I'm still testing the rewrite until I merge the rewrite branch with the main branch. If you want to, however, you can try the rewrite if you pull/clone from the rewrite branch. I would advise you to do so in a separate folder, so you don't overwrite your current files. To clone the rewrite branch: git clone https://github.com/byggemandboesen/H-line-software -b rewrite There will most likely be bugs, hence why it's not on main branch yet, but feel free to test it and take note of any bugs that may occur. Then I will fix them Victor

Thanks Steve, your testing is very valuable to me! I will most likely decrease the dpi at which the observation image is saved at. A 2-300mb gif isn't really what many would expect from a gif. Ideally it should be sharable on social media and etc, without taking up too much space/loading time.

Baader Classic Ortho. The BGO is the older Baader Genuine Ortho.

RA_sun is the right ascension of the sun in the sky. I'm sure you can get it with astropy, although I've not used it myself. I use PyEphem, for which it's very straight forward. Where Jupiter should of course be replaced with Sun.

RA1 = RA_Sun - 90 - RA_Obs And you only really need the absloute value of the above so: RA1 = abs(RA_Sun - 90 - RA_Obs) = | RA_Sun - 90 - RA_Obs |

Add to the radial velocity, subtract from the doppler shift And yes, that would give us the true doppler- or radial velocity with respect to our solar system/sun (not taking into account the rotation of Earth).

Finding the Earth's velocity in the direction of the observing area should be fairly straight forward. You can use this formula: Where, RA_1, is equal to the difference between the Earth's orbital direction (RA coordinate 90 degrees west of the Sun's RA coordinate) and the direction of the observing area. This can be done in code without much trouble, and could be added to the debug file! The declination is just the declination of the observing area. Earth_v is Earth's orbit velocity (29.8km/s). Victor

All feedback is welcome! With regards to the GIF maker, I never really considered it a problem before you shared your experience with. So that's definitely something I'll look into. I would ideally like to retain the high resolution of each plot, so either I need to add some downscaling in the code before creating the GIF, or just not create a GIF. I could also do a mix of both and let it be an option to create a GIF or not Debug data. I will also improve this as it currently isn't "truly" sufficient for any debugging. When observing, the software collects an observation centered at the H-line, and another one offset på 3MHz. Then it subtracts these two, to get SNR and to even out the spectrum. Currently, only the final "SNR_spectrum" is included in the debug. Ideally I'd like both the blank, the H-line, and the SNR_spectrum. This will all be included in the new rewrite, together with datetime, all parameters, coordinates and etc. You are correct. Back when I estimated the rotation curve of our Milky Way, I had to correct for the orbital velocity of the Earth (+- 30km/s). Above you can see the uncorrected, blue, velocities and the corrected ones, red. I did this "manually" from the date I performed the observations on. Essentially I calculated the Earth's velocity vector in the observing direction, and added it from the observed velocity. Notice, the observed radial velocity in the last image are the blue dots. Then I add the values from second last image to get the red dots. This is also something that can be added to the software, but it's not my priority currently. Victor

Sorry, been a bit busy last couple of days! The plot looks great (and correct!), but I do think it would help with a couple more scans as you say I will give you a little spoiler as for what I've been messing around with lately Doing this as a part of my long awaited rewrite, which I'm currently working on. I have decided to ditch the command line options simply because there were so many, that they were cumbersome to work with. Instead, all settings will be available through the config.json or by using the UI. This way one does not depend on the UI when using the software, which is and has always been an important part for me to maintain, as many people are likely using it headless on a Raspberry pi! Victor