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

0 Members and 1 Guest are viewing this topic.

Offline olicat

  • Forecaster
  • *****
  • Posts: 527
  • DP1500, GW1100, HP2551C, HP3500 & FOSHKplugin
    • 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
« Last Edit: October 13, 2021, 04:46:01 AM by olicat »

Offline davidefa

  • Contributor
  • ***
  • Posts: 109
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 ) unity of years
- the ..MM..MM should read Mm  M =  (high nibble) tens of months, m = ( low nibble ) unity of months
- the ..DD..DD should read Dd  D =  (high nibble) tens of days,   d = ( low nibble ) unity of days
- the ..HH..HH should read Hh  H =  (high nibble) tens of hours,  h = ( low nibble ) unity of hours
- the ..MM..MM should read Mm  M =  (high nibble) tens of mins,   m = ( low nibble ) unity of mins
- the ..SS..SS should read Ss  S =  (high nibble) tens of secs,   s = ( low nibble ) unity of secs


P.S.
So my pc is couple of seconds late ( 1.71secs )
« Last Edit: October 15, 2021, 04:01:28 AM by davidefa »

Offline broadstairs

  • Senior Contributor
  • ****
  • Posts: 220
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.

Offline olicat

  • Forecaster
  • *****
  • Posts: 527
  • DP1500, GW1100, HP2551C, HP3500 & FOSHKplugin
    • 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

Offline Rover1822

  • Forecaster
  • *****
  • Posts: 792
    • 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 x2,WH31B x2,WH40E,WH31P
EcoWitt: GW1100,GW1000 x4,WH31 x2,WH57,WH51 x12, WH40,WH5360B,WN34S
Web Sites: WU, Ambient Weather , Ecowitt.net , Ecowitt.net (TEST)
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.

 

anything