Source code

[jpmeijers]

Is it possible to publish the source for the Arduino firmware images? Some might need modification for different regions of the world.

[spleenware]

I'm still weighing up whether to open source or not. For now, I have considered the problem of different frequencies for regions. I think the way forward will be to have an Advanced preferences screen in the app where you can apply preferred LoRa radio settings (freq, spreading factor, coding rate, etc). Then this would just be sent over the serial link to the Arduino.

Would that be enough for what you can foresee (for now)?

[jpmeijers]

I would really love to see this being open sourced. Not only will that allow one to make configuration changes and build for other platforms, but it will also allow other implementations of the protocol.

We are looking at this for search and rescue purposes where there is no, or almost no GSM coverage in the mountains. SMS via LoRa would be great, but if we for example can make it interoperable with LoRaWAN it will make everything even more redundant. The idea is when there is an incident we drive with the mobile field office (small truck) as far as possible into the valley. The truck has a LoRaWAN gateway and server running, receiving LoRaWAN GPS trackers. Existing LoRaWAN gateways on the mountains also might receive the GPS trackers, and if the truck is in a spot with GSM coverage, it get these packets too.

I imagine a hybrid system where we use your mesh/p2p protocol as an extension to the LoRaWAN network, adding coverage deeper into the valley, covering the LoRaWAN deadspots.

What I'm seeing is that if you opensource your implementation, it becomes the standard which other implementations and extensions should be compatible with.

[spleenware]

I haven't looked into LoRaWAN much yet. So, is that protocol more like a 'hub and spoke' network, not a mesh?

[spleenware]

Actually, what could be the most useful thing for people like you is if I published here, in the Wiki, the Serial protocol that the Arduino uses to communicate with the Android app. That protocol could quite easily be used by something other than the app to route messages in and out of the mesh, and act as a gateway. Would that be useful?

[jpmeijers]

Yes, LoRaWAN is a star of star topology. The only shortcoming is that it therefore lacks repeaters and mesh functionality.

It would be really useful if you publish the specs. However that is only useful in a phone-device setup. Some places I want the device itself to gather the data (like the GPS tracker). But let's see what we can do with it.

[spleenware]

OK, I'll prepare a Wiki with the Serial specs. It should, hopefully, make the Ripple mesh radio able to be repurposed. Originally, I had in mind to have the radios as general nodes in a sensor network, not just this SMS use-case. And the Serial protocol has provisions for this. But, none of the protocol is really set in stone yet, so could be good to get feedback on how to make it more general purpose.

[spleenware]

Also, there are fairly fundamental assumptions I've made about the whole architecture which I'm (as yet) still unsure about. This has affected a lot of tech decisions, and remains to be proven out in 'the wild' :-)

For instance, there are 3 types of packets: datagrams, 'messages', and ACK's. Datagrams have no retry capability (and are intended for things like sensor readings which are allowed to fail, or be ovewrwirtten by a later datagram). Messages do, but rely on ACKs. However, it is up to the Origin node to drive the retries. Intermediate nodes don't retry.

[spleenware]

OK, I've documented to serial protocol here in the Wiki: https://github.com/spleenware/ripple/wiki/Serial-Protocol

[luxonn]

There are similar commercial solutions already implemented and working perfectly. This project deserves to be open source as Linux in due time and then it will have a future. A very interesting project, unfortunately my experience does not allow to develop this from scratch. I have a helteс v1 433 and heltec v2 433, there is no binary for the version v1 433

[aHVzY2g]

I am also with SAR and we are looking towards this kind of architecture. @spleenware your implementation is promising but we would need to adapt some things to make it fit our use case. For that, it would be greate if you make it open source.

[spleenware]

There are still a lot of features I want to architect, and would rather take the time to do this at my own pace and not have to review pull requests and discussions, etc. I have a full time job doing Android dev, and that is takes up a lot of my energies. It might make sense to open source one day, but not at this stage in my opinion.

[marlon0]

Totally respect the desire not to get bogged down managing an open source project, because that in itself is a big job and takes away from actual design/coding.

But keep in mind that releasing the code doesn't commit you to entertaining any PRs or discussions, it just makes it possible for others to get value from it.

Even if you turn off PRs entirely, ignore the issue queue, and people just make weird forks, it could be that:

1. They learn by reading your code and are able to build a different project more easily
2. They develop a feature or integration that turns out to be useful or even just inspiring to you later down the road
3. They develop a feature or integration that helps them do an awesome thing in the world (e.g. search and rescue)

Even if you don't care much about 1 or 2, number 3 is pretty awesome and I would love to have a project that leads to that outcome (especially if I don't have to maintain it ;) ).

The humanitarian applications for this code are big - speaking for my group, we're hoping to use it to support disaster relief and emergency connectivity in rural areas. But to be honest, it's not useful at all to us as-is, since we can't depend on something if we can't throw a dev at it when it stops working. Anyway, I hope you'll give some thought to simply publishing the firmware and android code, it could lead to good things!

[marlon0]

Also, be aware that if any of the libraries you've used are GPL, the license requires you to provide the source along with the Android and Arduino binaries you're distributing. (Not to twist your arm or anything, obv nobody is gonna call a lawyer over this. But maybe you didn't know.)

[sramrajkar]

Hey I have also been developing a LoRa mesh protocol stack for over an year now. Started with PIC18 MCU and currently porting over to STM32G431. End products would be a PCB module and a DIN rail module. Let me know if you would be interested in collaborating on the project. If you are interested please send me a email at sramrajkar2@gmail.com Please find a link to some of the public documentation for my mesh stack here AT command set: https://docs.google.com/document/d/1B4R3MweKx8fC1kn7PL1VG2AEdeQMF4FevF2iVeBqe5s/edit#heading=h.uco7ly2tbbf8

Product preview: https://docs.google.com/presentation/d/1Gvk5F-FpKVj46AV1tnQNlPpOsXjoLdhaBVchAlFU-FU/edit?usp=sharing

[spleenware]

Hi,

I find it difficult to collaborate unless there is a really clear combined vision for the project. More often than not, there are too many differences in techniques or even styles that are jarring. So far I am doing this project because it's fun, and wrestling with other opinions is more like 'work' :-) Hope you understand.

On Mon, Jan 13, 2020 at 3:00 PM sramrajkar notifications@github.com wrote:

Hey I have also been developing a LoRa mesh protocol stack for over an year now. Started with PIC18 MCU and currently porting over to STM32G431. End products would be a PCB module and a DIN rail module. Let me know if you would be interested in collaborating on the project. If you are interested please send me a email at sramrajkar2@gmail.com Please find a link to some of the public documentation for my mesh stack here AT command set:

https://docs.google.com/document/d/1B4R3MweKx8fC1kn7PL1VG2AEdeQMF4FevF2iVeBqe5s/edit#heading=h.uco7ly2tbbf8

Product preview:

https://docs.google.com/presentation/d/1Gvk5F-FpKVj46AV1tnQNlPpOsXjoLdhaBVchAlFU-FU/edit?usp=sharing

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spleenware/ripple/issues/2?email_source=notifications&email_token=AAIVWJJDAK6WVL6RJPCQUKTQ5PRNVA5CNFSM4IYG75YKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXOVCA#issuecomment-573500040, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIVWJNCHASFSWRP3MWIDALQ5PRNVANCNFSM4IYG75YA .

[whoizit]

I think that you should not save blobs in the version control system and you should not use github to host proprietary blobs. There are right places for this like Dropbox or Google disk

[Cloolalang]

Now there is Meshtastic which is open source.

[jpmeijers]

Yes I saw Andreas Spiess' video about it. It's just meshtastic :P

[darkstar2002]

I also want to see the code. I want to use a m0 and a solder party board to make a messenger.