[digitalradio] JT65A..first contact

2007-09-30 Thread David Munn
Hi Allread Andy's very good Bozo Guide to HF JT65 and followed his
instructionswas on 14076 and saw a JT65A signal (using
Fldigi)...loaded up WSJT and proceeded to Monitor...saw JA2BGH calling
CQ so decided to take the plunge and replymade it first
shot..surprise...good contact both waysnow im bitten with the
JT65A bug.
Have been on digital modes for about 6 years using PSK31 RTTY
etcO/S is Kubuntu Linux on a AMD K8 machine with 512 ram...1.8ghz
speed
for clock accuracy im using the ntp server of au.pool.ntp.org as
Dimension4 is only for Windows..clock seems to be accurate
Rig is a TS-140S to a 2-30mhz Inverted V at 10m

Tnx Andy K3UK for a very good jobneed to add some comments for
Linux users

Hope to see some of you on JT65A

David VK4BDJ



Re: [digitalradio] JT65A..first contact

2007-09-30 Thread Andrew O'Brien
Thanks for the kind words David, glad you made your first JT65A
contact from Townsville (dangerously close, in my opinion , to Port
Douglas.  Home of the best meat pies, Mocka Pies !) .

 I will add a few Linux items to the next revision, especially the
options for clock accuracy.

Andy.


On 9/30/07, David Munn [EMAIL PROTECTED] wrote:


 Hi AllI read Andy's very good Bozo Guide to HF JT65 and followed his
  instructionswas on 14076 and saw a JT65A signal (using
  Fldigi)...loaded up WSJT and proceeded to Monitor...saw JA2BGH calling
  CQ so decided to take the plunge and replymade it first
  shot..surprise...good contact both waysnow im bitten with the
  JT65A bug.
  Have been on digital modes for about 6 years using PSK31 RTTY
  etcO/S is Kubuntu Linux on a AMD K8 machine with 512 ram...1.8ghz
  speed
  for clock accuracy im using the ntp server of au.pool.ntp.org as
  Dimension4 is only for Windows..clock seems to be accurate
  Rig is a TS-140S to a 2-30mhz Inverted V at 10m

  Tnx Andy K3UK for a very good jobneed to add some comments for
  Linux users

  Hope to see some of you on JT65A

  David VK4BDJ




[digitalradio] The Signal From Hell

2007-09-30 Thread Mark Thompson
The Signal From Hell
Hank Greeb, N8XX
[EMAIL PROTECTED]
September 28, 2007 



A FYBO QRP contest way up north? Not ’til Hell freezes over! (PS: It did.)



 
This is an outbuilding typically used as a woodshed, but we found it open and 
used it as the 40 meter operating shack. We had to close a wide gap that was 
used as a window so that wind wouldn’t blow snow in and goof up the 
electronics. [Hank Greeb, N8XX, Photo] 
 
Ed Kwik, AB8DF, and I warm up over at the 40 meter operating shack. [Cortland 
Richmond, KA5S, Photo] 
 
Cortland, KA5S, works 15 meter CW in a building normally used as a wedding 
chapel. Actually, he found his rig wasn’t transmitting enough to make a 
contact, but he tried. [Hank Greeb, N8XX, Photo] 
Have you been so perturbed at your buddy that you wanted to tell him or her to 
“go to you know where”? Well, there’s a place in Michigan where that’s very 
common -- a “wide spot in the road” with the name of Hell, Michigan, about 20 
miles from Ann Arbor. When the Arizona ScQRPions QRP Club announced the 2007 
“Freeze Your Buns Off” contest for February 3, the logical place to do that 
seemed to be where “Hell was frozen over.”
The object of this contest is to take your QRP rig out into the field and make 
as many contacts as possible before you either give up or freeze a certain part 
of your anatomy. The scoring gives a multiplier of 1 if the operating 
temperature is greater than 65 degrees, 2 if you’re operating between 55 and 
64, down to a multiplier of 6 if the temperature is less than 20. Another 
multiplier of 4 is if you’re operating outside, a multiplier of 2 if you’re 
operating independent of ac mains power. It’s relatively easy to get an overall 
multiplier of 48. Plus, a multiplier is given for each state, province or 
country you work. Wow!
It Froze! 
So, the idea of a “Hellxpedition” was born. With Hell freezing over at that 
time of year, we figured the temperature multiplier of 6 was a snap! The next 
step was to figure out a logical call that might attract a few more contacts. 
Why not N8H -- so we applied for it and received it!
As someone said, “All the rest is history.” I advertised this idea on several 
reflectors, and very soon Ed, AB8DF, from Waterford (near Detroit), and 
Cortland, KA5S, from Ada (near Grand Rapids) volunteered to join the effort. We 
decided that we’d each bring a rig and determine choice of bands by lottery.
As predicted, Hell was really frozen. When I arrived on Friday, the 2nd, the 
temperature was in the low teens, and the wind was brisk. After a few tries two 
halyards were strung over two trees, at about 50 feet, and the third point for 
ends of two antennae were chosen, but, because of the wind, I figured the 
antenna might blow down overnight. WRONG IDEA. 
Murphy Visits
The next morning, the temperature was 2 degrees, and wind blew one of the 
halyards into the tree, where it was hopelessly tangled on a branch about 30 
feet high. After just a little bit of thought, it was determined that 30 feet 
would have to do, because the wind and snow was just too much to attempt a 
launch of another halyard. Then the 40 meter rig wouldn't put power to the 
tuner -- it turned out to be broken coax, which was found and fixed. Also, 
alternate power from a generator wouldn't start at such a cold temperature, so 
we gave up and plugged into the ac mains, losing an “independence of ac mains 
multiplier. Overall, we didn't start operations until after 1700Z. Signals on 
40 were okay, but 20 was weak until 1900Z. Fifteen was non-existent -- or the 
rig was having problems.
We commandeered two unheated outbuildings for two of the three stations, and Ed 
operated from his van. The 40 meter station was in a woodshed with an open 
window -- so we scrounged around and found a garbage bag from which we made a 
“temporary window.” This kept out most of the wind and snow, until the wedges 
holding it gave way and the entire frame landed on top of the operating table 
and toppled a propane lantern which was being used for light and a bit of heat. 
Fortunately the only damage was a couple broken mantles to the lantern, and a 
broken cable between the computer and the rig.
We tried Feld-Hell on 40 meters at 1900Z and 2100Z with no takers. (We had 
advertised the mode, since this seemed very appropriate for the venue!)
Dancing with the Devil
The temperature never got above 13 degrees during the operation. You might say 
it was a cold day in Hell. The weather was getting blustery and snowy around 
2100Z, so we decided to close up at 2200Z while it was still light. We made 45 
contacts in 28 different states and provinces, so you might say we had a 
“helluva good time” in Hell.
Thanks to the Arizona ScQRPions for running a great contest. Folks who worked 
us were delighted to work the “Devil” -- a nom de plume used by the 40 meter 
op, and seemed to appreciate the contact with the special event call N8H. We 
hope to see everyone again during FYBO 2008. Unless 

