Announcing Portable PREDICT Plus!

Announcing Portable PREDICT Plus!

[John Magliacane]

Announcing the release of Portable PREDICT Plus, a miniature
distribution of Linux that includes several ham radio and OSCAR
satellite communication applications.

Portable PREDICT Plus boots from a pair of floppy disks and runs
entirely in RAM.  There's no need to download huge CDROM images,
install Linux, compile code, configure a kernel, or re-partition
your hard disk to run this software.  A third "data disk" is used
to save configuration and home directory files, and can be used to
import Keplerian orbital data into the system during setup.

Portable PREDICT Plus includes PREDICT, PB/PG, FODtrack, PacsatTools,
MoonTracker, minicom, setserial, and a small collection of AX.25
applications and utilities including kisson, kissoff, kissattach,
kissparms, listen, mheard, call, and beacon.  There's even a program
included to play audio CDs.  :-)

Portable PREDICT Plus is based on a Linux kernel version 2.6.7,
and supports a total of eight "virtual consoles", providing
multiple login sessions that take full advantage of the multitasking
and co-operative nature of the operating system and many of the
included applications.

Portable PREDICT Plus is capable of supporting moonbounce, analog
and digital (Pacsat) satellite operations (including the new ECHO
satellite), satellite and terrestrial packet radio communications
(including ISS operations), as well as the generation of APRS-style
beacons.  Portable PREDICT Plus supports KISS and 6pack mode terminal
node controllers, and runs on 32-bit PCs from 386s on up.

Portable PREDICT Plus is available in two forms:  One that builds
the disk sets under Linux, and another that builds the disks under
a DOS/Windows environment.  The DOS/Windows version contains some extra
tutorial information to assist those new to a Linux computing environment.

Downloads are about 3 megabytes, and are available as follows:

Linux version:
        http://www.amsat.org/amsat/ftp/software/Linux/ppplus-0.90.tar.gz

DOS/Windows version:
        http://www.amsat.org/amsat/ftp/software/PC/tracking/pplus090.zip


Portable PREDICT Plus was created by John A. Magliacane, KD2BD, and is
released under the GNU General Public License.  Additional information
is available at:

        http://www.qsl.net/kd2bd/predict.html


73, de John, KD2BD



=====
Visit John on the Web at:

	http://www.qsl.net/kd2bd/


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Re: Announcing Portable PREDICT Plus!

[Tapio Sokura]

John Magliacane wrote:
> Portable PREDICT Plus boots from a pair of floppy disks and runs
> entirely in RAM.  There's no need to download huge CDROM images,

But what about small bootable CD-ROM images? In this day and age, floppy 
drives are getting rare, especially on laptops. I realize that updating 
the keplerian elements and storing the configuration would not be as 
easy or possible at all when using a CD (maybe a USB flash memory could 
be used?), but at least it would make a nice demo environment. I'm not 
saying that a customized floppy distribution is bad, on the contrary, I 
find it admirable that there are people that have knowledge as well as 
energy to develop these systems. And espcially write the documents (= 
instructions) !

   Tapio

Re: Announcing Portable PREDICT Plus!

[John Magliacane]

Hi Tapio.

--- Tapio Sokura <oh2kku@iki.fi> wrote:

> John Magliacane wrote:
> > Portable PREDICT Plus boots from a pair of floppy disks and runs
> > entirely in RAM.  There's no need to download huge CDROM images,

> But what about small bootable CD-ROM images?

I was referring to complete Linux distributions.

> In this day and age, floppy 
> drives are getting rare, especially on laptops. I realize that updating 
> the keplerian elements and storing the configuration would not be as 
> easy or possible at all when using a CD (maybe a USB flash memory could 
> be used?), but at least it would make a nice demo environment. I'm not 
> saying that a customized floppy distribution is bad, on the contrary, I 
> find it admirable that there are people that have knowledge as well as 
> energy to develop these systems. And espcially write the documents (= 
> instructions) !

I'm sure the concept can be applied to create a bootable CD-ROM, but I
have not yet tried doing that yet for a number of reasons, including
the fact that my old, trusty PC cannot boot from a CD.

Aside from that, a business card sized bootable CD would be pretty neat
for something small like this.  :-)


73, de John, KD2BD


=====
Visit John on the Web at:

	http://www.qsl.net/kd2bd/


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

Usermode Soundmodem

