The "100x bandwidth" claim needs to be substantiated.
There are some significant regulatory issues with the current popular mesh network protocols in the USA, namely that neither MeshCore or Meshtastic are compliant with the actual FCC regulations. 100x bandwidth because you're breaking the rules isn't the same as 100x bandwidth legally.
The issue you linked to is about MeshCore using channels that are too narrow. A mesh system claiming to offer 100x bandwidth is probably not violating regulations in that particular way.
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.)
At least in Europe the 868 Band is is in contrast to 2.4 allowed only for low duty cycle applications that do not actually occupy the channel for more than 1% afaik (given space multiplexing). I also remember also that the free to us band was quite narrow by design (we built sensor nodes bit banging a PHY transceiver that were in the grey area of unenforced rules, 20 years ago .l)
What issues does it create for others to use too narrow of a bandwidth? Why “should” the FCC care if someone is only using a small portion of the spectrum that would otherwise be fine fr them to use?
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.
The idea with either requiring very wide band or frequency hopping on the 900Mhz band is to make it so that usages of the 900Mhz band 1. are tolerant to some loss (ie: by temporary collision) and 2. don't collide continuously (by using wide band or frequency hopping).
It's a mechanism to try to make the 900Mhz band more useful to uncoordinated users.
Our local discord questions the use of 2.4ghz for longer than 50 feet, between WiFi and Bluetooth, microwaves, and millions of "2.4 GHz (nonspec) wireless devices", the spectrum is just trashed.
i am just reading "its not allowed" "rules are being broken" "not premitted" lol. how should you invoate and break free from the current ISP model, if everythig is not premitted?
I never understood the popularity of these protocols, because when I looked at the legal duty cycles and multiplied that by time in a day and instantaneous bitrate, the result was a disappointing amount of data per day...
So many spectrum rules are totally weird though: should they be interpreted per radio device? or per user?
What -apart from cost- prevents a user who wants more bandwidth from installing 10 devices in parallel and alternate each radio so none of the radios exceed their allowed transmit duty cycle?
These things aren't "Internet Access", they're an easy way to get service that is bandwidth-equivalent to SMS, MMS, IRC or walkie talkie, over complex and distant terrain, without any central coordinating authority. Potentially even acting as last-mile to repeater nodes that pass through the actual Internet. This is a terrifically useful idea of a network in certain conditions, though in other conditions it's probably just going to be last-mile for your personal Gmail account.
I didn't assume "internet access", even for machine 2 machine applications, it was a disappointingly low bandwidth.
I don't deny a niche of applications, I tried to understand its popularity, and back then I came to the conclusion it was probably illicit use of the technology, not conformant use.
The people I know playing around with it are interested in something that offers very basic SMS style broadcast without any centralized authority or infrastructure.
For example here on the west coast we have a non trivial probability of earthquakes big enough that a lot of infrastructure may be down for weeks.
Another motivation is political. We've already seen efforts to restrict people's ability to warn others about ICE's activity. So I know some people that while not going full revolutionary or anything, are interested to learn about some peer 2 peer alternatives as a sort of hedge against things getting worse.
And some people just play with it because the tech is neat, it's fun to see how far your messages can get, etc.
> What -apart from cost- prevents a user who wants more bandwidth from installing 10 devices in parallel and alternate each radio so none of the radios exceed their allowed transmit duty cycle?
Folks with badges knocking on the user’s door. It is pretty trivial to locate stationary signals.
I suspect protocols like B.A.T.M.A.N. would consume all available LoRa airtime just with neighbor discovery. On Meshtastic, nodes announcing their presence more than once per hour is seen as unnecessarily talkative.
I also don't think it's possible to make Meshtastic into the kind of reliable and high-performance mesh network some users want without effectively dropping support for most battery-powered devices by requiring much more frequent transmissions to maintain connectivity and participation in the mesh.
> I also don't think it's possible to make Meshtastic into the kind of reliable and high-performance mesh network some users want without effectively dropping support for most battery-powered devices
Interesting.
Zigbee has this distinction between router node and non-router node.
Routers are active members of the mesh (relay). Non-routers are just clients.
Most battery devices in Zigbee acts generally as non-router.
It is surprising that Meshtastic did not follow this pattern. Zigbee is not a young protocol.
In the U.S. I believe the FCC has federal authority to knock down your door, if they can pinpoint an illegal interference emanating from within your home. Intent is not particularly a factor in that, since interference can have a large radius and be unintentional. Seems like an awful time to be intentionally emanating ‘de facto unenforceable’ illegal signals.
If projects like this and DynamicLand interest you, it's worth checking out https://folk.computer/ - they've been working on this much more recently than DynamicLand and share their code as open source.
Do you think there's a path where you can pregenerate popular paths of dialogue to avoid LLM inference costs for every player? And possibly pair it with a lightweight local LLM to slightly adapt the responses? While still shelling out to a larger model when users go "off the rails"?
Not the founder, but having run conversational agents at decent scale, I don't think the cost actually matters much early on.
It's almost always better to pay more for the smarter model, than to potentially give a worse player experience.
If they had 1M+ players there would certainly be room to optimize, but starting out you'd certainly spend more trying engineer the model switcher than you would save in token costs.
I agree, trying to save on costs early on is basically betting against things getting better. Not only that but in almost every case people prefer the best model they can get!
Not only that but I think our selling point is rewarding creativity with emergent behavior. I think baked dialogue would turn into traditional game with worse writing pretty quick and then you got a problem.
For example, this AI game here does multiple choices with a local model and people seem a bit mild about it.
We could use it to cache popular QA, but in my experience humans are insane and nobody ever says even remotely similar things to robots :)
Yep, SAR stands for "specific absorption rate". These sensors are typically used to change how the antennas on the phone transmit (like how much power they use) by detecting whether the phone is held close to your body vs. sitting somewhere like on a table.
Like the coulometer they mention. This is a battery discharge sensor, nobody would mention this in the specs. SAR sensor and coulometer are standard by now.
Which leads to a conclusion, either the makers don't know enough to know it's standard (which suggests they aren't well informed enough to make a modern smartphone), or they do know but decided to include it to pad their spec sheet (which suggests disingenuous marketing).
They could just be transparent and know their techy customers are interested in these sorts of things. Possibly, they want to assure customers that their off-brand phone includes such features.
That would also be my reading. I'm the type of nerd who's interested in minute details of his devices. I'm looking for a new phone currently and my spreadsheet includes columns like the UFS version, minimal brightness (as measured by some independent news site), whether it has a barometer, dual-frequency GNSS, etc. It always requires retrieving info via third parties such as https://docs.google.com/spreadsheets/d/1jXtRCoEnnFNWj6_oFlVW... (GPSTest database), https://phyphox.org/sensordb/, the video mode list on gsmarena.com, etc.
I haven't yet found a manufacturer that publishes sufficient detail such that I can fill out all relevant columns from their official spec page. They're never detailed enough so I can only applaud including more details. There will always be fields that aren't relevant to different subgroups of the audience...
> by detecting whether the phone is held close to your body vs. sitting somewhere like on a table
Wow, so it basically measures the material that it's near to! That's cool. I know that microwaves are well-adsorbed by water (such as in bodies), is that how this works, does it piggyback on the 2.4 GHz antenna? Can I read this sensor's output via some Android API or a device file (with root perhaps)?
Is it a product though? So far they've just released all their code as open source (which Dynamicland did not do) and helped people set up their own Folk systems in other cities. I don't think they're selling anything.
Erlang's use in the telecom sphere has primarily been focused on switching, routing, and real time voice processing on the backend. Beyond just handling cellular traffic, many internet switches are written in Erlang too. It's only recently that Erlang has been used for more of the type of code that could run on the frontend. (The niceness of writing Elixir is a big part of that too.)
The primary blocker to running Erlang on mobile has been the lack of portability of the BEAM VM itself, which is why this project is so exciting!
I looked at using this for a client project a few months ago. We use Erlang and Elixir at work, and it's my go-to for anything serious.
Be aware that parts of their stack use a custom license for some components... but a large portion of it is OSS Apache 2.0, which is nice if you can stick to those parts!
In middle school, in an attempt to get around the school firewall, I copied the HTML code from that website to my own to play Minecraft at school. Since my domain wasn't on the blocklist, it worked! But when my friends started using it to play, even after they hadn't bought the game, I resolved to add a login wall.
I built a backend proxy in PHP that would POST their credentials to the Minecraft API to make sure they had purchased the game. I still think it's funny to think I had no ethical qualms about circumventing the school firewall, but piracy was where I drew the line.
This book is a fantastic introduction to Erlang in very approachable language. It introduces the reader to both language syntax and design decisions that led to Erlang's strengths as a highly reliable programming language for realtime applications.
If you're learning Elixir right now, I can't recommend enough to also learn a bit about Erlang. The OTP and BEAM VM sit underneath both systems, and learning about what's going on under the hood helps a ton when troubleshooting production issues!
There are some significant regulatory issues with the current popular mesh network protocols in the USA, namely that neither MeshCore or Meshtastic are compliant with the actual FCC regulations. 100x bandwidth because you're breaking the rules isn't the same as 100x bandwidth legally.
Here is the issue discussing this in the MeshCore repository: https://github.com/meshcore-dev/MeshCore/issues/945