I have been working on my first project and have got it to a stage where I can share my progress.
nimbus is a small weather station that currently has sensors for temperature, humidity and light. I have plans to expand this to include pollution sensors too.
The next steps are to build a weather proof case and also write a WordPress plugin for easily interfacing with the Spark Cloud API. I also need to check that the lux value I am seeing is being calculated correctly.
Whilst putting this together a few questions have cropped up which would be helpful to have answered:
When my core is flashed and not in debug mode (see code) I have to do a hard reset before I can flash the core again. Is there a way to ensure the core can always be flashed remotely? When it is out in the garden it would be great to be able to update the code from the warmth of the house.
I am looking at ways to save power as nimbus will be solar powered with a backup battery. The Spark.sleep() function looks like it should do the job but I am having a hard time getting it to work. Any tips for working with this?
I would love some feedback and ideas for how it could be improved. Thanks!
Thatās a strange issue. By ādebug modeā, do you mean that you set bool debug = true;? I donāt see anything unusual that would prevent it from flashing over-the-air (OTA). Maybe someone else sees something that I donāt. I have noticed that it may have a hard time flashing if I have the Spark CLI serial monitor in a reconnect loop. It seems to upset the Core, so I just have to make sure I kill my little loop first.
Iām going to tag @peekay123 on this one. He has done lots of research and tinkering with this stuff!
How are you planning to power it once out in the garden? Iām curious as I want to do this, but havenāt taken the time to learn all the solar power stuff that I need to disconnect from the grid.
@scottsweb, @wgbartley, this weekend I will be doing some characterization of the WiFi.off() and Spark.sleep() power modes to get a better grip on power consumption. Some members have reported a change in the expected power consumption in regular sleep mode and I want to verify this.
On the issue of OTA, I recall an issue with testing booleans and I canāt recall if it has been fixed yet. So, can you change your if(debug) line to if(debug == true) in setup() just in case.
As good practice, I tend not to use delay() in a loop to achieve sampling intervals. Instead I use the elapsedMillis library and create a non-blocking sampling delay so the firmware background task runs at the end of loop(). HOWEVER, a call to the background task was added to the delay() function so this should not be an issue.
I donāt see anything else that would cause the cloud connection to be lost besides what Iāve already mentioned. Let me know if that debug change makes any difference.
That is correct. Whist debug mode is true I can flash OTA whilst the core is sitting in waiting in the serial loop within setup(). Once the core is in the loop() I can no longer perform an OTA update.
For power I am planning to use one of these: http://www.seeedstudio.com/depot/Lipo-Rider-p-710.html - it seems fairly straight forward. You can attach a battery and solar panel and feed the Core from the onboard USB port. I have yet to decide the size of battery and panel I need as it will depend on how efficient I can make my project.
I ordered 5 of these 3.7v 600mAh batteries a while back that are itching to get used again (I blew up my little quad copter). That board looks perfect for this. Thanks for the link! Any idea on what size solar panel youāre going to try?
@wgbartley@peekay123 After more testing this evening it would seem I am able to flash the core at all times OTA. I think it was partly my own faultā¦ by disabling the onboard LED I could no longer see what was happening to the core.
So just to confirm that changing my code to if(debug == true) didnāt seem to make a difference in this instance (that bug must be fixed) and OTA updates seem fine now.
It may have also been my experiments with Spark.sleep() that were disabling the ability to OTA update.
@wgbartley not sure on the panel size yet. I have a 1200mAh battery I can use providing the core is not too power hungry. It will then be a case of picking something that will keep that topped up in the relatively gloomy weather we get here in the UK. I will report back once I have progressed further with this part of the project.
@scottsweb, so it seems the fix was done to the firmware for the logic test
Spark.sleep() and WiFi.off() do basically the same thing in that they are supposed to put the WiFi module in standby mode, dropping the power requirements. Of course, during the sleep period (or until WiFi.on() is applied), the cloud is disconnected and OTA flashing is not possible. This is the dilemma of disabling the wifi and/or the processor in order to conserve power. You could, in theory, wake from sleep and wait some time to see if an OTA takes place but then that consume power. I donāt have a good process for this figured out yet.
As for the LiPo adapter, I have the LiPo Rider Pro which works very well. The only thing I wish it had was a way of feeding back to the Spark the condition of the battery/charge. I canāt wait for @timb to finish his amazing battery shield!
Battery shield is coming soon! I sent a BOM off to Will last night, but it had some errors so Iām working on a new one now. I also found a few flaws with the shield itself, so Iām working on that too.
Just an update on the battery life and my first tests. I have got hold of a 1200mAh battery and the lipo rider. After a full charge I had around 4 1/2 hours of core life.
So I definitely need to make my project more efficient as it wonāt last through the night as it stands. I will start by experimenting with the sleep modes once again.
I will also need to change the way I go about data collection and use the Spark.publish() API. If the core is asleep then I cannot guarantee it will be on when it is queried from my WordPress plugin: https://community.spark.io/t/sparky-wordpress-meet-spark-core/4623 ā¦ so I am already planning a re-write of it or thinking about how to get around it. Any updates on when webhooks will be available?
Another option may be to make direct calls from the core to WordPress but this is something I need to read up on.
@scottsweb, I believe the most effective way of getting long battery life out of the Spark is to use deep sleep mode. Using Spark.publish() is the best way meaning Wordpress would have to subscribe to the published event. The unfortunate side effect is that you cannot ad-hoc query the core and doing OTA flash will require some a little imagination. For example, you could have your Spark wake up for N minutes every X hours to accept an OTA flash for example.
@kennethlimcp will soon complete his FRAM/SD shield. You could accumulate data in FRAM which will persist during in deep sleeps. You could then wake hourly (for example) to Spark.publish() or push the data out using TCPClient.
@scottsweb I was able to get 2.5 hours on a 3.7V 600mAh battery plugged straight into VIN/GND (no other circuitry in between). I was able to get 11 hours when putting the Core (with u.Fl antenna) into deep sleep and waking up once per minute to publish data to a web service using TCPClient (instead of Spark.publish()). I got 12 hours out of a Core with the chip antenna running the exact same code. I need to recharge my lipos and do some more testing with less frequent intervals to see how far I can get that battery to last. Iām hoping to get to 24+ hours of uptime on a single charge.
@wgbartley, that is fantastic data! We need to gather some of these metrics for analysis and documentation. I will be doing the a similar test with a larger battery so stay tuned with those results.
@wgbartley, would it be worth getting my results in there for a bigger dataset? It seems to me that your findings should become a white paper on Core power modes, not just a post. This would be the first proper profiling of power modes and an opportunity to present recommended operating modes. One thing that would be cool is to estimate milliWatt/hr or milliAmp/hour figures for battery planning.
Have you seen high peak current consumption like I did? I would love to plot current vs time around the wakeup/publish/sleep event to see how long it takes to wake/connect. I would be more than glad to help if you want to extend the findings and do a more detailed report.
project and have got it to a stage where I can share my progress.
that currently has sensors for temperature, humidity and light. I have plans to expand this to include pollution sensors too.
