We had a county wide Winlink Packet Peer to Peer (P2P) drill today (see PDFs of the drill instructions attached) which I was able to check in with easily using my Kenwood TM-D710A and Winlink Express from my radio room at home and with my laptop while in my vehicle with a similar setup. I had anticipated being able to use my Kenwood D75A and RadioMail to check in also from the field mobile on foot with my iphone but when in the field I could not figure out how to do this with the RadioMail app and BB link adapter. Exercises like this are useful in showing you that you can't do something that you assumed you could easily do. I just got home to do a little searching from my desktop computer as part of the after action debrief and couldn't find out how to do this either. Am I missing something? I looked on this forum and the documentation links that I could find and the RadioMail product road map and it appears on the road map that peer to peer receive has been placed in the graveyard. Peer to peer is a very valuable mode for emcomm and persons with limited equipment in areas where RMS gateways are challenging to access. Emcomm groups like ours in Southern California rely on peer to peer as gateways are often tough to access due to the hilly terrain. ARES, RACES and USCG all use P2P as a standard operating mode. Sometimes the internet is out or one of the gateways is down or the terrain blocks access to line of sight. A group of hikers with P2P capability could use P2P to relay a critical message down the trail with HTs. A pair of persons hiking or persons aboard a boat with minimal equipment could exchange messages very easily if this was enabled. I would want especially the ability to do relays with P2P. Maybe I don't know where to look in the app or online but I can't find how to send a simple message from one station to another peer to peer with no other infrastructure in between or do a relay like this. I could not complete the exercise attached with my HT on foot in a location where I potentially could have relayed a P2P message in. Am I missing this somewhere as I thought this mode of operation would be a basic one. I spent about an hour searching and couldn't find how to do this. Any comments or help would be greatly appreciated!
Sincerely,
Anthony Mascola
KJ6OKV
I'd love to be able simply to send a message back and forth to my kids P2P if we had our handhelds in the field and our phones or do a demo for the scouts with this. They would get a kick out of it and would enjoy doing this on backpacks or campouts. Simple communications with minimal infrastructure would be a fun feature for RadioMail if it is not supported. If it is if someone could send me the instructions on how to do this I would really appreciate it!
I got a couple of very nice messages back channel to help me configure the BB link and iphone and radiomail and I want to confirm that I know that my hardware and software are all working together as I am able to hit regular RMS gateways and send and receive email fine with RadioMail - as long as I send it via a gateway. I have found RadioMail and my iphone to be very liberating as it is so portable but was surprised today that I couldn't operate peer to peer with this. Peer to Peer is useful and necessary when you can't reach the Winlink RMS gateways. That mode in particular is the one I can't figure out how to do. If we could figure this out I think a lot of persons would really benefit and enjoy this.
Certainly peer-to-peer is attractive when infrastructure is unavailable or unreachable.
RadioMail supports connecting to another station in a peer-to-peer fashion. However, other stations can’t connect to you because it’s impractical to do this on a phone. A server must run, listen for incoming connections, and maintain a connection to the radio. This requires an operator to actively set the application in that mode and monitor it or a mechanism for the “incoming server” to run in the background, which are subject to restrictions and can be killed by iOS if they consume too many resources, mostly due to battery drain.
So, while it would be a fun experiment, practical use is likely limited.
To initiate a P2P connection to another station, there are two main components:
1) Add the peer station to your directory, so you provide its callsign, frequency, and mode.
2) When composing a message, expand the message header and mark it as “Deliver only when peer-to-peer.” This ensures that the message is only delivered when you connect to a station with the same callsign as the recipient and prevents it from having an Internet address as a recipient.
After that, you can initiate a connection to that peer station.
Thank you Georges for such a wonderful application and the BB link. I am really enjoying the freedom of having a powerful communications tool that pairs with my HT in my pocket like this! You have done great work!
In response to your message:
1. Would it be possible to put RadioMail in a peer to peer receive mode for a very brief period of time so that messages could be received P2P and the phone would then revert back to a power conserving mode?
2. I did attempt to initiate a P2P connection to the drill station KM6RTE in the fashion you described in your message to do P2P but I was too far away from it to hit it directly. I was able to hit another station KF6BRC-10 from my location so I attempted to reach KM6RTE via relay station KF6BRC-10. I was able to configure the relay in RadioMail and could confirm that I could connect to the relay which in turn connected successfully to KM6RTE. The message was formatted to "deliver only when peer to peer" the handshake occurred between the three stations but the message was not sent. The session closed and the message remained in my outbox undelivered. Can you send peer to peer via a relay? One or two are likely to be needed from the handheld due to the antenna constraints...
Note that I have exchanged messages P2P in the field between stations using HTs for the transceivers which are running Winlink Express on laptops / tablets many times. I am hoping to ditch the need to have the laptop or tablet. A roll up J Pole in the field can be looped over a tree and one can have a decent station in the backcountry like the above. I am hoping this can be extended further to use just an HT, a smartphone and a small USB power bank battery pack. If the software could be used transiently in P2P mode if one does not have a battery pack available or for a longer duration if a battery was available it would be very nice as it would be much lighter, more compact and consume even less power than the tablet/laptop station.
I'll have to double check the P2P with Digipeater scenario you're describing as I don't think I tested it personally. As far as I know it should work because the digipeater works at the AX.25 layer and the Winlink session is above that.
WRT to temporary setting RadioMail to receive incoming connection, it's possible but requires quite a bit of work to get there and work for all the modes and radio type of connections. Maybe something to reconsider in the future but not super high on the list to be frank.
Thank you Georges. Let me know if there is something else that I can do differently to send P2P via RadioMail with a relay as this mode is expected in Southern California for emcomm and mobile operators in the field with an HT rather than a sit down station could really make use of this.
Regarding P2P receive I am sorry to hear that it is more involved. I am sure that this project keeps you very busy. Please know that we are very grateful for your work. RadioMail is very useful and fun. Not sure if there are any other programs anyone is aware of other than APRS.fi that allow exchanges of text messages between HTs or other stations on foot in the field and other stations. I run both FLDigi and Winlink express on my D710a and TS-590sg desktop stations and am trying to find similar digital synchronous and asynchronous messaging functionality in the mobile handheld arena.
If not, perhaps a mode like P2P receive in RadioMail could be run when manually initiated by the receiving operator and after nothing heard for a period of time move to a less power consuming dormant mode and “wake up” the rest of the process again only when a packet is received and the squelch opens. By the time the packet is re-sent the decoder might be online in time to read on the 2nd packet and decide if the traffic is relevant and either remain awake and decode or go back to sleep if the packet is not addressed to that particular station’s call sign.