SN Spotter Network: APRS—>SN Unstable Again
- Thread starter Mark Drees
- Start date
Thank you Mark. I may just put together my own script to produce an APRS list out of the APRS-IS stream. I was hoping not have to put that much work into it. But it seem like SN may or may not work on fixing this. So if SN works on this and needs help, let me know.
Thanks a bunch.
Thanks a bunch.
It has been almost two years since the APRS function has displayed correctly on the place files. I’m unsure why it’s even listed as an option anymore since it doesn’t work.
I am interested in creating a script or method to generate filtered place files from APRS too. I need to set up an iGate first though.
After my initial post, I discovered that AllisonHouse.com provides a custom APRS placefile, in addition to custom SN placefile. The cost may not be for everyone, but it is an option I can use.
David McAnally
WD5M
Last edited:
I’ve used the custom SN place file on Allison House for a few years. The only drawback is the icon doesn’t indicate movement (you have to hover the cursor over the icon to see it). However, it doesn’t really matter with most SN users now converting to RadarScope because movement isn’t displayed. It is an option if you’re able to subscribe.
Until Spotter Network resolves the APRS issue, my suggestion is to use the AllisonHouse tracking option that is available to subscribers. I've uploaded screenshots of how I have it setup and how it appears on GR.
Attachments
This thread is almost like a cold case murder file where you need to start from scratch with a fresh viewpoint and hope you find a detail that may have been overlooked. It would be nice if someone who understands the inner workings of APRS could remote into your computer using Team Viewer to take a look. That's taking support to a whole new level though on freeware!
There lies the issue. From what I understand the APRS data is flowing into SN, but no one knows why the information isn't being transmitted to the various place files and apps.
Here’s another issue I have. I understand SN is volunteer based, but why does it take so long to get a response from anyone? That has been my issue since the support was moved to Stormtrack. There is a lack of accountability and communication gap. Yes, it is useful to have others give input; however it doesn’t get the job done in the long run.
I think the problem is people have been frustrated with this issue not being resolved in the two years since it started. No one knows or sees anything on the backend being done. All they see is what is being said in a “forum” style response, which at times has been less than empathetic by some on the SN board. Coming from someone that has worked in the customer service industry for over fifteen years, anytime you don’t empathize, assure, and understand where the user or customer is coming from, everyone suffers externally and internally as well.
@John Wetter do you have any ideas left on how to troubleshoot this issue with APRS?
At this point we can't find what is making it unstable. We go to troubleshoot and there is data there... It's reported down... We go to look again and there is data... So at this point we just aren't able to track down the source of the problem. I'll admit it, the APRS one has stumped us. Ryan and I have certainly been spending time on it. We've changed out how we are authenticating to the data source and thought that fixed it but then the reports started again. Then we changed out how the data is being parsed and that seemed to fix it but then didn't... We've talked about putting a watcher on the data but we see data moving, but apparently yours either drops out, or a portion of the feed does, or some state where not all of the data stops moving so there isn't something we think we can even watch to identify the issue, troubleshoot and correct.
We were talking about options at ChaserCon when we were both there in person. We assume there is likely some worker process that was running on the AH side and when we did the service separation a year ago something didn't carry over. There are some pretty significant system things we're changing right now to help scaling for this coming year, and we are evaluating what kind of support we can offer for APRS going forward.
As far as support over-all, Yes, I don't monitor this as much in the off-season, but April to October I'm here pretty much every day, or at least a couple days a week. We can always improve and I welcome constructive criticism. Obviously this is a stubborn issue we just can't seem to find the real root cause of. I guarantee you that we've been investing time in to it though.
We were talking about options at ChaserCon when we were both there in person. We assume there is likely some worker process that was running on the AH side and when we did the service separation a year ago something didn't carry over. There are some pretty significant system things we're changing right now to help scaling for this coming year, and we are evaluating what kind of support we can offer for APRS going forward.
As far as support over-all, Yes, I don't monitor this as much in the off-season, but April to October I'm here pretty much every day, or at least a couple days a week. We can always improve and I welcome constructive criticism. Obviously this is a stubborn issue we just can't seem to find the real root cause of. I guarantee you that we've been investing time in to it though.
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
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?
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...
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.