If these Shahed drones have a propeller they should have a brutal signature between 0-250Hz as they are moving a lot of air. And if the engine speed of the Shahed stays constant it will be even easier to detect it ("Angry lawnmower sound".. but that's only the high frequency part of it).
There are extremely sensitive differential pressure sensors (like SDP600-25Pa) available from Sensirion that aren't overly expensive.
Use one differential side and connect it to a kitchen funnel for directional listening the other one to a plastic bottle with a tiny hole in it. This way the sensor will "Null" out the environmental pressure (which the bottle follows very very slowly) from both inputs. It then only will pick up everything high frequency which is left over (and the bottle cannot follow because of its small hole).
This way I was able to detect washing machines that have a physical link to a house from many hundred meters (machine spinning -> house wall shaking -> pressure waves) away. The speed pattern of washing machines when spinning is very unique (several steps over many seconds).
Add this with some GPS PPS frame timestamping and you should have a nice tracking network that doesn't require a lot of bandwidth. But maybe the setup must switch to analog differential pressure sensors as these Senirion-I2C sensors do not have a Sync ping for super precise timestamping.
> Use one differential side and connect it to a kitchen funnel for directional listening the other one to a plastic bottle with a very very small hole in it. It will pick up everything high frequency that's different to the environmental pressure.
Nevermind drones, and war, that's all fine; but I need to know more about this. Is there a phrase or name for this I could use to find more information, maybe example schematics?
Interesting! There are a lot of super loud cars in my urban area. I want to catalog where and when they drive, so I can stand on the side of the street and shake my cane at them.
I’ve always dreamt of building a mesh network of loud vehicle detectors that would map current loud noises and track where loud vehicles live, coupled with very powerful parametric speakers. So when e.g. the network detects a loud motorcycle at 3am anywhere in town, that live sound is instantly played at high volumes targeting only homes where other loud vehicles live.
Somehow there has been little VC interest in this idea.
Yes. But they usually are not performing very good between 1-250Hz.
Sensirion is using a thermal flow-sensing principle method which is basically a heated plate that cools/heats up when air passes it - making it extremely sensitive in this range.
The equivalent noise density of the sdp600 is 10^-2 Pa/sqrt(Hz). While the noise density of a typical microphone is 10^-6 Pa/sqrt(Hz). At same 50hz low frequencies. So either you're full of shit and a high quality microphone is x10000 more sensitive than this sdp600 sensor, or I'm not understanding what you're saying.
Any self-respecting microphone will be sensitive to tens of micropascals (the conversion between SPL and Pa is straightforward). The Sensirion device is proud of its ability to operate at 10 Pa.
That being said, most microphones are intended for audio and their amplifiers and readout circuitry are not optimized for very low frequencies. And the physical measurement devices don’t work down to DC. (If they did then the microphone wouldn’t work — the DC pressure is around 1 atm, which is some 12 orders of magnitude above the more quiet sounds the microphone is trying to detect.)
A device sold as a pressure sensor will be intended for use at or near 0 Hz and will work fine.
I assume the actual practical crossover is something like 0.1 - 10 Hz depending on the microphone. There’s an additional practical issue, though: the pressure sensor comes from the factory already calibrated for DC, whereas you may be on your own trying to get physical units out of a microphone much below 20Hz.
If you use a high end microphone intended for professional use with phantom power, you will also be fighting the power circuit and lower frequencies.
To detect something, you at least need response that isn’t effectively zero at the relevant frequency. And bonus points for not having ludicrous amounts of jitter due to polling a sensor over a bus like I2C that is really not intended to collect high frequency, equally spaced samples.
It "looked good" for me up to 100Hz after Nyquist in the spectrum but didn't pull any precise data. Just created a 50Hz tone using my speakers which showed up in the spectrum afterwards as expected as basic verification
Took some spectras from heat pumps, airplanes and a helicopter.
A long time ago I used a hot wire anemometer to measure flow up to several hundred Hz, but that was an expensive instrument being read by an expensive National Instruments acquisition platform. This is a cheap, self-contained device. Go Sensirion.
I wonder whether the frequency limit ends up being set by the ADC or the physical sensor. I’m also curious how the Sensirion sensor detects the sign of the pressure difference.
The SDP600-25Pa speaks I2C and only has a handful of commands.
Just read it out with a microcontroller you love (like ESP32) and send the samples to a host for analysis. The ESP32 has limited I2C time stretching capabilities limiting it in the highest resolution modes of the sensor - but often that's not a big factor.
To not overwhelm the poor processor and Wifi maybe better a bunch of frames (like 512 or more).
Theoretically wind can be Nulled with a 4-way water splitter that are placed in 90° angles (+ a connector at the bottom to the sensor). As long they are orthogonal the wind pressure coming from one side will cause a negative pressure on the opposite.
Only pressure waves coming into all holes at the same time will reach sensor.
Never tested it. Only a Gedankenexperiment as Einstein would say.
Applicable to only those of the US (who choose to comply), which would mean giving non-US an advantage, which is a distinct no-no. They tried to restrict Fable to only-US, but that backfired since the world isn't at all clean cut, resulting in full unavailability of the model
Without international treaty and regulation restricting frontier capabilities globally, any attempt to outlaw open source models will only be as effective as King Canute ordering the tide to turn. Unless the USA fancies bombing those who refuse.
It cannot. The only available law is an export control law. A restriction on an open model would be strongly unconstitutional due to a freedom of speech guarantee in the Constitution.
With Wi-Fi 8 we will finally get steerable friendly roaming like cellular radio is doing for almost 40 years now.
This "here's a neighbor table, disassoc and fuck you&good luck"-method we must use right now is just super painful. It's super complicated to build reliable networks that way.
All ham radio repeater groups here dropped Meshtastic as it was super unreliable. And they know how to build proper antennas and filters.
Meshcore is 100% free. The last issue was the closed sorce Android/iPhone client - but there are FOSS Flutter based-Opensource clients available (https://github.com/zjs81/meshcore-open)
With GNSS+PPS and a hardware timer latch you can easily sync internal microcontroller timers to 2 to 3-digits nanoseconds against the global standard with a tightly controlled loop. But cannot get better than the PPS signal itself (roughly 30-100nS).
Everything below needs that a huge amount of engineering. CERN&friends developed the "White Rabbit" (https://ohwr.org/projects/white-rabbit/) system for this. This allows sub-Nanoseconds syncing of netwoked devices.
Yes. I'm aware. Perhaps I'm more stupid about this topic than normal, but it looks to me like the NICs I have do (NIC names have been changed for clarity, but all other output is untouched):
$ ethtool -T intel-nic
Time stamping parameters for intel-nic:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
Hardware timestamp provider index: 0
Hardware timestamp provider qualifier: Precise (IEEE 1588 quality)
Hardware timestamp source: MAC
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all
$ ethtool -T brcm-nic
Time stamping parameters for brcm-nic:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
Hardware timestamp provider index: 0
Hardware timestamp provider qualifier: Precise (IEEE 1588 quality)
Hardware timestamp source: MAC
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
ptpv1-l4-event
ptpv2-l4-event
ptpv2-l2-event
Intel's drivers are notoriously annoying as the parent of the parent comment suggests. It seems to be a mix of hardware bugs and a driver that doesn't properly account for them. I know many who've moved to ASIX, Mellanox, and other chipsets just because they don't get weird behaviors or two edges per pulse without hacking the driver.
> It seems to be a mix of hardware bugs and a driver that doesn't properly account for them.
~~yaaaaay~~
Also, who the heck knows if my switches are behaving correctly? I may be dealing with a system with multiple failing components.
I'd never considered Mellanox hardware... I'd always thought of them as "super expensive datacenter hardware", but non-Infiniband cards I can see on Newegg aren't entirely-unreasonably priced. (TBD if I can find a PCI-E 2.0 1x card, though). I'd not heard of ASIX, and they have a card that would fit in my slot, but -sadly- no in-tree driver. It looks like the only in-tree driver is for a 100mbit card... the AX88796C.
Anyway, thanks for the advice/info and the mention of more-reliable manufacturers.
This - at least for me - messes up the rolling release stuff at least one a month.