Author Topic: DCF77 instead of NTP as time source for weather station  (Read 657 times)

0 Members and 1 Guest are viewing this topic.

Online olicat

  • Forecaster
  • *****
  • Posts: 1515
  • GWxx00, HPx5x1C, WN1900C, WN1980C & WS3800C
    • FOSHKplugin
DCF77 instead of NTP as time source for weather station
« on: October 13, 2021, 04:29:11 AM »
Hi!

Just asked Ecowitt in their forum (not yet approved) the following question:
Quote
There is also a variant of the WH31 with an integrated DCF77 receiver.
What speaks against using the transmitted time as a time source for the stations (e.g. HP3500, HP2551C, GW1x00)?
That would open up the possibility of being able to operate the weather station entirely locally without an internet connection at all.
Request info.
Thanks very much!
What do you think about this possibility?
The WH31 variant I mean is the dnt DNT000005 - it works without any problem with GW1000, GW1100, HP3501, HP2551C - of course only at 868MHz.
I don't know the Fine Offset model number for this sensor yet.

Does anyone with a little more experience with SDR have any idea where and how the time is transmitted via RF? In the default I don't see any differences with rtl_433 to WH31 without DCF77:
Code: [Select]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-10-08 00:16:14
model     : AmbientWeather-WH31E                   id        : 56
Channel   : 5            Battery   : 1             Temperature: 25.1 C       Humidity  : 50 %          Extra Data: cc00000000    Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Regards, Oliver

Offline davidefa

  • Forecaster
  • *****
  • Posts: 436
Re: DCF77 instead of NTP as time source for weather station
« Reply #1 on: October 14, 2021, 05:33:17 AM »
I have such a wh31.
I logged the transmission ( from yesterday 12:16 till today 9:25 )
These are the packets with time information ( each transmitted 3 times ):
Code: [Select]
2:04:43.283> [RSSI-52][full RX]52 28 52 21 10 14 02 04 45 3a 96 00 00 00 00 00 00
2:05:45.284> [RSSI-52][full RX]52 28 52 21 10 14 02 05 47 ac 0b 00 00 00 00 00 00
2:06:47.288> [RSSI-52][full RX]52 28 52 21 10 14 02 06 49 9e 00 00 00 00 00 00 00
2:07:49.283> [RSSI-52][full RX]52 28 52 21 10 14 02 07 51 90 fb 00 00 00 00 00 00

