Photon with BLE

I was reading datasheets and read about EXTERNAL COEXISTENCE INTERFACE. There are three dedicated pads for this purpose in both Photon and P1. My ultimate goal is to have P1 and nRF8001 in one board.
However as I know it’s possible to add BLE functionality to Photon using a BLE shield. Considering the fact the BLE shield is not connected to these pads, I wonder what’s the real benefit of COEXISTENCE INTERFACE? What happens if I don’t utilize it?

Which BLE shield are you referring to ?

If a co-located BT device chooses not to use this interface, things will probably muddle through, but performance may suffer under some conditions (e.g. audio might stutter (probably not a problem for BLE), range might be limited, you’ll see more retries on the wifi side, etc.) In short, you’ll be relying on the error recovery characteristics of protocols much more heavily than one would like for otherwise solid connections.


Thanks @AndyW. Still 3 more questions:

  1. I want to use Adafruit BLE board. But it does not have any pins related to COEXISTENCE INTERFACE. I checked nRF8001 reference design on Nordic website, but I could not find any pins related. Any example of how this INTERFACE is used?
  2. If COEXISTENCE INTERFACE is used, is it possible for both WiFi and BLE share the same antenna?
  3. Is there any project in progress or a reference design to have P1 and a BLE chip in one board?

@Amir, I’d understand the pins REQ, RDY and ACT make for a good counterpart for the coexistance pins on the Photon.

My guess would be

BTCX_STATUS      ->    RDY (not sure about this)
BTCX_TXCONF      ->    REQ
1 Like

Thanks @ScruffR. Looking forward for an answer to the 2nd and 3rd questions.

For the second question, both the P1 and the Adafruit board you mentioned already have an antenna designed into them. Are you trying to make your own board with the P0 and nrf8001 and have them share the same antenna?

For the third, yes, the bluz gateway will use the P0 and an nrf51822 on the same PCB. They will use the coexistence pins (to some degree). The nrf51822 doesn’t explicitly support the same type of interface, so there will be some other means to try and coordinate the transmissions between the two.

1 Like

Thanks @eely22 . You guys have done the heavy lifting! Is Bluz gateway OSHW? I could not find its files on your gitHub.

Yes, it is. We haven’t put that one up yet as we are still trying to minimize the footprint. We want to try and make the gateway as small as possible so it can be used for others products. The P1 is rather large, so we are currently looking at the best way to do this, or even if it makes sense to switch to the P0 and do the FCC testing ourselves.

One note, I noticed I wrote P0 in my last post. I meant the P1 as that was the original plan, though like I just said, we are still evaluating that.

I will let you know as soon as we figure this out.

1 Like

We published the hardware files for the bluz gateway today. These are pretty preliminary, I am still looking into ways to make this smaller and better, but I figured I would publish what we had so far and try to gather feedback from people. Would love to know what you (and everyone else) thinks:

1 Like

Hi eely22,

Looking forward to using this with Photon. (edited, found docs on github…)

Great! Most things are on GitHub and are open, though we have a few things that are currently hidden but available to beta testers. If you feel you need more info, please email me at we can certainly get you anything you may need.

Hi eely22,

For a first test to use bluz I want to use only UART connectivity between nRF51882 and Photon.

So if I follow the instructions at here
to hook up a MDBT40P from seeed studio to the Photon,

Would I need to program the nRF51822 for UART operation with a Photon?
Or the UART on nRF51822 just “works” ?


You want to use an nrf51822 dev board from Seeed and hook it to a Photon? You would have to program the nrf51 with whatever tools Seeed offers to use UART and talk to the Photon. That tutorial is part of our docs and would only work with the bluz firmware, so it wouldn’t work with any old nrf51.

You could always try to flash the bluz firmware onto the MDBT40, that would work, though some features may not work depending on the hardware rev and unless you hooked up SPI Flash or blocked some of that out.

What is it that you’re trying to do exactly?

Is that not what you have on github: here

the MDBT40P is not a dev board…me thinks …is it? Here is the link
The description calls out that it is a module, with same (?) pinout as you have in your schematic.

So, per your schematic, there is SPI flash… which I may upgrade to a microSD (is this possible?)

What I am trying to do: Same as your schematics, but with some changes (SPI, LED, etc)…

Would I still need to flash Bluz on microSD, perhaps via external means?

I guess I am getting a little confused about your different hardware and software requirements.

Yes, that shematic shows the gateway shield which is essentially an MDBT40 attached to a Photon through 7 GPIO lines. The MDBT40 also uses external SPI Flash. You can certainly recreate or modify this hardware.

The bluz firmware is currently for a BLE peripheral. Do you want a central device? Once the gateway firmware is open sourced, you would be able to use it on the above hardware. We do have firmware that works today, but it currently is not open source.

If you want to replace any of the hardware, you would need to modify the firmware to accommodate that. We store things like the Particle ID, keys, and OTA updates on the external flash. So if you wanted those features to work, you would need to modify the firmware to use whatever you want instead. We don’t load code onto the external flash, we use SWD to program the MDBT40, so you would need to make sure those lines are broken out as well or that you have some way to program it.

One not, if you want to use any of the Particle features, you need to make sure you buy an MDBT40 that has 32K RAM. Only the most recent rev of nrf51 has this, and it is still optional. So you should look for that.

Hmmm… I am still reading up on Bluz. Thanks for the info. I see the use of SPI flash in you schematic now.

In my application, I am using the Photon as the central device, and the BLE only to communicate some commands, or files to up load to photon. Photon then acts on this data… may be to access cloud.

With that in mind, I see that perhaps I do not need the SPI flash, not the SPI interface to Photon (-- unless I want to stream from an external BLE to this MDBT40P then on to Photon.).

So the simples application would have only the Rx/Tx between MDBT40P and the Photon, plus SWD pins for MDBT40P.

May be the above is a good start until you release firmware to opensource.
The above approach will also give me a chance to familiarize and learn about Bluez…

Dont know why I did not go to first!. It appears you are doing what I am looking for. And you mentioned in your earlier reply " please email me at we can certainly get you anything you may need." … I could become a beta tester, if you can provide me a few units of the core/photon+MDBT40P …??

Hi folks,

My teammate and I are currently trying to integrate bluetooth module (nrf51822) and Particle photon into single entity, which has capability of supporting WiFi and blurtooth communications. We are worrying about the issues of interference of bluetooth and WiFi, as both of them occupy 2.4GHz band.

Although there are 3 bluetooth co-existence pins on photon already, however, it looks like they are not supported currently (see From my test, I actually didn’t feel significance interference happened, but not sure whether this can be a issues in the future deployment??

@eely22 do you have any ideas and thoughts on the interference between ble and photon?
In our case:

by the way, is there any way to detect which channel of 2.4GHz do the bluetooth device is currently used?

Thank you!