[Dave Stubbs]

Hello all,

Just to mention, I recently set up the usermode soundmodem on Linux 
2.6.6 and when configuring my kernel I noticed that a new option was 
available under the ALSA settings - OSS PCM (Digital Audio) API.  This 
basically gives a /dev/dsp device which plugs right into ALSA.  So far, 
the usermode soundmodem software is working really well with this setup, 
on a Soundblaster Live even.  Something worth trying?

73's
Dave
VA3BHF

Re: Usermode Soundmodem

[Andrea Borgia]

Dave Stubbs wrote:


> 2.6.6 and when configuring my kernel I noticed that a new option was 
> available under the ALSA settings - OSS PCM (Digital Audio) API.  This 
> basically gives a /dev/dsp device which plugs right into ALSA.  So far, 
> the usermode soundmodem software is working really well with this setup, 
> on a Soundblaster Live even.  Something worth trying?

If it works, by all means! In my case (laptop with onboard VIA chipset), 
the soundmodem was losing the beginning of each packet using Alsa's OSS 
emulation so I tried the newer soundmodem which has direct Alsa support. 
Unfortunately, that doesn't work either, but I gave up trying because 
packet really isn't that high on my todo list.

B73,
Andrea.

-- 
Homepage: http://andrea.borgia.bo.it     /    Amateur radio: IZ4FHT
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: Usermode Soundmodem

[Dave Platt]

Dave Stubbs <dave.stubbs@utoronto.ca> wrote:
> Hello all,
> 
> Just to mention, I recently set up the usermode soundmodem on Linux 
> 2.6.6 and when configuring my kernel I noticed that a new option was 
> available under the ALSA settings - OSS PCM (Digital Audio) API.  This 
> basically gives a /dev/dsp device which plugs right into ALSA.  So far, 
> the usermode soundmodem software is working really well with this setup, 
> on a Soundblaster Live even.  Something worth trying?

The OSS emulation seems to work well for the soundmodem on some systems, 
and not on others.  Similar issues appear to exist with certain other
sound-card ham software.

From what I can tell, the problem is one of rate conversion.  The OSS
plugin for ALSA attempts to provide/accept data at the sample rate
specified by the user-mode application.  If the system's sound card
cannot sample/play at a rate fairly close to what the application
requests, the ALSA plugin tries to rate-convert the samples.  This
conversion logic appears to have some rather major glitches in
quite a few cases - these result in zero-values samples appearing
in the buffers (at buffer boundaries, I suspect), and the resulting
crackling and noise plays merry hob with the digital radio modes.

The problem appears to be most apparent on systems whose sound
interfaces use an AC97 codec.  These codecs usually have only
a limited number of hardware-based audio rates available (e.g.
44100 and 48000 samples/second).  Some systems have hardware-based
sample rate converters in their audio chips, to convert between
the codec's rate(s) and the application data rate, but I think
that not all of the ALSA drivers are "aware" of this and can
take advantage of it.

The net result is that using the OSS emulation plugin, on a
system with an AC97 codec, often results in unacceptable
distortion of the audio signal and bad results in the digital-
mode ham software.

It's possible to "echo" a string into one of the ALSA
configuration entries in the /proc filesystem, after loading
the OSS emulation plugin, and turn off the sample rate conversion.
This will, I believe, cause the OSS emulator to restrict the
rates at which it will work (and which it reports to the application)
to those rates implemented by the native hardware.  An application
which can do its own rate conversion (or simply operate at
an arbitrary sample rate) will probably work better, in this
mode.

The newer "native" ALSA support in the soundmodem should also
provide a way around the poor sample-rate conversion in the
OSS plugin, as it bypasses this plugin entirely.

Re: Usermode Soundmodem

[Luc Langehegermann]