Decoding agrees with what found on: https://github.com/merbanan/rtl_433/blob/master/src/devices/fineoffset.c
Code: [Select]
/**
Alecto WS-1200 V2.0 DCF77 decoder by Christian Zuckschwerdt, documentation by Andreas Untergasser, help by curlyel.
A Thermometer with clock and wireless rain unit with temperature sensor.
Manual available at
https://www.alecto.nl/media/blfa_files/WS-1200_manual_NL-FR-DE-GB_V2.2_8712412532964.pdf
Data layout:
    1111111 FFFFFFFF IIIIIIII B??????? ..YY..YY ..MM..MM ..DD..DD ..HH..HH ..MM..MM ..SS..SS CCCCCCCC AAAAAAAA
- 1: 7 bit preamble of 1's
- F: 8 bit fixed message type (0x52)
- I: 8 bit random sensor ID, changes at battery change
- B: 1 bit low battery indicator
- ?: 7 bit unknown
- T: 10 bit temperature in Celsius offset 40 scaled by 10
- R: 16 bit (little endian) rain count in 0.3 mm steps, absolute with wrap around at 65536
- C: 8 bit CRC-8 poly 0x31 init 0x0 for 10 bytes
- A: 8 bit checksum (addition)

// my correction to the explicative note
- the ..YY..YY should read Yy  Y =  (high nibble) tens of years,  y = ( low nibble ) units of years
- the ..MM..MM should read Mm  M =  (high nibble) tens of months, m = ( low nibble ) units of months
- the ..DD..DD should read Dd  D =  (high nibble) tens of days,   d = ( low nibble ) units of days
- the ..HH..HH should read Hh  H =  (high nibble) tens of hours,  h = ( low nibble ) units of hours
- the ..MM..MM should read Mm  M =  (high nibble) tens of mins,   m = ( low nibble ) units of mins
- the ..SS..SS should read Ss  S =  (high nibble) tens of secs,   s = ( low nibble ) units of secs


P.S.
So my pc is couple of seconds late ( 1.71secs )
« Last Edit: October 21, 2021, 11:31:18 AM by davidefa »

Offline broadstairs

  • Forecaster
  • *****
  • Posts: 853
Re: DCF77 instead of NTP as time source for weather station
« Reply #2 on: October 14, 2021, 05:43:46 AM »
I can understand why Froggit does this but as far as Ecowitt doing it generally the DCF77 time signal is only of use for Central European Time, so for the rest of the world either additional customisation in the received is needed or it is limited to only the EU!

Stuart
Ecowitt GW1003 with ultrasonic wind gauge, lightning sensor and PM2.5 sensor with Personal Weather Tablet as a console.

Online olicat

  • Forecaster
  • *****
  • Posts: 1515
  • GWxx00, HPx5x1C, WN1900C, WN1980C & WS3800C
    • FOSHKplugin
Re: DCF77 instead of NTP as time source for weather station
« Reply #3 on: October 14, 2021, 05:52:50 AM »
Hi!

So everything is there, only the station would have to learn to deal with these additional fields. Fine Offset can already do this with the HP3000 - this station has no WIFI and therefore no possibility of using NTP.
Technically, the station could first use NTP and if it does not receive a response, use the DCF time.
I'm curious to see if Ecowitt will go into that.

Quote
the DCF77 time signal is only of use for Central European Time, so for the rest of the world either additional customisation in the received is needed or it is limited to only the EU!
You're right.
But for other areas there are other time services which already supported through the sensors (e.g. WWV for US):
Quote
7. RCC with WWVB, DCF, MSF for Selectable;

The station only needs to evaluate the filled fields of the sensor.
So the solution could work globally. And if no time is available, there is no worse situation than now without NTP.

Oliver

Online Rover1822

  • Forecaster
  • *****
  • Posts: 1989
    • Mini Wind and Solar Data project
Re: DCF77 instead of NTP as time source for weather station
« Reply #4 on: October 15, 2021, 08:10:11 AM »
I just would like a configurable NTP on the consoles. I Run my own NTP server which my security cams get their time from.
There are atomic clock solutions for just about any platform including PI, along with NTP server software, so you could get away entirely from an internet connection.

Bit tougher on the configuration and assembly , but another solution.
Ambient:
  WS-2000
  PM 2.5(2)
  WH31B(2)
  WH40E
  WH31P
EcoWitt:
  GW1100
  GW1000(4)
  WH31(2)
  WH57
  WH51(12),
  WH40
  WH5360B
  WN34S
  WittBoy WS90 + GW2000
  WS90 (other one) + GW1100
Personal Sites: Weather Cam

Offline mahi

  • Member
  • *
  • Posts: 7
Re: DCF77 instead of NTP as time source for weather station
« Reply #5 on: October 15, 2021, 04:54:00 PM »
I just would like a configurable NTP on the consoles. I Run my own NTP server which my security cams get their time from.

Well, you can do that even when the device does not support it, but it requires a router/firewall with features that may not be present in dumbed-down consumer hardware:
  • Option 1: DNS overrides. Override the DNS name(s) of the NTP server(s) used by the device with the IP address of your own NTP server. The drawback of this method is that you'll need to monitor the network traffic to learn the NTP server(s) used by the device and the servers may change with a firmware update. For the GW1000/WH2650 with the latest firmware the NTP servers appear to be pool.ntp.org and time.nist.gov. Worse is when the device does not use your own DNS but directly gets the IP addresses from public DNS servers. Luckily that is not the case with the GW1000/WH2650.
  • Option 2: Firewall port redirection. Make a firewall rule intercepting all outgoing traffic over port 123 (NTP) and redirect it to your own NTP server. Even if the device uses public DNS servers or hardcoded NTP server IP addresses, the NTP traffic will now always go to your own NTP server. If you run your own DNS server you can also use the same trick on port 53 to force all devices to use your own DNS server.
My WH2650 is completely isolated from the Internet and I use the second method to redirect the NTP requests to my own NTP server.

Online olicat

  • Forecaster
  • *****
  • Posts: 1515
  • GWxx00, HPx5x1C, WN1900C, WN1980C & WS3800C
    • FOSHKplugin
Re: DCF77 instead of NTP as time source for weather station
« Reply #6 on: October 18, 2021, 05:30:31 AM »
Hi!

Quote
I just would like a configurable NTP on the consoles.
Of course, I would also like to have a configurable NTP server - most routers already have one built in.
With radio time synchronization, however, you could serve all those users who do not have Internet access or who consciously want to do without it because the station should only be operated locally.
And no further configuration would be necessary at all.
In addition, the "radio clock" feature is also very nice in the marketing texts ...
But: still no answer from Ecowitt.
In general, I have the impression that Ecowitt's communication has decreased in the last few weeks. I don't know whether this has something to do with a changed strategy, Covid-19, the energy crisis or just very heavy workload.
Inquiries from me by email are almost never answered at all. Even in their forum there are hardly any contributions from Ecowitt. And two of my contributions have been waiting for approval for a week or two.
Am I an isolated case there? Or do you have similar feelings? Maybe we are just spoiled by the extremely helpful and fast communication so far?

Oliver

Offline gszlag

  • Forecaster
  • *****
  • Posts: 431
  • ..have you calibrated your barometer today?
    • Michael's Bay - Manitoulin Island weather
Re: DCF77 instead of NTP as time source for weather station
« Reply #7 on: October 21, 2021, 10:46:17 AM »
Hi!

But: still no answer from Ecowitt.
In general, I have the impression that Ecowitt's communication has decreased in the last few weeks. I don't know whether this has something to do with a changed strategy, Covid-19, the energy crisis or just very heavy workload.
Inquiries from me by email are almost never answered at all. Even in their forum there are hardly any contributions from Ecowitt. And two of my contributions have been waiting for approval for a week or two.
Am I an isolated case there? Or do you have similar feelings? Maybe we are just spoiled by the extremely helpful and fast communication so far?

Oliver
Encountering a very similar issue. My Osprey rain gauge went dead..initial response was fast and helpful..ordered a part, no confirmation, folowup email enquiry..no response. Could be that none of my emails ever reached Ecowitt . I will try once more.

Sure, times are tough and some things may be outside their control. If Ecowitt is crushed with volumes of product and parts orders and order/parts/support inquiries are not responded to - then the solution becomes increasingly obvious. Hire more staff - even temporary staff to manage the volumes.

This is a great example of good/bad news. Good news. Business is growing exponentially. Bad news. Business can't cope..risking sales as consumers can and will vote with their feet if these issues are not attended to.

In the end though,for most consumers and businesses, it all boils down to after sales service and support. You may have a fantastic product but if parts, service and support are not available - it reflects poorly on the company.
Ambient Weather WS-2000
Ecowitt GW1000/GW1100
Ecowitt WS68: Anemometer, UV/solar
Ecowitt WH40: Rain gauge
Ecowitt WH57 Lightning sensor
Ecowitt WH32E: Outside T & H sensor
Stratus Rain Gauge (manual)
Raspberry Pi 3B+ (WeeWX/CumulusMX)
Raspberry Pi Zero 2W (WeeWX/MQTT/Belchertown)
---
Barometer wiki: http://meshka.eu/Ecowitt/dokuwiki/doku.php?id=barometer#barometer
---
http://weather.glenns.ca (pwsdashboard - live)
http://weewx.glenns.ca
http://glenns.ca/cumulusmx2/index.htm
---
Uploading to: AWN, ecowitt.net, Weather Underground, PWSweather.com, AWEKAS, Windy.com, WOW

Offline plunet

  • Member
  • *
  • Posts: 44
Re: DCF77 instead of NTP as time source for weather station
« Reply #8 on: October 21, 2021, 11:00:32 AM »
The 1st October to 10th October was a National Holiday in China. You might expect that the week after a national holiday is a catch up week but this week things should be back to normal.

Offline Jai Soone

  • Senior Member
  • **
  • Posts: 61
Re: DCF77 instead of NTP as time source for weather station
« Reply #9 on: October 23, 2021, 07:37:19 PM »
From Wikipedia:
DCF77 is a time signal broadcast on 77.5kHz by a radio transmitter located att Mainflingen near Frankfurt. The range is such that it should cover nearly all of Europe. ... The DCF77 modules that you can buy are generally simple radios. Give them power, and they return a single digital signal.

Offline zoomx

  • Senior Contributor
  • ****
  • Posts: 188
Re: DCF77 instead of NTP as time source for weather station
« Reply #10 on: October 28, 2021, 03:50:59 PM »
On Amazon I found a WH31 with DCF77 receiver inside.
It's selled as VLIKE WH32N for the VL2810 weather station.
it's the same bought by @davidefa.
« Last Edit: October 28, 2021, 03:54:09 PM by zoomx »