[digitalradio] Re: The Signal From Hell

2007-09-30 Thread expeditionradio
Good to see that Cortland KA5S is active in Hell.

Bonnie KQ6XA

--- In digitalradio@yahoogroups.com, Mark Thompson [EMAIL PROTECTED] wrote:

 The Signal From Hell 
 Cortland, KA5S, works 15 meter CW in a building normally used 
 as a wedding chapel.  



[digitalradio] Re: Tests in ARQ FAE

2007-09-30 Thread Demetre SV1UY
--- In digitalradio@yahoogroups.com, Brian A [EMAIL PROTECTED] wrote:

 Just for curiosity.  I wonder if the digital experts out there would
 care to speculate how all these new wonder modes would perform in
 the din of this contest?  Would ALE work at all?  Would these modes be
 able to exchange the contents of 2000 contacts as the bigger RTTY
 stations do in a weekend in the din?  Even with a 300HZ filter, RTTY
 stations are wall to wall 14065-14125 with almost complete overlap.
 
 Correct me if I'm wrong.  However, reading all these posts suggests
 that what these wonder modes want and or need is channelized, clear
 channel frequencies, with no human factor strengths added.  Is that
 realistic to expect on the ham bands?  
 
 73 de Brian/K3KO

I'm afraid that only PACTOR 2 or 3 has any chance of making it through 
these conditions OM. Everything else fails.

73 de Demetre SV1UY



[digitalradio] Re: 30 Meter PropNet Weekend October 6/7

2007-09-30 Thread Don
Hi Rick KV9U,

You bring up a good point actually and don't blame you for asking the 
question.  First I must say my choice of words might be misleading as 
I see it because I used `beacon' you might have reference to part 97 
section 203 on beacons:

http://www.arrl.org/FandES/field/regulations/news/part97/
http://a257.g.akamaitech.net/7/257/2422/13nov20061500/edocket.access.g
po.gov/cfr_2006/octqtr/47cfr97.203.htm

A beacon may be automatically controlled while it is transmitting on 
the 28.20-28.30 MHz, 50.06-50.08 MHz, 144.275-144.300 MHz, 222.05-
222.06 MHz, or 432.300-432.400 MHz segments, or on the 33 cm and 
shorter wavelength bands

Again my choice of words 'beacon' is incorrect because actually a 
PropNet PSK Station is using PSK31 within the allocated digital PSK31 
portion of the band and not only transmits but receives other PropNet 
stations so it is not really a beacon since a beacon as described in 
part 97 section 203 is described as one way communications.  I think 
the creator and owner of PropNet Ev W2EV had stated before on the 
question you ask saying:
Sure! We operate under the same provision that APRS does in the USA: 
FCC Part
97.221. Obviously, this applies only to USA stations.
http://a257.g.akamaitech.net/7/257/2422/13nov20061500/edocket.access.g
po.gov/cfr_2006/octqtr/47cfr97.221.htm

You might email Ev W2EV  (email  [EMAIL PROTECTED]  or ask  
http://groups.yahoo.com/group/PropNET-Online/ ) to ask him for the 
legal run down on this but to my knowledge it is a legal activity 
using a legal digital mode or I would not be participating or 
promoting illegal operation (I think PropNet has been covered by most 
all major Ham Radio Mags including the ARRL/QST, CQ, etc and Ev 
involved with the FCC over this subject matter and to date no 
issues).   

Again I would not operate or promote this if I thought it to be 
illegal.  I actually have operated PropNet like any other digital 
mode of communication where as I'm sending out my call and 
information and receiving others.  The neat thing about this is that 
it's all logged in a database for propagation study and also is set 
to a map for real time propagation mapping so everyone can see in 
real time the band activity.

I don't know if my response helps but its my honest understanding and 
thought your question needed a response.  We are trying to promote 
more 30m digital activity and if you can prove otherwise about 
PropNet then I surely would not promote it.  We always have our 
regular Thursday and Sunday night 30m PSK nights and that has 
promoted more activity on 30m also (of course other modes other than 
bpsk31 are being use too).  If you have time please give PropNet a 
look over and you can always use just the `lurker' mode for receive 
only and still participate by reporting what stations/areas you are 
receiving.  The information will be sent automatically via the 
Internet to the PropNet map where your location and received stations 
will be listed.  I can't participate the whole weekend and don't 
expect anyone to 24 x 7 (although in 'lurker mode' you really can 
participate 24 x 7)but when in the shack I will be sending out my 
call and participating the most I can.  Thanks again for the reply.

De kb9umt Don
http://groups.yahoo.com/group/30meterPSKGroup/
http://www.30meterdigital.com



--- In digitalradio@yahoogroups.com, Rick [EMAIL PROTECTED] wrote:

 Is this 30 meter beacon activity legal?
 
 Can you reference where Part 97 permits this here in the U.S. below 
28.0 
 MHz?
 
 Appreciate your help in understanding this.
 
 73,
 
 Rick, KV9U
 
 
 Don wrote:
  Please join us to promote 30m PSK and Propagation Study on 30 
meters 
  (PropNet anchor freq= 10.1395 USB PSK +1500 and 30m PSK call 
  freq=10.140 USB).  This event will be the weekend of October 6th 
 7th 
  (z 10/6/07 -Sat until 2359z 10/7/07 -Sun).  Any station 
welcome to 
  participate be it a PropNet PSK Beacon (tx  rx) or a PropNet 
`lurker 
  mode' (rx only).  SWL stations or others not wanting to be a 
beacon (tx 
   rx)  please note PropNet has `lurker mode' (rx only) function 
so 
  anyone can participate.  Please go here and download and try 
PropNet 
  and get on 30 meters October 6th  7th:
 
  http://www.propnet.org/
  http://www.n7yg.net/propnetpsk/main.html
  http://www.n7yg.net/propnetpsk/download.html
  http://www.n7yg.net/propnetpsk/faq.html
 
  de kb9umt Don – promoting 30 meter digital activity (30m our only 
low 
  power digital band)
  http://www.projectsandparts.com/30m/
  http://groups.yahoo.com/group/30meterPSKGroup/
  http://www.30meterdigital.com
 
 





Re: [digitalradio] Absolute best case transfer - NON STANDARD MODE - Bandwidth .3 to 2.7 khz

2007-09-30 Thread Robert Thompson
Can you repeat the test with the same setup and S/N of, say,  -5, 0,
+10 dB? It would be interesting to know how the mode degrades.


On 9/29/07, Les Keppie [EMAIL PROTECTED] wrote:
 Hi All
 Here are the figures for a file transfer done
 from  TEST1 to VK2DSG  on the same computer and
 using the same radio so we have absolute max S/N ratioup to 31 db

 Regards
 Les VK2DSG


-- 

Regards, Robert Thompson


Re: [digitalradio] useless qrm

2007-09-30 Thread Robert Thompson
A general-purpose clarification:

Useless QRM -- Anything someone else sends that I don't want to listen to.
Useful communication -- Anything I send that someone else doesn't
want to listen to.

(Tongue Firmly in Cheek here =)


On 9/28/07, David Michael Gaytko // WD4KPD [EMAIL PROTECTED] wrote:
 It sounds like a ghastly prescription for useless QRM.
 
  you mean like in contest 

 david/wd4kpd




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

 Yahoo! Groups Links






-- 

Regards, Robert Thompson


~   Concise, Complete, Correct: Pick Two
~   Faster, Cheaper, Better: Pick Two
~   Pervasive, Powerful, Trustworthy: Pick One
~Whom the computers would destroy, they first drive mad.
~-- Anonymous



Re: [digitalradio] Re: 30 Meter PropNet Weekend October 6/7

2007-09-30 Thread Rick
Don,

I have looked at the PropNet software and what it seems to be doing is 
acting as an unattended beacon. Also, I am not familiar with any 
allocated digital PSK31 portion of the band. Are you referring to the 
the automatic subbands?

 From Part 97:

/(9) Beacon/. An amateur station transmitting communications for the 
purposes of observation of propagation and reception or other related 
experimental activities.


Isn't this exactly what you PropNet is doing?

It does not seem that the receiving stations are connecting with the 
transmitting station but are reporting their reception through the internet.

Both APRS and PropNet appear to operate as beacons if they are 
unconnected. This is legal on part of 10 meters and other higher bands 
but not on HF. They don't seem to be operating as automatic stations 
where they are responding to interrogation by another station. They are 
just sending out unconnected packets or data which would seem to be a 
beacon.

Does anyone have insight into this and how the rules cover these modes?

73,

Rick, KV9U








Don wrote:
 Hi Rick KV9U,

 You bring up a good point actually and don't blame you for asking the 
 question.  First I must say my choice of words might be misleading as 
 I see it because I used `beacon' you might have reference to part 97 
 section 203 on beacons:

 http://www.arrl.org/FandES/field/regulations/news/part97/
 http://a257.g.akamaitech.net/7/257/2422/13nov20061500/edocket.access.g
 po.gov/cfr_2006/octqtr/47cfr97.203.htm

 A beacon may be automatically controlled while it is transmitting on 
 the 28.20-28.30 MHz, 50.06-50.08 MHz, 144.275-144.300 MHz, 222.05-
 222.06 MHz, or 432.300-432.400 MHz segments, or on the 33 cm and 
 shorter wavelength bands

 Again my choice of words 'beacon' is incorrect because actually a 
 PropNet PSK Station is using PSK31 within the allocated digital PSK31 
 portion of the band and not only transmits but receives other PropNet 
 stations so it is not really a beacon since a beacon as described in 
 part 97 section 203 is described as one way communications.  I think 
 the creator and owner of PropNet Ev W2EV had stated before on the 
 question you ask saying:
 Sure! We operate under the same provision that APRS does in the USA: 
 FCC Part
 97.221. Obviously, this applies only to USA stations.
 http://a257.g.akamaitech.net/7/257/2422/13nov20061500/edocket.access.g
 po.gov/cfr_2006/octqtr/47cfr97.221.htm

 You might email Ev W2EV  (email  [EMAIL PROTECTED]  or ask  
 http://groups.yahoo.com/group/PropNET-Online/ ) to ask him for the 
 legal run down on this but to my knowledge it is a legal activity 
 using a legal digital mode or I would not be participating or 
 promoting illegal operation (I think PropNet has been covered by most 
 all major Ham Radio Mags including the ARRL/QST, CQ, etc and Ev 
 involved with the FCC over this subject matter and to date no 
 issues).   

 Again I would not operate or promote this if I thought it to be 
 illegal.  I actually have operated PropNet like any other digital 
 mode of communication where as I'm sending out my call and 
 information and receiving others.  The neat thing about this is that 
 it's all logged in a database for propagation study and also is set 
 to a map for real time propagation mapping so everyone can see in 
 real time the band activity.

 I don't know if my response helps but its my honest understanding and 
 thought your question needed a response.  We are trying to promote 
 more 30m digital activity and if you can prove otherwise about 
 PropNet then I surely would not promote it.  We always have our 
 regular Thursday and Sunday night 30m PSK nights and that has 
 promoted more activity on 30m also (of course other modes other than 
 bpsk31 are being use too).  If you have time please give PropNet a 
 look over and you can always use just the `lurker' mode for receive 
 only and still participate by reporting what stations/areas you are 
 receiving.  The information will be sent automatically via the 
 Internet to the PropNet map where your location and received stations 
 will be listed.  I can't participate the whole weekend and don't 
 expect anyone to 24 x 7 (although in 'lurker mode' you really can 
 participate 24 x 7)but when in the shack I will be sending out my 
 call and participating the most I can.  Thanks again for the reply.

 De kb9umt Don
 http://groups.yahoo.com/group/30meterPSKGroup/
 http://www.30meterdigital.com

   


