Hi Clay,
Here is some pertinent text and a sample code file that talks about socket
feeds in Wview.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Clay Jackson
Sent: Monday, February 02, 2009 3:14 PM
To: Xastir - APRS client software discussion
Subject: Re: [Xastir] db2APRS
Hmmm - you're quite right. Turns out there's actually a bug in the
code. The Usage description says '-b'; but, the code looks for '-
d'. I'll see about fixing that in a future pass. But, as I
explained earlier, even if you do change the name of the database,
unless the tables created by wview are EXACTLY same (table names,
column names, etc) as meteo (which I strongly doubt); it won't do you
any good.
The whole 'read a different database and write something to a socket'
is really kind of a kludge anyway (and requires coding for specific
weather stations/programs); so I'm starting to focus my time right now
on setting up some more generic methods (XML or at least METAR based)
that would allow different types of stations/programs to use a more
standard interface.
Can wview put out a file of any sort with current weather in it? If
so, if you can send me a copy of that file, that would give me one
more bit of information.
Thanks!
Clay
=======
On Feb 2, 2009, at 10:01 AM, Barrie McConnell wrote:
> I'm not too savvy in the programming world...I kludge my way through
> it. I'm
> running SuSE 11.1. I guess I didn't really clarify what I was
> meaning when I
> said the -b option didn't work... the program doesn't recognize the
> option
> -b not that it won't rename it
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Clay Jackson
> Sent: Saturday, January 31, 2009 7:05 PM
> To: Xastir - APRS client software discussion
> Subject: Re: [Xastir] db2APRS
>
> I'd be completely amazed and flabbergasted if it did work; as I said,
> the code is very specific about having the database tables be meteo
> specific.
>
> I just sent Andreas (Meteo author) a set of perl scripts to do
> WeatherUnderground from Meteo - if you're interested in those let me
> know and I can send you a copy. What OS/distro are you using?
>
> Clay
>
>
> On Jan 31, 2009, at 3:57 PM, Barrie McConnell wrote:
>
>> Yes I realize that it was setup for Meteo. Wview also uses a mysql
>> database,
>> the default db name in db2APRS is Meteo, the -b option allows you to
>> change
>> the db name but it doesn't work. I like Wview as you can also output
>> to
>> Weather Underground and Weatherforyou.
>>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Clay Jackson
>> Sent: Saturday, January 31, 2009 5:55 PM
>> To: Xastir - APRS client software discussion
>> Subject: Re: [Xastir] db2APRS
>>
>> I think there may be some confusion here - db2APRS is (at least in
>> this incarnation) is really meteo/Davis specific. The -b option just
>> changes the name of the MySQL database that it looks at for the data.
>> The data still has to be in a MySQL database, with the sdata table
>> that meteo generates/loads.
>>
>> I'm pretty sure that Wview uses a different table structure -
>> unfortunately, since I have a WMII and not a Vantage, I can't test
>> it.
>>
>> I do have a different set of code (being 'alpha' tested now); that
>> takes a WXNOW.TXT file (2 lines, ala the one created by
>> WeatherDisplay) and writes an aprs formatted record to a socket, so
>> that might be an alternative. I'm also playing with a set of code
>> that will take an XML METAR feed and emit an aprs weather string.
>>
>> Clay Jackson
>> N7QNM
>>
>>
>> On Jan 31, 2009, at 8:27 AM, Barrie McConnell wrote:
>>
>>> I have tried to use the -b option to change the database and the
>>> program
>>> says that it is not a valid option. Has anybody had any success with
>>> this?
>>>
>>> Also has anybody tried to use Wview in lieu of Meteo with any
>>> success. I am
>>> wondering if the database fields are the same etc?
>>>
>>>
>>>
>>> Barrie McConnell
>>>
>>> KA8UPW
>>>
>>> _______________________________________________
>>> Xastir mailing list
>>> [email protected]
>>> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
>>>
>>
>> _______________________________________________
>> Xastir mailing list
>> [email protected]
>> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
>>
>> _______________________________________________
>> Xastir mailing list
>> [email protected]
>> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
>>
>
> _______________________________________________
> Xastir mailing list
> [email protected]
> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
>
> _______________________________________________
> Xastir mailing list
> [email protected]
> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
>
_______________________________________________
Xastir mailing list
[email protected]
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
13.5 Socket-Based Data Feeds
13.5.1 Overview
For true data feeds, wvalarmd provides a socket server which listens on
port 11011 of the wview server for connections. When a datafeed client
connects on that port, wvalarmd adds the client to the datafeed client
list. Then when loop data is received from wviewd, wvalarmd will write
the loop packet into each datafeed client's socket, preceded by a start
frame sequence. It is a one-way interface and the client may disconnect
at any time by calling "shutdown" followed by "close" to close the
socket. The number of active client connections is only limited by system
resources. The datafeed client will receive the full loop packet as
defined in common/datadefs.h - see the structure "LOOP_PKT".
13.5.2 Configuration
None required for socket data feeds, just the normal PUSH_INTERVAL setup
described above. No alarm entries are required in wvalarm.conf for
datafeed clients.
13.5.2 Client Requirements
The datafeed sockets are regular TCP/stream PF_INET sockets. The general
connection steps (in C) are as follows:
socket (...) // create the socket descriptor
[setup server address and port in socckaddr_in structure]
connect (...)
The client then may add the socket descriptor to an fdset for select
calls, simply block on the socket for reads, however you want to design
it. Other programming language procedures may differ, but the general
approach should be the same.
Normal Processing "Loop":
1) Wait for data on the socket
2) Sync to the start frame sequence: 0xF388, 0xC6A2, 0xDADA, 0xE7CF
3) Read loop packet
4) Process loop packet
5) Goto #1
To disconnect:
shutdown (sockfd, 2)
close (sockfd)
Note: There is a handy new radlib socket API which is illustrated in the
sample datafeed client source code which takes care of most of the
_______________________________________________
Xastir mailing list
[email protected]
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
