Hi,
I am new to Spark Core. I am using WebIDE particle build to build my firmware. I am finding some issues as explained below. I searched many similar posts, but not able to get what I am exactly looking for. Any help/solution would be very much appreciated.
My requirements:
Primary requirement is to preserve the charge of my battery that powers my Spark Core
I should be able to put my spark to deep sleep or wifi sleep and also wake it up using commands invoked over the cloud (Spark function calls).
Here are the issues I am facing:
I can easily put my spark into deep sleep using Spark.sleep() call invoked over the cloud. But the problem is in waking it up. As it turns out, cloud command cannot be sent to wake up the core since its in deep sleep and my command can’t reach the core since the wifi communication is off. Any suggestion on an alternative design/solution for this?
When I invoke wifi sleep, say Spark.sleep(30), the wifi shuts down and I can see the green blinking on RGB LED. But the problem is it never comes out of that even after 30 seconds. Is it a bug or known issue? (I simply call Spark.sleep(30) at the end of my setup()).
I am using a portable USB charger to power my Spark. When I use deep sleep in the range of few minutes, it comes back up. But if I set longer sleep (I used 30 mins/1 hour), the spark doesn’t come back up at all. I have to press the on/off switch of my portable USB charger to bring up the Core. It looks like my USB battery itself is probably going into a standby mode after sometime since very low current is pulled from it. Is it the case? I need to still see my USB charger’s specs. But I am thinking if I use regular 4 AA batteries, I probably won’t get into this issue?
I would like to use interrupt-driven wake up from deep sleep if possible, over the cloud. The use case is that my core should be by default in a deep sleep after it comes up and live for sometime (to preserve my battery power). Now when I send a command (e.g. to rotate a servo attached to A0 of the core) over the cloud, it should wake up the core and execute the command. But I guess this won’t be possible since wifi communication will be off. It seems only native code (no external communication) can be written to trigger an interrupt - but how does external world can trigger that native code?
For now, what I have done is that, inside my loop(), I am sending my core to deep sleep every hour and waking it up for only 3 minutes, and so on. But this is not working due to the USB charger issue. I can possibly bypass that using a 4 AA battery pack. But still this solution won’t help me eventually since the requirement is to be able to wake up the core using user command over the cloud - whether specific command to just wake it up, or some other function command (e.g. rotate the servo) that would first wake up the core and execute the command.
To save you the hassle, it's very unlikely to work. Unless you can communicate with your device, there's very little you can make it do externally. Turning off wifi means cutting of wireless communication, thus making it impossible to reach. A "wake on wifi", is not within the capabilities of the CC3000 as far as I'm aware.
Depending on your needs, you might consider creating a hardware interrupt. When a specified pins toggles a set state, you can wake your device.
Not to self promote too much, but you may want to check out bluz. It is the same as the Core/Photon but uses Bluetooth LE instead of WiFi. This means it can stay connected to the cloud and draw only uA’s so it will last on batteries for a very long time but also be accessible via the cloud.
Think of Bluetooth LE as just a WiFi alternative, it doesn’t have to be tethered to a smartphone and can be used anywhere and at all times. It is just much lower powered and thus well suited for battery powered projects.
Thanks!
Yes, I am aware of what you’re saying and also as I mentioned in my post. I have implemented hardware interrupt, but that works internally from within firmware code - can’t be triggered from outside.
Possibly I need to separate out my core from the end-point (servo in this case) and plug it up on a wall with a continuous power supply from the main electric power source via usb connection and keep a rechargeable battery pack as a backup. In that case I need to install a bluetooth with the servo and a bluetooth shield on the core which can be programmed to communicate with each other inside the house. (could this be a good solution?).
As I also mentioned, I can save power right now going into sleep/wake at hard/predefined intervals - but that would be pretty much hard-controlled and not intuitive - user has to know exactly when the core comes up and he can issue a command.
Again, my primary requirement is to save power for the core without interrupting/limiting the functionality of my project - i.e. user can send a command anytime without knowing much about the sleep/wake state of the core.
Thanks for the suggestion! I will try that out. I was also thinking in the same direction.
Since I have already invested in Core, I would like to see if I can use bluetooth LE here. Please see my other post where I am proposing a similar design, but using Core. Not sure if that’s feasible…
Eventually I would like to separate out the Core from the servo part and have core to use wifi to communicate thru’ the cloud, while it uses bluetooth inside the house to talk to the servo (where both servo and attached bluetooth can be powered from the same battery but with extended life/usage).
That is the perfect deployment scenario for bluz. You can use the gateway shield with your current Core to bring a Bluetooth LE “hotspot” into the house. This can be plugged in at a central location. Then you could use bluz boards for battery powered projects that will stay connected for a very long time.
This is one of the big use cases we built bluz for.
@sdash, your use case is exactly what I had in mind when I pledged for the Bluz and gateway. I met Eric at the SF Maker Faire and I am really excited about his direction. I don’t usually endorse but in his case, I have no problem doing so! :
@eely22, that’s excellent news! When you said "This can be plugged in at a central location. ", you mean plug in to continuous power supply from wall as well? If that’s not the case, problem with powering the core still remains, right? I have gone thru’ the bluz website, but still need to understand few things. For example, does the bluz gateway shield communicate with my wifi router in the house? Or, Core’s wifi will still be used to communicate to the cloud and the bluz’s bluetooth BLE hotspot will be used to communicate to the other bluz (BLE enabled) boards attached to the devices inside the house? Sorry to ask too many questions…
Since bluz products are coming in Oct, is there any other recommended BLE solution (compatible with particle) I can use in the meantime?
Cool. Makes sense.
I am doing a project (in early phase) which would eventually be required to be produced in huge volume - so I would like to make sure I can put all the right and required pieces/technologies together before the big investment is done
Yes, the gateway shield, with the Core, can be plugged in to a wall outlet or other constant power supply. The gateway does the same thing, it just already has the Photon board soldered down and has a nice plastic case (instead of being a bare PCB shield).
Once the gateway shield is powered on, the Core needs to be hooked to your home Wifi like usual and loaded up with specific code we supply that turns it into a gateway. The core will then communicate with the BLE device on-board which acts as a central. Up to 8 bluz boards can then connect to this gateway and be connected to the cloud (automatically).
Each bluz board is individually addressable, just like a Core/Photon. So you would use them the same way, there is no difference. The bluz boards are always online and talk through the gateway to the cloud.
I am not aware of any off-the-shelf BLE devices you can do this with today. There have been some projects combining Core/Photons with BLE, but not in this way (at least to my knowledge). We are open-source, and parts of the design have already been published online. It is possible you could make some of these parts yourself or we can always talk about how we could help you before October. If you want to discuss more, you can reach out at hello@bluz.io and we can talk more.
@eely22, thanks for the details. That’s excellent!
I think I exactly need this - the bluz gateway shield and the bluz boards. Since it already has a photon built-in, I assume I can directly use that as well (putting my Core on other use) and my same code written for Core should start working? Or any additional coding needed to tie up the BLE hotspots and other bluz boards?
Also, regarding bluz board, can I program them using same particle IDE? I believe I need to write additional code to communicate between BLE server and the individual bluz boards (device to device)? Does bluz board support all the firmwire (and additionally BLE) APIs that Core supports (e.g. can I code the BLE bluz board to rotate a servo attached, when it gets the command from gateway BLE server?)
Will send you a separate e-mail to talk about this more (one minor issue is that I am located in India - need to figure out the logistics of shipping etc).
I see, so you rather want to trigger remotely rather than only "from outside".
How remote do you want to be?
Depending on that there might more different routes, including bluz, Electron or even some low tech aproaches.
Just to clarify one thing, there is the gateway and the gateway shield, which are two different things (yes, we should come up with better names!). The gateway shield requires a Core/Photon while the gateway has the Photon built-in. So both options are available.
In both, the code to turn it into a gateway is provided, but in the end they are just Particle boards and can be re-programmed to do whatever you want.
Yes, you will be able to use the Particle Web IDE with bluz. Yes, it will support all the same commands (publish, subscribe, function, and variable). Yes, it will also support the same Wiring language (so things like Servo and analogWrite will work). It will be very similar to working with a Core/Photon.
Look forward to talking more with you through email.
Let’s say I have a mobile app from which I should be able to wake up the Core (i.e. using http get/post from web/app world over Spark Function calls built in the firmware) by sending a command, whenever I want…(I can only once put it to sleep though from the web/cloud/app, but without that, we can internally/automatically loop between wake up/sleep that depends on millis() to decide the intervals before it wakes up which is pretty much hard-coded, and this can’t be controlled over the cloud, and it becomes more like the device is running the user here ).
Although it doesn’t seem to be possible, but I was looking for thoughts (or validate my thoughts ), and bluz seems to have solved the issue by breaking down the problems, in a different way. (the issue of waking up now becomes little less important).
I need to look at the Electron.
Yes, would be good to look at some low tech approaches (good enough for testing/prototyping). If you could provide few pointers, that would be great!
Think of Bluetooth LE as just a WiFi alternative, it doesn't have to be tethered to a smartphone and can be used anywhere and at all times.
If it's not tethered it is "disconnected" and bluetooth is definitely not equivalent to wifi. I have one bluz coming in, but it's a completely different device.
It can be any other BT device and you don't need an AP to talk to it (which is my interpretation of "being tethered" in contrast to peer-to-peer connection - neither is "disconnected").
And also an "alternative" does not need to be equivalent in all respects to still be a valid alternative for a given purpose.
Furthermore "completely different" is definetly not true - since there are similarities (e.g. API, high grade code compatiblity, ...).
But foremoste, what does this comment have to do with the OPs question? How does it help the OP?
Electron or even some low tech aproaches.