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

0 Members and 1 Guest are viewing this topic.

Online olicat

  • Forecaster
  • *****
  • Posts: 603
  • 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: 144
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 »

Online broadstairs

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

Online olicat

  • Forecaster
  • *****
  • Posts: 603
  • 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: 858
    • 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.

Online olicat

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

  • Senior Contributor
  • ****
  • Posts: 160
    • 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.
Ecowitt GW1000: WiFi Gateway
Ecowitt GW1100: WiFi Gateway
Ecowitt WS68: Anemometer, UV and solar radiation
Ecowitt WH40: Rain gauge
Ecowitt WH32E: Outside Temperature (Celsius) & Humidity sensor
Ambient Weather WS-2000
Raspberry Pi 3B+ (running WeeWX)
Raspberry Pi Zero 2W (running CumulusMX)
---
http://weather.glenns.ca (pwsdashboard ECOWITT custom server upload)
http://weewx.glenns.ca (WeeWX 4.x.x)
http://glenns.ca/cumulusmx2/index.htm (CumulusMX)
---
WU: ITEHKUMM2
PWSweather.com: MBAYWX1
AWEKAS:id=15920
WINDY: Michael's Bay, Manitoulin Island
WOW: Michael's Bay

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: 57
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

  • Contributor
  • ***
  • Posts: 122
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 »