I have been reading that.
Other parameters that are available on some weather station units include:
L = luminosity (in watts per square meter) 999 and below.
l (lower-case letter “L”) = luminosity (in watts per square meter)
1000 and above.
So, given that, should you be using “l”? And what about wind direction and speed?
Maybe you know this. I changed the data I send and I see my Icon changed. Mine used to be just like yours. Now look at it.
This is the latest document even though it’s 18 years old.
ftp://ftp.tapr.org/aprssig/aprsspec/spec/aprs101/APRS101.pdf
After reading pages 62 to 67, over and over, I finally decided on this format:
FW3820>APRS,TCPIP*:/140158z3936.18N/10507.13W_356/002g004t080r000p004P000h17b08183L000eWFArchive_1.6.12_WeatherFlow
This part “APRS,TCPIP*:”, I am still reading about.
One more note: I cannot find where “e” for equipment is documented.
No idea. What did you change that caused the icon change? Maybe it’s the symbol value between lat/long and wind data? I’m using an ‘_’ which if I’m reading it right in the symbol table means:
_ DWz 63 WX Stn with digi (green) [w/ ov’lay]
looks blue to me, but whatever…
I wonder if it even matters what we put in the APRS software type of Unit type fields. That seems to be something specific to the APRS protocol and I think we’re just trying to get the data past the protocol checks, but it’s not actually going through anything that actually uses the APRS protocol anymore.
I changed the wind direction and speed. Go figure. I’m still testing and trying to figure what is going on.
Now I’m trying to figure out why so many packets go missing. there are times when several packets make it and then it seems the next 5 or 6 packets get lost.
This is interesting.
FW3820>APRS,TCPXX*,qAX,CWOP-1:/171200z3936.18N/10507.13W_000/000g000t059r000p000P000h45b10165L000eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-6:/171210z3936.18N/10507.13W_006/001g001t060r000p000P000h43b10166L004eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-1:/171220z3936.18N/10507.13W_350/001g002t061r000p000P000h41b10166L004eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-6:/171236z3936.18N/10507.13W_004/000g002t061r000p000P000h41b10168L130eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-2:/171247z3936.18N/10507.13W_331/000g001t061r000p000P000h41b10168L508eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-1:/171252z3936.18N/10507.13W_349/000g001t061r000p000P000h41b10169L788eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-6:/171313z3936.18N/10507.13W_000/000g000t061r000p000P000h44b10172l2868eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-1:/171323z3936.18N/10507.13W_000/000g000t060r000p000P000h46b10174l4641eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-6:/171355z3936.18N/10507.13W_000/000g000t060r000p000P000h47b10178l7471eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-1:/171400z3936.18N/10507.13W_000/000g000t061r000p000P000h48b10177l14071eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-1:/171410z3936.18N/10507.13W_000/000g000t061r000p000P000h47b10178l17303eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-1:/171416z3936.18N/10507.13W_000/000g000t062r000p000P000h46b10179l18722eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-6:/171431z3936.18N/10507.13W_000/000g000t063r000p000P000h44b10181l23217eWFArchive_1.6.12_WeatherFlow
FW3820>APRS,TCPXX*,qAX,CWOP-1:/171447z3936.18N/10507.13W_000/000g000t064r000p000P000h42b10181l28028eWFArchive_1.6.12_WeatherFlow
The number of packets sent verses recorded it way too low
11 hours UTC sent 20, recorded 5
12 hours UTC sent 20, recorded 6
13 hours UTC sent 20, recorded 3
14 hours UTC sent 20, recorded 5
How often are you sending data? APRS and CWOP specs used to discourage sending more than once every ten minutes, but have apparently been relaxed a little to once every five minutes recently…
Per their instructions 5 minutes after the last packet was sent.
I actually send it 310 seconds after the socket disconnects.
Checking this thread and decided to do a little preliminary research on what it entails to join CWOP so that I can share this great weather data that I am now in possession of. After reading what you folks are going through and what CWOP requires, it appears to be many hoops to jump through and lots of red tape with a generous sprinkle of government oversight. Can’t they just glean our data which is already online and publicly accessible? Can you CWOP participants give me a brief summary, in layman’s terms, what I would need to do to contribute? Thanks !!
First you get an ID, then you just send the data. It’s really simple.
To me it sounds intimidating. Data packet rates, third party software, reconfiguring settings, etc…Doesn’t sound easy at all. I did notice comments about incorporating CWOP into the WF app like they do with WU. Wouldn’t that be even easier? Like pushing the big red EASY button at Staples.
If you are listening Weather Flow, make a CWOP option under the public data tab of your app.
They have said on multiple occasions that reporting to various web sites is purely the realm of third-party apps. I personally recommend weewx because it can send to anything via multiple mediums short of carrier pigeons, but it is most definitely not a point-and-click experience to get it running. Meteobridge is a simpler option, assuming that you can follow their directions to flash it into a cheap router and not have to pay Ambient Weather’s North American retail price for a pre-flashed unit…
Much too complex of an endeavor for me.
I guess that my question would be why do they support a data link for WU ? I am not a developer and have no idea how hard or easy it would be for WF to include CWOP as well as WU.
Probably because at one time it was ‘the’ place for an amateur site to forward to.
I understand. I allow public data on WU and would support WF if they incorporated CWOP into the app. I am not willing to go through all the hoops to make it available to CWOP via their current method and standards. WAY too involved for me. As said, if the WF app developers could just make that one little toggle setting for CWOP.
If you would run a $10 raspberry-pi zero-w with a $5 SD card and a $5 USB power supply and spend an hour or your time, you’d be uploading to CWOP right away as long as you can edit ‘one’ line into ‘one’ config file. If that’s too much work for you, I don’t know what to say.
WF has been pretty clear for months that the app is what the app is, and they’re not going to spend engineering and support time on it to add in a bunch of features in the forseeable future.
At 3x the cost of a pi zero-w running “somebody’s” WF UDP listener driver that works pretty darn well…
Thank you for the input