Hacker Newsnew | past | comments | ask | show | jobs | submit | colanderman's commentslogin

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.


Sounds like you know what you’re talking about. I’d be very interested in learning more. I’m not a radio or even software expert. I’m a data scientist with a math background. Interested in communicating across mesh networks anonymously.

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.


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


Correction (too late to edit), MeshCore is 62.5 kHz bandwidth, not 125 kHz.

You keep posting this nonsense all over, yet Meshtastic bends over backwards to operate legally.

Either prove it by getting both mesh projects in trouble with the government or shut it. Your constant whining is annoying.


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.


Many radios don't have "a phone".


No, but all MeshCore radios operating in Companion Radio mode do, which is what my post is about.


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


You could perhaps compare notes with the author of [0] who did manage to achieve multilateration with rtl-sdrs using TDoA.

[0] https://jenda.hrach.eu/


Oh wow that's a fantastic resource thank you!


I want to experiment with stationary receivers around the perimeter of my property. It would be fun to document and pinpoint every RF source on my land, but I'd settle for being able to reliably find my dog.


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


I have a feeling this app would greatly increase the number of phantom vibrations I experience.


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.


Correct, sorry! My phrasing was off-the-cuff and less than precise.

File descriptor = reference/pointer-ish thing.

File description = referenced data.

close(2) = decrement refcount to description by closing descriptor; actual destruction of the file's open-ness doesn't happen until refcount == 0.


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.

[1] https://en.wikipedia.org/wiki/Definable_real_number


Hex D4xxxxxx is indeed (almost) BRK... on ARM64 [1].

Being ARM32, these should be BKPT (hex BExx). [2]

[1] https://developer.arm.com/documentation/ddi0602/2025-06/Base...

[2] https://developer.arm.com/documentation/ddi0597/2024-09/Base...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: