Re: [digitalradio] Is Propnet/HF APRS legal in USA ? (was : Trouble at mill RTTY contesters war with HFlink

[Steve Hajducek]

Hi Andy,

That's just nonsense.

/s/ Steve, N2CKH

At 09:03 AM 1/13/2008, you wrote:
>Yes,  I received a private email from the individual that is preparing
>the IED's.   With reference to ALE soundings,  he cites ..
>
>") 1 illegal 1-way transmissions;
> > 2) illegal automatic beaconing below 28.200 MHz, and; 3) illegal automatic
> > control of a digital station."
>
>
>as issues he asked the ARRL about and he reports the ARRL has
>forwarded to the FCC for comment.
>
>
>So, what about Propnet ? Would this not also apply to their beacons?
>Once per hour these station send out their coordinates and station ID.
>What about Packet on 30M, APRS.  I am fairly certain these station
>do not have a control op all the time as they becaon their coordinates
>based on their UI-View settings.
>
>
>Andy K3UK

Re: [digitalradio] ALE in a nutshell (and ALE dating FLARQ)

[Steve Hajducek]

Hi Alan,

I agree to a point, it depends on ones focus, if you recall I have 
always run my GAP DX Voyager antenna when looking for world wide 
activity such as in HFlink events, that antenna at 100 watts and an 
ATU works all Amateur bands 100%. However using a Skywave antenna 
heavily takes away from the ability of gateway stations to server 
users within NVIS range, I feel each such station should concentrate 
on their NVIS range user base. Which is why I feel the better 
approach for stations serving as gateways is to configure for 
automatic antenna selection where an optimal NVIS and Skywave antenna 
are selected as can be done with MARS-ALE. In Amateur Radio 
application this simply means that all such stations will serve their 
local NVIS range users better below 20m and all users at 20m and 
above. Such automatic selection of antenna is only available at 
present in MARS-ALE. I hope to see such automatic antenna selection 
show up in all Amateur software tools that provide for gateway 
connectivity which are not single channel oriented in their scope, 
e.g. WL2K PMBO's configured for scanning for example.

/s/ Steve, N2CKH

At 01:10 PM 1/12/2008, you wrote:

>I slightly disagree with my colleague Steve, while for MARS the majority
>of ALE is NVIS, in the ham side our NVIS bands are so crowded and
>cramped that the best comms occur higher. The goal is to have HFN
>stations spreadout enough that one or more will be able to provide comms
>whether NVIS or skip based.
>
>But Andy's post is still an excellent summary of ALE!

Re: [digitalradio] ALE in a nutshell (and ALE dating FLARQ)

[Steve Hajducek]

Hi Andy,

All true, I could not agree more!

/s/ Steve, N2CKH

At 10:20 AM 1/12/2008, you wrote:
>I'll say again... the only thing wrong with the concept of ALE is the
>lack of active users.  Everything else about ALE makes perfect sense
>to me.  Here are the basics.

Re: [digitalradio] Re: ALE Sounding and How does it work?

[Steve Hajducek]

Rick,

You obviously don't understand NVIS, the bulk of all my ALE activity 
is NVIS based, this is true of Amateur Radio as well, which is 30m 
and lower ( 5Mhz thru 11Mhz is excellent during the day, that is our 
premiere MARS range, 5-7Mhz can be counted on 24/7 by the way, its 
too bad that the ARS is so restricted at 5Mhz) WRT Amateur band 
allocations ( you would likely be surprised at times to see excellent 
contacts as low as 75m during the day ) to sit parked on a single 
frequency ( e.g. 20m band) 24/7 is in complete contradiction with the 
premise LQA base ALE application.

/s/ Steve, N2CKH

At 09:54 AM 1/12/2008, you wrote:
>John and group,
>
>There is minimal ALE activity here in North America. Maybe there are
>untold thousands of operators in other parts of the world but not here.
>For those who have been hams for any length of time and operated HF, it
>is obvious that the higher HF frequencies are not open very often. And
>the lower bands are mostly for evening use. That leaves mostly 20 meters
>as the prime daytime band. So monitoring 20 meters would give you an
>accurate sampling of the amount of traffic (or not) on ALE frequencies.

Re: [digitalradio] Re: ALE Sounding and How does it work?

[Steve Hajducek]

John,

Sorry but I know the relative level of activity 
at times. There is far less ALE than various 
other modes and more ALE than various other modes 
as well. It all depends on your point of 
reference, just as there is Hellscriber than GTOR 
and more CW than PSK31, regardless your statement 
as to the amount of activity is false, but its 
also moot in my opinion. I view ALE within the 
scope of Amateur Radio application as tool that 
needs to trained on and have networks in place 
for use as necessary, not necessarily used daily 
by all, although such use is just fine and the 
best tool for many pursuits within ARS, however 
its the application of ALE for ECOM where I see 
ALE having the biggest benefits to the ARS.

Rather than sitting on 20 meters you should try 
programming all the ALE frequencies into your 
choice of ALE controller and scanning for 24 
hours with appropriate antenna for NVIS below 
14Mhz and Skywave above 10Mhz for Amateur Radio 
and if you are properly configured you your results will be much different.

As to you what you are seeing on Channel One, it 
will depend on the geographic location of the 
HFlinkNet stations and what they are hearing 
based on the antenna type being used. Some are 
using NVIS antenna only, others Skywave antenna 
only, some are using something thing in between, 
those using automated antenna selection will be 
optimum, I do not know what all the stations are 
running. The MARS-ALE software which is being 
used by HFlinkNet stations supports programmable 
antenna selection during scanning using various 
devices, the CAT ANT ports in radios, external PC 
controlled ATU's with ant ports and dedicated 
antenna switches under PC control.

/s/ Steve, N2CKH

At 11:05 PM 1/11/2008, you wrote:
>
>If the statement below is False, why are there 
>not more call signs showing up on the main ALE frequencies?
>
>I can leave my rig on 14109.5 or 10145.5  for 24 
>hours and only see, at most 4 or 5 stations?  Ditto for the ALE website
>At HFlink.  And 99% of those are soundings. So 
>where are the QSO’s and the like?
>
>Who is up for testing the ability of PCALE to 
>handle a standard test document between 2 distant stations, compared to 141A or
>ALE400. Ditto for a file transfer?  I can’t on 
>PCALE since I can only receive, since I have a 
>problem getting the software to TX.
>
>Anyway , in the past I have told you guys at 
>least 20 million times not to exaggerate……
>
>
>John
>VE5MU

Re: [digitalradio] Ale Sounding: What is it and how does it work?

[Steve Hajducek]

John,

Your message below is easy to summarize  succinctly, thanks.

At 09:48 PM 1/10/2008, you wrote:
>
>Chris , ZL1BOE
>
>you will be told by others that ALE is widely 
>used to set up QSO’s and QSY’s using the one 
>line message ability . You will also be told 
>that it is used widely for keyboard to keyboard 
>QSO’s and that there are thousands of Hams using 
>ALE ( last figure I heard was 6000) . These are 
>folks who are using PCALE, who have aggressively 
>set aside frequencies for ALE use in all bands, 
>and are promoting ALE as the answer to emergency communications.

FALSE


>
>Granted, PCALE, in its MARS form may be a great 
>piece of software to pass messages from overseas

TRUE

NOTE: MARS does not make use of ALE for OCONUS traffic relay.

>  but that ability is certainly not evident on the ham bands.

FALSE


>
>The reality is that there are likely under 50 
>hams active with PCALE  worldwide, those using 
>PCALE spend most of the time sounding , with 
>little , if any message traffic passed, and no 
>QSO’s. PCALE does not work very well into the 
>noise, and is certainly not user friendly when 
>setting up a rig and computer to run the 
>program. Beyond using the sounding function 
>there appears not to be much interest in running 
>nets, or exploring emergency communications aspect of PCALE.

FALSE


>
>ALE400 (multiPSK) might be closer to your needs 
>since it is narrow band and works well into the 
>noise. It can be readily used for soundings, 
>file transfer, and is a pleasure to use for 
>digital QSO’s, keyboard to keyboard. The author 
>is constantly working on the software, and 
>appears to be moving closer to the Holy Grail of 
>being able to pass messages and files from HF to 
>the internet. It is simple to install, simple to 
>use, (although the screen can be a little 
>overwhelming at first)  .There is a plan afoot 
>which would see some extensive cross Canada 
>testing of this mode to determine it’s 
>suitability for emergency communications.

TRUE


>
>There are some other software out there to look 
>at. NBEMS has promise, but , since it uses BPSK 
>for the most part, suffers from multipath 
>flutter and other ozone maladies. The authors 
>state that it’s intention was to run over 
>VHF/UHF, and , while I haven’t tried it, would 
>probably work very well. This software is also 
>under active development so will be interesting 
>to see what other capabilities it will have.

TRUE


>
>RFSM8000  gets very little mention  on these 
>reflectors, since hams in the USA cannot exceed 
>300baud speed. Dimitry and his team have posted 
>the latest version which looks interesting , but 
>haven’t tried it, but is something we can run 
>here in Canada on most bands except 30m.( 
>bandwidth issues rather than speed)  It 
>apparently has the ability to pass traffic to 
>and from the internet from HF, using a sound card modem.

TRUE


>
>So much software, so little time……….

SO TRUE

/s/ Steve, N2CKH


>
>73’s John
>VE5MU
>

Re: [digitalradio] Emergency agencies/ ham equipment/ hams in emcomm

[Steve Hajducek]

Hi Rick,

 From reading your comments I see you still fail to fully understand 
the potential value of ALE to Amateur Radio, especially to ECOM.

ALE is the great facilitator to follow on communications, nothing 
aside from MIL-STD AQC-ALE and the host of copy cat systems such by 
the likes of CODAN, RHODE & SCHARTZ and TADIRAN even come close to 
the HF linking capabilities of ALE.

Rick you continue to spew out all kinds of negative comments and spin 
that is just not correct with just enough positive comment that there 
is hope for you in understanding ALE yet. Keep it up as it likely 
benefits someone that may read what you have to say and gets 
interesting in looking into ALE as they may not otherwise get 
interested, much like there is no such thing as a stupid question, 
someone may benefit from the question being asked.

The FCC sub bands for automated operation 100% appropriate for ALE 
operation when a station is Sounding, attended or unattended in the 
digital sub bands and other uses of ALE are appropriate under the 
rules outside those sub bands, as well as outside the digital sub 
bands altogether if one lives within FCC jurisdiction.

After the ALE link has been established based on whatever type of ALE 
call has been made, preferably based on the best ranked LQA frequency 
selection, the follow on protocols/waveforms used are NOT limited to 
the 125 wpm AMD protocol (which is a very basic FEC protocol) but 
rather allows for anything to be used after the ALE link. However the 
DTM and especially the DBM protocols are very good, DBM ARQ is every 
bit as robust if not more so than GTOR or PACTOR I as a matter of fact.

Another benefit at this point in time WRT ALE as applied to the ARS 
is that it is no longer limited to a hardware only solution with a 
narrow range of expensive options as it originally was, this was the 
stumbling point of ARS interest when ALE was first introduced to the 
ARS in the pages of QEW and QST. ALE tools being software 
modem/controller based using the PC Sound Device Modem (PCSDM) has 
brought ALE to any Radio Amateur interested, we are only at the 
starting gate with respect to ALE and ARS application, you really 
have not seen anything yet compared to what is to come.

What you just don't seem to get is that an ALE network provides the 
best means of supporting 24/7 HF networking in the selection of 
frequency and station(s) of interest via numerous linking call types 
to enable either one to one or one to many station communications, 
attended or unattended, local drop or store/forward, bridged to one 
or more automated delivery systems with return paths outside HF radio 
or not. There really are no limitations to the application of ALE 
within or outside of the ARS when it comes to HF communications link 
establishment, it is truly and unlimited system. Can the application 
of ALE be adapted within the existing limited framework of ARS 
operations, yes, it already has, should ARS welcome and adapt to the 
full potential of ALE is really the question, for which I feel the 
answer is Yes. However I am not running around pushing that as an 
agenda, I you have not noticed my posts are in response to those with 
questions or positions where the facts need presenting. In my view 
either the ARS ( especially those involved with ECOM ) will grasp the 
application of ALE and put it to work for the benefit of the ARS or 
not, if not then it will be a wasted opportunity to improve Amateur 
Radio HF networking in my opinion.

Rick, I can't put my finger on just what it is yet, but something is 
standing in your way of really seeing the potential of ALE.  The 
potential of ALE based communications to the Amateur Radio Service 
for HF networking is huge, you seem to be part way there, I hope you 
hang in there.

Anyhow, lunch time is running out and I need to finish up and get 
back to my day job work.

73

/s/ Steve, N2CKH

At 11:22 AM 1/10/2008, you wrote:
>As we have been finding out through testing,  ALE may have a place in a
>few niche interest areas but it is likely to be of limited value on the
>ham bands, and not well supported, since the shared nature of the bands
>do not lend themselves well to this kind of continuously dedicated
>frequencies. If the FCC does rule that ALE soundings are a legal
>activity, there is the potential for unintended consequences if we allow
>beaconing throughout the HF bands.

Re: [digitalradio] RM-11392

[Steve Hajducek]

Rick,

RM-11392 is a most excellent example of a bad petition in my opinion. 
As Andrew stated, "The proposal has no chance of being adopted".

Also, I don't see any relevance to your CW vs. SSB comments and 
RM-11392. I don't know where the heck you operate CW, even with my 
oldest hybrid transceiver and 250hz Fox Tango filter I could easily 
work CW stations among the worst SSB and I have when weak stations 
have called me for a split mode contact to break through during SSB 
pile ups, this is very common in contesting, especially on VHF+

I have no more time to waste discussing RM-11392, it is a dead issue in view.

73

/s/ Steve, N2CKH

At 05:38 PM 12/27/2007, you wrote:
>Hi Again, Steve,
>
>I think that you are also supporting "protectionism" as I am, only you
>don't think of it that way. It protects the users of incompatible modes
>from reducing the use of the spectrum. There may be no technical way for
>them to coexist unless you literally drive them off. Some may feel that
>way, but I do not. And it was not until I really tried using CW when the
>SSB operators encroached that I realized how bad it can get. The SSB
>operators may have multiple notch filters that can remove tones, but
>even that is not often satisfactory. CW can not cope well with SSB and
>similar waveforms, even with the narrowest filters.

Re: [digitalradio] RM-11392

[Steve Hajducek]

Hi Rick,

At 08:26 PM 12/26/2007, you wrote:
>Hi Steve,
>
>I agree that it is a type of protectionism.

Which in my opinion is a worst case issue for the Amateur Radio 
Service (ARS) than the technical challenges being presented.


>  I did not view it that way
>as much until we really started seeing a lot of new modes and how poorly
>they cooperated with each other. Especially with the main change over
>the years which is ... inability to intercommunicate. The best we can do
>is to try not to interfere with each other. The narrow modes do a far
>better job of this because of a practical reason. They do not need as
>much real estate to operate in what is often a VERY limited shared
>resource. I noticed this time and again when I tried to pick out a place
>to operate 2K MT-63 or wide Olivia. It is very hard to do without
>stepping on someone else.

As I have stated before what is needed within the ARS is segregation 
of narrow vs. wide digital modes. The approach taken should be to 
split in half the digital sub bands so that the bottom half is used 
for emissions below 500hz and the 2nd half for emissions greater than 
500hz, regardless of automated operations or not.

I agree that we have too little frequency allocation on most bands, 
period, not just when it comes to digital sub bands, personally I 
would like to see a 500Khz wide band for each segment below 10 
meters, but that's a dream, we come close to that on 15m, a bit less 
so on 20m ( and about the same for 40m in North America ) and we hit 
the mark on 80/75m but elsewhere we are no where near being close. 
With or without 500Khz bands I see no reason why each band allocated 
to the ARS could not be split 50/50 between Digital and Voice, I 
actually see no reason why that should not be the case with the 
allocations already in place personally. I would also like to see the 
availability of stations involved in the support of Emergency 
Communications, during such an event allowed to work multi-mode 
Voice/Digital in the Voice segments and not have to move off frequency.


>Another thing that I have noticed is that the digital and analog modes
>really do not work well in the same area. SSB voice just tears up such a
>large part of the band and you can not filter it out. This is the
>historical reason that CW and RTTY were kept separate from voice modes.

Well the problem with a large segment of AM/SSB stations is that they 
are over driven and splatter, those driving QRO level amplifiers make 
the situation even worst during their on-the-air pursuits. Its not 
like AFSK digital mode stations are immune from this either, I see a 
number of PSK-x stations and others over driven as well.

>Now that we have digital modes that may even sound somewhat the same,
>(OFDM for example), but may carry totally different payloads, e.g.,
>voice, text data, image data, etc. we have to be very careful how we
>intermix them (the modes, not the content). They have no way of
>intercommunication unless you do what used to be a mandatory requirement
>of providing at least some kind of CW ID. So absent that idea, some kind
>of segregation is needed.

Again, I am all for segregation of narrow vs. wide digital modes on a 
normal basis.


>There are some new technologies that may have some advantages, but
>usually there is a tradeoff. Digital voice is not competitive with SSB
>voice since it is technologically inferior on a shared resource like the
>ham bands. Can it ever overcome these limits? Maybe some day, but very
>unlikely. Just because something is older does not mean it is obsolete.

Don't take your Amateur Radio Digital Voice experience to heart and 
tell Government and Military users that, they will laugh at you. We 
Radio Amateurs are slapping together various equipments for digital 
voice operations that are either firmware/hardware digital voice 
modems or Software/PC OS based modems with common Amateur Radio SSB 
transceivers, change that paradigm to the use of full up 3Khz radios 
and Vocoder modems designed for the task and the results are quite different.


>I used to think that we were maybe being held back by old rules that
>were not necessary, but that kind of thinking can be shortsighted
>because after serious discussion with other active hams who are also
>technologically knowledgeable, we don't really have many limits.

You have to be kidding?


>For example, your agenda, promoting ALE and high speed modems on HF is
>not being held back at all by the rules.

Rick I have NO agenda as you state, I am NOT promoting anything, do 
you really think that? All my software development which I am 
involved that has to do with digital waveforms and data link 
protocols are in support of the MARS program. I am directly 
associated with G4GUO as my efforts with MARS-ALE is based on his 
efforts with PC-ALE and he asked that I update aspects of PC-ALE that 
have to do with Radio Control and interfacing, but I do not do any 
development of that tool with respect

Re: [digitalradio] RM-11392

[Steve Hajducek]

Hi Bruce,

 From your reply I can see that my statement really it home, sorry if 
the the hurts!

/s/ Steve, N2CKH

At 07:07 PM 12/26/2007, you wrote:
>You really need to view RM-11392 for what it is, the
>entire thrust of RM-11392 in my opinion is an effort
>at protectionism ( its an old story that dates back
>ages ) of obsolete technology and practices by
>an attempt to limit the advancement of new
>technologies and practices, this is just the opposite
>of what the Amateur Radio Service is all about in my
>opinion
>
>HERE WE GO AGAIN " obsolete technology and practices "
>
>If it an't digital it an't radio ..
>
>BUNK JUST BUNK .
>How come you dont see all of this on 1 1/4 meters ?
>How come you want it on HF?
>When you fill up 219 mhz and above THEN say its
>"protecting " obsolete technology and practices "
>UNTILL THEN You have more than 20 mhz already to use
>GO USE IT 

Re: [digitalradio] RM-11392

[Steve Hajducek]

Hi Rick,

You really need to view RM-11392 for what it is, the entire thrust of 
RM-11392 in my opinion is an effort at protectionism ( its an old 
story that dates back ages ) of obsolete technology and practices by 
an attempt to limit the advancement of new technologies and 
practices, this is just the opposite of what the Amateur Radio 
Service is all about in my opinion. The outcome of what takes place 
within the Amateur Radio Service as to what is and what is not 
accepted as technology and practices needs to be driven by the 
development of technologies and the choices made by the Amateur Radio 
community where the rules governing the Amateur Radio Service allow 
for the needed experimentation and development of new technology and 
practices rather than tightening of the rules to limit such.

I have no love for proprietary PACTOR x or any proprietary protocols 
or for automation systems based stations that just sit parked on one 
frequency rather than frequency multiplexing. I believe the future of 
the Amateur Radio Service will be based on open standards, the best 
of which currently are U.S. Federal, Military and NATO standards 
which the ARS can adopt as they exist of use as the basis of derived 
protocols adapted to the exacting needs of the ARS. However we need 
to be moving in the opposite direction of RM-11392, we need 3Khz 
bandwidth and relaxation of a number of existing rules here in the 
U.S. to keep pace with the world Amateur Radio community.

/s/ Steve, N2CKH

At 03:21 PM 12/26/2007, you wrote:
>Hi Mark,
>
>It is interesting that the opposition to your petition is overwhelming.
>I would have expected it the other way, based upon the discussions we
>all have on groups such as digitalradio.
>
>As they say, those who show up for the meeting get to decide the
>outcome, even if they are in the extreme minority.
>
>73,
>
>Rick, KV9U
>
>
>
>Mark Miller wrote:
> > At 10:53 AM 12/26/2007, you wrote:
> >
> >
> >> I wish that Mark, N5RFX, would put this on QRZ.com since there would
> >> many hams who might comment pro or con and the FCC would realize this is
> >> a major issue with the digital amateur community.
> >>
> >
> >
> > Hi Rick,
> >
> > I did submit a news article to QRZ.com, but it appears that there is
> > a queue, so I used the Ham Radio Announcements forum.  Some other
> > threads have popped up too.
> >
> > I checked around 1800z and a little more than 80% of the comments
> > were in opposition to the petition.
> >
> > 73,
> > Mark N5RFX
> >
> >
> >
> >
> > Announce your digital presence via our Interactive Sked Page at
> > http://www.obriensweb.com/drsked/drsked.php
> >
> >
> > View the DRCC numbers database at 
> http://groups.yahoo.com/group/digitalradio/database
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
>
>
>Announce your digital presence via our Interactive Sked Page at
>http://www.obriensweb.com/drsked/drsked.php
>
>
>View the DRCC numbers database at 
>http://groups.yahoo.com/group/digitalradio/database
>
>Yahoo! Groups Links
>
>
>

Re: [digitalradio] FDMDV Patent Issue?

[Steve Hajducek]

Hi Peter,

I have been very busy lately and just now reading 
the items on FDMDV, however its the Mixed 
Excitation Linear Prediction (MELP) for digital 
speech that was developed as U.S. and STANAG 
standards over the last 10 years or so then I don't see any issues.


/s/ Steve, N2CKH

At 10:34 AM 12/13/2007, you wrote:

I’m reading on another reflector that the FDMDV 
program uses MELP, and this use of MELP is 
patented and has not been licensed.  If this is 
true, it would mean that this program is a 
illegally infringing on the patent, and thus not 
really allowed – and probably not something 
members of the amateur radio community should be promoting.


I have no idea if any of this is true… but I 
sure am interested in the thoughts of those here in Digital Radio land…


de Peter K1PGV

Re: [digitalradio] Time to do something real with ALE400

[Steve Hajducek]

Hi Kevin,

I squeezed out support for com ports 1 through 16, older version were 
com 1 through 9. The limitation is imposed by the Microsoft 
supplied  comm driver for the C++ compiler.

/s/ Steve, N2CKH



At 06:25 PM 12/11/2007, you wrote:

>pcale 1.062H will only allow CAT control via COM1 and COM2.

Re: [digitalradio] Time to do something real with ALE400

[Steve Hajducek]

Hi John,

If you are using PC-ALE 1.062H ( the latest build being #5) I can not 
imagine why you are having any issues with your TS-480SAT if the CAT 
control of radio works otherwise with any other software.

All you need to do is select either KENWOOD or if using CTS/RTS 
handshaking, KENWOOD_HS to begin with. If your radio is setup to use 
the long standing 4800 baud for Kenwood radios for backward 
compatibility with older software tools, then that is all you need to 
do aside from selecting the com port for Radio CAT and your PTT 
interface choice.

If you are using higher then 4800 baud, then you need to click 
the  "Radio Port" button next to the Radio Type selection and 
configure for the RS-232 port parameters that you are using.

Upon proper setup, shutdown and restart PC-ALE, if should come up and 
tell what Kenwood model you are using from the radio ID, if for some 
reason it can't, it will state UNKNOWN and treat the radio as the 
newest Kenwood model the software knows about, which just happens to 
be the TS-480.

MARS-ALE is a based on PC-ALE to meet the needs of MARS operations 
and differs from PC-ALE in many ways.

/s/ Steve, N2CKH


At 01:05 PM 12/11/2007, you wrote:

>
>I am not a fan of PCALE , for a couple of reasons, not the least of 
>which, given that I am reasonably bright, not being able to get it 
>running with my TS480SAT. From what I can see so far, it scans 
>really well , but have no idea of how well it would pass messages. 
>Is there two different versions of PCALE, one that we find on the 
>ham bands and one used for MARS operations? And what are the differences?

Re: [digitalradio] Re: ALE400 – Narrow band ALE mode now available

[Steve Hajducek]

Hi Brian,

At 08:29 AM 11/2/2007, you wrote:
>I'm not trying to be a pain in the butt, honest.
>

Neither is my reply meant to be anything other than pointing out the obvious.



>We need narrower bandwidths not wider bandwidths for real progress
>with the real life crowded bands.  I think that is why PSK has worked
>so well.  Anybody pushing for wider bandwidths seems to be swimming
>against the current.


Patrick's efforts on FAE ARQ and ALE400 are an excellent example of 
taking Military
communications standards and deriving solutions for Amateur Radio applications
tailored to both the equipments being used by Radio Amateurs and 
within reason, to
the parameters being demanded as well, he did not have to take the 
time and effort
to provide ALE400 in response to those calling for narrower 
bandwidth, I certainly
would not have bothered doing so, I applaud his efforts!

For daily, casual Amateur Radio QSO's PSK and all modes down to CW ( which more
new Amateurs should be using) are just fine, great actually, with two 
good CW ops if
they can hear each other the message will be passed, but the top 
speeds under the
best of conditions are pale in comparison to modern digital FEC and 
ARQ protocols.


>I want to point out the old fashioned analog mode of SSB this weekend
>had at least one station making 10,000 DX QSO's in a 48 hour period.
>This was the bottom of the sunspot cycle with incredible QRM.

For the given speed that a Phone SSB contact can be made, 1.8Khz band width is
about as narrow as you can go and still be intelligent, for 
meaningful traffic passing
and not DX contacts you would NEVER see 10,000 contacts in 48 hours on SSB,
taking into account a typical ECOM message and band conditions, from a single
operator based SSB Phone station, you would be really lucky to get off 600 and
with shifts of changing operators.


>It just seems to me that to replace existing technology, the newer
>stuff has to be able to do all the old technology could do and much
>more in the same or less bandwidth.  I'm not seeing this in these
>digital modes.  Yep, laws of physics do tend to get in the way.

Yes, for digital speed you need bandwidth, its that simple. SSB Phone 
and AM Phone take up
a lot of bandwidth for very little in the way of speed, or for that 
matter accuracy and operator
fatigue has a negative affect on both parameters during an ECOM event.


>Those interested in what can be done if the bandwidth were available
>should read the proceedings of the AMSAT meeting held this month in
>Pittburgh.  They are talking about a geosyncronous satellite with 6MHz
>of bandwidth available.  Supposedly being able to be reached with 5
>watts and a 60cm dish.  They think this is the future of emergency
>communications.

All well and good, but the focus here is HF digital communications 
for ECOM, at least that is
my focus and when you start talking about this aspect of ECOM we can 
of course any existing
technology, however for the best throughput and error free delivery I 
can not see much less than
2Khz BW and ARQ protocols being used to achieve greater than 300 baud 
operation, the adaptive PSK
ARQ stuff that I am work with in MARS exceeds 800 baud uncompressed 
already using the
PC Sound Device Modem (PCSDM) within a 2Khz BW, wether those with a 
narrow BW focus come around
or not, these wave forms on coming on the air from countries outside 
the U.S, here the out of date
FCC rules need to change to bring it and other technology to the U.S. 
Amateur Radio bands to enable
the U.S. Amateur Radio Service to benefit from the application of the 
PCSDM in support of ECOM and
not continue regulate U.S. Amateurs to using expensive, proprietary 
hardware modems when we
could be achieving desire results via the PCSDM.

/s/ Steve, N2CKH

>73 de Brian/K3KO

Re: [digitalradio] Digital Propagation Tests

[Steve Hajducek]

Hi Rick,

You obviously do not use MT-63 to pass book traffic on a daily basis 
on NVIS paths, fore if you did your opinion would be completely 
different and if you don't believe me, just ask any MARS member that 
is using a Sound Card based system these days and they will tell you 
just how robust MT-63 is for an FEC protocol.

As to MIL-STD-188-110 serial tone modem and associated protocols, 
being as not only FEC but ARQ is provided and with data rates down to 
75bps, it is extremely robust, granted 75bps is rather slow, but it 
just can not be stopped, 75bps is know as ROBUST mode by the way, 
there is no PSK carrier frequency and its a psuedo spread spectrum 
waveform within a 3Khz channel, even in MARS-ALE at 75bps its always 
3Khz as you can't diddle with the carrier and symbol rate which don't 
exist as such at higher data rates.

/s/ Steve, N2CKH

At 05:51 PM 10/27/2007, you wrote:
>Steve,
>
>If MT-63 is robust relative to MIL-STD-188-110, then the latter may not
>be all that robust! I do not find MT-63 to be all that robust, and it is
>not as sensitive as other modes since it does not work well into the noise.
>
>Do you have any real world amateur tests yet on the MIL-STD-188-110
>modems using the PC-ALE software approach?
>
>I have tested this out on 6 meters and it seems to transmit OK. I don't
>have anyone close by with the capability to run the program who can also
>operate digital modes.
>
>Also, have you found anyone who has run this software on HF here in the
>U.S. in the voice/image portions of the bands?
>
>It has been several weeks and I have not received any response back from
>ARRL yet on my tentative submission to the FCC for an interpretation of
>these regulations. Perhaps some are holding back because they consider
>the modes not legal in the voice/image areas? My reading of the rules
>says that it should be proper to use this software.
>
>Do you (or anyone else) have any thoughts as to why these modes are not
>being at least tested on HF?
>
>73,
>
>Rick, KV9U

Re: [digitalradio] Digital Propagation Tests

[Steve Hajducek]

Hi Tony,

Too bad you did not also run MT-63 at all three 
modes for comparison. I can tell you that next to 
the various 75bps Robust mode on the 
MIL-STD-188-110/STANAG modem, its very robust. 
However under such conditions nothing but an ARQ protocol will really suffice.

/s/ Steve, N2CKH

At 12:31 AM 10/27/2007, you wrote:
>All,
>
>For what it's worth, I ran several digital modes through a high-latitude
>ionospheric path simulator and recorded the results. The signal spread
>was set to 30Hz and path delay was 7 milliseconds. With these settings,
>the audio sounds much llike the most extreme polar path distortion and
>the simulator did a real number on throughput.
>
>Signal-to-noise (AWGN) was set at a threashold that allowed the most
>robust mode to print at 90 percent. In this case, that mode was Olivia
>1000/32. Although far from conclusive, mode performance seemed to
>compare well with on-air experience under the most disturbed conditions.
>
>See below...
>
>Tony K2MO
>
>
>
>OLIVIA 1000HZ / 32 TONE
>
>THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG
>THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG
>THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG
>THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG
>
>OLIVIA 500HZ / 16 TONE
>
>THE QUICK BROWN FO6 JUMPS OVE< THE LAZY DOG
>THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG
>THE QUIMK LROWN FOX JUMPS OVEn THE LAZY DOG
>QHA QUICK BROWN FOp JUMPS OVER THE LAZY DOG
>
>OLIVIA 500HZ / 8 TONE
>
>THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG
>THE QUICKRhWN ~ JUMPS OVER jELAZY UOG
>THKUICK BROWN FOi JUMPS OVER THE cAZv
>THF7yICK BROWN FO_ J$9=SGOVER THE LAZY DOG
>
>CONTESTIA 1000HZ / 32 TONE
>
>/THE QUICK BAOWN FOX J+M*S ,VER THE & ZJFDOG
>$H 4.ICK B8OWN FOX JUMPS 5E QUIY<:A,OWN FONMATSR THE LAZY DOG
>THE QUICK BROWN FOX J(LPS OVE0 TLE LAZY DOG
>
>CONTESTIA 500HZ / 16 TONE
>
>THE QUICK BROWN FOX JUMPS OV&U THE LXZ_ DJG
>TME QUI/K BRON FOX JUM?S OVERTHE LAZY DOQ
>TH' QUGCK BROWN G-C?JU/PS,OVFL5LE L"Z  DOG
>THE QUIKK BQOWN:#OX JUM!S OVERXTHE LAZT D5G
>
>CONTESTIA 500HZ / 8 TONE
>
>THE QUICK BROWN F#- T65IIRLI4L DJ! DO64I)(+
>QUICKCAH23DOX^6XMK-_,[EMAIL PROTECTED]" ,J<^'
>OWN'C!5TWNTQV0GRSM9OT
>
>MFSK-16
>
>u ÊICK BÀêe òt*ePÒct if'cÃlPøh vci]pdgeldt
>N¢án i!i   - ís=te.aOaÍC=iòYÃHE LAZY eeAxn1E
>^Àn±uQ1yaPitvén iafDel²ePS uh  ueo ^um P
>
>RTTY 170HZ SHIFT / 45 BAUD
>
>WAHXQAICC VBU  IDGTX KMLDJLUDUSTHE KLARFBJMY
>YHJNJ VBBBDQMBMPZX DFHPYU YLNKXK YHVEQQCPZWP
>OGTYD QPPWX!99 8!=9 YLDACVRDJFDDJ6!5),?''?
>
>PSK-31
>
>  i R  ® n  waeaoo o-  oeo   yietotreo ieP
>goe   },iitE,ã re o $ree" o  l i osehest
>e  n_ I t dvee  ruiTa e do e ro D e r
>e_n- § 3e o ti  e- }   dohItQ   s-e ty
>eottor eo1keo ele roetahe eeÀiefA seg
>
>
>
>
>
>
>
>Announce your digital presence via our Interactive Sked Page at
>http://www.obriensweb.com/drsked/drsked.php
>
>Yahoo! Groups Links
>
>
>

RE: [digitalradio] Need new emergency communications mode

[Steve Hajducek]

Dave,

As simple as I can put it for you, it is my opinion that the better 
solution is separation into sub bands is the only logical solution to 
your perceived issues with automated stations triggered by remote 
users as technology as we know it now (and likely for a very long 
time to come) does not offer a workable frequency busy detection 
solution that would not hinder timely access to automated 
communications in my opinion.


/s/ Steve, N2CKH

At 06:22 PM 10/18/2007, you wrote:
I have suggested that automatic busy detection be disabled on 
unattended stations handling during emergencies. This has nothing to 
do with preferring the human factor, whatever that might be. It has 
to do with optimizing for the transport of messages during an 
emergency situation.


Your overall argument seems to be that QRM between amateur stations 
can't be entirely eliminated, so it's okay if unattended stations 
QRM existing signals. Keep in mind that 97.101(d) prohibits 
*willful* interference. If stations A calls CQ and in the process 
QRMs station B, but station A cannot hear station B, then the 
interference is by definition not willful. However if station A can 
hear station B but calls anyway, then the interference is willful 
and station A is in violation of 97.101(d). This does happen, but 
it's very infrequent; any ham would refer to A as a lid in these circumstances.


Unattended stations behave exactly like station A above. When 
initiated by a remote station, they transmit whether they will QRM a 
station or not. This behavior is unacceptable whether or not there's 
a technical solution that can prevent it much of the time. It's 
double unacceptable when the solution is not incorporated. I am 
disappointed that someone as comfortable with digital technology as 
you are would offer up a continuous stream of lame excuses for not 
deploying this solution (or a better one, if you have one in mind).


73,

Dave, AA6YQ

Re: [digitalradio] Current balun

[Steve Hajducek]

Hi Dave,

Basically your intent is to de-couple that antenna from the feed line 
for consistent performance, as such for a resonant dipole feed you 
can use a 1:1 balun, you internal antenna tuner will work much better.

A 4:1 balun for a resonant dipole will yield a higher VSWR at the 
point of resonance using 50 ohm coax.

A 6:1 balun would be proper for going from 50 ohm unbalanced coax to 
300 ohm twin lead to your dipole or from 50 ohm coax to a full wave 
loop antenna.

If you wanted to make a multi-band doublet for 80m through 10m, then 
use a 9:1 balun with a short run of coax to the balun and 450 ohm 
ladder line to the dipole cut for the bottom of 80m. More than likely 
your antenna tuner will handle it well on 80, 40, 20, 15 and 10m due 
to the harmonic relationships with 80m, the same should be true of 
the WARC bands if its mounted in the clear, however use far outside 
the Amateur Bands for CAP, MARS etc. may challenge the ATU in your 
radio as it has a limited tuning range.

/s/ Steve, N2CKH

At 05:07 PM 10/18/2007, you wrote:
>I understand the basics of using a balun, but have a question about the
>specifics. Using a dipole, what would be the difference between using a
>4:1 balun compared to a 6:1 balun? Which would I choose, and why would
>I choose it? Planning on feeding the dipole direct from the tuner in my
>IC-746 (non-Pro), if that makes a difference.
>
>Thanks!
>Dave
>KB3MOW

Re: [digitalradio] Need new emergency communications mode

[Steve Hajducek]

Rick,

At 03:21 PM 10/18/2007, you wrote:
>Steve,
>
>This is not a dream of mine. This is what eventually will have to be if
>automatic operation is to continue to be permitted on amateur
>frequencies.

Its just a dream on your part and other until such time rules ever 
require it Rick.

>  This attitude that the automatic stations are more
>important than human operated stations is simply not a wise position to
>take on a shared service such as we have in amateur radio.

Show me any Amateur Radio operation that is manned 24/7 ready, 
willing and able to accept traffic for relay Rick and I will then 
look upon that operation as having the same level of importance to 
the Amateur Radio Service. As far as I am concerned Amateur Radio 
Operators and Automated Amateur Radio Systems ( HF and above ) that 
are positioned to provide and support Emergency Communications is the 
basis for the continued existence of the Amateur Radio Service in 
this country and most countries in the world.

>No one has to learn any new coding. It has already been invented.

Nothing exists that is not ripe with issues anyway you look at it Rick.

>  The
>issue of busy frequency detection may have been around a long time (and
>rightfully so considering the interference problem from automatic
>stations) and the conventional wisdom was that automatic detection could
>not be done. I don't know if you have used this software, but I
>certainly have used it and it does work.
>
>I will say this, with the comments made by an increasing number of hams
>like yourself, who either lack technical understanding of hidden
>transmitters or who want to ignore the problem, that I, and also an
>increasing number of hams are becoming less supportive of any automatic
>stations on the congested HF bands. Think about the direction you are
>taking with this anti technology approach and the long term
>ramifications that may come your way in the future.

Rick, think about the direction that you are calling for and the 
ramification that may come your way in the future with such a 
proposition, there you are with important traffic to pass and you 
can't get connected to move it due to some daily QSO going on or 
whatever that either your station or the other station detects ( that 
you may not even hear with your ears) and where they don't hear 
either you or the station that you are looking to work, be it 
attended or not, but where you frequency busy detection that you are 
dreaming about holds off your communications. That's the future that 
you dreaming about my friend, to me, its nothing more than a 
potential nightmare.

You and everyone else should be calling for separate traffic lanes 
(similar to driving down the highway) for Amateur Radio Service 
Traffic Automation if you feel the existence of such systems 
co-mingled with peer-to-peer traffic is such an issue as separation 
and not dreams of busy detection is the only logical answer to your complaints.

/s/ Steve, N2CKH


>73,
>
>Rick, KV9U

RE: [digitalradio] Need new emergency communications mode

[Steve Hajducek]

Hi Dave,

Thanks for jumping in here with Rick and I, if you read my reply that 
I just sent in response to Rick I feel you will see that I pretty 
much already touched on your points, I see that you would personally 
turn off automatic frequency detection as you prefer the human 
factor, no surprises there.


/s/ Steve, N2CKH

At 12:22 AM 10/18/2007, you wrote:

>>>AA6YQ comments below

From: digitalradio@yahoogroups.com 
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Hajducek


>snip<

2. With respect to Remote User to Automatic Station communications,
the human operator initiates the communications and its all up to
them to decide the coast is clear to do so or not and if they need to
stop because they screwed up and did not listen long enough ( how
long is long enough?

>>>The hidden transmitter effect means that the remote initiator 
cannot reliably ensure that the coast is clear.


>>>If we're on the telephone from California and say "14180 is 
clear here, give me a call there", can you transmit on 14180 from 
your QTH on the east coast without first listening to see if 14180 
is clear there? Of course not; doing so might QRM a station in 
Florida that you hear 59 but I don't hear at all. Now consider your 
station to be an unattended server and my station in California to 
be the remote initiator. Your unattended server will QRM the 
station in Florida.




 be it human operator or computer software there
is not now and never will be any perfect means of busy detection in
my opinion) to detect that the frequency was indeed in use due either
propagation or just plain long pauses between transmissions of the
3rd party stations.

>>>"Perfect" is unnecessary. It is clearly possible to build busy 
frequency detectors that are at least 80% effect, since such a busy 
detector was demonstrated years ago. Applying such an imperfect 
busy detector to unattended stations would reduce their QRM by a factor of 5.


>>>This "it's impossible to build a perfect busy detector" argument 
reminds me of Xeno's paradox, in which he proves that all motion is impossible.



In closing, you and everyone else on this frequency busy detection
quest just don't seem to grasp the realities the shared aspects of
the Amateur Radio bands and tolerance for co-frequency levels of
interference and just what it is that you are proposing with your
frequency busy detection dream.

>>>To what "realities" are you referring? Amateur radio bands are 
certainly shared, but that gives no station the right to QRM existing signals.


Also you seem to think the issue is
with Automatic Stations, when in fact it is really with Human
operated stations. If there is going to be frequency busy detection
in digital mode communications software ( and hardware where all that
is not so equipped would need to be banned from use to make your
dream a reality) than it needs to be in the Remote User's software to
second guess the human factor at all times and not in the Automatic
Station side as its the human operator that initiates the
communications, for any Automatic Station Forwarding between like
stations then and only then would frequency busy detection apply to
the Automated Station initiating the connection.

>>> What are you talking about? The issue is preventing an 
unattended station from transmitting on a frequency that is already in use.


 Also, to be as
complete and concise as possible, such frequency busy detection needs
to be applied to all known and legal for use digital modes around the
world and not just detection of RF energy period ( else your station
may never go into TX ). Doing so would force all human users to be
courteous and standby when any real digital mode signal that is
within their passband from any source, which will force the use of
narrower filters for given modes or cause stations to yield to wider
band mode operations and narrow bandwidth modes operations will have
to steer clear of wider mode operations. Then, depending on the
timing of who transmits first and what the forced upon you timing
constraints of the algorithms used end up being, you just sit and
wait for an opportunity to transmit, you may get out a CQ or other
call but then your system detects another signal and puts you into a
holding pattern again, should it be just any signal detected at any
time? Should be only when both sides of signal exchange are heard so
that your station isn't just making you wait due to another station
CQing etc., if not full QSO detection in the given mode of operation
then what about that "hidden transmitter" effect?. Oh, I can see it
now, a lot more listening for everyone, the early bird gets the
frequency for the QSO, gee what a dreamy situation, but when an ECOM
event comes about, will they ever get a chance to send that health
and welfare traffic in a timely manor or at all? 

Re: [digitalradio] Need new emergency communications mode

[Steve Hajducek]

Rick,

I don't share your dream Rick, sorry that you did not like that 
description, but I was trying to be polite about it. I am not here to 
stop you or anyone from pursuing your dreams, go learn C++ or Ada and 
start coding it up into your dream communications software. However I 
am a realist and as I don't share your dream, I see it for what it 
really is, a potential nightmare that would hinder communications 
rather than actually improving it. I won't be pursuing your dream 
with my valuable time available to me for code development unless a 
dreamer manages to get such a requirement into the rules which govern 
the Amateur Radio Service, which I don't see happening anytime soon, 
if ever, as those in charge of the rules are also realists, at least 
at present.

The issue you are talking about has been around since day one and 
always will be in all forms of RF communications, the answer to the 
issue is a level of tolerance, its that simple. Just because one 
station of two ( regardless if one is unattended ) can hear a 3rd 
station does not even mean that the 3rd station can hear either of 
the two in question. As a matter of fact the 3rd station may be 
hearing the that station which does not hear them rather than the 
scenario that you paint, which means that it would be the attended 
station that is offending the 3rd station and not the unattended 
station in your scenario.

In actual operation the dream scenario that you are proposing be it 
for Attended, Unattended or at all emitter  locations, which is what 
I would want to see,  would not make the Amateur Radio Service 
better, it would actually only hinder communications. You would still 
have the same issue that you are complaining about happening as you 
already realize from your comments, but just about as often if you 
ask me and if the algorithms were ratcheted up to the point really 
making a dent in the issue, then we are talking about holding off TX 
whenever enough RF signal is detected in the pass band over x amount 
of time that the algorithm qualifies as a true digital mode signal 
from somewhere and unless the band in question is dead, that is 
pretty much all the time. What will you will have then, almost no 
communications taking place would be the result as there is almost 
always a signal being heard from somewhere. Granted, you and many 
others would love to see almost no communications taking place WRT 
automated stations as you and others think they should not exist 
except when you feel they are needed for an ECOM event only, well I 
don't share that view, my view is just the opposite, automated 
systems are very important to the Amateur Radio Service, as they 
serve everyone and not just the individuals pursuit, they exist for 
the benefit of all Radio Amateurs communications needs 24/7, which 
means they can be relied upon by ECOM first responders in the middle 
or the day or night when needed. I fully understand why you and 
others would never want what you are preaching for in automated 
system to be in the systems that you use for digital communications 
and if it were to be why you would want the option to turn it off, 
however an unattended station can not just decide to turn it off, 
human intervention would be required and for the first ECOM 
responders trying to use the system that intervention would likely 
not come fast enough.

I had stated on this forum a while ago that the only way to make you 
and others with your opinions of as you call it "on going problems" 
with automated stations is to have all such stations in sub bands 
where no other operations are conducted, that is the logical answer, 
any such  "on going problems" would then related to only a remote 
user of an automated system, which by their decision to do so means 
they accept.

/s/ Steve, N2CKH


At 08:33 AM 10/18/2007, you wrote:
>Steve,
>
>I am surprised that you do not understand the basic technical issues
>here since you appear to be claiming that there is no such thing as the
>hidden transmitter.
>
>A human operator can not determine the paths present at the remote
>automatically controlled station. That is why there is such concern
>about this on-going problem.


 >>SNIP<<

Re: [digitalradio] Need new emergency communications mode

[Steve Hajducek]

Hi Rick,

I feel compelled once again to make some statements on the subject of 
frequency busy detection.

1. Item 5 makes no sense to this station unless you have Automatic 
Station initiating contacts to forward traffic, whereas Automatic 
Station A has 1 to number of messages queued and needs to hand those 
off to Automatic Station B in the scheme of things via HF due to any 
other forwarding methods ( if any) being down. In such a scenario 
then and only then does busy detection on the part of the automatic 
station make any sense as it needs the ability to replace the ears 
and brain of the human operator.

2. With respect to Remote User to Automatic Station communications, 
the human operator initiates the communications and its all up to 
them to decide the coast is clear to do so or not and if they need to 
stop because they screwed up and did not listen long enough ( how 
long is long enough? be it human operator or computer software there 
is not now and never will be any perfect means of busy detection in 
my opinion) to detect that the frequency was indeed in use due either 
propagation or just plain long pauses between transmissions of the 
3rd party stations.

In closing, you and everyone else on this frequency busy detection 
quest just don't seem to grasp the realities the shared aspects of 
the Amateur Radio bands and tolerance for co-frequency levels of 
interference and just what it is that you are proposing with your 
frequency busy detection dream. Also you seem to think the issue is 
with Automatic Stations, when in fact it is really with Human 
operated stations. If there is going to be frequency busy detection 
in digital mode communications software ( and hardware where all that 
is not so equipped would need to be banned from use to make your 
dream a reality) than it needs to be in the Remote User's software to 
second guess the human factor at all times and not in the Automatic 
Station side as its the human operator that initiates the 
communications, for any Automatic Station Forwarding between like 
stations then and only then would frequency busy detection apply to 
the Automated Station initiating the connection. Also, to be as 
complete and concise as possible, such frequency busy detection needs 
to be applied to all known and legal for use digital modes around the 
world and not just detection of RF energy period ( else your station 
may never go into TX ). Doing so would force all human users to be 
courteous and standby when any real digital mode signal that is 
within their passband from any source, which will force the use of 
narrower filters for given modes or cause stations to yield to wider 
band mode operations and narrow bandwidth modes operations will have 
to steer clear of wider mode operations. Then, depending on the 
timing of who transmits first and what the forced upon you timing 
constraints of the algorithms used end up being, you just sit and 
wait for an opportunity to transmit, you may get out a CQ or other 
call but then your system detects another signal and puts you into a 
holding pattern again, should it be just any signal detected at any 
time? Should be only when both sides of signal exchange are heard so 
that your station isn't just making you wait due to another station 
CQing etc., if not full QSO detection in the given mode of operation 
then what about that "hidden transmitter" effect?. Oh, I can see it 
now, a lot more listening for everyone, the early bird gets the 
frequency for the QSO, gee what a dreamy situation, but when an ECOM 
event comes about, will they ever get a chance to send that health 
and welfare traffic in a timely manor or at all? Hopefully some of 
this has assisted you in seeing more of the complexity and down sides 
of this busy frequency detection dream Rick.

Sincerely,

/s/ Steve Hajducek, N2CKH



At 09:56 AM 10/17/2007, you wrote:

>5. For any automatic station, busy frequency detection is a must,
>however during emergency situations, you will often have human operators
>at both ends insuring that the frequency is being monitored.

Re: [digitalradio] PCALE with IC706IIG

[Steve Hajducek]

Hi Kevin,

You are using OLD software, you want the latest PC-ALE v1.062H 
Interim Build #5 which is found at the HFlink Yahoo forum.

/s/ Steve, N2CKH

At 11:02 AM 10/14/2007, you wrote:
>Steve Hajducek wrote:
> > Hi Kevin,
> >
> > If you select by model number from "Radio Type" you want your radio
> > to be using the factory address and 19200 baud.
> >
> > If you use GENERIC ICOM, which I don't recommend, then you want to
> > use the baud radio your is set to 8N1, the radio address your radio
> > is set. Don't both checking SPLIT VFO as your model is not going to
> > benefit from it due to its design.
> >
> > I say never use AUTOBAUD and keep INFORMATION set to OFF.
> >
> > /s/ Steve, N2CKH
> >
> >

RE: [digitalradio] PCALE... it's making me insane!

[Steve Hajducek]

Hi Peter,

You need to join the HFlink forum or the FlexRadio forum as not 
having a system here I can only tell you that what I coded into 
PC-ALE works when all else involved in the radio configuration is 
solid and that's about it on my end, I just don't have any feel for 
it beyond the PC-ALE side.

One last thing, CAT PTT is not the recommended form of PTT for any 
radio in my opinion for a number of reasons. Usually when its a case 
of PTT not releasing it is due to RF interference, that has occurred 
countless times with users where after working on their system 
cabling by adding common mode chokes and the like to reduce stray RF 
the issue goes away. Its usually seen during Sounding what with the 
rapid progress of coming onto a frequency and going into PTT, 
transmitting and then sending the CAT command to drop PTT, rather 
than sitting single channel, thus its seen with the ALE software 
operation and not other programs that provide CAT PTT, its something 
to due to the fast command sequence on the tail of an RF burst. It 
can be simulated with 3rd party software by timing another type 
of  Data or Voice transmission to end just as you drop CAT PTT or 
dropping CAT PTT while still providing the drive signal to see if 
under a similar set of circumstances dropping of CAT PTT will fail 
with other software, a few guys have done with systems to try to 
prove to me it was just a PC-ALE or MARS-ALE issue and seen that 
their other software hung on dropping CAT PTT as well.

/s/ Steve, N2CKH

At 08:52 PM 10/13/2007, you wrote:
> >
> >OK... I just downloaded #5.
> >
> >Note that if I use PTT to key the radio, it WORKS (yay!) -- but if I
>use
> >CAT to key the radio, the radio will key but not unkey.
> >
>
>To follow-up my own post... With PTT, keying the radio works fine, but
>CAT control (such as changing frequency) is intermittent.  It'll work
>for a while and then just stop.
>
>I suspect that there's some odd interaction between the radio control
>implemented in PCALE and N8VB's vCOM drive.  But, as a result, I'm not
>having any sustained luck running PCALE with PowerSDR.  I checked the
>HFLINK archives, but didn't see anything specific to the SDR-1000 that
>was helpful.
>
>Just reporting what I'm experiencing,
>
>de Peter K1PGV

Re: [digitalradio] PCALE with IC706IIG

[Steve Hajducek]

Hi Kevin,

If you select by model number from "Radio Type" you want your radio 
to be using the factory address and 19200 baud.

If you use GENERIC ICOM, which I don't recommend, then you want to 
use the baud radio your is set to 8N1, the radio address your radio 
is set. Don't both checking SPLIT VFO as your model is not going to 
benefit from it due to its design.

I say never use AUTOBAUD and keep INFORMATION set to OFF.

/s/ Steve, N2CKH


At 10:26 PM 10/13/2007, you wrote:
>I have been trying to get PCALE functioning with my IC706IIG.
>I cannot get the CAT function to work ie. scanning etc.
>Transmits (individual call) fine with PTT via com 1.
>I have tried using the "Generic Icom" and entering the correct address
>etc. and still no joy.
>CAT works fine on "Commander" and "HRD".
>Any help appreciated.
>
>Kevin VK5OA

Re: [digitalradio] PCALE... it's making me insane!

[Steve Hajducek]

Hi Peter,

A number of fellows tested the new radio control 
in PC-ALE v1.062H in the latest builds ( #5 being 
the most recent) with the SDR-1000 and all works 
just fine I am told, although I wrote it, I don't 
have one here to test with. If you are using DIG 
instead of USB, you need to select USB-D using 
CHANNEL > MODIFY, otherwise USB is fine. You need 
to ask your questions of the SDR-1000 owner/users 
of PC-ALE via the HFlink forum.


/s/ Steve, N2CKH

At 06:16 PM 10/13/2007, you wrote:

I’ve tried to use the PCALE program several 
times now.  Each time I try to use it, I have zero luck.


A year or so ago, I downloaded it and couldn’t 
get it to control my TS-2000.  But I heard there 
was a new version in the works, so I vowed not to write it off.


A couple of weeks back, I downloaded the latest 
version of PCALE.  Now, instead of using my 
TS-2000 I’m using an SDR-1000 (that emulates a 
TS-2000).  I religiously followed the 
instructions at 
http://hflink.com/pcale/setup/ 
about setup.   I got things linked up, more or 
less… seemingly got CAT control working 
(57.6Kbps, 8N1 – exactly how I setup MixW – 
Kenwood, etc) because I could change 
frequencies… but I couldn’t transmit (using CAT 
control).  PCALE would TRY to transmit, but I’d 
get zero output.  Worse, after exiting from 
PCALE, I couldn’t get anything ELSE on my system 
to transmit either.  Arrrgh.  After several 
restarts of the applications, and reboots of the 
system, I removed and re-installed the Virtual 
Audio Cable driver.  I didn’t get ALE to work, 
but I was able to use MixW again with my radio.  Enough success for that day.


Today, just a few minutes ago, I decided to try 
to get PCALE to work again.  ALE OTAW and all… 
what better time, right?  Yet, again, after 
diligently following the directions on 
HFLINK.COM (not that they tell you WHAT you’re 
doing, but they tell you what to DO anyhow)… my results were mixed:


a)  One time PCALE transmitted (the “@@@” 
test message – what IS that by the way?), and at 
the end of the transmission didn’t unkey the rig.


b)  Another time PCALE transmitted (the 
“@@@” test message again) and actually managed to unkey the radio properly


c)  Thereafter… no rig control, no transmit.

S… it seems like I’m having a CAT control problem.  Or something.

If I do that “@@@” thing, and my message is 
getting out, should it show up on the Bonnie 
Super Locator Whizzy Keen web page??


Anybody have any guidance they can offer as to 
what the problem may be?   I suspect bad rig 
control in PCALE, but hey… what do I know?


de Peter K1PGV

Re: [digitalradio] ALE NOCALL ISSUE

[Steve Hajducek]

Hi Guys,

You need to either use an ASCII editor like NOTEPAD and use find and 
replace on NOCALL to change to your callsign and reload the .QRG file

OR


Select an unused SCAN GROUP  where no OWN is being used and starting 
at the top menu selection Address > Modify > Own and select NOCALL 
from the pull down, click OK and edit your callisign and click OK and 
then select the SCAN GROUP of choice and then restart the tool.

/s/ Steve, N2CKH

At 04:58 PM 10/13/2007, you wrote:
>Tony wrote:
> >
> > All:
> >
> > Had to re-download PC-ALE and noticed NOCALL was
> > being transmitted instead of my callsign. I
> > entered my call during the set-up process, but
> > NOCALL seems to be set as the default. I tried
> > deleting, but keep getting the "NOCALL" in use
> > message.
> >
> > Any suggestions..
> >
> > Tony K2MO
> >

Re: [digitalradio] Ale

[Steve Hajducek]

Hi David,

I know of no *nux based native application that has been offered to 
the world yet as ready for use. There is a package for developers 
that Charles Brain and another fellow placed on SourceForge under GNU 
called LinuxALE that dates back over 5 years now, which I have not 
seen anyone make use of yet as to developing a *nix application.

A number of MARS members are running MARS-ALE under WINE, here my 
Linux boxes are not up to doing so as they are all older IBM PC 325 
servers, two for IRLP nodes running Red Hat 6.2 that I really need to 
go and update, one is a 7.3 box and the other is a 9.x server, but 
nothing above 300Mhz. Since I got back into programming I have only 
been developing code for MS-Windows, although I keep thinking about a 
Linux box as a stand alone modem/controller to select for use by 
MARS-ALE, were said box would have no GUI, it would just be a 
modem/controller, a monitor, keyboard and pointing device would not 
even be needed. Then again, I also think about a RTOS on a single 
board CPU or MCU modem/controller as well, its just the price point 
of such new and time all around to make things happen.

/s/ Steve, N2CKH

At 06:26 AM 10/3/2007, you wrote:
>Hi All...have been reading with some interest and some wondering about
>this program ALEi know it is written for Windows but im wondering
>if an attempt has been made to port it to Linuxyes there are a
>large number of Hams worldwide who operate with Linux in one form or
>another...ive been using Linux distros for about 6 years and i would
>not go back to Windows...am i being left out of part of the digital
>reveloution in Ham Radio because im not in the so called main stream...
>
>David VK4BDJ

Re: [digitalradio] interesting piece by K1ZZ

[Steve Hajducek]

Hi Andy,

The FCC rules don't actually require changing WRT ALE other than to 
satisfy those that want to see things spelled out in black and white 
specifically approving or disapproving each and everyone little 
thing. This is not the intent of the FCC to constantly be updating 
the rules to specify all new things that come along in the world of 
technologies and practices. Instead they have written the rules to 
broadly cover everything as much as possible.

As an ARRL Official Observer station, my initial interpretation of 
the FCC rules WRT full ALE operations where questionable, even though 
I code the ALE software beginning with my efforts in support of 
MARS-ALE and now PC-ALE as well. You may even recall my exchanges 
with Bonnie on the subject via this forum, to the point where she 
just wanted to agree to disagree. I have never written an OO notice 
regarding any use of ALE and no other ARRL OO has even done so 
either, the reason being that the ARRL OO program and the FCC have no 
issues with Amateur Radio ALE operations, once that was clear to my 
satisfaction I took a much more active role in Amateur Radio ALE in 
addition to my MARS focus. So Rick can compile his list of questions 
and so can anyone else, however ALE is not new, it has been around on 
the Amateur Radio bands for over 10 years now, and written about in 
QST and QEX and the ARRL has a web page ( 
http://www.arrl.org/tis/info/ale.html ) on the subject and all things 
8FSK ALE is just fine with the FCC. That is not the case with all 
things MIL-STD-188-110x modem related (which many incorrectly assume 
is also ALE) under the present rules however, that modem and FS-1052 
found in PC-ALE or RFSM etc. is not legal for non image data transmissions

As I stated in my earlier message, due to all of its benefits and 
more ALE options, ALE in my opinion will become more common in ARS 
use, especially for ECOM, its application will leave that realm of 
the sophisticated user in the know and enter the realm of everyone 
having access to it if they are interested in it, PC-ALE and MultiPSK 
users of ALE are increasing daily, its legal, its an efficient 
propagation tool, its a wonderful BBS tool, after the ALE link any 
protocol can be used for follow on communications, its easy to use 
and its fun to use, its also on the Sound Device Modem which is the 
modem of choice for the ARS.

Anyhow, there are 2897 members of this forum of your Andy and I have 
challenge for everyone with a sound card interface, download the 
latest PC-ALE 1.062H Interim build, install and configure it and use 
it during the coming "ALE On The Air Week, October 5 - 15" starting 
this weekend. I will even be coming out from behind the C++ coding of 
the ALE tools to participate. Those not already configured had better 
get started as the clock is ticking, the more stations on the air 
with ALE the better it will be to stress test the Amateur Bands for 
those so called ALE negative effects, however I warn everyone, you 
may just get hooked on ALE! As this is a worldwide event, for those 
that love DXing, if you think Packet Cluster Spotting works, wait 
until you see real time DX station Soundings spotting where the given 
band you are Scanning is starting to open or dying, in near-real 
time, no Spotting Network or Propagation Tool can beat, one or more 
DX ALE Sounding stations in each country of the world depending on 
geographic area of the country would make for a fantastic world wide 
DXing tool, ALE is actually the most versatile HF communications tool 
yet devised and its just getting better and as Bonnie stated earlier 
newer ALE technology and techniques enable even higher efficiency 
levels, using very short bursts, and GPS synchronization... while 
maintaining backward  compatibility with the regular 2G ALE (141) 
that is the current defacto international standard.

I look forward to working stations this weekend, I will be running 
MARS-ALE and accepting AMD, DTM, DBM traffic ( my MIL-STD-188-110 
modem will be off. My KAM TNC will be enabled under MARS-ALE in 
PACTOR I as default, anyone who connects can send an AMD Orderwire 
message to switch it to GTOR and then initiate a GTOR link instead if 
they like using the following 12 character AMD message:

 >>CMD GTOR<<

If you want to switch to another protocol after the ALE link, be glad 
to hit the release RESOURCES button ( frees Sound Card, CAT RS232 
port and maintains ALE link) to change over to any common Amateur 
Radio Sound Card protocol. Those using PC-ALE can do as well and 
depending on their interfacing for PACTOR or GTOR etc. may also need 
to hit the RESOURCES button for radio PTT access using a 3rd party 
tool for the control of their TNC/Modem.

See you all in the "ALE OTAW".

/s/ Steve, N2CKH

At 09:13 PM 10/2/2007, you wrote:
>Seeing how useful PC-ALE is, I have to imagine a time when that is how
>most HF communication is attempted.  If it requires brief "soundings"
>that are consi

Re: [digitalradio] Re: interesting piece by K1ZZ

[Steve Hajducek]

Hi Jim,

It sounds almost like you are making case to abolish all forms of 
Amateur Radio Contesting with this argument of yours, no where in the 
FCC rules are contesting ( which by the way I enjoy ) mentioned as 
such, actually many of the FCC rules could be used to make an 
argument against contesting if one wanted to do so. Hi Hi

/s/ Steve, N2CKH

At 10:25 PM 10/2/2007, you wrote:
>The only problem I see with this is how several tens of thousands or
>even hundreds of thousands of hams are going to do 10-20 seconds of
>sounding even using whole segments of bands.  There won't be any room
>or time for actually talking!  I just don't see this being good for
>"most HF communications".
>
>Jim
>WA0LYK

Re: [digitalradio] interesting piece by K1ZZ

[Steve Hajducek]

Hi John,

For ARRL members, that piece was on page 9 of the Oct 2007 QST.

More and more ALE will become integrated into the Amateur Radio 
Service (ARS) do to its significant advantages, it is just such an 
obvious path to take with respect to the role that the ARS plays in 
ECOM support for one thing in my opinion.

This would have happened 10 years ago or more if it were not for the 
cost of ALE hardware and the fact that no PC software solution was 
available, but that is now changing on both fronts what with free 
software and hardware manufacturers getting near the $1000USD price 
point for a complete ALE transceivers and TNC's with ALE likely to follow.

Reading the various comments on this and other electronic forums of 
those that are not, let's say, pro ALE, reminds me of all the that I 
have read and heard about when other advances came along to the ARS 
prior to my becoming a Radio Amateur and those that I witnessed first 
hand, change for many is just not easy to accept, not matter the benefit.

Anyhow, all things ALE with respect to the Amateur Radio Service are 
really just getting started, I think it will be very interesting to 
look back at it in a few years, especially when we start seeing 
CODEC's in transceivers with a USB port, I was very excited to see 
that in the ICOM R1500/2500 receiver that I added to MARS-ALE over a 
year ago and recently to the PC-ALE baseline, getting the CODEC out 
of the PC is huge WRT noise and jitter, just why it is taking so long 
to see it turn up in transceivers when the ARS has long ago now 
standardized on such communications software I don't quite 
understand, I hear the Elecraft K3 may be doing so and I hope to see 
the new IC-7200 have an internal CODEC, it does not look like one is 
coming in the IC-7700 from what I have read to date, who knows maybe 
Kenwood or Yaesu/Vertex or even Ten Tec has something in the works?

/s/ Steve, N2CKH


At 10:44 AM 10/2/2007, you wrote:
>piece on Interoperability.
>
>http://www.arrl.org/news/features/2007/10/01/1/?nc=1

Re: [digitalradio] Re: PC-Ale & TS-480

[Steve Hajducek]

Hi Joe,

You must be using PC-ALE v1.062H ( build #2 should be used) for the 
support of the IC746PRO data port, when you use ADD or MODIFY 
channels you need to select USB-D and not USB.

When using the "Radio Type" selection of 746PRO you need to use the 
factory address and 19,200 baud, if you want to use other then you 
need to select GENERIC ICOM and use the "Radio Port" interface and 
enter the Address and select Split VFO as well. I recommend that you 
use the normal 746PRO selection. I also recommend that AUTO BAUD not be used.

You will find lots of users on the HFlink forum that have the 746RPO 
in use that you can chat with.

/s/ Steve, N2CKH


At 05:49 PM 9/24/2007, you wrote:
>I am not able to get the program to work with an Icom IC746 Pro. 
>Nothing works. I selected the 746 and set the address to 66 and 
>nothing works, PTT, Scan or anything else. I am using the DATA jack 
>on the rear.
>
>Joe
>W4JSI
>

Re: [digitalradio] Re: PC-Ale & TS-480

[Steve Hajducek]

Hi John,

I sent you a direct e-mail with screen caps that should get you going.

/s/ Steve, N2CKH

At 04:32 PM 9/24/2007, you wrote:
>well I d'loaded the not quite latest version as Steve suggested, and , as
>before, I can copy stations but cannot transmit anything, except using VOX.
>
>The comms port just doesn't see my rig under this software, but it works
>fine with the Kenwood CAT program, Mix W and MultiPSK. The CAt side is not
>working since I cannot change frequencies or scan using PCALE.
>
>I am not using an interface, rather chose to go direct from the data port to
>the computer as Kenwood suggested, and have the serial cable
>running from the rig to the computer for rig control. With other digital
>software I have been using VOX for TX/RX , which has worked fine,
>and also used the PTT functions as well from time to time.
>
>I deleted the ALE.dat file as you suggested, to no avail. I have also cold
>booted my computer and the software several times during this
>process , again without any effect.
>
>Would be very interested in the settings you are using, at least would be a
>starting point. please include the menu settings on the Kenwood as well
>so that I can duplicate what you are using.
>
>Thanks
>
>John
>VE5MU

RE: [digitalradio] ALE standards work fine Re: [hflink] ARQ FAE

[Steve Hajducek]

Hi Rud,

In my opinion there is already a better ALE, it is Alternate Quick 
Call (AQC) ALE which improves upon ALE in a number of ways as 
detailed in MILl-STD-188-141B where a number new features have been 
added ( such as shorter linking cycles, 6 character maximum SELCALs, 
PSK burst mode etc.) and some older aspects of ALE have been dropped 
that result in a much faster and more robust 8FSK ALE system.

However the ALE hardware manufacturers have not jumped on it aside 
from those providing real Military Grade ALE radios and then charging 
even more money for them. You can't find AQC-ALE in CODAN, MICOM or 
other commercial ALE radios yet, but for years now AQC-ALE has been 
in PC-ALE and MARS-ALE, I know of no other software ALE tools that 
have support for AQC-ALE in two-way communications at this time. In 
my opinion, Amateur Radio operators should move forward to all 
AQC-ALE operations, but that is just my opinion.

Anyhow, tell me if what you are seeking is in the way of the 
following type of information after you have time to read the report 
at:  http://www.hfindustry.com/jun02/presentations/wp9c_rpt.doc

/s/ Steve, N2CKH



At 11:06 AM 9/24/2007, you wrote:
>Hi Steve,
>
>My first response to you may have been over the top because of others
>previous messages. My apologizes.
>
>I want to compare the ALE waveforms with other existing waveforms. This is
>difficult because the values reported by ALE do not conform to normal
>standards for digital communications. I think I can roughly map the ALE SN
>to standard analog SNR. The bit error rate is elusive. I am working from the
>ALE milspec. I am asking that you show me some numbers for the assertion
>that
>
>"ALE is not just a possible candidate, for the fastest and most
>reliable means of connecting with stations of interest on HF on the
>best BER/SNR channel it is the best !"
>
>I ask not because I am trying to trash ALE but to determine where
>improvements are needed so in 2-5 years there are better ham digital
>protocols.
>
>
>Rud Merriam K5RUD
>ARES AEC Montgomery County, TX
>http://TheHamNetwork.net
>
>
>
>
>Announce your digital presence via our Interactive Sked Page at
>http://www.obriensweb.com/drsked/drsked.php
>
>Yahoo! Groups Links
>
>
>

Re: [digitalradio] ALE yes ... or no?

[Steve Hajducek]

Hi Rick,

That reference is to Government/Military HF e-mail topology which has 
evolved to the STANAG 5066 standard pretty much across the board, 
however not everyone is there yet due to costs and time to update 
their network infrastructures. STANAG 5066 can basically be thought 
of as what you know the Internet to be via your PC and ISP provider, 
however its done via HF radio, HF and above.

ALE is what it has always been to the network topology for selecting 
the best ranked LQA channel for follow on traffic, that has not and I 
do not any time soon see that changing.

It is the follow on traffic that continues to evolve whereas the 
Government and Military user needs speed to support the traffic load 
they have and thus the use of newer waveforms on MIL-STD-118-110B modems.

There are many things that are dumped into 3G ALE, just remember 
this, if we are talking an ALE network, then ALE (or AQC-ALE) is 
always used to establish the link on the best LQA ranked channel.

However there are also point-to-point links, backbones and networks 
in operation that just make use of the the high speed modems and 
protocols due to their particular support scenarios where either 
nodes are plentiful or ground wave is all that is being covered or 
operations are VHF+ etc.

/s/ Steve, N2CKH

At 10:10 AM 9/24/2007, you wrote:


>Do the 3G protocols still support the 8FSK125 waveform and this is used
>for the initial signaling and linking and then you switch over to the
>other PSK modes?  If they do, then what is he saying in his above statement?
>
>73,
>
>Rick, KV9U

Re: [digitalradio] ALE yes ... or no?

[Steve Hajducek]

Hi Rick,

Patricks FAE ARQ is an excellent protocol, it is the best example to 
date in my opinion of a PCSMD based ARQ protocol developed for Amateur Radio.

The ALE 8FSK is not being replace by serial tone modem use for its 
Sounding/LQA/Calling/Linking, believe me that is not going to happen. 
Just what will replace ALE as we know it now will likely be AQC-ALE 
at some point, but that is not happening fast what will the large 
number standard ALE systems in use and the cost of hardware AQC-ALE systems.

What has already taken place in the U.S. Government/Military and NATO 
world is a transition to the MIL-STD-188-110B modem and various 
waveforms for heavy follow on data requirements in peer-to-peer and 
networking where STANAG 5066 is the topology for distributed 
networking where you must have speed what with its HTML support, 
after all you for all intents and purposes talking the full Internet 
via HF radio with STANAG 5066 ( not to be confused with S5066 DLP).

However, the good old 100wpm FEC 8FSK is still used for an awful lot 
of ALE signaling, remote orderwire command and control and 
communications just using the basic AMD protocol. It gets a lot of 
use for signaling application where Radio Amateurs would use DTMF, 
automated phone patches are a heavy user of AMD actually, the ACP193 
protocol and SWALE protocol are fine examples of just what can be 
done with the excellent AMD basic protocol.

/s/ Steve, N2CKH

At 10:55 PM 9/23/2007, you wrote:
>I had very good luck testing FAE with Sholto, KE7HPV yesterday evening.
>The 8FSK125 waveform is a fairly old design. They would not be using FSK
>if they were developing a new mode. From what I have been reading, the
>government/commercial long term plan for the MIL-STD/FED-STD/STANAG's
>will replace that modulation with the single tone modem protocol.

RE: [digitalradio] ALE standards work fine Re: [hflink] ARQ FAE

[Steve Hajducek]

Hi Rud,

Sorry that I could not be of help in getting you squared away with 
your understanding of ALE.

/s/ Steve, N2CKH

At 07:14 PM 9/23/2007, you wrote:
>See my main comment inline below...
>
>This is likely my last response to these messages. I have better things to
>do than argue with a group that is picking a fight with me over some
>objective statements. Interestingly nothing said specifically refuted my
>statements.
>
>Rud Merriam K5RUD
>ARES AEC Montgomery County, TX
>http://TheHamNetwork.net

Re: [digitalradio] Re: ALE yes ... or no?

[Steve Hajducek]

Hi John,

Using PC-ALE v1.062H Interim build 2 from the HFlink forum files 
section ( forget build 3, it has an issue), just select radio type 
KENWOOD or if you want to use RTS/CTS handshaking, KENWOOD_HS and if 
your radio supports more than 4800 baud, click on "Radio Port" and 
provide the Baud Rate ( up to 240,000 supported for TS-480) , Data 
bits, Stop Bits and Parity ( the other items are not needed and don't 
matter ) and click OK and then OK again, if your radio is powered and 
attached and the proper COM port ( 1 thru 16) has been selected, it 
will be found and you will get a message telling you so.


/s/ Steve, N2CKH

At 07:19 PM 9/23/2007, you wrote:
dunno. But darn near impossible to get a Kenwood running on 
PCALE. Have a TS480


John
VE5MU

RE: [digitalradio] ALE standards work fine Re: [hflink] ARQ FAE

[Steve Hajducek]

GM Rud,

At 12:56 AM 9/23/2007, you wrote:
>Quite all right being blunt with me Bonny. I am learning about HF protocols
>and part of them will be mean getting slapped down about misinformation. I
>am deed-restricted so have some problems getting HF. But I am addressing
>them so I may get onto the HF waves with at least an NVIS setup in the near
>future. ALE will be a possible candidate for operation.

ALE is not just a possible candidate, for the fastest and most 
reliable means of connecting with stations of interest on HF on the 
best BER/SNR channel it is the best !

Their are other SELCAL systems on HF, some of which such as the Rhode 
& Swartz and the Tadiran 4FSK proprietary systems are some what 
popular and basically just copies of standard ALE, but ALE accounts 
for the majority of all SELCAL systems and now the majority of all HF 
digital signals on HF period world wide with the bulk of all use is 
with 100w or less transceivers.



>However, I will stand by my statements. ALE is achieving 375 bps in 2.5 kHz
>and >0 db. (Info from http://hflink.com/technical/ and current Channel 0
>statistics.] That is not terrifically good at just under .15 bps per Hz. It
>certainly comes nowhere close to the theory, as expressed in the table.

You need to do the math here Rud, the lowest frequency tone is 
centered at 750hz and the highest is 2500hz , overall the ALE signal 
BW is under 2Khz of spectrum with a properly setup ALC


>The reason it is acceptable for the military is because (1) they can put out
>the power to get a good SNR or (2) they are doing short distance with man
>packs so the SNR is acceptable.
>
>Amateur are trying to do word-wide communications with 100w. Despite the
>fact that we can do more, most do not or cannot go beyond that 100w for
>various reasons. So a ham mode should start with 100w as a maximum output as
>a consideration on the attainable SNR.

You really need to get on the air!


>Pragmatically, most of the articles indicate that existing protocols only
>get with 10 dB of the theory. Turbo codes do much better and theoretically
>LDPCs should do even better (within a dB or so).

Theorectical is just that!


>So in response to Demetre's original question, yes, 375 bps in 2500 Hz is
>not that great. There is a lot of room for improvement.


The ALE signaling, AMD and DTM BRD(FEC)/ARQ protocols are all using 
the same 375bps/100wpm data rate with no interleaving, the DBM 
BRD(FEC)/ARQ protocol is deeply interleaved to a factor of 3x and 
performs as well as or better than GTOR and PACTOR I.

>I think HFLink is doing a great job so don't take this as any kind of
>bashing. We all would like to see better protocols developed and that is my
>goal with The Ham Network. IMO a protocol developed for non-ham use is a
>good place, possibly, to start but not the one for hams to hang their hats
>on for the future.

ALE is not just an HF protocol, ALE is an HF SELCAL networking system 
that provides its own BRD (FEC) and optional ARQ protocols, however 
the follow on protocols for digital communications can be anything, 
most ALE hardware radio systems these days only offer the AMD 
protocol as its required by the standards, some offer DTM ARQ and DBM 
ARQ standard or as options, but most offer nothing or high speed 
MIL-STD-188-110 modems and waveform options. The Commercial, 
Government and Maritime ALE user tends to use commercial TNC/Modem 
based protocols, although the U.S. Government is now making a big 
move to MIL-STD-188-110 modems and STANAG 5066. In MARS we are 
heavily using all of the above, the MARS-ALE users has both the PCSDM 
and external TNC/Modem options and at a push of a button can release 
PCSDM and RS232 port resources ( I just added this to PC-ALE as well) 
to use 3rd party tools with those resources so that any protocol can 
be used for peer-to-peer follow on while maintaining the ALE linked 
state. So as you can see if the ALE LQA and its (at you paint the 
picture, poor) 375bps FEC protocol does its job in communicating the 
BER/SNR ( which I must again tell you it does an excellent job at 
doing) then an ALE station will always be aware of the best ranked 
BER/SNR channel for use and the choice of protocols for follow on 
digital communications is up to those involved.

/s/ Steve, N2CKH

>
>Rud Merriam K5RUD
>ARES AEC Montgomery County, TX
>http://TheHamNetwork.net
>
>
>-Original Message-
>From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On
>Behalf Of expeditionradio
>Sent: Saturday, September 22, 2007 3:22 PM
>To: digitalradio@yahoogroups.com
>Subject: [digitalradio] ALE standards work fine Re: [hflink] ARQ FAE
>
>
> > Rud k5rud wrote:
> > My recent readings indicate that the ALE standards
> > are _NOT_ good for ham use because the military is not power
> > limited. They can attain good SNRs because of this.
> > Hams are not able to do this.
>
>
>Hi Rud,
>
>Sorry to be blunt, but your opinion about ALE standards is simply
>wrong. :)

RE: [digitalradio] Re: [hflink] ARQ FAE

[Steve Hajducek]

Hi Rud,

Yes, the Military and Government HF users can and do at times operate 
with more RF EIRP that we Radio Amateurs have licensed limits for operating.

However, WRT ALE at least, its not needed and the bulk of HF Military 
activity is usually within NVIS ranges as its tactical, and with NVIX 
100 watts or less is the rule for two reasons, one being multi-path 
when operating more power and the other being the heavy use of man 
pack ALE radios.

When operating Ground Wave and Skyway vehicular and base stations 
typically run 100, 500 and 1Kw, all power ranges within Amateur Radio 
limits in most parts of the world. Airborne stations also typically 
operate at 100 and 500 watt levels.

Ships at sea too work 100 to 1Kw levels and often more for some 
reason that I can't explain.

I can however tell you that those man pack radios usually run no more 
than 20 watts and represent the bulk of HF ALE operation with 
Military forces communicating with other operational forces on the 
front line and to the rear areas to their air and sea transport contingents.

In MARS, the majority of all operations are below 100 watts period. 
The majority of all ALE operations are below 50 watts using 100 watt 
transceivers and the MARS-ALE software. No one is running more than 
100w when operating in NVIS using ALE or other digital modes due to 
multi-path issues, especially on State nets and in some states that 
are very hilly stations decrease power as much as possible to limit 
multi-path efforts during digital mode operations.

/s/ Steve, N2CKH

At 11:15 AM 9/22/2007, you wrote:
>Here is a table I generated in Excel. I will get something up on The Ham
>Network to do calculations, or put up the spreadsheet.
>
> SNR C/BWBW/CBW for
> (db)(bits/s/Hz)(Hz/bits/s)  1200 bps
> --- --
> -30 0.0014  693.4937832192
> -20 0.0144  69.6607 83593
> -10 0.1375  7.27258727
> 0   1.  1.1200
> 10  3.4594  0.2891 347
> 20  6.6582  0.1502 180
> 30  9.9672  0.1003 120
> 40  13.2879 0.0753  90
> 50  16.6097 0.0602  72
> 60  19.9316 0.0502  60
> 70  23.2535 0.0430  52
>
>C = channel capacity in bps
>BW = bandwidth
>
>These are normalized by bandwidth so the rightmost column is just the BW/C
>column times the desired rate of 1200 bps. I find it interesting that once
>the SNR is less than 0 the bandwidth goes up by a factor of 10 for each -10
>db.
>
>The second column from the left (C/BW) is the bit rate per Hz of bandwidth.
>
>I also need to get the calculations that are more applicable to digital
>communications. Instead of power SNR they are expressed in Eb/N0 still with
>units of db. Eb/N0 is the SNR for a single bit. See
>http://thehamnetwork.net/wiki/#Shannon-Hartley%20%5B%5BShannon%20Limit%5D%5D
>
>One aspect of that I need to figure out is why -1.6 db (Eb/N0) is the
>asymptotic limit, i.e. nothing goes through the channel beyond that limit.
>
>The challenge hams face is twofold. First our transmitters are power
>limited, typically 100w or less. Second, the bandwidth available is limited,
>typically less that 3 kHz. My recent readings indicate that the ALE
>standards are _NOT_ good for ham use because the military is not power
>limited. They can attain good SNRs because of this. Hams are not able to do
>this.
>
>
>Rud Merriam K5RUD
>ARES AEC Montgomery County, TX
>http://TheHamNetwork.net

Re: [digitalradio] Here's some frequencies for unattended HF operations

[Steve Hajducek]

Hi Andy,

Frequencies are are required on all the Amateur Radio band assets to 
deal with the changes in propagation 24/7. As a matter of fact, the 
Amateur Radio Service does not have enough allocations to actually 
deal with 24/7 propagation changes, a key reason for the WARC bands 
in '79 and the recent 60 meter allocation. We have another hole in my 
opinion between 40m and 30m, but one which will be very hard to find 
any space world wide.. An another hole between 30m and 20m, which we 
again, will be hard to find any space world wide. We very lucky to 
get a foot hold in the 5Mhz band, which we can hopefully grow.

/s/ Steve, N2CKH

At 01:49 PM 9/22/2007, you wrote:
>I'm an odd ham in that I smile with amusement when amateur radio
>groups rush to "defend" frequencies and worry about some non-hams
>getting "our" frequencies.  I happen to think we have more than we
>need and can easily give some away.  With that in mind , here are some
>freqs for PACTOR and ALE stations to inhabit.  They can then do their
>unintended "thing" til their heart's content.
>
>
>1808 to 1815
>3577 to 3584
>The entire 60M band (a good band, and we don't need it for anything else)
>14.105 to 14.110
>24.890 to 24 .925
>
>That's it, nothing else.
>
>The above frequency allocations would be sufficient for PACTOR BBS,
>automatic ALE soundings ,  ALE SMS messaging, and PSK MAil servers   .
>  ALE, PACTOR and others could use other allocated digital sub-bands
>but not unattended.  No busy detection required (optional) in the"
>automatic zones" , mailbox operators would work out their voluntary
>QRV schedules via their "Frequency Coordination Council"  .  The above
>frequency ranges would give PLENTY of room for message traffic and
>emergency communication drills.
>
>Yes, no 40, 30, 17,15,10, freqs...simply not enough demand  and no
>real propagational needs.
>
>OK, now off to have lunch with the FCC chairman, see if can implement
>in the USA by next Friday.  Rest of the world, they'll just have to
>adjust :>)
>
>Andy k3UK

Re: [digitalradio] Re: Busy Detectors

[Steve Hajducek]

Hi Jim,

You really must be making a tongue in check joking reply here, that 
is the only way that I can take such a reply as the Amateur Radio 
bands have been broken down into specific use for decades and ever 
changing. I can NOT go down to 14.004Mhz and make a SSB contact as it 
is dedicated to CW as a prime example. On the other hand I can not go 
into the dedicate Phone and lessor Image sub bands and use MT63.

In my opinion, tor the Amateur Radio Service to continue it needs to 
constantly change and adapt to the times and the needs of those that 
the ARS serves and I see it, that does not mean the individual that 
just wants to Rag Chew or Chase Paper ( which I love to do by the 
way), but the larger picture overall and in this day and age that 
also means providing for higher speed digital communications at 
greater BW in support of traffic automation with multiple routing and 
embedded document support for HF e-mail. Creating a sub band for 
traffic automation which has basically always been done, but still 
allowed for peer-to-peer in the mix ( which as always a stupid 
approach) where the sub band is set aside such activity only, keeping 
it away from peer-to-peer and keep peer-to-peer away from it seems to 
be the best solution as then, the only interference to and from such 
activity would be from such activity, it really makes sense to me and 
hopefully it will make sense to those who regulate the Amateur Radio 
Service at the world level.

/s/ Steve, N2CKH


At 11:20 AM 9/18/2007, you wrote:
>   Once you set
>a precedent that amateur spectrum can be "assigned" to a specific use,
>you open the doors for everyone to claim their piece of the pie.  Just
>exactly how would you propose to deal with this?

Re: [digitalradio] Re: Busy Detectors

[Steve Hajducek]

Hi Jim,

A good analogy of sharing spectrum between peer-to-peer and 
remote-to-automated is like a car or any size sharing a single road 
lane with a tractor trailer, where both are competing to have the 
lane, the outcome is clear in the long run, however what would be 
better, especially for the car, is separate lanes for like vehicles 
of transport.

Within the current Amateur Radio Service rules and regulations the 
limitations imposed and conflicts caused  are not in the best 
interest of the future of the ARS and many of the purposes for the 
ARS existence in my opinion.

I am in agreement with the point you make below to the extent that we 
need to convince the powers to be that bandwidth and mode spectrum 
allocation is needed. In addition, I believe that in the digital 
world of peer-to-peer vs. remote-to-automated applications,  sub band 
management, call it arrogant or anything else you like, it is the 
only logical and 100% effective way to mitigate co-channel 
interference between these two categories of operations where the ARQ 
based operations in either category suffer the least amount of 
negative affects.

/s/ Steve, N2CKH

At 11:09 PM 9/18/2007, you wrote:
>Until someone can convince the FCC to change tradition and move away
>from shared amateur spectrum to a assigned channels for different
>modes/purposes, we will need to share.

Re: [digitalradio] Re: Busy Detectors

[Steve Hajducek]

Hi Jim,

You really must be making a tongue in check joking reply here, that 
is the only way that I can take such a reply as the Amateur Radio 
bands have been broken down into specific use for decades and ever 
changing. I can NOT go down to 14.004Mhz and make a SSB contact as it 
is dedicated to CW as a prime example. On the other hand I can not go 
into the dedicate Phone and lessor Image sub bands and use MT63.

In my opinion, tor the Amateur Radio Service to continue it needs to 
constantly change and adapt to the times and the needs of those that 
the ARS serves and I see it, that does not mean the individual that 
just wants to Rag Chew or Chase Paper ( which I love to do by the 
way), but the larger picture overall and in this day and age that 
also means providing for higher speed digital communications at 
greater BW in support of traffic automation with multiple routing and 
embedded document support for HF e-mail. Creating a sub band for 
traffic automation which has basically always been done, but still 
allowed for peer-to-peer in the mix ( which as always a stupid 
approach) where the sub band is set aside such activity only, keeping 
it away from peer-to-peer and keep peer-to-peer away from it seems to 
be the best solution as then, the only interference to and from such 
activity would be from such activity, it really makes sense to me and 
hopefully it will make sense to those who regulate the Amateur Radio 
Service at the world level.

/s/ Steve, N2CKH


At 11:20 AM 9/18/2007, you wrote:
>   Once you set
>a precedent that amateur spectrum can be "assigned" to a specific use,
>you open the doors for everyone to claim their piece of the pie.  Just
>exactly how would you propose to deal with this?

RE: [digitalradio] Re: Busy Detectors

[Steve Hajducek]

Hello Rud,

How often does a remote users sending traffic through an automated 
station have to wait due to an exasberated number of ARQ retries due 
to stations purposely transmitting CQ's or whatever just because they 
don't care that its not a two-way QSO that is inhabiting the channel. 
It's more than a two way street, worst when you consider that the 
human factor does what it does knowingly and without regard to the 
remote automated station user.

Again, what is really needed for the ARS to grow and continue to be 
of value is set aside spectrum for traffic automation where 
peer-to-peer steer clear, then we shall have the best of situation. 
Until that happens its just going to be what we have now, which is 
not the best situation from either perspective.

/s/ Steve, N2CKH

At 02:46 PM 9/17/2007, you wrote:
>How many times is a QSO busted because neither the attended or unattended
>stations could hear the QSO?
>
>I suspect this happens more frequently than most like to consider. It is
>easier to get aggravated.
>
>
>Rud Merriam K5RUD
>ARES AEC Montgomery County, TX
>http://TheHamNetwork.net
>
>
>-Original Message-
>From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On
>Behalf Of Dave Bernstein
>Sent: Monday, September 17, 2007 1:23 PM
>To: digitalradio@yahoogroups.com
>Subject: [digitalradio] Re: Busy Detectors
>
>
>When an attended station attempts to activate an unattended automatic
>station on some frequency, an ongoing QSO on the same frequency could
>be inaudible to the attended station, but easily copied by the
>unattended station; from the perspective of the attended station, the
>participants in that ongoing QSO are hidden transmitters. A properly
>configured busy detector in the unattended station would prevent the
>ongoing QSO from being QRM'd -- the unattended station would simply
>not respond to the attended station's attempted activation because it
>knows that by doing so it would QRM an ongoing QSO.
>
>
>73,
>
>Dave, AA6YQ
>
>
>
>Announce your digital presence via our Interactive Sked Page at
>http://www.obriensweb.com/drsked/drsked.php
>
>Yahoo! Groups Links
>
>
>

Re: [digitalradio] Re: QRL ? Busy detect ALE

[Steve Hajducek]

Hi Andy,

Yes you are missing the key item with this support, its called "Voice 
Detect", not "Busy Detect"! As such its looking for channel acty that 
is Voice or Voice like ( which is what I hate about this item) to 
hold off transmitting.

In Amateur Radio as in most applications of ALE, you have scenarios 
where ALE is used in a multi-mode environment of digital signaling, 
digital data, digital voice and analog voice, Voice Detect looks for 
Analog Voice. Thus with respect to Amateur Radio it would not be used 
in the digital subbands but rather the Voice subbands so as not to 
transmit where ALE can be used in limited ways due to Amateur rules 
in many areas, especially here in the U.S.

In MARS, and most all Government and Military operations, all modes 
utilized are done so on the same channels ( for the most part ) and 
as such Voice Detect keeps an ALE Sounding or Linking Call from 
stomping on an Analog Voice contact, predicated on the timing the 
sample period to detect the analog voice and the analog voice channel 
acty, which is why no form of busy channel, be it Voice Detect or 
other will ever be perfect unless one is looking to detect a signal 
that is always active, in which case the channel is for the most part 
useless ( unless said signal can be overcome by EIRP).

I find all this channel busy detect crap rather funny myself, I know 
such a statement is going to bring out the flames, but intentional 
interference is one thing, however system automation for digital 
communications where one end of the equation is automated and the 
goal is for the Remote Attended station to grab the Automated station 
for access to send and receive e-mail is not interference, the 
stations that are operating on the same spectrum should know better, 
its that simple.

Really what should be done at the next WARC is set aside 10, 25, 50 
to 100Khz (depending on the spectrum size of each given band in 
question) off little used Voice spectrum on the bottom of each band 
that goes mostly unused except for contests of the occasional rare DX 
station that pops up for much more useful daily Traffic Automation 
Systems using 3Khz channels ( or better ) with no symbol rate 
limitations where no peer-to-peer contacts are NOT allowed in my 
opinion, there is just so much Phone spectrum going to waste its just 
stupid, especially consider the benefits it provided by Traffic 
Automation. Such a move would be a move in the right direction for 
the future of the Amateur Radio Service.

Sincerely,

/s/ Steve, N2CKH



At 05:12 PM 9/16/2007, you wrote:
>I tested PC-ALE on a 21 meter broadcast signal at S5 (both AM and SSB)
>, an S3 20M CW signal and and S5 military RTTY signal on 30M-- In each
>situation PC-ALE listened for a few brief seconds and then switched to
>transmit.
>
>Perhaps there is a setting I am missing ?
>
>
>Andy K3UK
>
>digitalradio@yahoogroups.com, "Andrew O'Brien" <[EMAIL PROTECTED]> wrote:
> >
> > Has anyone experimented with busy detect in PC-ALE ?  I think Bonnie
> > and others have mentioned that it does have such capability.  I did
> > notice the other day that my sounding did not activate on 40M , I
> > wondered why but think it may have been related to the busy detect,
> > there was a strong broadcast signal present.  I wonder how much signal
> > it takes to postpone a PC-ALE sounding?  I may do some experimenting
> > and write a QRG file with some known broadcast signals, see if it goes
> > to sounding while a signal is present.  WWV freqs might be worth a
> > test too.
> >
>
>
>
>Announce your digital presence via our Interactive Sked Page at
>http://www.obriensweb.com/drsked/drsked.php
>
>Yahoo! Groups Links
>
>
>

Re: [digitalradio] So there I was -

[Steve Hajducek]

Hi Rick,

Take any non-GUI or even a GUI OS that has been tailored down for the 
embedded application at hand that is running sufficient CPU/RAM and 
you could implement a PI through PIII solution if SCS would allow it.

PII and PIII if fully documented could be done using a PC Sound 
Device Modem (PCSDM) solution, but to be compatible with SCS hardware 
PACTOR x, you still need PI for the linking before moving forward to 
PII and above and that along with the fact that SCS does not grant 
permission to implement above PI via the PCSDM is the hitch in doing 
so under a multi-tasking OS.

In my opinion what SCS has been doing over the years is basing their 
system on the best of other systems, PACTOR I being a hybrid of 
PACKET and AMTOR. Then later after a good long study of U.S. MIL-STD 
and NATO STANAG modems and waveforms, adding PII waveforms and 
protocols to the mix after the PI link step, and later PIII. Its all 
similar to having an ALE link step followed by MIL-STD/STANAG 
waveforms which is the world standard in Government/Military 
communications. If you look at PIII and those MIL-STD/STANAG modems 
and waverforms you will see all the similarities, but not all the 
benefits as ALE offers a full HF networking solution whereas PI does 
not, its just an ARQ 2FSK 2 raw speed protocol similar to ALE DBM ARQ 
which GTOR is heavily based. What would be best for the Amateur Radio 
service is getting the various world regulatory issues addressed ( 
such as with the FCC here in the U.S. ) to pave the way for all Radio 
Amateurs to be able to take full advantage of the MIL-STD/STANAG 
waveforms which will open the doors for more PCSDM based software 
solutions to come along from the various authors taking in the full 
range of these waveforms and not just a few aspects of them to the 
benefit of the Amateur Radio Service.

/s/ Steve, N2CKH

At 09:29 AM 9/14/2007, you wrote:


>The PSK modes of Pactor (Pactor 2 and Pactor 3) have never been
>developed into sound card modes, because of the difficulty of exactly
>duplicating these commercial modes, and partly because they require
>fairly significant computing power and at the same time require fast
>switching times.
>
>The only way to buy P2 and P3 is with the commercial hardware/firmware
>products from SCS in Germany and that is extremely expensive, even more
>expensive than the cost of some rigs. In the "old days," many of us used
>Amtor and Pactor 1 for casual chats and even DXing, but the sound card
>modes have made that obsolete. Amtor is almost never used anymore as it
>also requires even more stringent switching, and other limitations.
>Pactor is still used for some e-mail connections although that will
>probably lessen if an ARQ sound card mode is developed that would
>replace it.
>
>73,
>
>Rick, KV9U

Re: [digitalradio] Experiences from users of MIL-STD-188-110

[Steve Hajducek]

Hi Andy,

In the U.S. ( correct me if I am wrong) which you are located, 300bps 
for MIL-STD-188-110 is not legal for data  on HF, nothing is due to 
the symbol rate.


Anyhow, what ever, who ever, where ever does using MIL-STD-188-110 
within the ARS, the standard 1800hz PSK carrier and 2400bps symbol 
rate necessitates a 3Khz BW, so if you are not at least at 2.7Khz IF 
BW, the results using the standard modem settings will be poor and 
the higher the data rate the worst the results under perfect channel 
conditions, add in QSB and the like and you get the picture.


/s/ Steve, N2CKH

At 06:24 PM 8/6/2007, you wrote:

Rick et Luc,

I have set mine to no more than 300 baud to make sure I am legal 
below 10M, let me know if you want to sked.


Of course, with ALE...we should not need to "sked", just call me :>)

Andy

On 8/6/07, Luc Fontaine 
<[EMAIL PROTECTED]> wrote:


Well I would like to do more tests with that mode when conditions 
will be good. Would like also to try at >300 bps.


Luc
VE2FXL

- Original Message -
From: Andrew O'Brien
To: digitalradio@yahoogroups.com
Sent: Monday, August 06, 2007 2:19 PM
Subject: Re: [digitalradio] Experiences from users of MIL-STD-188-110

Luc , VE2???, is also playing around with this.  Bonnie talked me 
through the up and I was able to make a link with Luc under fairly 
poor conditions.  I will be happy to do some tests at 300 baud or less.

Has anyone tried it at higher rates on 6M ?

Andy K3UK


On 8/6/07, Rick 
<[EMAIL PROTECTED]> wrote:


Hi Andy,

What software do you suggest? If PC-ALE will be able to key the PTT line
via CAT interfacing with an upcoming new version, this should work for
me with my main digital rig which is the ICOM 756 Pro 2.

But if I understand it correctly, I could use my Ten Tec Argonaut V,
although I don't normally have the fans plugged in since I mostly use
this rig for QRP CW and for general monitoring.

Since you can select the baud rates, if you work below 10 meters here in
the U.S., you can just set the maximum rate at 300 bps and both the
minimum and default values at 75 bps.

For stations who are close together, say 30 miles, with modest antennas,
or much farther with gain antennas, this should also work up to 1200
baud on 10 meters and higher on 6 meters and up. This won't give you an
accurate lower band HF experience, but might give you some feel for how
well (or not) the modes perform.

Isn't anyone else trying out these software programs with
MIL-STD-188-110 and can give us some feedback on their results? Is it
due to lack of interest, or getting it to work with your equipment?

73,

Rick, KV9U

Andrew O'Brien wrote:
> I have done some playing around with this Rick. Let me know if you
> want to try a "QSO".
>
> Andy K3UK

Re: [digitalradio] help for setting pcale with FT1000 MP mark V

[Steve Hajducek]

Hi Howard,

RFSM2400 is not using a standard Data Link Protocol (DLP) and thus it 
is a tool onto itself where you have no interoperabilty with any 
other MIL-STD-188-110 system used for MARS operations such as 
hardware based systems or MARS-ALE.

/s/ Steve, N2CKH/NNN0WWL

At 10:22 AM 8/6/2007, you wrote:
>Rick, there is a real need for correcting errors, such as
>is done with Pactor.  I am not saying that Pactor is the
>mode of choice, only that error correction is essential
>to error free messages.  Once you switch to TOR mode,
>only the (connected) receiving station will be able to
>copy error free.
>
>IMO an ideal mode would use FEC for keyboard to
>keyboard mode, then when you were transferring a
>message it would switch to TOR.  It would also be able
>to run at low speeds with low bandwidth and switch
>to high speeds to transfer large messages (or files).
>
>Also IMO the program called RFSM2400 is a giant step
>in this direction.  A couple of us have done some testing
>on MARS frequencies and it works well.  We have not
>yet established how well it works in noisy conditions
>but we hope to do that testing soon.
>
>There may be others that work as well or better?
>
>Howard K5HB / AFA4CI

Re: [digitalradio] help for setting pcale with FT1000 MP mark V

[Steve Hajducek]

Hi Rick,

At 09:59 AM 8/6/2007, you wrote:

>In terms of CAT PTT, aren't you  using some of the same interfacing with
>RS-232 serial connection for rig control?  It seems a step backwards to
>set up two RS-232 serial ports considering that we also need to convert
>from USB. I admit that the ICOM CI-V might be less than perfect and
>could hang up in TX mode as I have had this happen. For unattended
>operation, maybe you would need a separate PTT, but for most users,
>keeping it as simple as possible commensurate with adequate rig control
>seems to me to be the goal with modern interfacing.

I don't know where you keep getting this need for 2 serial ports to 
do hardware PTT from Rick? If that is your choice fine, but is not a 
requirement. Please read my previous post to Jon today for my 
comments that cover this subject matter.

>While the Rigblaster interfaces are used by many hams, I am not that
>impressed with their design if it requires two serial ports and I am not
>sure if they completely isolate both audio lines.

It only requires the CAT RS-232 port with the use of a splitter Rick, 
the same for all RS-232 RTS/DTR keying.

>  One of the most common
>interfaces seems to be the Tigertronics which keys the PTT line using
>computer audio, but I definitely do not recommend that approach:)

I agree on that and its one situation where if the user has already 
committed to using such and if they have a CAT PTT capable radio, I 
suggest that for ALE use they enable CAT PTT as the Vox like hardware 
keying will not suffice for ALE in two way acty.


>To meet the spirit, and perhaps the legal requirements of Part 97, all
>ALE programs need to be able to monitor all transmissions. The last
>thing we need is a replay of Pactor modes which are problematical in
>monitoring and many of us, if given the choice, would ban the use of
>such modes.

Nothing requires the actual application used by the Radio Amateur to 
be able to decode the data transmissions of a third party Rick, when 
you are linked and you can decode, that is all that counts, any other 
monitoring is not your concern as far at Part 97 is involved 
regardless of what your opinion of the spirit of Part 97 may be. 
However if you have the time and interest to decode and listen to 
everyone's QSO's then there are plenty of free PCSDM based tools 
about for ALE and even other modes in commercial offerings ( both 
PCSDM and dedicated hardware modem) that support most everything that 
you can make use of in your pursuits to even include those PACTOR 
modes you wish to monitor if you want to spend the money.

/s/ Steve, N2CKH

>73,
>
>Rick, KV9U

Re: [digitalradio] Re: help for setting pcale with FT1000 MP mark V

[Steve Hajducek]

Hi Brian,

At 08:24 AM 8/6/2007, you wrote:
>Of course, if you don't have a spare RS232 port then CAT contol is
>obviously better.  At least for PSK, I found the CAT control on the MP
>to work just fine.

I can't speak for all software applications, but for PC-ALE the 
standard use of RTS or DTR for PTT is made via the same serial port 
as is CAT control, you simply use an RS232-Y cable or 
connector/connector shelled Tri-Port adapter etc. PC-ALE does for 
some time now also support a dedicated RS-232 port for PTT has many 
Amateurs requested this, but a dedicated port in my opinion is waste, 
I reluctantly added the same alternate PTT support for a dedicated 
RS232 PTT port to MARS-ALE due to users requests as that is how they 
are configured for other applications, which makes no sense to me 
when doing it all on the CAT RS-232 port is the logical way to 
support hardware PTT.


>I question the "timing" conclusion.  Anybody who has tried using RS232
>ports or LPT's for sending CW knows the highly buffered environment in
>XP and VISTA screws up the timing.  We're talking way more than 10 ms
>delays and timing inaccuracies.  People have gotten around this in XP
>by a program called DLPORT which allows direct port writes like one
>could do in older OS's.
>
>Another solution has been to use WINKEY instead of generating CW
>within the computer.  One sends out an ASCII character via a port and
>the WINKEY PIC generates the perfect CW character. In effect it is a
>CW TNC.  That's real progress!  Instead of just turning on and off an
>external line at prescribed times one has to resort to such nonsense.
>
>Anyhow the software/hardware out there should be working on USB
>interfaces rather than COM port interfaces.  USB/com port intefaces
>have been problematic with RTTY due to the slow baud rate.  I assume
>the same would be true for these modes.  Obviously rig control for
>most present generation rigs has to be over COM's.  Most USB/COM port
>converters work OK for rig control.  However, the same timing problems
>most likely exist. I simply don't know if USB timing suffers from the
>above timing problems or not.  Perhaps so.  But for computers with no
>COM ports, USB is the way to go.
>
>The problem is that a real time operating system is needed when timing
>is critical.

All GUI based OS's are a challenge for timing, long ago I added 
support to my old CATCC software for CW keying, however it was in 
support of controlling my AEA MM-3 keyer ( the best keyer ever 
designed to data in my opinion!!) when my wrists and fingers needed a 
break from the paddle and even pressing the keypad to send from memory.

For repetitive fast time domain events just running an open 
application under MS-Windows is not going to provide proper results 
all the time, its a given due to the nature if the OS. I had to take 
it to another level of timing even just for radio control support of 
a beast of a radio that requires RS232 breaks as attention timing 
prior to the follow on command data recently for reliable CAT control 
of this one make/model radio, timing to less than 10ms can be 
achieved under MS-Windows, but you basically need to reduce the OS to 
an almost single application use level, which depending on the 
application is just fine and can be done using the embedded 
application API calls or other multi-media calls, buts its a lot more 
work to manage things.

/s/ Steve, N2CKH


>73 de Brian/K3KO
>
>--- In digitalradio@yahoogroups.com, "Simon Brown" <[EMAIL PROTECTED]>
>wrote:
> >
> > Chiming in here: no delays, less to go wrong. Also a *lot* easier
>for the
> > poor old programmer.
> >
> > Simon Brown, HB9DRV
> >
> > - Original Message -
> > From: "Jon Maguire" <[EMAIL PROTECTED]>
> > >
> > > Can you give a rundown as why dedicated PTT is better than CAT PTT?
> > > Thank you.
> >
>
>
>
>
>Announce your digital presence via our Interactive Sked Page at
>http://www.obriensweb.com/drsked/drsked.php
>
>Yahoo! Groups Links
>
>
>

Re: [digitalradio] Re: help for setting pcale with FT1000 MP mark V

[Steve Hajducek]

Hi Jon, Simon:

Well MS-Windows being an event driven, multi-tasking environment is 
the not the best environment when it comes to dealing with signaling 
and data comm ports, however it can be managed for PTT needs 
reasonable well depending on how strict such PTT timing requirements 
are. For example as we all should know by now repetitive PTT timing 
down to 10ms is a big challenge.

Anyhow, the point with regard to ALE operations and PTT is that when 
fully exercised ALE is a near-real time scanning operation at 1, 2 
and 5 channels per second (ch/sec) presently and 10 ch/sec coming as 
mentioned in the current MIL-STD-188-141B standard. At that 5 ch/sec 
scan rate there is but a 100ms window to change radio characteristics 
from channel to channel regarding Frequency, Mode ( and other 
parameters that may be supported such as Antenna Port, ATU etc.) when 
Scanning/Sounding. Par of the Sounding process is of course PTT as is 
when receiving and replying to a call while Scanning or during a user 
initiated LQA Linking Call during Scanning. What must be taken into 
account here also is the baud rate at which the radio is operating, 
at 9600 baud and 100ms a maximum of 80 characters can be exchanged 
whereas at 1200 baud it is only 10, 2400 baud is 20, 4800 baud is 40. 
Also, even though a radio may be operating at 9600 baud, its CPU may 
not be able to process the data sent to it fast enough and may use 
whatever means provided ( if any) to ask the PC application to wait 
before sending more data at certain juncture and if not the follow on 
data that comes to fast will be ignored. In ALE operations the last 
thing to be sent for a TX event is the TX method, thus for CAT PTT 
the TX command is the last item sent to the radio and if may be 
ignored. I have however found in my testing that it does work rather 
well with the make model radios that I have here for testing with, 
but I still prefer and I do only use RS-232 RTS or DTR for my PTT 
needs as I know for sure that the RS-232 will go high and go low, I 
state that as aside from what I have just pointed out, RS232 noise, 
data collision ( depending on the topology such as CI-V CSMA) and 
dropped data bits, missing polling event ( depending on radio model), 
a constant keep in PTT or keep alive command needing to be sent over 
and over for some models ( e.g. Harris RF-350 family and  Kachina 
505DSP) etc. as well as the possibility of radio lock up due to RFI 
or over heating or just plain failure come into play with CAT PTT and 
not with RTS/DTR signaling.

For casual use of Amateur Radio CAT PTT is fine as far as I am 
concerned, its also seems to work ok for most radios, most of the 
time for ALE applications from the years of experience now under my 
belt in discussing this issue with MARS-ALE users who have been using 
it and as stated, its not supported for each radio type selection in 
the next version of PC-ALE being tested for those that want to use 
it, I just can't recommend it for everyone to use taking into account 
the known issues and variables involved, whereas hardware PTT through 
the 10 ch/sec ( supported in MARS-ALE) scan rate works great all the 
time. With it now being in place in the next PC-ALE, everyone can 
experiment with their installation ( if their radio supports it) to 
determine if its reliable for their ALE pursuits.

/s/ Steve, N2CKH

At 07:45 AM 8/6/2007, you wrote:
>Chiming in here: no delays, less to go wrong. Also a *lot* easier for the
>poor old programmer.
>
>Simon Brown, HB9DRV
>
>- Original Message -
>From: "Jon Maguire" <[EMAIL PROTECTED]>
> >
> > Can you give a rundown as why dedicated PTT is better than CAT PTT?
> > Thank you.

Re: [digitalradio] help for setting pcale with FT1000 MP mark V

[Steve Hajducek]

Hi Rick,

At 08:34 PM 8/5/2007, you wrote:
>Steve and group,
>
>1. I really have no knowledge at all about MARS-ALE so I have no
>reference to this. I suspect most of us are this way, but there are a
>number of MARS operators and perhaps they would look at this differently.
>
>2. But that brings up an interesting question:
>
>What really is the difference between MARS-ALE and PC-ALE?
>
>3. And maybe more importantly, why would there be a need for different
>programs that are not openly shared?

MARS-ALE although based on PC-ALE differs in a number of ways, 
basically its tailored to meet the needs of  MARS members and is not 
in competition with PC-ALE for two-way usage by the general Amateur 
Radio community. G4GUO and I work closely and both tools benefit from 
that collaboration.


>4. It might be interesting to have one of those voting surveys to see
>how many hams are now moving toward PTT control via the rig computer
>interface rather than via a separate PTT line. I won't buy any rigs
>anymore that can not do PTT control. I still have my old TS-440SAT which
>I ran on digital modes decades ago, but then I started using VOX on the
>Ten Tec Pegasus (not satisfactory to me) and now have the ICOM rig and
>swapped my Peg for a Ten Tec Argonaut V that I think will key up for
>digital modes with the RS-232 serial port.

The Pegasus supports CAT PTT, even the Jupiter does, but only using 
Pegasus emulation mode, why Ten Tec does not have CAT PTT ON/OFF 
commands in the Jupiter command set of a supposedly SDR radio blows me away.

The only time that I recommend the use of CAT PTT for for ALE 
operations when someone is using an otherwise VOX interface of any 
type as the latency for PTT activition with ANY such device is not 
fast enough in my opinion.

I think you will find on a whole and especially within the ALE 
community that RTS/DTR hardware PTT is the standard to this day, just 
look at all the RigBlaster and other interfaces being used ( where if 
such an interface is the choice and RTS/CTS handshaking is being used 
either DTR for PTT or again the use of CAT PTT with such units in the 
Vox position would be used).

>5. In terms of split operation being changed, it is welcome. We will
>have to differ on the politically correct way to phrase it. I have done
>some split operation since I have been a ham for a fairly long time. But
>I am a bit uncomfortable toward this kind of operation as those hams are
>using up a rather large amount of spectrum. I realize that in most
>cases, it is done because there is just no alternative due to different
>rules in the three regions.
>
>6. If it is not possible to monitor the connected stations, then it does
>appear that there could be some legal issues with Part 97 and this will
>need to be changed to have a listen mode.

PC-ALE is not the only means for Radio Amateurs to decode ALE and 
follow on transmissions and it is certainly not the tool used by the 
various regulatory agencies such as the FCC. If you want to monitor 
all the DTM and DBM traffic there are a number of software based 
options available, some free and some commercial that utilize the PC 
Sound Device Modem, MultiPSK does so, MARS-ALE can be downloaded and 
used for such purposes as well with Listen Mode enabled, thousands of 
Amateurs and Utility monitoring users have been doing so from what I 
am told, see: http://www.n2ckh.com/MARS_ALE_FORUM/


>7. I really appreciate your help, Steve, and I am sure others on this
>group do too. If you support something that is really going to be
>successful, it is much better in the long run to be open and inviting to
>others and they will want to participate if there really is a perceived
>benefit.

As I stated, ask away here or via the HFlink forum and I will answer 
to the best of my abilities.

I truly see the benefit to the Amateur Radio Service (ARS) of ALE, 
especially for ECOM, HF traffic automation, SELCAL and Propagation 
Analysis, however my main focus is MARS-ALE development, in time I 
may take a more active role within the ARS ALE scene and PC-ALE 
development as well, at present my main contribution to PC-ALE is the 
radio control library.

PC-ALE is the most complete software based ALE modem/controller 
available to the ARS, free or otherwise, it can't help but be 
successful within ARS ALE circles.

/s/ Steve, N2CKH

Re: [digitalradio] help for setting pcale with FT1000 MP mark V

[Steve Hajducek]

Hi Rick,

At 02:38 PM 8/5/2007, you wrote:
>Steve and those interested in the ICOM rigs for ALE:
>
>I had asked Steve:
>
> > I am using the default hex address 64 with CAT PTT selected.
>And he responded with information on the new Alpha version:
>
>For the new ALPHA  version of PC-ALE you still need to select CAT PTT if
>that is your desire, I have coded CAT PTT for all make/model radios
>where supported.
>
>- - - - -
>
>I must have misinterpreted what he said, but to me, this means that if
>you "still need to select CAT PTT" which definitely is my desire, then
>it was available earlier as well.  Especially since someone else
>confirmed this a while back that I needed to check the right box. Sorry
>that there was this unfortunate miscommunication or lack of knowledge on
>someone's part.

In PC-ALE you actually need to check a box for CAT PTT. In MARS-ALE 
if RTS or DTR are not checked for PTT then CAT PTT is by default 
selected, thus you see my mind set in my wording.


>With new software coming out my hope is that we will be able to control
>the PTT CAT which is a mandatory issue with me as I just will not use
>software that can not support this feature since the top digital
>software has been doing this for some time and I suppose you get "spoiled."

It may be mandatory with you Rick however the bulk of all Amateurs 
that I have had contact with over the years to include myself do not 
use CAT PTT for digital ops.


>I do consider the fact that the PC-ALE software could not go into split
>when you scanned and return to normal operation as a defect or at least
>a shortcoming when the new software is going to correct that. Steve, you
>must be in marketing in your day job to claim this is not even a fix:).

It can't be a fix when it was not designed to do anything other than 
be in SPLIT VFO all the time if the user selected SPLIT VFO now can it?

You may not realize it, but the majority of all radios designed for 
ALE are basically always in duplex operation as you need to program 
in both an RX and TX frequency and often a mode for each, although 
many just use a common mode, this is also true of most Military, 
Commercial and Marine grade HF SSB transceivers, even many Amateur 
transceivers are like that when if comes to computer control, e.g. 
FT-600 and Ten Tec Jupiter and Pegasus. So when G4GUO started to 
provide SPLIT VFO for ICOM radios as they were at the time the most 
popular make being used for ALE and it was known that it would hold 
off the pesky PA relays for a number of models, being in duplex all 
the time when selected was rather natural. Don't forget, the tool 
asks you for both RX and TX frequency and mode in setup.


>Just as an example of what can happen, if you are using your rig to do
>ALE scanning and forget about the split operation,and I have been
>doing a lot of this lately, you may be operating illegally when you
>switch to another software program, such as Multipsk, if you do not
>remember to return the transceiver to normal operation!! This actually
>happened to me on Friday so it is not something theoretical:(

Well that was an oversight in previous versions of PC-ALE as the 
GENERIC ICOM selection is not even part of the 
"radio_de_initialise_module" which would have placed the radio back 
into simplex. However it is a pretty easy thing for a user to get 
used to doing and all must as I have never heard anyone complain 
about it before, I take it that you don't do much DX  voice work on 40 meters?

>HFlink does not seem to have all the information that I need, nor have I
>had much luck in asking, thus I have been asking in the larger digital
>group. I have been thinking about the possibility of forming an ALE
>related group which does not have an agenda and will be more open to
>problems and questions.
>
>Even then, I have been a bit surprised that almost no one other than the
>regular ALE folks, have tried to assist or even have ever mentioned
>their experiences with ALE, and nothing yet on the single tone modems.
>Maybe over time, there will be a critical mass of operators so some of
>these digital modes can be explored? I know that I want to try them out
>to see if they really can compete with existing modes.

Posturing aside, ask away as I have no agenda's when it comes to ALE 
and Amateur Radio other than being of assistance when asked and 
providing to the best of my abilities the correct information on the 
subject matter that I can.


>Most recent ALE scanning from 1617 Z to 1836Z with lowest frequency 40
>meters and highest frequency 12 meters and some stations received
>multiple times and bands:
>
>K7EK
>AF6 to KQ6XA
>KB3FN to KF4IN
>NOCALLSIGN
>NJ7C
>VE2FXL
>KF4IN
>KQ6XA
>VE2FXL to W9WIS
>EA2AFR

That station running NOCALLSIGN needs to linked with and informed 
that they have forgot to change they SELCAL properly.


>Maybe try and call some of these or see if anyone is around. I am still
>not sure if you see connections when you monitor because thus far I

Re: [digitalradio] help for setting pcale with FT1000 MP mark V

[Steve Hajducek]

Hi Rick,

At 07:01 PM 8/4/2007, you wrote:
>Thanks for your comments, Steve,
>
>I understood that it did support the ICOM 756 Pro 2, including CAT
>control, and was told by someone in the ALE world that I needed to check
>the CAT box which I of course did. Maybe I missed it, but I did not
>realize that this particular rig can not even operate at this time with
>CAT control, because if I did, I would not have spent quite so many
>hours trying to get it to key with PTT CAT:( I don't have any hardware
>PTT plans at this time as other programs work reasonably well and it
>simplifies the cabling requirements.

The PC-ALE versions that have been out for years provides support for 
any ICOM radios address, baud rate
etc. and SPLIT VFO operation via the GENERIC ICOM interface, but not 
CAT PTT ever, originally PTT was
only RTS or DTR as in the past for one thing CAT PTT was not common 
in radios and hardware PTT it was much more reliable than CAT PTT. 
Also, most all of the radios with dedicated digital ports do NOT 
support the use of CAT PTT via those ports.

Any, I have updated PC-ALE for the next release with CAT PTT for all 
radios that support it.


>What I  understood was that the current program is defective with
>setting up the split function properly. It sets it up the split when you
>boot the program, not when you scan, and it does not return to non-split
>mode either when you stop scanning or when you leave the program. My
>understanding was that this will be fixed in the new version, although
>it is still in Alpha at this time.

No defect, nothing to fix, for ICOM radios only in the past and via 
the GENERIC ICOM interface only, you could enable SPLIT VFO all the 
time to defeat those pesky PA spectral purity relays during Scanning.

In the current PC-ALE in ALPHA testing I have applied a new approach 
similar to that which I developed for MARS-ALE where for any radio 
that supports SPLIT VFO ( and a radio specific BYPASS command) where 
it will tame those pesky relays for scanning, that when scanning is 
started the issue is addressed and when scanning is stopped normal 
operation of those relays resume. Its an enhancement, not a fix.


>Your list of the many different rigs is very helpful and this kind of
>information needs to be easily located on ALE websites so that there is
>no misunderstanding of what a given "supported" rig can or can not do at
>any given time. It doesn't make sense to me why this would not be
>heavily promoted.

Its all posted at HFlink.

For the next release a page has been created by the webmaster at:

http://hflink.com/pcale/pcaleradio.html


>As far as activity, I suppose it depends upon your definition. I
>monitored for several hours today with scanning with the ICOM 756 Pro 2
>and heard the following:
>
>KK7IF
>VE2FXL
>WD8ARZ
>KM4BA
>LU8EX
>VE6OG
>
>Of course there can be other areas of the world and those with better
>antennas who may be able to copy more test signals and calls.Most of
>these were soundings but some appeared to be calls. I don't know if you
>actually can receive any messages being sent by others when in this
>scanning mode, but I have not actually printed anything like that.
>
>Again, it seems that it is difficult to find information of this kind on
>the internet and I rather expect it to be very openly available and very
>clear and concise.
>

Again, the proper venue is Hflink.com, if you can't find what you 
want, just ask the web master.

/s/ Steve, N2CKH





>Steve Hajducek wrote:
> > Hi Rick,
> >
> > I have replied to your comments many times on these matters:
> >
> > 1. PC-ALE as released does not specifically support the PRO2, the
> > next release will. For now if you are not interested in ALPHA testing
> > the next release, its the use of the GENERIC ICOM interface and
> > DTR/RTS for PTT. It works for everyone else that has a PRO2, I can't
> > see why you should have any problems unless you have something out of
> > the ordinary configured.
> >
> > 2. As hard as you may find it to believe, there is a lot of ALE
> > activity on the Amateur Bands.
> >
> > Sincerely,
> >
> > /s/ Steve, N2CKH
> >
> >
>
>
>Announce your digital presence via our Interactive Sked Page at
>http://www.obriensweb.com/drsked/drsked.php
>
>Yahoo! Groups Links
>
>
>

Re: [digitalradio] AQC ALE ?

[Steve Hajducek]

Hi Andy,

It is the same 8FSK modem, however it uses shorter bursts for calling 
and sounding and there is a PSK burst mode as well which uses the 
MIL-STD-188-110 modem for generation.

/s/ Steve, N2CKH

At 09:26 AM 8/4/2007, you wrote:
>Thanks Steve.  Is the AQC-ALE a different digital mode, different 
>tone characteristics?
>
>
>Andy K3UK

Re: [digitalradio] help for setting pcale with FT1000 MP mark V

[Steve Hajducek]

Hi Rick,

I have replied to your comments many times on these matters:

1. PC-ALE as released does not specifically support the PRO2, the 
next release will. For now if you are not interested in ALPHA testing 
the next release, its the use of the GENERIC ICOM interface and 
DTR/RTS for PTT. It works for everyone else that has a PRO2, I can't 
see why you should have any problems unless you have something out of 
the ordinary configured.

2. As hard as you may find it to believe, there is a lot of ALE 
activity on the Amateur Bands.

Sincerely,

/s/ Steve, N2CKH



At 11:51 AM 8/4/2007, you wrote:
>This has been the same problem I have with my ICOM 756 Pro 2. It scans
>reasonably well although it goes into split operation when you boot up
>the program and does not return to normal operation without manual
>intervention, but it can not transmit.
>
>I was surprised that no one else is using this model transceiver for
>ALE, or at least was willing to help solve the problem., assuming that
>the rig can actually operate with PC-ALE. It does fine with Multipsk.
>One wonders if there really are hundreds or thousands of ALE users as
>has been claimed.
>
>73,
>
>Rick, KV9U

Re: [digitalradio] help for setting pcale with FT1000 MP mark V

[Steve Hajducek]

Hello Ali,

The current version of PC-ALE is really RTS/DTR PTT based, the reason 
being that it has long proven  to be much more reliable whereas CAT 
PTT has not, RF into the radio can lock a rig into TX using CAT PTT 
and other issues come into play, if you notice most rigs do not 
support CAT PTT on the data/digital/aux ports.

Anyhow, G4GUO started to add CAT PTT to PC-ALE as many users were 
requesting it, to date through the current release version of PC-ALE 
the following radios are supported:  FT100, FT817, FT847, FT897, 
SKANTI 8250, Ten Tec TT516 and TT550.

However, I have now integrated the radio control library from 
MARS-ALE into the latest ALPHA version of PC-ALE which has just been 
released to the HFlink test group where all radios which support CAT 
PTT allow for its use if that is what the user desires as their PTT method.

The updated PC-ALE supports the Quiet Scanning/Sounding (QS/S) method 
of MARS-ALE were all make/model radios that either via SPLIT VFO 
operation or a radio specific BYPASS command disable the RF PA 
section spectral purity filter relays from activation during Scanning 
automatically and upon the first TX event allow their operation again 
and when Scanning is stopped, the radios go back to single channel mode.

Also now supported are the various dedicated data ports where other 
than USB/LSB is used etc. such as with the FT817 family and ICOM PRO models.

Those interested in PC-ALE and testing the ALPHA build of the next 
release should consider joining 
http://tech.groups.yahoo.com/group/pcale/ as the more that sign up to 
test the ALPHA, the better it will met everyone's needs when released.

Below is a list of all make/model radios that are supported at the 
moment by their "Radio Type" menu selection moniker and other models 
the selection supports, there are more to come like the MICOM H, 
SEA235 and others for which I have yet to write drivers.

DX77T   < NOTE: Also use for DX-77, DX-77EQ, DX-701 and DX-707
FT450
FT450HS < NOTE: RTS/CTS handshaking support
FT600   < NOTE: Also Vertex System 600
FT650   < NOTE: Also FT655
FT757GX
FT767GX
FT817   < NOTE: Supports FT817x, FT857x, FT897x
FT817DIG< NOTE: DIG port support for all models in 
this sub family
FT847
FT890   < NOTE: Also FT-100, FT-747, FT-80C, FT-840, FT-890,
FT-900, SB-1400
FT920
FT920DATA   < NOTE: Supports data port, AFSK-FSK switch to AFSK
 and setup the radio for the +2125hz offset 
in the U-45 setup
FT990   < NOTE: QS/S support where FT-990 requires 
ROM version 1.2 or later.
FT980
FT1000MP
FT2000  < NOTE: Also for FT-2000D
FT2000HS< NOTE: As FT2000 above but RTS/CTS handshaking support
FTDX9000
GENERIC ICOM< Mostly obsolete now but still supported, CAT PTT 
and QS/S support provided.
IC78
IC703
IC706
IC706MkII
IC706MkIIG
IC707
IC718
IC725   < NOTE: Factory addressing is used, WRT 
address diodes D57-D63, only D60 and
 D62 should be in place for the factory 
address of 28h. Diode D64 for transceive
 operation should no be installed either. 
9600 baud is being used, not the factory
 default 1200 baud. As such, the CI-V Baud 
Rate diode, D2 must be in place and
 D3 must be empty. Also diode D4, the factory 
default, must be in place for standard
 5 byte frequency data.
IC726   < NOTE: Factory addressing is used, WRT 
address diodes D57-D63, only D61 and
 D62 should be in place for the factory 
address of 30h. Diode D64 for transceive
 operation should no be installed either. 
9600 baud is being used, not the factory
 default 1200 baud. As such, the CI-V Baud 
Rate diode, D2 must be in place and
 D3 must be empty. Also diode D4, the factory 
default, must be in place for standard
 5 byte frequency data.
IC728   < NOTE: Factory addressing is used, WRT 
address diodes D57-D63, only D60, D61
 and D62 should be in place for the factory 
address of 38h. Diode D64 for transceive
 operation should no be installed either. 
9600 baud is being used, not the 
factory   default 1200 baud. As such, the CI-V 
Baud Rate diode, D2 must be in place and
 D3 must be empty. Also diode D4, the factory 
default, must be in place for standard
 5 byte frequency data.
IC729   < NOTE: Factory addressing is used, WRT 
address diodes D57-D63, only D58, D60,
 D61 and D62 should be in place for the 
factory address of 3Ah. Diode D64 fortransceive 
operation should no be installed either. 9600 baud is being used, not the
   

Re: [digitalradio] AQC ALE ?

[Steve Hajducek]

GM Andy,

In PC-ALE the AQC-ALE operation differs from MARS-ALE for some time 
now, however with both tools selecting AQC-ALE means that all 
Soundings and Calls originated by your station will be in AQC-ALE 
mode, which differs from NORMAL ALE and which can only be decoded by 
an ALE modem that supports AQC-ALE.

The way in which G4GUO implemented AQC-ALE in PC-ALE regardless of 
wether you are actually in AQC-ALE or not, it will decode and display 
AQC-ALE channel acty and respond to either type of call made to your 
station. However I have found this to be a problem with falsing on 
bad ALE words and processing NORMAL ALE linking calls as AQC-ALE 
which is just wrong and I changed MARS-ALE to only do so when 
actually in AQC-ALE where the standard mandates backward support in 
the event of an incoming NORMAL ALE call when in AQC-ALE mode.

I also changed MARS-ALE so that when in AQC-ALE scan rates of 2 
ch/sec and above are supported as that is my interpretation of the 
standard,  whereas in PC-ALE only 5 ch/sec is supported.

AQC-ALE is far superior to NORMAL ALE, its 2G+ and is much more 
reliable and fast at establishing and maintaining an ALE linked state 
under severe channel conditions. It is only to be found in the most 
expensive Military ALE transceivers to date, its use is tactical 
rather than 24/7 networks and it offer many additional operational features.

/s/ Steve, N2CKH

At 11:56 PM 8/3/2007, you wrote:
>I think previous postings here indicated that AQC ALE is unlikely to
>filter down to amateur transceivers.  Does anyone know what the AQC
>Enable feature within PC-ALE does ?
>
>Andy K3UK

Re: [digitalradio] A.L.E., VHS and Betamax

[Steve Hajducek]

urers come 
out with less than $10 devices in single quantities with guts and 
free development toolset's, don't know if I will live long enough to 
see that though.


>  The main development of new, and yet practical
>technology has come from Patrick's FAE mode.

FAE ARQ is a great protocol in my opinion, every Amateur wants to use 
their PCSDM and have an ARQ protocol should start using it, other 
tools authors should start adding it to their list of supported protocols.


>As I often point out, we have the pieces already developed, to wit:
>
>- very high speed modes that work with very good signals (> 10 dB S/N)
>and modest baud rates that are legal here in the U.S.
>- software frameworks such as Multipsk and possibly DM780 that handle
>the rig control through an auxiliary program such as DXLab Commander and
>Ham Radio Deluxe
>- no longer having a need for fast switching due to being able to
>pipeline data into a background thread to be processed while a new
>packet is incoming
>- busy frequency detection

Tradeoffs my friend, just as in all forms of life, you can ask for 
but can't expect to get everything you want.

>The main missing piece is being able to automatically switch between a
>suite of modes and negotiate the best mode for the current conditions.

There are a number of fully adaptive data link protocols, some 
partially adaptive, in a speed sense both PACTOR I and GTOR are speed 
adaptive, the new PACTOR x and DLP's use with MIL-STD-188-110x are 
fully adaptive on both ends for speed and interleaver and more, until 
you see your PCSDM system where here my RX sucks due to channel 
conditions, but your RX is fine and thus my side tells yours to slow 
down the data rate and your side tells mine to speed up, after 
starting at 600bps and then automatically changing to 300/1200bps on 
the overs or whatever, you have not really experienced adaptive HF 
digital operation, what I just described is an aspect of 
MIL-STD-188-110x using just old FS-1052 ARQ which we use in MARS via 
MARS-ALE with a 2Khz BW and is found in PC-ALE ( but only at the 
standard 3Khz BW).


>I'm still very skeptical of the utility of very high baud rate single
>tone modems for moderate to weak signals that are well below the MUF,
>but I am keeping an open mind on this and keep looking for some real
>world testing results that would compare various modes. The earlier
>document I mentioned suggests to me that these modes may not work well
>below 10 dB S/N and that is often what we radio amateurs must work with.

For traffic networks the speed is really nice to have, especially 
during an ECOM event. Perhaps at some future WRC the powers to be 
will formulate two frequencies on each Amateur Band that are clear 
channels for only high speed HF data network links, not where users 
get on, but just back end routing channels, that way the users via 
other frequencies can use various speed ARQ protocols when accessing 
networks, but those reserved high speed channels can carry the 
radio-to-radio ( we can't live on just radio-to-Internet alone) flow.

As to other uses of high speed data modes, well keyboard to keyboard 
use is rather stupid as most Amateur's can't even type fast enough 
and good enough to use 100-200 baud or even less mode, I am told by 
users all the time that the ACK/NAK diddling of the radios puts 
pressure on them to type faster and they can't, but for pre-canned 
message traffic and file attachments the speed is needed, although I 
would like to see full STANAG 5066 or other aspects of 3G ALE systems 
come to Amateur Radio, I do not see the need for full blown systems 
for web page browsing and the like, just e-mail, file attachments and 
FTP will suffice for Amateur Radio needs.


>Lately, there have been more comments about HF e-mail and ALE. What is
>currently available other than PSKmail for Linux OS that permits anyone
>to set up servers to route the traffic into the internet?

HFlinkNet/Winlink 2000 interfacing is rolling out, visit HFlink.org 
or the HFlinkNet Yahoo forum for details, any ALE system capable of 
sending/receiving the ALE AMD protocol, which is all ALE systems will 
be able to send single line or multi-line messages via WL2K 
interfacing, this was developed in support of MARS and is now coming 
to Amateur Radio.

/s/ Steve, N2CKH



>73,
>
>Rick, KV9U
>
>
>
>
>
>Steve Hajducek wrote:
> > GM Rick,
> >
> > Alternate Link Call (AQC) ALE is basically 2G Plus ALE in that its an
> > advanced 8FSK form of ALE where most all of the un-necessary overhead
> > of ALE has been removed and new capabilities have been added, to
> > include a PSK burst mode. The linking time to setup is must faster
> > with AQC-ALE and the ability to achieve a linked state in the face of
> > poor channel conditions is huge

Re: [digitalradio] A.L.E., VHS and Betamax

[Steve Hajducek]

GM Rick,

Alternate Link Call (AQC) ALE is basically 2G Plus ALE in that its an 
advanced 8FSK form of ALE where most all of the un-necessary overhead 
of ALE has been removed and new capabilities have been added, to 
include a PSK burst mode. The linking time to setup is must faster 
with AQC-ALE and the ability to achieve a linked state in the face of 
poor channel conditions is hugely improved.

Remember this, ALE is the great facilitator of follow on traffic, be 
it data or voice ( analog or digital) or remote signaling for command 
and control and where the data may be of any format and not just 8FSK 
ALE or other MIL-STD protocols, there are no limitations to what 
follows after the ALE Link Quality Analysis (LQA) has been used to 
select the best channel from those provided to work with.

GTOR and PACTOR I are a challenge within the frame work on an event 
driven OS to implement, if you take control of the OS and limit the 
interrupts to a point of which the application is in control of 
environment, which would for the most part preclude the multi-tasking 
3rd party application aspect of the OS to point where only the 
digital communications application is running, then it even these 
fast timing ACK/NAK protocols would work, even AMTOR ARQ which is 
even a worst case than PACTOR I timing. As to the new PACTOR x and 
CLOVER modes, they do not have the same short turn around timing, 
PACTOR III is basically modeled after the newer Military waveforms 
which run on the MIL-STD-188-110x modem.

The work that Patrick has done with FAE ARQ to date is the best 
example of an FSK ARQ protocol for Amateur Radio designed for the PC 
Sound Device Modem (PCSDM) in my opinion, it provides the best 
aspects of the MIL-STD ALE DBM ARQ protocol ( developed from the 
MIL-STD's which Kantronics also worked up GTOR from) and PAX/PAX2 
into a new protocol that I find to be perfect for Amateur Radio at 
keyboard to keyboard, file transfer and HF e-mail needs. What the 
Amateur Radio Service will see come along on the PCSDM in the way of 
a high speed PSK modem waveform that provides all the desired 
features and is legal in all countries for use is yet to be seen. Its 
obvious to me that the MIL-STD-188-110x modem with one of a number of 
DLP waveforms are contenders, timing is not an issue as far as the OS 
is concerned and the speed is certainly there, just as fast and even 
faster and as and more robust than is PACTOR III which the ham world 
uses as the yard stick for some reason, tailoring down of the PSK 
carrier and symbol rate for less than 3Khz signal BW is doable, some 
hardware modems support it and I did in MARS-ALE, but its still to 
much under current FCC rules for Amateur Radio here in the U.S., so 
stay tuned for more developments to come is what I say and for now 
embrace the legal FSK ARQ waveforms on the PCSDM.

/s/ Steve, N2CKH

At 11:43 PM 6/18/2007, you wrote:
>Steve,
>
>Can you give us some current information on AQC-ALE? I had not been
>familiar with this term but did a little web surfing and found a very
>interesting document:
>
>http://www.dsto.defence.gov.au/publications/2402/DSTO-CR-0214.pdf
>
>That covers a rather full spectrum of digital modes, including amateur
>ones.
>
>Curiously, some of the information seems to support my comments a while
>back about using multiple PSK like tones to come up with a higher speed
>modem, without having too high a baud rate. Is this still too difficult
>to implement in software such as the 64 tone with moderate baud rate,
>can still have a high bps rate.
>
>It is interesting to note that many of these  modes do not work below +
>10 dB S/N. We already have some pretty good speeds with WinDRM types of
>modulation that effectively using a QAM protocol with significant
>throughput at somewhat lower than +10.
>
>Amateur radio, being very different from commercial/military use of
>radio, does not typically need a calling system since we do this with
>the CQ in most any mode. I can see some applications from ALE for
>emergency use or for personal preference, but it will never be all that
>popular with the average digital ham that doesn't use it in this manner.
>
>I was surprised to see your comment that Pactor and Clover could be used
>via sound card modems if they were not proprietary. The conventional
>wisdom is that these modes require a much too fast switching time to
>implement with non real time computers and even Linux was not able to
>work well enough with Pactor I to equal a hardware modem.
>
>What I do think is very doable is to use the waveforms that we know
>work, and the techniques that we know work with weaker signals and yet
>can scale up for improved speeds under good condx, and do this using an
>ARQ pipelining technique of performing the computer time on the last
>packet in the background while the next packet is coming through. In
>fact, this is what I hope will come out of the ARRL's interest in
>possibly developing a new HF mode(s) for soundc

Re: [digitalradio] Re: New ARQ FAE mode on Multipsk

[Steve Hajducek]

Hi Rick,

Plus it retains the bi-directional (duplex) support ( and most 
things) of DBM ARQ and thus both stations can type at the same time 
and as soon as it sync's the resends will only be predicated on propo.

/s/ Steve, N2CKH

At 10:05 AM 2/27/2007, you wrote:
>Had a late night connection with VE5MU on 80 meters. While it would not
>have been possible to maintain the link in the summer evening QRN
>levels, it worked fairly well with pushing the power levels up to close
>to 50 to 100 watts. The throughput is quite good at around 100 to 150
>wpm I think when the flow is maximum and not too many ARQ repeats.
>
>This mode operates very similarly to Clover II and I think works better
>(although 4 times wider) than Clover II did. USB and LSB I think could
>be used. You can set the passband to a fixed tone edges or variable with
>the options menu.
>
>73,
>
>Rick, KV9U

REPLY - MARS digital ops - Re: [digitalradio] re: 25-02 crashes

[Steve Hajducek]

Hi Rick,

RTTY is dead in MARS in my opinion as to being useful, but still 
allowed in all three MARS programs as far as I know, CW was 
vanquished some years ago now, prior to my return to MARS. There are 
3 MARS as you know and to date, there are different approaches in all 
three and many commonalities regarding HF digital communications. I 
was NMCM in the 80's until '91 and I have been Army MARS since 2003, 
I had to bow out for a number years as career and TDY travel got in 
the way. Almost since returning to MARS, I have been involved with 
the more to ALE within MARS.

In NMCM these days its mostly MT-63 and PACTOR I, where FEC is used a 
lot as programs such as MultiPSK and MixW support a connection 
between the TNC user and the PC Sound Device Modem user. This is also 
true for Army MARS. In NMCM the BBS system is MDS on DOS and is 
PACTOR I. For both Army and Air Force MARS, WL2K PBMO's with AirMail 
as the client is being used and 95%+ of the users are PACTOR I based, 
Army MARS has shutdown their older MSYS and Winlink Classic BBS 
systems just this month and currently has all their eggs in the WL2K 
basket. Air Force MARS retains its MSYS and Winlink Classic for 
radio-to-radio BBS capability as does NMCM with MDS, and NMCM does 
not allow the use of WL2K. As to Air Force MARS attended digital 
communications, I am not sure just what the story is outside of my 
direct activities, I know MT-63 is also getting heavy use, along with 
PACTOR. Basically MARS makes use of all digital modes that are 
commonly used by both Amateur Radio, Commercial and the U.S. Military 
to some extent, but PACTOR I and MT-63 currently rule, my opinion 
obviously, others in MARS may disagree.

In my direct activities, members of all three MARS programs are 
working jointly in the use of ALE where a Tri-Service ALE network 
operates 24/7 where MARS-ALE is the ALE tool set for most users and 
is the ALE LQA front end for the existing and developing MARS Traffic 
System. At present we have MARS-ALE via Telnet communicating with 
back end servers, one is for network activity reporting automation 
and the other is the BBSlink server.

Any MARS-ALE based station can use the report automation tool for 
feed the view from their station perspective (its the MARS-ALE/BBS 
24/7 perspective that will always be fed) when on-the-air, on a 
selected period of all channel acty via Internet e-mail to one or 
more end points for display, analysis and reporting in near-real 
time, there is an SQLdbase being developed and host of reporting 
tools, at present one such feed is to a closed Yahoo forum such as 
this one ( http://groups.yahoo.com/group/MARS-ALE-SITREP/ ) where all 
that data exposes all the network acty as to Soundings, linking 
calls, what stations were linked one on one or one on many etc., and 
network diagrams and other reporting can be derived, our reporting 
tools are not all in place yet and manual processing has really 
become difficult as the acty has increased.

The BBSlink sever at present supports WINLINK.ORG and MARSALE.ORG ( a 
new development that uses standard SMTP/POP3 client and webmail when 
not on HF) on the back end where only Air Force and Army MARS can use 
WL2K. This is a very new development that has only just entered wider 
testing. Any supported MARS-ALE ARQ protocol, including the use of 
Tactical AMD messages can be used to send and receive e-mail ( AMD is 
painful on incoming e-mails if more than one line !)  and not just 
PACTOR x, MARS-ALE supports a number of ARQ protocols on the PCSDM 
and provides external TNC/Modem support. The next addition to the 
BBSlink server with be WA8DED emulation so that MDS, MSYS and Winlink 
Classic will see MARS-ALE as just a TNC on another port, at that time 
NMCM and Air Force MARS will have a full radio-to-radio and Internet 
HF e-mail solution as BBSlink will at one site all combinations. My 
MARS-ALE/BBS which is running at the moment has accepted traffic 
today from stations where test message were send by the Remote ALE 
user during the connection using both WINLINK.ORG and MARSALE.ORG 
agents in separate messages sent, its just a matter of the addressing 
to tell BBSlink which agent to use, the same will be true of 
MDS/MSYS/Winlink Classic support when added, thus if Internet is 
completely down that BBS has a radio-to-radio path, the user still 
has a path to send their out going traffic. Our interface for all 
these BBS systems supports the Remote ALE user to list ( if desired) 
any incoming messages and chose which to read as during an ECOM event 
in the field, one does not want to reading waiting for a ton of 
incoming traffic if the order of business is just to send their 
outbound traffic, but one may be looking for a specific message or 
two inbound, this is not an option when using the normal WL2K PBMO interfaces.

With MARS-ALE the use of AMD, DTM and DBM modes are automatically 
detected and if ARQ responded to in same, this is also true of 

Re: [digitalradio] 14100.5 kHz USB - ALE Channel Bandwidth, IARU Beacon Guardband

[Steve Hajducek]

Hi Guys,

For optimal ALE reception you want your RX passband set to 1625hz 
when using less than 2.8 or 3.0Khz IF filtering, anyone running a ham 
rig with the typical 2.1 to 2.7 filtering will need to enable IF 
shift and move it up in frequency else you are starving the modem 
from seeing all 8FSK tones properly. Depending on the particular 
software tool being used for ALE intercept this can be seen visual if 
a tuning display is provided, such as the TUNE Tones display in 
PC-ALE and the water fall in MultiPSK.

/s/ Steve, N2CKH


At 12:50 PM 2/24/2007, you wrote:
>The ICOM 756 Pro 2 centers on 1500 Hz. If anyone knows if you can change
>the center, I would like to know how to do it. My preference would be
>1000 Hz since it makes it easier to increment one kHz from the dial
>frequency.
>
>As mentioned to Jose, the correct frequency you were operating on was
>14.111, not 14110.
>
>SSB nets are not running digital modes and their frequency is the dial
>frequency, whether USB or LSB. CW nets are based on the zero beat
>frequency, but different rigs have different CW offsets. Many rigs have
>the ability for the operator to change the CW pitch to center the
>received audio frequency in the filters as well as meet operator
>preference. The other operator has no idea that you are doing this as
>long as you are zero beat on the frequency.
>
>KV9U
>
>
>John Bradley wrote:
>
> >  I appologize, since I didn't realise that it is equipment 
> defficiencies which do not allow you to change from the 1500hz center point.
> >  It must be an Icom thing, since the Kenwood equipment I am using 
> permits centering on 1000,1500, or 2210 hz.
> >
> >  I think that you should take up your cause with all the many 
> digital, RTTY and SSB nets around the world who only specify
> >  a VFO frequency as opposed to the exact frequency of the offset 
> or sideband in use. It certainly is a "slap in the face" to good 
> operating practices and should not be condoned by experienced 
> operators anywhere.
> >
> >  Some remedial math might also be in order since 14109.5 + 1500hz 
> is 14111.0  ( not that this supports my argument or anything)
> >
> >  "Nuf said, will continue to bumble along with VFO frequencies, 
> trusting that others can deal with the vagarities of their equipment,
> >  and hope that we can co-exist for the common good.
> >
> >  somewhat tongue-in-cheek,
> >
> >
> >  John
> >  VE5MU
> >
> >
> >
> >
> >
> >
> >--- 
> ---
> >
> >
> >  No virus found in this incoming message.
> >  Checked by AVG Free Edition.
> >  Version: 7.5.446 / Virus Database: 268.18.3/699 - Release Date: 
> 2/23/2007 1:26 PM
> >
> >
> >
> >
> >
> >
> >No virus found in this incoming message.
> >Checked by AVG Free Edition.
> >Version: 7.5.446 / Virus Database: 268.18.3/699 - Release Date: 
> 2/23/2007 1:26 PM
> >
> >
>
>
>
>
>
>Announce your digital  presence via our DX Cluster 
>telnet://cluster.dynalias.org
>
>Our other groups:
>
>http://groups.yahoo.com/group/dxlist/
>http://groups.yahoo.com/group/themixwgroup
>http://groups.yahoo.com/group/contesting
>http://groups.yahoo.com/group/wnyar
>http://groups.yahoo.com/group/Omnibus97
>
>
>Yahoo! Groups Links
>
>
>

Re: [digitalradio] ALE with MULTIPSK + Tests of the MIL-STD-188-141A mode (ALE) and new modes Unproto and ARQ FAE

[Steve Hajducek]

Hello All,

Patrick is to be commended on his efforts to date with regard to 
adding ALE capabilities to MultiPSK in support of Amateur Radio 
application single channel.


I have been using his new a bit for the past two days and I find his 
new ARQ FAE protocol which is based on the DTM ARQ and DBM ARQ 
protocols of ALE with his modifications and influence of PAX. Its 
bi-directional as is DBM ARQ and its much faster than DBM ARQ and 
offered in two frame selections, 30 and 63 characters.


The ALE support provided to date in MultiPSK is limited with regard 
to full ALE operation, it will decode a number of ALE data 
transmissions, it fully supports an ALE linking call being made or 
received and it will display and AMD as well as send an AMD at ALE 
link. I have not learned how to send an AMD other than during the ALE 
linking call if supported. I have not learned how to send and DTM or 
DBM based messages eitther, if supported. It will decode for display 
DTM and DBM traffic however there are issues with support at this time.


The real thing of interest however is the ARQ FAE protocol that 
Patrick has developed, as stated, its a hybrid protocol that is a 
full ARQ and based on the ALE standards as is GTOR and is very fast 
compared to either. It has great potential. I have used is keyboard 
to keyboard and tested the bi-directional aspect here, that was 
challenging, luckily I can type on two keyboards with both hands at 
the same time but its sending the characters as typed and not on the 
enter keystroke, thus the challenge, I have also sent using ARQ FAE 
from a text file, I have not learned how to cut and paste into 
MultiPSK if supported, to send a message.


DBM ARQ is a very robust FSK protocol, its deeply interleaved and 
resists QRM, QSB and fading, in my opinion its better than GTOR, the 
tweaks that Patrick has made with ARQ FAE are my opinion a wonderful 
step toward an excellent new Amateur Radio PC Sound Device Modem 
based ARQ protocol based on the best of DBM ARQ and PAX.


/s/ Steve, N2CKH/AAR2EY



At 12:16 PM 2/21/2007, you wrote:

Hello to all,

As said by Bonnie, Multipsk proposes now some basic ALE functions, 
but not in the official version (which is still 4.1.2). For 
instance, it is only under a test version.
For the Hams interested by testing ALE, Unproto or ARQ FAE, here is 
the original test message.


73
Patrick

Re: [digitalradio] Need a PDF manual (or any format) for the MFJ 1278 Data Controller

[Steve Hajducek]

Hi Jonathan,

Can you accept a 26MB email?

/s/ Steve, N2CKH


At 12:56 AM 2/13/2007, you wrote:
>Howdy folks,
>I need this manual if you have it on PDF. No longer on their site.
>Thanks,
>Jonathan KC7FYS

Re: [digitalradio] US Hams Codeless Feb 23

[Steve Hajducek]

Hi Paul,

Considering that neither the ARRL or the FCC did the right thing, 
which would have been to make the Technician Class license the entry 
class license that it really could have been by maintaining the 
Novice Subbands and keeping the Novice RF input power for all classes 
of licensees but allow all modes, voice and digital to be used in the 
sub bands on 80, 40 and 15m and not just restricting such ( and even 
not all modes) operations to 10m, then yes, there really is no choice 
but to upgrade to General as the Technician class license on HF remains a joke.

/s/ Steve, N2CKH


At 06:39 PM 1/20/2007, you wrote:
>Nope - General and higher will have all modes.
>
>For no-code techs, it's the opposite -- except on 10 meters, HF
>privileges for codeless techs will be *CW ONLY*: no SSB, no SSTV,
>no RTTY, no soundcard digital -- except for CW.  ON/OFF keying
>using the international morse code.
>
>On 10 meters, they'll be allowed CW and data in the bottom of the
>band, and SSB-only from 28.3 to 28.5
>
>I suspect most of the techs who choose to come down to HF frequencies
>will upgrade (written test only) to General or Extra.
>
>
>larry allen wrote:
> > Assuming the no code licencee can only use voice... what happens when they
> > loose interest in only being able to use voice
> > Larry ve3fxq
> >
>
>
>
>Announce your digital  presence via our DX Cluster 
>telnet://cluster.dynalias.org
>
>Our other groups:
>
>http://groups.yahoo.com/group/dxlist/
>http://groups.yahoo.com/group/themixwgroup
>http://groups.yahoo.com/group/contesting
>http://groups.yahoo.com/group/wnyar
>http://groups.yahoo.com/group/Omnibus97
>
>
>Yahoo! Groups Links
>
>
>

Re: [digitalradio] Ham software authors afraid of ALE - NOT!

[Steve Hajducek]

Hi Rick,

No.

The only similarity between PACTOR would be PACTOR I and that would 
be that both are FSK, actually 2FSK vs. 8FSK and that is about it.

The similarities between ALE, particularly DBM ARQ and GTOR are much 
more, its a still a 2FSK vs. 8FSK in that regard, but the development 
of GTOR was greatly influenced by the standards for ALE and DBM ARQ, 
read the following:

http://jitc.fhu.disa.mil/it/tptt.html

GTOR in my opinion is far superior to PACTOR I.

Here are ALE documentation links for you:

http://www.arrl.org/tis/info/ale.html

http://www.armymars.net/ArmyMARS/HF-Email/resources/188-141B.pdf

http://jitc.fhu.disa.mil/it/tptt.html


/s/ Steve, N2CKH




At 09:16 AM 1/17/2007, you wrote:


>Isn't there some similarity to this 8FSK waveform and Pactor 3?
>
>KV9U

Re: [digitalradio] Re: DBM ARQ tests ?

[Steve Hajducek]

GM Andy,

There are some issues with DBM ARQ in PC-ALE which will be going 
away, thus the use of RESET MODEM may often be required at times 
during poor conditions.


Also remember to NEVER, NEVER use any of the TRACING functions when 
you want to use the tool in two-way communications and you want 
proper results, When/If you use TRACING, if using more than a 1Ghz 
PC, then you should only use 1 or 2 at the max 3 at a time and be 
sure to reboot the tool after using them. They were implemented for 
development and testing and not for real use, they load the system 
resources heavily. Also, keep the MIL-STD-188-110 modem OFF and use 
SYNC and TONES display for the same system resources loading 
reasoning. Some people have RX Words on all the time for some reason, 
not a good idea for best results, perhaps on a 3Ghz PC its not an 
issue, don't know as I don't have really up to date PC's here, my 
best are 1Ghz boxes. Also, running any version of PC-ALE that has the 
MIL-STD-188-110 modem requires a Sound Device that directly supports 
a 48Khz sample clock and you really should use nothing less than 
Windows 2000 Professional, the use of Windows Me and all the other 
stuff is not a good idea.


/s/ Steve, N2CKH

At 08:03 AM 1/17/2007, you wrote:
Thanks, I tired to find a way to trick it last night but failed, 
this method should be fun to try.


Folks, PC-ALE takes about 2 minutes to set-up  so if you want to try 
it, let me know...I can talk you through the basic set-up.


Andy.


On 1/17/07, expeditionradio 
<[EMAIL PROTECTED]> wrote:


>Andy K2UK wrote:
>
> If someone wants to try DBM ARQ, let me know. You will need
> PC-ALE and a regular ALE link and then we can switch to DBM ARQ.

Hi Andy,

If you ever need to, you can also trick the PCALE program to think it
is LINKED by sending a GLOBAL ALLCALL. However, that will also stop
all the other ALE stations scanning for 10 minutes or until they
timeout. It is good ALE manners to send a CLEAR LINK when you are
finished with your ALLCALL test. Alternatively, you could send the
GLOBAL ALLCALL into a dummy load or just turn down your transmitter
audio drive.

Bonnie VR2/KQ6XA




--
Andy K3UK
Skype Me :  callto://andyobrien73
www.obriensweb.com 

Re: [digitalradio] Re: HF Packet BBS?

[Steve Hajducek]

Hi Rick,

The U.S. Declaration of Independence of late has become a popular 
MARS EXERCISE test message in testing MARS-ALE and with ALE DBM ARQ, 
that as the body of the message along with the standard MARS message 
header and tail takes just over 6 minutes if there are no ACK/NAK 
failures using a frame size of setting of 10 seconds of data which 
means less data is sent prior to an ACK/NAK, if you increase that 
from 10 to 100 the message will go some what faster as there are less 
ACK/NAK handshakes, however if their is a handshake failure due to a 
poor channel than a much longer frame needs to resent which would 
mean the message would take much longer than if a shorter frame was sent.

PC-ALE always requires and ALE link first, you can't just use DBM 
ARQ, however a ham program can be written to drop the ALE link and 
just implement DBM BRD and DBM ARQ, all the details are published in 
standards to do so. In MARS-ALE as soon as I have the time such will 
be the case as well. PC-ALE is configured as a data message tool 
where you type or paste a message and just send it. The interface is 
not a keyboard to keyboard interface per see as you need to go 
through menus to keep getting back to the point where you send the 
message. However in the most recent version there is a one lone data 
bar for sending a message in any mode, this provides for keyboard to 
keyboard without the changing focus, and DBM ARQ is bidirectional, 
thus technically both station can both be sending those one line 
messages at the same time and as fast as they can type, but the 
interface is really designed to buffer all this so that you can, I 
have testing the bidirectional aspect and it does work but you can't 
load it up, you can send a full message from both ends and watch the 
exchange where they will pop up on each stations display, the 
shortest message will usually finish first. The Military 
implementation of DBM ARQ seems to be all keyboard to keyboard 
buffered terminals with type ahead buffers triggered to send when x 
amount of data is ready by configuration parameter settings. I did 
recently add LISTEN mode to MARS-ALE which is like GTOR Monitor or 
PACTOR PLISTEN for DBM and DTM ( DTM is not deeply interleaved as is 
DBM) and its rather amazing how well one can monitor a DBM ARQ 
message when not in the link, yes you will get frame repeats when 
sent, but unless you loose sync on a poor channel you get the entire 
message and with far fewer repeats than you do when listening to 
PACTOR I by the way.

By the way, data compression can be applied to DBM ARQ where mixed 
cased messages will benefit the same as GTOR and PACTOR do, thus you 
can more than double the throughput that I mentioned earlier, this 
will be in the next release of PC-ALE as a user selected option.

When you leave PACTOR I, which for a PII or PIII modem is just used 
for the initial link and then a negotiation to a higher mode/data 
rate you start to move away from FSK, basically what SCS has done is 
to follow what the Military has been doing over the last 10+ years 
whereas PIII is pretty much the SCS version of Military waveform's 
that are used on the MIL-SDT-188-110 modem.

Someone should really look at making a stand alone DBM ARQ terminal 
program and DBM ARQ BBS if an excellent FSK ARQ PCSDM based system is 
desired, the speed and robustness are all good and the protocol is 
all published and free to implement. I believe that I read on this 
forum that ALE Sounding and Decoding was added to MultiPSK for an 
experiment? That's not really something that has any usefulness in a 
program such as MuliPSK, however DBM ARQ would be just the thing.

The turn around time after the sending station sends a DBM ARQ frame 
( or block ) is seconds, not milliseconds, the receiving station 
should immediately respond, but in a few seconds if no response is 
heard or if the response is heard and is bad, the sending station 
sends the last frame again, if the receiving station gets a frame 
twice that match then one is tossed, when all is said and done if the 
message is complete you have success and if not you have a failed 
message. During the process if the number of retries set to send a 
frame is ever exceeded ( it resets on each successful frame) then you 
have a failed message. Lately with MARS-ALE we have been sending long 
messages on poor channels over short and long distances where DBM ARQ 
gets through and GTOR and PACTOR I at times fail, pretty amazing, 
here I am using a KAM Plus, KAM XL for both modes and also an SCS 
PTCII Pro at times, but mostly the KAM Plus on my 24/7 station. That 
24/7 ALE station by the way is using the on-board AC'97 sound device 
and its a laptop PC, worst case when talking about good, low jitter, 
low noise PCSDM, PCI is much better and external PCSDM is the best, 
which I also have and use, but I always do most of my development 
work with worst case, obviously when switching over to the 
MIL-STD-188-110 PCSDM

Re: [digitalradio] Re: HF Packet BBS?

[Steve Hajducek]

Hi Andy,

A system that implemented the ALE Data Block Message (DBM) ARQ 
protocol using the PC Sound Device Modem (PCSDM) which at a raw 125 
baud with its deep interleaving providing a full 3x throughput on a 
good circuit where no ACK/NAK failures occurred would be much better. 
GTOR which blows away PACTOR I is blown away by ALE DBM and best of 
all it can be easily implemented on the PCSDM as the ACK/NAK 
is  variable in seconds and not milliseconds. In MARS we sending 
messages using DBM ARQ and FTP on channels where GTOR and PACTOR I 
are failing, its really something to see for yourself. The DBM 
protocol is extremely robust and it supports bidirectional messaging 
as well which is an interesting twist when two stations are attended.

/s/ Steve, N2CKH

At 07:20 PM 1/16/2007, you wrote:
>Jose's comments have been helpful.  I used VHF packet in the old 
>days and also used the first satellite gateway on the east coast. 
>run by my neighbour down the street!
>
>When I started this thread I had one goal in mind, a simple way that 
>hams can send brief  email without use of the Internet ,  without 
>the use of expensive proprietary protected modes  (e.g. PACTOR II 
>and III), AND without a TNC (just  using soundcard packet).
>
>  Although 300 Baud is not very robust and quite slow, what would be 
> wrong with ...say, 10 HF Packet BBS's strategically located around 
> the world, perhaps on 30 meters?  I would not expect them to 
> forward mail to local VHF gateways or use the Internet , instead 
> people interested in mail would connect to the HF Packet BBS 
> directly and retrieve their own mail.  If all 10 BBS need to have 
> the same mail they could forward to each other via a backbone , 
> that would be a smaller task because the traffic load would require 
> less forwarding than if VHF or Internet forwarding was part of the plan.
>
>Of course PSK Mail might be a better plan but would need a Windows 
>release to make it more accessible to the Masses.
>
> From an "emergency communications" point of view, my goal would be 
> a simple method of communication that allows message storage.  No 
> expected links to government communication networks, no elaborate 
> node interfacing to the Internet.  Simply turn on a radio, activate 
> a computer, issue a "connect" command, enter a "Send Private" or 
> Send Bulletin"  Command , type a brief message and save.
>
>Andy K3UK.

Re: [digitalradio] What mode is this?

[Steve Hajducek]

Hi Leigh,

4FSK Clover Amateur HF Email Net

/s/ Steve, N2CKH

At 08:44 PM 12/17/2006, you wrote:
>4 parallel signals, each looks about like 63Hz wide with a guard band
>about that size between them.
>Heard for many minutse on 14.062.
>Waterfall at http://wa5znu.org/log/2006/12/what-mode.html
>
>Leigh/WA5ZNU
>
>
>
>Connect to  telnet://cluster.dynalias.org a single node 
>spotting/alert system dedicated to digital and CW QSOs.
>
>
>Yahoo! Groups Links
>
>
>

RE: [digitalradio] Re: New ARRL Petition

[Steve Hajducek]

Hi Walt,

I had also meant to mention that MT-63 is the most popular PCSDM FEC 
protocol being used in MARS at this time.

/s/ Steve, N2CKH/AAR2EY

At 11:39 AM 12/14/2006, you wrote:
>Doc,
>
>The problem with SHARES, MARS, Red Cross and other NGO disaster 
>operations frequency/spectrum assignemnts is that the assignments 
>say what type of transmissions are allowed.  Thus if the frequency 
>is assigned for SSB, then you cannot use CW or a data mode...even if 
>the organization desired to.  SHARES and MARS frequencies have a 
>better change of getting other modes allowed on their frequencies 
>than other NGOs.
>
>Walt/K5YFW

RE: [digitalradio] Re: New ARRL Petition

[Steve Hajducek]

Hi Walt,

SHARES, is VOICE, PACTOR I and ALE AMD at this time.

MARS is using just about every FEC/ARQ protocol common in the U.S. In 
MARS CW, it long ago was obsoleted. RTTY has not officially been 
obsoleted, but is all but gone. In MARS AMTOR/SITOR is still seeing 
use, mostly in FEC, but fading away. PACTOR I, GTOR, CLOVER, PACTOR 
II and PACTOR III in that order see the most use via commercial 
TNC/Modems. Next comes MIL-STD-188-110x modems and various wave 
forms. ALE and AQC-ALE acty is ramping up and thus more use of the 
ALE DTM and DBM protocols.

Both SHARES and MARS will be moving more to ALE network operations 
and to full STANAG 5066 in time as are all U.S. Government agencies 
and supporting entities.

/s/ Steve, N2CKH/AAR2EY

At 11:39 AM 12/14/2006, you wrote:
>Doc,
>
>The problem with SHARES, MARS, Red Cross and other NGO disaster 
>operations frequency/spectrum assignemnts is that the assignments 
>say what type of transmissions are allowed.  Thus if the frequency 
>is assigned for SSB, then you cannot use CW or a data mode...even if 
>the organization desired to.  SHARES and MARS frequencies have a 
>better change of getting other modes allowed on their frequencies 
>than other NGOs.
>
>Walt/K5YFW

Re: [digitalradio] Re: New ARRL Petition

[Steve Hajducek]

GM Rick,

The FCC needs to attend some "Keep It Simple Servant" a.k.a. KISS 
training seminars as well as bring FCC Part 97 into the modern world. 
Those members of this forum that on OCONUS for the most part must 
laugh themselves silly at all this non-sense.

In my personal opinion, there are a number of data modes being used 
by U.S. Amateurs that are in gray areas or outright illegal taking 
into account FCC Part 97 and many Amateurs have no clue that this is 
the case do the complexity of the Part 97 and even the lack of 
enforcement of the rules on the part of the FCC, some good hardware 
protocol examples are the use of PACTOR III and MIL-STD-188-110 
modems, but for different reasons as detailed via this forum on many 
occasions by various individuals.

I believe that the FCC should simplify things regarding these issues 
and open the door to more experimentation and enhancement of data 
communications by U.S. Amateurs by simply allowing for 3Khz BW 
maximum and data rates through 3600bps ( baud rate will vary by data 
content, but average at 1200 baud ) where all protocols must be fully 
documented in public view so that anyone can develop the capability 
to monitor the transmissions, this includes any data compression 
formats being applied.

/s/ Steve, N2CKH


At 10:16 AM 12/14/2006, you wrote:
>Jim,
>
>Pactor 3 is not classified as a narrowband mode. It is a fairly wideband
>digital mode.
>
>The FCC made a very incorrect claim in the Report and Order, that stated:
>
>"The Rules also subdivide all but two of these bands into a frequency
>segment in which amateur stations may transmit only emissions that
>require a narrow bandwidth, such as telegraphy, data or radio teletype
>(RTTY) emissions, and a frequency segment in which amateur stations may
>also transmit emissions that require more bandwidth, such as voice or
>image emissions."
>
>The fact is that there are other modes such as P3, wide versions of
>Olivia, MT-63, that are similar to the bandwidth needed for voice
>communication.
>
>They go on further to make it very clear that they view the Data/RTTY
>area as narrowband and the voice/image area as wideband and divided up
>80 meter band to "result in a more equitable division of spectrum
>between users of narrowband and wideband mode."
>
>Footnote 60 is most interesting:
>
>"... this division would result in two hundred channels for stations
>transmitting telegraphy and other narrowband emissions and one hundred
>thirty three channels for stations transmitting voice and other wideband
>emissions."
>
>They also seem to be suggesting that 500 Hz is the maximum size that is
>appropriate for narrow band modes and why they made the limit at that
>point, but they also would not go along with the ARRL request that they
>not impose a 500 Hz BW limitation on data emissions an d would not make
>it 3 KHz, yet they allowed the previous modes to be wider.
>
>73,
>
>Rick, KV9U

Re: [digitalradio] Re: Dec 15?

[Steve Hajducek]

Hi Danny,

Do they still send in ASCII?  What a waste, I remember back when the 
FCC first allowed it on HF, oh my, try to use 300 baud !

They should start using MT-63 as all PC Sound Device Modem based 
Amateurs would then be able to get solid FEC copy and drop ASCII, for 
that matter, on technical grounds, RTTY could be dropped as well, but 
there are still those within the ARS that only use RTTY for digital 
data mode acty.

/s/ Steve, N2CKH

At 08:16 AM 12/14/2006, you wrote:
>Hi Danny,
>
>I was just being facetious to make my point.
>
>I too used to listen to W1AW.
>
>But in CW, RTTY, AMTOR, ASCII and VOICE ?
>
>73
>
>Bill  KA8VIT
>[EMAIL PROTECTED]
>http://ka8vit.com

Re: [digitalradio] best pcale interface for icom 706

[Steve Hajducek]

Hi OM,

The use of the MIC port via a RigBlaster for both TX audio and PTT 
and fixed audio output for RX audio.

/s/ Steve, N2CKH

At 02:59 PM 12/11/2006, you wrote:
>Since there has been several notes about interfaces that are not
>optimal, What about those that are good. Whats the best way to
>interface a icom 706 to laptop running PCALE?

Re: [digitalradio] Basic Encrypted Data Communication Prior to MIL-STD-188-110

[Steve Hajducek]

At 05:14 PM 9/21/2006, you wrote:
>Prior to the wide deployment of MIL-STD-188-110 equipment, most U.S. 
>military HF data communications used RTTY/ASCII modes through 
>encryption devices.  These were large and not really field portable.

Hi Walt,

The MIL-STD-188-110 parrale16 tone modem with or with the pilot 
carrier (probably without, anyone monitoring the audio would get a 
heahache) at 600bps would be a good choice for ham use, though as 
usual, many would balk at the over 2Khz BW, however it would I 
believe be FCC legal.

/s/ Steve, N2CKH




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
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:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] Don't hear much clamor about, Chirp, DominoEx, MFSK16 anymore!

[Steve Hajducek]

Hi John,

I like an ALE for starters with DBM ARQ chaser... hi hi

I have just had a long QSO after an AQC-ALE link (this is the latest 
ALE that is only found in state of the ar Military rigs) where I was 
sending DBM ARQ and get my handshakes and the other station was 
sending AMD Orderwire and getting there handshakes, that's another 
cool thing you can do with MARS-ALE, but sides of the QSO do not need 
to be sending with the same protocol as its all automatically 
detected on RX in by modem and its knows how to respond, the RX 
station never needs to select anything as long as all the modems are 
enabled and default parameters are being used.

As to OLIVIA, I need to give that a spin, its been around for almost 
a year too !

/s/ Steve, N2CKH

At 09:34 PM 9/20/2006, you wrote:
>There are still a lot of us on OLIVIA and MFSK , both on 40and 20. 
>Had a great chat with Txema in Spain on 20 this past weekend
>
>Think a lot of folks on here have consumed too much ALE, and 
>forgotten about using these modes :}
>
>Would like to try a DominoEX and PAX2 QSO sometime. You up for that?
>
>John
>VE5MU
>
>   - Original Message -
>   From: Jerry W
>   To: digitalradio@yahoogroups.com
>   Sent: Wednesday, September 20, 2006 12:02 PM
>   Subject: [digitalradio] Don't hear much clamor about, Chirp, 
> DominoEx, MFSK16 anymore!
>
>
>   Where did everyone go that used to be on Chip64, DominoEX, MFSK16?
>   There is a little Olivia, but seems to be a lot less users than when
>   it was released for Multipsk and MixW. I know there was a DominoEX
>   contest about a month ago, but was not able to participate due to
>   crummy weather, rain/thunderstorms.
>
>   73,
>
>   Jerry - K0HZI
>
>
>
>
>
>
>--
>
>
>   No virus found in this incoming message.
>   Checked by AVG Free Edition.
>   Version: 7.0.405 / Virus Database: 268.12.5/451 - Release Date: 9/19/06
>
>
>[Non-text portions of this message have been removed]
>
>
>
>Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org
>
>Other areas of interest:
>
>The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
>DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
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:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Dave,

Regarding the Sounding aspect of life, not all stations need to be 
Sounding and not all stations need to be Sounding once per hour. 
Sounding can be adjusted to accommodate the loading of a network. The 
more stations that are ALE active on the same channel less frequent 
you sound and longer you set the LQA data base time out.

For example you can implement a specific network where you really 
want to stay on the changes in propagation where you have x number of 
target stations in each geographic area Sounding each 30 minutes 
(when not otherwise occupied) over 10 channels where the purpose of 
that network is for the users to establish a link with one of the 
Sounding stations to move traffic. So, say all 50 U.S. States had an 
ALE station at each State EOC (just an example) or say the ARRL 
sponsored a ham in all 50 states using an ALE station and all these 
stations in either example connected to each other periodically, then 
any user Scanning would pick up there Soundings when Scanning and 
whenever a user (from either of the two example networks) want to 
send a message via either network, they would just call the target 
Sounding station in that network, establish a link on the best ALE 
LQA ranked channel and leave a message. You can build on all this, 
from their the relay of that may could wait for the station operator 
to manually relay it or a automated system can be created with 
routing etc., many uses have a flat model mailbox or BBS configured 
where you link with ALE and then switch to PACTOR x  and leave/pickup 
your traffic. This is ALE Network Operations where the network is 
planned, serves an on going 24/7 purpose for known number of stations.

However, getting back to Amateur Radio focus where we operate more 
loosely on a daily basis an application of much less frequent 
Soundings and longer LQA time outs as mentioned up front would 
suffice for our casual operations where stations sounded once every 3 
hours or 5 hours, the LQA database can be maintained for days, this 
yields a on going daily trend analysis of LQA data  (the systems must 
be running 24/7 for this approach) to base the automatic linking call 
on as all data is listed as good since it has not been aged out of 
existence and if you did not hear your target station on all 10 
channels today yet, then yesterdays data would be used, for the same 
time of day, day to day, propo is usually repetitive. So as you can 
see there is no reason to get all hung up on the massive proposition 
of a Million or 100,000 or 10,000 or 1,000 stations Sounding 
constantly with a solid wall of ALE 8FSK Soundings, its just a matter 
of adjusting the ALE operations as the growth of ALE usage takes place.

I hope this helps everyone understand the flexibility and application 
of ALE better.

/s/ Steve, N2CKH



At 12:24 PM 9/1/2006, you wrote:
>If propagation allows 1000 amateur ALE users to hear each other on
>the same pilot channel, and they are all sounding for 10 seconds
>every hour, then wouldn't the pilot channel be massively
>oversubscribed to the point where no station could decode anything?
>
>1000 users times 10 seconds is 1 seconds of transmission per
>hour, but there are only 3600 seconds per hour. With no collision
>avoidance, wouldn't anything more than 1200 seconds of transmission
>per hour would be problematic?
>
>   73,




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Dave,

I really could not say for sure based on your criteria, depending on 
what you mean as asked.

However using ALE and an appropriate Global Allcall or Anycall is 
very powerful. If the propo is there for the given frequency at the 
given time of the call, if there were 1,000 stations monitoring the 
channel and I placed a Global call then I could potentially link to 
all 1,000 or 10,000 or 100,000 stations, its unlimited, they could be 
sitting there or scanning past, its just my station transmitting in 
this case, they don't and then I could send an ALE DBM BRD (FEC) or 
FS-1052 BRD (FEC) message and potentially all stations (unlimited 
number) may receive that message. I could then send a all clear and 
clear the link and those that were Scanning will continue. That is a 
very powerful capability, QST to anyone basically. You can be more 
selective with these calls then you can be very selective and use a 
Net Call, so if there were only 1,000 people monitoring within range 
of may that had the same Net Call entered and yet there were 10,000 
over all, I would potentially just get those 1,000 using the same Net 
Call and not any of the other 9,000 listeners. I can be even more 
selective and make a GROUP call were I have to enter each Self 
Address (Callsign) of the intended stations that I want and only 
those will potentially be linked to and receive my message.

/s/ Steve, N2CKH/AAR2EY

At 12:09 PM 8/29/2006, you wrote:
> >>>AA6YQ comments below
>
>--- In digitalradio@yahoogroups.com, "expeditionradio"
><[EMAIL PROTECTED]> wrote:
>
>Fortunately, that's not the way it works with ALE, John. There is
>plenty of room for thousands of ALE operators around the world on
>the few ALE HF channels we presently use now. Signals are separated
>by time, location, and propagation.
>
> >>>Simple arithmetic that no one has disputed shows that with one
>pilot channel per amateur band, ALE can support between 64 and 128
>simultaneous users. If your statement that "Signals are separated
>by time, location, and propagation" means that ALE operates as many
>disjoint sub-networks, then your earlier claim that one ALE user can
>reliably contact any other ALE user is false -- an ALE user can only
>reliably contact one of the 100 or so users on the same sub-network.
>This sounds a lot like a VHF repeater.
>
> >>>However, HF propagation is not nearly that "clean" -- it
>constantly shifts over the course of the day, particularly on the
>higher bands. Sub-networks will sub-divide; since each station only
>sounds once per hour, members of a sub-network may find that stations
>supposedly connected do not respond. Disjoint sub-networks will also
>merge; if this happens to two sub-networks that each have ~100 active
>users, the result will be a sub-network whose pilot channels are
>oversubscribed, and users will be dropped as described below.
>
>
>There is some collision prevention within the ALE protocol. As for
>soundings, when collisions do occur, it is not a problem, because of
>the redundancy of timing and channels. If only two seconds
>of a desired sounding gets through, that is enough because it is only
>a simple callsign we are looking to decode, not a complete message.
>
> >>>That's not correct, Bonnie. If only 2 seconds of a 10-second
>sounding "get through", then on average 80% of the receiving stations
>will miss the sounding because they were scanning other frequencies
>during that 2 second interval. These receiving stations will conclude
>that the sounding station is not available, a "misunderstanding" that
>can not be corrected until the station's next sounding an hour later.
>But unless the congestion terminates (users drop out, or propagation
>divides the sub-network), then 80% of the receiving stations will
>again reach the wrong conclusion at the next sounding.
>
>
>For future expansion, the flexibility of the ALE sytem makes
>it possible to make a variety of adjustments, so the timings
>and channel lists we use today are not etched in stone.
>Right now, we use timings and settings that are optimized for
>light load and maximum weak signal decoding. In the future we
>may want to optimize for peak loading, at the discretion of the
>operator, or as part of the overall amateur ALE strategy.
>
> >>>Omnidrectional NVIS antennas and tuners set to bypass on receive
>seem inconsistent with optimizing for maximum weak signal decoding.
>
> >>>As currently described, amateur ALE sound like a fine way for
>local groups of amateurs to connect, though propagation may
>occasionally separate them or unite them with other groups. If
>groups are limited to ~30 users, loss of connectivity due to pilot
>channel overload when propagation combines multiple sub-networks
>should not be a frequent occurrence.
>
> >>>These limits can be overcome with faster scanning and more
>frequencies per band, as military deployments have demonstrated. Both
>of these solutions are problematic for amateurs, however: the former
>because the min

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Rick,

At 01:24 PM 9/1/2006, you wrote:
>Can you explain how it is that you can run a symbol rate of 2400 (baud)
>with 188-110A and it works very well running at this extremely high
>speed for HF? And yet other modes, such as Packet, don't work very well
>at 300 baud, and Walt has pointed out that government studies had show
>that under 50 baud was about the optimum for the types of conditions we
>often find on HF?

See my reply to Mark.


>Why would we not just increase the baud rate of MT-63 or MFSK16 to get a
>similar speed boost if it can work that well?

There is a lot of differences here, if you focus on the MT-63 part of 
your query that is more like the FSK aspect of MIL-STD-188-110 that 
we have not coded but in only BRD and at a fixed data rate.


>How tight do you need the frequency tolerance to be to enhance weak
>signal modes? The ICOM Pro rigs run at around 0.5 ppm, which seems
>several orders of magnitude better than what some of the digital mode
>programs require. I wonder how much better a weak signal/difficult
>condition mode we could come up with if there was a tighter frequency
>tolerance.

That more than good in my book, it would be nice if everyone used 
such a radio, but you have guys using 1980's rigs that were the first 
to offer RS-232 control.

/s/ Steve, N2CKH

>You might recall the early developement of Clover I, by Ray, W7GHM. If I
>remember right, the signal was phaselocked to WWV or other time standard
>frequency. Later this was abandoned with DSP developed as a bus card and
>the computer mostly being used as a dumb terminal, but it will never be
>as tight a frequency tolerance as 10 e -6 or so:)
>
>73,
>
>Rick, KV9U
>
>
>Steve Hajducek wrote:
>
> >Hi Rick,
> >
> >ALE itself is 8FSK, 125 baud, all protocols on that modem.
> >
> >After an ALE link, any protocol, be it an ALE 8FSK or other can be
> >utilized via other modems. Built into PC-ALE/MARS-ALE is a
> >MIL-STD-188-110 modem, MARS-ALE also actively supports external
> >TNC/Modems. PC-ALE passive provides this support as well using any
> >third party program.
> >
> >The MIL-STD-188-110A serial tone modem is just that, a single PSK
> >carrier frequency that by the standard is locked at 1800hz using a
> >constant 2400bps Symbol Rate. Then coded data rates from 75-2400bps
> >and 4800bps un-coded, this is what is supported by PC-ALE. MARS-ALE
> >supports 1200hz, 1500hz and 1800hz selections for the PSK carrier and
> >a symbol rate as low as 1600bps (the only one that can be used with
> >the 1200hz PSK carrier) to achieved lesser IF BW requirements from
> >the standard 300-3300hz (3Khz). I could not make less than a 1600bps
> >symbol rate work when I last was focused on that modem. Later
> >standards and newer versions of '188-110 and DLP's and waveforms that
> >have developed that are implemented in new hardware are much faster
> >and some modems will auto adjust to different PSK carriers and symbol
> >rates I have learned. At present in MARS we have all the speed we
> >need with the 2400bps coded until faster CPU's come along and more
> >consistent external PCSDM's are used by all stations and radios with
> >better frequency accuracy and stability are being used.
> >
> >/s/ Steve, N2CKH/AAR2EY
> >
> >
> >
> >
>
>
>
>Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org
>
>Other areas of interest:
>
>The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
>DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)
>
>
>Yahoo! Groups Links
>
>
>
>




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

RE: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Mark,

I just seen this after sending you a reply...

You go the idea, you actually put it forth simpler than I did as gave 
you too much detail, but yet just touched the tip of it !  I may have 
to save your explanation below for a more simple reply in the future, 
but I can never seem find my own and end up writing anew again.

You can get a real headache reading all those standards and then 
writing C++ code to implement it. There is an FSK modem aspect of 
MIL-STD-188-110 as well but its not implemented in PC-ALE or MARS-ALE.

/s/ Steve, N2CKH

At 03:24 PM 9/1/2006, you wrote:
>After further reading I understand now how it works.  The symbol rate is
>2400 Baud.  The coded (rate 1/2 convolutional ) data rates have differing
>interleaving depths.  75 has the highest interleaving depth, and 2400 has
>the lowest interleaving depth.  4800 is not coded nor interleaved. Olivia
>does something very similar.  It has multiple Baud rates, and interleaving
>depths.  Packet has no convolutional coding, and does not interleave data.
>
>73,
>
>Mark N5RFX




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

RE: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Mark,


The Mil-Std-188-110B serial (single-tone) mode use M-ary Phase-Shift 
Keying (PSK) on a single carrier frequency  (1800hz standard)  as the 
modulation technique for data transmission. The serial binary 
information is converted into a single 8-ary PSK-modulated output 
carrier where the modulation of this output carrier is a constant, 
standard is a 2400 symbols-per-second waveform regardless of the 
actual throughput data rate selected (75-2400bps coded). Many small 
shifts in phase can be created to represent various binary states. 
The addition of amplitude shifts to the phase shift information can 
also be used to increase the amount of information contained during 
any time interval. The data rate is a variable, either user selected 
or adaptive to at which the data is sent. At present we are using up 
a 2400bps coded data rate with an additional Data Link Protocol to 
Federal Standard 1052 (FS-1052). It does not stop at 2400bps though, 
hardware modems just keep doubling it, 4800, 9600, etc., we just have 
not gone there yet, and frankly, due to the Amateur grade radios 
being used and the other system components at this time, 2400bps is 
pretty much it for the average MARS members system, the same would be 
true for Ham radio use, if even legal at present which I believe it 
not the case.

The interleaver is a matrix block type that operates upon input bits 
where the matrix size accommodates block storage of 0.0s, 0.6s, or 
4.8s of receiving bits (depending on whether the zero, short, or long 
interleave
setting is chosen) at all required data rates, MT-63 is similar with 
its Short and Long interleave settings.
With MIL-STD-188-110, to maintain the interleave delay at a constant 
value, the block size is scaled by
bit rate with an interleaver matrix dimension of rows and columns 
allocated for each required bit rate and interleave delay. Any 
unknown data bits are loaded into the interleaver matrix starting at 
column zero where
the first bit is loaded into row 0, the next bit is loaded into row 
9, the third bit is loaded into row 18, and the fourth bit into row 
27. Thus, the row location for the bits increases by 9 modulo 40. 
This process continues until all 40 rows are loaded. The load then 
advances to column 1 and the process is repeated until the matrix 
block is filled. This procedure is followed for both long and short 
interleave settings, all this adds up to the "coded" vs. "uncoded", 
the later being the case at 4800bps.

The above is a simplified explanation, there is much more to it all 
that can be read about in MIL-STD-188-110B, the current standard and 
then the DLP stuff in FED-STD-1052 which has been replaced by STANAG 
5066 DLP that in PC-ALE and MARS-ALE has not yet been coded. Then, 
for the details of the Robust 75bps mode, one needs to read STANAG 4415.

/s/ Steve, N2CKH


At 02:29 PM 9/1/2006, you wrote:

> >The 2400 and 4800 baud is a composite baud rate for the mode/protocol NOT
> >the discrete baud rate of any individual component of the waveform.
>
>
>Can you explain further?  I saw that:
>
>"MIL-STD-188-110A serial tone modem is just that, a single PSK carrier
>frequency that by the standard is locked at 1800hz using a constant 2400bps
>Symbol Rate.
>
>The symbol rate is 2400 Baud, so what makes this perform better than Packet
>at 300 Baud?
>
>73,
>
>Mark N5RFX
>
>
>
>
>
>
>Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org
>
>Other areas of interest:
>
>The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
>DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)
>
>
>Yahoo! Groups Links
>
>
>
>




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

RE: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

e "slow" tones you mention below at 125 baud for an 8FSK
> >signal were available as an ARQ mode, I think that we would have a sea
> >change in sound card modes.
> >
> >Just to clarify, does the 8PSK have each of the 8 running at 125 baud,
> >or is that the total baud speed and the tones are really 15.625 x 8
> >which would give you the 125 baud speed?
> >
> >
> >73,
> >
> >Rick, KV9U
> >
> >
> >
> >
> >Steve Hajducek wrote:
> >
> > >GA Rick, Patrick:
> > >
> > >The stuff from MIL-STD-188-141B that relates the MIL-STD-118-110x
> > >modem and Data Link Protocols (DLP) via other standards (e.g.
> > >FS-1052  DLP, S5066 DLP etc.) is all high speed serial tone and as
> > >specified, not legal under FCC Part 97 at present in the U.S., I do
> > >not know all the rules OCONUS. MIL-STD-188-110x with an added DLP is
> > >quite doable on the PC Sound Device Modem, I have tailored it down to
> > >where it is almost FCC legal, but when trying to go lower than a
> > >1600bps symbol rate to get there it just failed to work, the PSK
> > >carrier at 1200hz was as low as it could go, at that symbol rate and
> > >carrier combination is a 2Khz BW from 200-2200hz but almost twice the
> > >legal symbol rate the last I worked on it. I am hoping FCC rules
> > >changes will allow it in the near future as it works great from a
> > >150-2400bps coded data rate. The 75bps data rate uses a rake
> > >algorithm which is nearly unstoppable but at a full 3Khz BW.
> > >
> > >What Patrick and others could easily code on an FSK PC Sound Device
> > >Modem that would be legal is the optional Data Block Message (DBM)
> > >FEC (BRD) and ARQ protocols from MIL-STD-181-141x which is an 8FSK
> > >125 baud protocol, it and GTOR are kissing cousins as Kantronics
> > >developed GTOR with influence by the standards on which DMB is based.
> > >All of the details are spelled out in the standards for anyone that
> > >wishes to implement the protocol.
> > >
> > >Get a copy of PC-ALE and single channel just establish a link between
> > >you and another station and then fire off a DBM BRD or ARQ message,
> > >there are settings for number of retries and maximum frame size, with
> > >DBM supporting binary data there is also a DBM FTP selection for
> > >sending files. The speed is always fixed at maximum.
> > >
> > >/s/ Steve, N2CKH
> > >
> > >
> > >
> > >At 04:44 PM 8/29/2006, you wrote:
> > >
> > >
> > >>Hello Rick,
> > >>
> > >>
> > >>
> > >>>How difficult would this be to implement the MIL-STD-188-141-B DLP in
> > >>>software such as Patrick's Multipsk Program?
> > >>>
> > >>>
> > >>It depends, in general, on the precision of the specifications. If
> > >>you must reverse-engineers (is it English?) to extract the necessary
> > >>information, it's long. If all is clear, it cannot be very long
> > >>except if there are a lot of possible configurations and/or a
> > >>protocol to manage. However, for instance, I have a lot of other
> > >>subjects, but in the future who knows...
> > >>
> > >>73
> > >>Patrick
> > >>
> > >>
> > >>
> >
> >
> >
> >Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org
> >
> >Other areas of interest:
> >
> >The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
> >DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy 
> discussion)
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
>
>Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org
>
>Other areas of interest:
>
>The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
>DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org
>
>Other areas of interest:
>
>The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
>DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)
>
>
>Yahoo! Groups Links
>
>
>
>




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Dave,

I put in a number of years of DoD IV&V and I agree 100% that Ada was 
a huge benefit over all the languages, many of them unique to a 
particular CPU or embedded platform. I can't begin to tell you how 
many languages that I was forced to use in DoD related projects 
before Ada came along and then we went to best commercial practices. 
I was not knocking the Ada language, just the compilers written in 
support of the language for Windows development when I last used 
them. I was very proud that AMDS was created using Ada in the face of 
the tools we had to use, but I was also very happy to move to C++ for 
the added enhancements from the more optimizing compiler. In Europe 
Ada is much more popular outside Military circles than in the states, 
likely due to Pascal being used to teach programming much more than here.

/s/ Steve, N2CKH

At 01:24 PM 8/31/2006, you wrote:
>C++ was a huge step backward from Ada, IMHO. There'd have been no
>need for Purify if everyone programmed in Ada instead of C and C++.
>How many billions of dollars have been lost just to = vs ==, much
>less to memory leaks.
>
>Pascal was a teaching language never intended for industrial use.
>Both Pascal and Ada are Algol-style languages, which optimize for
>human readability. The developers of C optimized instead for "minimal
>keystrokes during program entry", and C++ inherited this unfortunate
>decision. We type a program once; we read it many times over its life.
>
>But we digress...
>
>73,
>
>   Dave, AA6YQ




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] FS-1052

[Steve Hajducek]

Hi Walt,

PC-ALE and MARS-ALE are long ago there and its operational in the 
MARS program daily in messaging.

Many MARS members with enough CPU/RAM are running MARS-ALE under 
Windows emulation such as WHINE or CrossOver, however my Linux boxes 
are rather old PC's ( 4 Red Hat box's - 2x 6.2 for IRLP nodes, 1x 7.3 
Server, 1x 9.0 workstation)

I have never done any development for Linux, and porting an MS MFC 
C++ app to Linux does not look like fun, at least not yet. I have 
been doing everything in Windows for a long time now as that is where 
the market is at, even when I was directly supporting the U.S. 
Military the move to Windows NT in the circles that I was in was 
heavily under way, then later I did a lot of user support for 
Linux/Sun/HPUX users of the FPGA CAD tools but even there the bulk of 
users aside from Modelsim simulation farms were under Windows 2000 
and XP Pro. The Modelsim simulation farms loved Linux due to the more 
efficient disk I/O file system which was faster than DOS or HPFS and 
meant a faster simulation time on large designs.

/s/ Steve, N2CKH/AAR2EY

At 06:24 PM 8/31/2006, you wrote:
>Steve,
>
>I sure hope you can get a soundcard version of FS-1052 going for 
>data transmission.  I believe that N4HY has also been working in 
>this area.  Then port it to Linux for me.
>
>Walt/K5YFW




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Rick,

ALE itself is 8FSK, 125 baud, all protocols on that modem.

After an ALE link, any protocol, be it an ALE 8FSK or other can be 
utilized via other modems. Built into PC-ALE/MARS-ALE is a 
MIL-STD-188-110 modem, MARS-ALE also actively supports external 
TNC/Modems. PC-ALE passive provides this support as well using any 
third party program.

The MIL-STD-188-110A serial tone modem is just that, a single PSK 
carrier frequency that by the standard is locked at 1800hz using a 
constant 2400bps Symbol Rate. Then coded data rates from 75-2400bps 
and 4800bps un-coded, this is what is supported by PC-ALE. MARS-ALE 
supports 1200hz, 1500hz and 1800hz selections for the PSK carrier and 
a symbol rate as low as 1600bps (the only one that can be used with 
the 1200hz PSK carrier) to achieved lesser IF BW requirements from 
the standard 300-3300hz (3Khz). I could not make less than a 1600bps 
symbol rate work when I last was focused on that modem. Later 
standards and newer versions of '188-110 and DLP's and waveforms that 
have developed that are implemented in new hardware are much faster 
and some modems will auto adjust to different PSK carriers and symbol 
rates I have learned. At present in MARS we have all the speed we 
need with the 2400bps coded until faster CPU's come along and more 
consistent external PCSDM's are used by all stations and radios with 
better frequency accuracy and stability are being used.

/s/ Steve, N2CKH/AAR2EY



