I appreciated the Pluto.jl mention! Going from Pluto notebooks that understand data flow to Jupyter notebooks where you have to tell the computer which order to run the cells in is always baffling to me. Why doesn't Jupyter know the run order and dependencies already? The way Pluto handles dependencies between code cells is really just so nice.
Yup, slight mix-up. Gravity waves are waves in the ocean and atmosphere (or other fluid bodies) where Earth's gravity is the restoring forces that causes wave propagation. Gravitational waves are the waves in spacetime caused by powerful astronomical events like black hole mergers.
Sure, all the water in the ocean is affected by gravity.
However, there are many different types of waves in physics, usually described by some form of wave equation[1]. And for some of those, body forces[2] like gravity doesn't play a direct role.
A relevant example is acoustic waves[3], which are the propagation of changes in pressure. In that case, the only thing gravity is doing is confining the water to a single body through which the acoustic wave can propagate, it doesn't affect the propagation otherwise as such.
Cool! It looks like the Wansview Q5 has a similar SoC/camera/wireless setup as the Wansview W7, which as an installer guide on the Thingino wiki [1]. I wonder if that same installation process (but with the q5 firmware) would work. For $16 I'm inclined to try it out.
> The analog ones are easy to play with. You just need a DAC to drive their VCO and then can sample the I/Q pins with an ADC
Do you have any reference or notes on how to access the IQ pins on one of these devices (ideally one of the FMCW ones)? I've been wanting to play around with one of these 24 GHz or 60 GHz units for coherent radar but it seems like most of the boards only report on distances over serial links. If there's an easy way to tap into the analog IF signal after down conversion I'd love to see how to do that!
Cool! Do you like that approach? I've thought about setting up that exact thing but I wasn't sure how well it would work in practice. Are there any pitfalls you ran into early on? I might give it a shot after your "very easy to set up and operate" review!
Honestly it was very easy. Their documentation is decent, and the defaults are good.
Setting up Pangolin on the VPS, and Newt on your lan, connecting them and adding e.g. a small demo website as a resource on Pagolin will take you about half an hour (unless your domain propagation is slow, so always start by defining the name in DNS and point it to your VPS IP to start with. You can use a wildcard if you do not want to manually make a new DNS entry each time)
I would recommend just trying it out! (as long as you have the disk space for a few models). llama.cpp[0] is pretty easy to download and build and has good support for M-series Macbook Airs. I usually just use LMStudio[1] though - it's got a nice and easy-to-use interface that looks like the ChatGPT or Claude webpage, and you can search for and download models from within the program. LMStudio would be the easiest way to get started and probably all you need. I use it a lot on my M2 Macbook Air and it's really handy.
> you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC
This sounds very interesting! What's the scenario where you'd do this? Would you be, for example, emulating an ARM processor with qemu on an x86 computer and chrooting into Android on an eMMC?
These days (with recent kernels) you don't even have to copy the qemu binary into the rootfs nor use a static binary - these used to be workarounds for things that kernel now handles on its own.
Well technically you can't, in the sense that chroot has no idea you're doing it... the magic of binfmt support in the kernel (setup for qemu by the post-install script for qemu-user-static I believe) basically lets you run any architecture's binary that qemu-user-* supports just by trying to execute it natively, it basically just translates the execution of "./other-arch-cmd" into "qemu-user-static ./other-arch-cmd".
Thank you. That makes sense. Even though there is a translation layer via qemu-user-static, still having the facilities to have that transparently is very fantastic. And also very fascinating and a revelation to learn about for a bearded old timer like me who has never seen it before.
Yeah, that’s how we customize the NVidia Orin BSP before flashing it. Untar the rootfs onto a fast x86-64 machine, chroot into it, and use qemu-user to run a bunch of Arm commands and build some stuff. Way easier than trying to set up a cross-compiler toolchain.
chroot can be a alternative to setting up fussy cross-compilers. It'll be slower, but that slowness pays off as long as you spend less time on extra CPU cycles than you do on getting cross compilers to work.
It's also useful for reverse-engineering router/IoT firmware.
A challenge there is that there are very few stable lunar orbits! High orbits are perturbed by Earth's gravity (3-body problem) and low lunar orbits are perturbed by the lumpy distribution of mass in the Moon's interior [0]. Lunar GNSS satellites with a little bit of onboard propulsion could probably correct for some of these perturbations but once they ran out of fuel they would have a limited orbital lifetime.
Technically, satellite positioning only needs 1 satellite. GPS requires several but one of its forerunners was Transit[1] which I believe only needed a signal from a single satellite at a time. It worked by measuring the doppler shift of the signal coming from the satellite. Of course that only works if the orbit can eventually cover all (or much of) the surface and for all I know there is no such frozen orbit for the moon. Also, it would still presumably require extensive surface-based tracking and correction.
I wonder if lunar space elevators might be the fix here. If I understand correctly, such an elevator would not be as subject to the perturbations since the tension would keep it's orbit stable (is it still an orbit if it's tethered?).
Another option might be a LORAN style system put up on towers. With lower gravity and no atmosphere I imagine we could stick transmitters up very high without super complex construction, maybe even just a giant carbon fiber tube with a transmitter at the top.
> The mascons' gravitational anomaly is so great—half a percent—that it actually would be measurable to astronauts on the lunar surface. "If you were standing at the edge of one of the maria, a plumb bob would hang about a third of a degree off vertical, pointing toward the mascon," Konopliv says. Moreover, an astronaut in full spacesuit and life-support gear whose lunar weight was exactly 50 pounds at the edge of the mascon would weigh 50 pounds and 4 ounces when standing in the mascon's center.
It is still all completely correct. There may be some new findings, but the lunar prospector ( https://en.wikipedia.org/wiki/Lunar_Prospector ) did all the work and this was written after that.
You need signals from 3+ different locations to navigate, and the two stable Lagrange points, L4 and L5, are as far from the moon as Earth is: https://en.wikipedia.org/wiki/Lagrange_point.
But-- GPS already produces an okayish fix. Improving it with another signal from somewhere else would make a big difference.
> and the two stable Lagrange points, L4 and L5
We have plenty of spacecraft hanging out around L1, etc. It's possible to orbit it without too much issue. Having one broadcast a navigation signal synchronized with GPS would not be too bad.
> are as far from the moon as Earth is
The issue isn't that they're far away-- it's that they're all in pretty much the same direction. There's very small uncertainties in orbits and measured path length, but if they're all in the same direction you get very poor lateral position.
This is the same effect you can get if you can only see a little tiny bit of the sky with GPS. You might have enough satellites to navigate, but since they're all close to the same direction the navigation solution is much worse.
The restricted three-body problem deals with the case when the third mass is trivial and the orbits are circular. The new solutions in this case are the Lagrange points. That's helpful, but doesn't make finding dynamic solutions much easier on it's own.
