This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How do I eliminate advDelay inserted in advertising events of S132

We need to accurately control the time when the Bluetooth advertising package is sent out,
so that the two slavers can simultaneously send the beacon data to produce the signal overlap area, so that we can clearly know which slaver the label is near.

In S132, is there an advDelay inserted before sending the first advertising package?Is there any way to send the broadcast packet immediately without delay?

[1]Only the 37 channel are used in the ble_advertising_start():

 // Initialize advertising parameters with default values.
    memset(&p_advertising->adv_params, 0, sizeof(p_advertising->adv_params));
	p_advertising->adv_params.channel_mask[4]=0xC0;//37

[2]By toggle IO pin every second triggers an interrupt to call in_pin_handler(). The advertising_start()

is called once per second.

bool First_Advertising_End_Flag=0;
void in_pin_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)//中断回调函数
{
	if(nrf_gpio_pin_read(KEY_1)== 0)
	{
		if(nrf_gpio_pin_read(KEY_1)== 0)
		{
			if(First_Advertising_End_Flag==0)
			{
				First_Advertising_End_Flag=1;
			}
			else if(First_Advertising_End_Flag==1)
			{
				sd_ble_gap_adv_stop(m_advertising.adv_handle);
			}
			advertising_start();
		}
		
	}
}

Parents
  • Hello,

    In S132, is there an advDelay inserted before sending the first advertising package?

    Yes, this advDelay is part of the BLE specification, and thus is present in all of our SoftDevices - since they all conform to the specification.

    Is there any way to send the broadcast packet immediately without delay?

    Unfortunately, there is not. This delay must be present in all BLE conforming devices. If this behavior is paramount to your application you might have to look into using a proprietary radio stack, in which you could implement this however you would want.

    We need to accurately control the time when the Bluetooth advertising package is sent out,
    so that the two slavers can simultaneously send the beacon data to produce the signal overlap area, so that we can clearly know which slaver the label is near.

    Could you describe the sought after functionality more?
    Perhaps there is a way to achieve this while still conforming to the BLE specification.
    Are you only looking to know which beacon is closest? Have you already ruled out the possibility of using the RSSI for this?
    It would of course be hard to get a clear cut answer to which device is closest(due to the RSSI's inaccuracy), but it could be used to tell if the devices are "close, far, or outside reach" at least.

    Best regards,
    Karl

  • Hello Karl,
    You are really perceptive.indeed, we are doing Bluetooth indoor RTLS.
    RSSI is easily influenced by external environment and leads to misjudgment.
    Our solution is to make logical positioning in key locations, such as inside and outside doors.
    We can adjust the Bluetooth transmitting power of two locators to generate signal overlapping area.
    If close to one of the locators, the Bluetooth data of the other locator will not be received,
    then the positioning data of this locator can be received stably, and the purpose of clearly locating the room can be achieved.

    I have seen in Nordic Devzone that TimeSlot can work without closing the protocol stack.So I can control the RF to send 2.4GHz data between sd_radio_session_open() and sd_radio_session_close().I think it is possible to precisely control the time of sending the Beacon in this way.

    Best regards,
    Gale Du

  • Hello Gale Du,

    杜明伟 said:
    You are really perceptive.indeed, we are doing Bluetooth indoor RTLS.
    RSSI is easily influenced by external environment and leads to misjudgment.

    Yes, you are absolutely correct. The issue of using RSSI for RTLS project has been discussed many times over in the forum already, and I recommend taking a look at these discussions.
    My previous answer in this ticket tries to summarize these discussions, briefly.

    杜明伟 said:
    Our solution is to make logical positioning in key locations, such as inside and outside doors.
    We can adjust the Bluetooth transmitting power of two locators to generate signal overlapping area.
    If close to one of the locators, the Bluetooth data of the other locator will not be received,

    Does the system need to pinpoint if a person has passed through a door within the last minute, or more real-time like 'currently passing through the door'?
    I assume then that the moving device will be sending out advertisements, and that the locators will pick up these advertisements when the moving device gets near, or will it be the other way around - the moving device will detect the advertisements of the locators, and report it to some other database which then knows where they are?
    If the former, you could turn down the TX power on the moving device - which will also save power - to increase the chance that only 1 of the two locators will receive the advertisement packages.
    Additionally, if you place the locators with a little distance to the door in question ( such as in a hallway leading up to the door ) you should be able to track the logical position of the person with some accuracy ( if the overlapping zone of two locators is kept small ).
    Keep in mind that this is just speculations on my part, as I do not know the exact requirements of your application.

    杜明伟 said:
    I have seen in Nordic Devzone that TimeSlot can work without closing the protocol stack.So I can control the RF to send 2.4GHz data between sd_radio_session_open() and sd_radio_session_close().I think it is possible to precisely control the time of sending the Beacon in this way.

    That's correct, you may use the Timeslot API to schedule timeslots in which you could use the radio proprietarily. This way, you could use the radio without consideration of conforming to the BLE specification. The downside to this of course is that you yourself have to implement this proprietary radio behavior yourself.

    Best regards,
    Karl

  • Hello Karl,
    By the TimeSlot function, we have been able to send 2.4GHz data of ESB protocol without stopping the BLE stack.
    We are now able to control both locators to send 2.4GHz data at the same time, One of the locators send RF data with a delay of 5-192us, resulting in signal overlap.
    Test equipments: No. 1 locator (transmitting 2.4GHz data), No. 2 locator (transmitting 2.4GHz data), receiving label (receiving 2.4GHz data), frequency point 2498MHz
    Locator placement height: 2.1 meters
    Locator placement distance: 8 meters
    TX power of locator: -20dBm
    Test shows: In the middle position, in all directions, either receive No. 1 locator data, or receive No. 2 locator data, or receive nothing at all.
    It is strange that the signal don't overlap in all directions by turning the receiver tag.

    Thank you for taking the time to answer my question. Do you know the reason for this phenomenon?

    Best regards,

    Gale Du

  • Hello Gale Du,

    杜明伟 said:
    By the TimeSlot function, we have been able to send 2.4GHz data of ESB protocol without stopping the BLE stack.

    Great, I am happy to hear that you got this up and running!

    杜明伟 said:

    Test shows: In the middle position, in all directions, either receive No. 1 locator data, or receive No. 2 locator data, or receive nothing at all.
    It is strange that the signal don't overlap in all directions by turning the receiver tag.

    Thank you for taking the time to answer my question. Do you know the reason for this phenomenon?

    First of all I will have to say that it is very hard  to say anything about the 2.4 GHz environment of your test without being there myself - there could be many environmental factors degrading your performance, for example if there is tons of reflections in the test hallway, or if the test door is made of metal or other reflective materials, or if there is a lot of interference from other 2.4 GHz sources, so it is hard to say anything definitively - but let us take a look!

    Could you possibly include a sketch of this test setup? Is there a door in-between one of the locators and the receiver, for example? You mentioned this earlier, but I am uncertain if this is relevant for the test you describe in your most recent comment.

    Could you retry this test with more TX power, and see if this resolves your issue?
    For example, increase the TX power of the locators to +0 dBm and see how well this is picked up by your receiver. If it is reliably picked up you could turn down the TX power and try again.

    Could you also elaborate for me how you are testing this - how is your receiver configured? Have you tested that the receiver works as intended when it is very close to the locator and with a clear line-of-sight(to ensure that the receiver works as intended)? Are you using a customer FW implementation as the receiver in the test, or are you using the nRF Sniffer tool? I recommend that you use the nRF Sniffer tool to do these tests, to see if any advertisements makes it to the receiver successfully.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Reply
  • Hello Gale Du,

    杜明伟 said:
    By the TimeSlot function, we have been able to send 2.4GHz data of ESB protocol without stopping the BLE stack.

    Great, I am happy to hear that you got this up and running!

    杜明伟 said:

    Test shows: In the middle position, in all directions, either receive No. 1 locator data, or receive No. 2 locator data, or receive nothing at all.
    It is strange that the signal don't overlap in all directions by turning the receiver tag.

    Thank you for taking the time to answer my question. Do you know the reason for this phenomenon?

    First of all I will have to say that it is very hard  to say anything about the 2.4 GHz environment of your test without being there myself - there could be many environmental factors degrading your performance, for example if there is tons of reflections in the test hallway, or if the test door is made of metal or other reflective materials, or if there is a lot of interference from other 2.4 GHz sources, so it is hard to say anything definitively - but let us take a look!

    Could you possibly include a sketch of this test setup? Is there a door in-between one of the locators and the receiver, for example? You mentioned this earlier, but I am uncertain if this is relevant for the test you describe in your most recent comment.

    Could you retry this test with more TX power, and see if this resolves your issue?
    For example, increase the TX power of the locators to +0 dBm and see how well this is picked up by your receiver. If it is reliably picked up you could turn down the TX power and try again.

    Could you also elaborate for me how you are testing this - how is your receiver configured? Have you tested that the receiver works as intended when it is very close to the locator and with a clear line-of-sight(to ensure that the receiver works as intended)? Are you using a customer FW implementation as the receiver in the test, or are you using the nRF Sniffer tool? I recommend that you use the nRF Sniffer tool to do these tests, to see if any advertisements makes it to the receiver successfully.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Children
Related