Re: [digitalradio] JT65A..first contact

2007-09-30 Thread Jose A. Amador

I guess you are using ntp via modem.

I am interested in finding a way to sync Linux to CHU, WWV or WWVB using
a soundcard and the radio time codes.

Does anyone on the list has already done that? How?

73,

Jose, CO2JA

---

David Munn wrote:

 for clock accuracy im using the ntp server of au.pool.ntp.org as
 Dimension4 is only for Windows..clock seems to be accurate
 
 Tnx Andy K3UK for a very good jobneed to add some comments for
 Linux users
 
 Hope to see some of you on JT65A
 
 David VK4BDJ


__

Participe en Universidad 2008.
11 al 15 de febrero del 2008.
Palacio de las Convenciones, Ciudad de la Habana, Cuba
http://www.universidad2008.cu


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

2007-09-30 Thread Robert Thompson
On 9/27/07, Jose A. Amador [EMAIL PROTECTED] wrote:
 In my personal experience, JNOS first, and Linux in second place, have

You probably mean Linux kernel-mode AX.25, since JNOS runs fine on Linux =)

 been a fairly good match to the radio channel characteristics for e-mail
 and web browsing over AX.25 packet radio.

(snip)

 But something is clear to me: it is IMPOSSIBLE to pass TCP traffic
 coming from a LAN, keeping LAN access parameters, timers, segment and
 window sizes without grinding the radio link to HALT with endless
 retries and repeats. TCP windows sizes up to 32767 may be acceptable on
 a LAN, but not on a 2 meters voice radio or a 3 kHZ HF radio.

Absolutely true! Two or three possibilities: Do what is sometimes done
for internet satellite terminals and spoof the TCP state machine
by locally generating ACKs, etc then committing to transfer the frames
yourself however you see fit. This works fine for some things,
terribly for other things. This is great for conditions where the TCP
client and server will break if their assumptions are tested
(Remember, 99.5% of modern internet apps *assume* ubiquitous high
bandwidth, low delay, low loss connectivity, and the timings that go
with it)

Alternatively, you can create protocol gateways that do non-TCP over
the air, with the other end acting like a remote-controlled TCP
client. The HMTP smtp-variant can be thought of as one take on this,
and it's not too hard to implement a similar thing for straight POP or
HTTP. The result will work better (since neither the local-to
radiobridge TCP connection nor the remote-radiobridge-to-internet TCP
connection needs to have its timing fiddled with), but there are a LOT
of non-trivial edge conditions to deal with if you want the thing to
work with the internet in the wild. Sadly, not reads internet RFCs
every night before bed... =)

(snip)
 packet sizes. Even on 2 meters 1200 baud links, it creates havoc.

Heh, you want a feel for exactly how bad the problem is? Try using a
GSM/GPRS (others might do this too, but GSM/GPRS guarantees this
ability) cellphone to make a 9600 baud dial up connection to an ISP
modem (or whatever you have handy). Note, this is *not* whatever high
speed connection your provider offers. This is 9600 baud, fairly long
latency with occasional latency spikes due to scrambled-and-resent
data frames. A lot of modern software does *not* function over this
vastly better connection. I've actually seen a client (a chat client,
not that it matters) successfully connect, then queue up so much XML
status information that the connection *never* succeeded at passing
any actual information.

(snip)

 But it is clear to me that you CANNOT expect that a bandwidth bottleneck
 like a radio link, particularly a HF radio, to perform as a 10 or 100
 Mb/s (say) wired LAN. Otherwise, mating a LAN with a radio link without
 the appropiate traffic downsizing is doomed to failure.

A: You need applications that are aware of their link resource, or
else are OK with batching traffic and offloading actual delivery to
some other tool.

B: even 802.11b/g has to significantly adjust the timings under the
hood in any enterprise campus location. Much of the inefficiency a
large wifi location sees is due to the fact that the actual layer 3
protocol (TCP in this case) timings aren't dynamically adjustable, so
layer 2 has to try to provide what layer 3 has been tuned to expect.

C: Amateur radio networks aren't best modeled by the modern TCP view
of the internet anyway. They're a much better approximation to the old
asynchronous-bundle-delivery UUCP days (although we have learned a few
things since those days; no need to be mistake-compatible with UUCP
=) Most useful things can be turned into bundles that can be
transferred to the peer whenever the peer can be reached. Unlike UUCP,
however, there must be at least some ability for ad-hoc
pathing-peering discovery, since HF is much different than a scheduled
telco-hardline dialup link.

(snip)


 There is no problem with RFC821 or RFC822, it is just a matter of what
 kind of channel access parameters are used. If they are matched to the
 channel properties, it may be OK, but otherwise, it will be entirely flawed.

