headers
Edward R. Cole | 1 Dec 04:03

Re: Linrad and JT65

At 10:16 AM 11/30/2006 -0500, Joe Taylor wrote:
>
>Several weeks ago I mentioned on this reflector that I was 
>thinking about ways to better integrate the combined use of 
>Linrad and WSJT.  I write now to bring you up to date on my 
>progress.

Joe,
----------------------------------------------------------------------------
-------
You never cease to amaze.

This is an interesting "collision of coincidences" as I have just recently
downloaded the windows vers. of Linrad to "study".  I have reserved one of
the new RFSpace SDR-IQ boards which I hope to have in a couple months.
Using it with Linrad was my prime goal...now you have gone and merged it
with JT65...PERFECT!  If the SDR-IQ works out well, I will consider running
two of them on my four 2MXP20's.  I will have to build a second matched LNA
for this.

I guess a question would be if you have only developed this for the Linux
version?  Diving into Linux at this point is more stuff than I want to try
on.  Learning Linrad and the settings of the new SDR will be enough.

Since the SDR tunes 500-Hz to 30-MHz, I have bought a low-power xvtr from
DEMI (model 144/28K).  This will run my 2m and 23cm eme, as well as, all my
microwave xvtrs since they all use an IF of 144.

The SR-IQ (like its predecssor the SDR-14) send the data-stream via the
USB-2.0 port.  Linrad has a driver for this.  I wonder if you see any
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edward R. Cole | 1 Dec 08:39

Re: Linrad and JT65

Joe,

At 10:16 AM 11/30/2006 -0500, you wrote:
---snipped---
>When a full minute of data is available, MAP65 scans the 
>full 90 kHz (or any designated portion) looking for JT65 
>signals, which are easily recognized by the software because 
>of the known pseudo-random pattern of their sync tones.  For 
>each detected JT65 signal, the program "peaks up" to find 
>the best-fit values of frequency, time delay DT, and linear 
>polarization angle.  It then decodes the received message. 
>The results are displayed in the form of a "band map" that 
>looks something like the following (based on a particular 
>segment of recorded data that I have been using for tests):
>
>   Freq    DF   DT   UTC Seq   Message                KV  DS
>-----------------------------------------------------------
>144.114   -4  2.6  1753  2 #  WA4EWV RK3FG KO86  OOO  1   0
>144.127  340  2.7  1753  2 *  CQ KB8RQ EM79           1  10
>144.129  204  2.7  1753  2 *  QRZ W5UN EM23           1   0
>144.131  234  2.6  1754  1 *  CQ S52LM JN65           1  10
>144.133 -281  2.7  1754  1 *  CQ 9H1TX JM75           1  10
>144.145  -14  0.3  1753  2 *  OK1TEH K5GMX FN31       1   0
>144.147 -250  2.7  1754  1 *  CQ EA2AGZ IN91          1  10

I would like display of the peak polarity angle received as my Tx pol is
discrete: H/V and this would help in prediction of best Tx pol.  I have
separate RX and Tx polarity selection.  Perhaps Linrad does this
already...just begining using Linrad.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Taylor | 1 Dec 15:50
Picon
Favicon

Re: Linrad and JT65

Many thanks to all who have responded both on- and off-list 
to my posting about MAP65.  I will answer here a few 
questions that came up in those responses.

1. So far, MAP65 has been developed and and tested in Linux 
only.  It should be easy to make it run in Windows, however. 
  If the program goes beyond the status of being an 
interesting plaything for my own use, I will try to make 
both Linux and Windows versions available.

2. WSE converters are not required.  The source of Linrad's 
input data could be an SDR-14, a homemade I-Q mixer, or 
whatever else you have.  Any running Linrad system can be 
patched and recompiled so as to send the required data to MAP65.