On Monday 26 July 2004 19:34, you wrote:
> Dave Stubbs <dave.stubbs@utoronto.ca> wrote:
> > Hello all,
> >
> > Just to mention, I recently set up the usermode soundmodem on Linux
> > 2.6.6 and when configuring my kernel I noticed that a new option was
> > available under the ALSA settings - OSS PCM (Digital Audio) API.  This
> > basically gives a /dev/dsp device which plugs right into ALSA.  So far,
> > the usermode soundmodem software is working really well with this setup,
> > on a Soundblaster Live even.  Something worth trying?
>
> The OSS emulation seems to work well for the soundmodem on some systems,
> and not on others.  Similar issues appear to exist with certain other
> sound-card ham software.
>
> From what I can tell, the problem is one of rate conversion.  The OSS
> plugin for ALSA attempts to provide/accept data at the sample rate
> specified by the user-mode application.  If the system's sound card
> cannot sample/play at a rate fairly close to what the application
> requests, the ALSA plugin tries to rate-convert the samples.  This
> conversion logic appears to have some rather major glitches in
> quite a few cases - these result in zero-values samples appearing
> in the buffers (at buffer boundaries, I suspect), and the resulting
> crackling and noise plays merry hob with the digital radio modes.
>
> The problem appears to be most apparent on systems whose sound
> interfaces use an AC97 codec.  These codecs usually have only
> a limited number of hardware-based audio rates available (e.g.
> 44100 and 48000 samples/second).  Some systems have hardware-based
> sample rate converters in their audio chips, to convert between
> the codec's rate(s) and the application data rate, but I think
> that not all of the ALSA drivers are "aware" of this and can
> take advantage of it.
>
> The net result is that using the OSS emulation plugin, on a
> system with an AC97 codec, often results in unacceptable
> distortion of the audio signal and bad results in the digital-
> mode ham software.
>
> It's possible to "echo" a string into one of the ALSA
> configuration entries in the /proc filesystem, after loading
> the OSS emulation plugin, and turn off the sample rate conversion.
> This will, I believe, cause the OSS emulator to restrict the
> rates at which it will work (and which it reports to the application)
> to those rates implemented by the native hardware.  An application
> which can do its own rate conversion (or simply operate at
> an arbitrary sample rate) will probably work better, in this
> mode.
>
> The newer "native" ALSA support in the soundmodem should also
> provide a way around the poor sample-rate conversion in the
> OSS plugin, as it bypasses this plugin entirely.
>

Well... that is only true for 'standart' soundcards.

You will not be able to use it with an card which has an ice1712 chip. 
Channels arent there defined per PCM devices, but you have one PCM device 
with 12 channels. 

soundmodem doesn't support that. Another problem is, you will only get 32 bit 
samples, so anyway have to use plughw (again plugins....)

I did an ugly hack, added an command line switch to the code, that lets you 
use an fixed sample rate. This workaround seems to work with my card, and OSS 
emulation. But only testet it with loopback from another soundcard, didn't 
yet get a chance to test it on the air.

If anyone is interested to try it out, I could send him the modified source.

73, Luc, LX2GT

> -
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Usermode Soundmodem

[Pierre-Philippe Coupard]

Andrea Borgia wrote:
> If it works, by all means! In my case (laptop with onboard VIA chipset), 
> the soundmodem was losing the beginning of each packet using Alsa's OSS

I think the source of your problem is contained in your statement: VIA
chipset. Almost all odd sound or timing problem reports I get for my
software can be traced back to a VIA, AC97, or I8x0 sound chip. It's
unfortunate that you're kind of stuck with it on a laptop...

73 de Pierre F8EJF

Re: Usermode Soundmodem

[pa3gcu]

On Monday 26 July 2004 21:33, Pierre-Philippe Coupard wrote:
> I think the source of your problem is contained in your statement: VIA
> chipset. Almost all odd sound or timing problem reports I get for my
> software can be traced back to a VIA, AC97, or I8x0 sound chip. It's
> unfortunate that you're kind of stuck with it on a laptop...

Uum!, on a laptop!!, not just a laptop i fear, one of the shops in our street 
sells more mobo's with VIA than anyother at the minute, its a question of 
price rather than thinking about what one wants, they see and hear in this 
case a computer with sound comming out of all cracks and crannys with windows 
supported software, unfortunatly some if not all of those boards have VIA 
chipsets, as soon as some unfortunate sole try's his brand spanking new 
computer with Linux he is confronted with all sorts of sound related problems 
due to chipset's spec's not being available to open source projects.

-- 
If the Linux community is a bunch of thieves because they
try to imitate windows programs, then the Windows community
is built on organized crime.

Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/

Re: Usermode Soundmodem

[Pierre-Philippe Coupard]

pa3gcu wrote:
--8<--8<--
>>software can be traced back to a VIA, AC97, or I8x0 sound chip. It's
>>unfortunate that you're kind of stuck with it on a laptop...
> 
> Uum!, on a laptop!!, not just a laptop i fear, one of the shops in our street 