Yes, in general, rather than trying to cram a legal ham HF/VHF link
under the existing internet layer 2 protocols, which at best results
in *terrible* efficiency, average throughput (whatever the peak may
be), etc, it's usually better to implement application protocols that
are a better fit to the channel constraints. Yes, you *can* adapt IP
protocols enough so that they'll work; once you've done that, almost
all applications written with the internet in mind will break anyway.
Just for fun, go look up the timings embedded in the HTTP/1.1 spec,
and imagine trying to meet the timeouts over a HF channel. Now note
that a large subset of the internet is unreachable from a HTTP/1.0
client... specifically *every* host that uses name-based virtual
hosting, which is almost 

Re: [digitalradio] Re: center of the waterfall question

2007-09-30 Thread Robert Thompson
Additionally, depending on the filters, the signal may be distorted
enough to impact its decodability despite favorable SNR. Usually by
the time this is a serious factor, the actual passed signal is
obviously too far down, but I've seen it happen once well within the
passband of a particularly weird filter.

Some modulations are more sensitive than others.
--
Regards, Robert Thompson


Re: [digitalradio] JT65A..first contact

2007-09-30 Thread Robert Thompson
I'm not sure what the current status is, but the NTP code has from
time immemorial contained modules for those... actually the CHU module
(basically a bell 103 software decoder) was what got me interested in
software signal processing ;-)



On 9/30/07, Jose A. Amador [EMAIL PROTECTED] wrote:

 I guess you are using ntp via modem.

 I am interested in finding a way to sync Linux to CHU, WWV or WWVB using
 a soundcard and the radio time codes.

 Does anyone on the list has already done that? How?

 73,

 Jose, CO2JA

 ---

 David Munn wrote:

  for clock accuracy im using the ntp server of au.pool.ntp.org as
  Dimension4 is only for Windows..clock seems to be accurate
 
  Tnx Andy K3UK for a very good jobneed to add some comments for
  Linux users
 
  Hope to see some of you on JT65A
 
  David VK4BDJ


 __

 Participe en Universidad 2008.
 11 al 15 de febrero del 2008.
 Palacio de las Convenciones, Ciudad de la Habana, Cuba
 http://www.universidad2008.cu


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

 Yahoo! Groups Links






-- 

Regards, Robert Thompson


~   Concise, Complete, Correct: Pick Two
~   Faster, Cheaper, Better: Pick Two
~   Pervasive, Powerful, Trustworthy: Pick One
~Whom the computers would destroy, they first drive mad.
~-- Anonymous



Re: [digitalradio] Re: [multipsk] Re: Tests in ARQ FAE

2007-09-30 Thread John Bradley
Steinar;

I'll listen for you on 30m and 20M , on 10136.5 now but probably too late. 

Have heard Europe today so maybe band is improving, will sit on 14109.5 as of 
0600Z tomorrow. See if you can get my station to answer

John
VE5MU


  - Original Message - 
  From: Steinar Aanesland 
  To: [EMAIL PROTECTED] ; digitalradio@yahoogroups.com 
  Sent: Saturday, September 29, 2007 4:57 AM
  Subject: [digitalradio] Re: [multipsk] Re: Tests in ARQ FAE


  Hi Patrick,

  What about trying 10.136,500 later this evening ?
  The 30m is a lovely band free from contest qrm .

  73 de LA5VNA Steinar

  Patrick Lindecker skrev:
  
   Hello to all,
   
   As there is a WW RTTY contest, the 14109.5 frequency is and will not
   be free. So this ARQ FAE test will be done another day.
   
   73
   Patrick
   
  
   - Original Message -
   *From:* Patrick Lindecker mailto:[EMAIL PROTECTED]
   *To:* [EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED] ; [EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED] ; digitalradio@yahoogroups.com
   mailto:digitalradio@yahoogroups.com
   *Sent:* Friday, September 28, 2007 11:21 PM
   *Subject:* Tests in ARQ FAE
  
   Hello to all,
  
   I will be QRV for tests to-morrow saturday morning in 14109.5 KHz
   USB at 10h00 UTC, for the ones interested. I will call CQ in ARQ
   FAE up to 10h30 UTC.
  
   A 4.4.2 Multipsk test version in a ZIP test package is available
   in my site. It contains the Multipsk test version (with ARQ FAE
   bugs fixed).
   http://f6cte.free.fr/MULTIPSK_TEST_22_09_2007.ZIP
   http://f6cte.free.fr/MULTIPSK_TEST_22_09_2007.ZIP
  
   Paste this adress in your Internet Explorer or equivalent.
   Download the file.
   Create a tempory folder (C:\TEST, for example), unzip the file in
   it and start C:\TEST\Multipsk.exe (the auxiliary files will be
   created automatically).
  
   73
  
   Patrick
  
   



   


--


  No virus found in this incoming message.
  Checked by AVG Free Edition. 
  Version: 7.5.488 / Virus Database: 269.13.33/1037 - Release Date: 9/29/2007 
1:32 PM


Re: [digitalradio] JT65A..first contact

2007-09-30 Thread David
Jose A. Amador wrote:


 I guess you are using ntp via modem.

 I am interested in finding a way to sync Linux to CHU, WWV or WWVB using
 a soundcard and the radio time codes.

 Does anyone on the list has already done that? How?

 73,

 Jose, CO2JA

 ---

 David Munn wrote:

  for clock accuracy im using the ntp server of au.pool.ntp.org as
  Dimension4 is only for Windows..clock seems to be accurate
 
  Tnx Andy K3UK for a very good jobneed to add some comments for
  Linux users
 
  Hope to see some of you on JT65A
 
  David VK4BDJ

 __

 Participe en Universidad 2008.
 11 al 15 de febrero del 2008.
 Palacio de las Convenciones, Ciudad de la Habana, Cuba
 http://www.universidad2008.cu http://www.universidad2008.cu

  
