BLE module likely broadcasting at undesired time

[Dak]

Hello,

I'm using a nrf51422_xxac_s110, with the Keil uvision IDE.  I recently upgraded my sdk from an older version, to 12.3 in order to use some components like FDS.  Consequently I also had to change my soft device hex file from 

s110_nrf51_8.0.0_softdevice.hex     to

s130_nrf51_2.0.1_softdevice.hex   

in order to have the module broadcast, and establish a connection from our app.  

Our BLE module is connected to a larger embedded device, and communicates with a processor within that device via two pins that are basically Tx and Rx.  These two pins are multiplexed to also communicate with a physical wire connection.  At any given time only one of either the BLE module, or the physical wire can have an established connection to the port that handles the content received and transmitted on these pins.  

I'd like to know how I can stop the BLE from broadcasting, or at least lower the rate at which it broadcasts so interference is kept to a minimal?  Would using a different softdevice.hex file help instead?  

Thanks

Dak

[Dak]

I should have explained further that when we connect using software running on a PC with the wired connection, using a Modbus protocol, the connection is dropped, which we believe is due to the BLE module continuing to broadcast on the same pins.  I haven't scoped those pins yet to see if that's necessarily the case.  When we used s110_nrf51_8.0.0_softdevice.hex with the older sdk, we didn't have this issue.

[Einar Thorsrud]

Hi Dak,

Our BLE module is connected to a larger embedded device, and communicates with a processor within that device via two pins that are basically Tx and Rx.  These two pins are multiplexed to also communicate with a physical wire connection.  At any given time only one of either the BLE module, or the physical wire can have an established connection to the port that handles the content received and transmitted on these pins.  

So the nRF and some external device (whatever is on the "physical wire connection") use the same pins to communicate with the host MCU? So this is effectively a bus. What protocol do you use? And how do you control whether the nRF or the other device are allowed to communicate on the bus?

I'd like to know how I can stop the BLE from broadcasting, or at least lower the rate at which it broadcasts so interference is kept to a minimal?  Would using a different softdevice.hex file help instead?  

Broadcasting here, is that BLE on-air, or communicating with the MCU on the pins/bus? If BLE, then it is up to you to terminate any connections and/or stop advertising or active scanning. If communication with the host MCU then that depends. There is no information here on how this communication happens, so you must elaborate on what protocol you use (is it UART, SPI, etc.?), how you signal which device is allowed to communicate, and how you control this on the nRF side.

I'd like to know how I can stop the BLE from broadcasting, or at least lower the rate at which it broadcasts so interference is kept to a minimal?  Would using a different softdevice.hex file help instead?  

Hot to stop BLE advertising/broadcasting depends a bit on if you are using a library to handle advertising for you, but generally you need to somehow call sd_ble_gap_adv_stop().

[Dak]

Hi Einar, 

I did some further investigating, and it seems the issue I raised was actually a non-issue, based on a misunderstanding on my part about our system.  Thank you for your lengthy answer to my poorly worded question.  You can consider this resolved.

[awneil]

Dak said:

You can consider this resolved

You do that by verifying an answer: