Loading ...
Sorry, an error occurred while loading the content.

Re: [aprsisce] This is a test

Expand Messages
  • Rick
    Good Grief...didn t know it was going to be so involved ..but it will be nice after..hope your Mountain Dew supplier doesn t run out. Thanks for all you re
    Message 1 of 6 , Sep 27, 2012
      Good Grief...didn't know it was going to be so involved ..but it will be nice after..hope your Mountain Dew supplier doesn't run out.
      Thanks for all you're doing, I appreciate your free time and sweat you pour into this Hobby, I hope it's still fun for you.

      On 09/27/12 15:09, Lynn W Deffenbaugh (Mr) wrote:
      I think you've been watching the new GEICO commercial too much.... "Is this thing on?"... "Too bad nobody heard me".

      No, I've been quiet because I'm getting overwhelmed as I lay out the stepping stones toward finalizing the internal port renovations.  Some of those steps will be...

      1) Change the way internal port indices are assigned so that creating/deleting ports no longer messes up the packet rates and statuses.

      2) That's necessary to accurately track WHICH RF port a station was heard on.  Currently I only remember that it was "Heard on RF".

      3) That's necessary to transmit acks ONLY on the RF port which received the message.

      4) Which is also necessary to make sure that -IS to RF IGating only considers that a station was not heard on THIS RF port to suppress gating a filtered packet.  Currently if a station was heard on ANY RF port, that station's packets won't gate from -IS to RF even if they hit the IGate filter.

      5) Which is necessary to support RF port to RF port filtered "gating".  Otherwise, since the station was heard on ONE RF port, it won't gate back out ANY RF port.

      6) And that drives the packet counters to need to be RF port specific instead of a single RF counter per station.

      7) Which means that the counters need to be a structure linked to the station, not embedded in the station structure, in order to support an arbitrary number of ports that may copy a given station.

      8) Which drives needing to renovate the station structure definition to use a linked list of optional structures instead of dedicated pointers to the various pieces, many of which will be NULL for most stations (right click on APRS-IS OK and select Memory from the bottom of the popup.  It shos how many stations are known and how many stations have which of the optional components as well as how big those component structures are).

      9) Which opens up the world for additional optional structures on the stations like tracking DX by RF port and time of last DX to do whatever it was that James wanted me to do to the DX determinations.

      10) And then to move the packet parsing into the port threads, renovate how packets are passed around so that each reception only gets parsed once, which also enables me to carry nulls inside the packets (although not inside the displayable text, maybe), and figure out a nice UI for configuring and remembering IGate filters.

      11) And a UI for configuring the various features of <DigiXForms> and move the digipeat to the individual port threads.

      12) And then renovate the individual port types to better support user-supplied <Open/CloseCmd>s, a UI to edit those commands, a terminal emulator mode to locally drive a port.

      13) And all the while lay the groundwork for opening up the program for Lua scripting with full protected multi-threaded access to the internal station information.

      And along the way I'm discovering a few other things like the fact that I'm currently truncating any packet received that has an embedded null character (yes, I code in C).  I'd have never expected it, but apparently AGWtracker can do some strange tricks with comments and some UI-View DX plugin is using a null instead of a degree symbol (I think).

      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

      PS.  Consider the following packets.  aprs.fi shows it better, but the <00> is a null character:

      BG5EKR-8>APAGW,TCPIP*,qAS,BG5EKR:=3038.32N/12032.70EZ<00>T<00>o<00>n<00>g<00>x<00>i<00>a<00>n<00>g<00> <00>i<00>g<00>a<00>t<00>e<00> <00>1<00>4<00>4<00>.<00>3<00>9<00>0<00>M<00>H<00>z<00> <00>1<00>2<00>0<00>0<00>b<00>p<00>s<00>
      BG5EKR-8>APAGW,TCPIP*,qAS,BG5EKR:><00>T<00>o<00>n<00>g<00>x<00>i<00>a<00>n<00>g<00> <00>i<00>g<00>a<00>t<00>e<00> <00>1<00>4<00>4<00>3<00>9<00>0<00>M<00>H<00>z<00> <00>1<00>2<00>0<00>0<00>b<00>p<00>s<00>
      F6BXD>APAGW,TCPIP*,qAC,T2FRANCE:=5009.45N/00325.42E%<00>D<00>x<00>C<00>l<00>u<00>s<00>t<00>e<00>r<00> <00>V<00>o<00>c<00>a<00>l<00> <00>1<00>4<00>5<00>.<00>5<00>5<00>0<00> <00>M<00>h<00>z<00>
      KI4BKE>APAGW,TCPIP*,qAC,T2POLC:=3536.47N/07851.47W=<00>h<00>t<00>t<00>p<00>:<00>/<00>/<00>t<00>r<00>i<00>a<00>n<00>g<00>l<00>e<00>a<00>p<00>r<00>s<00>.<00>n<00>e<00>t<00 00>
      JR0MOE>APAGW,TCPIP*,qAC,T2JNET:=3549.06N/13938.63E-<00>W<00>i<00>R<00>E<00>S<00> <00>#<00>4<00>8<00>6<00>8<00>D<00> <00>S<00>S<00>-<00>W<00>i<00>R<00>E<00>S<00> <00>S<00>R<00>I<00> <00>N<00>O<00>-<00>R<00>F<00>
      JR0MOE>APAGW,TCPIP*,qAC,T2JNET:><00>W<00>i<00>R<00>E<00>S<00> <00>#<00>4<00>8<00>6<00>8<00>D<00> <00>S<00>S<00>-<00>W<00>i<00>R<00>E<00>S<00> <00>S<00>R<00>I<00> <00>N<00>O<00>-<00>R<00>F<00>
      7N2ATD>APU25N,TCPIP*,qAC,T2SAPPORO:>271712zDX: JP7DKH-1 37.12.63N 140.52.04E 55.0km 17<00> 02:10
      JA1RMT>APU25N,TCPIP*,qAC,T2TOKYO2:>271710zDX: JO1ZXU-2 36.32.21N 139.10.83E 99.1km 333<00> 01:54
      JA6ZME-10>APU25N,TCPIP*,qAC,JG6YCL-JA:>271657zDX: JG6YDA-3 33.33.12N 130.35.19E 87.2km 351<00> 01:38
      JA8EFI-3>APU25N,TCPIP*,qAC,T3SAPPORO:>271704zDX: JR8YMH-3 43.10.10N 141.24.71E 16.3km 20<00> 01:59
      JE3RLL-10>APU25N,TCPIP*,qAC,T2JNET:>271717zDX: JR3SGJ-3 35.06.72N 135.57.08E 51.7km 39<00> 02:16
      JF5FFL-10>APU25N,TCPIP*,qAC,T2EHIME:>271715zDX: JA5WUO 34.18.38N 133.57.30E 74.6km 55<00> 02:00
      JF6PEK-10>APU25N,TCPIP*,qAC,T2FUKUOKA:>291713zDX: JE6DJS-2 33.39.27N 130.45.67E 26.0km 109<00> 02:00
      JF6YLF-10>APU25N,TCPIP*,qAC,JG6YCL-JA:>271706zDX: JG6YBZ-2 31.35.63N 130.50.52E 46.9km 209<00> 01:36
      JG6YCL-2>APU25N,TCPIP*,qAC,JG6YCL-JA:>271718zDX: JG6YCB-2 33.29.00N 130.54.64E 47.8km 138<00> 02:15
      JJ2KZA-10>APU25N,TCPIP*,qAC,T2JNET:>271710zDX: JM2ITU-1 34.01.  N 136.09.  E 23.3km 42<00> 01:58
      JM4PRG-10>APU25N,TCPIP*,qAC,T2FUKUOKA:>271707zDX: JA5YVT-2 33.56.75N 132.51.00E 81.2 miles 233<00> 01:50
      JN1NVQ>APU25N,TCPIP*,qAC,T2SAPPORO:>271710zDX: JF1EKQ-1 36.36.17N 138.52.52E 89.3km 300<00> 01:46
      JO1PYV-1>APU25N,TCPIP*,qAC,T2TOKYO2:>271710zDX: JO1YDG-10 35.35.56N 138.31.40E 5.7 miles 186<00> 01:47
      JO2SIF-10>APU25N,TCPIP*,qAC,T2JNET:>271712zDX: JR2JYU-10 35.21.27N 136.46.93E 26.8km 264<00> 01:53
      JR0DMI-15>APU25N,TCPIP*,qAC,T2SAPPORO:>271715zDX: JA0ZRY-2 37.25.47N 138.46.70E 43.5km 210<00> 02:10
      JR4IUS-10>APU25N,TCPIP*,qAC,T2EHIME:>271718zDX: JJ4RJE-3 34.16.05N 132.41.16E 25.5km 127<00> 02:02
      JR6CUM-10>APU25N,TCPIP*,qAC,T2EHIME:>271709zDX: JE6ZFX-3 32.46.58N 131.37.57E 23.0km 168<00> 01:57

      On 9/27/2012 2:42 PM, Rick wrote:
      My email hasn't been dinging all day like in the past...I quess you enjoying that Lynn.

      On 09/27/12 14:14, Lynn W Deffenbaugh (Mr) wrote:

      Is what working? Yahoo groups? They have good days and bad days just
      like the rest of us...

      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

      On 9/27/2012 2:12 PM, kd4dra wrote:
      > I've never seen it this slow...is it working
      > Rick / kd4dra


    Your message has been successfully submitted and would be delivered to recipients shortly.