Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Is it possible to return the epoch time in milliseconds? #79

Open
iogbole opened this issue Oct 20, 2019 · 10 comments
Open

Question: Is it possible to return the epoch time in milliseconds? #79

iogbole opened this issue Oct 20, 2019 · 10 comments

Comments

@iogbole
Copy link

iogbole commented Oct 20, 2019

No description provided.

@Majubs
Copy link

Majubs commented Oct 30, 2019

Any response to this? I would like to know as well.

@LPena10814
Copy link

I would also like to know if this is possible.

@MHotchin
Copy link

MHotchin commented Dec 7, 2019

It wouldn't be possible without changing the data type returned by getEpochTime(). Right now the unix time is 1,575,693,824. Multiplying by 1000 will overflow the maximum value that an unsigned int can hold.

Even if you did change the data type, the simple synchronization code used will never be accurate to the millisecond level - the answer would be more precise, but it would not much be more accurate. So, there's really no point.

@WhymustIhaveaname
Copy link

Need not change the datatype. Just add another float _current_epoc_dec to record the decimal part of the current time from the Epoch.

I solved this in Pull Request #102. I add a new function named get_millis() which will return a float in [0,1000) recording the ms number of this second.

@fededim
Copy link

fededim commented May 13, 2020

@WhymustIhaveaname It would be useful to add a new method called getEpochTimeMs which returns a uint64_t containing the number of ms since 1-1-1970 because having 2 different calls (one getEpochTime and the other get_millis) could generate some drift if the second between the 2 calls changes (e.g. getepochtime returns 13/05/2020 08:41:59(.999) and get_millis returns 000 (meaning 13/05/2020 08:42:00.000)

@WhymustIhaveaname
Copy link

@fededim Thanks for your suggestion. I will add this function if my PR gets merged. But for now, you can add this function manually yourself.

unsigned long NTPClient::getEpochTimeMs() const {
  return 1000*this->_timeOffset + // User offset
         1000*this->_currentEpoc + // Epoc returned by the NTP server
         (millis() - this->_lastUpdate + this->_current_epoc_dec*1000); // Time since last update
}

@fededim
Copy link

fededim commented May 13, 2020

@WhymustIhaveaname Ok, thanks. The PR can't be merged because the Travis CI build fails. You have to fix the errors, see here.

@WhymustIhaveaname
Copy link

The Travis CI build fails because I add a new ntp_demo.ino into it. The examples in this lib are too old and they are not showing the full capability of this lib. This is the reason why I resist to delete the demo, even it leads to check failure.

@fededim
Copy link

fededim commented May 13, 2020

The errors of the build are quite strange, they two functions actually exists...I try to contact the reviewer in order to fix the build.

@sylvanoMTL
Copy link

sylvanoMTL commented Jan 2, 2021

I confirm the program from @WhymustIhaveaname works well. Here is a screenshot of 2 esp32s flashed using his NTPClient.h and NTPclient.cpp and a loop running at 10ms. Button were release at the the nearly same time (witch is tricky to clear the consoles and press tiny buttons).

NTPClient_on_two different_esp32s

The main loop contain the following code:

void loop() { timeClient.update(); Serial.print(timeClient.getFormattedTime());Serial.print("."); int ms = timeClient.get_millis(); if(ms<10){ Serial.print("00");Serial.println(ms); } else if(ms>=10 && ms<100){ Serial.print("0");Serial.println(ms); } else{ Serial.println(ms); } delay(10); }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants