Re: [digitalradio] ALE400 and 141a messaging

[Jose A. Amador]

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 alp

RE: [digitalradio] ALE400 and 141a messaging

[John Bradley]

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
  settings via the Web (Yahoo! ID required) 
Change settings via email: Switch
  delivery to Daily Digest | Switch
  format to Traditional 
Visit
  Your Group | Yahoo! Groups
  Terms of Use | Unsubscribe
 

Recent Activity

.  7

New
  Members

.  1

New
  Files

Visit
  Your Group 

Drive Traffic

Sponsored
  Search

can help increase

your site traffic.

Yahoo! Groups

Join
  people over 40

who are finding ways

to stay in shape.

Y! Groups blog

The
  place
to go

to stay informed

on Groups news!

.

 
 
 

Re: [digitalradio] ALE400 and 141a messaging

[Alan Barrow]

Jose A. Amador wrote:
> 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.
>   
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.

Buried inside the P3 WL2K pactor transfers is a basic F6FBB chat &
login. 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.
Real answer is a public/private key system. Anything else is wasted time
& bandwidth. Adds no security, and reduces reliability.

SMTP over HF is much less efficient & reliable because it has many, many
turnarounds. 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. (just
like the trailblazer modems did with UUCP in the old unix days)

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.

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 know of
unix systems still using JNOS as transport. :-) If we scratched deep
enough we'd find some in use on corporate routers.

Have fun!

Alan
km4ba

Re: [digitalradio] ALE400 and 141a messaging

[Alan Barrow]

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

[Jose A. Amador]

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

[Alan Barrow]

Jose A. Amador wrote:
> I almost always used JNOS with KISS interfaces, it is a natural way of 
> using it. TNC's under MSDOS, and also thru pipes under Linux with 
> net2kiss (I would have to go back to the manual to remember a few 
> details). It could be interfaced with the BPQ switch, so FBB, JNOS, the 
> BPQ switch could share the same KISS TNC.
>   

Lot's of discussion, planning, and work has gone on in this area in the
ALE space.

The short version is with AX.25 packet, the session & link layers are
already taken care of. KISS is just a way to communicate with the TNC
and assumes the existence of AX.25 type link layers.

With other HF protocols those layers sometimes have equivalents, but not
defined as such and never in a form that can be directly leveraged in JNOS.

Even devices like the SCS P3 modems have had to bridge this gap with
supplementary commands, etc.

So you can't just implement a KISS interface and magically have a new
mode working with JNOS.

I still think KISS is the right approach for portability, but there is
lot's of design work needed to add the additional layers.

Same for "we'll just use TCP/IP" way too much overhead in the
protocol, and it does not respond well to HF reality. Timing and retries
just will not work on HF. lot's of mil/gov research in this area. SMTP
is very "chatty", with almost a dozen back & forth exchanges to send a
message. There are some HF tuned SMTP equivalents, but they really do
not add any value over some of the approaches currently in use in the
ham world. Which brings us to..

Regarding FBB interface, Patrick is right, it's the defacto standard,
well understood, and even implemented inside the WL2K systems. It's also
the model we used for BBSLink & ALE.

The challenge on HF is that interactive bbs type chat's are extremely
inefficient, especially with low bandwidth protocols. To the point that
many HF BBS's now discourage interactive sessions.

So for BBSLink we went with a very compressed approach. Same general
command set as FBB, but in a form that you can initiate a message with
subject line in a single line of text, followed by the body of the
message in subsequent lines if it's a multi-line message. BBSLink then
translates to the session "chat" needed with the gateway system, be it
FBB, MSYS, WL2k, or SMTP.

This allows us to interface with pretty much any of the major bbs/email
gateways. Right now most of the work is with WL2K & SMTP message
domains, but there is no reason the SMTP host could not be a NOS session
coresident on the same box. Or an MSYS style FBB box.

If you examine bbslink commands, you'll see the exact FBB commands: SP
(send private), RM, LM, etc

