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

Added time() and sleep() functions #28

Merged
merged 2 commits into from
Jul 25, 2013
Merged

Added time() and sleep() functions #28

merged 2 commits into from
Jul 25, 2013

Conversation

OrganicIrradiation
Copy link

From the documentation: "This command sets the real-time clock by
synchronizing with the time server specified with the time server (set
time) parameters. This command sends a UDP time server request packet."

Also added sleep() function per mgrey's recommendations: #9

OrganicIrradiation added 2 commits July 25, 2013 11:04
From the documentation: "This command sets the real-time clock by
synchronizing with the time server specified with the time server (set
time) parameters. This command sends a UDP time server request packet."
Added the sleep() command.  Calling it with (seconds) will set the
system wake timer before putting the module to sleep.
harlequin-tech added a commit that referenced this pull request Jul 25, 2013
Added time() and sleep() functions
@harlequin-tech harlequin-tech merged commit 28b3893 into harlequin-tech:master Jul 25, 2013
@ghost ghost assigned harlequin-tech Jul 25, 2013
@quique123
Copy link

Hi guys! Just wanted to clear something up. Does the wifi module/shield have an rtc? But it is not battery powered like a DS1307 or DS3231? So it only keeps time while the unit has power, correct? I have a project that uses an external ds1307 breakout to keep time and together with timealarms library, I call measurements every 30 minutes. I wanted to eliminate the external ds1307 breakout and see if I could keep the alarm-measurement functionality using the wifi module's rtc. But I guess that if the wifi module reboots, which it sometimes does, it would loose its time? But it would sync again on setup, right?

@OrganicIrradiation
Copy link
Author

If my memory serves me correct, the module does not have a battery backup, so the time would be lost if power is lost (until a time resync is performed). I'm honestly not sure what the status of the WiFly's RTC would be after a soft reboot.

@quique123
Copy link

Oh ok but it does have a clock? And on reboot I could probably call a function to sync the clock again. Who knows. Do you know of any examples using the rtc functions?

MV

On Nov 13, 2015, at 6:23 PM, OrganicIrradiation [email protected] wrote:

If my memory serves me correct, the module does not have a battery backup, so the time would be lost if power is lost (until a time resync is performed). I'm honestly not sure what the status of the WiFly's RTC would be after a reboot.


Reply to this email directly or view it on GitHub.

@OrganicIrradiation
Copy link
Author

Yes, it does have an RTC (see section 3.11 in the command reference). And yes, you can call the time() function that was added in this to commit to re-sync. Here's some old code that (I believe) should work:

WiFly.setTimeAddress("129.6.15.30"); // time-c.nist.gov
WiFly.setTimePort(123);
WiFly.setTimezone(22);  // CEST UTC + 2 hours
WiFly.setTimeEnable(5);
WiFly.time();

const byte bufferSize = 32;
char buf[bufferSize];
WiFly.getTime(buf, sizeof(buf));

@quique123
Copy link

Thanks. I was trying a slightly different code and it didnt work. The 2 main differences are the setTimeEnable which I had at 1 and you have at 5, and the ntp which I had at ...28 and you have at ...30. Im guessing it might have had to do with the setEnableTime? What does 5 do vs 1? Here is my code:

char dataBufferToReceive[bufferSize]; //for the time
long int uptime;
char timezone;
long int rtc;
wifiSerial.begin(9600);
// set time from ntp
wifly.setTimeAddress("129.6.15.30");******************_// I was using .28
wifly.setTimePort(123);
wifly.setTimezone(7);
wifly.setTimeEnable(5); //
_*******************Is this why?
wifly.time();
wifly.save();
delay(1000);
uptime = wifly.getUptime();
timezone = wifly.getTimezone();
rtc = wifly.getRTC();

Serial.print("uptime: ");
Serial.println(uptime);
Serial.print("timezone: ");
Serial.println(timezone);
Serial.print("rtc: ");
Serial.println(rtc);
Serial.print("MyTime from wifly getTime: ");
Serial.println(MyTime);

//Get time from wifi module
if (wifly.time()) { // My testing of rtc
//print time
delay(1000); // My testing of rtc below
char *something = wifly.getTime(dataBufferToReceive,sizeof(dataBufferToReceive));
int something = wifly.getRTC();
Serial.print("RTC from wifly getRTC: ");
Serial.println(something);
} else {
Serial.println("Failed to get time");
}

@OrganicIrradiation
Copy link
Author

In the section (3.11) of the datasheet I mentioned above, they explain the value for set time enable:

The RN module can also be configured to get the time whenever it powers up using the
set time enable 1 command. If time enable is set to a value greater than ‘1’, the RN
module pulls the time continuously every <value> minutes.

So, wifly.setTimeEnable(5); will update the time every 5 minutes while wifly.setTimeEnable(1); will only update the module's RTC on startup. You can also see section 4.3.11 for other "set time" feature descriptions.

@quique123
Copy link

Yeah I read that section. So that wouldn't have been the issue. Anyway, thanks because with your code it worked.

MV

On Nov 17, 2015, at 12:09 AM, OrganicIrradiation [email protected] wrote:

In the section (3.11) of the datasheet I mentioned above, they explain the value for set time enable:

The RN module can also be configured to get the time whenever it powers up using the
set time enable 1 command. If time enable is set to a value greater than ‘1’, the RN
module pulls the time continuously every minutes.

So, wifly.setTimeEnable(5); will update the time every 5 minutes while wifly.setTimeEnable(5); will only update the module's time on startup. You can also see section 4.3.11 for other "set time" feature descriptions.


Reply to this email directly or view it on GitHub.

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

Successfully merging this pull request may close these issues.

3 participants