Re: [digitalradio] ALE400 and 141a messaging
Based on what I know, for SMTP, JNOS may be an option at less than 300 baud, i.e., 100-110 baud or PAX, using MultiPSK as soundcard modem. I have not tested any of it yet. I have had no time and possibilities to test it so far. JNOS can use FBB compression or LZW compressed SMTP on any of its radio ports using KISS protocol to connect to a TNC. I ran both FBB and JNOS simultaneously for several years sharing the same TNC under MSDOS and Linux, and HF mail using compressed FBB protocol or LZW compressed SMTP worked, even when painfully slow, at 300 baud on a shared forwarding frequency. Even FTP worked (I do not remember if it could be compressed as well) on HF. It is not theoretical. JNOS networking works on HF with the known 300 baud weaknesses. How well does it work really matters when nothing else is available? Certainly, that may be an option in an unconnected scenario. I have also read some papers (which are not recent ones) mentioning the possibility of using JNOS for armed forces communications. I believe it should be tried out. Configuring JNOS is not easy, it is command line oriented and learning its options is a steep process not suited for the faint of heart, because along its history, it has been developed and maintained by people familiar with Unix, networking and text mode consoles in a spartan command line environment. Working options may be saved in a configuration file that it reads at the start up. One almost miraculous option it has is the maxwait parameter. It limits the usual TCPIP exponential backoff to a value of your choice (not arbitrary, it basically depends on the signalling speed and channel reliability or congestion), indispensable when running TCPIP on a radio link and not on a high speed, less noisy, wired environment. Other TCPIP implementations fail without this kludge, particularly, on HF radio. Even Linux with its native TCPIP stack is subject to fail as well. JNOS packet stack is better crafted than the Linux AX.25 support. Alan is right, maybe a kludge between an AX.25 stack and other modes could be devised, but it is not simple. If other sound card modes work at the same speed, why wouldn't PAX or slow packet work? APRS has been tested so far with slower than 300 baud speeds and has worked, even with the nowadays prevalent bad HF propagation. Frugality in message content is *INDISPENSABLE*. Compression is your friend. In a bandwidth limited radio channel, concise, short, text messages are preferable to more voluminous file formats (.doc, .xls, .bmp, etc). If that is not acceptable, then, who needs that should procure a wideband VSAT link. 73, Jose, CO2JA --- John Bradley wrote: What would be our non VHF options? John VE5MU VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energética sustentable www.ciercuba.com
Re: [digitalradio] ALE400 and 141a messaging
John Bradley wrote: ARES has responded with a command unit which has HF data capability. This could include a WIFI router so that laptops could be included from the local EOC. This command unit would work back into an EOC with data and internet connections. ARES would be tasked with passing text messages, destined both for the EOC and to other outside agencies and base hospitals. WL2K is an option , other SMTP sound card modes. at higher speeds would also work, such as RFSM8000. What would be our non VHF options? Several answers: 1) It's going to sound like Heresy, but paclink, airmail, and WL2K is specifically designed for your scenario, works now, and with an SCS P3 modem (expensive proprietary as it is) is very hard to beat. Essentially an off the shelf solution. Laptops, wireless, auto gateway to HF, and to the target recipient over the HF Horizon. But there are many who cannot or don't want to play SCS P3 modem. Which leads to: 2) Your command unit HF control operator (you have one, don't you) takes the traffic aggregated by the jnos or linux box, and initiates into the HFLink system using ALE. Can send direct to an SMTP address, or into the WL2K system. Yep, it's a manual cut paste right now into pc-ale on the sending end, but it works. And there are some who say all traffic should be hand entered. (I'm not one of them). PC-ALE has hooks for drop box type operation, and we have had plans for similar in marsale. I'm sure this won't satisfy you, but having an HF drop box (in any) program does not address the local (command unit) end of the handoff. HFLink.net already delivers message traffic via HF from multiple HW radios + the ALE variants. Not perfect, I have a nasty bug to chase down which impacts some multi-line DBM messages, but we are headed there. 3) So you want to bridge two sites not using the internet? Same deal. There is no restriction that bbslink has to run on the Internet. You can run it on the local lan in your two command vans. SMTP is SMTP. Your JNOS instance coresident with bbslink does the handoff/gateway to your laptops. 4) You dis single line messages quite frequently, but there is lot's of traffic flying around on APRS. Same concept with ALE AMD's, and we look to allow interoperation between the two. AMD's get through when other stuff does not. Nope, it won't be the proverbial my served agency wants to send a 600k powerpoint, nothing else is acceptable solution, but about a zillion 170 character SMS messages are sent in the cellular system each month. Yep, 90% are kids, but it's a useful medium even with restrictions. Nothing in your scenario justifies creating (yet another) ham focused messaging layer. Between existing JNOS/FBB/WL2K systems plus native SMTP handoff, ALE/BBSLink can pass traffic in pretty much any scenario. Again, PC-ALE has rudimentary message box buried in it, but we've focused our efforts in other directions. Taking ownership of a message for future delivery is a serious commitment. Tools like JNOS, and linux postfix type systems are far better at implementing the rules, retries, etc. HF should just be transport. What I have spent some design time on is how you could have marsale be an outbound transport to a sendmail/postfix system. (And possibly JNOS) But it would still be transport only, a plugin used instead of SMTP based on rules in the mail system config. It succeeds, or fails. No in-between. No store forward on the ALE/bbslink side. JNOS is an old friend. I was compiling, tweaking, and using Phil Karn's KA9Q, and then later, NOS back in the early 80's, and used it as a 56k packet gateway from my pc workstation lan starting in '85. There might even be some of my code/comments buried in there, I'd have to look. It's the swiss army knife of amateur messaging. If I were to try to implement an auto forward outbound gateway into the ALE BBSLink system I'd probably leverage JNOS to aggregate hand off. But I have been down the path of trying to make transparent TNC replacement plug-in using KISS. Lot's of session/link decisions would have to be made, each with tradeoffs. It's not just connect the dots. Not impossible, just analysis design. If winmor goes into production that may be another alternative. But you still have to do the session stuff. KISS just sends bytes, initiates connects, and detects connections. So whether f6fbb, winlink, or whatever, that has to be addressed. Have fun, Alan km4ba
RE: [digitalradio] ALE400 and 141a messaging
You are right in that the likely solution would be SCS and Pactor3. The only other thing that we have tried is RFSM8000, developed by Dimitri , which has a email gateway built into it, is ARQ and runs on soundcard Nobody in the US is using this on the ham bands at least since it does not conform to FCC rules as far as speed etc. I don't know if he is still actively developing the software but what we had worked well but required a pretty strong signal to work, since the bandwidth is about 3Khz I am sending a copy of this to Dimitri to see if he is around still. I make no apologies for dissing 1 line messages... sure I use SMS myself regularly for quick questions among family members and friends, but to pretend that this is a meaningful solution for emergency comms is just plain crazy. It's fun to use but not much beyond that. If I were sending this message from an area in Canada out of range of any internet access short of Sat phone, I couldn't get past the first line. I don't know about the USA, but a number of emergency agencies in other countries are revisiting HF backup systems for point to point data, since recent infrastructure failures have proven that our everyday systems are very vulnerable. Those involved with health and bioterrorism are particularly interested.. a number of health agencies and Canada's version of the Center for Disease Control have HF abilities already. In fact CDC in Atlanta has HF ALE has a place in all this to establish links and determine the most useable frequencies, But software like 141A or ALE400 are far more useful for passing data than the one-liners in PCALE. Now if it had a better interface to the internet other than a copy and paste routine, so much the better. I get very frustrated with those who still regard ARES contribution to emergency comms as tactical voice on VHF or HF. We have that role.am currently writing an exercise which would use hams as back-up in ambulances and EMS dispatch over a wide area of rural hospitals and small town EMS units. I also am frustrated since slowly but surely we are being forced into Pactor 3 as the only viable and expensive option for what we need . John VE5MU Change http://groups.yahoo.com/group/digitalradio/join;_ylc=X3oDMTJmcGl1MHZrBF9TAz k3MzU5NzE0BGdycElkAzE4NzExODMEZ3Jwc3BJZAMxNzA1MDYzMTA4BHNlYwNmdHIEc2xrA3N0bm dzBHN0aW1lAzEyMzM0NTQ5MTg- settings via the Web (Yahoo! ID required) Change settings via email: Switch mailto:digitalradio-dig...@yahoogroups.com?subject=email%20delivery:%20Dige st delivery to Daily Digest | Switch mailto:digitalradio-traditio...@yahoogroups.com?subject=change%20delivery%2 0Format:%20Traditional format to Traditional Visit http://groups.yahoo.com/group/digitalradio;_ylc=X3oDMTJkc2szZmJjBF9TAzk3MzU 5NzE0BGdycElkAzE4NzExODMEZ3Jwc3BJZAMxNzA1MDYzMTA4BHNlYwNmdHIEc2xrA2hwZgRzdGl tZQMxMjMzNDU0OTE4 Your Group | Yahoo! Groups http://docs.yahoo.com/info/terms/ Terms of Use | Unsubscribe mailto:digitalradio-unsubscr...@yahoogroups.com?subject= Recent Activity . 7 New http://groups.yahoo.com/group/digitalradio/members;_ylc=X3oDMTJmODQyaDVkBF9 TAzk3MzU5NzE0BGdycElkAzE4NzExODMEZ3Jwc3BJZAMxNzA1MDYzMTA4BHNlYwN2dGwEc2xrA3Z tYnJzBHN0aW1lAzEyMzM0NTQ5MTg- Members . 1 New http://groups.yahoo.com/group/digitalradio/files;_ylc=X3oDMTJnYjRpZm0xBF9TA zk3MzU5NzE0BGdycElkAzE4NzExODMEZ3Jwc3BJZAMxNzA1MDYzMTA4BHNlYwN2dGwEc2xrA3Zma WxlcwRzdGltZQMxMjMzNDU0OTE4 Files Visit http://groups.yahoo.com/group/digitalradio;_ylc=X3oDMTJlNTEzbjFxBF9TAzk3MzU 5NzE0BGdycElkAzE4NzExODMEZ3Jwc3BJZAMxNzA1MDYzMTA4BHNlYwN2dGwEc2xrA3ZnaHAEc3R pbWUDMTIzMzQ1NDkxOA-- Your Group Drive Traffic Sponsored http://us.ard.yahoo.com/SIG=13oqb6f0b/M=493064.12016255.12445662.8674578/D= groups/S=1705063108:NC/Y=YAHOO/EXP=1233462119/L=/B=1K2CNEPDhFQ-/J=1233454919 349769/A=4025338/R=0/SIG=12jnci1fd/*http:/us.rd.yahoo.com/evt=44092/*http:/s earchmarketing.yahoo.com/srch/index.php Search can help increase your site traffic. Yahoo! Groups Join http://us.ard.yahoo.com/SIG=13on793t9/M=493064.12662708.12980600.8674578/D= groups/S=1705063108:NC/Y=YAHOO/EXP=1233462119/L=/B=1a2CNEPDhFQ-/J=1233454919 349769/A=5349276/R=0/SIG=11nhsqmjq/*http:/advision.webevents.yahoo.com/Every dayWellness/ people over 40 who are finding ways to stay in shape. Y! Groups blog The http://us.ard.yahoo.com/SIG=13ou8g634/M=493064.12016258.12582637.8674578/D= groups/S=1705063108:NC/Y=YAHOO/EXP=1233462119/L=/B=1q2CNEPDhFQ-/J=1233454919 349769/A=5191953/R=0/SIG=112mhte3e/*http:/www.ygroupsblog.com/blog/ place to go to stay informed on Groups news! . http://geo.yahoo.com/serv?s=97359714/grpId=1871183/grpspId=1705063108/msgId =29840/stime=1233454918/nc1=4025338/nc2=5349276/nc3=5191953
Re: [digitalradio] ALE400 and 141a messaging
Alan Barrow wrote: Yes, I understand it works. FBB works OK on HF because once you are logged in, it's not that interactive. But you still have 2-3 turnarounds before you send the initial message, etc. FBB protocol has a feature I find very valuable: the Z-modem style resume. JNOS had not achieved that until 1.11g or so... about the last I used seriously. Buried inside the P3 WL2K pactor transfers is a basic F6FBB chat login. Yes, I have been able to login to WL2K from FBB using P2 or P3. Typically 5-10 seconds to link, get logged in, and sync prior to really transferring the messages. Again, it works, lot's of messaging sent this way. But a bit wasteful. Why are you logging in when the system already knows who is sending it via your callsign? And you just sent the password in the clear on hf, so why bother? Login's are wasteful on HF. Lot's of analysis discussion in this area as well. That is interesting. I had (and lost) an archive collection of the early decisions in packet and BBS's. I learned a lot from that (and have forgotten many fine details as well). Real answer is a public/private key system. Anything else is wasted time bandwidth. Adds no security, and reduces reliability. I used the JNOS MD5 challenge/response logins. Otherwise, it was false security with clear passwords flying on the air. I am not too familiar with the public/private key systems. SMTP over HF is much less efficient reliable because it has many, many turnarounds. It is true. But JNOS LZW compressed SMTP fared fairly well in comparison. It's designed for a lan with infinite signal to noise ratio. :-) short packets, many turnarounds. With more overhead in the TCP/IP header than in the data sent. So in the commercial military systems, you see TCP/IP spoofing. Eat, then recreate the IP headers on the opposite end. Same for SMTP. I have never seen that in the ham world. Sounds interesting. (just like the trailblazer modems did with UUCP in the old unix days) I lived that... So how do you deal with this using the tools you have? With BBSLink we use an FBB command structure, but compress the initiation of sending the message into a single file transfer. IE: the command, user ID, etc is prepended to the message and processed by bbslink. So no login chat over the air, retries, etc. With HF, you only get so many seconds of decent S/N at times. You don't want to waste half of your window getting logged in using a system oriented for interactive users. Certainly. But there is a catch. I have *SUFFERED* receiving a queue where the most important mail is not the one I get first. A tricky condition that may prove nasty in an emergency. Perhaps it could be handy to be offered a set of headers/message sizes to choose. Routinely, it should not be necessary, but could be invoked if needed. Something to think about. I am not too familiar with WL2K beyond being a user. If the message is short enough, it's a single send, then ack back from the receiving system. Longer messages do have an ack before the next frame is sent, etc. DBM is not perfect, but works, and is a true WW standard. (for as much as that means... F6FBB is also a defacto standard but there are very many implementation differences in login specifics, etc when talking to them programatically.) We'd like to see other protocols like FAE, etc leveragable as well. So could you make JNOS/MSYS work over HF with a kiss modem? Most likely. Is that the best way? I think we can do better if we apply ourselves work together. JNOS is certainly a useful tool in the mix. I have had a good experience with FBB and JNOS and feel that the networking part worked in a fairly decent way. I used MSYS very little and liked FBB a lot, I felt it led the race in the early 90's. I am aware that the limit was not the networking part, but some sublayers in layer 1. I did quite a bit of FBB forwarding using my PTC-II and it worked wonderfully, with the same radio and using a lot less power. At least 10 times better on the average, thruput-wise. Maybe there is some room for improvement left, but nevertheless, I don't feel that the wheel has to be reinvented. Maybe just use more suitable tires, or better roller bearings, but reusing what has been proven to work. If the best known is not affordable, don't quit, and use another acceptable alternative. The worst is havin no comms at all. I dared to answer John because if networking and HF are an important terms in the equation I would rather use what I know that somehow works and not wait until a perfect solution shows up. It will eventually show up. Fortunately for us, there are people that strive to find better solutions for working systems. The best is, as far as I know, a SCS pactor controller. But slow packet or PAX could be workable solutions for HF. Would other modes capable of passing a full ASCII alphabet (8 bit words) work instead of a modem whistling