3. As I understand things, I do not think that a pair of 
SDR-14's (or the new version that Pieter Ibelings has 
announced) can be used to make a fully functioning dual 
polarization system.  You could have pure H and pure V, but 
other combinations would require modifications to ensure 
simultaneous sampling of the two polarization channels.  (If 
I'm wrong about this, someone please correct me!)

4. MAP65 determines the polarization angle of a received 
JT65 signal and matches it optimally when decoding.  If the 
locator of the transmitting station is known (normally it is 
included following the callsign in a JT65 transmission) then 
the program can compute the optimum Tx polarization. 
(Linrad does this already, if you tell it the transmitting 
station's locator.)  I plan to have MAP65 display "V" if the
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ramiro Aceves | 5 Dec 12:03
Picon

Re: Multicasting

Leif Asbrink escribió:
> On Thu, 9 Nov 2006 00:45:04 +0100
> "J.D. Bakker" <jdb@...> wrote:
> 
> Thanks. The immediate problem that pops up is here:
> In order to play with multicast, 
> your GNU/Linux box needs special configuration. 
> 
> Recompiling the kernel is no longer an easy thing.
> Nowadays it is even difficult to compile kernel modules
> since modern distributions do not contain the necessary files.
> One can sometimes download the source code from the Internet,
> but then it will be the latest kernel with a possibillity
> to choose from a couple of older ones, but it will not
> be possible to download the really old one from which
> the kernel of the distribution was built.
> 
> It seems that before considering multicasting I need to
> verify that modern Linux distributions are compiled
> with the necessary options enabled. How do I find out?

Hello Leif,

I am not sure whether I understand what you mean. For example, in Debian 
systems, you can see what it is compiled into the debian standar kernels 
or as modules in the /boot/config-2.x.x-x-xxx file. Sorry if I missed 
something and you did not ask that.

For example:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Leif Asbrink | 5 Dec 14:14

Re: Multicasting

Hello Ramiro,

The problem is soloved. I have checked several modern 
and not so modern kernels and they all have multicasting 
enabled:-)

(The site where I found that the first step was to 
recompile the kernel must have been pretty old....)

ON4IY has kindly sent prototype routines. It looks
really easy but I have not yet have had time to try
them. 

73

Leif / SM5BSZ

> > It seems that before considering multicasting I need to
> > verify that modern Linux distributions are compiled
> > with the necessary options enabled. How do I find out?
> 
> Hello Leif,
> 
> I am not sure whether I understand what you mean. For example, in Debian 
> systems, you can see what it is compiled into the debian standar kernels 
> or as modules in the /boot/config-2.x.x-x-xxx file. Sorry if I missed 
> something and you did not ask that.
> 
> For example:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ramiro Aceves | 5 Dec 16:13
Picon

Re: Multicasting

Leif Asbrink escribió:
> Hello Ramiro,
> 
> The problem is soloved. I have checked several modern 
> and not so modern kernels and they all have multicasting 
> enabled:-)

Good news!

> 
> (The site where I found that the first step was to 
> recompile the kernel must have been pretty old....)

Yes, there are too many old HOWTOS and obsolete stuff flying around in 
the Internet  :-)

> 
> ON4IY has kindly sent prototype routines. It looks
> really easy but I have not yet have had time to try
> them. 

Ok Leif, thank you very much and good luck.

73, Ramiro.

> 
> 73
> 
> Leif / SM5BSZ
(Continue reading)

Permalink | Reply | 10 comments |
headers
Leif Asbrink | 8 Dec 22:57

Multicasting addresses

Hi All,

Multicasting seems straightforward. The simple routines
kindly sent by ON4IY work well inside Linrad for sending
small amounts of test data. Data can be received (simultaneously)
on any computer on the network running Linrad including
a second instance of Linrad running on the same computer.

Presumably it will work perfectly well at the full data rate
of current hardwares. 24 x 2 x 96000 bit/s = 4.6 megabit/s
should be no problem for networks rated at 100 megabit:-)

Now I have a few questions before proceeding.

