It appears the mystery of the Kenwood D710 going deaf is solved...
This blog:
has a link to the withering filters explanation:
and a link to the solution:
73
Bill - WA7NWP
Wednesday, October 27, 2010
Tuesday, October 12, 2010
BALLOON LAUNCH SAT OCT 16 FROM RITZVILLE
The as-yet-unnamed Inland Empire Near Space Enthusiasts (IENSE) group has completed final preparations for the launch, tracking, and recovery of a high altitude balloon scheduled for launch Saturday morning from the Ritzville, WA area. Final launch preparations were discussed in a leadership meeting this past weekend.
Details follow:
Launch: Saturday, October 16, 0800-0830PDT, weather dependent (forecast is a go for launch)
Launch Site: Ritzville High School. Launch team on-site by 0730. Breakfast at Ritzville Perkins 0645PDT.
Flight profile: Wind predictions are to the East.
Projected LZ (landing zone) is 65-90 miles (LZ will be refined and identified on www.findu.com upon burst detection).
Projected altitude is 90k feet on a two hour flight.
Tracking callsign: Two APRS trackers: K7GPS-11 and KG5AO-8. (Tracking also available on www.aprs.fi)
Package: 1000g latex balloon with helium fill, 6' parachute for recovery after burst, capsule is 15"x12"x9" styrofoam container with two APRS trackers (KG5AO-8 and K7GPS-11), vertical SD color video camera with GPS overlay to record balloon expansion and burst), SD color video camera on diagonal alignment, and two SD Canon A470 cameras with CHDK-hack recording horizontal imagery every 10 seconds.
Tracker details: K7GPS-11 is a BigRedBee BeeLine 2M all-in-one APRS tracker. KG5AO-8 is a Yaesu Vertex 2M HT, Byonics TinyTrak3 controller, and Garmin E-Trex GPS. Both GPS devices are certified for flight above 60k ft.
Credit: Thanks to members of the Spokane Astronomical Society for their interest, support, and enthusiasm with this project.
PAO Note: KHQ has been contacted and may attend the launch activities.
Related links:
- Tracker 1 K7GPS-11: http://www.findu.com/k7gps-11
- Tracker 1 K7GPS-11: http://aprs.fi/?call=k7gps-11
- Tracker 2 KG5AO-8: http://www.findu.com/kg5ao-8
- Tracker 2 KG5AO-8: http://aprs.fi/?call=kg5ao-8
Regards, David K7GPS
Thursday, October 7, 2010
APRS Messenger v2.89 with many changes released
Date: Thu, Oct 7, 2010 at 3:26 AM
Subject: [cross_country_wireless] APRS Messenger v2.89 with many changes released
I've just uploaded v2.89 to the website and Files section.
This version has a lot of changes:
Separate transmit and receive sound cards can now be configured.
Sound card sample rates of 48000 Hz and 11025 Hz can now be selected.
Fast and slow CPU options can now be selected.
It has the latest version of the MMVARI sound card engine (first update in 5 years).
The program can with fast CPU selected run 24 simultaneous receivers receiving a selection of modes including PSK-63, PSK-250, QPSK-63, QPSK-125, QPSK-250, GMSK-63, GMSK-125 and GMSK-250. The CPU load is higher and it will only run on PC's faster than 500 MHz due to the amount of number crunching and text string munching that the program is doing.
With slow CPU selected the CPU load is similar to earlier versions with only PSK-63, PSK-250, GMSK-63 and GMSK-250 being received. The slow version will also send on any selected mode but will only receive on the centre frequency with slow AFC.
The check before transmitting routine has also been changed to stop transmitting over other signals.
The delay before an ACK is transmitted has also been extended by 300 microseconds as it was too fast for some transceivers.
Subject: [cross_country_wireless] APRS Messenger v2.89 with many changes released
I've just uploaded v2.89 to the website and Files section.
This version has a lot of changes:
Separate transmit and receive sound cards can now be configured.
Sound card sample rates of 48000 Hz and 11025 Hz can now be selected.
Fast and slow CPU options can now be selected.
It has the latest version of the MMVARI sound card engine (first update in 5 years).
The program can with fast CPU selected run 24 simultaneous receivers receiving a selection of modes including PSK-63, PSK-250, QPSK-63, QPSK-125, QPSK-250, GMSK-63, GMSK-125 and GMSK-250. The CPU load is higher and it will only run on PC's faster than 500 MHz due to the amount of number crunching and text string munching that the program is doing.
With slow CPU selected the CPU load is similar to earlier versions with only PSK-63, PSK-250, GMSK-63 and GMSK-250 being received. The slow version will also send on any selected mode but will only receive on the centre frequency with slow AFC.
The check before transmitting routine has also been changed to stop transmitting over other signals.
The delay before an ACK is transmitted has also been extended by 300 microseconds as it was too fast for some transceivers.
Chris, G4HYG
Sunday, October 3, 2010
Summary on UIView and IGates by WA8LMF
1) UIview does an excellent job as an igate. Contrary to the previous posting on this thread that two-way igates are difficult to set up, the default settings in UIview make it almost trivial to place a two-way igate on the air with next-to-zero impact on the RF channel.
2) Two-way igates DO NOT indiscriminately flood the RF channel with traffic from the APRS Internet System. Unless you go out of your way to explicitly edit a control file in UIview, the program only "reverse-gates" (i.e. Internet-to-RF) messages addressed to specific callsigns --- NOT generic APRS traffic such as WX beacons and position reports that are "broadcast" to everyone, and not reverse-gate to stations that are not in the immediate area.
3) On the "Setup, APRS Server Setup" dialog, locate the area in the upper right of the dialog that says "Gate RF To Interenet". Check "Open the gateway" and "Insert station callsign". In the area just below this ("Gate Internet To RF"), check "Gate local messages" and "Use reverse digi path" .
4) The option "Use reverse digi path" causes UIview to override the normal "Unproto Address" digi path set in "Setup, Station Setup" for the station's own beacons, when reverse-gating messages. Instead, messages sent to stations heard by the igate directly (i.e. not via digipeaters) will be transmitted to RF with NO DIGIPEATER PATH AT ALL.
5) Messages will be reverse-gated IF and ONLY IF the destination station has been heard on RF locally (either direct or within one digi hop) --- and --- if the destination station has been heard on RF by the igate recently (within the last half hour).
6) This process of selectively reverse-gating on a minimal path works both for messages originated by the RF (mobile) station, and for messages originated by the Internet party.
7) It even works for a station on RF in one part of the world (say on the East Coast or in Europe) working a mobile on RF in another part of the world (say the West Coast). That is a message path can go RF<-->Internet<-->RF in a manner similar to a station on RF in California talking to a mobile in Europe via EchoLink or IRLP.
The same reverse-gating rules apply: If the RF stations on each end are both local to their respective igates, and have both been heard by their respective igates recently, then two-way messaging will work. Otherwise, reverse-gating will not happen.
8) As a mobile travels cross-country, it will move out of the local range of a given igate, and into the range of another one. When an igate stops hearing the mobile LOCALLY (it might still hear the mobile via several digi hops), the digi will then age the mobile's call out of it's table of "recently heard stations" and will stop reverse-gating any messages to/from that mobile. Hopefully by this time, the mobile is now within the "local" range of another igate which will take up the task of reverse-gating. [This process is very similar to a traveler with a cellular phone moving from one cell site to another.]
Note that the stations in question don't have to be messaging for these decisions to be made. The igates make the determination of "local" and "recently heard" based on the periodic "one-way" position beacon transmissions the station is normally making anyway.
8) One-way igates break this symmetry of send/receive. A mobile originating a message will get INTO the Internet system through a one-way igate, but the reply (ack) can't get BACK to him. The originating mobile responds by cluttering the RF channel with endless automatic repetitions of the message in a vain attempt to get an ack back. In other words, one-way igates can create MORE congestion than two-way ones!
Further the Internet (or remote RF station) being messaged can't reply to the incoming message he just received.
Stephen H. Smith wa8lmf (at) aol.com
Home Page: http://wa8lmf.net
2) Two-way igates DO NOT indiscriminately flood the RF channel with traffic from the APRS Internet System. Unless you go out of your way to explicitly edit a control file in UIview, the program only "reverse-gates" (i.e. Internet-to-RF) messages addressed to specific callsigns --- NOT generic APRS traffic such as WX beacons and position reports that are "broadcast" to everyone, and not reverse-gate to stations that are not in the immediate area.
3) On the "Setup, APRS Server Setup" dialog, locate the area in the upper right of the dialog that says "Gate RF To Interenet". Check "Open the gateway" and "Insert station callsign". In the area just below this ("Gate Internet To RF"), check "Gate local messages" and "Use reverse digi path" .
4) The option "Use reverse digi path" causes UIview to override the normal "Unproto Address" digi path set in "Setup, Station Setup" for the station's own beacons, when reverse-gating messages. Instead, messages sent to stations heard by the igate directly (i.e. not via digipeaters) will be transmitted to RF with NO DIGIPEATER PATH AT ALL.
5) Messages will be reverse-gated IF and ONLY IF the destination station has been heard on RF locally (either direct or within one digi hop) --- and --- if the destination station has been heard on RF by the igate recently (within the last half hour).
6) This process of selectively reverse-gating on a minimal path works both for messages originated by the RF (mobile) station, and for messages originated by the Internet party.
7) It even works for a station on RF in one part of the world (say on the East Coast or in Europe) working a mobile on RF in another part of the world (say the West Coast). That is a message path can go RF<-->Internet<-->RF in a manner similar to a station on RF in California talking to a mobile in Europe via EchoLink or IRLP.
The same reverse-gating rules apply: If the RF stations on each end are both local to their respective igates, and have both been heard by their respective igates recently, then two-way messaging will work. Otherwise, reverse-gating will not happen.
8) As a mobile travels cross-country, it will move out of the local range of a given igate, and into the range of another one. When an igate stops hearing the mobile LOCALLY (it might still hear the mobile via several digi hops), the digi will then age the mobile's call out of it's table of "recently heard stations" and will stop reverse-gating any messages to/from that mobile. Hopefully by this time, the mobile is now within the "local" range of another igate which will take up the task of reverse-gating. [This process is very similar to a traveler with a cellular phone moving from one cell site to another.]
Note that the stations in question don't have to be messaging for these decisions to be made. The igates make the determination of "local" and "recently heard" based on the periodic "one-way" position beacon transmissions the station is normally making anyway.
8) One-way igates break this symmetry of send/receive. A mobile originating a message will get INTO the Internet system through a one-way igate, but the reply (ack) can't get BACK to him. The originating mobile responds by cluttering the RF channel with endless automatic repetitions of the message in a vain attempt to get an ack back. In other words, one-way igates can create MORE congestion than two-way ones!
Further the Internet (or remote RF station) being messaged can't reply to the incoming message he just received.
Stephen H. Smith wa8lmf (at) aol.com
Home Page: http://wa8lmf.net
Subscribe to:
Posts (Atom)