GPS over LXMF (request for conceptual assistance)

[faragher]

One of the things I've been excited about is the ability to use personal equipment to assist search and rescue people in the field. Obviously, there's an outpouring of well-meaning but often undertrained and underequipped volunteers when there are people lost in the wilderness. By using a tracking system at incident command, the chances of areas being missed or searchers getting lost is minimized.

LoRA uplinks are far superior to WiFi and often superior to cell signals in many of these regions, particularly in these mesh configurations or if an airborne platform can house a node.

I've had excellent luck with Traccar, which accepts a wide variety of GPS formats as input over TCP/IP but I don't want to rely on running IP over Reticulum when direct communication is possible. I'd like to float the general process I was thinking of, mostly in the hopes of not running around in circles duplicating effort or making an inappropriate system.

Private Phone: Using an LXMF compatible client, GPS data is pulled from the phone, and sent in a compatible GPS format (with or without additional headers) to a pre-shared address using an RNode connected via bluetooth.

RNode: Does the magic of sending the data over LoRA. I was considering a custom hardware and modified firmware to take care of GPS positioning on the RNode itself, but given the near ubiquitous GPS on cell phones, and the fact that a $20 cell phone could be pressed into service for close to the cost of the additional board space and module, I'm not sure it's worth it. Especially forking the hardware and firmware.

Server: Python LXMF client sees the packet, (from sever RNode or other hardware interface) ensures it's meant for the node, authenticates the address as a registered node, and then sends a TCP/IP request to Traccar, entering the data in that server.

It's basically sending an arbitrary data packet, but I'd like to make sure I'm not missing something big or misunderstanding the process. I'm not a mobile dev, so I would prefer not to try to troubleshoot both the concept and learning the peculiarities of mobile at the same time. I'd also very much like to not duplicate effort if someone else has done similar work.

Thanks in advance!

[markqvist]

Hi @faragher!

This is a really valuable area of application, and that I've hoped for a long time Reticulum would find it's use in, since it is so well suited to such scenarios.

The overall architecture of the approach you outline is sound. But this is a case where I would actually say that using LXMF is too much overhead, unless you need to make sure that all position reports are ultimately received by the coordination center.

If this is not the case, a better approach would be to just use the raw Packet API. Since all such position or telemetry reports would easily fit into the packet MTU of Reticulum, they can just be efficiently sent as singular packets over the network to their final destination. This model is also very suitable for situations where you have a large amount of people moving around, possibly dropping in and out of coverage, and transmitting telemetry in an uncoordinated fashion. You don't even waste bandwidth on establishing and maintaining Reticulum Links.

Such a system easily scales to a lot of people, even on low bandwidth mediums. You can also segment devices out into different channels to increase capacity further.

I wish there was already an Android basic app source example available. In that case, it would be quite easy to just add some simple code to send the telemetry every X seconds, or once the position has changed more than a defined threshold. Unfortunately, no such "quickstart project" exists yet. You may be able to use the Sideband app as a starting point though.

Another option would be to just add the functionality to Sideband. It was the plan from the beginning to add this kind of functionality, but it has not been completed yet.

I hope this all gives a little more clarity to the subject!

[faragher]

Is this something that requires changes to Reticulum? The beacon I'm working on works just fine on the stack without modification and data is data. Given its ability to hook into packet radios (right?) it might just be an issue of writing software to manage the messages and pass it to whatever handles the APRS input/output.

[buhalo1]

I am currently trying to build a system with the described functionality. This requires solving several problems.

1. KISS TCP modem emulator to which amateur radio applications would connect.

For these purposes, you can use TCP KISS server https://github.com/simplyequipped/tcpkissserver

2. A parser-router that would decode packets from amateur applications arriving at the TCP KISS server would determine and process the PATH headers contained in these packets, after which, depending on the header, it would send these packets along two different routes.

a) Through the reticulum in broadcast, multicast or directional modes.

b) Bypassing the reticulum, but to the same interfaces used for the reticulum. In this case, I'm primarily interested in routing such packets to KISS (RNODE & AFSK) and UDP broadcast (DMR & P25 radios) interfaces used by reticulum, in the original format.
It would be even better to be able to choose which interface to send the packet with one or another PATH header, and in the case of transmission via UDP BROADCAST, select the port through which this packet will be sent depending on the PATH header included in the packet or on whether through which connection to the TCP PATH server the packet was received on.

Problem #1 is the parser-router. Programming is not my forte, the most I can do is to intuitively read and, if necessary, edit someone else's code a little, and also sometimes admire the harmony of someone else's code, for example, the reticulum code. But in any case, this task can be solved by a wide range of programmers, since its solution does not require specific knowledge.

A more difficult task, in my opinion, is the transfer of packets bypassing the reticulum but through the interfaces used by the reticulum. In my understanding, for these purposes, a bypass interface should be provided in the reticulum, which would pass packets arriving on it to the interfaces used by the reticulum without any processing.

[markqvist]

There is no need to pass Reticulum traffic over APRS. The APRS protocol is not very advanced, and has no native routing support. It would only add tons of overhead and make things much more inefficient.

You can already pass Reticulum traffic directly over AFSK packet modems, or any other systems using such hardware. No point in wrapping it all in APRS packets.

If you really, really need to, there is already support for the AX.25 interfaces, that allows you to pass Reticulum traffic over AX.25 networks, but I honestly don't recommend that, unless you absolutely cannot avoid it.

[buhalo1]

@markqvist I have the opposite goal. The goal is to transmit through interfaces used by reticulum, data from applications connected via tcp kiss in their native format without reticulum overhead. But still being able to use the reticulum.
I am considering two such applications.
1 is APRS, 2 is chattervox. This possibility is necessary for communication with operators who do not use reticulum. For example, chattervox allows you to broadcast a link to a website to all participants during an evening net over repeater, even those who do not use reticulum, but use, for example, a simple AFSK modem and an amateur radio application connected to it.
But also, for example, it can be a classic AX25 BBS running over UDP BROADCAST over P25 radios.
This option will allow you to use dongles based on vocore2 or rpi0w connected to the radios, while all of the listed applications can simultaneously run on computers connected to these dongles over wifi.

[faragher]

without reticulum overhead.

Sending arbitrary data over the RNode is trivial, if that's what you're looking for. Otherwise I'm not sure exactly how you wish to use Reticulum interfaces without Reticulum itself and its associated overhead.

Fire up Python and play with RNS and you should be able to get raw data to/from a LoRa RNode, otherwise I don't understand what you're looking for.