I clicked through at least 20 different repositories expecting lots of MATLAB code, but to my surprise, I didn't find a single .m file. I hate how MATLAB is so popular in the DSP world and it makes me happy to see that the astronomy community has not been infiltrated by Mathworks (yet).
The article is light on details, but we can make some guesses based on the label "10s integrations, 1Hz channels" in the plot. I assume they have a bank of 1Hz filters, and they split the output of each filter into 10s intervals, and somehow combine ('integrate') each 10s chunk into a single number for each bin.
They need to compensate the Doppler shift so that the signal stays in one bin over the 10s integration time. I imagine they are using non-coherent integration (basically computing total signal energy over 10s in each bin) to take into account that the doppler compensation is not perfect (if it was, you could have 0.1Hz bins with 10s integration time).
If the above is true, then yeah, they can't demodulate any data because the integration time is much longer than symbol duration.
I wonder if with more accurate Doppler prediction, you could get an ever longer integration time and narrower bins, and thus even bigger SNR gain, perhaps allowing signal detection with a smaller dish...
The "live" plot (with the peak) uses indeed 1Hz bins (of 1 second), that we average over the last 2-3 minutes to reduce the noise. We could go even narrower, I might give that a try on the recorded data.
Thank you for the clarification. Recently I've been reading a lot about tracking of space objects (though much closer ones, on LEO/MEO), so this is some very interesting stuff for me!
GPS navigation messages do include information about leap seconds and other stuff necessary to convert between GPS time and UTC. See GPS Interface Specification IS-GPS-200, 30.3.3.6.2 - UTC and GPS Time
Can confirm, it's a great way to get started with radio stuff. Since I live in Europe, I did this with the German DCF77 signal. The frequency is low enough that you can do direct sampling with a 192ksps sound card or with an RP2040.
A nice thing about DCF77 is that once you manage to receive the amplitude modulated signal, you can move onto decoding the slightly more advanced spread-spectrum phase modulated signal, which carries (almost) the same data.
You can start by buying a time signal receiver module, and once you confirm that the module can receive the signal, cut off the ferrite antenna and use it with your own receiver.
If one wire in the pair is still connected, it's not really working because of capacitance (which is ~nil at 5mm), it's working because diff pairs are amazing. The remaining signal level on the single wire was probably enough to keep the receiver happy (at ~10kBaud in the Reddit post, versus the design ~100MBaud), and so, you win.
Any time you can spare the pins & wires to go differential, and have the slightest hunch you might need it, just do it. Diff pairs work!
Old analog tv over coax used to work with the cable poorly seated. You could even disconnect the cable entirely and just point the conductor at the plug and still get a(n admittedly quite noisy) picture as long as the cable end was near enough.
I had that happen as a kid and never figured out what caused it. My Atari was giving a very snowy image but I kept playing for a while. After dying I go to fiddle with the cable and it’s not even plugged in.
Honestly kind of messed with me at the time especially as I couldn’t replicate it.
Related, Deep Sky Videos did a series of large-telescope tours / interviews a few years back. For example, this is their one on Alma; there are a number of others in their channel: https://www.youtube.com/watch?v=eAQZp6yTR2Q
I wanted to build something like this but for Linux, especially the vimium-like hints that would work in any app. I even made a prototype by abusing the AT-SPI2 accessibility API. Unfortunately, querying AT-SPI2 for all buttons takes too long in complex apps. And even if it was fast, many apps (especially non-GTK ones) implement accessibility poorly or don't implement it at all, so I abandoned the project.
I guess it would be possible to make a framework specific implementation, for example by replacing the GTK shared library with a modified version, but that's too much effort and I lost interest in the whole 'mouseless' thing anyway.
I have built this here https://github.com/phil294/vimium-everywhere, and it works okay-ish performance-wise. For example, generating the click hints on this thread on Firefox takes (including FF's UI elements) takes one second, perhaps less on a fast machine. I use it on a daily basis. It needed a lot of optimizations to get to that point though. There are also a few alternatives listed.
And almost all applications support at-spi once you set some env vars! Including electron apps etc., see the readme
The thing about linux is that ime you can just implement this individually across all (most) the apps I use. I have vim-like binds for mpv, my pdf reader, terminal emulator/terminal file manager, image viewer, and of course my window manager.
The ones where I don't are the ones where it would be too complex to be taken care of by an external app. A DAW would need its own core implementation of modes for example, same with something like Krita and in that case it would probably not even be advisable.