Well yeah, what I meant was, with a desktop machine at least you have 
the option of installing something else. Matter of fact, I always buy 
at least one SB-Live! to install in any computer I get, regardless of 
whatever sound device is already inside. I figure $15 is pretty cheap 
for a decent soundcard that supports any sample rate and hardware 
mixing flawlessly, and if the original sound device works too, so much 
the better :-)

73 de Pierre F8EJF

Re: Usermode Soundmodem

[pa3gcu]

On Monday 26 July 2004 22:23, Pierre-Philippe Coupard wrote:
> pa3gcu wrote:
> --8<--8<--
>
> >>software can be traced back to a VIA, AC97, or I8x0 sound chip. It's
> >>unfortunate that you're kind of stuck with it on a laptop...
> >
> > Uum!, on a laptop!!, not just a laptop i fear, one of the shops in our
> > street
>
> Well yeah, what I meant was, with a desktop machine at least you have
> the option of installing something else. Matter of fact, I always buy
> at least one SB-Live! to install in any computer I get, regardless of
> whatever sound device is already inside. I figure $15 is pretty cheap
> for a decent soundcard that supports any sample rate and hardware
> mixing flawlessly, and if the original sound device works too, so much
> the better :-)

How correct you are, but most mobo's have 5 pci slots, i need one for my DVB-s 
card, one for a HTP37X IDE/RAID card, one for my SCSI adapter, one for my 2nd 
ethernet card, one for my DXR3 MPEG card, i always ask too much from a 
computer, but you are correct, normally speaking a seperate card is the 
answer.

73 .. 

> 73 de Pierre F8EJF

-- 
If the Linux community is a bunch of thieves because they
try to imitate windows programs, then the Windows community
is built on organized crime.

Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/

Re: Usermode Soundmodem

[Andrea Borgia]

Pierre-Philippe Coupard wrote:


> I think the source of your problem is contained in your statement: VIA
> chipset. Almost all odd sound or timing problem reports I get for my
> software can be traced back to a VIA, AC97, or I8x0 sound chip. It's

What it your software? I might try it just to see how it fares. By the 
way, gMFSK works flawlessly on this same laptop using Alsa's OSS emulation.

I would like to solve this problem just because I like fixing things, 
not because I really need the soundmodem to work: I can reach my own 
dxcluster node by telnet much more conveniently and reliably than over 
the air.

B73,
Andrea.

-- 
Homepage: http://andrea.borgia.bo.it     /    Amateur radio: IZ4FHT
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: Usermode Soundmodem

[Pierre-Philippe Coupard]

Andrea Borgia wrote:
> What it your software? I might try it just to see how it fares.

It's CWirc (http://webperso.easyconnect.fr/om.the/web/cwirc/). The 
reason it tends to reveal problems with sound devices is because it 
requires very low latency from them, because latency is quite an issue 
with fast CW'ers, and also because it derives its timing from the 
sound card. As a result, bad sound devices that are okay, or at least 
passable with less demanding programs, may create a number of problems 
with CWirc, most notably sound scratchiness, and strange sync issues 
with gMFSK when the latter is used in CWirc-slave mode. Those problems 
never happen with sound devices other than the ones I cited.

> By the way, gMFSK works flawlessly on this same laptop using Alsa's OSS emulation.

gMFSK has lesser sound buffer size and fragment size requirements than 
CWirc.

> I would like to solve this problem just because I like fixing things, 
> not because I really need the soundmodem to work: I can reach my own 
> dxcluster node by telnet much more conveniently and reliably than over 
> the air.

The problem is in the sound hardware that puts too much burden on the 
driver side to compensate for the chip's cheesiness. It's a typical 
"winmodem" approach to hardware engineering: make the cheapest 
hardware possible and let the driver compensate, at the expense of CPU 
usage and performance.

CWirc already has provisions to alleviate the problem somewhat, by 
installing it suid root so it can renice itself, and if you really 
have to, you can recompile it with a larger sound buffer size, but it 
makes the audio latency unacceptable for high-speed operators. Already 
  as it is, there's a 30ms delay between the moment you press the 
paddle and the moment you hear the beep, and that's enough to make 
keying over 25 wpm significantly harder than with a real transceiver.

73 QRO, Pierre F8EJF