For several reasons we did not emulate the full forwarding syntax of the
BBS world, as it really starts to increase the scope as you get into
"store & forward".  Once you accept a message, you own it, including
communicating failure back to the initiating session. Big
responsibility. So by design bbslink is stateless. The message handoff
either succeeds immediately, or it fails. And the initiating station
knows either way. It's the only safe way, as there is no guarantee that
you will ever be able to reach the sending station again if the message
fails, etc.

We also chose not to duplicate existing messaging infrastructure.
Instead, we decided to focus on leveraging the 3 most common messaging
gateways encountered in the ham world. (SMTP, WL2K, F6FBB/W0RLI) Doing
so bridges networks, rather than fragmenting the amateur community
further. Common message systems are a big win, separate ones slowly die.
(Genie, AOL, Compuserve, Prodigy, teletext, etc)

So if you want compatibility with NOS/MSYS, etc, that is already working
in the ALE world. You don't need KISS, it's done at the session layer
using TCP/IP and direct socket based transfers.

SMTP is the most prevalent, whether the "big I" Internet or entered into
a ham/mars packet system via NOS SMTP gateway. Or even MSYS. You could
argue that SMTP is the defacto standard in messaging gateways as pretty
much all systems support it in some form.

I still owe Patrick documentation on how to interact with bbslink (or
emulate entirely) which should help bridge the networks further. The
external bbslink interface is documented. I just need to write up the
internal interface so multi-psk can be used as transport as well.

All of this is good dialog, and worth exploring. It's just sometimes
harder to make play than just picking protocols.

Have fun,

Alan
km4ba



Announce your digital presence via our Interactive Sked Page at
http://www.obriensweb.com/sked



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/digitalradio/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:digitalradi

Re: [digitalradio] ALE400 and 141a

[Rick W]

When I used to be on another digital group (I think it may have been one 
of the TAPR lists?), Maiko was able to get certain hardware/firmware to 
work with his development of JNOS2.

Although JNOS is very theoretical to me, I wonder if it could it be set 
up with the mode of your choice (within limits) that will work well with 
sound cards?

Considering the tremendous effort that has gone into some of these 
technologies, and the little use they seem to have gotten, it suggests 
to me that they do not meet the needs of a target user. Developing for 
proprietary hardware/firmware does not seem like the direction to take, 
but developing for sound card applications does seem like the most 
practical way to create something that may reach critical mass with 
enough users.

I have believed for some time that we need a framework that would allow 
"bolting on" of different sound card modes for low cost and accurate 
data transfer between stations and even into the internet on an ad hoc 
basis so that you can set it up whenever you have the need and wherever 
an internet connection might be available for public service/emergency 
traffic.