1) Multicasting group.
Is there any reason to make this parameter something
that the Linrad user should set himself? It will
be much easier just to use a define like this:
#define NET_MULTICAST_GROUP "225.0.0.37"
(Placed in options.h)

Having it as a parameter in the setup (stored in the
par_network file) would add the complication that the
user has to set the same value for the computers and
Linrad instances that should share input.

Is there a reason to use something else rather than 
225.0.0.37 or do you see a good reason to make it a 
user parameter?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Taylor | 9 Dec 15:26
Picon
Favicon

Re: Multicasting addresses

Hi Leif,

Thanks for your efforts toward building data-sharing capabilities into 
Linrad once again.  A few comments on the points you raised:

1,2: Multicasting group and port assignments.

Your proposals sound fine to me, but I have no experience in network 
programming.  Perhaps others with more knowledge can comment.

3. Calibration.

Again your ideas sound OK.  As far as I can see, you could make it even 
simpler by just requiring the user to copy the calibration files onto 
any downstream computer(s) before starting Linrad there.  Ordinarily, 
this would need to be done only once, right?

Block structure.

I agree that block headers with block number and hardware center 
frequency would be good.  I suggest adding a time-stamp, as well.  This 
could be the output of gettimeofday(), or simply a double expressing the 
time since the epoch (Jan 0, 1970?) in seconds.

	-- 73, Joe, K1JT

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@...>.
To unsubscribe, E-mail to: <linrad-off@...>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christophe Huygens | 9 Dec 15:48
Picon
Picon

Re: Multicasting addresses

Hello Leif, Joe, et al.

I am reposting this using gmane.com.radio.linrad since
my other message did not get through.

73 xtof on4iy

--
For the rulebook on address assigment, see
http://www.iana.org/assignments/multicast-addresses.

Regarding the use of fixed address and port numbers. The question
is, do we want to keep compatibility with the existing multicast
capable network MBONE that is an overlay on the current IPv4 net.
If you want to retain compatibility with that net you need to
dynamically request a session address/port and advertise is in
the "multicast directory" that has by itself a group address,
using the service annoucement protocol.
(for those interested in the current MBONE, see Mantra
http://www.caida.org/tools/measurement/Mantra/topology/topology.html)

My feelings is with current state of Linrad technology and
the bandwidth required we will exclusively use this on the
LAN, or within locally closed user environments. In that case
it is good practice to use locally scoped multicast address
space as per RFC2365 (just like our local 192.168. IPv4 addresses).
This range is 239.255.0.0/16.

I think there will be novel uses of Linrad that could do
with a global multicast address for example, decoded audio or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Leif Asbrink | 10 Dec 02:02

Re: Multicasting addresses

Hi xtof and all,

> For the rulebook on address assigment, see
> http://www.iana.org/assignments/multicast-addresses.
Hmmm,
"Addresses within the 232.0.1.0-232.255.255.255 are dynamically 
allocated by hosts when needed [RFC4607]"

Does this mean that 232.144.144.X
with X=0 to 255 could be a good choice for Linrad?
(easy management of an integer 0-255 in a par file)

> Regarding the use of fixed address and port numbers. The question
> is, do we want to keep compatibility with the existing multicast
> capable network MBONE that is an overlay on the current IPv4 net.
> If you want to retain compatibility with that net you need to
> dynamically request a session address/port and advertise is in
> the "multicast directory" that has by itself a group address,
> using the service annoucement protocol.
> (for those interested in the current MBONE, see Mantra
> http://www.caida.org/tools/measurement/Mantra/topology/topology.html)
Sorry, I do not understand anything of this:-(

> My feelings is with current state of Linrad technology and
> the bandwidth required we will exclusively use this on the
> LAN, or within locally closed user environments. In that case
> it is good practice to use locally scoped multicast address
> space as per RFC2365 (just like our local 192.168. IPv4 addresses).
> This range is 239.255.0.0/16.
So you say Linrad should use 239.255.0.X with X=0 to 16.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane