Serial connection

[SunSayIsCool]

Is it possible to make pli and chat exchange via bluetooth serial port without using meshtastic, only serial exchange?

[paulmandal]

Hey can you clarify whether you mean USB serial here? I'm not sure what Bluetooth serial is -- Meshtastic uses Bluetooth Low Power (i think?) by default to connect to phone devices.

You can connect to the phone via USB with a USB On-the-Go connector and the plugin supports this kind of connection.

[SunSayIsCool]

I have radios with bluetooth serial port. So is it possible to use your plugin for sending and receiving cots through serial connection without using meshtastic devices?

[paulmandal]

Ah I understand now, this is not currently supported.

Which radios are you using? If I can pick some up I might be able to add support in the future.

[SunSayIsCool]

I use mototrbo dp4801. They also have UDP/IP support but atak's message too big for it, messages and pli not always reach destination EUDs

[adrianpike]

I'd also love this capability in the atak-forwarder plugin - I've got a pair of tnc3's, and am currently using a workable setup of an RPi to do UDP bridging, but it's finicky, complicated, and doesn't get to share any of the cotshrink previous work here. If the plugin could interface directly w/a KISS bluetooth serial device, I could pull the whole Pi bridge out of the chain and have a much better experience.

[paulmandal]

Ok this might be as simple as having a menu option to pick a serial port and having the plugin send every broadcast CoT to that port / listen to incoming from that port. I probably won't be able to work on this for a month or so because of my work obligations but it is technically possible. If someone else wants to give it a try check out the MeshSender class that interfaces with Meshtastic. Might be able to make a SerialSender class that does the same sort of thing and a SerialReceiver class for the other end. the CommandQueueWorker would also need to be modified to send to both MeshSender and SerialSender.

I am looking to make some of these mods to support DigiMesh but again probably not for a month or two.

[SunSayIsCool]

Hi. Can you add usb-cdc support for atak forwarder? I have some radios with usb interface and they can send serial data over usb. Or separate version for serial exchange only?

[e1ferapontov]

I use mototrbo dp4801. They also have UDP/IP support but atak's message too big for it, messages and pli not always reach destination EUDs

Could you please elaborate on that one? I too have dp4801 and never knew it could act like a Bluetooth TNC/udp gateway

[paulmandal]

Can anyone in this thread recommend cheap hardware that I can develop my code with?

[SunSayIsCool]

I think you can use basic Lora module or serial bluetooth. Or 2 usb to com connected via cable.

[tim292stro]

This will be a tangent, but I've been playing with an RPi Zero as a COT router. Keeps most of the stuff out of ATAK, but still using the libcotshrink library on the Pi. RaspberryPi Zero W (and just picked up a few Zero 2W), acts as a USB OTG Ethernet gadget for the phone (operating in airplane mode, basically only a display device). ATAK connects to the RPi over Ethernet without any modification to ATAK (I initially did this because of the plugin not working with the new version of ATAK, I wanted to decouple it).

Routing is being done in the RPi using the least-cost methodology, Wifi mesh (via B.A.T.M.A.N.) is the cheapest/highest-throughput, a LoRa module (Ebyte E32-915T30S 1W) is the mid-cost/medium-throughput, and finally an Iridium 9603N SBD modem is the highest cost/lowest-throughput. The bandwidth degrades when WiFi mesh is not available and causes the COT messages to be run through libcotshrink. Based on type of message, I choose to filter even more when LoRa/Meshtastic is not available to reduce the bursts on Iridium (not cheap at all).

It seemed to me to be a high burden to put all of the decision making into ATAK, and the system design was very use-specific, more so I thought than I wanted to subject Paul to at least. Since I'm running the Mehtastic protocol on the RPi for the LoRa radio, it's still compatible with vanilla implementations of the ATAK Forwarder+Meshtastic, but I get the bonus of remote sensor video and data packages when on WiFi mesh and any COT exchange when on B.L.O.S. Iridium.

I've also been toying with some legacy 915MHz ISM Ubiquity cards to attempt a longer range WiFi degradation (1-2MHz channels vs up to 160MHz channels) before fall-back to LoRa, but I have to built a base-board for a RPi CM4 so that I can adapt Mini-PCI card to that with a PCIe bridge. Given the power demand for all of that additional hardware, those nodes will be routers+vehicle only.

I kind of see a hierarchy depending on the size of deployment:

1. Server+Iridium
2. Fixed Router+Cellular+915MHzWiFiMesh+2.4MHzWiFiMesh+LoRa (<-- intended for permanent remote installations only)
3. Mobile Router+Cellular+915MHzWiFiMesh+2.4MHzWiFiMesh+LoRa+Iridium (<-- Vehicle Borne)
4. Fixed/Portable Restock/Rally-Point Comms Box 915MHzWiFiMesh+2.4MHzWiFiMesh+LoRa+Iridium (bigger battery, probably solar recharge - could be air-dropped)
5. Mobile Unit Comms Guy 915MHzWiFiMesh+2.4MHzWiFiMesh+LoRa+Iridium (bigger battery)
6. Mobile Team Comms Guy 2.4MHzWiFiMesh+LoRa
7. Individual Team Member LoRa-only
8. Tracking an item, simple remote control device or sensor, Meshtastic LoRa device only no ATAK head

