RNS Interface for Soft Devices

[OtisByron]

Is there a recommended method for configuring a Reticulum Interface for use with a software application, instead of a hardware device? For example, I've sort of written a Python FSK modem utility (using the minimodem application to do all the heavy lifting). How should I connect it to Reticulum?

Another use case (that may be a better solution than my Python package) would be interfacing fldigi software with Reticulum.

I have tried creating a custom Interface and "manually" inserted it into a running Reticulum instance, and it works but it seems messy. My next attempt would be to add UDP or TCP to my Python package, but this seems like a lot of overhead.

I'm interested to hear if others have done something similar, or if there are any recommendations. It's entirely possible that I'm missing something obvious.

Here is the minimodem Python package in case anyone is interested. It works across the room with a speaker and microphone, but has not been tested on the air yet.
https://github.com/simplyequipped/minimodem

https://github.com/simplyequipped/fskmodem

Repo and package renamed to fskmodem.

[markqvist]

That is some nice work, really useful adding a Python package for that!

For any software modem that supports KISS over TCP, Reticulum can already use it with the TCPClientInterface and the kiss_framing option. Have a look at this part of the manual. Fldigi already supports this.

For connecting your minimodem implementation, there's several options:

• We could build a Reticulum interface class around it, and add it to Reticulum "officially".
• You could add a TCP server to it, that read KISS frames over TCP. Then it would work with the TCPClientInterface already present in Reticulum. I agree that this seems like a bit of a silly amount of overhead, especially when both Reticulum and your implementation is Python. On the other hand, it is not a bad method as such, and it would be pretty quick to set up.
• We could find another generic transfer mechanism for things like this. There are several python IPC libraries available, but I really want to keep dependencies of Reticulum to a minimum, so if we can avoid any extra libraries, it'd be nice.
• We could use UNIX domain sockets. No TCP, but not really much cleaner.

I think I am generally mostly in favor of adding this as an actual interface in Reticulum, but I would also be happy to code up some kind of other generic interface type that it could interface with, if it was useful for other similar purposes.

What do you think?

[markqvist]

On further thought, maybe Reticulum could integrate this even better by implementing something like a "SoftwareInterface" or "ProgramInterface" (don't know what naming is best). It would still use the TCP KISS framing, but just simplify the setup for users. Config could be simplified to just a port number for example (or a simplified ID or similar, if some sort of scheme was agreed upon), which would be make it very clean and easy to set up.

[4c3e]

Something like the I2P SAM API for RNS would be useful for building native apps in any programming language without having to put in the effort towards a RNS rewrite.

[markqvist]

Something like the I2P SAM API for RNS would be useful for building native apps in any programming language without having to put in the effort towards a RNS rewrite.

That would be very useful indeed. The above was more in relation to offering an easy way to interface for programs providing communications transports, for example software/soundcard modems and similar. It would also make it easy for anyone needing one-off/specialised interfaces for internal/personal use. As an example, it would probably be out of scope to include an interface directly in Reticulum for using a SQL database server as a communication medium, but obscure needs happen all the time, and with the above, it would be easy to whip it together yourself because there would be a standardised interface for it, and some minimal examples and documentation.

[OtisByron]

That is absolutely great. Very clean and effective. Thanks a lot for sharing your implementation. Do you mind if I add a section to the manual about creating custom interfaces based on your work here?

Feel free to use this however you like.

If I'm understanding correctly, adding an RNS interface for this specific type of TCP client would only save two lines in the config file (kiss_framing and target_host) compared to using the existing TCP Client Interface, and you already have the latter documented well in the manual (I just missed it, which is why this discussion exists in the first place :)

A Software Interface that implemented an API for external applications (as @4c3e mentioned above) would significantly reduce the complexity on the user side, but I suspect that would be a lot more development on the RNS side. Maybe adding some documentation to the manual as you mentioned is good enough for now, and the API can be considered for future development if there is enough demand.

[markqvist]

Thanks @OtisByron!

Yeah, I agree it would probably just be much ado for saving two config lines. I will see to making it more visible in the manual, that this is the way to go about it.

I also think an externally accessible API for non-python programs is a good idea, but I agree it will be a bit further down the road, when and if there is demand.