... that is a given. The comet is a nice addition though.
... that is a given. The comet is a nice addition though.
The largest estimate for the size of Psyche is 253 km across. Mars is about 6800 km in diameter, enormously larger.
Yes, I just picked up a SDRPlay 2 last weekend.
The main differences between it and the Funcube dongle are the same: the SDRPlay can sample at much higher rates, but only at 12 bits/sample, while the Funcube dongle samples at 192 kHz with 16 bits. The Funcube dongle therefore appears better suited to narrower modes, especially on HF and VHF where there may be strong interferers on nearby frequencies. The SDRPlay can do broadband modes too wide for the Funcube, such as HD Radio, ADS-B and digital TV, though many of those can also be done even more cheaply with 8-bit RTL-SDR dongles. The SDRPlay can also produce wideband waterfall displays.
Many hams today ARE using the Raspberry Pi and Arduino for their projects. Such as the local high school kids I help mentor. They build high altitude balloon payloads and fly them, and they all carried either an Arduino, a Pi, or both.
I/Q interfaces are vulnerable to ground loops only if the I/Q interface is analog. Why should it be, when we have excellent digital interfaces designed specifically for stereo digital audio? There are now several inexpensive SDRs (price range $100-$200) with USB interfaces, e.g., the Funcube Dongle Pro+ and the SDRPlay (there's now a second version). There's also the ultra-cheap RTL-SDR, but its narrow 8-bit A/D limits its use to VHF or UHF signals without strong adjacent channel interference. It's ideal for ADS-B (with a filter!) but I wouldn't recommend it for HF.
I've done most of my work so far with the Funcube dongle, which samples at 192 kHz and 16 bits/channel, feeding a USB interface. It looks just like a standard audio A/D to the OS, because that's what it is. The I&Q signals are produced at baseband so yes there are DC offsets and small gain and phase errors, but I found them easy to remove in software. Some phase noise is sometimes audible within a few hundred hertz of DC, but is easily swamped by typical input noise and gain settings.
Overall, this thing makes an excellent but inexpensive general coverage receiver. I sure wish I had something like this when I was a young ham without much money.
Hey, if you can read that disk, could you put it on the net somewhere? I didn't keep copies of all the earlier versions of my software. It'd be neat to see which one you got.
Probably the ultimate in QRP right now is WSPR (Weak Signal Propagation Reporter). This is a specially-designed very low speed (~1 bps) digital modulation and coding format designed for use as a propagation beacon, especially on the HF ("shortwave") bands. But it has recently been adapted for tracking ultra light weight (12.5 gram!) high altitude balloon payloads. One such payload, WB8ELK-2, has completed three complete trips around the world in the past month and is now on its fourth:
The tracker payload is powered directly by a pair of small thin-film solar panels. The weight budget is so extremely tight that there is no battery, so it transmits only during the day.
Well, not to toot my own horn too loudly, but in the mid 1980s I wrote a TCP/IP implementation. I intended it for ham radio use on low end PCs, as the only existing general purpose implementations were on commercial minicomputers far beyond a ham budget. (I actually began it on a dare by Terry Fox, WB4JFI, who insisted it was too complex to implement on anything a ham could afford.)
Before I knew it, my software was being widely used outside ham radio for dialup access to the Internet. Universities and companies set up banks of modems and PCs to give their students and employees access to their existing connections. Pretty soon commercial companies sprang up to do the same for the public, again using my software; I think we now call them "Internet Service Providers".
Meanwhile, the OSI world was continuing to produce large piles of paper, but no inexpensive (or free), usable software.
In the early 1990s, I went to Qualcomm where I ported my code onto their phones so it could be used to provide wireless Internet services.
Sure, my software is long obsolete now. When people still ask about it, I tell them to go look at Linux. But it once played a role that went well beyond ham radio, even though that's all I had originally meant it for. Perhaps this was an example of a butterfly flapping its wings; I don't know.
Thanks. It was actually TCP/IP (the Internet protocols) over packet radio.
I was just trying to say exactly that, but Slashdot lost my edited comment when I changed an option. Argh.
I never said all hams should build their own radios. But all hams should be able to learn how their radios work, if they are so inclined, and to modify and experiment with them. That's what the hobby is supposed to be about. It's exactly the same philosophy behind the open source software movement, only we hams had it first.
Most ham manufacturers still make hardware schematics available for their equipment, but microcontroller firmware has always been a sore point, especially with more and more functionality moving into DSP (as it should).
Yes, I am working on open source DSP software for the Raspberry Pi (or any other Linux platform) and inexpensive software-defined radio (SDR) front ends like the Funcube Dongle and the SDRPlay. (All three products come from the UK. Not sure what that means, but I'm glad they're making them.)
But my biggest beef is with ham digital voice. There are not one, not two but THREE mutually incompatible digital voice "standards" in common use on the VHF/UHF bands here in soCal: Fusion (Yaesu), D-Star (Icom) and DMR (Motorola). All three modulation and coding designs are dated and inefficient, with disappointing performance. Worse, they all use the same proprietary digital voice codec (AMBE) that's patented out the wazoo. It must be purchased on a custom DSP when it could easily be implemented in software on the same DSPs that do everything else in the radio. This is despite the ready availability of a superior, un-encumbered ham-developed algorithm called CODEC2 (by Dave Rowe, VK5DGR). The manufacturers simply ignore it, and few of us hams are in the position to mass-market small hand-held radios.
The domain list is on the GitHub site mentions by one of the others here. The domains, with and without www. prefix, resolve to just 13 addresses:
The whole of North Korea is on 1,280 IP addresses: 18.104.22.168/22, and 22.214.171.124/24.
This is definitely very cool, but "reveals" is a strong word. They've demonstrated that it's a plausible explanation for the puzzling distribution of stars in this cluster, but there are still other explanations that have not been ruled out.
What's puzzling about the cluster is that the stars appear well-mixed -- the high mass stars follow the same distribution as the lower mass stars. That's weird because globular clusters should undergo mass segregation, where the high mass stars slowly congregate towards the center while the lower-mass stars migrate towards the outside (interestingly, this is because self-gravitating systems have negative heat capacity, which is a concept that tends to freak out non-astronomers). And we indeed see that most clusters are mass-segregated.
So why do black holes help? They form from the most massive stars, which died early, and they end up being significantly more massive than the lower-mass stars that are left. So if there are lots of black holes, then the effect of mass segregation is to make the *black holes* congregate towards the center. In other words, mass segregation is still happening, but it's operating on black holes (which we can't see, so we don't notice its effect) instead of stars (which we can see).
There are other ways you can explain this, though. If there's a massive-enough intermediate-mass black hole at the cluster center, that makes the process of mass segregation take longer, so it might not have had time to make any significant change. A sufficiently large fraction of binary stars within the cluster could have a similar effect (i.e. make the mass segregation timescale much longer). Or, more speculatively, you could posit that there was some dynamical event that happened to the cluster since its formation that mixed the stars, so mass segregation has not had as long to operate as we assume. So their explanation is a plausible interesting one that they have demonstrated can indeed cause the desired effect, which is really cool! But these other options also need to be investigated.
Life is cheap, but the accessories can kill you.