SN Spotter Network: APRS—>SN Unstable Again

I've had one or two of those in my lifetime. It sounds like you're working on it so I can't ask anymore of you than that. I agree that last year during the chase season you were here regularly addressing issues. It seemed to me like a lot of repetitive stuff that started to be a real drag. Thanks for the update and for the time you've invested in this during the last year, now, and in the future. I hope as data streams begin picking up with the Spring coming you guys will be able to resolve whatever is causing this brain damage!!
 
Thanks for the update, @John Wetter and for all that y'all have been doing regarding this issue. I have a question... Has anyone looked at the APRS Tracker option on the Allison House site, how it operates, and how the data is transmitted outbound? Instead of having the system poll for the !SN! string, just have it poll the call/SSID of the user. I know I maybe grasping at straws, but just a thought.
 

Attachments

  • Example 2.png
    Example 2.png
    83.2 KB · Views: 0
Thanks for the update, @John Wetter and for all that y'all have been doing regarding this issue. I have a question... Has anyone looked at the APRS Tracker option on the Allison House site, how it operates, and how the data is transmitted outbound? Instead of having the system poll for the !SN! string, just have it poll the call/SSID of the user. I know I maybe grasping at straws, but just a thought.

Yep, the same person supports both and it is largely a shared code base which is why this is so brain wracking.
 
@John Wetter, is all of the data flowing into SN on the same server or are there separate servers handling different things?

Edit: Sorry, I haven't had my coffee yet. I guess I'm asking if all requests are made to the same location in reference to APRS vs standard location updates?
 
@John Wetter, is all of the data flowing into SN on the same server or are there separate servers handling different things?

Edit: Sorry, I haven't had my coffee yet. I guess I'm asking if all requests are made to the same location in reference to APRS vs standard location updates?
It's a load-balanced setup but in general yes, it is the same system if I'm understanding the question correctly...
 
It's a load-balanced setup but in general yes, it is the same system if I'm understanding the question correctly...

I ran into a similar situation with an application I developed for GPS tracking. One component worked with a different protocol than the other, and running into the same endpoint caused issues that to this day I have no idea how it happened. I migrated one protocol to a different API endpoint, then converted the information into a readable format the application could use with the Google Maps API. Worked like a charm after that.

I'm not sure if that would help in relation to Spotter Network, but it was a workaround that helped me out in the past. Bugs me to no end that I couldn't figure out why it would process some data, but not the other. No errors. Everything was fine on the backend. Anyways, I digress.

Thanks for getting back to me. I appreciate you.
 
Curious if there has been any progress on this situation? Also,

I have a question... Has anyone looked at the APRS Tracker option on the Allison House site, how it operates, and how the data is transmitted outbound? Instead of having the system poll for the !SN! string, just have it poll the call/SSID of the user. I know I maybe grasping at straws, but just a thought.
Mark maybe I don't have things configured correctly after all. I am able to (or at least could in the past) track others via this method but I'm not getting my own position. Does the wild card (%) make a difference? I don't have it on the others I've tracked. As I said in the other thread I replied to initally, I am getting info on aprs.fi so apparently I have the radio configured (at least somewhat) correctly.
 
Back
Top