Point of this tangent is, there is more than one way to skin a cat, and the Forwarder plugin might get a bit messy and harder to maintain if it has to wear too many hats and convert too many protocols. Simple Serial Stream Out of COT-XML with selectable libcotshrink reduction is probably as far as I'd advocate pushing Forwarder.

After all it's forwarding, not doing all the work.

[314analytics]

I just want to second the sentiment that @tim292stro expressed about the most straightforward path being where atak-forwarder is a forwarder to a single common standard rather than a jack-of-all-trades converter/adapter to a myriad of protocols and interfaces.

In my opinion, the root source of the difficulty is that ATAK is an implementation nightmare... in many senses.

One of these difficulties is associated with trying to use ATAK with anything other than a cloud-connected high-bandwidth Wi-Fi connection or a cellular data plan.

Even the tim292stro suggested notion of using USB Ethernet is replete with gotchas and potential problems. Android is simply not designed to have multiple non-cellular network connections. Many Android devices don't even have USB Ethernet drivers included in their Linux kernel, and even if they do have the right compatible ones (RNDIS, CDC-ECM, CDC-NCM, and CDC-EEM just to name a few industry-standard variants... never mind the proprietary ones from ASIX and others popular with physical USB Ethernet adapters), the Android API can't fathom the possibility of having two (non-cellular) network connections where one connection for the "Internet"/"cloud" and the other for talking to ATAK and there are all sort of weird behavioral issues. (The Google authors of the Android API have provided for choosing between cellular data vs Wi-Fi, but that is all.)

So, many ATAK users who want to use ATAK without Wi-Fi access points nearby or cellular data (the two Android network options) are stuck. Thankfully, this is a path blazed by @paulmandal, which is a great thing, but it also makes atak-forwarder a lightning rod for everyone else who would like to follow in those footsteps.

This leads to the second major difficulty with ATAK, IMHO. Look at all the mid-2022 issues with atak-forwarder not being able to interoperate with the Play Store ATAK, and this is with a comparatively mainstream ATAK plugin. I don't think it is malice on the ATAK developers' part per se; it is just that their plug-in architecture is an utter nightmare to use and they seem indifferent to making it any easier.

Consider that a developer has to manage to compile ATAK with private keys before they can ever hope to compile the atak-forwarder code. Even if they manage to compile atak-forwarder after this, find the seemingly unfindable "CommHardware" interface mentioned in README.md, and then modify the source code to talk to something else, they only have bespoke ATAK and atak-forwarder apps that can only be side-loaded on a limited number of devices. Furthermore, each time the ATAK developers update their source code, the process has to begin all over again.

The communications API between atak-forwarder and Meshtastic-Android is nowhere near as rigid and fragile as the one between ATAK and its plugins. It seems that one can mix and match atak-forwarder and Meshtastic-Android versions without everything breaking.

Given this, would there any hope that there could be a atak-forwarder that just did CoT/chat exfiltration and infiltration, both with (optional?) libcotshrink, to user-chooseable companion app? If there were a standard inter-app API to send and receive these messages and a companion 'Hello, world' sample app to do the interfacing to the transmitter and receiver, such a companion app (whether it were Meshtastic-android or other custom one implementing whatever interface is needed) could encapulate these messages into whatever protocol as needed. The major advantage I see of this approach is that the developer only has to modify the companion app, not an entire spectrum of apps from ATAK onwards.

Aside: for what it is worth, I've prototyped the approach of emulating a USB Meshtastic-device as a way to side-step the ATAK plugin nightmare. (ATAK -> atak-fowarder -> Meshtastic-Android -> custom-Meshtastic-device) It does function, but I should warn you that with the Meshtastic developers controlling both Meshtastic-Android and Meshtastic-device, it is all too easy for them to change things frequently and so the USB serial protocol (and protobufs) are in constant flux (particular with v1.3 in development).

A third major difficulty with ATAK is its total lack of cybersecurity. The cellular data, Wi-Fi, and (sometimes feasible) USB Ethernet interfaces all have no security. The app comes with all network ports open, and some of these vulnerabilities cannot be disabled as they are hard-coded into the source code. (IMHO, this gives further reason to NOT use ATAK with these interfaces. If I had my way, all the ATAK network interface code for CoT/TAK servers, external GPS adapters, their TAK mesh protocol, etc. would be moved out of the app and into plugins so that said plugins could be disabled and removed for added cybersecurity.)

However, for anyone just trying to get data into and out of ATAK for test purposes, here are some options that worked for me and might bear fruit:

1) If you need to both send CoT to ATAK and get CoT back from ATAK: set up a private CoT/TAK server (this, I believe, is what tim292stro is doing) accessible via Wi-Fi or USB Ethernet. ATAK sends CoT messages up to the server via a TCP socket, and it acts upon CoT messages that are sent back from the server (via the same TCP socket). I have ANSI C source code for a bare-bones "TAK server" that accepts CoT messages here.

2) If all you want to do is send CoT messages to ATAK: figure out what the IP address is of the Android device, open a TCP socket on port 4242 of that IP address, and write the CoT message, and close the socket. You can repeat this as often as needed. A quick and dirty ANSI C example of this is here.