Wakeup Photon/Electron from nrf51822 in Gateway?


#1

Question from Kickstarter:

If this is used with the photon or electron gateway, then can the 51822 be used to control power cycling on the photon/electron? I understand that this chip uses much much less power than those chips do and would like to use this as the “always on” computer to minimize power consumption.


#2

This is a great question!

The nrf51822 on the gateway shield is connected to the Photon/Electron through 7 GPIO pins. 4 of these are used for SPI communication, the others are used for controlling data flow. We have a specific pin that we use to alert the Photon/Electron (which is the SPI Master) that data is available on the nrf51822 (which is the SPI Slave).

Theoretically, yes, you can use this pin, which will only go high when the nrf51822 wants to send data to the cloud, to wakeup the Photon/Electron, which could be sleeping otherwise. However, this can lead to interesting issues. For example, if the Photon/Electron takes a long time to connect back to the cloud, then data in the buffers on the nrf51822 could get overriden while it is waiting to send it.

To be honest, I hadn’t been planning on this for the most part. I’d always imagined the gateway as an always-on, constant-powered device. It would be plugged into the wall in a house or in some other reliable power source at all times. So power consumption wouldn’t be a critical issue with it.

Do people see making a battery powered gateway? Is this a concern of people? I would love to hear feedback on this and see peoples plans.


#3

@eric, having the ability to wake a sleeping Photon or Electron is a major requirement IMO. I have several designs which are battery powered and using a Bluz+Photon/Electron combo is key to the success of the products. I had anticipated doing exactly what the OP is asking for where data collected by the Bluz would be sent to the cloud by waking the Photon/Electron to send the data. In my designs, this would be at slow intervals (10 mins to daily) for example.


#4

Fair enough.

This should be rather trivial to add. Simply put the Photon/Electron to sleep, then wake it up when the “data ready” pin goes high. The Photon/Electron can then notify the nrf51 when it is connected and ready to send data before it hands it over SPI.

My biggest concern is timing. Clearly if you want to send data at a fast rate (a minute or less probably) then this wouldn’t be very efficient. Also, if you wanted to send a lot of data quickly when you do wake the Photon/Electron up, there could be issues. Let’s say, for whater reason, it takes 30 seconds for the Electron/Photon to connect and alert the nrf51. If you fill up the buffer on the nrf51 before this happens, you could have data loss.

So there would certainly be some caveats to it, but the feature itself isn’t terribly difficult to add.


#5

+1 on this capability. Cheers!


#6

You could use the manual or semi-automatic modes on the Photon/Electron so that it doesn’t immediately have to connect to the cloud on wake-up. Since connecting to the cloud is non-blocking, you could buffer data on the Photon while it works on getting that cloud connection in the background. The new multi-threading may make it even easier.

Also, plan for the worst with the Electron. Not that the hardware or cloud infrastructure bad, just the nature of cellular is prone to being slow to establish the initial connection. I have an Electron that I could pop on the gateway shield for testing once the feature is ready and has been tested on a Photon.


#7

Yes, if you have an Electron, that would be great!

Those are mostly my issues. It isn’t so much the cloud connection for the Photon/Electron, but for the bluz boards. If they are attempting to send up a lot of data, and the Photon/Electron takes too long to connect, the buffers will fill. We need one buffer each for up to 8 bluz boards, to it could potentially be a lot of data all at once.

We will just have to test it and try things. In most use cases it would probably be fine, but there are situations that can cause problems.


#8

The Electron firmware isn’t quite ready to be a Bluz gateway, but this is what it might look like on the Bluz gateway shield. :wink:


#9

I’m way late on this but couldn’t you store data in external flash when space gets low? This would give you a bit more time to “drain” the Bluz to a Photon/Electron? Some sort of define for “buffer to flash” that watches for this state and spills up to a user defined value or number of pages. I too want to have a battery powered Electron with Bluz modules sending data from sensors.


#10

This is a possibility. It really depends on how much data people are sending and how fas the Electron connects. It may be best to try it out at some point, I know a few of the bluz beta backers also have beta Electrons, so it is certainly something we can start to look at.


