Call for Gateway Shield Testers


We are really, really close to shipping out the gateway shields, but are hoping to get a handful of people that can help us test this week and make sure there are no more show-stopping issues.

The firmware is working, we have the Particle portions implemented, and everything seems to be working fine. Therefore, no special tools should be required to update the firmware to newer versions, it will be done OTA just like bluz. If for any reason you have issues updating your shield to production code, we will swap it out for you, so you won’t lose anything by signing up.

We will send you full production hardware, so no worry about beta boards or out of date hardware.

Due to time constraints, we can only ship out to United States backers. Shipping internationally would just take longer than the testing period.

Some more details:

What do we need you to test? Mainly we just want people to test normal use cases, connecing bluz to the cloud and leaving it there and making sure it works. You will also test using the Web IDE with the gateway shield and basic firmware updates.

What do you need to test? Just a Photon. If you have ordered a gateway shield from our Kickstarter campaign or through our online store, we will ship your whole order including any bluz DK boards that you ordered. So you should receive everything you need and only need to provide the Photon yourself.

What about the gateway? This testing is only for the gateway shield, we will do something very similar for the gateway very soon once we have PCBA samples.

So, if you have a Kickstarter order or pre-order with a gateway shield and have been patiently waiting on your hardware, and want to get it first and help us test, please let us know. You can email us at as soon as possible and we will get your order shipped out ASAP.




Count me in! I’m happy to help.


@eric, count me in also :wink:


Thanks everyone! The gateway shields that people requested shipped out today so the testing can commence! Once we have kicked the tires a bit, we will ship the rest of the orders out to the masses.

You can also see updates to the docs to get you started with your gateway shield. The new tutorial, which includes links to the code, can be found here:


The first small batch of gateway shields have reached the testers. So, I wanted to point out the items we are hoping to test and also the current limitation of the gateway shields (that should hopefully get fixed before launch). These are the items we would like to test out:

  • Connect multiple devices at one time and leave them online for 24 hours+
  • OTA updates of bluz DK through the gateway shield
  • OTA Updates of the gateway shield itself*
  • Simple apps running on the gateway shield (blink LED’s, Tinker, etc.)
  • Test the gateway shield with Photon, Core, and Electron
  • If the documentation is up to date and ready, or people think there are holes

If you could tackle one or more of those and let us know if you find any problems, or if things work as expected, that would be great.

Now, for the one limitation and the current * above. The Particle build farm has a fixed version of gcc, it currently uses 4.8. The problem is, 4.9 does a better job of optimizing and creates smaller binary files, and it turns out the larger binary files from 4.8 are too large. There is less flash space available in the gateway shield compared to bluz since the SoftDevice is larger, so we cannot load code built from 4.8 onto it, it is just too big.

David at Particle is trying to get us a fix soon so that we can set the build farm with specific version of gcc based on the branch. Until that happens, you can’t use the Web IDE to upload code. So, if you want to test loading code, you will have to build locally (with gcc 4.9) and flash using the CLI.

I will let everyone know as soon as this is fixed.


How much do the current Gateway Shields differ from the Beta Gateway Shields?
Will tests with that be worth anything for you still?


Yes, you can upgrade your beta shield to the production code. The only real difference is that the LED is on a different IO then we recommended. If you want to see where he new LED goes and the new labeling, you can view that in the docs:

There are instructions in the Pre-Release category to upgrade, you can see them here:

You will need to send me the device ID generated by the script so that I can add it to the Particle cloud. There is talk of this in the thread.

If you want to test too, that would be great! Please let me know if you need anything or have any issues.


@eric, I’ve got 3 bluz connected to a new shield. Claiming a DK with the iOS app was SUPER easy btw. I’ll let these run for a while. Do I need to update the firmware on the older DKs? All three of them are showing up on Particle list with all Tinker functions listing.

To test OTA via the GW, what’s the best app available on the IDE to use?

For the GW, what can I OTA to it to test? :wink:



When you say “older DK’s”, do you mean beta units? Any DK can be updated to the 1.0.47 release through the Web IDE. If you would like to update to the develop branch, and get the new fixes mentioned in the other thread, you can do that. No update should be required, though, unless you have a beta DK with really old firmware. The gateway shield follows the same protocol as the apps, so everything should just work.

To test OTA updates to a DK through the gateway shield, you can just use the Wed IDE. They will be slower than they are through the apps, but that is normal and unavoidable. It would be great to also test OTA updates of the system part (since they are larger and would stress things more) so you could use the CLI to flash locally compiled system parts to bluz as well. If you did want to update your bluz DK to the newest develop branch, you can locally compile and then flash the system parts through the gateway shield, that would sort of kill two birds with one stone!

To test OTA updates to the gateway shield, you will have to locally compile and use the CLI. So you can just use ‘particle flash …’ to send down system and user parts. Again, testing flashing both system and user parts is good since the size of the two is massively different.


@eric, yup, beta DKs. I’ll do the local compile/CLI OTA thing and get back to you :smile:


@eric, do I OTA flash the HEX or BIN files?


BIN files, other files won’t hurt anything but wouldn’t work either


@eric, I compiled locally under modules and used CLI to flash over the system part (.bin). The (beta) DK is flashing magenta for about a minute or more. It then rebooted and reconnected with the Tinker app (already on there) running fine. I then flashed over the “latest” tinker and it only took about 10 seconds to flash. It then rebooted and reconnected quickly.

I repeated for my other beta DK and timed the system part which took just over 3 mins after which the LED when dark and stayed that way. However, the DK was still showing online so I flashed over tinker and the LED came back to flashing magenta, though for a long time (ie as if flashing system part again). I left it alone for several minutes and it was still flashing magenta and still showing online. Now it’s not taking any OTA firmware (CLI fails).

I then tried to do a factory reset (went to solid blue then solid magenta) and OTA tinker again but OTA failed. Oddly, around the same time, both other connected DKs lost their connection and I had to reboot the GW to get everything to reconnect.

I’ll most likely have to reflash the stuck DK using serial.


@eric, I recovered the beta DK using programmer_release with adalink. All three DKs are now online showing tinker. I was able to control all three with the Particle app on Android. FYI - response to D7 on/off was fast! :wink:


@eric, I added a 4th bluz to the mix, which I claimed via the Android app. Depending on the order I booted them in, only 3 connect to the GW.


Yea, that is a current limitation. The Photon is currently hard coded to only handle 5 sockets, one is used by the Photon itself, one is used by the gateway, and then 3 bluz DK. So we can’t go above 3 connected bluz at the moment with the Photon.

The good news is, I talked to @BDub and it seems this may be changeable, but it will require modifying the Photon system firmware. I have yet to test this, but I know where it needs to change so I plan to get to it soon.


Since the first batch of gateway shields have gone out, I have found and fixed a few issues. Mainly:

  • If a gateway shield is turned on and 3 devices try to connect at once, it can flood too much traffic through the buffers and some data can get lost. To prevent this, connections will now be staggered. So we will connect one device, wait 8 seconds, connect another, wait another 8 seconds, and so forth. This should prevent the massive flood of traffic in the beginning.
  • The buffers have been set to handle two times the maximum payload, hopefully preventing any data loss under even high stress conditions
  • The gateway shield would not reconnect automatically if the Photon loses the socket. You can easily test this by getting the gateway shield online, then resetting the Photon. The gateway shield would never reconnect to the cloud. This is fixed, so now it will

If you want to get the fixes for these changes, you can get latest from the gateway repository (, build locally and use the CLI to flash the system firmware to the gateway shield. Or use adalink for those who have it set up.


@eric, I flashed the system part to the gateway via OTA and after some time (10mins), rebooted the GW. Now, none of the DKs connect. Should I be flashing the user-part as well (and which one)?


You shouldn’t have to flash the user part. When you flashed the gateway, was the LED blinking on/off? After 10 minutes, was it still blinking?

When you boot it up now, what happens? Does the LED blink? Does the gateway shield connect to the cloud?

One note, the gateway shield will not connect to any bluz DK’s while itself isn’t connected to the cloud. So if it is flashing quickly, that means it is trying to connect and won’t connect to any bluz in that state.