[aprssig] Fwd: Re: New Paradigm for UIDIGI

Robert Bruninga bruninga at usna.edu
Mon May 16 09:42:18 EDT 2005


With a lot of work by Jim and Ron and others, the
mysteries of the EXISTING UIDIG ROMS has been
mastered and now the UIDIGI rom can do all the
New-N Paradigm stuff correctly...
Details will follow in a few days.

THanks Jim and Ron, etc...
Bob


>>> Jim Jennings <jennings at intercomm.com> 5/16/2005 2:17:48 AM >>>
Bingo!!!!

This evening I remote accessed SLIDE, COREY, LEWIS, and AUSTIN (all 
UIDIGI 1.9 Beta 1 or 3 firmware), changed UITRFL to 2, removed WIDE1-1

from their UIDIGICalls, then gave AUSTIN's Beacon 2 a path of 
WIDE1-1,WIDE2-1, with the following result:

AUSTIN>COREY>WIDE1*>WIDE2-1>APNU19 [UI]:
!3927.22NS11703.22W#PHG1700/W4,NVn, Info:  w7xz at arrl.net   A=008460
AUSTIN>COREY>WIDE1>SLIDE>WIDE2*>APNU19 [UI]:
!3927.22NS11703.22W#PHG1700/W4,NVn, Info:  w7xz at arrl.net   A=008460

It would appear that the UITRFL value of 2 has been available in all 
versions of UIDIGI following 1.8 Beta 6 as well, but a web search 
tonight indicates that not even the documentation (UIDIGIE.DOC) for 1.8

Beta 6 (or succeeding versions, not even 1.9 Beta 3) reflects this 
addition.  Only CHANGES.TXT ever makes mention of it.  Nevertheless, it

makes things work as originally intended, and it's "full speed ahead" 
for the New Paradigm with UIDIGIs.

Megathanks to you and Dick for the info (was over at "second QTH" for 
the weekend when I got my first look at this forwarding), and pleased
to 
confirm that it works in our all UIDIGI system!  And the burnfiles get

revised and recompiled again.  :-)

Jim, W7XZ


Cap Pennell wrote:

>With the old stable version 1.8b6 in our Fremont Peak K6JE-3 digi, I
tried
>
>UITRFL 2
>FPRA:K6JE-3} UITRFL was: 4 now is: 2
>
>
>THEN it worked with the new paradigm "fill-in" path of
WIDE1-1,WIDE2-1
>showing:
>
>KE6AFE>AP,K6JE-3,WIDE1*,WIDE2-1:v
>
>KE6AFE>AP,K6JE-3,WIDE1*,WIDE2:v  (this packet from a too old KPC-3
"UIFlood
>WIDE,30,NOID" digi)
>
>73, Cap
>
>
>  
>
>>-----Original Message-----
>>From: aprssig-bounces at lists.tapr.org 
>>[mailto:aprssig-bounces at lists.tapr.org]On Behalf Of Robert Bruninga
>>Sent: Saturday, May 14, 2005 06:06 AM
>>To: rejenkins at adelphia.net; ron.stordahl at digikey.com; Robert
Bruninga
>>Cc: aprssig at lists.tapr.org 
>>Subject: [aprssig] Re: New Paradigm for UIDIGI
>>
>>
>>Dick,
>>Yes!  This UIDIGI version does appear to fix the major UIDIGI
>> problem! When did this new version come out?  Thanks!
>>Bob
>>
>>    
>>
>>>>>Richard Jenkins <rejenkins at adelphia.net> 05/14/05 6:24 AM >>>
>>>>>          
>>>>>
>>>It is my understanding that one of the reasons for the current
>>>recommended methodology for reprogramming UIDIGI eproms
>>>was that UIDIGI could not properly place the '*' character after
the
>>>"expired" WIDE command.
>>>
>>>This capability was apparently added in version 1.8b6.  The
>>>applicable portions of the "CHANGES.TXT" file are listed below.
>>>
>>>      
>>>
><snip>
>  
>
>>>- Added new flags to UITRFL command. Now the bit flags have the
>>>following
>>>meaning:
>>>
>>>bit 0 TRACEN-0 will be repeated
>>>bit 1 put has been repeated flag on TRACEN-0
>>>bit 2 make call substitution on TRACEN-0
>>>
>>>I have changed the UIFLDfl parm to 4 (the numerical value of bit 2)
>>>and it works.  I now have 2 digis that are properly adding the *
>>>(asterisk) to the end of the expired WIDEn path statement.
>>>
>>>What does this do to the new paradigm plans for UIDIGI?  It would
>>>seemingly remove the need to alias the WIDE1-1 command.
>>>
>>>Dick w2gwy
>>>      
>>>
>
>
>
>
>  
>





More information about the aprssig mailing list