#11

As I’d understand it, both - the nrf51822 and the Particles - (and possibly additional Bluz’) firmware are in the hand of the same programmer/user, so if (s)he’s informed about the possible implications (s)he can take appropriate measures on both sides.

It might be nice to have a “good practice” sample for doing such in the docs to keep some kind of code uniformity.


#12

Yes, it is true that an interested student could extend the system to do whatever they wanted. I guess I am just trying to come to grips with what is needed for the default behavior out of the box. This use case of shutting down the Electron and waking it up from the nrf51 is outside what I would have considered default behavior. So we can do our best to support it by default, but there will probably be corner cases where it won’t cover everything.

Certainly something we love to hear feedback on and will try to get all of these little features into the base product.


#13

That seems to be an edge case. While I expect the Electron to be one of the most popular cellular dev kits once it’s released, I don’t think it will have the adoption rate of a Core or Photon due to the monthly subscription, even if it is super cheap! I think it’s one of those things that if it works at launch, that’s great. If it doesn’t, it’s not the end of the world.

The good news with the Electron is they have drastically improved connect times with the latest round of firmware, so given the inherently slow speed of BLE, it may work out okay. :smiley:


#14

So an awesome lib for Electron and Bluz would be a “publish collector” the main idea is not to send data that isn’t unique to previously sent data. Set a variance threshold and squash the pub unless it is outside the variance but keep track of how many samples were squashed and report that on a different but longer variable. This could be great for GPS, temp data, state whatever. Depending on the receiver of said data you just have to send say for example (temp, 71.2, 15, 60) temp data, 71.2 degrees, 15 samples at 60sec intervals. I’m going to "teach"
the GW to do something like this for my Bluz so updates from it are regular but the Bluz stays happily asleep. Just need my watchdog to make sure it is no data cause it is meant to be that way and not because it is offline.


#15

That wouldn’t be a terrible lib idea for the whole Particle ecosystem. It would definitely go well with the Electron, which is similarly constrained by bandwidth and battery life.

It almost reminds me of the spark-batch-publish library I wrote last year. I did something similar with another Photon device I built this weekend that operates similarly to the batch publish idea but waits X seconds after a variable has changed before initiating the publish. In that case, I am using Blynk to change the colors of a NeoPixel strip. Since it changes rather quickly, I keep incrementing a variable (nextBlynkPush = millis()+2000;) and then check it in the loop if(nextBlinkPush>0 && millis()>nextBlinkPush) doBlynkPush();. The batching lets stats queue up so they can all be sent in as few publishes as possible, and the incrementing variable acts as a governor so I don’t spam the cloud with publishes.

Maybe I’ll try to combine all of these ideas into the batching library soon. So that would be batching, governing, and sampling/variance checking.


#16

I am the one who originally asked about this. The rationale is that I was planning to locally save data to the BLE central device, store up 10 data points from each of, let’s say, 5 peripheral devices, and store it on the central device. So that’s 50 data points, perhaps stored in EEPROM or, if many more points, maybe on an SD. Then, once per hour, the central would wake up the Electron and transmit the data to home base. This would all be battery powered for monitoring purposes where there is no wifi or Bluetooth to internet bridge available. The bluz/electron would be the bridge :grinning:

In any event, I have a FONA that I can test with right now but it just seems so elegant to keep everything in the same family. Plus, this is the only Bluetooth/cellular combo that I know of on the market right now. If the HW would just work, there is a whole market segment waiting for this.

Edit: Sorry to dig up an old post. My apologies :innocent:


#17

This is all certainly possible, and actually relatively simple. It would require only some very minimal changes to the underlying gateway code on the Electron and the gateway shield, and you wouldn’t need to change any underlying firmware on the bluz board.

This is one of those things where I would love it if a community member wanted to try and tackle it! I can give you all the pointers and info you need (it really isn’t that complicated), and if you want to tackle the job and right up a tutorial or publish some sample code, I will definitely send you some free hardware!

Interested?


#18

I’d be willing to take a crack at it.