Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[TRLog\]\s+TR\s+6\.64\s+comments\.\.\.\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[TRLog\]\s+TR\s+6\.64\s+comments\.\.\.\s*$/: 22 ]

Total 22 documents matching your query.

1. [TRLog] TR 6.64 comments... (score: 1): Author: rrossi@btv.ibm.com (Ron D. Rossi); Date: Tue, 16 Apr 2002 09:51:44 -0400; Folks, I am glad the improved band map is generally working very well for everyone. There are plans for further improvements as well. I have a few comments on the current release. With the release of; /archives//html/TRLog/2002-04/msg00068.html (8,488 bytes)
2. [TRLog] TR 6.64 comments... (score: 1): Author: roberto.soro@sia.it (Soro Roberto); Date: Tue, 16 Apr 2002 16:46:17 +0200; Fisrt of all a BIG thanks to Ron for his huge work! Now the band map is quite superb. A couple of things that sound strange to me. Just paly a bit with the spot file, I found these mismatches: after; /archives//html/TRLog/2002-04/msg00069.html (10,746 bytes)
3. [TRLog] TR 6.64 comments... (score: 1): Author: rrossi@btv.ibm.com (Ron D. Rossi); Date: Tue, 16 Apr 2002 11:32:58 -0400; Thank you and you're welcome! I will check that out. It probably has something to do with "/" designator. The call window does get the full call correctly though, right? One of the changes I forgot; /archives//html/TRLog/2002-04/msg00070.html (9,648 bytes)
4. [TRLog] TR 6.64 comments... (score: 1): Author: kg2au@stny.rr.com (Jimmy Weierich); Date: Tue, 16 Apr 2002 18:19:22 -0400; Can't play messages in 6.64 here either. Trips PTT and immediately drops it. Fails with a previously recorded and reloaded message as well as a newly recorded one. Recording is okay, messages recorde; /archives//html/TRLog/2002-04/msg00071.html (8,015 bytes)
5. [TRLog] TR 6.64 comments... (score: 1): Author: jimsmith@shaw.ca (Jim Smith); Date: Tue, 16 Apr 2002 21:44:50 -0700; Hi Ron, Haven't tried 6.64 yet. Was anything done about not being able to set the decay time beyond 63 min or so? I would like to be able to set it to, say, 4 hours as it makes S&P much easier. i.e.; /archives//html/TRLog/2002-04/msg00072.html (9,678 bytes)
6. [TRLog] TR 6.64 comments... (score: 1): Author: kl7ra@blizzard.gcgo.nasa.gov (KL7RA); Date: Wed, 17 Apr 2002 09:12:52 -0800; Are you sure Jim? Four hours is forever in a contest. I actually adjusted the time the other direction and set the fade to 20 mins during the WPX. Except for the M/M CQ beacons I doubt too many spots; /archives//html/TRLog/2002-04/msg00073.html (8,100 bytes)
7. [TRLog] TR 6.64 comments... (score: 1): Author: jimsmith@shaw.ca (Jim Smith); Date: Tue, 16 Apr 2002 23:03:35 -0700; Hi Rich, Well, it depends on the contest and whether or not you use spots. I don't use spots. I can imagine that 4 hours of spots in the bandmap would look pretty silly. In domestic contests such as; /archives//html/TRLog/2002-04/msg00074.html (9,001 bytes)
8. [TRLog] TR 6.64 comments... (score: 1): Author: vr2bg@harts.org.hk (VR2BrettGraham); Date: Wed, 17 Apr 2002 06:50:53 +0000; I2WIJ mentioned: I reply here as maybe I'm alone with this idea, but since we (should be) are aware of what band we are on, rather than including the Mc bit of the frequency in the bandmap, might dis; /archives//html/TRLog/2002-04/msg00075.html (8,654 bytes)
9. [TRLog] TR 6.64 comments... (score: 1): Author: kharker@cs.utexas.edu (Kenneth E. Harker); Date: Wed, 17 Apr 2002 07:48:02 -0500; If I remember correctly, TR uses 6 bits of a byte to hold the bandmap decay time. The largest number one can store in 6 bits is 63. If you increased it to use all 8 bits of a byte, the largest number; /archives//html/TRLog/2002-04/msg00077.html (11,698 bytes)
10. [TRLog] TR 6.64 comments... (score: 1): Author: rrossi@btv.ibm.com (Ron D. Rossi); Date: Wed, 17 Apr 2002 08:55:19 -0400; Not yet. The only practical way for me to do this would be to change the granularity of the decay from one minute increments to something larger. The max number of "time units" an entry can survive; /archives//html/TRLog/2002-04/msg00078.html (9,532 bytes)
11. [TRLog] TR 6.64 comments... (score: 1): Author: rrossi@btv.ibm.com (Ron D. Rossi); Date: Wed, 17 Apr 2002 09:21:01 -0400; The display can handle multiple bands, so the MHz info is relevant. The full call shows up in the call window as you tune by it, and you know the most important things about the station at a glance:; /archives//html/TRLog/2002-04/msg00079.html (9,341 bytes)
12. [TRLog] TR 6.64 comments... (score: 1): Author: kg5u@hal-pc.org (Dale L Martin); Date: Wed, 17 Apr 2002 09:09:27 -0500; ap. So, if I selected a BAND MAP DECAY UNIT of 2, decay would be lengthened to 126 minutes? What about something a bit more variable and maybe clearer: Don't have a BAND MAP DECAY UNIT. Set the norma; /archives//html/TRLog/2002-04/msg00080.html (9,602 bytes)
13. [TRLog] TR 6.64 comments... (score: 1): Author: tree@kkn.net (Tree N6TR); Date: Wed, 17 Apr 2002 08:46:40 -0700; We could make it longer... we could change the code so we decrement the "time to live" count on even minutes - and make things go twice as slow. When it was designed, I just imagined that 63 minutes; /archives//html/TRLog/2002-04/msg00081.html (7,790 bytes)
14. [TRLog] TR 6.64 comments... (score: 1): Author: tree@kkn.net (Tree N6TR); Date: Wed, 17 Apr 2002 08:51:07 -0700; The dupe and mult status bits. However, an "easy" way to get around this is to only decrement the time on every other minute (even minutes) and that way it will work for 2X the time. Tree; /archives//html/TRLog/2002-04/msg00082.html (8,117 bytes)
15. [TRLog] TR 6.64 comments... (score: 1): Author: N7DR@arrl.net (D. R. Evans); Date: Wed, 17 Apr 2002 11:11:30 -0600; Ugly, but I would sure like this. I find the current limitation very annoying and, worse, causes me to waste time and adds to my frustration level. Doc N7DR - -- D.R. Evans N7DR / G4AMJ N7DR@arrl.net; /archives//html/TRLog/2002-04/msg00083.html (10,402 bytes)
16. [TRLog] TR 6.64 comments... (score: 1): Author: kk1l@arrl.net (Ronald Rossi); Date: Wed, 17 Apr 2002 22:16:55 -0400; Folks, I have it implimented and it works. It is called the BAND MAP DECAY MULTIPLIER. Selecting 1 is normal time, 2 is twice as long, 3 three times, etc. I'll see about having the multiplier feed ba; /archives//html/TRLog/2002-04/msg00084.html (9,746 bytes)
17. [TRLog] TR 6.64 comments... (score: 1): Author: ua9cdc@mail.ur.ru (Igor Sokolov); Date: Wed, 17 Apr 2002 17:01:33 +0600; What about band map that shows all bands simultaniously. Without MC bits you will not know what band the spot is on/ Igor, UA9CDC; /archives//html/TRLog/2002-04/msg00085.html (8,344 bytes)
18. [TRLog] TR 6.64 comments... (score: 1): Author: jimsmith@shaw.ca (Jim Smith); Date: Wed, 17 Apr 2002 21:59:21 -0700; Fabulous. Now I won't have to wear out the space bar doing a dupe check on every old signal I come across. Thanks very much. 73 de Jim Smith VE7FO; /archives//html/TRLog/2002-04/msg00086.html (8,650 bytes)
19. [TRLog] TR 6.64 comments... (score: 1): Author: juhan@chem.ut.ee (Juhan Põldvere; Date: Thu, 18 Apr 2002 17:05:31 +0300 (EEST); Shifting left and right could give you 4 or 8 hours with 4 or 8 minute increments. -- Juhan ES5QX; /archives//html/TRLog/2002-04/msg00088.html (8,622 bytes)
20. [TRLog] TR 6.64 comments... (score: 1): Author: dl2zav@gmx.de (Udo DL2ZAV); Date: Thu, 18 Apr 2002 21:57:25 +0200; Hi Ron, [Ron D. Rossi, 17 Apr 2002:] Confusing enough to have two parameters to set. Besides, DECAY TIME = 45 (minutes) in fact would mean 90 minutes when UNIT = 2. Maybe it could be called BAND MAP; /archives//html/TRLog/2002-04/msg00091.html (10,374 bytes)

Current List: 1 - 20
Page: [1] [2]