[linrad] Re: MAP65 compiling
Hi Alberto and all, Alberto E. Zagni (I2KBD) wrote: I have just a couple of questions about current MAP65 compiling status: - Is MAP65 currently only working on Windows platform? MAP65 runs under Windows and Linux. A packaged executable (version 0.8, r502) is available on the WSJT Home Page for Windows. You must compile it yourself for Linux, from the source code. - Did you cross compile MAP65.EXE under Linux or directly on Win? I compile the Windows executable under Windows. My development setup uses the Microsoft VC6 and Compaq Visual Fortran compilers on Windows. These compilers are somewhat dated and not widely available, and it would be good to convert to using the GNU compilers, either directly on Windows or cross-compiling under Linux. I have not yet done this. - What's your plan for a (beta) release of source code to play with? The MAP65 source code has been freely available for nearly a year, as the program develops. It is located in the same Berlios repository as WSJT. The easiest was to download the full source code for MAP65 is to install the program Subversion and then type svn co https://svn.berlios.de/svnroot/repos/wsjt/branches/map65 at a command prompt. After some work, with help from Roger W3SZ I have been successful to compile WSJT598 on Ubuntu 7.10 and I would like to do the same for MAP65, since I am planning to make some experiments on 6m JT65a. You should know that the present MAP65 code uses only the JT65B mode. Just for your knowledge, next month the Ciao Radio H102 direct sampling receiver with dual parallel input should be available, and I am curious to see if it can be used for dual polarization EME work. This sounds interesting! -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Paper on MAP65
A paper on the MAP65 program has been placed on the Documentation page of the WSJT web site. A direct link to the paper is: http://physics.princeton.edu/pulsar/K1JT/MAP65.pdf -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Got Them EME Window / call3.txt Blues Again
Roger -- My guess is that you may simply need to change the call3.txt file from DOS format to *nix format, i.e., C: dos2unix call3.txt You can do the conversion in Linux, if your Windows installation does not have the dos2unix utility. This is only a guess ... See you at MUD (Microwave Update) tomorrow! -- 73, Joe, K1JT Roger Rehr wrote: Hello, All, I am trying to set up the EME Window on Linrad for Windows and having difficulty. I have re-discovered the following: 1. Linrad wants the emedirectory to be C:\emedir, NOT \home\emedir or C:\home\emedir as in Linux [not documented that I can see]. 2. dir.skd is no longer available on the net. At least I couldn't find it. Even af9y's links for it are broken. 3. If call3.txt is either copied from a wsjt download or downloaded from http://www.bigskyspaces.com/w7gj/tracker.htm and placed in the emedir, Linrad rejects it with the error: [1230]routine:init_eme_database file:eme.c Failed to read CALL3.TXT Excessive line length or field too long. 4. The reference page http://www.sm5bsz.com/linuxdsp/run/emewin.htm makes no mention of the fact that linrad may potentially use call3.txt, but only mentions the now essentially defunct dir.skd, eme.dta, and allcalls.dta files. I thought I remembered that as a result of a previous posting linrad would work with call3.txt, but was stymied by #4 above. I am very suspicious that all of this is old information and that I am having a major deja vu experience, but figured I would send this to the list after Google failed to give me what I need ;) All of this came about as I was preparing to give a lecture and 'how to' session on Linrad tomorrow. I guess I'll skip the eme window, at least from Windows ;) [Yes I have everything working from Linux including the EME Window] 73, W3SZ Roger Rehr http://www.nitehawk.com/w3sz Roger Rehr W3SZ http://www.nitehawk.com/w3sz # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: MAP65 Experiment
Hi Joe and all, Sorry to be a bit slow in responding. I have been traveling since last week, and it seems that you have largely answered your own question. The polarization-matching capabilities of the Linrad-MAP65 combination depend on having a two-channel receiver. Any mixing in the Rx chain must be done using the same local oscillator in both channels, so as to maintain phase properly. Single-channel systems like the SDR-1000, SDR-14, and SDR-IQ can't satisfy this requirement. (Of course, they still make excellent single-channel receivers, and can provide all of the MAP65 capabilities except polarization-matching.) Leif has some examples of relatively simple and inexpensive down-converters on his web site. Something like a pair of Soft-Rock boards would also do the job well, if modified so that the mixers on two boards are driven by the same LO. -- 73, Joe, K1JT Joe Barger wrote: After reading the Polarization question thread that Joe started, reviewing the WSE architecture, and thinking about the problem more, my quick and dirty approach to getting linrad/MAP65 with polarization probably won't work. Calibration using Dphi may compensate for initial phase errors between the two RX channels, but the phase errors introduced by the SDR-1000 (and transverter) LOs drifting at different rates would quickly degrade performance. Using the same (low phase noise, etc.) clock for each conversion stage appears necessary to preserve phase information. Probably obvious to those who have thought about this for more than a microsecond, but ... WSE is really nice solution, but with one kid in college and another close behind, it's a bit out of my price range at the moment. There's an external 10 MHz frequency input for the SDR-1000 so both SDR-1000s can be run from the same frequency reference, but I'll have to investigate potential transverter/down-converter solutions. What hardware are others using to solve the problem? joe n6kk - Original Message - From: Joe Barger [EMAIL PROTECTED] To: Linrad mailinglist linrad@antennspecialisten.se Sent: Thursday, July 26, 2007 3:51 PM Subject: [linrad] MAP65 Experiment I'm thinking about how to easily adapt my EME station to take advantage of MAP65, initially receive only. The receive side my station consists of two phased yagis, preamp, Elecraft 144 transverter, and SDR-1000. I'm considering removing the power splitter, rotating one of the yagis 90 degrees and duplicating the receive components to have duplicate H and V RX paths. My main questions involve how closely the two RX paths must match in amplitude, phase and frequency. Amplitude I can probably adjust reasonably well in the SDR-1000, and I can probably adjust the RX frequency in both SDR-1000s to initially be pretty close, but the SDR-1000s are not locked to the same LO so they will drift apart after some period of time. In addition, the relative phasing will be unknown and probably also change over time. Hopefully amplitude will remain fairly stable. I think Dphi will compensate for initial phase errors between the channels, but how sensitive is the system to drift between the two SDR-1000 LOs (and corresponding phase and frequency errors)? I think the SDR-1000s (and transverters) will stay within a couple hundred hertz of each other for a reasonable period of time, but if the relative frequency and phase in the two channels must stay locked to within a few hertz/degrees then I think there is no hope with this approach. I'll probably just have to wait for a couple of the HPSDR Mercury boards ... or buy another SDR-IQ (if the LOs can be locked ... I don't remember if they can). If this hardware approach works, the next issue will be how to get two instances of PowerSDR, one linrad and one MAP65 all working happily on the computer resources I have ... Thanks joe n6kk # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the
[linrad] SDR-IQ and Linrad
Hi Dave, Dave Blaschke wrote: K1JT wrote: In principle, any hardware that can be made to work with Linrad should also be usable with the Linrad-MAP65 combination. At present this is true only if the sampling rate can be set to 96.000 kHz (four channels, two I-Q pairs) or 192.000 kHz (two channels). If you want to try MAP65 and don't have xpol, a simple way to get started would be to put nothing into the Y channel (or perhaps put the X signal into both X and Y inputs). I have tried this in my station and it works -- although of course no polarization information is produced for the received signals. The SDR-IQ can provide effective I-Q sampling rates of 55.555, 111.111, 158.730, and 196.078 kHz for a single polarization. For some reason my post to Linrad mailinglist linrad@antennspecialisten.se is bouncing. I'm using SDR-IQ. Is it a certainty that the SDR-IQ cannot handle sampling rate values outside those shown above; such as the 96.000 kHz required by MAP65? I would like to test this. (Or am I misunderstanding the requirements?) I don't have an SDR-IQ or any of its documentation, but as I understand it the A/D sampling rate is fixed at 66.667 MHz. Resampling and decimation is then done in a specialized chip (by Analog Devices, I think). I imagine this means that only certain output sampling rates are possible -- ones related to 66.667 MHz by the ratio of small integers. Perhaps someone else with better knowledge of the SDR-IQ can correct me, or otherwise elaborate. I can see how to set the sound output sampling rate under Linrad to 96.000 kHz, but how does one manually set the sound input sampling rate to this value? Or is a pre-programmed value chosen by Linrad whenever SDR-IQ is selected as the input device during setup? When you use the SDR-IQ with Linrad you don't need a Delta44 or any other soundcard for input. A/D conversion takes place in the SDR-IQ, so the input sampling rate is determined there. As I mentioned above, the SDR-IQ also does decimation to provide a smaller bandwidth (190 kHz or less) at its output. The output from SDR-IQ (input to Linrad) is digital, not analog. My second question: Has a revised version of Linrad been released that will detect the SDR-IQ under Linux? I am currrently running the Windows version. I expect Leif will correct me when he returns home, if I am wrong about this. I believe the most recent version of Linrad (both Windows and Linux) can always be found at the bottom of this page http://www.sm5bsz.com/linuxdsp/linroot.htm along with a brief description of changes from previous versions. The most recent (stable, released) version can be found on the Linrad Home Page: http://www.nitehawk.com/sm5bsz/linuxdsp/linrad.htm -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Testing MAP65 v0.8
Rick and all, Well, it seems I'm learning more about computer networking than I ever wanted to know... ;-) Why did you use a mask of 224.0.0.0 instead of 240.0.0.0 in your multicast route statement on the Linux box? (Your: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 statement.) My mistake when typing it into the email message. I had it right when the tests were made. Unfortunately neither of the switches you tested with had the horsepower (i.e. were managed switches) to control the multicast traffic, though they will segment the unicast traffic. Yes, this is exactly what I discovered. You asked some more good questions, and I will follow up on them soon. In the meantime, I've realized that there is really no reason to use multicasting for the Linrad -- MAP65 connection. I could just as well unicast the UDP data stream between the two machines, using a crossover cable and explicit private-LAN (192.168.x.x) addresses on each end, and have none of the problems I've been worrying about. This solution causes the data go where I want it to go, and nowhere else. The other option that I'm beginning to think very attractive is running both Linrad and MAP65 in a single machine. TIMF2 data could go from Linrad to MAP65 over the loopback (lo) interface -- or by way of shared memory, or ??? -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Testing MAP65 v0.8
Rick -- Thanks for the suggestions, they are much appreciated. I have been tied up since yesterday afternoon, but hope to find time to try them out soon ... maybe even later today. I will report back here on any success or failure. -- 73, Joe, K1JT Rick Kunath wrote: Joe Taylor wrote: My earlier problem with dropped multicast packets seems to be fixed in MAP65 v0.8. However, when running the Linrad-MAP65 combination on two separate computers I still have some network-related problems. Perhaps someone on this list who knows much more than I about networking can help. My computer network looks like this: ADSL 10 Mb/s -- Computer_A DSL -- Modem -- Ethernet -- Computer_B Hub| -- Computer_C Three computers are connected to a 10 Mb/s Ethernet Hub. Have you considered replacing the hub with a 100 Mbps full-duplex Ethernet switch? There are many advantages in this over a hub. Computer_A is my XYL's machine. Computer_B runs Windows 2000 Pro, and Computer_C runs Linux (presently the Kubuntu 6.06 distribution). In addition to the connections of all three machines to the hub, a crossover cable makes a direct 100 Mb/s connection between computers B and C. The ethernet interfaces on B and C appear to be configured correctly. On Linux they appear as eth0 and eth1 (occasionally they boot up as eth0 and eth2, I don't know why???). This is configurable, generally, and should be fixed if you intend to use interface based static routes. Check here for more info on iftab (/etc/iftab): http://linux.die.net/man/5/iftab Connections to the Hub are assigned dynamic IP addresses; I assume these addresses are in the 192.168.1.x range? I assigned hard-coded addresses 192.168.10.12 and 192.168.10.13 for the direct inter-machine connection between B and C. I can use the 100 Mb/s direct line for many purposes. I can ping over it in either direction; I can ssh into Linux from Windows; I can use Cygwin/X (as described above) to display Linux X programs on the Windows screen. However, I cannot seem to persuade Windows 2000 Pro to accept multicast packets over the direct line. When I run Linrad on computer C and MAP65 on B, the multicast traffic is always received over the slow line, through the Hub. This uses most of the 10 Mb/s link's bandwidth, and my wife can't read her email when I'm on the air. This is NOT GOOD. An Ethernet switch would eliminate this, as traffic passing between two machines (B-C) does not use any bandwidth, nor is it seen, by any other machines. Internet access by machine A would be unaffected by a transfer occurring between machines B and C. Machine A would not see the traffic, nor would there be any contention for bandwidth on it's connection because of the B-C traffic. By default the multicast traffic generated by Computer_C goes to eth0. I can use the Linux route command to explicitly tell the system to use eth0: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth0 This works fine (but of course, still sends the heavy multicast traffic through the hub). If I remove this routing instruction and instead enter # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 the multicast data are not received by MAP65 running on the other machine. If I unplug the crossover cable from the Windows machine and instead plug it into a laptop running Win/XP, the laptop receives the multicast packets without a problem. Thus, it would seem that the problem must be in my setup of the Win2k machine -- the one with two ethernet interfaces. Can anyone shed any light on this situation for me? Would there be sufficient bandwidth in a 100baseTx connection (100 Mbps full-duplex) to handle both of the networking streams, i.e. the hub and the direct stream? If so, replacing the inefficient hub with a faster switch, thus confining network traffic to only the ports of the involved machines, might solve the issue. This might allow you to eliminate the direct connection between machines B and C. As to W2k the unicast and multicast routes are handled in separate tables, check here for more info: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/intwork/inaf_mul_hwmc.mspx?mfr=true Hope some of this is of some use :) Rick Kunath, k9ao # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED
[linrad] Re: Testing MAP65 v0.8
Rick, and all -- OK, I've a chance to make some more tests. My computer network looks like this: ADSL 10 Mb/s -- Computer_A DSL -- Modem -- Ethernet -- Computer_B Hub| -- Computer_C Three computers are connected to a 10 Mb/s Ethernet Hub. Additional information: ipconfig on Windows, ifconfig on Linux, report the following IP addresses: Computer A:172.16.28.67 Computer B(1): 172.16.28.69 Computer B(2): 192.168.10.13 Computer C(1): 172.16.28.31 Computer C(2): 192.168.10.12 Have you considered replacing the hub with a 100 Mbps full-duplex Ethernet switch? There are many advantages in this over a hub. Yes. That was my first attempt at a solution. I tried replacing the 10 Mb/s hub with a 10/100 Mb/s switch. The result was the same: when Computer C was multicasting 16-bit Linrad data at about 0.77 MB/s, Computer A was essentially unable to use the internet. The switch apparently did not prevent multicast traffic from reaching A. This was with a D-Link 10/100 Desktop Ethernet Switch. I also tried it with a Linksys model EZXS55W EtherFast 10/100 5-port Workgroup Switch. Same result. I then tried using both the hub and the switch: ADSL 10 Mb/s -- Computer A DSL -- Modem -- Ethernet Hub -- Ethernet -- Computer_B Switch | -- Computer_C Again, no change. This time I checked and confirmed that packets were arriving at A at the correct rate for them to be the multicast packets from C. Computer_A is my XYL's machine. Computer_B runs Windows 2000 Pro, and Computer_C runs Linux (presently the Kubuntu 6.06 distribution). In addition to the connections of all three machines to the hub, a crossover cable makes a direct 100 Mb/s connection between computers B and C. The ethernet interfaces on B and C appear to be configured correctly. On Linux they appear as eth0 and eth1 (occasionally they boot up as eth0 and eth2, I don't know why???). This is configurable, generally, and should be fixed if you intend to use interface based static routes. Check here for more info on iftab (/etc/iftab): http://linux.die.net/man/5/iftab RRR, thanks. Connections to the Hub are assigned dynamic IP addresses; I assume these addresses are in the 192.168.1.x range? No, see above. I was probably wrong to call them dynamic IP addresses. They are assigned by DHCP, but I believe they are always the same. I assigned hard-coded addresses 192.168.10.12 and 192.168.10.13 for the direct inter-machine connection between B and C. I can use the 100 Mb/s direct line for many purposes. I can ping over it in either direction; I can ssh into Linux from Windows; I can use Cygwin/X (as described above) to display Linux X programs on the Windows screen. However, I cannot seem to persuade Windows 2000 Pro to accept multicast packets over the direct line. When I run Linrad on computer C and MAP65 on B, the multicast traffic is always received over the slow line, through the Hub. This uses most of the 10 Mb/s link's bandwidth, and my wife can't read her email when I'm on the air. This is NOT GOOD. An Ethernet switch would eliminate this, as traffic passing between two machines (B-C) does not use any bandwidth, nor is it seen, by any other machines. Internet access by machine A would be unaffected by a transfer occurring between machines B and C. Machine A would not see the traffic, nor would there be any contention for bandwidth on it's connection because of the B-C traffic. Well, as far as I can see this does not seem to be the case. Can it be that your statement is true for normal one-to-one IP traffic, but not for multicast traffic? Or is it true for a router, but not for a switch? By default the multicast traffic generated by Computer_C goes to eth0. I can use the Linux route command to explicitly tell the system to use eth0: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth0 This works fine (but of course, still sends the heavy multicast traffic through the hub). If I remove this routing instruction and instead enter # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 the multicast data are not received by MAP65 running on the other machine. If I unplug the crossover cable from the Windows machine and instead plug it into a laptop running Win/XP, the laptop receives the multicast packets without a problem. Thus, it would seem that the problem must be in my setup of the Win2k machine -- the one with two ethernet interfaces. Can anyone shed any light on this situation for me? Would there be sufficient bandwidth in a 100baseTx connection (100 Mbps full-duplex) to handle both of the networking streams, i.e. the hub and the direct stream? If so, replacing the inefficient hub with a faster switch, thus confining network traffic to only the ports
[linrad] Re: Testing MAP65 v0.8
Well, I found the following information about Ethernet switches: Data received on any port of a repeating hub will be repeated on all of its ports. Unicast, broadcast and multicast messages are all the same to a repeating hub. With a switching hub or switch, unicast messages are only sent to the ports involved in a conversation. However, a standard unmanaged switch without IGMP snooping will handle a multicast message just like a broadcast message: it will receive the message on one port and transmit the message onwards on all other ports. See http://ethernet.industrial-networking.com/articles/articledisplay.asp?id=936 It would appear that a direct inter-machine connection is the way to go. Now I need to understand why it works fine into my WinXP laptop, but not into the Win2k machine. Any further comments or suggestions would be welcome! -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: beta-MAP65 using
Hi Ermanno, [EMAIL PROTECTED] wrote: Hi Joe. Thank you for the answers. Also here uses a program for the control of the rotors (as is small the world !!) taking the data from [azel.dat] One of I these days will add the routine for set of the frequency also. Thank you Ermanno / ik7ezn p.s. Do I be trying to decode from a recorded file ( S key of Linrad) but probably don't find the any sync for the time not real, any suggestion? I assumed, as you did, that raw data files saved by the Linrad S command do not have time information. I now understand from Leif that this is not so. I do not tested to see whether, when one reads a raw data file back into Linrad, it is possible to have Linrad send network data -- and if so, whether the network data will have the original UTC time stamps. I will probably put a Save feature into MAP65, anyway. -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: beta-MAP65 using
Hi Rick, K9AO (Rick Kunath) wrote: I am wondering why on the Linux machine you didn't just run the NTP daemon? I've been using that method for years and it works extremely well. Using the NTP daemon would allow for even better accuracy of the clock on the Linux machine than just doing an ntpdate prior to running xLinrad. The simple reason is that with my present setup most of the available ethernet bandwidth is used for the data being multicast from Linrad to MAP65. I don't want either of the two computers using the network for non-essential purposes, causing collisions and dropped packets. I'm still in the early learning stages of using multicast data, and I want to understand the system's limits as well as I can. I expect that with two network interface cards in each machine and a dedicated private line for the multicast data, ntpd will indeed be the way to go. -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] MAP65 v0.7 r474
To: HB9DRI, IK7EZN, W3SZ, W5UN Cc: Linrad mailing list From:K1JT Subject: MAP65 Beta Testing Date:July 5, 2007 MAP65 version 0.7, r474, is now available for download on the WSJT Home Page, http://physics.princeton.edu/pulsar/K1JT/ . The actual installation file is http://physics.princeton.edu/pulsar/K1JT/MAP65_07-474.EXE . You should first read the updated MAP65 Status Report, http://physics.princeton.edu/pulsar/K1JT/MAP65_Status.txt , and then the MAP65 Quick Start Guide, http://physics.princeton.edu/pulsar/K1JT/MAP65_Quick_Start.txt This early version of MAP65 works well. However many planned features are not yet in place, and surely there are bugs in the code. I expect that there will be frequent updates to the documentation and the program in coming days and weeks. Please report your experiences, bug reports, and wish list to the Linrad mailing list. -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Polarization question
Hi Leif, I have been thinking more about the Linrad polarization questions that I raised here two weeks ago. I wrote: Suppose they [the feedline lengths in X and Y channels] are not well matched. In other words, suppose that the complex gains and signal delays in the two polarization channels are not equal. Will Linrad's polarization-matching capability be compromised? As far as I can see, it still works well even with poorly matched feedlines. I suppose this must mean that Linrad solves for a differential complex gain, and that over a fairly narrow bandwidth a different delay can be treated as a phase shift. You replied: From a practical point of view the cables are well matched. I think it is a safe assumption to guess that the length differences will be very small and of no concern. Let's work in terms of the Stokes Parameters, with complex signals X and Y. I = |X|^2 + |Y|^2 (total power) Q = |X|^2 - |Y|^2 (horizontal linear component) U = 2Re(X^* Y)(vertical linear component) V = 2Im(X^* Y)(circular component) L = sqrt(Q^2 + U^2) (linear polarized component) Theta = 0.5*atan(U/Q) (polarization angle) If I shift the phase of X relative to Y (say, by inserting an extra piece of cable in the X feedline), the values of U, V, L, and Theta will surely change. I don't know what you meant when writing From a practical point of view the cables are well matched. In my station, at present, it would be a complete accident if the downlines from the tower-mounted X and Y preamps were the same electrical length. They are just two pieces of coax that I had lying around. Moreover, my xpol yagis have the H elements located forward of the V elements by some 10 inches or so (I forget the exact amount) -- maybe 1/8 of a wavelength. This will have a very significant effect, as well, no? So, it seems to me that the only way to get things calibrated correctly is the one you outlined: Listen to a linearly polarised signal that arrives with similar strength in both polarisations. (This is the strongest reason why the X configuration is so much better than the + configuration. It is easy to find a pure H-pol signal. Finding a 45 degree terrestrial signal is virtually impossible due to ground reflections so a + configured system has to be calibrated on EME signals.) Change cable lengths until the signal appears close to linear on the pol meter. Fine tune by tweaking the second RF amplifiers. (will affect both amplitude and phase, but there are two second RF amplifiers so it should be possible to find both amplitude and phase matching. On the other hand, a strong practical reason to use the + configuration is that one wants to use the antenna for tropo as well as EME -- and therefore wants the ability to transmit a horizontal signal. My array, therefore, is in the + configuration. It would of course be easy to add parameters for amplitude and phase balance, but I have not done it since I found it easy to do in hardware:-) To me it seems much easier to do it in software, and perhaps I will try this within MAP65. Suppose the gains in the X and Y channels are already matched. Then, while receiving a 100% horizontally polarized signal, shouldn't it be sufficient to multiply the complex signal for X (or Y) by a complex constant e^(i*phi), with the phase shift phi chosen so as to minimize Stokes Parameter V ? -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: MAP65 and Linrad Network
Hi Leif, Moreover, one will almost certainly want separate screens for Linrad and MAP65 -- both of which generally use most or all of a normal-size screen. Yes, I agree - but those who have only one standard computer should know it is possible - if it really is;-) When MAP65 is available, I will be sure to document how it can best be used, and what the hardware requirements will be. Hmmm, I would have liked a file that allows me to play with Linrad on the data that are sent to MAP65. Presumably you have a couple of spurs and perhaps other interesting interference that MAP65 (or at least the waterfall graph) would benefit from not getting. This will not be a problem. I have the original raw data file and have placed it at http://physics.princeton.edu/pulsar/K1JT/06_0744.raw.bz2 It is 263 MB in size. One of the nuisances of using the original data file is that Linrad's raw data are not time-stamped. As you know, JT65 transmissions must start at the top of a UTC minute. To use the raw data file effectively with MAP65 you will need to do something to ensure that the multicast packets contain times that are close to being correct with respect to the original time (modulo 60 seconds). Surely, for MAP65 testing and development I agree that your strategy is more convenient - but from my point of view the original file is far more interesting Yes. It probably will be far more interesting, for you especially. You will find plenty of birdies and other junk in the test file!! See http://physics.princeton.edu/pulsar/K1JT/MAP65_1.JPG . -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: MAP65 and Linrad Network
Hi Leif, The combination works OK, and but a significant number of packets (around 400 in each minute, or slightly more than 1% of the data) are dropped during MAP65's most compute-intensive parts of each minute. Since plrs does no significant computing, I imagine that the problem may be worse when running Linrad + MAP65. It could also be the other way around. Indeed, it could. In that case I will be surprised, but it will hardly be the first time I have been similarly surprised. It may be necessary to add a call to Sleep(0) under Windows or to sched_yield() under Linux at regular intervals in all routines that might lock up the CPU for a too long time. Those calls are effected by lir_sched_yield() in the OS independent code of Linrad and I found it necessary to place about 45 such calls within Linrad. Hmmm, I may have trouble doing the equivalent. For example, MAP65 does some very long FFTs using tthe FFFTW3 library. I can't very well put calls to relinquish CPU control inside these tasks. On the other hand, there is a threads version of FFTW3, which might be what's needed. Right now such issues are not a top priority, though. -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] MAP65 and Linrad Network
MAP65 Status I have now established the necessary network connection between Linrad and MAP65. So far, I have found nothing to prevent a happy marriage! MAP65 receives a full 90 kHz of xpol signal from Linrad, finds all the JT65 signals in that bandwidth, matches the linear polarization angle of each one, decodes the messages, and provides the operator with a band map showing callsigns, operating frequencies, polarization angles, and message contents over the past 15 minutes or so. The program provides a full-width waterfall display and another one zoomed in on the frequency of the station currently being worked. Questions about Linrad's TIMF2 Multicast Data - Header information accompanying Linrad's multicast TIMF2 data includes two single-byte parameters, userx_no and passband_direction, about which I have questions. I understand that userx_no should correspond to the number of RF channels, with negative sign indicating floating format. I would have expected the value -4 for my system using xpol antennas and the WSE converters (I and Q for each of two polarizations), but in fact I see -2. Is this as it should be? Similarly, I would have expected passband_direction=1 as I have no LO's on the high side and the spectrum is not inverted. However, Linrad sends passband_direction=-1. Is this correct? Linrad FFT Versions --- I have been using FFT Version 0 for the first forward, first backward, and second forward FFTs. This produces floating-point TIMF2 data on the multicast network. To save on memory usage in MAP65 it may be desirable to use 16-bit data for TIMF2. I have effected this by setting first forward FFT to version 5, first backward FFT to version 1, and second forward FFT to version 2. Are these good choices? Is there any downside to their use that I might not have thought about? Also, with these settings I notice that the signal in the high resolution graph (red dB lines) is higher than it was with FFT versions 0. Should I adjust some other parameter to bring this level down be several dB? MAP65 with Windows, Linux, FreeBSD, Winrad, SDRxxx ... ? Like WSJT, MAP65 runs on both Windows and Linux. (It should also run on FreeBSD and Macintosh, but I can't test those here.) In my station I will probably run Linrad under Linux and MAP65 on Windows, on a second computer. In response to questions I have been getting: MAP65 could run with Winrad or with various SDR's if their software is modified to provide the necessary multicasting capability. In itself, this would not be too difficult. However, one of the most important MAP65 features is its automatic Rx-polarization-matching capability. That requires a receiver with full xpol processing, which (as far as I know) is not now provided by Winrad, SDR-1000, SDR-14, or SDR-IQ. -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Using the Linrad Network
Leif and all, It turns out that my network speed problem had a simple cause. The computer running Linrad is connected to the LAN through a rather old 10 Mbit/s hub/repeater. Therefore it maxes out around 1.2 MByte/s, too slow for 4 channels at 96 kHz in any of Linrad's network modes except mode 4. Looks like I need a new hub, or at least a simple crossover cable between the two computers. I will report further, fairly soon I hope, on my effort to connect Linrad to MAP65. -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Using the Linrad Network
Hi Leif, Thanks for the reply. Something is wrong. Presumably the reason is the same as for the other errors you observe. ... Check for memory usage first. No swapping is taking place, so I don't think it's a memory issue. I will study the problem more and report back if I learn anything useful. -- Joe # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Using the Linrad Network
He Leif and all, Today I made my first tests of Linrad's network broadcasting capability. I installed Linrad 02.34 and checked it out. All seemed to be well. I selected N on the main menu to initialize networking parameters, and then selected format 4 (16-bit raw data) for output. After toggling network write ON, I found that the program continued to run correctly in Weak CW mode. Unfortunately, I did not have good luck with any of the other data formats. In particular, formats 7, 8, and 9 caused the program to produce broken sound output -- that is, frequent gaps in the Rx background noise when an active frequency is selected with the mouse. Hitting T while receiving, so as to display timing information, shows an apparent A/D sampling rates as follows: Format A/D --- 4 96 kHz 7~30 8~73 9~49 Obviously, something is seriously wrong! I did notice that when using Format 9, although the audio on the master computer has frequent interruptions, watzo running on a second computer displays waterfall data that looks more or less correct. I tried to use one instance of xlinrad to broadcast format 4 data, and a second instance of xlinrad on the same computer receiving the raw 16-bit data. This failed with error #1272 (Write to network socket returned an error) on the master and error #1274 (Network read failed) on the slave. Can you help me to understand what may be wrong in my setup? The computer on which Linrad is running is reasonably fast (2.7 GHz P4, 0.5 MB cache, 1.25 GB memory), and is around 20% busy when running xlinrad. -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Polarization question
Leif, Zaba, and all, Many thanks for the clear explanations! -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: WSE Freq-select box
Hi Leif, Thanks for the reply. Yes, I am using a somewhat older Linrad version, 02.20. It is the one I was using last November, and I thought to bring things up as they were working before, and then upgrade my Linrad version when all is well. It appears that I may have lost communication between the parallel port and the WSE converters. I will look further into that possibility ... -- Joe, K1JT Leif Asbrink wrote: Hello Joe, Maybe your Linrad version is very old? The current version is 02-34. The freq control box was originaly intended for controlling the frequency of the hardware. The standard package supports the WSE units and the SDR-14 and users with other hardwares were supposed to add their own users_hwaredriver to set the frequency of other hardwares. With this intended usage, the frequency control box was only displayed when there was some hardware present (and properly set-up) The frequency control box will not only affect the hardware, it will also change the frequency scales, and someone asked me to allow it always. Therefore it should be present always in recent versions. If you use Linux you have to set the parallel port to whatever value your computer uses (PC COM1 is usually 888) and if you do not, the freq control box would not appear in old Linrad versions. In case the freq control box does not re-appear when you make a test with Linrad-02.34 there is something unexpected going on and if it happens, please pack all par* files and send them to me. There might be something that I do no longer remember. The box should always be there:-) 73 Leif / SM5BSZ Having finished the building of a new 4 x 14 xpol EME antenna, I have now turned to completing the task of reconfiguring my station. After 6 months of not using Linrad, my old brain seems befuddled. The box that one clicks to increase/decrease frequency by 25 kHz steps -- it controls the crystal oscillators in the WSE converters -- has disappeared from my Linrad screen. What have I mistakenly done, when re-connecting and restarting things, to make this box disappear? How do I get it back? Can anyone shed some light on this for me? -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] MAP65 status report
Dear EME Friends, A month ago I mentioned here a piece of SDR software that I have been working on, tentatively called MAP65. Many people have written to ask for more details. I have consequently placed a status report and a MAP65 screen shot on the WSJT web site. Links to them are given below. Very briefly: MAP65 is the back end of a a wideband receiver optimized for JT65 signals. It works together with Linrad and suitable RF hardware to provide automatic polarization-matched reception of all detectable JT65 signals in a 90 kHz passband, in real time. The program runs under both Windows and Linux. In the future it will probably work with Winrad, as well as Linrad. The present state of MAP65 can be judged from the screen shot, which was produced by processing 10 minutes of data recorded on November 11, during the second weekend of the ARRL EME contest. In those 10 minutes, MAP65 decodes nearly 50 callsigns of EME stations operating between 144.100 and 144.160. My EME antenna at the time was a pair of 2MXP20 yagis. MAP65 has not yet been used on the air. My EME antenna was taken down just after the 2006 ARRL contest, and its replacement will not be erected until warmer weather arrives. The MAP65 Status Report and Screen Shot can be found at: http://pulsar.princeton.edu/~joe/K1JT/MAP65_Status.txt http://pulsar.princeton.edu/~joe/K1JT/MAP65_1.JPG Like WSJT, MAP65 will be Open Source software. I hope that these small tidbits of information will entice some others to participate in the program's development. With best wishes to all, -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Video displays and Linrad
I have some time to kill this evening, and I find myself wondering whether anyone else on this list has experienced anything like the following problem. When I put a Linrad system into regular use back in October, I noticed that if I left Linrad running continuously, it always happened that within a day or two I would come into the shack and find that the monitor had lost sync, or some such fault. The Linrad display would be all messed up, with horizontal streaks in many random places, and all system control (via mouse, keyboard, or attempted login from another computer) had been lost. Turning the monitor off and on again did not help. After a reboot the system would be OK again ... but the problem would reappear after another few days. The monitor is a Panasonic 17-inch model, perhaps 6 or 8 years old. To try to understand the problem better I swapped monitors between the Linrad computer and a second machine that I use to run WSJT under Windows. The second monitor is a 15-inch Dell flat-panel LCD model. For some weeks now both monitors -- the Panasonic CRT model now on the Windows computer, and the Dell LCD model on the Linux machine -- have behaved flawlessly. Linux has been left running continuously, but with only a couple of xterms on the screen. Then, yesterday, I started Linrad and left it running. This evening I found the picture on the Dell monitor all screwed up, just as had happened before with the CRT monitor. A reboor was required to clear things up. So my question is this: has anyone else seen their monitor suddenly go berserk in this way? Does it happen only when Linrad is running, as seems to be the case for me? Maybe I have a bad video card that somehow gets more stressed when displaying Linrad than when displaying an inactive X11 desktop?? -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Network standards for SDR
Hi Leif and all, - I would want a timestamp in there somewhere. It might be derived from block_no, but why not make it explicit ? I do not see what it would be good for. Why do you want the clock from the master while there is another one in the slave? Surely I could add this, but there is a cost to it. The packages are sent out at maybe 1 kHz. The corresponding time resolution is 1 ms. There is an appreciable time jitter however and it is not obvious what time to put into a specific package. Presumably it should be the time when the first sample within the package was taken from the hardware. What would it be good for? It is not trivial to evaluate. I agree that a timestamp will be useful. For what I am thinking about, very high precision and high accuracy are not required. JT65 wants to know the UTC of a data block to within a second or so. (Relative timing among successive blocks is of course maintained by the fixed and nominally known sample rate.) Of course the slave computer could use its own time, but that will add another level of jitter. As a minimum, I suggest that each packet include as a 32-bit integer the number of seconds since the Unix epoch, according to the master computer's system clock. So much the better if you include a number of milliseconds as a second number, or combine both into a double. Never mind about jitter; the receiving program would need to know that jitter in the time values will exist, and behave accordingly. Together with the block number, these approaches will suffice very nicely for JT65, anyway. They will work better and more reliably than having the slave computer use its own system clock. Please let me know when a broadcast-enabled Linrad version is available for testing with MAP65. And if you have some example code for use by the receiving program -- or, say, a stand-alone dummy receiving program that can receive broadcast packets, I would be happy to see the code! -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: Network standards for SDR
Leif and all, Would you agree on milliseconds since midnight? From JDB I learned that a double with seconds since Unix epoch would be a bad idea since conversion may be difficult on non-PC platforms. (It is the internal time format within Linrad however) Yes, milliseconds since UTC would be OK. Maybe you should send BOTH this quantity AND a double with seconds since Unix epoch (which I would actually prefer). I don't see the conversion issue as a big deal; little-endian to big-endian copnversion is trivial, and doesn't nearly everybody use IEEE floating point these days? -- Joe # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: complete answer from Roger
Hi Leif and all, Thanks for your answers to my questions posed on October 31. Your reward is a new set of questions about Linrad features ... :-) 1. The Network capability does not seem to exist in recent Linrad versions. Is this correct, or am I missing something about starting it up? 2. References to a file dsp_uiparm still exist on the Linrad Home Page, but the functions of this file seem to have moved to par_userint. Is this correct? 3. What has happened to the startup question about using memlock? Is this no longer used, or no longer a user-level parameter? 4. Figure 1 on the page http://www.nitehawk.com/sm5bsz/linuxdsp/linroot.htm shows a noise blanker operating between timf3 and fft3. Am I right that this blanker is not yet implemented? 5. At the bottom of page http://www.nitehawk.com/sm5bsz/linuxdsp/run/widegr.htm we read Secondary signals are selected or deselected with the left mouse button, which also can deselect the main signal. The help.lir message [2] says Right button selects secondary frequency for decode cw to ascii on screen only (not yet implemented). What is the true status of secondary signals? I find that genparm[MIX1_NO_OF_CHANNELS] is set to 1 (I am not using AFC), and therefore secondary signals cannot be activated. Perhaps this is intentional? 6. On page http://www.nitehawk.com/sm5bsz/linuxdsp/run/widegr.htm we find that it should be possible to pause and resume the waterfall (which waterfall??) by using the Pause key. I can't see that the Pause key has any effect at all. Has it been de-activated? I would like to be able to make both waterfalls pause (or at least go black) when one is transmitting, to avoid having them filled with eye-straining white. -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] S-meter question
Hi Leif and all, Another simple question: Is there an easy way to eliminate the new S-meter graph from the screen? I do not find it useful, and would prefer to have its screen area available for other things. -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: complete answer from Roger
Hi Leif, Thanks for your quick answers, which will be very helpful to my current effort to build a JT65 decoder to work directly with Linrad. A brief response to your last point ... ... I would like to be able to make both waterfalls pause (or at least go black) when one is transmitting, to avoid having them filled with eye-straining white. The pause key is disabled. I do not remember why The Tx side is a major issue that I have not yet given much consideration. Surely the Rx should be muted and several different mechanisms will be needed for this purpose. A key-press could be one of them, one of the parallel port pins could be another. Would you think the space bar is the key to use for Rx/Tx shift? In a first stage it would just quiet the rx, but at a later stage it would start automatic CW keying and perhaps transmissions in other modes with PTT control and maybe other control signals. (A radar mode with PIN-diodes is VERY helpful in aurora, meteor-scatter and perhaps in sporadic E) For what it's worth: Today I modified the routine screen.c in such a way that it automatically detects when I am transmitting and blanks both waterfalls (wide graph and baseband graph). The effect is that instead of bright white strips across all (baseband) or part (wide graph) of the waterfalls, there are black strips. These are much easier on the eyes. Together with a simple patch to wide_graph.c which causes clicking on the wide graph to set the effective BFO frequency to an even kHz, and a users_extra.c routine that sets mt TS-2000 to that same even-kHz frequency for transmitting, the changes make the Linrad/WSJT combination very pleasant to use. I would be happy to share this source code, if anyone is interested. -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: complete answer from Roger
Leif and all -- It has been some time since your email of October 18, but I have finally found time to think about some of the suggestions you made for optimizing Linrad parameters for use with WSJT/JT65. You suggest using fft1 BW=80 Hz, sin^3 window, first mixer BW reduction parameter=3, a large storage time (perhaps 15 s ?) for fft2, and a large averaging number (say 100) for the hi-res graph. OK, these are close to the parameters I have been happily using. Then you say With these parameters Linrad is very sensitive in the main waterfall provided that the waterfall is made very slow. No more than 10 lines per second. The reason is that S/N may be lost in the process of converting the 16384 spectrum to a waterfall of about 100 pixels. I do not understand these sentences at all. Did you possibly mean no more than 0.1 lines per second and a waterfall of about 1000 pixels ?? (You are speaking of the wide-graph waterfall here, not the baseband waterfall -- right?) You repeat the 10 lines per second comment later in the same paragraph. I cannot imagine why one would want to run the waterfall at such a high speed for JT65, so I suppose this was just an unintended mistake? I also do not understand your brief calculation suggesting that the main waterfall (meaning the wide graph, right?) should reveal signals down to -35 dB on the WSJT scale. It's true that in practice I have lots of birdies (though not thousands of them, I believe); but as I have it set up I can see JT65 signals only down to perhaps -24 dB on the wide waterfall. The WSJT (SpecJT) waterfall makes it possible to see JT65 signals down to around -29 dB, or about the limit of the DS decoder. The SpecJT waterfall uses 2.7 Hz per pixel, N=4096 FFTs with no windowing, and I generally run it at its slowest rate, about one line every 3 seconds. I do not see how it could be possible for the Linrad wide-graph waterfall to achieve sensitivity as good as this one does, while displaying anything like 90 kHz of spectrum. What have I missed in understanding what you wrote? -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: users_hwaredriver.c for Flash Xtal (ESS) and Icom (TRX)
Hi Christophe, I am doing much the same thing with my users_hwaredriver.c, but for a Kenwood TS-2000. I am sure I would find it useful to see your code; could you send me a copy of your users_hwaredriver.c ? Many thanks! -- 73, Joe, K1JT Christophe Huygens wrote: Hi folks, just to let you know I have done the users_hwaredriver.c for a. the Flash Xtal as an agile Linrad LO (in my case on 4*28 MHz feeding into the ESS TM daughterboard). This can also be used for the Softrock 7 instead of the on board Xtal. b. Icom rigs for tuning the TRX TX frequency same as Linrads (in my case on 144MHz). Should be ok for all 5 byte ICOMs (all except 735?). I won t be having time in the short run to put this on my site but in case somebody needs it just shoot me an Email. Installation is trivial just drop users_hwaredriver.c in the source directory and recompile. Station automation using linrad is pretty neat! (Of course, will need 2 serial ports for the above). Hope this helps, 73 de xtof on4iy # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