Hi Jose.in most Linux distros such as Ubuntu Fedora Mandriva etc 
there is a gui for setting the Date and Time under a Settings Menu.i 
use the KDE desktop so know that one well..i understand that the same is 
available under GNOME.in KDE it comes up with the GUI and you can 
set the automatic update of the time so that it uses a ntp 
server...there are some listed in the gui...the one i use is setup for 
VK and is useful if any part of the net goes down overseas.a list of 
the servers can be found by searching on the net.
I presume it does the same thing as Dimension4 does for Windows as i 
notice it uses a net time server
Yes this is done via a modem interfacing to the net...
i dont know of a way to do this via a radio and a time signal station 
such as WWV or WWVH...
Here in VK the HF time signal stations are very weak or not audible at 
times due to propagation and the fact there are none down under in the 
South Pacific.

Hope this helps ...any more questions im only too happy to try and 
answer.

David VK4BDJ


[digitalradio] Digital supported in LOTW Contest: 0000 UTC Saturday 6 October 2007 to 2359 UTC

2007-09-30 Thread Andrew O'Brien
Name:   Name:   LoTW Contest
Contest Periods:PHONE:   UTC Saturday 6 October 2007 to 2359
UTC Saturday 6 October 2007

CW / RTTY/Digital:   UTC Saturday 13 October 2007 to 2359 UTC
Saturday 13 October 2007

PHONE, CW, and RTTY/Digital portions of the contest are considered
separate contests and must be submitted separately.

All operators may use spotting networks, either RF or internet, as
long as the use of the spotting network is open to the general public.
Categories: Single Operator CW
Single Operator RTTY/Digital
Single Operator SSB
 Band:  AB -- All Band (no WARC 12M,17M, or 30M) band QSOs allowed)
S160 -- Single band-160M
S80 -- Single band-80M
S40 -- Single band-40M
S20 -- Single band-20M
S15 -- Single band-15M
S10 -- Single band-10M
Power:  HP -- Greater than 200 watts
LP -- 200 watts or less for the whole contest
QRP - less than 5 watts for the whole contest
Exchange:   All participants use RS(T) and State/Province/DXCC
Country. If you are also a participant of another contest, you can
additionally send other formatted reports, but for this contest that
extra information does not need to be logged.

NOTE: If it is determined that an operator is not in the state sent in
the report, his entry will be disqualified.
  Points:   QSOs with country, 2 points. QSOs with other countries
on same continent, 5 points. Contacts with other continents, 10
points. Maritime mobile contacts count 5 points. There is no
lmultiplier value for a maritime mobile contact.

All scoring will be automated and assessed when the LoTW QSL log is evaluated.
 Multipliers:   Each continental U.S. State (48), USA District of
Columbia (DC), Canadian area (13), and DX country. KL7 and KH6 are
considered DX and not states for this contest. DX countries are DXCC
plus WAE (IT, GM Shetland Islands, et al). Canadian areas include VO1,
VO2, NB, NS, PEI, VE2, VE3, VE4, VE5, VE6, VE7, NWT, and Yukon. Do not
count States and Canada as separate countries. For DX stataions, send
signal report and DXCC prefix for your country. Example for OM2AK in
Slovak Republic, the DXCC is OM, therefore on CW, he would send 599
OM. Note multipliers (countries, provinces, and states) will be
automatically determined by the sponsors log-checking software. Same
multipliers as CQWW160M Contest.
  Score:Total Points X Total Multipliers
  Logs: Contest logs in either Cabrillo Format or ADIF format
should be uploaded to LotW any time after the contest, but no later
than 30 days after the contest.  No hand-written logs or any other
format will be accepted. Use the following contest names on the
CONTEST: line of the Cabrillo log file: LOTW-SSB or LOTW-CW or
LOTW-RTTY. If an adi/adif file is used to upload logs to the ARRL
site, then there is no need to include the name of the contest.
  Elgible Operator: Non-LoTW member stations may operate, but must
join LoTW as soon as possible (no later than 30 days after the
contest) after the contest to be included and have your LoTW QSLs
count for the other members and to be included in the results
listings.
  Submittals:   Your contest submittal is your LoTW QSL download
report for the contest period, renamed from LOTWREPORT.ADI to
Example: Callsign_Category_Band_Power.ADI) and should be downloaded
no sooner than 30 days after the contest and no later than 45 days
after the contest.  Your downloaded QSL report is your contest entry
and should be uploaded to http://www.lotwcontest.com anytime between
30 days and 45 days after the contest. To complete your entry, you
will fill out an online entry form, on which you will enter, Your
Callsign, Mode operated, Class (All or which singe-band), Highest
power used, State/Province/Country operated from, and filename of
uploaded ADI file,   To make this fair to all entries, our log
checking software will only count QSLs that are awarded within the 30
days immediately following the contest period.

Name your lotwreport.adi file as: Callsign_Category_Band_Power.ADI.
Examples:  N5RR_CW_AB_HP.ADI or N5RR_PHONE_S160_LP.ADI.

Contest loggers use existing setup for Oceania DX Contest and
disregard score for the LoTW log. Scoring for the LoTW Contests will
be automatically generated by the sponsor once your log is submitted.

There will not be any penalty for duplicates since our log checking
software will automatically zero out the duplicate contacts on the
same band.

Busted calls will not be a factor, since there will not be a match and
no LoTW QSL will be generated. Same goes for non-LoTW participants
which can make QSOs, but their logs would have no way to get submitted
into LoTW, hence no QSL generated.
  Awards:   Certificates for High World, High State, High Province,
and High Country in each power class.  Second and Third place will be
awarded as participation requires.  All stations making more than 500
QSOs will receive 

Re: [digitalradio] JT65A..first contact

2007-09-30 Thread Jose A. Amador

David,

I do not have full Internet at home, just e-mail.

I have been using CHU with the CLOCK program from F6CTE, for Windows.

I am running XP now, but this is a dual boot PC. That's the reason I
am interested in using the radio to sync my PC, which is necessary to 
use WSJT or track satellites.

I have used gMFSK and FLDIGI ocassionally. I began using Linux with my 
old 386 and did so for some 10 years also with newer computers.

