GW1000 - solar radiation data lost while switching from Interceptor to API driver

[Rainer Lang]

I was running Weewx with the GW1000 interceptor and everything ran smoothly. After downloading and installing the GW1000 API driver v. 0.1.012b and meticulously following the readme instructions, I got the system running - with ONE issue - the solar radiation data had disappeared and would no longer be displayed.

(they are there and sent to Ecowitt.net, WU etc. and are captured by CumulusMX and Meteobridge => it's not a GW1000 console issue, it's obviously a weewx (configuration ?) issue. I have 4 GW1000 type consoles and switched between them to make sure it's not due to the console [with weewxd].

Since midnight the solar radiation picture/graph has completely disappeared.

So I'm wondering what went wrong here ...

Anyone can advise ?

attached the syslog of the driver switch time window and some debug=1 output at the end, the weewx.conf, a screencopy of the missing or mutilated graph and the output of weexd as screencopy and text.

[Graham Eddy]

syslog shows you have mapped 'UV’ from ‘uv’ and ‘radiation’ from ‘solar_radiation’.

my working config has ‘UV’ mapped from ‘uvi’ and ‘radiation’ from ‘uv'

--
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 weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/712d3a95-4fd7-4bbc-9b07-62477f1b2774n%40googlegroups.com.
<syslog.20201216.txt><weewx.conf><weewxd_console_output_GW1000-API.txt><Weewx-radiation-missing-2.JPG><Weewx-radiation-missing.JPG>

[gjr80]

Hi,

The short answer is that radiation (aka solar insulation) or an equivalent is not available via the GW1000 API so the GW1000 driver does not emit it. The reason you see it on Ecowitt pages and WU is that the GW1000 takes what the GW1000 API refers to as 'light' in lux and approximates solar insolation by dividing by 126.7. The GW1000 then uploads this derived value to Ecowitt and WU (and to anywhere else the GW1000 is configured to upload). A similar result can be achieved with WeeWX by having the WeeWX StdCalculate service calculate WeeWX field radiation. This is done by adding an entry for radiation under [StdCalculate] [[Corrections]] in weewx.conf:

[StdCalibrate]

     ....

    [[Corrections]]

        ....

        radiation = luminosity/126.7 if luminosity is not None else None 

The reason the interceptor driver picked up radiation is that the interceptor driver intercepts the the same data the GW1000 uploads to Ecowitt or WU, so the interceptor driver sees the radiation field that was calculated by the GW1000. WeeWX drivers do not calculate/derive observations; rather they decode/unit translate data provided buy the station/sensors only. Calculation of derived observations is taken care of by other WeeWX services, typically the StdCalculate service.

I can't speak for what Cumulus does but I know Cumulus obtains the exact same data from the API that the GW1000 driver does. Cumulus must be set to automatically derive solar insolation from luminosity.

As further background, the GW1000 API emits three 'radiation' related observations; what the API refers to as 'light' in lux, 'UV' in microwatts/square metre and 'UVI' an index from 0-15. Of these observations 'light' corresponds to the WeeWX extended schema field luminosity and 'UVI' corresponds to WeeWX field UV. Consequently, (and by default) these observations are mapped to the equivalent WeeWX field. There is no equivalent to the GW1000 API field 'UV' so the GW1000 driver passes this field through as uvradiation (uvradiation was chosen to distinguish it from WeeWX field UV). Note that uvradiation is not equivalent to WeeWX field radiation.

I am in the process of producing a wiki page for the driver repo to explain this.

Gary

[Rainer Lang]

Thanks, Gary

that was enlightening  😎 - and apart from planning to explain the details more in the wiki (which is highly appreciated),

I suggest to include the above entries to the [[Corrections]] stanza also in the readme file that comes with GW1000 API driver

and also include them - unless already done (I cannot tell as I did the migration to the API driver manually) - in the install process which updates the weewx.conf file.

Great to have knowledgeable people to explain and help !

--

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 weewx-user+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d085a7f5-f83a-445b-82dc-6cd826f25456n%40googlegroups.com.

[Jerry Tesar]

Thank you from me aswell. I received my PWS yesterday, used the GW1000 driver and was about to ask the same question, then I found this.

I have one more question about pressure mapping.

I noticed the driver maps "absbarometer" to "pressure" but the "relbarometer" to "relbarometer" aswell, which as far as I know is not used by default in Weewx.

In the WeeWX wiki I found that it uses "pressure", "altimeter", and "barometer".

Did you make these mappings so that you let the WeeWX recalculate the other parameters automatically from the "absbarometer"? This gives a different result then I have in WS View app (I guess the app only uses offset based on altitude, but weewx actually uses humidity and temperature aswell), now the problem is that the sea-level pressure is reported higher then other stations around me (including METAR), to correct this should I offset the absolute pressure in the WS View app? Or maybe used the corrections in weewx?

I have problem with sending data PWSWeather, not sure what parameter for pressure it sends, but when I open the station on their website, open Observations, there is no reported pressure, then in the dashboard I see some pressure, but it is even higher than the one reported by WeeWX.

Thank you

[gjr80]

Whilst I am happy to document the process to enable the approximation of radiation in the wiki, I am less willing to force calculation of radiation via StdCalculate. Largely because the extension installer is somewhat limited and it uses an all or nothing approach - radiation will be set to calculate for everyone or for no one; the user will have no choice in the matter. The WeeWX wee_config utility is more flexible in that it can be set to prompt the user for input but I believe wee_config's scope is limited the driver stanza only (not the config stanzas for other services in weewx.conf). It may be that we will just have to rely on the user reading some install instructions rather than having them blindly install.

In summary, I will look at what can be done to enable the calculation of radiation on install, but will only implement it if it can be done interactively.

Gary

[gjr80]

Hi,

Yes the default mapping used by the GW1000 driver will map absbarometer to WeeWX field pressure and relbarometer is mapped to WeeWX field relbarometer (though in reality nothing will be done with relbarometer as it is extremely unlikely the user would have field relbarometer in their database schema). This was done deliberately to make use of WeeWX' ability to calculate WeeWX field barometer if absolute or station pressure is known. I fully expect that WeeWX would give a different barometer result to that from the GW1000 as WeeWX compensates for temperature and altitude whereas the GW1000 applies a simple linear offset that does not compensate for temperature.

If having different values for barometer is particularly bothersome for you can force WeeWX to use the GW1000 provided relbarometer as WeeWX field barometer by adding a field mapping to the GW1000 driver config stanza in weewx.conf as follows:

[GW1000]

    ...

    [[field_map_extensions]]

        barometer = relbarometer

You will need to restart WeeWX or do a config reload for the change to take effect.

Gary