Anything physical which dampens higher frequency oscillations would act as an antialiasing filter.
HN user
colanderman
chris@pacejo.net
Spectral power density is the primary concern.
The legal power limit in these bands is 1 W. If you spread that out over 500 kHz, that signal is weaker than background noise at any given frequency for anyone more than about a city block away. (Give or take many factors.)
But, if you compress that 1 W into, say, 12.5 kHz (typical for FM voice), your signal is now detectable (and will interfere with other, possibly licensed, users) at over 6 times the distance.
There are probably other factors. For example, it's not legally sufficient to simply reduce your power by a corresponding factor. I suspect it may simply be the FCC's goal to reduce conflict between users by mandating spread-spectrum technologies for unlicensed use.
Note also that 47 CFR 15.247(e) [1] gives a spectral power limit which corresponds approximately with the 1 W max / 500 kHz min specified in (b)(3) and (a)(2).
Final side note – https://docs.fcc.gov/public/attachments/FCC-02-151A1.pdf is interesting reading as to how the current form of 15.247 came to be. Specifically it changed the rule from specifically DSSS to digital modulation generally, which in turn allowed the transition from 802.11b (DSSS) to 802.11g (OFDM) on 2.4 GHz.
[1] https://www.ecfr.gov/current/title-47/part-15/section-15.247...
Correct. The LoRa configurations mentioned which offer 100× the speed of Meshtastic/Core operate at 800 kHz and 1.6 MHz bandwidth, which are permitted by the FCC in 15.247.
As far as I know there's not actually anything particular to 2.4 GHz allowing higher throughput for LoRa than that the corresponding Semtech chip happens to support wider bandwidths. (I.e. no legal barrier.)
The tradeoff is less range due to lower link budget. Doubly so because 2.4 GHz has higher free-space path loss. You're not going to get outside your house with these speeds. The primary use (as stated in the original post) is likely through clear space with a directed antenna.
(The 2.4 GHz band is better suited to this use since you can use antennas with higher than 6 dBi gain. If my math is correct, anything higher than 11 dBi is a win even accounting for FSPL and the power derating the FCC imposes.)
(Aside, I am the author of that MeshCore ticket.)
The 915 MHz, 2.4 GHz and 5.8 GHz bands are regulated in the US largely in the same manner, see https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A...
I did not state that humans cannot see corona.
Nor is the paper is about humans seeing corona.
It is about detecting UV photons using specialized equipment.
Which photograph? The one in the article is not from the paper. The paper contains no photographs of corona.
Can you point me to the images of corona in the paper which I missed?
The images in the article are not from the paper. The paper contains no images of corona.
There is in fact no photograph of treetops glowing.
There is a digital UV-wavelength video of the corona, and a visible-wavelength video of the trees.
The paper [1] contains a sole picture with tiny circles indicating where the UV-video detected corona events, overlaid over a frame of the visible-wavelength video.
The paper does also contain a video [2] which overlays a somewhat processed version of the UV video over the visible wavelength video, where UV photon events are indicated by decaying red dots.
[1] https://agupubs.onlinelibrary.wiley.com/doi/10.1029/2025GL11...
[2] https://agupubs.onlinelibrary.wiley.com/action/downloadSuppl...
Nice! I've been looking for such a thing lately. KISSLoraTNC [1] is another implementation: The radio control interfaces differ though.
I am just getting into the packet scene in the Boston area.
APRS aside, as far as I've found, there are about a half dozen Winlink nodes in the area and one BBS. And one lovely node in Cambridge (KZ2X-1 [1]) which provides connectivity to a bevy of ancient (though virtualized) OSes.
I don't know how much AMPRnet activity there is. There are only 7 allocations in the area (mine included). I'd love to be able to e.g. log in to my home network from a few radio hops away but I don't think there's any infrastructure in place for that (such as Mobile IP).
Hah! I was literally about to open up my nascent userland AX.25 stack. Is yours open-source, or would you mind sharing? (My e-mail is in my profile.) I want to get something running on an ESP32-S3. My goal is to turn a Cardputer into a companion TNC console for my Kenwood TH-D74.
You may find a good fit at a UU church.
I have nostalgia for Wario Land, because I played it for 5 minutes in a Toys'R'Us, and it's a good game which I never got to play in full until decades later. But I never owned one, so everything else you said rings true to me.
I know only basics about mesh networks per se. I'm speaking here from a background in signal theory / amateur radio / research on the LoRa protocol. If you have specific questions on those aspects feel free to contact me, my e-mail is in my profile.
Is your goal nondetection? If so, know that triangulating a radio signal is fairly straightforward, even in a dragnet fashion. The exception I think is something like cryptographic DSSS (found in military use) wherein not only is the signal far below the noise floor, but the spreading function is not predictable by an adversary (LoRa being very much predictable). Even then, you're limited by physics to only be able to transmit so far without the signal being detectable near the transmitter.
Correction (too late to edit), MeshCore is 62.5 kHz bandwidth, not 125 kHz.
I am pretty sure (though have not vetted) that triangulation of LoRa is possible even at very low SNR.
The trick is understanding LoRa's trick, which is simply to "skew" the signal across time (via chirps), modulo a window of the configured bandwidth around the center frequency. The key is that the skew rate is purely a function of the spreading factor, bandwidth, and IQ polarity (= pol × BW² / 2^SF), so there's a small-ish finite number of skew rates. So you can just modulate raw IQ data with carriers at each of these skew rates to find one which gives you a bunch of carrier waves that hop around discretely at about twice the symbol rate, looking like an FSK signal. You can then bin this at a factor of, say 2^(SF-2) to correlate the signal and raise it up above the noise floor, on which you can apply any standard triangulation technique.
I'll try vetting this soon and reply to this post with results.
A gentle FYI for casuals interested in Meshtastic / MeshCore in the the USA: the default radio settings promoted by both these services are actually outside the parameters permitted by the FCC for unlicensed spread-spectrum operation, which require that such signals be spread over at least 500 kHz of spectrum [1]. Meshtastic "LongFast" spreads over only 250 kHz, and MeshCore "USA Recommended" over only 125 kHz.
(500 kHz bandwidth is indeed a valid setting for the underlying LoRa protocol, and is used when the radios get certified.)
Unfortunately the community meshes in most/all US metros have coalesced around these settings, meaning one is forced to choose between linking with "the" mesh, or operating legally.
[1] https://www.ecfr.gov/current/title-47/part-15/section-15.247...
No, but all MeshCore radios operating in Companion Radio mode do, which is what my post is about.
Agreed – and MeshCore follows a similar "security on the radio" design.
With the "cell phone + companion radio" setup which is currently very popular, it would seem the correct solution is to perform encryption on the phone – using the Signal protocol – and use the companion radio only to send/receive these blobs.
This has the added benefit that you can pair with _any_ arbitrary companion radio, rather than your identity being tied to one specific radio you own.
Ah TDoA might not have the resolution you need for that, unless you are working with very wideband signals. Probably ~100 m resolution is the best you can get from it.
Oh wow that's a fantastic resource thank you!
https://khanfar-spectrum-analyzer.web.app/ also has some phase-based direction-finding software and upcoming hardware.
For triangulation though, if you have a reference signal at a known location, TDoA (time difference of arrival) requires less hardware (just a single receiver at each location, e.g. an RTL-SDR). I don't know of any open-source software which does that though I've been slowly building some for my own use (it's pretty janky at the moment).
Oh I really like this idea! If you do make this please post it here.
This would be a great learning tool for those of us who are trying to learn it also.
Not a bug, it was an explicit change they made about a year ago. I used to enjoy the recommendations based on my likes and they took that away.
The common guidance I've seen is en dash with spaces, em dash without.
Terminology nit: "file descriptor" is the reference itself. "Open file description" is the thing referenced. dup(2) and fork(2) create new file descriptors which reference the same underlying open file descriptions.
Not all reals are expressible: to be expressible is to have a finite representation in some language. Definable numbers [1] are that (countably infinite) subset of the reals which can be expressed individually. Almost all reals are not definable and therefore cannot be individually named.
Why, in your own words, is the jump supposed to be there? (Keep in mind this code is in between two functions.)
And why, in your own words, is it OK for the jump to be a conditional backwards jump?
From your own link:
The trapsleds implemented in this diff convert NOP sleds longer than 2 bytes from a series of 0x66666690 instructions to a 2 byte short JMP over a series of INT3 instructions that fill the rest of the gap.
The BMI instructions in the article are not jumping over breakpoint (INT3) instructions. They're conditionally jumping backwards by some amount.
Why in your belief is this? Please use your own words or a relevant direct quote to state your understanding of how a trapsled works.