Even when I have three Linux distros installed here nowadays (Ubuntu 
6.06 LTS, Slackware 10.2 and Mandriva Spring 2007), I use XP mostly 
because I need to stay compatible with my students, who use Windows 
mostly. Open Office has not been entirely compatible for reasons we all 
know, and I do not want to jeopardize my conferences with some obscure 
bug to embarrass me in an inappropiate moment.

I revived an old russian receiver and I have been even receiving WWVB on 
60 kHz from 3200 km away almost 24/7, using my HF G5RV. I have to do my 
homeworkand build a better long wave antenna...but so far I have not.

I know that VNG did shut off some time ago, but maybe you could try JJY 
on 40 or 60 kHz, if you could, even when I know that you can sync from 
the Internet. I believe that even WWVH might be too far away from you in 
this scarce sunspots period.

Being capable to sync from a radio is also interesting when you are 
portable, and away from the Internet. I have never been able to get the 
NTP sound card code working on Linux. I would have to look for it and 
download it again. I believe I compiled it a long time ago and some 
dependencies failed at compile time, I do not remember exactly which 
right now. Being busy and in a hurry as usual, I left it for some 
quieter moment...still to be found.

Back to comment about CHU, their code seems bulletproof. It either syncs 
  the right time or does not at all. Not the same with the simpler codes 
that WWV or WWVB use, with a lot of false decodes, that do not harm 
because I keep a very tight sync window of only three minutes to filter 
out the false decodes.

Thanks for your reply,

73,

Jose, CO2JA



David wrote:

 Hi Jose.in most Linux distros such as Ubuntu Fedora Mandriva etc 
 there is a gui for setting the Date and Time under a Settings Menu.i 
 use the KDE desktop so know that one well..i understand that the same is 
 available under GNOME.in KDE it comes up with the GUI and you can 
 set the automatic update of the time so that it uses a ntp 
 server...there are some listed in the gui...the one i use is setup for 
 VK and is useful if any part of the net goes down overseas.a list of 
 the servers can be found by searching on the net.
 I presume it does the same thing as Dimension4 does for Windows as i 
 notice it uses a net time server
 Yes this is done via a modem interfacing to the net...
 i dont know of a way to do this via a radio and a time signal station 
 such as WWV or WWVH...
 Here in VK the HF time signal stations are very weak or not audible at 
 times due to propagation and the fact there are none down under in the 
 South Pacific.
 
 Hope this helps ...any more questions im only too happy to try and 
 answer.
 
 David VK4BDJ


__

Participe en Universidad 2008.
11 al 15 de febrero del 2008.
Palacio de las Convenciones, Ciudad de la Habana, Cuba
http://www.universidad2008.cu


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

2007-09-30 Thread Jose A. Amador
Robert Thompson wrote:

 You probably mean Linux kernel-mode AX.25, since JNOS runs fine on
 Linux =)

Yes, I meant EXACTLY that. Kernel AX.25 can be fooled to endless repeats
by TFPCX and an inadequate computer (say, a 286 running some terminal
ughh !!) That has been a factual case for endless sysop/nodeop
headaches.

 been a fairly good match to the radio channel characteristics for
 e-mail and web browsing over AX.25 packet radio.

I used PCElm, and some other client with JNOS before I had a phone at
home. I had my e-mail that way, using LZW compressed POP3 and SMTP.

Not for exchanging photo albums, but perfect for mail contacts and even
some ftpmail in small manageable chunks.

The beauty of JNOS is the ability to tweak parameters, and topping
maxwait, so the it is better able to hold the radio link.

 Absolutely true! Two or three possibilities: Do what is sometimes
 done for internet satellite terminals and spoof the TCP state
 machine by locally generating ACKs, etc then committing to transfer
 the frames yourself however you see fit. This works fine for some
 things, terribly for other things. This is great for conditions where
 the TCP client and server will break if their assumptions are tested 
 (Remember, 99.5% of modern internet apps *assume* ubiquitous high 
 bandwidth, low delay, low loss connectivity, and the timings that go 
 with it)

It is a pity I cannot remember the names now, since that bad experience
has piled up more than 10 years of oblivion. It was something capable of
using a terminal with a packet driver and redirecting packets from 10
Mb/s ethernet to the serial port. It was a chaos generator, even on
clear 2 meters channels with agressive fracks.

 Alternatively, you can create protocol gateways that do non-TCP
 over the air, with the other end acting like a remote-controlled
 TCP client.

I also used FBB forwarding for SMTP email over HF. It worked, but it
needed a fairly clean channel to suceed, since the JNOS version did not
implement the Z modem style code of the original FBB forwarding, and if
the link failed, it could not continue from the offset it broke but
rather had to restart the transfer from the beginning.

 The HMTP smtp-variant can be thought of as one take on this, and it's
 not too hard to implement a similar thing for straight POP or HTTP.
 The result will work better (since neither the local-to radiobridge
 TCP connection nor the remote-radiobridge-to-internet TCP connection
 needs to have its timing fiddled with), but there are a LOT of
 non-trivial edge conditions to deal with if you want the thing to 
 work with the internet in the wild. Sadly, not reads internet RFCs 
 every night before bed... =)

Yes, I have read about HMTP but have not actually tried it. I was
rereading an article about it yesterday's evening

Nevertheless, I already have telephone at home and a V-90 modem, so I
have no need to do the past linking acrobatics.

Seems there are more than 100 ways to boil a frog

 (snip)
 packet sizes. Even on 2 meters 1200 baud links, it creates havoc.
 
 Heh, you want a feel for exactly how bad the problem is? Try using a 
 GSM/GPRS (others might do this too, but GSM/GPRS guarantees this 
 ability) cellphone to make a 9600 baud dial up connection to an ISP
  modem (or whatever you have handy).

