The reason of my concern is that I would like to use the imp + env tail available on the kit as a weather station of sorts. I imagine I would need to use the date() function somewhere in my hardware code, but I wanted to be clear the timestamp is accurate rather than offset by some duration (e.g. to queue online the timestamp). Could someone confirm?
Other than that, from the Starting Guide my understanding is that this sort of application would require imp.wakeup, as shown on the weather station tutorial, which is default to 10s. But how low could the resolution be in such a way that it wouldn’t block the OS to interface with the agent?
Lastly: Is there a way to turn the imp in a data logger to interact the agent from time to time in case the internet (not the power) runs out?
The RTC in the imp is set when it connects to the server, and will be preserved as long as power to the imp is maintained. It’s generally +/- up to 1 second and is resynced regularly to an NTP-synchronized host when the imp is connected.
I don’t quite get what you mean by “how low could the resolution be in such a way that it wouldn’t block the OS interface with the agent” - do you mean, how fast could you run a loop which will still allow network traffic to be processed? For that, you’d just use an onidle handler, as that will run immediately after any traffic as been processed.
Thank you so much for clarifying this The assumption in my lab was that the imp001 were waiting for the data to go “online” to only then timestamp meaning the date() function wouldn’t really be able to be trusted on a second reading resolution. Knowing the imp has a clock synced so long power is flowing in it is really reassuring.
Let me start by first clarifying my last question (and please keep in mind, I am a computer science student learning the hardware part at the same time, so beware rookie questions!):
I don't quite get what you mean by "how low could the resolution be in such a way that it wouldn't block the OS interface with the agent" - do you mean, how fast could you run a loop which will still allow network traffic to be processed? For that, you'd just use an onidle handler, as that will run immediately after any traffic as been processed.
I took a look at the onidle() documentation, and my natural language translation to that would then be “Collect readings as much as possible!”. This looks like a good take, but I was more interested in having the imp collecting readings every x seconds (e.g. every 10 seconds ; every 5 seconds) or so. That way, the timestamps are not all over the place if we have more than one imp running on different parts of the same building (this actually motivates a follow-up question but more on that in a bit). So under that perspective, how low the resolution (i.e. how low every x seconds) could I safely put the imp to sample the data with the date() timestamp and all sensors readings of the Env Tail without running the risk of blocking the OS to ever be able to push the data to the API?
The following question is then: For 2 or more imps, is there any way to have the imps sync their reading timestamp? I imagine one alternative would be going after what I suggested in 1), by ensuring they start at 00:00 and then keep sampling every x seconds (the lowest resolution possible that wouldn’t block the OS). But I was wondering if there is other way (considering we have other devices that are not imps, maybe this will end up being the only way but it doesn’t hurt to ask!).
From the link you provided I found the statement I was looking for, that makes the imp behave as a data logger of sorts. I also understand this means I am now having to be more detailed on what the imp needs to do, so I will need more time to read it through (kuddos to whoever made this wi-fi diagram, it is great!). I took a quick look but I could not identify how many readings would the buffer be able to hold before it would “blow up”, meaning how long it could operate without internet. I intend for now to only use the Env Tail on the lowest resolution for all 4 readings it can get (relative humidity, temperature, pressure and ambient light). Would you have any idea how long that would be or how large is the buffer or if there is an online specs table? I am having a bit of hard time to find that (I wasn’t the one who acquire it).
Is there any documentation on logging this data in a external database or something that could be accessed through an API? I missed that piece on the weather station tutorial (it only go as far as showing the latest reading, so I am not sure if storing the readings somewhere through the IMP api is viable).
On (1) you’d have to experiment, but it’s going to be many times per second (imp.wakeup takes a float, resolution is down to 20ms as I remember). You may need to use RETURN_ON_ERROR mode (to prevent blocking automatic retries) and other techniques if you must have monotonic samples - but you may have to do that anyway even sampling every 5 seconds - networks are non-deterministic and latency will always happen at the worst time
Note that the agent is decoupled from the device, so actual forwarding data to a cloud service is not going to slow down the device.
On a large scale you don’t really want to do this as it’ll create peaks of load for your backend (trust me, we’ve seen it!). Environmental parameters tend to change pretty slowly - tens of seconds or even minutes. But, yes, you would sync to the RTC time.
Number of readings depend on RAM. Assuming all your devices are awake (not sleeping in microamp mode) you have ~85kB of RAM for your devices to use for workspace (imp001/2), ~130kB (003) and >1MB (005). So - likely thousands of readings assuming 1 byte for temp, 1 for humid, and maybe 2 & 2 for pressure and light. You could pack further - I’d suggest using a blob - to give the best density.
Plenty of options. See the libraries page. You could try initial state first, it’s very easy to use.
Thank you again. I just wanted to double check if I caused a misunderstanding on something: The networks are non-deterministic, but it is fine if it samples offline every 5 seconds and it arrives at different times. From what you said previously, it would be able to sample offline and them send it all together. Does that means I could have a every 5 second sampling happening offline and sending when possible to the server? That would suffice to me. I think this would also address the peak concern on the server side like you pointed out.
Yep, you could buffer samples then send at once; the only issue is if you have trouble sending at a time which overlaps with a 5s period. This wouldn’t be an issue if you had a good wireless connection.
The assumption in my lab was that the imp001 were waiting for the data to go “online” to only then timestamp meaning the date() function wouldn’t really be able to be trusted on a second reading resolution. Knowing the imp has a clock synced so long power is flowing in it is really reassuring.