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

Re: UNPROTO problem

Expand Messages
  • tuckmeat
    OK, I feel like a dufus now. :) I didn t realize that the radio s TNC would get set to NOCALL if it was configured with the same SSID as the software (is this
    Message 1 of 6 , Jan 2, 2011
      OK, I feel like a dufus now. :)

      I didn't realize that the radio's TNC would get set to NOCALL if it was configured with the same SSID as the software (is this by design?). I had changed it to be different, but then changed it back for some reason that I don't remember. Now when I set APRSIS32 to a different SSID it seems like it's working great. When the radio beacons, it sends the software's SSID and when it digipeats it also uses the same SSID.

      One thing that was confusing me was that when I just have APRSIS32 configured for RX only, the port logging looks a little different. When it's RX only, I see the radio callsign/ssid and full packet text displayed in the port log when it beacons. When the software is configured for TX, I just see UNPROTO with the Mic-E logged upon radio beacon. I thought it was actually sending the text UNPROTO with NOCALL as the beacon text, which it isn't (well, it WAS sending NOCALL).

      Anyway, I understand how it works now and it's all good.


      --- In aprsisce@yahoogroups.com, "Lynn W Deffenbaugh (Mr)" <kj4erj@...> wrote:
      >
      > What do you have the Configure / General / MyCall-ssid set to in
      > APRSISCE/32? The only reason APRSISCE/32 would set the radios MYCALL to
      > NOCALL is if that's the callsign you have configured into APRSISCE/32.
      >
      > Can you Enables / View Log / <YourPortName> and click Enable on that
      > menu bar. Then disable and enable the RF port itself and wait for a
      > beacon to go out from APRSISCE/32. Then close the client and sent your
      > APRSIS32.XML and APRSIS32*.LOG files to KJ4ERJ@... I'll see what
      > sense I can make out of it.
      >
      > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
      >
      > tuckmeat wrote:
      > > OK, didn't know about the MIC-E format. That helps.
      > >
      > > I've done that procedure a few times myself to see if it would solve the problem and just did it again to verify what happens. It doesn't solve the problem for me. I made sure that the TNC was off and let APRSIS32 turn it on. When the radio beacons, it sends UNPROTO. I also forgot to mention earlier that that APRSIS32 is setting MYCALL to NOCALL on the radio's TNC. When that happens, the digipeating no longer works properly because of the settings change. I did see this time around that the setup is actually working properly UNTIL the radio beacons. If I turn beaconing off on the radio and tell
      > > APRSIS32 to control the beaconing, everything works as it should. I verified this by using another HT at very low power to make sure that the TH-D72 would digipeat and igate the packet. When the radio's TNC settings get messed up, if I shut down the APRSIS32 radio port, the TH-D72 goes back to working properly. So...it appears to me that something is getting set in the TNC by APRSIS32 that isn't quite right?
      > >
      > >
      > >
      > > --- In aprsisce@yahoogroups.com, Randy Love <rlove31@> wrote:
      > >
      > >> Sounds like the radio has gotten out of sync with APRSIS putting it into the
      > >> proper mode.
      > >>
      > >> Have you always been careful to shut down APRSIS before moving it to the
      > >> next pc *and* starting APRSIS after connecting to the new pc??
      > >>
      > >> To resync the tnc in the D72, press the TNC button until the TNC/APRS
      > >> indicator is OFF ( no longer displayed on the screen of the radio ). Shut
      > >> down APRSIS on the computer. Connect the computer and radio, then restart
      > >> ARPSIS.
      > >>
      > >> That should get everything back to normal.
      > >>
      > >> As for the STPYUU in the destination call, that's not a problem, that part
      > >> of the way that the D72 does it's position encoding called Mic-E format.
      > >> Mic-E format uses the destination call for Longitude and puts Latitude in
      > >> the payload part of the packet.
      > >> You can read more about it here:
      > >> aprs.org/doc/APRS101.PDF page 43
      > >>
      > >> 73,
      > >> Randy
      > >> WF5X
      > >>
      > >>
      > >
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.