Hi Simon,

I am terribly sorry, I completely forgot about your problem, I put your 
previous post aside to sit down and do the maths but never got back to it. 

Does sound like there is a problem, going to need to refresh my memory on 
the interceptor/observer operation. Unfortunately, it will be a tomorrow 
job, late here, won't forget it this time. As for archive records (REC:), 
the interceptor driver only knows how to emit loop packets, it does not 
know how to emit archive records. WeeWX accumulates the loop packets to 
produce an archive record (known as software record generation) which is 
why you will see nothing about archive records in the interceptor debug 
output. You are right in that setting record_generation = hardware under 
[StdArchive] will force WeeWX to obtain archive records from the driver; 
however, if the driver cannot emit archive records WeeWX effectively falls 
back to software record generation and archive records are synthesised by 
WeeWX from the accumulated loop data.

Gary

On Saturday, 25 April 2020 20:20:54 UTC+10, Season Ticket wrote:
>
> Hi Gary,  I've spent some time looking at the log files and focusing on 
> the windgust, still unresolved unfortunately.  
>
> I’m using the interceptor driver,  I looked at the comments in the 
> interceptor driver code which says 
>
> "*The gust measure has resolution of 1.1 m/s (2.46 mph) - one revolution 
> of the anemometer."*  
>
> However the lowest gust value in the LOOP logs is “0.683510010315”.  There 
> must be a units problem here,  I understand that “0.683510010315” 
> usunits=1=mph, displayed in the each log record, and will convert to 1.1 
> km/h,  but the console shows 4 km/h,  so I’m assuming that 1.1 is m/s which 
> converts to 3.96 km/h, very confusing,  but I can get the figures to match 
> even if they don’t make sense to me. Is there a simple explanation about 
> these figures?
>
>  
>
> I notice that the LOOP & debug data for windgust is consistently the same, 
> however debug data does not show the REC: records,  these are only shown 
> from the weewx direct logs. I'm unsure if the interceptor driver is sending 
> the REC: records,  do you know? 
>
> I assume it is as weewx.conf says 
>
> *“[StdArchive]*
>
> *….*
>
> *# Set the following to "software" to force software record generation.*
>
> *    record_generation = hardware”*
>
>
> On Wednesday, 11 March 2020 22:10:40 UTC, Simon Davies wrote:
>>
>> Hi Gary,
>>
>> From my previous table "DB" showed the windGust value.
>>
>> As requested,  I've taken readings from the weewx direct LOOP/REC data,  
>> debug data,  extract from the DB and I've taken a couple of screenshots 
>> from the console.  
>> Time period would be best to take from 21:03 for  approximately 15 
>> minutes,  although the logs cover a larger period.  I've attached 5 files 
>> with this information.  I hope they contain the information you have 
>> requested.
>>
>> I've not checked all of the values myself,  I'll will do after posting 
>> here.
>>
>> loop_hilo is set to True.
>>
>> Many Thanks Simon
>>
>> On Wednesday, March 11, 2020 at 4:11:45 AM UTC, gjr80 wrote:
>>>
>>> Hi Simon,
>>>
>>> I tried setting the debug level to 1 and viewed the syslog.  The units 
>>>> displayed in the log are usunits=16 (which I assume is meters per 
>>>> second?). 
>>>>
>>>
>>> The usUnits decodes are 1 (or 0x01) is US (aka US customary) and uses 
>>> miles per hour for wind speeds, 16 (or 0x10) is Metric with wind speeds in 
>>> km per hour and 17 (or 0x11) is known as MetricWX with wind speeds in 
>>> metres per second.
>>>  
>>>
>>>> I could not understand how these values were used to be stored in the 
>>>> archive database.  
>>>>
>>>
>>> A little background on how units are used within WeeWX. First up the 
>>> database, in weewx.conf under [StdConvert] you have a setting 
>>> target_unit that will either be US, METRIC or METRICWX. This sets the 
>>> database unit system used throughout the database. The default is US. Some 
>>> folks insist on having target_unit set to the units they use natively, 
>>> there really is little value in doing this unless you have specific 
>>> requirements as WeeWX automatically converts to/from the units required (in 
>>> fact I have seen it cause issues variously where database units are used 
>>> (for example specifying QC limits without units), folks forget their 
>>> database units are different to the normal and they can get unexpected 
>>> results). Data coming from drivers, whether they be loop packets or archive 
>>> records can be in any of the three unit systems, WeeWX automatically 
>>> converts any data being saved to database to the target_unit unit 
>>> system. Likewise any archive records or loop packets being processed 
>>> elsewhere by WeeWX could be in any of the three unit systems. Data being 
>>> output in a Cheetah report or plotted by the image generator is 
>>> automatically converted to the units specified by the tag, skin.conf or 
>>> weewx.conf or the defaults as applicable. Bottom line is when analysing 
>>> WeeWX data never assume any units, always check the usUnits value.
>>>  
>>>
>>>> See the table below,  for example 1.1 mps  becomes 1.36 mph.  it should 
>>>> be 2.46 mph using my calculations.  Do you have any ideas why the archive 
>>>> DB has this value?
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>> *time*
>>>>
>>>> *debug data wind gust (mps)*
>>>>
>>>> *debug data usunits*
>>>>
>>>> *console minutes*
>>>>
>>>> *console wind gust km/h*
>>>>
>>>> *DB (mph)*
>>>>
>>>> Mar
>>>>
>>>> 8
>>>>
>>>> 22:40:57
>>>>
>>>> 1.1,
>>>>
>>>> 16
>>>>
>>>> 40
>>>>
>>>> 4
>>>>
>>>> 1.36702
>>>>
>>>> Mar
>>>>
>>>> 8
>>>>
>>>> 22:42:49
>>>>
>>>> 0.0,
>>>>
>>>> 16
>>>>
>>>> 42
>>>>
>>>> 0
>>>>
>>>> 0.68351
>>>>
>>>> Mar
>>>>
>>>> 8
>>>>
>>>> 22:44:57
>>>>
>>>> 1.1,
>>>>
>>>> 16
>>>>
>>>> 44
>>>>
>>>> 4
>>>>
>>>> 2.05053
>>>>
>>>> As mentioned above you usUnits=16 data will be km/hr rather than m/s. 
>>> That still doesn't help things tally. So what is 'DB', is that windSpeed 
>>> or windGust?
>>>
>>> Appreciate the table may make things easy to read but perhaps it might 
>>> help more if you provide the actual loop/archive record output when WeeWX 
>>> is run directly, a copy of the log (with debug set) over the same period 
>>> and a query from the database again covering the same period and your 
>>> recorded observations of the console gain over the same period.
>>>
>>> So when there is some wind around let's run WeeWX directly for about 5 
>>> minutes. At the same time WeeWX is running directly note your wind speed 
>>> values on the station display. Capture the console output (LOOP: and REC: 
>>> data) for the entire period. Take a log extract that covers the entire 
>>> period that WeeWX was run directly.
>>>
>>> Now query the database after finishing the direct WeeWX run. Am assuming 
>>> you are using SQLite as your DBMS. Note you may need to install the sqlite3 
>>> application using sudo apt-get install sqlite3 if not already 
>>> installed. Also assuming your database is named weewx.sdb and it is 
>>> located in /home/weewx/archive (it may be located in /var/lib/weewx 
>>> depending on your WeeWX install method - adjust following command as 
>>> necessary):
>>>
>>> $ sqlite3 /home/weewx/archive/weewx.sdb
>>> sqlite> .headers on
>>> sqlite> SELECT datetime,datetime(dateTime,'unixepoch','localtime'),
>>> usUnits,windSpeed,windGust FROM archive ORDER BY dateTime DESC LIMIT 20;
>>>
>>> that will display the timestamp, human readable date-time, usUnits, 
>>> windSpeed and windGust values for the last 20 minutes (use .quit to 
>>> exit sqlite3). If run within 15 minutes of completing your direct run we 
>>> should have some overlapping data to compare from (1) the loop packets and 
>>> archive records seen by WeeWX (2) the raw data seen by the SDR driver (3) 
>>> your visual observations of the station display and (4) the database. Post 
>>> these four pieces of data.
>>>
>>> One final question, is your loop_hilo setting under [StdArchive] in 
>>> weewx.conf set to True or something else?
>>> Gary
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e9638550-3e1e-412e-aad9-faa9c7a12d1b%40googlegroups.com.

Reply via email to