Meshtastic is going to space!

Hi, I just quickly went through Lacuna Space website and what I can see is that they basically mention LoRaWAN and not just LoRa. I guess the meshtastic LoRa packet differs from LoRaWAN- packet and thus is not routable.
I do not just have Meshtastic LoRa devices, but also several other devices that send LoRaWAN compliant packets and once they reach one of the gateways, they are forwarded to, in my case, the things stack and I can then collect the data with mqtt-client.
So, it is correct that we could send LoRa-packets to satellite, but whether it is able to forward those meshtastic packets somewhere remains unclear to me

I wonder how hard it would be to support the native Meshtastic mesh implantation and similar to the MQQT gateway an option to relay messages with a LoRaWAN gateway, terrestrial or satellite.

I don’t think I get it. :upside_down_face:
Lacuna-Space is working in the field of IOT using LoRaWAN.
Many devices (nodes) sent messages to a gateway and few messages are sent back to the IOT devices.

While Meshtastic is about a mesh network without gateways and nodes, every device has the same function and is redundant.

I would go for a satellite phone, more reliable and certainly affordable when your life may depend on it.

There have been a lot of use cases discussed over the past two years. Having an option for satellite to internet would not likely be used for chatting but could be useful in other ways. If it is reasonable to support such a feature…

@costo Meshtastic by itself is supposed to power only mesh communication. Lacuna’s satellites can read your message and bounce it back in your general direction to cover a wider area, hence letting you reach your groupmates even if they are beyond the line of sight or the horizon.

A lot of our potential customers are park rangers, search and rescue teams, mariners, hikers, and so on. I do not see the difference between a “satellite messenger” and our proposed device. Both of these can send messages out to satellites, especially for emergencies. Satphones cost hundreds of dollars per year in subscription and usage fees. Our device can provide hundreds of satellite relayed messages for less than 5$ a month.

Why do you think that satellite phones are more reliable than what we will come up with?

@Spor7biker The satellite relay can be used for chatting if needed. For now, I am more concerned about being able to provide the ability to send out a message to the “outside world”, even if one is stuck on the North Pole.

Now I’m beginning to see a picture. :slightly_smiling_face:

As I understand it, Lacuna Satelittes are meant to work as LoRa-gateway’s in space.

It is not feasable that these satellites relay/bounce/respond-to every message that is received.
Just like in a LoRaWAN network, gateway’s are mostly receiving, collecting messages that can be sent over a backbone to be processed.
A gateway cannot receive at the moment it sends a message, therefor the ratio of RX:TX is in the order of 100:1 or more, so the network can function as intended.

Shure the satellite’s SDR receiver can detect your doppler-shift and can respond with a opposite shift so your simple meshtastic-like device will receive that packet as if there is no (doppler) shift. This can only work if the satellite responds fast (seconds or maybe a minute ?) because it moves so the doppler-shift and the needed opposite shift change over time. Which is important when you use a a smaller BandWidth.

Logically Lacuna can only bounce certain packets that are approved by the backend.
Maybe that is the fee (5$/month) for that you are talking about ?

You say that for the moment, there is a lag from 9 to 90 minutes. So you cannot know if your packet was received and will be processed.
So right now a satellite-phone is better for a reliable connection. In the future things may change.

I assume they are going to want some sort of key transmitted to authenticate against an account so that they can track/charge for usage.

This is what LoRaWAN is able to do

What proof of concept or feasibility has been performed to confirm that they will relay our packets appropriately? They will need the logic that’s now being built by the Meshtastic Repeater project (@thebentern - fyi).

I do see a very high risk that if they’re not processing our packets properly, this could result in circular routing and at worse case result in an unintended denial of service attack.

I assume Lacuna has it’s own protocol for validating and responding to approved messages.
They may ‘demand’ that Meshtastic is adapting it’s protocol which I doubt will happen.

I guess that’s the reason kokroo is thinking about forking Meshtastic so ‘his’ fork will confirm to the rules Lacuna is demanding.

There’s no need to fork. We gladly accept PRs as we already support gateways.

1 Like

I indeed highly doubt they will accept non-LoRaWAN packets. On the other hand, this would be a good incentive to work on LoRaWAN compatibility for Meshtastic. This would also be cool for many other applications, like giving your mesh access to the internet or relay data through The Things Network, for example.

For that I think your best bet would be to look into this open issue of RadioLib, which seems quite some work, but doable.

1 Like

Well, LoRaWan is quite different as what comes to joining the network and keyhandling etc. In fact, as I have now seen both worlds meshtastic / LoRaWAN, I like meshtastic approach of autonomic mesh being easy to set up. If you like to start with LoRaWAN and use some cheap IoT gadgets from RAK and like to initiate joining to the network you either need someone’s gateway close enough or you invest on own gateway > 100EUR after that you rely on services provided by somebody paid or not-paid.
One possibility could be gateway between Meshtastic and LoRaWAN keeping both worlds separate.

@loodydo On their own devkit there is a chip used for authentication, but from what I have been told so far, any conventional LoRa device should be able to connect to the satellites. So it could be something as simple as an auth key in the header, or something like an encrypted packet. I have made another post regarding testing this, I will post instructions there once I am up to speed on this.

What proof of concept or feasibility has been performed to confirm that they will relay our packets appropriately? They will need the logic that’s now being built by the Meshtastic Repeater project (@thebentern - fyi).

I do see a very high risk that if they’re not processing our packets properly, this could result in circular routing and at worse case result in an unintended denial of service attack.

@mc-hamster I am not sure about that. The only thing I can confirm is that their low-power devices which utilize SX126x chips do work with the satellites indeed. The first feature I have in mind is the ability to send out an SOS message to authorities or preset numbers via our satellite relay. I thought about routing and I think that if we bounce the message via satellite, we will need to set the number of hops to 0.

@costo “Meshtastic” per se does not need to confirm their protocol. We can build a module in the source code which switches the config to “satellite mode”. I was thinking of a fork before in case a rapid pace of changes is not agreed upon by the project maintainers. There is no need to fork as of now.

@GUVWAF You are right, they utilize LoRaWAN but I am still finding out if “standard” LoRa packets will work. It shouldn’t be very hard to integrate that.

@rsainio In Lacuna’s case, the only “gateway” is their satellite which then relays it to their ground station and then to your own server if you’d like.

That’s dangerous. Preventing the denial of service will need to be more thought out – it’d also need to include tracking the message ID. The two are required to ensure the health of the flood mesh network that we are built on.

1 Like

Is your intent to use Meshtastic firmware on your hardware (as is), or to contribute to the project to support your hardware? I’m not sure if I’m following the big picture of what you’re intending.

Maybe I’m wrong but doesn’t setting hops to zero mean “don’t repeat this message”?

Whatever changes we make to the firmware will be, by default, made to the mainline meshtastic firmware.

So there’s no separation between what runs on our hardware and what runs on others. The only differences will be between hardware specs.

There needs to be two forms of protection for mesh routing to guarantee the message doesn’t overwhelm the network. One is setting the hops and the other is to note the message ID and never send it back out. This is so if one protection fails for any reason, then the other is also in place.

If you send a message out from your node and set it to 0 hops, it should never be repeated again by anyone – including an orbiting satellite.

The conversation we’re having here is good – it’s part of research. If we’re engaging a 3rd party for integrating with this technology, let’s understand what would be involved on both ends before making any kind of commitments.

2 Likes

This is realy a great news, i’love it …