Hello Matthew,
On Monday, March 9, 2020 at 10:26:56 AM UTC-4, mwall wrote:
>
> bill,
>
> for hardware that can be configured to send data in different unit types,
> you have to either:
>
> a) in the driver initialization, set the hardware to the units that you
> want, then hope that no one chang
bill,
for hardware that can be configured to send data in different unit types,
you have to either:
a) in the driver initialization, set the hardware to the units that you
want, then hope that no one changes it while the station is running
or:
b) in every loop packet check the unit type for e
Hello Tom,
On Sunday, March 8, 2020 at 10:33:06 PM UTC-4, Tom Keffer wrote:
>
> All units within a packet must use one of the three weewx unit systems,
> US, METRIC, or METRICWX. You can change from packet to packet, but not
> within a packet.
>
Yes, that's what I understand from looking at man
Well, I did say, "if possible!"
In your case, it does make sense to convert to a common unit system and
keep everything together in one packet.
On Sun, Mar 8, 2020 at 9:26 PM John Kline wrote:
> I agree that, all things being equal, a driver should just pass it on; but
> this is not that case.
I agree that, all things being equal, a driver should just pass it on; but this
is not that case.
There won’t be any meaningful loss of precision for the double conversions. As
such, the alternative, splitting into separate packets, is an unnecessary
complication even without factoring in that
Yes. A good driver makes minimal interpretations about the data it is
seeing. If possible, it should just pass it on.
On Sun, Mar 8, 2020 at 9:03 PM John Kline wrote:
> This isn’t the general case. I find it difficult to see the harm in
> converting to and fro for some cases. Are you worried a
This isn’t the general case. I find it difficult to see the harm in converting
to and fro for some cases. Are you worried about loss of precision?
> On Mar 8, 2020, at 8:45 PM, Thomas Keffer wrote:
>
>
> As you concluded, it's generally best to keep the unit system as close to the
> "nativ
As you concluded, it's generally best to keep the unit system as close to
the "native" unit system of the hardware as possible.
-tk
On Sun, Mar 8, 2020 at 8:32 PM Bill Burton wrote:
> Hello,
>
> On Sunday, March 8, 2020 at 4:01:53 PM UTC-4, John Kline wrote:
>>
>> Since you are writing the driv
Hello,
On Sunday, March 8, 2020 at 4:01:53 PM UTC-4, John Kline wrote:
>
> Since you are writing the driver, have you considered performing the
> necessary conversions so that the driver returns US or metric (i.e., one or
> the other, not a mix)?
>
Yes, good question. I suppose it could be done
All units within a packet must use one of the three weewx unit systems, US,
METRIC, or METRICWX. You can change from packet to packet, but not within a
packet.
You could emit a different packet for each observation type, but you could
miss out on some calculations. For example, to calculate dewpoi
Since you are writing the driver, have you considered performing the necessary
conversions so that the driver returns US or metric (i.e., one or the other,
not a mix)?
> On Mar 8, 2020, at 12:57 PM, Bill Burton wrote:
>
>
> Hello,
>
> I'm implementing a driver for the Columbia Weather Syste
Hello,
I'm implementing a driver for the Columbia Weather Systems MicroServer that
supports a variety of their weather stations including the Pulsar 600. So
far I have the driver polling the station reliably under WeeWX 3.9.2 under
Python 2.7 and 4.0.0b13 under Python 3.6.
However, the issue I
12 matches
Mail list logo
