Rick W. wrote: > I would have to say that your belief that there is some tone in my > message is unwarranted.
Not going to debate this. I'll just say I read your reply to someone else's question/comment first without knowing who it was and wondered what the deal was. But since you are sincere and have no agenda, we can proceed! > For the record, I did not find an explanation > of the Pilot station on the web site where one would think it would be > clearly explained and I appreciated your clearing this up. > > This is a fair question, and one we have not made a big deal about. We needed something to call the stations that committed to being available 24x7. They are not just PMBO's, or BBS's, as their intended function is more than that. (Though they serve that role as well) > I do not share the view that having multiple networks is necessarily > good if that makes things more complex (increases the potential for > failure). Again, like it or not, WL2K is the prevalent ham radio messaging system in use right now. In an emergency, there is a very high probability that the people you will need to swap email with will be on WL2K. It's also an advantage just to be able to send to a callsign, no other routing needed. Ignoring this factor isolates a new technology and makes it doomed to failure just like some of the pre-TCP-IP/SMTP mail networks. Build a bridge, interoperate, and value is added. It also makes sense to have traditional SMTP capability without depending on the WL2K network. Both for availability and independence reasons. > These networks do fail and they sometimes have long delivery > times, but the promoters tend to gloss over such information and make it > sound like there is 100% up time. There up time is very good, but > nothing is perfect. Delivery time in the modern email world is pretty quick. If you are seeing long delivery times in WL2K it has to do with how you connect. They made a design choice which makes sense for HF that add's a nuance. Your mail is not kept on every pmbo/server. It moves to the one you last connected to. Connect to a new one, and it may be a few minutes before it is sync'd there. There are valid mail store design issues involved in this approach. The design changed a bit with the implementation of the WL2K CMS's, which do tend to stay in sync, but the I believe the concept is the same. You clearly cannot keep everyone's mail on every server, you end up with a giant synchronization issue. Huge bandwidth and expense trying to keep large message stores in sync when geographically dispersed like the WL2K servers (properly) are. > If I send a message with one system and the message does not go through, > then I suppose I could try another system as an alternative. But would I > even know that there is a problem? Probably not until much later, and by > then (hours later) the message that was bottlenecked, may be finally > getting through. > If you get a message ID, the message was sent. If you did not, you can resend or try alternates. You have the same level of confirmation that you do with your traditional ISP email client. There is no guarantee that the message was delivered, just that it was accepted by the server. > You did not mention it, but isn't the main value of using the Winlink > 2000 systems is the ability to route traffic through many different > methods, primarily internet, but also VHF and HF and find the recipient > at any point in the system, even if they change location? Just like > having web based e-mail vs. fixed ISP e-mail. No other system has this > feature. > WL2K discussion tends to be very polarizing, even in this group. People tend to lump WL2K in with Pactor, when in fact one can be used and has value without the other. So I don't promote WL2K extensively as it's heavily promoted in other areas. Based on past threads, my belief is that users of this group already have an opinion formed, valid or not, about WL2K. So I don't revisit. Ham's either understand or they don't. But your point is valid, and one of the reasons we see interoperation with WL2K as critical. > He had trouble connecting but later in the day was eventually > able to do it and I received duplicate messages just short of an hour > after he sent them. Not too bad for time, although this was a one line > message. He was able to use the ARQ mode and should have been able to > send a much longer message. > There have been changes in how to use the multi-line ARQ modes for messaging. It's not a capability we have promoted widely as we are still tuning to align the tool's capabilities (PC-ALE/MARS-ALE) with the messaging needs. The challenging issue is that DBM/DTM was really designed to behave like a serial stream, even though in PC-ALE it looks like a block text transfer. So we are having to come up with an approach to delineate the end of a message, as the protocol does not allow for that intrinsically. We are not clear on whether this is an implementation issue or a protocol issue. So we are working to come up with a flexible and robust approach that meets the needs. > I also tried to connect with several of the Pilot stations, but no luck > so far. I have been able to do this in the past. I sincerely believe > that it is vital to have many available stations so that you have > redundant NVIS coverage as well as longer skywave propagation for those > more isolated areas or due to conditions at that moment. Otherwise you > wind up being like existing systems which could be very difficult to > connect to when you need HF connectivity. Especially if you have an > emergency station operating on lower power with mediocre antennas! Most of the pilot stations are heavy on NVIS capability. All are active and accessible on the lower bands, though some (like mine) are not optimal on 75m. I will say a few things: - It's HF radio and we are in the depth of the sunspot cycle. There are times even the most mature and widely deployed systems are challenged by this - If you do a scanning netcall for HFN within N America, there is a very high probability that you will make a link, either on skywave, nvis, or groundwave. May not be the station you thought it would be, but at any given time/condition most of us have connectivity to an HFN station as needed. Why should a user have to know who is on and in range? Netcalls are a huge advantage - I run ALE Mobile and portable quite a bit. The geographic distribution combined with the all band approach really increases the odds of a link > Many of us are surely impressed with the tremendous dedication it takes > to set up and maintain a 24/7 operation. What is neat is that we essentially have a waiting list for N America. From a network design perspective too many is worse than not enough, so we have intentionally not over saturated certain areas. We will need to revisit this as time passes, but for now the goal is to provide the right coverage, not just raw numbers. > tremendous advantage that HFLink has is the sound card access and > Winlink 2000 does not. It is that simple. They do not compete since HF > Winlink 2000 is simply not available to 99% of hams and HFLink is > available to at least a few percent which would include nearly all of us > on a group such as this one that has radio amateurs who are interested > in digital modes, even if not necessarily emergency use today (but there > is always tomorrow:) You have identified one of the main goals of hflink. There is a group of users who will/can not use Pactor 2/3, but will/can use a soundcard based mode. It's a win for all if we can fill that need. Which also includes using off the shelf HW radios, no PC/soundcard needed. Which is another need. Add to it the capabilities of scanning netcalls on all bands. From a sel-call perspective this makes tremendous sense. Key players have multiple times seen this as an area that WL2K operations could leverage, but they have another approach and have declined. But we keep the communication channels open, and this may change over time. Certain federal users certainly recognize the value in this capability and see this as a gap that the WL2K ops should fill. Finally, you also have the infrastructure now in place to assemble net's on demand, whether digital or voice. > I knew that you were planning to go to a full blown e-mail messaging > system, but either this has not been promoted by your group (which seems > unlikely) or I completely missed it. I am not sure how you use these > different modes: AMD, DTM, and DBM, or why, but is this automatically > done when you connect depending upon the size of the message and whether > you have certain kinds of software? Same command structure whether sent by AMD or DBM. We are working the issue of termination of multi-line message now, and have a workable scheme in place now. (Terminate with /EX twice on separate lines) It's not the final scheme, just one we are trying. It would be easy to change the protocol to make it do what we want, but then we are non-standard and fall short on a couple of our design objectives. So we are trying to stay MIL-STD. > I have standardized on Multipsk for > any ALE/FAE operation. Does this software work transparently to set up > the correct modes? I have not used the latest Multi-PSK with DBM yet, so cannot speak to that. I am very hopeful that it interoperates well with mars-ale/pc-ale, as that would really add a viable option. Implementing DBM/DTM can be quite challenging. Steve and Charles have spent lot's of time there, and it appears that PC-ALE/MARS-ALE may be viewed as compliant to the mil-spec standard. Not all the HW radio/controllers are so, if they implement at all. So Kudo's to Patrick if he has been able to implement a std DBM ARQ, as that is a significant addition to multi-psk and one of the most needed areas. This is something I'll be testing shortly. ALE400 is not an area that I've spent much time in. FAE certainly has some advantage, but since it's a different tone approach we cannot interoperate with HFLink/ALE ops. (IE: On the HFLink freqs) I would very much like to understand the mailbox mode in multi-psk. Messaging in the ALE world is very batch oriented, with commands, etc. We build on the BBS heritage inside WL2K, and also how SMTP works. APRSlink does similar, though developed independently. The hooks/placeholders are present inside PC-ALE/MARS-ALE for full SMTP transparent access inside the STANAG protocols, but for now it's more important to integrate the wide base of diverse (PC-ALE, Multi-PSK, HW ALE Radio, HW ALE controllers) than it is to push yet another (effectively) single source mode/protocol. Have fun, Alan km4ba / afa2ns
