Brian, I thought I would start a topic for the ‘WD direct connect to APRS Server’ stationless feature. Now that findu.com is not a viable solution for data polling, this would the the best route to take.
WD already has the APRS Server socket / telnet connection code in place… hopefully this wouldn’t require a huge effort.
WD would need a new stationless option that would allow you to specify the APRS Server to connect to along with the connection string which would allow you to limit the number of APRS reports based on the connection parameters. i.e. you could specify that you only want reports from a certain radius based on long/lat and or use connection params to limit reports to a specific callsign / station. You would also ‘obviously’ need to specify the station callsign that you were interested in for the WD data… and type of data… i.e. Peet Bros Hex format etc… (you already have the Peet Bros Hex format in place based on the findu.com implementation)
Brian, I thought I would follow up on this feature suggestion. It’s been awhile since the polling issues related to findu.com happend at the first of the year. Are you still thinking about working on the direct APRS server connect feature as a stationless option in WD? I still think it would be a great solution for building WD websites based on remote APRS wireless weather stations. Getting findu.com out of the loop would be a big improvement.
hi
if you go to control panel, CWOP setup, then click on the tab, listen to other data, and then enter your call sign
does your data show up there eventualy?>
what is your call sign to listen to?
humm, if i click on , listen to the data, i just get
Hi Brian, sorry about the delay, I haven’t check my messages for a couple of days.
You need to log on to an APRS server that supports filters. I was able to login to arizona.aprs2.net on port 14580 (the standard port that allows filters)
WD will only need read access, so the login is pretty clean, try this using telnet from the command line:
Connect to a server/port that supports filters:
telnet arizona.aprs2.net 14580
Login with a callsign and other required info, including a filter command that will filter 500 km around KE7CXV’s last known location:
user KE7CXV pass -1 vers WD 1034 filter f/KE7CXV/250
Once you are logged in, you will start to see traffic 250km around KE7CXV’s last know position in this case!
I didn’t have a lot of time this evening, but does this help? You can see how those login params work after you look at the http://www.aprs-is.net/valid.htm link above. i.e. the -1 gives you read only access… WD would need to have user defined fields for the connecting callsign, valid APRS password… it would also pass WD as the connecting app and WD’s version number etc… and then a user supplied filter command.
Let me know if this helps… I think you have most of the connection code ready to go… it’s just a matter of getting the APRS server login and connection string going… maybe you have all this down too?
ops., my mistake
i am getting data now
CW1717>APRS,TCPXX*,qAO,T2WXCWOP:@190633z4029.77N/11122.60W_102/005g005t027r000P000p002h72b10242v31
and its showing up OK in WD in the listen to the data section, so half my work is done already!
caught your report:
KE7CXV>APN390,KF6RAL-11*,WIDE2-1,qAo,KD7LRJ:$ULTW00620039016D076027FCFFFFC64E000103AA006B05910000005D
i will have to add ability to use that ultimeter data (i already have that code in WD, so thats OK)
I will do that…but I have to eat now…LOL
under control panel, CWOP setup, then go to the tab to listen to the aprs data
then set the call sign
click on connect
then click on listen for this call sign now
and then tick, use to update wd’s data and tick, hex mode
then click on save data
(and I have tested it all works on restart of WD)
then once that call sign data is found the data will be updated on the screen
i did a soak test for 5 minutes, and it looks good
There’s something you can add to the filter that allows you to just get weather report packets (I think it’s “t/w” but that’s without looking at the docs).
Brian this is great news! I can’t wait to try it out tonight.
Chris is right, there is a filter command to only look at reports from a specific station. Here is a sample using the Budlist Filter:
user KE7CXV pass -1 vers WD 1034 filter b/KE7CXV
This is better, because you totally limit incoming traffic to this specific station. A very friendly use of the bandwidth. Keep in mind that if the station has SSID attached to the callsign, you would need to filter for that too… i.e. b/KE7CXV-11 or you could use a wild card on the budlist command… i.e. b/KE7CXV*, this would pass everything that started with KE7CXV
Using the budlist command is the way to go in this case… thanks for pointing us in that direction Chris.
I haven’t looked at your changes yet, but it would be really nice if you allowed the user to set the filter string and also the login information. In my case, I have a valid login for my callsign and it’s nice to see that you are verified when you login to the server. Maybe you have these changes in there already?
I think it would still be useful to add on the t/w filter (if that’s correct). Without it, WD will see all packets from the station but it only wants to see weather reports. There isn’t any point seeing position or other type of reports because WD can’t do anything with those.
Chris, I didn’t have a lot of time to test… but when I did test the t/w filter option… along with the budlist option b/KE7CXV in this case… the t/w option would pass all weather records… it stopped the budlist option from working?? If you can figure out how to use the t/w weather filter along with the budlist option, this would result in the lowest bandwidth connection. However, the position reports are trivial, WD has to toss/ignore a minor amount of data. The APRS-IS echo reports are the most annoying.
Brian, on another topic… you have have this logic already in WD… will WD automatically reconnect if the connection is lost to the APRS server?
You could try using an exclusion filter to block all packet types apart from weather packets and then filter on budlist to get just the weather packets you want, e.g.
b/KE7CXV -t/pointqsum
The exclusion filter acts first, ie. it drops all but the weather packets and the budlist would then (presumably) only let KE7CXV (weather) packets through. I haven’t tried this myself, but from the docs it looks like it should work.
I just tried your suggestion Chris… it works… nothing but weather for the budlist station comes through… i.e. I logged in with this connect string:
user KE7CXV pass -1 vers WD 1034 filter b/KE7CXV -t/pointqsum
I could not get t/w along with b/KE7CXV to work.
Most effective use of bandwidth. Brian, this is the way to go… however, I still think it would be nice to let the user specify the login / filter information that overrides the default.
Brian, I have had 10.34r running since last night and it looks like it’s working well. I removed the previous options in the ftp/client setup dialogs where you would setup the polling options for findu.com. I assume I needed to do that.
I lost a hard drive on my machine where WD is running for my remote KE7CXV station, so the WD web output is nothing special right now: http://www.nurcac.org/wx (has been using the direct APRS server feed feature since last night)
It seems to be working fine. How does the APRS-IS server connection logic work? Is there reconnect logic built into WD if the connection to arizona.aprs2.net is lost?