I have been tempted to try it, but it is  E X P E N S I V EI rather
use the V.90 modem.

 Note, this is *not* whatever high speed connection your provider
 offers. This is 9600 baud, fairly long latency with occasional
 latency spikes due to scrambled-and-resent data frames. A lot of
 modern software does *not* function over this vastly better
 connection. I've actually seen a client (a chat client, not that it
 matters) successfully connect, then queue up so much XML status
 information that the connection *never* succeeded at passing any
 actual information.

Linux AX.25 taught me a vastly better implementation than what I had
seen in MSDOS and Windows. I used standard browsers and it was usable
for ftp and textual HTML. Images seem to be always heavy. You could feel
the slowness, but with a lot of patience, it did work, qnd I would say
it did its job well. All that at 1200 baud.

And I even could finish quite a few ftp transfers on HF at 300 baud.
Small files, from 10 to 50 K were perfectly transferable.

 (snip)
 
 But it is clear to me that you CANNOT expect that a bandwidth
 bottleneck like a radio link, particularly a HF radio, to perform
 as a 10 or 100 Mb/s (say) wired LAN. Otherwise, mating a LAN with a
 radio link without the appropiate traffic downsizing is doomed to
 failure.
 
 A: You need applications that are aware of their link resource, or 
 else are OK with batching traffic and offloading actual delivery to 
 some other tool.

Certainly. RedHat 5.2 and 6.2, (and possibly others as well) performed
as expected in a SLOW link. A feat Windows is uncapable of.

 B: even 802.11b/g has to significantly adjust the timings under the 
 

[digitalradio] Amateur Radio Newsline Report - RADIO LAW: NFCC ASKS FCC TO DECLARE DIGITAL VOICE REPEATERS THE SAME AS ANALOG

2007-09-30 Thread Mark Thompson
Amateur Radio Newsline Report 1572 -  September 28, 2007

Amateur Radio Newsline report number 1572 with a release date of  
Friday, September 28, 2007 to follow in 5-4-3-2-1.   

The following is a Q-S-T. The National Frequency Coordinators' Council 
asks the FCC to declare all digital voice repeaters follow the same 
rules as analog F-M repeaters, Australia makes ready for digital voice 
operations and four New England repeaters voluntarily shut down over 
interference to Pave Paws radar.  
Find out the details on Amateur Radio NewslineT report number 1572 
coming your way right now.
 
**

RADIO LAW:  NFCC ASKS FCC TO DECLARE DIGITAL VOICE REPEATERS THE SAME 
AS ANALOG

Is a digital voice repeater really a repeater or is it something else 
yet to be defined in law?  The National Frequency Coordinators' Council 
believes that anything that repeats voice in close to real time is a 
repeater, and its now asked the FCC to declare this to be the case.  
Jay Maynard, K5ZC, is president of the NFCC.  He explains the back 
story that lead his organization to act:

--

K5ZC:  When D-Star started really taking off, somebody wanted to put 
up a D-Star repeater.  He went to his local coordination council and 
wanted to put up a 2 meter D-Star repeater.  He went to his local 
coordination council but was told no because we do not have any 
frequencies available for you.  In desperation -- I don't know if 
that's a truly accurate word but its close enough -- they (the want to 
be repeater owners) went to the FCC and described what D-Star did in 
such a way that the FCC -- specifically Bill Cross -- concluded that a 
D-Star repeater really wasn't a repeater and therefore did not have to 
operate in the repeater subbands.

--

That night be all well and good if it were only D-Star and other 
digital repeaters that fell into this category.  Unfortunately, many of 
today's analog FM systems alo include a slight audio delay to 
facilitate control or linking.  And it soon became apparent that this 
opinion by Bill Cross could lead to a lot of problems on the VHF and 
UHF bands:

--

K5ZC:  This guy said 'fine' and he put his machine up on 145.61MHz 
with a minus 1.2 MHz offset and went to town  That gave  D-Star a 
foothold in that area, but it also opened up a real can of worms 
because the way that Bill Cross wrote the message, he said that its not 
simultaneous because there is a delay  in the path between the input 
and the output.  

The problem there is that lots of (analog) repeaters have delays 
between the input and the output.  Anyone that's running an RC-850 
(controller) or other computerized controller has a delay.  And it was 
only a matter of time before some bright spark read that message and 
said: 'Ah hah!  My repeater does not transmit simultaneously either.  
Its not a repeater and I can get on outside the repeater subbands and  
go to town.

--

And that's what had frequency coordinators concerned.  They did not 
want to see a return to the repeater turf wars that marked the early 
days of FM relay operation:  

--

K5ZC:  In the late 1960's and early 1970' there was a lot of 
proliferation of repeaters.  That was really the 'golden age' of 
repeater construction.  And in that era is when frequency coordination 
first came about because you had people wanting to put their repeaters 
up all on the same frequency, and that did not work very well -- as you 
might imagine.

Part of the regulation that came down to stem that tide was restricting 
repeaters to parts of the ham bands so that they wouldn't take over the 
entire band.  After all, there are folks that do other things than 
operate FM repeaters on 2 meters and on some of the other bands and 
they have just as much right  to operate on the ham bands as repeater 
operators do.  And that's where the restriction (of repeaters) to 
certain subbanbds comes from.
  
--

After debating the matter for several months  as more and more digital 
voice systems took to the air, the majority of NFCC members agreed that 
it was imperative for them to let the FCC know that they believe any 
device that retransmits an audio signal in near to real time is a 
repeater and should be treated as such.--

--

K5ZC:  What the NFCC did was vote to ask the FCC to treat anything 
that asks like a repeater, as a repeater.  This was a formal motion and 
vote of the council.

--

Specifically, the letter states that the NFCC believes that any amateur 
station, other than a message forwarding system, that automatically 
retransmits a signal sent by another amateur station on a different 
frequency while it is being received, regardless of any delays in 
processing that signal or its format or content, is a repeater station 
within the meaning of paragraph 97.3(a)(39) of the FCC rules and should 
be treated as such.  In practical terms, it means that D-Star, APCO 25 
and any other repeatable digital voice system that comes along would be 
restricted to operation in the FCC