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

20369RE: [aprsisce] Tracking Ships

Expand Messages
  • Fred Hillhouse
    Oct 3, 2012
    • 0 Attachment
      A specific port makes sense, now for confirmation or redirection. I will have to read about the q-construct again. Maybe this time it will make a little more sense.
       
      Auto-switching would have to give an indication that it was switched. An internal message could be generated, kind of like when a filter is changed.
       
      Three works. Why didn't I think of that? Oh, I know why. I was blind sided by the way I usually operate. I inject data into APRSIS32 and have RF=>IS turned off since I am learning packet formation and such. I figured I would do the same with AIS if I could find a data stream. My goal has been to keep my learning private without banging on a server somewhere. So, I only bang on mine. So far I have constructed readable packets and KISS packets. It has been a learning experience giving a bit more insight into APRS. I have an new appreciation for all the thought that went into it and look forward to what the future holds.
       
      I am looking forward to Firenet.us coming back up!
       
      Thanks again for creating a great application! I have recently added it to a webDT360 and am working out the nuances.
       
       
      Best regards,
      Fred, N7FMH
       
       
       

      From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Lynn W Deffenbaugh (Mr)
      Sent: Wednesday, October 03, 2012 18:01
      To: aprsisce@yahoogroups.com
      Subject: Re: [aprsisce] Tracking Ships

       

      On 10/3/2012 5:18 PM, Fred Hillhouse wrote:
       
      I guess the next question, assuming one lived in range, had a receiver, how does data get injected into Firenet.us?

      That's a good question for which I have never seen any documentation.  And with firenet.us down, we can't even consult the :14501 status page's description of the supported ports.

       
      I think I just thought of the answer. If my instance is connected to Firenet.us and I have an application to listen to a receiver and send a properly formatted packet to APRIS32, then the data would  go to Firenet.us and not APRS-IS. If this answer is wrong, please let me know! I have not found any other answer yet.  I suspect the packet can't look like an APRS packet per se or it may go to APRS-IS anyway. I have created packet and sent them through Firenet.us and could still see them on APRS.FI which means to me there is something special about Firenet.us packets.

      Not special about the packets because firenet.us is simply a configured instance of javAPRSSrvr.  The "specialness", I believe, is which port firenet-specific (aka non-APRS-IS) packet injectors connect to.  Port 14580, the normal filtered port, will pass your gated and injected packets through to APRS-IS (albeit with a "client-only" q-construct as I recently discovered).

       
      If my answer is correct, the issue I see is if the APRSIS32 server was changed to the APRS-IS (like when Firenet.us is offline) then the data would show up there which is not acceptable. There are a couple of possibilities that might help. One, a checkbox could be added to select Firenet.us only. This way, if someone was injecting AIS into Firenet.us and the server stopped working and the instance was changed to APRS-IS (manually or automatically-future?), then the data would not go further. I like this one since there may be other data that would be useful to inject.

      Auto-switching APRS-IS connections from firenet.us to the APRS-IS network is something you really don't want if you think about it.  What happens when the connection to firenet.us is interrupted momentarily and your client switches to the APRS-IS?  It will only switch back when that connection fails leaving you without the "specialness" of firenet without your knowledge.

      There's another feature that may be finalized in the port renovations to allow APRSISCE/32 to accomplish close to what you're after, but only for non-IGate (read: client-only) instances.

      Two, Lynn adds AIS decoding to APRISIS and cool configurable icons (like vesseltracker) to match the vessel type then he controls where that data is injected. *grins

      Three - If you're doing AIS decoding and APRS packet generation from the received data, simply inject the packets directly into the firenet.us port that keeps them firenet-local and then let APRSISCE/32 do what it does best, display APRS data from whatever APRS-IS server you have configured within it.

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

    • Show all 25 messages in this topic