By itself, the old MIL-STD-188-141A protocol is a fairly old technology 
(1970's), and would not normally be something that we would 
intentionally use anymore. The FAE modified form has proven itself to me 
and several of us who have been experimenting with it, since it is more 
robust and yet reasonably fast with the slower baud rate and narrower 
bandwidth of FAE400.

Are any developers looking at the Winmor specifications and its approach 
to not only error free data transfer, but having adaptive modes that can 
work under varying conditions?

73,

Rick, KV9U


Jose A. Amador wrote:
> I almost always used JNOS with KISS interfaces, it is a natural way of 
> using it. TNC's under MSDOS, and also thru pipes under Linux with 
> net2kiss (I would have to go back to the manual to remember a few 
> details). It could be interfaced with the BPQ switch, so FBB, JNOS, the 
> BPQ switch could share the same KISS TNC.
>
> I was not succesful to interface JNOS to MultiPSK using TCPIP, and have 
> not tried yet using the KISS interface, but I see that others have had 
> quite a bit of success with it.
>
> Could that be extended to ALE? Right now I don't really know, but looks 
> interesting to find out.
>
> I am not up to date with all that Maiko has added to JNOS 2.0
>
> 73,
>
> Jose, CO2JA
>
> ---
>
> John Bradley wrote:
>   
>> So how would we go about using FBB or JNOS? JNOS has appeal since it can
>> gateway to the internet, a desirable feature
>> for emergency comms
>>
>> John
>> VE5MU
>>
>>
>> I believe that the simplest is not reinventing the wheel, and using MultiPSK
>> as a modem, using traditional BBS programs as the mail application.
>> Does anyone find this to be wrong?
>>
>> The store and forward part could mean a *LOT* of work to be done, or
>> actually, re-done...
>>
>> For traditional ham mail, I find FBB is very good. And for e-mail, JNOS.
>>
>> Would it be possible to extend the KISS mode interface to other modes and
>> not only packet? I don't know right now, but sounds tempting.
>>
>> I feel that a lot of the old packet legacy programs have a lot to offer if
>> the classic TNC is replaced for a better modem.
>>
>> Maybe it would be interesting to identify other interfacing software, i.e.,
>> KISS-WA8DED, 6PACK-KISS, etc
>>
>> 73,
>>
>> Jose, CO2JA
>> 

Re: [digitalradio] ALE400 and 141a

[Jose A. Amador]

I almost always used JNOS with KISS interfaces, it is a natural way of 
using it. TNC's under MSDOS, and also thru pipes under Linux with 
net2kiss (I would have to go back to the manual to remember a few 
details). It could be interfaced with the BPQ switch, so FBB, JNOS, the 
BPQ switch could share the same KISS TNC.

I was not succesful to interface JNOS to MultiPSK using TCPIP, and have 
not tried yet using the KISS interface, but I see that others have had 
quite a bit of success with it.

Could that be extended to ALE? Right now I don't really know, but looks 
interesting to find out.

I am not up to date with all that Maiko has added to JNOS 2.0

73,

Jose, CO2JA

---

John Bradley wrote:
> So how would we go about using FBB or JNOS? JNOS has appeal since it can
> gateway to the internet, a desirable feature
> for emergency comms
> 
> John
> VE5MU
> 
> 
> I believe that the simplest is not reinventing the wheel, and using MultiPSK
> as a modem, using traditional BBS programs as the mail application.
> Does anyone find this to be wrong?
> 
> The store and forward part could mean a *LOT* of work to be done, or
> actually, re-done...
> 
> For traditional ham mail, I find FBB is very good. And for e-mail, JNOS.
> 
> Would it be possible to extend the KISS mode interface to other modes and
> not only packet? I don't know right now, but sounds tempting.
> 
> I feel that a lot of the old packet legacy programs have a lot to offer if
> the classic TNC is replaced for a better modem.
> 
> Maybe it would be interesting to identify other interfacing software, i.e.,
> KISS-WA8DED, 6PACK-KISS, etc
> 
> 73,
> 
> Jose, CO2JA
> 
> ---
> 
> John Bradley escribió:
>> Maybe we can convince Patrick to look at possible “store and forward” 
>> functions as well
>>
>> 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 



Announce your digital presence via our Interactive Sked Page at
http://www.obriensweb.com/sked



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/digitalradio/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:digitalradio-dig...@yahoogroups.com 
mailto:digitalradio-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
digitalradio-unsubscr...@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: [digitalradio] ALE400 and 141a

[John Bradley]

So how would we go about using FBB or JNOS? JNOS has appeal since it can
gateway to the internet, a desirable feature
for emergency comms

John
VE5MU


I believe that the simplest is not reinventing the wheel, and using MultiPSK
as a modem, using traditional BBS programs as the mail application.
Does anyone find this to be wrong?

The store and forward part could mean a *LOT* of work to be done, or
actually, re-done...

For traditional ham mail, I find FBB is very good. And for e-mail, JNOS.

Would it be possible to extend the KISS mode interface to other modes and
not only packet? I don't know right now, but sounds tempting.

I feel that a lot of the old packet legacy programs have a lot to offer if
the classic TNC is replaced for a better modem.

Maybe it would be interesting to identify other interfacing software, i.e.,
KISS-WA8DED, 6PACK-KISS, etc

73,

Jose, CO2JA

---

John Bradley escribió:
>
> Maybe we can convince Patrick to look at possible “store and forward” 
> functions as well
>
> 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 



Announce your digital presence via our Interactive Sked Page at
http://www.obriensweb.com/sked



Yahoo! Groups Links

Re: [digitalradio] ALE400 and 141a

[José A. Amador]

I believe that the simplest is not reinventing the wheel, and using 
MultiPSK as a modem, using traditional BBS programs as the mail 
application.
Does anyone find this to be wrong?

The store and forward part could mean a *LOT* of work to be done, or 
actually, re-done...

For traditional ham mail, I find FBB is very good. And for e-mail, JNOS.

Would it be possible to extend the KISS mode interface to other modes 
and not only packet? I don't know right now, but sounds tempting.

I feel that a lot of the old packet legacy programs have a lot to offer 
if the classic TNC is replaced for a better modem.

Maybe it would be interesting to identify other interfacing software, 
i.e., KISS-WA8DED, 6PACK-KISS, etc

73,

Jose, CO2JA

---

John Bradley escribió:
>
> Maybe we can convince Patrick to look at possible “store and forward” 
> functions as well
>
> 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 



Announce your digital presence via our Interactive Sked Page at
http://www.obriensweb.com/sked



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/digitalradio/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:digitalradio-dig...@yahoogroups.com 
mailto:digitalradio-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
digitalradio-unsubscr...@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: [digitalradio] ALE400 and 141a

[John Bradley]

 

technically we were using FAE400 mode and FAE2000 modes, in ARQ as opposed
to general broadcast (unproto) mode.

 

I agree with you on the 400ARQ mode, and the feature I appreciate most is
the ability to send mail to an unattended station, having determined that
the unattended station can hear you, using QRZ,HFN or a user defined net
call. This is about the only time that the ALE function is useful is doing
what it was meant to do: establish a link.  More than a few hams have taken
the approach that ALE is a legitimate mode for passing traffic. Unless
traffic is limited to a one line message, there doesn't seem to be much
point.

 

What I would like to propose is that we pick an 80M frequency (not 3596,
since it seems to be the main frequency for RTTY broadcasts and activity)
and try

to pass a few messages around the country, using 400. Maybe we can convince
Patrick to look at possible "store and forward" functions as well

 

John

VE5MU

Hi John,

At the time I was listening to the frequency there were RTTY stations on 
either side and very close, so did not attempt a connection.

Were you using ALE400 or FAE400? My understanding is that FAE is faster 
than the ALE with plain text due to compression which I don't think is 
available in ALE400. I have never quite understood the purpose of the 
ALE modes unless perhaps it was used for a group (non ARQ) transmission. 
But in such a case wouldn't you want to use a better mode than ALE which 
is an older technology from the 1970's and developed before the advent 
of sound card modes and computer access.

When I have tried the wide 141A (ALE/FAE 2000) modes, they have not been 
as practical to use for the conditions you normally find on the lower 
bands. FAE2000 might work reasonably well on higher bands with low 
ISI/Doppler. The speed is several times faster, but the bandwidth is 
about 5 times wider and less robust.

The reasons that I am so impressed with FAE400:

- relatively narrow (keeping under 500 Hz) to meet the IARU band plan 
bandwidths designated for the RTTY/Data portion of 80 meters

- has compression which can greatly increase speed

- first sound card ARQ mode with the full ASCII character set

- first sound card mode employing memory ARQ

The only other mode that may have some of these characteristics is 
Winmor, but that has not been released yet.

What has been surprising to me is that few hams have any interest in 
using these connected modes, especially for public service/emergency use.

73,

Rick, KV9U

John Bradley wrote:
>
> After an evening of limited testing, VE6OG and I found ALE400 much 
> better on a file transfer tonight, given the band conditions and
>
> QRM.
>
> 
>
> Both stations remain on for the rest of the night and early morning .
>
> 
>
> John
>
> VE5MU
>
> 

 

Re: [digitalradio] ALE400 and 141a

[Rick W]

Hi John,

At the time I was listening to the frequency there were RTTY stations on 
either side and very close, so did not attempt a connection.

Were you using ALE400 or FAE400? My understanding is that FAE is faster 
than the ALE with plain text due to compression which I don't think is 
available in ALE400. I have never quite understood the purpose of the 
ALE modes unless perhaps it was used for a group (non ARQ) transmission. 
But in such a case wouldn't you want to use a better mode than ALE which 
is an older technology from the 1970's and developed before the advent 
of sound card modes and computer access.

When I have tried the wide 141A (ALE/FAE 2000) modes, they have not been 
as practical to use for the conditions you normally find on the lower 
bands. FAE2000 might work reasonably well on higher bands with low 
ISI/Doppler. The speed is several times faster, but the bandwidth is 
about 5 times wider and less robust.

The reasons that I am so impressed with FAE400:

- relatively narrow (keeping under 500 Hz) to meet the IARU band plan 
bandwidths designated for the RTTY/Data portion of 80 meters

- has compression which can greatly increase speed

- first sound card ARQ mode with the full ASCII character set

- first sound card mode employing memory ARQ

The only other mode that may have some of these characteristics is 
Winmor, but that has not been released yet.

What has been surprising to me is that few hams have any interest in 
using these connected modes, especially for public service/emergency use.

73,

Rick, KV9U



John Bradley wrote:
>
> After an evening of limited testing, VE6OG and I found ALE400 much 
> better on a file transfer tonight, given the band conditions and
>
> QRM.
>
>  
>
> Both stations remain on for the rest of the night and early morning .
>
>  
>
> John
>
> VE5MU
>
> 

Re: [digitalradio] ALE400 and 141A

[Alan Barrow]

John Bradley wrote:
>
>  
>
> · Have given up on the PCALE and HFlink bunch, since there
> seems to be no interest in doing anything other than sending 1 line
> messages to each other , or simply sounding. The MARS version of PCALE
> might work, but the author is not allowing use of this software
> outside of the MARS side… why is anyone’s guess. As far as I can see
> no progress has been made to get some sort of practical message
> handling system in place, using ALE to establish contacts.
>

Hello John,

I'm not sure I understand your comments about one line messaging, as
many of us have been using dbm & dtm multi-line messaging via pc-ale,
mars-ale, and of late multi-psk.

It's not perfect, but it works, is a true international & mil standard,
and is soundcard based. Right now I'm probably the biggest hold up to
more DBM based multi-lined messaging. It's not from lack of interest,
it's just time & tech issues. Even as is it works well for shorter
message, we have some bugs I need to chase & resolve for long (1k+
messages). Routes out to smtp or into the winlink system. Reads back
messages, you can delete messages, etc. Approaching packet BBS
functionality, which has been my model for basic functionality.

We are working on other messaging concepts which will increase the
functionality further.

Regarding mars-ale vs pc-ale, Steve N2CKH has been slowly converging the
two. First the modem core moved, then radio support libraries, and
lately the capability to communicate with other programs via telnet has
as well.

Right now, the current pc-ale beta has the majority of US ham legal
content of marsale.

Between pc-ale & multi-psk there are some very good tools available.

>  
>
> · From our point of view have thrown in the towel and will
> likely go with SCS Modems using Pactor 3 for some of the longer haul
> stuff we do, and our served agencies seem ready to purchase the
> necessary gear. Still interested in a sound card messaging mode which
> could link to the internet when required.
>
>  
>
P3 has it's uses and can be effective if you can obtain the modems. But
tech like P3 would be far more powerful if leveraged with an ALE
approach to find the highest S/N path and leverage the bands more
effectively. Or connect to a specific station on demand.
>
> · Am going to send Patrick a separate email about doing a
> striped down version of multipsk for emergency comms, something that
> would do PSK,MFSK,Olivia and the ALE modes, and nothing else…….AND
> with a message gateway……… that’s all I want for next Christmas , hee hee.
>
This would be a neat thing. Ever give any thought to working on
something like this? Several of us have, would be great to have some
other folks coding. I know Patrick has exposed an "API" to multi-psk.

Have fun,

Alan
km4ba

Re: [digitalradio] ALE400 and 141A

[Rick W]

I tried to connect again today (this afternoon) as I saw your request 
for connecting via FAE400 on 14.111 and 7.103. I tried both stations 
callsigns as it almost seemed as if the frequencies were reversed from 
the other day with the regular MIL-STD-188-141A mode, but maybe I 
misread that, HI. I was sure that I would be able to connect today, but 
maybe I am not understanding the times you are going off air? I even 
tried using increased power with my amplifier to 100+ watts and still 
nothing. I also tried QRZ as well as the callsigns, but not sure if you 
would key into that.

Based on their odd behavior, PCALE and HFLink appear to have some very 
disturbed people. Not all, of course as some really went out of their 
way to help, but enough to lose credibility with most hams. I have 
received comments from others, surprisingly, even on the air contacts, 
where individuals expressed similar views, and I have been personally 
attacked as apparently not being pure enough in how I used their system. 
It is hard to understand, since I really tried hard to figure out how to 
make the system work as best as I could, even going so far as to have 
Patrick make some changes for me to try with Multipsk but we never could 
get it to work properly. I know they were most upset that I pointed out 
that contrary to their claims, I was one of the only hams world wide 
that actually tried using their system for practical messaging. And it 
was rather obvious after monitoring their web site which shows all world 
wide activity that was not happening. Their solution was to actually 
block my IP from accessing their site so I can no longer report on the 
minimal use. Needless to say, anyone who would do such a thing, is very 
dangerous in terms of providing serious, public service/emergency 
communications that you can count on. It might not be there, or could be 
blocked during an emergency. Either way, they have certainly damaged 
their cause beyond repair with many hams and it was completely 
unnecessary. My rule of thumb is to just be honest and don't try and 
make false claims because sooner or later it will catch up with you.

On a more positive note, it would be very interesting to see is a 
software like Sigmira that could not only decode MIL-STD-188-110A 
protocols, but could also transmit them. I have been able to decode some 
open ID's of stations from France that must be ildling and ready to 
transmit data. But as mentioned, we U.S. hams would have to use it on 
VHF and up. Most of these stations tend to use the 300 and 600 bps data 
rates, but the software supports all the way down to the 75 bps speed 
which is necessary to handle the severe conditions on HF.

In the meantime, I have great expectations for Winmor. And if the 
specifications are open, it is very possible that some of our amazing 
programmers could make a peer to peer version of Winmor. As I always 
say, it only takes one person who has the knowledge and interest to do 
it. This technology could be set up with a multiband/multimode rig with 
a sound card interface and be used from HF through UHF with minimal 
changes in operating technique. But if you need something today, then 
SCS is probably the best commercial route to take.

It was interesting to show my wife the choices we have available now for 
ARQ modes, but except for RFSM2400, the others were intimidating. This 
assumes that the user can work out the other 99 steps you need to take 
to get a rig interfaced to a computer with the software properly 
configured, etc., etc. I take it for granted (most of the time) but even 
I sometimes have something become non operational due to some glitch. In 
fact, just had an odd thing happen during the ARRL VHF Contest when I 
was trying out N1MM Logger. It appears to force a switch from mike input 
to auxiliary input (which I don't use) and you have to know to go back 
into the sound card software to switch it back when you want to use a 
digital sound card program. Maybe there is a fix for that?

It was surprising how many hams we had locally participate in the VHF 
contest. I have personally asked some of them, plus sent out some e-mail 
promoting what we can do with digital modes on HF and VHF and even on 
VHF FM and whether they would give some consideration to doing some 
public service stuff but the answer is either ... not interested, or too 
busy with other things to try something new like that. I don't see many 
of my ham students from my entry level (and even General) classes do 
much more than 2 meter FM and then move to HF SSB but not a lot more. 
But I keep trying to promote digital modes on HF and VHF and up.

Keep us posted on any more attempts to connect with you or GPM

73,

Rick, KV9U



John Bradley wrote:
>
> In answer to your questions…….
>
> · did not have any luck with a connect from anyone other than local 
> hams on both 141A and ALE400 , but the bands were in particularly bad 
> shape over the weekend . Am in the process