| |
ZL3AI > APRDIG 10.03.03 16:37l 234 Lines 9556 Bytes #999 (0) @ WW
BID : 999-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 05, 2/5
Path: DB0FHN<DB0ZWI<DB0HST<ON0DXC<WA7V<VE1ATT<HA3PG<CT2GWY<VK3TE<VK7AX<
ZL2BAU<ZL3VML
Sent: 030308/1057Z @:ZL3VML.#80.NZL.OC #:61216 [Chch-NZ] FBB7.00i $:999-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Linux soundcard modem performance and refernces
From: "Ryan Wilkins" <ryan@deadfrog.net>
Date: Wed, 5 Mar 2003 08:14:22 -0500 (EST)
X-Message-Number: 6
In my experience, Soundmodem support worked very well at 1200 baud and
worked damn near as well at 9600 baud. I ran a APRS digi on it for a
while and I don't think anyone knew the difference. The only reason I
stopped is because the userspace programs to get Soundmodem to do
something wouldn't compile with the new glibc. I was running Redhat 6.2
on the machine but upgraded it to Redhat 8 and that pretty much put an end
to Soundmodem for me.
Looking now I see there are some updated RPM's for Redhat 7.3. Perhaps
the issues have been worked out.
As for current docs, I don't think there are any. You may try looking at
http://www.baycom.org/~tom/ham/soundmodem/ to see if that stuff will work
for you.
Ryan K9ZOE
>How well does this work (on a fast enough machine) when compared to a
>TNC-2 or KPC-3?
>
>Can anyone provide pointers to current docs? I've found a bunch of
>fragments, but nothing complete.
----------------------------------------------------------------------
Subject: Re: Linux soundcard modem performance and refernces
From: "J. Lance Cotton" <joe@lightningflash.net>
Date: Wed, 05 Mar 2003 08:30:39 -0600
X-Message-Number: 7
To add to this:
I recently wondered the same thing: how well would the usermode
soundmodem tools work; just in case I had my laptop with me and needed
to get an emergency APRS packet out or something.
Regarding the usermode soundmodem docs: I can't find any. I guess 'the
documentation is the source code'.
Here's what I found out. First, as root, run soundmodemconfig so that
you can create the various virtual modems. You need to create a 'New
Configuration', and then, inside that configuration, create a 'New Channel'.
After setting up the various parameters for the channel, you can run
soundmodem (as root). This will create an AX.25 interface, probably
called sm0 (or whatever you put in that field during configuration of
soundmodem).
Now the toughest part that I had was trying to figure out how to link up
this sm0 to my named port from /etc/ax25/axports file. I knew that with
Xastir, I typed in 'radio' as the port name, because that's what I
called it in the axports file. I also knew that I attached my KISS TNC
to this port with 'kissattach /dev/ttyS0 radio ...'. I saw that this
created an 'ax0' interface, but I had no clue how it was used.
Through playing around, I figured out that what probably happens is that
as the interfaces are created (like with kissattach, or soundmodem) they
grab the first unused line in the /etc/ax25/axports file (or wherever
your particular axports file is; I think mine is
/usr/local/etc/ax25/axports).
As far as performance; I was amazed that my old IBM Thinkpad 600 with a
crappy Crystal soundcard in it was able to decode as well as my MFJ-1270
TNC-2 clone. I haven't tried transmit yet, but I expect it will be similar.
Ryan, I think whatever issues there were with glibc have been worked
out. I am using soundmodem 0.7 and it compiles fine on RedHat 7.3 and
SuSE 8.1.
I really wish there was some documentation with the package other than
'this is the readme file for soundmodem 0.7'.
-Lance KJ5O
--
J. Lance Cotton, KJ5O
Three Step Plan: 1. Take over the world. 2. Get a lot of cookies. 3. Eat
the cookies.
----------------------------------------------------------------------
Subject: Re: APRS Urban Legend: FCC firmware upgrades, was Kenwood blah blah
From: "Ronald Reams" <wa4mjf@worldnet.att.net>
Date: Wed, 5 Mar 2003 09:49:51 -0500
X-Message-Number: 8
Right and NO tag with TYPE or TRANS TYPE number. Thanks, Joe.
Maybe some others will now know that ham transmitters do not go through the
procedure formerly known as type acceptance.
All devices that intentionally or unintentionally radiate RF have to have a
Part 15 certification.
73 de Ronnie
----------------------------------------------------------------------
Subject: Re: Kenwood redefines Warranty
From: "Laurie - g6isy" <g6isy@dsl.pipex.com>
Date: Wed, 5 Mar 2003 15:59:43 -0000
X-Message-Number: 9
Jeff King wrote:
>Yes, it is. So far, we have only identified 15.121 as the only thing
>restricting firmware updates by the end user, and then only on
>receivers capable of covering the cellular bands. Be aware that all
>unintential radiators (receivers) must be type accepted under part
>15, and that includes amateur radio transceivers.
Whilst not wishing to prolong this debate, Kenwood do provide end user
firmware upgrades for their TS-2000 radio. This covers HF to UHF. So I
suspect the issue as to whether firmware upgrades can be carried out by the
end user is not a fundamental or legislative issue with them. Its most
likely (as I think Bob said) that there is something about the design of the
D700 that means it cannot be reasonably upgraded by the end user.
Laurie
----------------------------------------------------------------------
Subject: Re: Kenwood redefines Warranty
From: Jeff King <jeff@aerodata.net>
Date: Wed, 5 Mar 2003 11:23:35 -0500
X-Message-Number: 10
On Wed, 5 Mar 2003 15:59:43 -0000, Laurie - g6isy wrote:
>Jeff King wrote:
>>Yes, it is. So far, we have only identified 15.121 as the only thing
>>restricting firmware updates by the end user, and then only on
>>receivers capable of covering the cellular bands. Be aware that all
>>unintential radiators (receivers) must be type accepted under part
>>15, and that includes amateur radio transceivers.
>
>Whilst not wishing to prolong this debate, Kenwood do provide end user
>firmware upgrades for their TS-2000 radio. This covers HF to UHF. So I
>suspect the issue as to whether firmware upgrades can be carried out by the
>end user is not a fundamental or legislative issue with them.
Good find Laurie.
If you notice my other thread, this confirms what I was saying. That it is a
urban legend that the FCC was preventing them, wholesale, from allow end
users to update the firmware. Now, do notice on the TS-2000 that it does not
cover anywhere near the cell phone bands, this is apparently how they got
around 15.121 with it. Even if the D700 has a poor design for end user
updates, I don't think they could have gotten around 15.121 since it has a
wideband receiver (however such is not the case on the TH-D7x). They would
have had to demonstrate to the FCC the synthizer could not be reprogrammed
for the cell phone bands. Easy when a rig only covers 2meters and 440, a bit
harder when it covers DC to light.
73
Jeff
----------------------------------------------------------------------
Subject: Re: APRS Urban Legend: FCC firmware upgrades, was Kenwood blah blah
From: "Mark Fellhauer" <sparkfel@qwest.net>
Date: Wed, 05 Mar 2003 10:40:30 -0600
X-Message-Number: 11
At 08:49 AM 3/5/2003, Ronald Reams wrote:
>Maybe some others will now know that ham
>transmitters do not go through the
>procedure
>formerly known as type acceptance.
>
>All devices that intentionally or unintentionally
>radiate RF have to have a Part 15 certification.
I don't know how you got on this jag, because regardless of whether type
acceptance is used or not, various governemnt agenicies (both U.S. and not)
can exert pressures that prevent transceivers (or receivers), and
especially tranceivers with broadband receivers from being easily modified
for out of band reception and transmission. Which means that to update
their firmware, the unit has to go back to the factory (either by design or
by government mandate). That issue can probably be circumvented these
days by current technology, but to do it takes forethought, planning, and
money. To pick on the D700 is this regard is unfair, because I have had
to send radios that were in production (and not made by Kenwood) around the
same time back to the factory for firmware upgrades/fixes.
As has been pointed out, Ten-Tec transceivers do no transmit or receive in
or around frequencies that have been deemed by ECPA to be protected, and
are therefore probably not subject to as much scrutiny.
And as I have pointed out, Government agencies can hold
people/companies/manufactures to a HIGHER standard than current law or
rulemaking dictates...especially if they've had compliance problems in the
past. I have worked for companies that have been under such agreements,
and corporations consider them highly private and confidential.
And I expect that the Homeland Security Law will add another layer of
oversight and unintended consequences to technology manufacturers...
73,
Mark
KC7BXS
Firmware Fun - The unintended consequences of easily updatable firmware:
http://forum.rpc1.org/portal.php
I have noticed that many makers of 802.11 hardware use common platforms
customized to the vendor. Open up a Linksys AP and a D-Link AP and you may
find they are electronically identical and the only difference in the two
(other than case design) is the firmware. The only think keeping one from
cross installing firmware is usually something small like a 2 digit
manufacturer's ID in the Bin file. Change that ID in the Bin (or modify a
lin or two in the installer's .ini file) and you can make your Linksys AP a
D-Link AP.
http://www.seattlewireless.net/index.cgi/Wap11Ver22Hack
My Afreey DVD player has patched Sampo firmware.
http://www.area450.com/
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
