| |
VK7AX > OZAPRS 26.11.07 05:04l 681 Lines 19340 Bytes #999 (0) @ VKNET
BID : VK7AX-2611OZ
Read: GUEST
Subj: Ozaprs Digest, Vol 27, Issue 25
Path: ON0AR<ON0BEL<CX2SA<ZL2BAU<VK7NW
Sent: 071126/0344Z @:VK7NW.#ULV.TAS.AUS.OC #:30636 [NWTARIG] FBB7.00g $:VK7AX-2
From: VK7AX@VK7NW.#ULV.TAS.AUS.OC
To : OZAPRS@VKNET
Today's Topics:
1. ICOM 706 MKii G Packet experience. (Andrew Rich)
2. Alpine Rally - APRS & RF conditions (Richard Hoskin)
3. Re: ICOM 706 MKii G Packet experience. (Andrew Rich)
4. Re: [aprssig] ICOM 706 MKii G Packet experience.
(Stephen H. Smith)
5. Satellite server test (Andrew Rich)
6. Re: Alpine Rally - APRS & RF conditions (Dick)
----------------------------------------------------------------------
Message: 1
Date: Sun, 25 Nov 2007 12:15:53 +1000
From: "Andrew Rich" <vk4tec@people.net.au>
Subject: [OZAPRS] ICOM 706 MKii G Packet experience.
To: "Aprssig" <aprssig@lists.tapr.org>
Cc: ozaprs <ozaprs@aprs.net.au>
Gudday
I thought I would share this experience - others may be able to help.
I bought a KPC3 for 1200 baud to use outboard with the ICOM 706 Mk iiG
Seemed to work well enough - using the "data" port on the ICOM 706. I seemed
to be copying most packets on ISS and PCSAT.
I then migrated to AGWPE sound card and I noticed that it was not copying
packets 100%.
I had a look on the Sound Card tuning aid and I saw something odd.
It looked like 1200/2200 but was sort of riding on a low frequency sine
wave, in that the packet tones where not symetrical about zero volts.
OK, time to drag out the CRO. Sure enough saw the same thing on the CRO.
Time to try something different - the "phones" connection on the front
panel - perfect nicely balanced packet.
Fiddled with the 9600 / 1200 baud lines and settings in the ICOM 706. Not
much joy.
Before I dig deeper (service manual), anybody seen similar ?
I wondered why my SATGATE was not hearing as much.
Seems the outboard TNC was more tolerant of the mucked up waveform ?
Cheers
----------------------------------------------------------------------------
Andrew Rich VK4TEC
vk4tec@people.net.au
http://www.tech-software.net
------------------------------
Message: 2
Date: Sun, 25 Nov 2007 13:53:06 +1100
From: "Richard Hoskin" <vk3jfk@amsat.org>
Subject: [OZAPRS] Alpine Rally - APRS & RF conditions
To: "'VK / ZL APRS Users'" <ozaprs@aprs.net.au>
Gday,
This weekend WICEN Vic is running the Alpine rally in eastern Victoria.
WICEN is using VK3REB-1 and VK3RGI-1 as digipeaters for APRS and scoring
data.
Due to RF conditions there is a lot of APRS traffic from VK7 and other areas
of VK3 being seen at the digipeaters. This has the effect of reducing the
available free air time for WICEN operators to use and is causing some
problems for communications in the event.
Here is an example of some of the data that is being received at the
digipeaters.
1:Fm VK7YBI To APRS Via TAS2* <UI pid=F0 Len=54 >[11:47:51]
;TRAFFIC *251159z4106.33S\14555.92E? 59 In 10 Minutes
1:Fm VK7HIL To APAGW Via VK7RAA,VK7RAC,WIDE2* <UI pid=F0 Len=19 >[11:48:08]
> >Will @ West Moonah
1:Fm VK3MHZ-12 To APT311 Via VK3CV-1,WIDE1,VK7RAA,WIDE2* <UI pid=F0 Len=15
> >[12:04:38]
> >TinyTrak3 v1.1
1:Fm VK3MHZ-12 To 37T8S8 Via VK3CV-1,WIDE1,VK7RVP,WIDE2* <UI pid=F0 Len=13
> >[12:05:22]
`IYllSmk/"4V}
1:Fm VK7DC To APU25N Via VK7RAC <UI pid=F0 Len=44 >[12:05:54]
}VK2INT-9>SSU2Y8,TCPIP,VK7DC*:`OX_mhk>/"4<}
1:Fm VK7DC To APU25N Via VK7RAC* <UI pid=F0 Len=44 >[12:08:31]
}VK2INT-9>SSU2X2,TCPIP,VK7DC*:`NV]mAV>/"4)}
1:Fm VK7HRM-9 To T1P6T5 Via VK7RAC*,WIDE2-2 <UI pid=F0 Len=13 >[12:08:32]
`IJ)l"+R/"6K}
1:Fm VK7HIL To APAGW Via VK7RAA*,WIDE2-1 <UI pid=F0 Len=19 >[12:08:03]
> >Will @ West Moonah
1:Fm VK7HIL-2 To APAGW Via VK7RAA*,WIDE2-1 <UI pid=F0 Len=75 >[12:08:04]
@251222z4251.35S/14716.65E_099/006g006t067r000P000p000h44b10218 West Moonah
1:Fm VK7HRM-9 To T1P6T5 Via VK7DC*,WIDE2-2 <UI pid=F0 Len=13 >[12:08:35]
`IJ)l"+R/"6K}
1:Fm VK7YBI To APRS Via TAS2* <UI pid=F0 Len=54 >[12:15:48]
;TRAFFIC *251227z4106.33S\14555.92E? 66 In 10 Minutes
1:Fm VK7YBI To APRS Via TAS2* <UI pid=F0 Len=54 >[12:17:44]
;TRAFFIC *251229z4106.33S\14555.92E? 82 In 10 Minutes
1:Fm VK7YBI To APRS Via TAS2* <UI pid=F0 Len=54 >[12:17:46]
;TRAFFIC *251229z4106.33S\14555.92E? 82 In 10 Minutes
No one can easily predict conditions or their effects and it is not the
fault of the operator that his/her data is travelling further than what
would normally be expected.
This is however a good example and lessoned that there are no state
boundaries to RF APRS and that we need to work together and cooperate with
each other on common standards and coordination with APRS.
To this extent we should have communicated before this WICEN event with VK7
and requested that they reduce their APRS traffic levels while the event is
on.
I have stopped all VK3 IGate traffic for the event duration and turned off
VK3RGI-1 as the event is not using it today.
I'm asking APRS stations in VK3 and northern VK7 to reduce their APRS RF
transmissions if the are not using the APRS network for a specific purpose
until the WICEN in VK3 finishes at the end of today.
Thanks.
Cheers
Richard
VK3JFK
------------------------------
Message: 3
Date: Sun, 25 Nov 2007 13:44:27 +1000
From: "Andrew Rich" <vk4tec@people.net.au>
Subject: Re: [OZAPRS] ICOM 706 MKii G Packet experience.
To: <vk4tec@people.net.au>, "Aprssig" <aprssig@lists.tapr.org>
Cc: ozaprs <ozaprs@aprs.net.au>
Found it - Switch mode power supply noise
----------------------------------------------------------------------------
Andrew Rich VK4TEC
vk4tec@people.net.au
http://www.tech-software.net
-----Original Message-----
From: Andrew Rich [mailto:vk4tec@people.net.au]
Sent: Sunday, 25 November 2007 12:16 PM
To: Aprssig
Cc: ozaprs
Subject: ICOM 706 MKii G Packet experience.
Gudday
I thought I would share this experience - others may be able to help.
I bought a KPC3 for 1200 baud to use outboard with the ICOM 706 Mk iiG
Seemed to work well enough - using the "data" port on the ICOM 706. I
seemed to be copying most packets on ISS and PCSAT.
I then migrated to AGWPE sound card and I noticed that it was not copying
packets 100%.
I had a look on the Sound Card tuning aid and I saw something odd.
It looked like 1200/2200 but was sort of riding on a low frequency sine
wave, in that the packet tones where not symetrical about zero volts.
OK, time to drag out the CRO. Sure enough saw the same thing on the CRO.
Time to try something different - the "phones" connection on the front
panel - perfect nicely balanced packet.
Fiddled with the 9600 / 1200 baud lines and settings in the ICOM 706. Not
much joy.
Before I dig deeper (service manual), anybody seen similar ?
I wondered why my SATGATE was not hearing as much.
Seems the outboard TNC was more tolerant of the mucked up waveform ?
Cheers
--------------------------------------------------------------------------
--
Andrew Rich VK4TEC
vk4tec@people.net.au
http://www.tech-software.net
------------------------------
Message: 4
Date: Sat, 24 Nov 2007 20:10:50 -0800
From: "Stephen H. Smith" <wa8lmf2@aol.com>
Subject: Re: [OZAPRS] [aprssig] ICOM 706 MKii G Packet experience.
To: vk4tec@people.net.au, TAPR APRS Mailing List
<aprssig@lists.tapr.org>
Cc: ozaprs <ozaprs@aprs.net.au>
Andrew Rich wrote:
> > Gudday
> >
> > I thought I would share this experience - others may be able to help.
> >
> > I bought a KPC3 for 1200 baud to use outboard with the ICOM 706 Mk iiG
> >
> > Seemed to work well enough - using the "data" port on the ICOM 706. I
> > seemed to be copying most packets on ISS and PCSAT.
> >
> > I then migrated to AGWPE sound card and I noticed that it was not
> > copying packets 100%.
> >
> > I had a look on the Sound Card tuning aid and I saw something odd.
> >
> > It looked like 1200/2200 but was sort of riding on a low frequency
> > sine wave, in that the packet tones where not symetrical about zero volts.
> >
> > OK, time to drag out the CRO. Sure enough saw the same thing on the CRO.
> >
> > Time to try something different - the "phones" connection on the front
> > panel - perfect nicely balanced packet.
> >
> > Fiddled with the 9600 / 1200 baud lines and settings in the ICOM 706.
> > Not much joy.
> >
> > Before I dig deeper (service manual), anybody seen similar ?
> >
> > I
1) What kind of computer and sound system were you using with AGW?
2) What kind of interface/isolation were you using between the radio
and the computer.
Some general observations and possibilities in no particular order........
o Motherboard-based sound systems are notorious for picking up noise
and hash from the computer's timing chains and clocks and DC-DC power
converters since they typically share the power supply and ground/common
busses with all the digital stuff on the motherboard. The result is a
lot of low-level trash superimposed on what ever you feed into them.
You don't hear this junk on the cheap speakers lacking bass response
typically used with computers, but critical DSP applications such as ham
sound card programs will be affected.
o Most motherboard-based sound systems are brain-dead "gutless
wonders" that substitute massive software drivers for dedicated
hardware, and dump the sound processing tasks on the host CPU instead of
using dedicated hardware. In turn, the sound processing competes for
CPU "air time" and interrupts with all the other software running on the
CPU at the same time. The sampling rate and timing of the audio A-to-D
conversion actually varies depending on the number of other tasks
running at the same time. The timing errors and varying sample rates
of many motherboard-based systems is enough to severely degrade the
decode performance of AGW.
Traditional add-on sound cards and external USB-connected sound systems
use dedicated hardware with accurate crystal-controlled timebases and
normally are much more accurate and consistent, and tend to be much
quieter.
o If you don't totally isolate the computer sound system from the
radio with audio transformers, you have a common metallic chassis
ground/earth between the two devices. In turn, this allows 50/60 Hz AC
leakage currents from the power supplies of either the computer, the
radio or both, and hash/noise from the computer's switching power
supply, to circulate on the common shield wires of the audio connections.
In turn, these circulating currents (a.k.a. "ground loops") can cause
several 10s or 100s of millivolts of noise and hum to be superimposed on
the TX and RX audio. Note that completely isolating the PC and radio
requires both transformer-coupling the TX and RX audio lines (typically
with 600/600 ohm telephone-type audio transformers salvaged from old
modems or answering machines) -AND- isolating the PTT line for keying
the transmitter with either opto-isolators or relays.
o The TNC has a very definite lower limit to it's audio frequency
response determined by the audio coupling capacitors on it's input.
(The TNC designer knows that nothing lower than several hundred Hz needs
to pass and sizes the caps accordingly.) The computer sound system has
an audio frequency response that is essentially flat clear to 5 or 10 Hz
(or even to DC). Any low frequency hum or hash picked up by cable ground
loops will pass much more readily into the computer sound input, with
less loss, than into the hardware TNC.
o Another possible source for the low-frequency hum or hash is the
refresh clocks for LCD displays in the radio which are often scanned at
only a few tens or hundreds of Hz. The speaker or headphones output
typically has far less low-frequency response than the dedicated
data/packet jack which is often DC-coupled to preserve the DC levels of
9600-baud packet. Small value coupling capacitors in series with the
audio isolation transformers can reduce this kind of low-frequency "
garbage.
o Finally, if you are using the MIC input of the computer sound
system rather than a LINE level one, you may need to attenuate the
receive audio fed into it by something like 50:1 to 100:1 to prevent the
mic amp from overloading. A simple resistive voltage divider consisting
of something like a 100K resistor and a 1K resistor will usually do it.
--
Stephen H. Smith wa8lmf (at) aol.com
EchoLink Node: 14400 [Think bottom of the 2M band]
Home Page: http://wa8lmf.com --OR-- http://wa8lmf.net
------------------------------
Message: 5
Date: Mon, 26 Nov 2007 07:54:41 +1000
From: "Andrew Rich" <vk4tec@people.net.au>
Subject: [OZAPRS] Satellite server test
To: <bruninga@usna.edu>, "'TAPR APRS Mailing List'"
<aprssig@lists.tapr.org>
Cc: ozaprs <ozaprs@aprs.net.au>
Ok, how about this, a socket server and a web page with status.
1. There is a PERL telent server running at vk4tec.no-ip.org, port 10151
2. The result ends up here on a web site.
http://vk4tec.no-ip.org/cgi-bin/sat_status.cgi
Point you UI-VIEW , satlogger etc.
What you send, gets there
----------------------------------------------------------------------------
Andrew Rich VK4TEC
vk4tec@people.net.au <mailto:vk4tec@people.net.au>
http://www.tech-software.net
-----Original Message-----
From: Robert Bruninga [mailto:bruninga@usna.edu]
Sent: Monday, 26 November 2007 2:18 AM
To: vk4tec@people.net.au; 'TAPR APRS Mailing List'
Subject: RE: [aprssig] GO32 Traffic
> > What is wrong with a pass all satellite server ?
Because there are lots of packets every 5 seconds from GO32 that
have nothing to do with APRS. So I wanted to filter them out,
but let the APRS status, beacons and bulletins pass to cut the
load on the APRS-IS.
I th ink GO32 is a great APRS asset. Anywhere on the planet,
even if you are crashed into a GORGE or ravine. If you switch
your uplink to 145.93 and switch to 9600 baud and path to VIA
4XTECH, then you will be seen at least twice a day.
Bob, WB4APR
> >
> > I think it would be a good thing to see satellite traffic.
> >
> > That is a pity about GO32 and APRS-IS. I started to invest
> > some time and
> > money into a GO32 station.
> >
> >
> > --------------------------------------------------------------
> > --------------
> > Andrew Rich VK4TEC
> > vk4tec@people.net.au <mailto:vk4tec@people.net.au>
> > http://www.tech-software.net
> >
> >
> >
> >
> > -----Original Message-----
> > From: Bob Bruninga [mailto:bruninga@usna.edu]
> > Sent: Monday, 26 November 2007 12:12 AM
> > To: vk4tec@people.net.au; TAPR APRS Mailing List
> > Subject: Re: [aprssig] GO32 Traffic
> >
> >
>> > > I just copied this from GO32 but not seen
>> > > in findu.com. My ui-view RFtoInet log says
>> > > the same. Why would the APRS-IS dump it ?
> >
>> > > 4XTECH-12>BEACON::BLN1 GO32:su APRS!!Use pth via 4XTECH
> >
> > I had proposed a SATGATE Server for all SATgates to connect
> > to and it would
> > filter out all NON APRS packets from GO-32 and pass the APRS
> > packets. But
> > AE5PL chose the simplistic solution of blocking all GO32
> > packets from all
> > javAPRSSrvr's worldwide.
> >
> > So anything that goes through a javAPRSSrvr will not allow
> > any GO32 packets
> > to reach the APRS-IS. Although user packets via GO32 will
> > get through OK,
> > the inability to monitor the operation of the APRS bulletins,
> > beacons and
> > status from GO-32 via the APRS-IS is frustrating.
> >
> > Bob, Wb4APR
------------------------------
Message: 6
Date: Mon, 26 Nov 2007 09:47:03 +1100
From: Dick <vk7dik@dodo.com.au>
Subject: Re: [OZAPRS] Alpine Rally - APRS & RF conditions
To: vk3jfk@amsat.org, "VK / ZL APRS Users" <ozaprs@aprs.net.au>
Are you for real Richard ???
On Sun, 25 Nov 2007 13:53:06 +1100, Richard Hoskin <vk3jfk@amsat.org>
wrote:
> > Gday,
> >
> >
> > This weekend WICEN Vic is running the Alpine rally in eastern Victoria.
> >
> >
> > WICEN is using VK3REB-1 and VK3RGI-1 as digipeaters for APRS and scoring
> > data.
> >
> >
> > Due to RF conditions there is a lot of APRS traffic from VK7 and other
> > areas
> > of VK3 being seen at the digipeaters. This has the effect of reducing the
> > available free air time for WICEN operators to use and is causing some
> > problems for communications in the event.
> >
> >
> > Here is an example of some of the data that is being received at the
> > digipeaters.
> >
> >
> > 1:Fm VK7YBI To APRS Via TAS2* <UI pid=F0 Len=54 >[11:47:51]
> >
> > ;TRAFFIC *251159z4106.33S\14555.92E? 59 In 10 Minutes
> >
> >
> > 1:Fm VK7HIL To APAGW Via VK7RAA,VK7RAC,WIDE2* <UI pid=F0 Len=19
>> > >[11:48:08]
> >
>> >> Will @ West Moonah
> >
> >
> > 1:Fm VK3MHZ-12 To APT311 Via VK3CV-1,WIDE1,VK7RAA,WIDE2* <UI pid=F0
> > Len=15
>> >> [12:04:38]
> >
>> >> TinyTrak3 v1.1
> >
> >
> > 1:Fm VK3MHZ-12 To 37T8S8 Via VK3CV-1,WIDE1,VK7RVP,WIDE2* <UI pid=F0
> > Len=13
>> >> [12:05:22]
> >
> > `IYllSmk/"4V}
> >
> >
> > 1:Fm VK7DC To APU25N Via VK7RAC <UI pid=F0 Len=44 >[12:05:54]
> >
> > }VK2INT-9>SSU2Y8,TCPIP,VK7DC*:`OX_mhk>/"4<}
> >
> >
> > 1:Fm VK7DC To APU25N Via VK7RAC* <UI pid=F0 Len=44 >[12:08:31]
> >
> > }VK2INT-9>SSU2X2,TCPIP,VK7DC*:`NV]mAV>/"4)}
> >
> >
> > 1:Fm VK7HRM-9 To T1P6T5 Via VK7RAC*,WIDE2-2 <UI pid=F0 Len=13
>> > >[12:08:32]
> >
> > `IJ)l"+R/"6K}
> >
> >
> > 1:Fm VK7HIL To APAGW Via VK7RAA*,WIDE2-1 <UI pid=F0 Len=19 >[12:08:03]
> >
>> >> Will @ West Moonah
> >
> >
> > 1:Fm VK7HIL-2 To APAGW Via VK7RAA*,WIDE2-1 <UI pid=F0 Len=75 >[12:08:04]
> >
> > @251222z4251.35S/14716.65E_099/006g006t067r000P000p000h44b10218 West
> > Moonah
> >
> >
> > 1:Fm VK7HRM-9 To T1P6T5 Via VK7DC*,WIDE2-2 <UI pid=F0 Len=13 >[12:08:35]
> >
> > `IJ)l"+R/"6K}
> >
> >
> > 1:Fm VK7YBI To APRS Via TAS2* <UI pid=F0 Len=54 >[12:15:48]
> >
> > ;TRAFFIC *251227z4106.33S\14555.92E? 66 In 10 Minutes
> >
> >
> > 1:Fm VK7YBI To APRS Via TAS2* <UI pid=F0 Len=54 >[12:17:44]
> >
> > ;TRAFFIC *251229z4106.33S\14555.92E? 82 In 10 Minutes
> >
> >
> > 1:Fm VK7YBI To APRS Via TAS2* <UI pid=F0 Len=54 >[12:17:46]
> >
> > ;TRAFFIC *251229z4106.33S\14555.92E? 82 In 10 Minutes
> >
> >
> >
> > No one can easily predict conditions or their effects and it is not the
> > fault of the operator that his/her data is travelling further than what
> > would normally be expected.
> >
> >
> > This is however a good example and lessoned that there are no state
> > boundaries to RF APRS and that we need to work together and cooperate
> > with
> > each other on common standards and coordination with APRS.
> >
> >
> > To this extent we should have communicated before this WICEN event with
> > VK7
> > and requested that they reduce their APRS traffic levels while the event
> > is
> > on.
> >
> >
> > I have stopped all VK3 IGate traffic for the event duration and turned
> > off
> > VK3RGI-1 as the event is not using it today.
> >
> >
> > I'm asking APRS stations in VK3 and northern VK7 to reduce their APRS RF
> > transmissions if the are not using the APRS network for a specific
> > purpose
> > until the WICEN in VK3 finishes at the end of today.
> >
> >
> > Thanks.
> >
> >
> > Cheers
> >
> > Richard
> >
> > VK3JFK
-- Cheers, Dick. VK7DIK
------------------------------
_______________________________________________
Ozaprs mailing list Ozaprs@aprs.net.au http://aprs.net.au/mailman/listinfo/ozaprs
End of Ozaprs Digest, Vol 27, Issue 25
**************************************
Read previous mail | Read next mail
| |
