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.
reply