| |
ZL3AI > APRDIG 22.09.06 00:33l 223 Lines 9746 Bytes #999 (0) @ WW
BID : 8795-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 27 #19, 2/6
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<TU5EX<I0TVL<CX2SA<CE8FGC<VK6HGR<
ZL2BAU
Sent: 060921/2210Z @:ZL2BAU.#87.NZL.OC #:5682 [Waimate] $:8795-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Message: 5
Date: Mon, 18 Sep 2006 12:42:18 -0500
From: "John Habbinga" <kc5zrq_at_gmail.com>
Subject: Re: [aprssig] APRS Link
>But D-Star is just "TCP" so why would you need APRSlink instead of
>Outlook, Airmail or Paclink. It would be a good "You've got mail" tool.
DStarInterface is an adjunct to javAPRSSrvr and it works as an Internet
gateway by converting D-STAR GPS position reports to the APRS format and
sending it to the APRS-IS.
DStarTNC2 is software that runs on my laptop which, like DStarInterface,
converts D-STAR GPS position reports into the APRS format and allows me to
use UI-View32 to view the data, just like as if it was APRS.
I also have the advantage of using a single frequency for both APRS and
Voice simultaneously.
--
John Habbinga, KC5ZRQ
Lubbock, Texas
http://find-you.com/cgi-bin/find.cgi?call=KC5ZRQ-6
------------------------------
Message: 6
Date: Mon, 18 Sep 2006 13:13:44 -0500 (CDT)
From: wa7nwp_at_jnos.org
Subject: Re: [aprssig] APRS Link
>>But D-Star is just "TCP" so why would you need APRSlink instead of
>>Outlook, Airmail or Paclink. It would be a good "You've got mail"
>>tool.
>
>DStarInterface is an adjunct to javAPRSSrvr and it works as an
>Internet gateway by converting D-STAR GPS position reports to the APRS
>format and sending it to the APRS-IS.
>
>DStarTNC2 is software that runs on my laptop which, like
>DStarInterface, converts D-STAR GPS position reports into the APRS
>format and allows me to use UI-View32 to view the data, just like as
>if it was APRS.
>
>I also have the advantage of using a single frequency for both APRS
>and Voice simultaneously.
Right - but it's a TCP connection with DSTAR back to the APRS-IS.. right?
Or are you using the low speed DSTAR system and these are aprs packets
piggybacking on the voice channel? So it's not an ID1?
Bill
------------------------------
Message: 7
Date: Mon, 18 Sep 2006 13:16:08 -0500
From: "John Habbinga" <kc5zrq_at_gmail.com>
Subject: [aprssig] APRS over D-STAR (was APRS Link)
Here is a screenshot of UI-View32 monitoring APRS over D-STAR which is
being transmitted in Lubbock on 145.670 MHz.
http://members.cox.net/d-star/dstar-uiview.png
You might notice that it appears that UI-View32 is connected to the
Internet. It is not. It is connected to DStarTNC2 (127.0.0.1:14551) which
is running on my notebook computer.
The DStarInterface, or the Internet gateway, is in a tall building in
central Lubbock. Since there is not a whole lot of APRS activity in
Lubbock I have configured the filter to pass traffic from any APRS station
located in the area served by the Lubbock office of the National Weather
Service, all of Dallas County, Texas, and all D-STAR GPS position reports
worldwide. Postion reports from APRS digipeaters are filtered out since
there is no purpose for a D-STAR user to know that information.
This configuration results in a transmission rate of about 1 or 2 times per
minute.
So you can see that even in what is normally a congested APRS environment,
the same amount of information is passed with D-STAR with much less
bandwidth (time). There is also the advantage that voice communcations can
take place on the same frequency with very little chance of interference.
--
John Habbinga, KC5ZRQ
Lubbock, Texas
http://find-you.com/cgi-bin/find.cgi?call=KC5ZRQ-6
------------------------------
Message: 8
Date: Mon, 18 Sep 2006 13:18:09 -0500
From: "John Habbinga" <kc5zrq_at_gmail.com>
Subject: Re: [aprssig] APRS Link
>Right - but it's a TCP connection with DSTAR back to the APRS-IS.. right?
>Or are you using the low speed DSTAR system and these are aprs packets
>piggybacking on the voice channel? So it's not an ID1?
I'm using Low-Speed data on 145.670 MHz. The high-speed data of the ID1
would not be practical for the way that I'm using D-STAR for GPS position
reporting and APRS over D-STAR.
See my other posting titled APRS over DSTAR.
--
John Habbinga, KC5ZRQ
Lubbock, Texas
http://find-you.com/cgi-bin/find.cgi?call=KC5ZRQ*
------------------------------
Message: 9
Date: Mon, 18 Sep 2006 11:40:21 -0700
From: Jim Lux <jimlux_at_earthlink.net>
Subject: [aprssig] followup on Rant about cross platform
I respect Gregg's enthusiasm for Java, his software development experience,
and his philosophical desire for wider universality of software generated
by and for hams. I readily concede that he has orders of magnitude more
experience with Java than I do, but that's really the point. Most hams
developing software are more like me than Gregg, and that drives the
selection of development environment.
The idea I was trying to develop was that people developing software for
love (which is the vast majority, if not all, of amateur radio software)
have to make decisions about how to allocate their scarce resources. The
easy decision (because developers for love tend to want to minimize the
work making their baby) is to work in what you know, and, statistically,
that's not likely to be Java (no matter how wonderful it may or may not
be).
When you talk of DSP code (e.g. the example Gregg gave of a PSK31 engine,
or some other modem implementation), the likely coder is someone who is
almost certainly not from the Java world, if only because Java isn't
particularly popular for these applications, especially in an embedded
environment. While there are high performance Java implementations on the
PC platform, the same is probably not true for, say, TMS320, SHARC, or even
various 8 bit MCUs that have been pressed into service for DSP applications
over the years. A cursory google for "Java DSP" turns up lots of little
demo applications to show how various DSP algorithms work, and a fair
amount of stuff on how you can use Java to effectively glue together native
code DSP functions.
This is not to say that you couldn't write hard-real-time DSP code in Java
(Ii suspect you could, with sufficient resources), but rather that, most
likely, the code base they would be starting from is more likely to be in
ASM or C. There is a lot of work involved in writing modem code,
especially to handle all the corner cases and deal with the idiosyncracies
of the surrounding environment, while still giving good performance, and
most people start with something that they know works somewhere, and then
modify it for the new platform. As they say, old habits die hard.
I'll also comment that in many of the DSP projects I've been involved in,
the non-determinism of timing in standard Java would make it an
out-of-the-gate non-starter, even if it were available for the target
processor. Sure, one could probably come up with a custom implementation
of the JVM/JRE with appropriate determinism, hooks to the hardware, etc.,
but then, you're not in the "write once, run everywhere" model anymore. I
readily confess that I know next to nothing about how one might even start
doing this in Java. I understand that there are efforts being made to
create a "real-time Java", but, it's nowhere near as mature as the existing
body of knowledge in Asm or C (better the devil you know, etc.). But this
gets back to the point about people tend to want to work in the environment
they are familiar with, which, statistically, is not Java.
So, it's a pretty bold request to ask a volunteer to take on not only
coding/porting up some sort of modem (a non-trivial task in itself, but one
that is small enough to be done in a reasonable time ), but also to ask
that they learn a whole new computing environment, with just as many
idiosyncracies as, say, Windows. You'd probably have to show that the new
environment provides some really useful functionality (to the volunteer)
that they currently don't have available, or that is a pain to get. That
is, it will make their job noticeably easier if they adopt, for example,
Java. An appeal to an abstract altruism: "it will help society in the
future" is a much harder sell. It's true you've at least got them
volunteering in the first place, so it's not a totally lost cause. There's
a similar discussion going on in the SDR-1000 world about the adoption of a
language called Erlang.
Gosh, people are still developing applications for ham radio that are based
on MS-DOS, and probably modified from code originally written for a Z80
running CP/M. In that context, Java is just a young stripling with a lot
of growing left to do. And, I see ham radio software moving towards a more
"componentized" implementation, with cleaner interfaces among components.
I really shouldn't care what langauge the PSK engine is written in, as long
as it's available for my platform and it has the right hooks to make it
work.
Jim Lux, W6RMK
------------------------------
Message: 10
Date: Mon, 18 Sep 2006 15:02:15 -0400
From: Brian Riley <brianbr_at_mac.com>
Subject: Re: [aprssig] Rant - Cross platform portability
"Legacy" PPC code runs under a 'sortof' emulation on an Intel Mac called
"Rosetta"... I say 'sortof' emulation because it isn't emulation in the
conventional sense we were used to say in VirtualPC running Windows on a
Mac_PPC. Rosettta appears to run PPC code on an Intel Mac very quickly. (I
have he entire MS Office 2004Suite as well as the entire Adobe CS2 all in
PPC code running on my MacBookPro with 2GHZ Code Duo and they ran as fast
or faster than they do on my 1.8 GHz iMac G5 (both machines have 2GB RAM).
If this copy of Starry Night is relatively recent it is likely the Mac
installer is a "Universal Binary," meaning that it has two forks one with a
PPC binary and one with an Intel binary and the loader selects the correct
fork.
---
cheers... 73 de brian riley, n1bq, underhill center, vermont
------------------------------
Read previous mail | Read next mail
| |
