[Berlin-wireless] Alternate radio internet network
freifunki098 at riseup.net
freifunki098 at riseup.net
Mo Mär 28 21:49:32 CEST 2022
idk about running it on a cell phone.
But there are small portable routers that you could use.
Gl.inet produced several that can run with the freifunk software.
To be sure it's available for freifunk berlin, check this:
https://selector.berlin.freifunk.net/
On 2022-03-28 08:08, Julius Hamilton wrote:
> Thanks.
>
> I read online Freifunk runs a “mesh network” which I guess is
> exactly what I was looking for, so I’ll try to join that network.
>
> Does anyone think a cell phone could correspond with the network in
> some way?
>
> Or do I need to buy a router?
>
> Are there any very small or mobile ones?
>
> Thanks very much,
> Julius
>
> On Mon 28. Mar 2022 at 01:26, Christian Hammel <hammel at gmx.de> wrote:
>
>>> You might use the LORA Wan stuff …
>>
>> mmh. Probably not.
>>
>> 1.
>> The LoRaWAN protocol does not cover meshing or peer to peer
>> Networking.
>> It is designed to use a central infrastructure (end-device -->
>> gateway
>> --> Internet --> packet broker (central server) and some more
>> central
>> elements --> user's application and vice versa) End-device -->
>> end-device or end-device --> gateway --> end device ist not part of
>> the
>> protocol. Workarounds would probably fail because of the end to end
>> encryption of the packets.
>> For LoRa as a physical layer (without LoRaWAN) some p2p examples are
>> known.
>>
>> 2.
>> I have no idea, how to force answers within 0,1 s at the LoRaWAN
>> level.
>> If intended this would probably have to be implemented in the
>> server-sided (user's-)application. In addition to that a particular
>> amount of packet losses is always probable in the ISM band even when
>> they were sent in the timing windwow. And (even worse): If you don't
>> implement it in your device or in your application LoRaWAN does not
>> ACK
>> packets (workaround known) and the packet's payload is only some
>> 40bytes
>> (TTN) or less (Helium). Aditionally downstream messages are more
>> restricted than upstream.
>>
>> 3.
>> LoRa is not exactly "free": The chirp radio behind LoRa is
>> IP-protected
>> by semtech's patents. The LoRaWAN standard is published but also
>> owned
>> by semtech or the LoRaWAN alliance, respectively. For using a
>> specific
>> network your packets must have a network ID in their headers in
>> order to
>> be accepted, forwarded or dismissed by the network operator's packet
>> broker. A network ID for your own LoRaWAN-Network must be bought or
>> leased for (much) money. Using other people's LoRaWAN networks (and
>> their IDs) is for free but restricted by a a fair use policy (TTN)
>> or
>> costs transmission fees (Helium and other
>> Cryptomining-IoT-Networks).
>> In all cases LoRaWAN networks are far away from Freifunk's pico
>> peering.
>>
>> 4.
>> Are you aware of IoT networks like LoRaWAN, Sigfox and others beeing
>> extremly narrow-banded? They are usually good for transferring some
>> bytes like the readout of a thermometer and begin to reach their
>> limits
>> already with transferring characters. Depending on what is intended
>> to
>> do, 0,1 s response time might not be the biggest problem with these
>> technologies.
>>
>>>> Because assuming I only need to design a protocol, I just need to
>>>> create a web server of a certain kind. People can share the
>> locations
>>>> of their servers, exactly like a URL for HTTP, or an email
>> address for
>>>> IMAP. As long as it conforms to the “standards” in a way
>> (I’m not sure
>>>> how to enforce that, like a protocol in Swift or an interface in
>>>> Java), it’s a valid server - just like a REST API I believe can
>> be
>>>> written in any language but it just respond to things like GET
>>>> requests and so on.
>> In a narrowband world you would make your device send it's
>> GPS-Coordinates every some minutes or so to a database and fetch the
>> coordinates from there via the internet and not adress the
>> GPS-sensor of
>> your device directly (whether with LoRaWAN or something alike or
>> not) by
>> GET requests. It's also safer because it avoids direct communication
>> between third parties and your device.
>>
>> Christian
>>
>> _______________________________________________
>> Berlin mailing list
>> Berlin at berlin.freifunk.net
>> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>> Diese Mailingliste besitzt ein ffentlich einsehbares Archiv
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein �ffentlich einsehbares Archiv
Mehr Informationen über die Mailingliste Berlin