At 12:15 AM 8/31/2006, you wrote:
>Steve,
>
>Ideally, it would be something you would want to share as a
>collaborative effort. Without this type of effort on the part of a few
>hams (Patrick being one, along with Dave's DX Lab software), we would
>not have the incredible synergy that these two programs bring to nearly
>any amateur operator.  Right now we just do not have a good solution for
>sound card ARQ. This is not because it technically can not be done, but
>because the hams who have the knowledge to do it just are not interested
>in such a mode or at least it is very low on their priority list. They
>primarily design for keyboard to keyboard modes.
>
>What is the baud rate maximum speed for the MIL-STD-188-141B for a
>single tone? You seem to imply that even slowing it down you still are
>running these tones at 600 baud? I am having great difficulty
>understanding how any tones can be much faster than even 200 baud and
>actually work on HF. I believe that GTOR had the ability to max out at
>300 baud, but it was rare for the software to switch into this speed
>since the ionosphere doesn't really cooperate that much at baud rates
>that high. Which is why 300 baud Packet was such a poor HF mode. It was
>much too fast for the symbol rate and ISI issues made it nearly
>impossible for the receive station to decode the packet correctly.
>
>I am not clear yet as to whether the FCC considers the baud rate of the
>entire combined modulations or the individual baud rate of a given tone.
>Even if only the "slow" tones you mention below at 125 baud for an 8FSK
>signal were available as an ARQ mode, I think that we would have a sea
>change in sound card modes.
>
>Just to clarify, does the 8PSK have each of the 8 running at 125 baud,
>or is that the total baud speed and the tones are really 15.625 x 8
>which would give you the 125 baud speed?
>
>
>73,
>
>Rick, KV9U
>
>
>
>
>Steve Hajducek wrote:
>
> >GA Rick, Patrick:
> >
> >The stuff from MIL-STD-188-141B that relates the MIL-STD-118-110x
> >modem and Data Link Protocols (DLP) via other standards (e.g.
> >FS-1052  DLP, S5066 DLP etc.) is all high speed serial tone and as
> >specified, not legal under FCC Part 97 at present in the U.S., I do
> >not know all the rules OCONUS. MIL-STD-188-110x with an added DLP is
> >quite doable on the PC Sound Device Modem, I have tailored it down to
> >where it is almost FCC legal, but when trying to go lower than a
> >1600bps symbol rate to get there it just failed to work, the PSK
> >carrier at 1200hz was as low as it could go, at that symbol rate and
> >carrier combination is a 2Khz BW from 200-2200hz but almost twice the
> >legal symbol rate the last I worked on it. I am hoping FCC rules
> >changes will allow it in the near future as it works great from a
> >150-2400bps coded data rate. The 75bps data rate uses a rake
> >algorithm which is nearly unstoppable but at a full 3Khz BW.
> >
> >What Patrick and others could easily code on an FSK PC Sound Device
> >Modem that would be legal is the optional Data Block Message (DBM)
> >FEC (BRD) and ARQ protocols from MIL-STD-181-141x which is an 8FSK
> >125 baud protocol, it and GTOR are kissing cousins as Kantronics
> >developed GTOR with inf

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Rick,

At 01:53 PM 8/31/2006, you wrote:
>The PC-ALE program gave my some difficult times at first with crashing.
>I think I figured that out. At this time I don't see to be able to get
>the program to interface with my ICOM 756 Pro 2 rig through the CI-V.

For that model with the current PC-ALE you need to select the GENERIC 
ICOM interface if you have not already done so and provide the needed 
details and you want to select SLIT VFO to bypass the BPF relays 
during Scanning until needed for TX. Many are using the 756PROII with 
the current tool and this approach. CAT PTT is not supported.


>It may be possible for those who wish to install some kind of PTT
>control running under another COM port or virtual COM with USB, but I
>don't plan on using any software that doesn't key the rig via the CI-V
>which has this already built in.

Then you will just have to wait for the next next release of PC-ALE 
then. Most but not all manufacturers now have CAT PTT in all their radios.

However you really can only count on radios using RTS/CTS handshaking 
to always exercise all commands being sent to them, something that 
ICOM does not support, Kenwood always has, Yaesu has only just added 
it to their new FT-2000.

I remember back in the '80's when I first coded for the FT-980, all 
software validation for each command, then Yaesu moved away from 
that, they have been so inconsistent to their approach with radio CAT 
that they any Ten Tec are tied for the worst, although they were on a 
good track at first and so was Ten Tec early on when they were 
emulating and adding to the ICOM CSMA system, Ten Tec via that 
interface offered CAT PTT before ICOM ever did and then they went 
amuck! Kenwood and ICOM have been the most stable and now the 
FTdx9000 and FT-2000 are following Kenwoods command structure for the 
most part. I love the Kenwood built in radio ID approach, in MARS-ALE 
all you need to do is select Kenwood w/o RTS/CTS and baud rate, with 
the radio on at program start it reads that radio ID and knows what 
can be done with the attached radio. The ICOM addressable CSMA 
approach (used by Ten Tec for years as well) has merits too as you 
can control more than one radio (up to 6 actually) the bus and you 
have built in collision support, Watkins-Johnson used (different 
addressable header and other codes) it for years with their receivers 
and then enhanced it beyond being compatible with ICOM and older Ten Tec's.


>What I would like to see is an ARQ sound card mode made available for
>digital use. Practically speaking this means something that drops into
>existing multi-mode sound card programs. Preferably, with the
>unbelievable Multipsk program which has rig control through Dave's DX
>Lab Commander program. There doesn't seem to be any other combination
>like that where two powerful programs become even more powerful through
>the synergy between them. I would like to see other ham developers and
>software experts move in a similar direction to expand the use of new
>modes that really make a difference.

I have too many projects going now to help make you happy on that score Rick.

At some point, now that the power of the CPU and OS has arrived, just 
as I want to get back to my Sight It! tool, I want to get back to my 
CATCC (http://www.n2ckh.com/download.htm) software as well. I lost 
many years of development beginning in May '99 when I suffered an 
accident that kept me from sitting at a computer after learning to 
walk again etc., I did not start software development again until the 
Fall of 2004 on MARS-ALE. When I can focus on the hobby again in a 
big way I likely will, but at present my main focus is on the needs of MARS.

/s/ Steve, N2CKH/AAR2EY

>73,
>
>Rick, KV9U




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Dave,

That aspect of PC-ALE in being updated. For a number of years the 
core users of PC-ALE mostly used a common set of HF SSB transceivers 
that were well to ALE Scanning use where the PA BPF relays were not 
an issue or could be bypassed via command and external PTT was mostly 
used and a few more were added by G4GUO.

Now that ALE is much more popular in the hobby via PC-ALE, everyone 
wants their make/model radio and particular PTT type supported, the 
same was true in the MARS program. Thus the Radio Control Library 
that I wrote for MARS-ALE is being integrated into PC-ALE and the 
next release will provide much more flexibility in this regard.

However only make/model radios that allow for the bypassing (all 
Kenwood's except TS-440, most high end [IC-765, 775, 781] and later 
model [74x, 75x, 7800] ICOMs, Yaesu FT-990 and FT920, Harris RF-350 
family and others) of those BPF relays during RX Scanning should 
really be used unless repair of replacement of those relays and 
perhaps PA is not an issue to the user early than would otherwise be 
the case. Some radios such as the ICOM Marine Grade models are said 
to have BPF relays that hold up very well for many years of constant 
scanning as proven in service, but I have not been able to get any 
info from the manufactures as to the life of the relays used in this 
application, so I am most users prefer radios that this is not an 
issue at all (Ten Ten Argunaut V/TT516, FT-650) or ones that can be 
Bypassed rather than listening to them constantly switch and waiting 
for them to fail.

/s/ Steve, N2CKH

At 10:52 AM 8/31/2006, you wrote:
>I tried PC-ALE as well, but as its documentation says
>
>"Two of the handshaking lines from the P.C are also used to control
>the radio, the RTS line is used to operate the radios PTT and the DTR
>line is used to control muting and unmuting of the radio".
>
>There is evidently no way to use DTR for TX-RX switching, if that's
>how you have things wired, and as Rick pointered out you can't
>specify a CAT command either. Making PC_ALE more flexible in this
>area would be straightforward, and would make it much easier for
>existing soundcard mode users to give it a try.
>
>Also, keep this in mind:
>
>"After changing the serial port it is necessary to restart the
>program  for the new option to take effect. It is also necessary
>whilst doing this to select the correct radio interface from the same
>menu."
>
> 73,
>
> Dave, AA6YQ




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Dave,

Speaking of Ada, I developed the MS-Windows AMDS ( 
https://peoiewswebinfo.monmouth.army.mil/portal_sites/IEWS_Public/rus//AMDS.htm 
) for the I-REMBASS Battlefield Sensor System in Ada for the U.S. 
Army due to requirements (Ada is a very good large embedded systems 
language, it is very much PASCAL like )  to use Ada, but the 
compilers were never great. When I wrote Sight It! LOS ( 
http://www.n2ckh.com/SI/sight_it.htm )  for the hobby based on all I 
had to learn to do AMDS and showed it off to my employer and Army 
bosses, AMDS went from ADA to C++ pretty darn fast, which did not 
bother me at all. Years later when I stated working in the ASIC/FPGA 
world along comes VHDL which is based on Ada, I was glad that those 5 
years up time January 2005 were just spend selling the ModelSim/FPGA 
Advantage and other VHDL CAD tools and not actually doing development 
in VHDL (or Verilog) which are both facing stiff C++ competition these days.

PC-ALE and MARS-ALE are both MS C++/MFC developed tools.

/s/ Steve, N2CKH

At 11:50 AM 8/31/2006, you wrote:
>Re "Dr. Hopper is also know for her work on "Flow-Matic" business
>language, COBOL and Ada.
>
> >>>I met Grace Hopper when we (Rational Software) validated the first
>Ada compiler in the early 80s. She was inspirational...
>
>73,
>
>Dave, AA6YQ




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

RE: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Walt,

I guess you  mean the Frederick 1102 made under license from Harris? 
I have one of those actually. They are strictly to the standard, 
1800hz PSK carrier, 2400bps symbol rate, the needed channel BW is 
300-3300hz (3Khz) at any supported data rate (75-2400bps coded). Its 
that symbol rate, its to high, it exceeds the 300 symbol/sec limit 
per FCC Part 97.

In MARS-ALE I added tailoring to get down to a 1200hz PSK carrier and 
1600bps symbol rate, it works great at 200-2200hz for a 2Khz BW, but 
the symbol rate is still to high.

/s/ Steve, N2CKH

At 02:47 PM 8/30/2006, you wrote:
>Steve,
>
>Why wouldn't the MIL-STD-118-110x (FS-1052) and high speed serial 
>tone modes not be legal under Part 97?
>
>There used to be a bunch of hams on the East Coast who ran the 
>Fredericks(sp) version of the Harris Serial Tone Modem on HF and at 
>least one was an FCC engineer.  One of the groups was even selling 
>the Fredericks modem for under $1000.  They didn't have an special 
>license or permission from the FCC as far as I know.
>
>Walt/K5YFW
>
>
>-Original Message-
>From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, August 29, 2006 4:33 PM
>To: digitalradio@yahoogroups.com
>Subject: Re: [digitalradio] Re: ALE QRM is minimal
>
>
>
>GA Rick, Patrick:
>
>The stuff from MIL-STD-188-141B that relates the MIL-STD-118-110x
>modem and Data Link Protocols (DLP) via other standards (e.g.
>FS-1052  DLP, S5066 DLP etc.) is all high speed serial tone and as
>specified, not legal under FCC Part 97 at present in the U.S., I do
>not know all the rules OCONUS. MIL-STD-188-110x with an added DLP is
>quite doable on the PC Sound Device Modem, I have tailored it down to
>where it is almost FCC legal, but when trying to go lower than a
>1600bps symbol rate to get there it just failed to work, the PSK
>carrier at 1200hz was as low as it could go, at that symbol rate and
>carrier combination is a 2Khz BW from 200-2200hz but almost twice the
>legal symbol rate the last I worked on it. I am hoping FCC rules
>changes will allow it in the near future as it works great from a
>150-2400bps coded data rate. The 75bps data rate uses a rake
>algorithm which is nearly unstoppable but at a full 3Khz BW.
>
>What Patrick and others could easily code on an FSK PC Sound Device
>Modem that would be legal is the optional Data Block Message (DBM)
>FEC (BRD) and ARQ protocols from MIL-STD-181-141x which is an 8FSK
>125 baud protocol, it and GTOR are kissing cousins as Kantronics
>developed GTOR with influence by the standards on which DMB is based.
>All of the details are spelled out in the standards for anyone that
>wishes to implement the protocol.
>
>Get a copy of PC-ALE and single channel just establish a link between
>you and another station and then fire off a DBM BRD or ARQ message,
>there are settings for number of retries and maximum frame size, with
>DBM supporting binary data there is also a DBM FTP selection for
>sending files. The speed is always fixed at maximum.
>
>/s/ Steve, N2CKH
>
>
>
>At 04:44 PM 8/29/2006, you wrote:
> >Hello Rick,
> >
> > >How difficult would this be to implement the MIL-STD-188-141-B DLP in
> > >software such as Patrick's Multipsk Program?
> >It depends, in general, on the precision of the specifications. If
> >you must reverse-engineers (is it English?) to extract the necessary
> >information, it's long. If all is clear, it cannot be very long
> >except if there are a lot of possible configurations and/or a
> >protocol to manage. However, for instance, I have a lot of other
> >subjects, but in the future who knows...
> >
> >73
> >Patrick
> >
> >
> >   - Original Message -
> >   From: KV9U
> >   To: digitalradio@yahoogroups.com
> >   Sent: Tuesday, August 29, 2006 10:06 PM
> >   Subject: Re: [digitalradio] Re: ALE QRM is minimal
> >
> >
> >   OK Steve,
> >
> >   I got the impression that the various modes mentioned below were a part
> >   of STANAG 5066 and did not realize that there is a separate DLP part of
> >   STANAG 5066. The jargon gets to be a bit much, but very common for
> >   military type descriptors.
> >
> >   For some reason, the data transfer part of this has not been really
> >   talked about much and the focus has been more on ALE. I find the ARQ
> >   mode to be the real value in all of this. Assuming it can perform
> >   reasonably well.
> >
> >   Tell us more about the waveform type, number of tones, and how this
> >   works compared to your experiences with the typical sound card modes
> >   that we normally use.
> >
>

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

GA Rick, Patrick:

The stuff from MIL-STD-188-141B that relates the MIL-STD-118-110x 
modem and Data Link Protocols (DLP) via other standards (e.g. 
FS-1052  DLP, S5066 DLP etc.) is all high speed serial tone and as 
specified, not legal under FCC Part 97 at present in the U.S., I do 
not know all the rules OCONUS. MIL-STD-188-110x with an added DLP is 
quite doable on the PC Sound Device Modem, I have tailored it down to 
where it is almost FCC legal, but when trying to go lower than a 
1600bps symbol rate to get there it just failed to work, the PSK 
carrier at 1200hz was as low as it could go, at that symbol rate and 
carrier combination is a 2Khz BW from 200-2200hz but almost twice the 
legal symbol rate the last I worked on it. I am hoping FCC rules 
changes will allow it in the near future as it works great from a 
150-2400bps coded data rate. The 75bps data rate uses a rake 
algorithm which is nearly unstoppable but at a full 3Khz BW.

What Patrick and others could easily code on an FSK PC Sound Device 
Modem that would be legal is the optional Data Block Message (DBM) 
FEC (BRD) and ARQ protocols from MIL-STD-181-141x which is an 8FSK 
125 baud protocol, it and GTOR are kissing cousins as Kantronics 
developed GTOR with influence by the standards on which DMB is based. 
All of the details are spelled out in the standards for anyone that 
wishes to implement the protocol.

Get a copy of PC-ALE and single channel just establish a link between 
you and another station and then fire off a DBM BRD or ARQ message, 
there are settings for number of retries and maximum frame size, with 
DBM supporting binary data there is also a DBM FTP selection for 
sending files. The speed is always fixed at maximum.

/s/ Steve, N2CKH



At 04:44 PM 8/29/2006, you wrote:
>Hello Rick,
>
> >How difficult would this be to implement the MIL-STD-188-141-B DLP in
> >software such as Patrick's Multipsk Program?
>It depends, in general, on the precision of the specifications. If 
>you must reverse-engineers (is it English?) to extract the necessary 
>information, it's long. If all is clear, it cannot be very long 
>except if there are a lot of possible configurations and/or a 
>protocol to manage. However, for instance, I have a lot of other 
>subjects, but in the future who knows...
>
>73
>Patrick
>
>
>   - Original Message -
>   From: KV9U
>   To: digitalradio@yahoogroups.com
>   Sent: Tuesday, August 29, 2006 10:06 PM
>   Subject: Re: [digitalradio] Re: ALE QRM is minimal
>
>
>   OK Steve,
>
>   I got the impression that the various modes mentioned below were a part
>   of STANAG 5066 and did not realize that there is a separate DLP part of
>   STANAG 5066. The jargon gets to be a bit much, but very common for
>   military type descriptors.
>
>   For some reason, the data transfer part of this has not been really
>   talked about much and the focus has been more on ALE. I find the ARQ
>   mode to be the real value in all of this. Assuming it can perform
>   reasonably well.
>
>   Tell us more about the waveform type, number of tones, and how this
>   works compared to your experiences with the typical sound card modes
>   that we normally use.
>
>   Is this going to be available for amateur use eventually?
>
>   How difficult would this be to implement the MIL-STD-188-141-B DLP in
>   software such as Patrick's Multipsk Program?
>
>   73,
>
>   Rick, KV9U
>
>   Steve Hajducek wrote:
>
>   >Hi Rick,
>   >
>   >Just time for a quick comment.
>   >
>   >Don't confuse STANAG 5066 Data Link Protocol (DLP) as covered in
>   >MIL-STD-188-141B which is a Data Link Protocol at the Physical Layer
>   >with STANAG 5066 which is a network protocol at the Link Layer.
>   >Basically and DLP with the need ARQ support and speed can be used at
>   >the Physical Layer. If an MT-63 Adaptive ARQ protocol with a
>   >transport layer and enough speed were to develop it could be used.
>   >
>   >STANAG 5066 DLP (S5066) replaced FED-STD-1052 DLP (FS-1052) going
>   >from MIL-STD-188-141A to MIL-STD-188-141B. Both are DLP's that make
>   >use of the MIL-STD-188-110x modems, both provide and ARQ protocol,
>   >where 5066 DLP is much improved.
>   >
>   >We use FS-1052 daily in MARS, we get full 2400bps throughput on a
>   >good channel with stations that are properly configured. We have not
>   >yet implemented S5066, its on the "To Do" list.
>   >
>   >/s/ Steve, N2CKH/AAR2EY
>   >
>   >At 11:16 AM 8/28/2006, you wrote:
>   >
>   >
>   >>One of the main interests that I have in digital modes is getting a
>   >>message through the most difficult conditions, completely intact as
>   >

Re: [digitalradio] -tor modes and PCs

[Steve Hajducek]

Hi Chris,

Take a look at DBM ARQ in 
http://www.n2ckh.com/MARS_ALE_FORUM/MIL-STD-188-141B.pdf starting on 
page 178, it really lends itself to the PCSDM and its works 
fantastic, I love GTOR, more so than PACTOR I since the day I bought 
my first KAM Plus (I like my KAM XL a bit better though) and DBM ARQ 
( GTOR is a kissing cousin) is every bit as good and in some ways 
better. Here's a comparison of the TOR's and DMB ARQ timing:

ProtocolCycle LengthData Length Ack Length   NOTE: 
All in seconds:

AMTOR   0.450.210.07

PACTOR  1.250.960.12

GTOR2.401.920.16

DBM ARQ variablevariable1.57

If for no other reason, anyone interested in a robust FSK ARQ 
protocol (there DBM BRD which is just FEC that is great as well) 
should give it a try in any version of PC-ALE, no Scanning, no 
Sounding required, just you and a buddy establish a link and then 
send your message with DBM, pretty much like establishing a link with 
GTOR or PACTOR but no constant channel diddling while linked, its so 
much less annoying to others tuning by or having a QSO in the 
distance, the only transmitting is the Linking and then the sending 
of the data and the handshaking and the throughput is just as fast.

As my Mother used to say and was often right, "Try it, you'll like it!"

/s/ Steve, N2CKH

At 07:23 PM 8/28/2006, you wrote:

>The ACK time could be made as long as you like, but the throughput
>would suffer accordingly.
>
>For example, with Pactor I, (according to p. 9-24 of the 2005 ARRL
>Handbook), the sender sends the packet in 0.96 seconds, then
>propagation delays and receipt of the ACK takes 0.29 seconds, for a
>total of 1.25 seconds per packet.  If we increase the ACK delay to be
>the same as the transmit time, the total time per packet would be 1.92
>seconds for the same amount of data as Pactor I sends in 1.25 second,
>and the throughput would be 1.25/1.96 or approximately 0.65 times what
>the present protocol delivers.
>
>Is it doable?  Yes.  Would most hams want it?  I have my doubts.
>
>To get the same throughput with a longer ACK time, you have to make
>the transmit time longer too, so it bears the same relationship to the
>total time as it does now.  That means either a much longer data
>packet, or a pipelined group of packets covered by a single ACK.  The
>longer the packet, the greater chance that a static crash or other
>event will corrupt the packet, so we're back to talking about
>pipelined packets.
>
>--
>73 DE AE6VW Chris JewellGualala CA USA




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] -tor modes and PCs

[Steve Hajducek]

At 11:41 AM 8/28/2006, you wrote:
>I'm willing to believe that the timing tolerances in -tor modes
>are so tight that ordinary PC operating systems cannot cope with
>them the way a dedicated processor can.  What I don't understand
>is why the tolerances need to be so tight.  The transmitter sends
>a packet and then listens for an ACK or NAK.  Why can't it wait
>arbitrarily long?
>
>There are protocols for wire transmission e.g. IBMs Bi-Sync
>which worked in the days of modems that could only transmit in
>one direction at a time.  These used old slow computers to
>run the protocol.

That is pretty much the way it is with the ALE DTM ARQ, DBM ARQ 
protocols and most of the ARQ protocols on the high speed 
MIL-STD-188-110x PSK serial tone modem.

The FSK one's will run on just about any CPU and PC Sound Device when 
an 8Khz sample clock is used.

The '188-110 modem is a CPU/Memory hog and requires a 9.6Khz sample 
clock, to have both the FSK/PSK modems active at the same time on the 
same PC Sound Device you need a common ground so 48Khz is used as its 
dividable by both 8k and 9.6k. We have a version of MARS-ALE called 
"Legacy Edition" that only has the FSK modem at 8Khz and then both 
modem at 48Khz, thus the MARS-ALE LE version runs on a 386 and 
Windows 98SE and that DBM ARQ is a real performer at a raw 125 baud 
and deep interleaving.

/s/ Steve, N2CKH




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Rick,

Just time for a quick comment.

Don't confuse STANAG 5066 Data Link Protocol (DLP) as covered in 
MIL-STD-188-141B which is a Data Link Protocol at the Physical Layer 
with STANAG 5066 which is a network protocol at the Link Layer. 
Basically and DLP with the need ARQ support and speed can be used at 
the Physical Layer. If an MT-63 Adaptive ARQ protocol with a 
transport layer and enough speed were to develop it could be used.

STANAG 5066 DLP (S5066) replaced FED-STD-1052 DLP (FS-1052) going 
from MIL-STD-188-141A to MIL-STD-188-141B. Both are DLP's that make 
use of the MIL-STD-188-110x modems, both provide and ARQ protocol, 
where 5066 DLP is much improved.

We use FS-1052 daily in MARS, we get full 2400bps throughput on a 
good channel with stations that are properly configured. We have not 
yet implemented S5066, its on the "To Do" list.

/s/ Steve, N2CKH/AAR2EY

At 11:16 AM 8/28/2006, you wrote:
>One of the main interests that I have in digital modes is getting a
>message through the most difficult conditions, completely intact as
>sent, and as fast as possible. I was looking at the STANAG 5066
>specifications and test results, (Steve has some below), and quite
>frankly I am concerned that this standard has what I would normally
>consider to be unacceptable performance (non performance) with weak
>signals.
>
>I am not sure what kind of cps or wpm throughput the bit rates mean but
>it I wonder how it compares to SCAMP running at 10 db S/N?  Because
>SCAMP only operated down to about +10 db S/N (maybe slightly better), it
>was rejected as unacceptable for practical messaging.
>
>  From the info on Steve's site:
>
>http://www.n2ckh.com/MARS_ALE_FORUM/MIL-STD-188-110B.pdf
>
>Here are some claimed performance levels:
>
>Bit rate  Multipath  SNR  BER
>
>4800 2 ms 27 db 1 x e-3 with .5 Hz
>fading BW
>2400 2 ms 30 db 1 x e-3 with  5 Hz
>fading BW
>1200 2 ms 11 db 1 x e-5 with  1 Hz
>fading BW
>300   5 ms   7 db 1 x e-5 with  5 Hz
>fading BW
>75 5 ms   2 db 1 x e-5 with  5
>Hz fading BW
>
>Even with the slowest 75 bps, and a multipath of 5 ms, it can only work
>down to 2 db ABOVE the noise! This is not good. From personal
>experience, it is not easy to get even 10 db S/N signals with typical
>amateur signals with modest antennas on the lower bands.
>
>They even show some constellations at 64 QAM. From what the SSTV folks
>have said, 64 QAM is not really a useful mode on HF. Perhaps that is
>because they are not using ARQ?
>
>Note also that the multipaths are moderate to low compared to worst case
>HF propagation. I question whether this stuff can work under many
>conditions we routinely operate with sound card modes (but are not 100%
>copy without ARQ).
>
>The BER that this system can handle seems to indicate that the channel
>has to be rather good.  These BER's seem to be more appropriate for what
>we would expect on equipment designed for VHF and up ...  aren't they?
>
>For those of you who have used STANAG 5066 waveforms, what kind of
>throughput have you experienced with real world connections?
>
>The deeper I examine this NATO standardized agreeement, the more it is
>beginning to look like another one of those "the emperor has no clothes"
>findings.
>
>Thanks and 73,
>
>Rick, KV9U
>
>
>
>Steve Hajducek wrote:
>
> >I recommend that to answer all of your technical questions on subject
> >ALE that you refer the actual Federal, Military and STANAG Standards
> >which you can find on the Internet quite easily. You can start with a
> >number of them at the following URL:
> >http://www.n2ckh.com/MARS_ALE_FORUM/tecref.html
> >
> >Listed below are the "ALE Operational Rules" taken directly from
> >"MIL-STD-188-141B APPENDIX A", take the time to read this and do
> >additional research WRT the details of the referenced items herein
> >and you should be satisfied that ALE is the most courteous digital
> >mode with automatic operation you could ever want to see, compared to
> >any other system that has ever been used on the Amateur Radio bands.
> >
> >/s/ Steve, N2CKH/AAR2EY
> >
> >A.4.4 ALE operational rules.
> >The ALE system shall incorporate the basic operational rules listed
> >in table A-V. Some of these
> >rules may not be applicable in certain applications. For example,
> >"always listening" is not
> >possible while transmitting with a transceiver or when using a common
> >antenna with a separat

Re: [digitalradio] Re: New to Digital HF -- PACTOR setup and hardware maybe needed???

[Steve Hajducek]

Hi Dave,

I mentioned AMTOR as its timing is more robust that PACTOR I.

As I have stated to the MARS-ALE users, the future version of that 
tool when PACTOR I support is added ont he PCSDM will pretty much own 
the OS, not a problem for our purposes as that one program running is 
our only focus. GTOR is less demanding, but may be require the same 
approach as PACTOR I. This is not required of DBM ARQ which is much 
less demanding that GTOR.

/s/ Steve, N2CKH

At 06:43 AM 8/28/2006, you wrote:
>Precise timing isn't the issue, Steve. WinWarbler originally used
>GetTickCount() and QueryPerformanceCounter() in its CW generation
>code, but a high-resolution timer using the multimedia library is
>sufficiently accurate and more convenient. The problem is thread
>scheduling. WinWarbler uses SetPriorityClass to establish
>REALTIME_PRIORITY_CLASS and SetThreadPriority to establish
>THREAD_PRIORITY_TIME_CRITICAL . Nonetheless, there are many CPU-
>consumptive events that Windows insists on handling at higher
>priority -- such as displaying and moving the Task Manager window.
>Spin locks are not an acceptable solution IMHO; the user would find
>it disconcerting if the mouse pointer stopped following mouse
>movements during CW generation or Pactor-3 operation, for example.
>Yes, one could dedicate a headless Windows PC to executing one
>application like Pactor-3, but what would be the point? Even the most
>expensive Pactor-3 TNC would be cheaper and more compact to boot.
>
>I didn't comment on the feasibility of implementing AMTOR on Windows;
>Pactor-2 and Pactor-3 were the protocols I mentioned.
>
> From my days as a CPU architect and designer, I have lots of
>experience with real-time operating systems and applications -- but
>WinWarbler was my first encounter with extracting real-time
>performance from Windows. Any suggestions or pointers you have in
>this area would be appreciated.
>
> 73,
>
>  Dvae, AA6YQ




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Dave,

At 10:46 AM 8/28/2006, you wrote:


>I have reviewed enough of the military documentation to understand
>that they employ dedicated ALE transceivers capable of much faster
>scanning rates.

Really?  Please enlighten me, I was under the impression that the ALE 
scan rates of 1, 2 and 5 ch/sec was it at present and that the future 
goal as stated in MIL-STD-188-141B was 10 ch/sec. The PC-ALE software 
supports 1, 2 and 5 ch/sec with an HF transceiver that is cable of 
all selections.


>  As a result, sounding duration is signficantly
>reduced,

Sorry, but you will have to explain to me how Sounding duration 
decreases with an increase in the Scan Rate.

>  and channel capacity increases in proportion.

Well not exactly. A 2 ch/sec scan rate allows you to cover the same 
number of channels faster than a 1 ch/sec scan rate and thus increase 
the odds of hearing a Sounding or a Linking call sooner.

Running 2 or 5 ch/sec will also permit the station to be part of more 
than one ALE network at the same time, not an issue per see with 
Amateur Radio, but if two networks had scan groups of 10 channels 
each, you could scan both with excellent results.

The number of channels you scan does have an effect on your 
Soundings, you sound longer when you have more channels in the mix. 
There are variable here as we are now at a stage were you have 3 
generations of ALE. The latest ALE technology supports GPS time 
synchronization of the Scanning/Sounding which in the future will 
radically reduce BER/SNR data transfer for LQA ranking when all 
user's can support it.


>  But one ham
>with an amateur transceiver limited to a 2 channel-per-second scan
>rate would force all ALE participants to sound for 20 seconds, even
>if their equipment could scan more rapidly. Do I have this right?

The details are to be found in MIL-STD-188-141B Appendix A. 
Regardless of the scan rate, if the controller Sounds based on number 
of channels in the scan group its less than 1 second per channel. The 
minimum redundant sound length (Trs) is equal to the standard 
one-word address leading call; that is, Trs = Tlc min = 2 Ta min = 2 
Trw = 784 ms. Thus for 12 channels it would be about 9.4 seconds 
depending on your address length being sent. The address length is 
based on an ALE Word which is 3 ASCII characters, for Amateur Radio 
applications we would being using 2 ALE Words as there are no 3 
character callsigns, whereas in the Military and Government world 
there are 3 character ALE Self Addresses being used. So W1AW, N2CKH 
and WB2XYZ are all 2 ALE Words were automatic padding is used to fill 
the second word. The least number of ALE Words the more efficient and 
reliable is the system. One would now want to use WB2XYZ/W6 to 
indicate they are in California. For AQC-ALE where many things were 
changed to make things even more efficient, a 2 ALE Word is the 
maximum allowed, whereas the original ALE allowed a 5 ALE Word (15 
character) Address to support the Military Automatic Digital Network 
(AUTODIN) system to directly link a Phone Patch call. Feel free to 
double check me with the standards, I am no expert on all this stuff 
and I am not perfect either, I make calculation errors often.

/s/ Steve, N2CKH




Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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

Re: [digitalradio] Re: ALE QRM is minimal

[Steve Hajducek]

Hi Dave,

 >At 10:53 PM 8/27/2006, you wrote:
 >Does ALE provide some means of reducing contention?

I recommend that to answer all of your technical questions on subject 
ALE that you refer the actual Federal, Military and STANAG Standards 
which you can find on the Internet quite easily. You can start with a 
number of them at the following URL: 
http://www.n2ckh.com/MARS_ALE_FORUM/tecref.html

Listed below are the "ALE Operational Rules" taken directly from 
"MIL-STD-188-141B APPENDIX A", take the time to read this and do 
additional research WRT the details of the referenced items herein 
and you should be satisfied that ALE is the most courteous digital 
mode with automatic operation you could ever want to see, compared to 
any other system that has ever been used on the Amateur Radio bands.

/s/ Steve, N2CKH/AAR2EY

A.4.4 ALE operational rules.
The ALE system shall incorporate the basic operational rules listed 
in table A-V. Some of these
rules may not be applicable in certain applications. For example, 
"always listening" is not
possible while transmitting with a transceiver or when using a common 
antenna with a separate
transmitter and receiver.

TABLE A-V. ALE operational rules.
1) Independent ALE receive capability (in parallel with other modems 
and simular audio receivers) (critical).
2) Always listening (for ALE signals) (critical).
3) Always will respond (unless deliberately inhibited).
4) Always scanning (if not otherwise in use).
5) Will not interfere with active channel carrying detectable traffic 
in accordance with table A-I (unless this
listen call function is overriden by the operator or other controller).
6) Always will exchange LQA with other stations when requested 
(unless inhibited), and always measures the
signal quality of others.
7) Will respond in the appropriate time slot to calls requiring 
slotted responses.
8) Always seek (unless inhibited) and maintain track of their 
connectivities with others.
9) Linking ALE stations employ highest mutual level of capability.
10) Minimize transmit and receive time on channel.
11) Automatically minimize power used (if capable).
NOTE : Listed in order of precedence.

TABLE A-I. Occupancy detection probability (2G and 3G).

WaveformSNR (dB in 3 kHz) Dwell Time (s) Detection Prob

ALE 0   2.0 0.80
 6   2.0 0.99

SSB Voice   6   2.0 0.80
 9   2.0 0.99

MIL-STD-188-110 0   2.0 0.80
(Serial Tone PSK)   6   2.0 0.99

STANAG  45290   2.0 0.80
 6   2.0 0.99

STANAG 4285 0   2.0 0.80
 6   2.0 0.99





Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

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