WD not working as client for an APRS weather station

Ask a Question
, , ,
1

WD 10.37Q b00, but it doesn’t work on earlier versions neither.

WD works fine in client mode over the internet if reading a clientraw.txt file. But I want to capture data from an APRS feed. So I configure WD as stationless, and TCP/IP client/server settings to read realtime data from internet as an APRS feed, station ID DW4743. WD does not read this feed.

Feed URL’s are working fine too, I can even see these messages on the WD’s WS2500 screen used to debug:

“getting aprs dta from DW4743 Location”
Feed URL with recent data: DW4743 Location

Option “Raw data” ticked:
“getting aprs dta from Raw Weather for DW4743”
Feed URL with recent data: Raw Weather for DW4743

No data shown on WD.

2

Please, any help on this? Can anyone cross-check with me this feature? I’ve read in older threads there are some people using it, picking up data from APRS feeds to populate WD.

Thank you.

3

Still here trying to populate WD with an APRS feed, I don’t know if I have to set up any other thing than stationless and client settings. Saving and restarting with every change, but WD does not read the feed.

4

I did some work on the client TCP/IP with the new compiler version (was not working due to a change with the new compiler)
so you should be using the latest build and not build 00

5

Thank you very much Brian. Downloaded and installed the new compiler version build 02, Version on 23 November 2010 - 19:51:29. Still does not work. Attached my client configuration screen:

wdclientsetup.png
wdclientsetup.png908×994 35.2 KB

6

does 10.37P build 44 work?
I think the problem is that findu.com does not allow this feed to occur any more and blocks this access now

however, is there any data in the file
clientviewerrawdata.txt
where WD is installed?

7

No, it does not work neither.

I think the problem is that findu.com does not allow this feed to occur any more and blocks this access now

I don’t know so much about this, but the query to findu.com seems to work:
Raw Weather for DW4743

however, is there any data in the file clientviewerrawdata.txt where WD is installed?

No, it is just a blank 4 bytes file.

In case findu.com does not allow the feed, would WD use aprs.fi instead? You can get raw, hex or decoded data with a HTTP query:
Login – aprs.fi – live APRS map

Or even make a direct aprs.fi database query with an api key. Format: http://api.aprs.fi/api/get?name=dw4743&what=wx&apikey=APIKEY&format=json (API kei needed).

More on aprs.fi API: aprs.fi Application Programming Interface – aprs.fi – live APRS map

8

I will do some testing in use that URL instead

9

I see the problem
you need to use DW and not dw for the call sign in the setup in WD
then it works via findu
(every 100 seconds (fixed time period, to not hit findu too hard)
this will make it work with the older 10.37P build 44

testing with the new compiler version here now (as I think there is a problem with ansistring)

10

use a new .zip update, ready now (I had to change the way the text file was read in (due to LF’s in use (due to a change in the components used with the new compiler))
and change to DW instead of dw for the call sign setting
ie
DW4743
and do not have ultimeter raw data ticked,only have ticked,its a aprs data feed (as well as have ticked data is from over the internet)

and it works :slight_smile:
(updates every 60 seconds)

11

New .zip installed. It works the first time, but following readings does not update WD data. Clientviewerrawdata.txt is ok, growing in size with new updated rows.

Here is what you can see under WS2010 screen:

getting aprs data from Raw Weather for EA1JL
10154
findu rain 000
new findu rain 0.0
old findu rain 0.0
change in rain amount0.0
getting aprs data from Raw Weather for EA1JL
10154
findu rain 000
new findu rain 0.0
old findu rain 0.0
change in rain amount0.0

And so on…

12

I’m not sure of what I said before. Now it seems to upgrade, big latency over internet or even findu.com itself. I’ll check it for a couple of days. Thank you very much Brian :slight_smile:

13

Brian, I think I’ve found the “latency” reason: WD reads APRS data from findu.com this way:

http://www.findu.com/cgi-bin/rawwx.cgi?call=EA1DAX&length=1&start=1

This gives this result:

EA1DAX>APRS,TCPXX*,qAX,CWOP-3:@250803z4319.98N/00822.18W_135/002g005t040r000P000h99b10165eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-1:@250808z4319.98N/00822.18W_135/003g005t040r000P000h99b10167eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-2:@250813z4319.98N/00822.18W_180/004g007t040r000P000h99b10165eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-3:@250818z4319.98N/00822.18W_135/002g007t040r000P000h99b10165eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-1:@250823z4319.98N/00822.18W_180/002g006t040r000P000h99b10167eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-2:@250828z4319.98N/00822.18W_180/003g006t040r000P000h99b10168eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-3:@250833z4319.98N/00822.18W_135/003g005t042r000P000h99b10167eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-1:@250838z4319.98N/00822.18W_135/004g006t043r000P000h99b10168eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-2:@250843z4319.98N/00822.18W_135/004g007t044r000P000h99b10167eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-3:@250848z4319.98N/00822.18W_135/002g007t046r000P000h99b10167eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-1:@250853z4319.98N/00822.18W_180/004g008t046r000P000h99b10168eCumulusEW
EA1DAX>APRS,TCPXX*,qAX,CWOP-2:@250858z4319.98N/00822.18W_135/002g008t045r000P000h99b10169eCumulusEW

But WD seems to read the first row (the older one) and not the last one. That’s why I have the same data for long periods of time, even when APRS data is updated by findu.com every 5 minutes as you can see. Any way to solve it?

And some more minor bugs I’ve found: not all weather stations report the same data fields. In the example above the field “p000” is missing (last 24h rain). So I think WD is parsing data in the wrong way, eg: barometer & rain (see attached pic)

Another thing: as long as findu.com does not allow data update intervals below 5 minutes, WD would let set up to 300 seconds on the interval time selector, so we won’t “hurt” too much to findu.com.

wdaprs.png
wdaprs.png808×592 37.7 KB

14

I should be able to wrangle that today hopefully
( In between school trips, school camps, etc (very busy time of year!!))

15

It’s easy for us Northerners to forget that you are basking in the sun at this time of year :lol:

16

Absolutely… snow warning here for the next three days. Don’t worry Brian, I’ll wait :slight_smile:

17

sorted in a new .zip update, ready now

18

Can’t read anything now :frowning:

These are the clientviewerrawdata.txt from 3 different stations:

EA1AQE-8>APU25N,ED1YAX-3*,WIDE3-2,qAS,EA1EOL-10:@260808z4321.55N/00825.20W_225/000g007t043r000p…P002h89b10080 WX STATION A CORUNA {UIV32N}
EA1AQE-8>APU25N,ED1YAX-3*,WIDE3-2,qAS,EA1EOL-10:@260838z4321.55N/00825.20W_180/000g004t045r000p…P002h88b10080 WX STATION A CORUNA {UIV32N}

EA1AML>APU25N,TCPIP*,qAC,T2SPAIN2:@260748z4243.39N/00639.18W_360/000g000t023r000p…P000h83b10184 /VEGA DE ESPINAREDA
EA1AML>APU25N,EC1H-12*,WIDE3-2,qAR,EA1GGZ-1:@260801z4243.39N/00639.18W_045/000g001t023r000p…P000h84b10185 /VEGA DE ESPINAREDA
EA1AML>APU25N,EA1A-3*,WIDE3-2,qAR,EB1AJP-1:@260811z4243.39N/00639.18W_225/000g000t023r000p…P000h83b10186 /VEGA DE ESPINAREDA
EA1AML>APU25N,TCPIP*,qAC,T2SPAIN2:@260818z4243.39N/00639.18W_045/000g000t023r000p…P000h83b10185 /VEGA DE ESPINAREDA
EA1AML>APU25N,EC1H-12*,WIDE3-2,qAR,EA1GGZ-1:@260821z4243.39N/00639.18W_135/000g000t023r000p…P000h83b10185 /VEGA DE ESPINAREDA
EA1AML>APU25N,EA1A-3*,WIDE3-2,qAR,EB1AJP-1:@260831z4243.39N/00639.18W_180/000g001t024r000p…P000h83b10187 /VEGA DE ESPINAREDA
EA1AML>APU25N,EA1A-3*,WIDE3-2,qAS,EA1URO-10:@260841z4243.39N/00639.18W_135/000g001t024r000p…P000h83b10187 /VEGA DE ESPINAREDA

EA1URO-8>APRS,TCPIP*,qAC,T2SPAIN:@260809z4219.25N/00752.00W_090/002g004t032r000P000h99b10048eCumulusEW
EA1URO-8>APU25N,ED1YBK-3*,WIDE3-2,qAR,EB1AJP-1:@260810z4219.15N/00751.60W_090/001g004t031r000p…P000h99b10094 / WX info (URO) {UIV32N}
EA1URO-8>APRS,TCPIP*,qAC,T2SPAIN:@260839z4219.25N/00752.00W_090/002g005t032r000P000h99b10049eCumulusEW
EA1URO-8>APU25N,WIDE3-3,qAR,EB1AJP-1:@260840z4219.15N/00751.60W_090/001g005t032r000p…P000h99b10095 / WX info (URO) {UIV32N}

19

i my test, which worked, there was data like this

DW4743>APRS,TCPXX*,qAX,CWOP-2:@260653z4306.87N/00727.82W_220/002g003t032r000p006P000b10167h99L0000.WD 31

for when using the DW4743 station

I have WD looking for a line starting with DW or CW

20

Ah, ok. It works with my own station (DW4743), but APRS data come from many other callsigns other than CWOP, remote weather stations connected to a TNC, which is my goal. I see the callsign has 6 characters max. Sometimes is longer (EA1URO-8) but calling the base callsign (EA1URO) you get data as well. Would it be possible?

O even better: assume the callsign is the first n characters until the “>” char is found.