This item has been resolved.

Per SiLabs, the BT5.0 coded PHY uses secondary advertisements. These advertisements contain a pointer to another channel where the actual data can be found. As a result, a ~60% advertisement packet rate is not considered to be a malfunction. This is incompatible with beacon style applications that require a high packet capture rate. When implemented in low level physical RF, the benefits of a coded PHY are clear but they are lost when implemented as a beacon. 

This item has been resolved.

Per SiLabs, the BT5.0 coded PHY uses secondary advertisements. These advertisements contain a pointer to another channel where the actual data can be found. As a result, a ~60% advertisement packet rate is not considered to be a malfunction. This is incompatible with beacon style applications that require a high packet capture rate. When implemented in low level physical RF, the benefits of a coded PHY are clear but they are lost when implemented as a beacon. 

This item has been resolved.

Per SiLabs, the BT5.0 coded PHY uses secondary advertisements. These advertisements contain a pointer to another channel where the actual data can be found. As a result, a ~60% advertisement packet rate is no considered to be a malfunction. This is incompatible with beacon style applications that require a high packet capture rate. When implemented in low level physical RF, the benefits are clear but they are lost when implemented as a beacon. 

Is this thing on? Hello? 

Repeated test data at 100ft and 10ft. 

Coded at 10ft -13 RSSI 60% packets

Coded at 100ft -49 RSSI 60% packets

1M at 10ft  -10 RSSI 95% packets

1M at 100ft -49.5 RSSI 96% packets

Delu,

Still hoping to hear about the range test function you mentioned. 

Delu,

We're using 125k. EFR32BG13 can't do 500k S-2 to my knowledge. 

For clarity, I believe we're doing something wrong. There's no chance that SiLabs would offer a "long range" phy that loses 7/10 packets in an open air test. 

Jun,

A RF clean area that is more than 300ft long is a luxury I do not possess. Running the test on our roof with elevated platforms next to a 1M phy test that shows high packet count and stable RSSI is my way of getting as close as I am able. I hope your not asserting that the long range PHY works, but only in a chamber. That would be relatively useless for real world applications. 

Can you elaborate on the range test function you described?

We're running some open air tests on SiLabs EFR32BG13 demo board/dev kits. Using BGTool, we're just advertising on 37/8/9 and recording it with a sympathetic receiver in the correct PHY. The results received were concerning on a few fronts. Primarily, 2 items. 

1: The coded PHY seems to have an issue with packet loss when advertising. This has been repeated here in our lab in a multitude of setups/environments.

2. The long range - low power setup i had intended to create instead gave me similar RSSI but particularly poor packet rate across the board. This is counter to my expectations. This will be recreated again when it stops raining. 

Transmitter and Receiver: SILabs demo boards, X axis horizontal. Elevation of system, rooftop ~25ft. Sensors on plastic elevations ~4ft tall.

Receiver using BGTools, generic scanning mode with PHY set to match transmitter

5 minute scans.

+10dB

Coded PHY 300ft range

RSSI -79.9

Packet reception rate 40.1%

1M PHY at 300ft range

RSSI -80.8

Packet reception rate 79.4%

+0dB

Coded PHY 300ft range

RSSI -81.7

Packet reception rate 34%

1M PHY at 300ft range

RSSI -80.8

Packet reception rate 39%

*****edited*****

Retested at ½ range

+0dB

Coded PHY 150ft range

RSSI -71.3dB

Packet reception rate 57.9%

1M PHY at 150ft range

RSSI -75.5

Packet reception rate 94%

We're running some open air tests on SiLabs EFR32BG13 demo board/dev kits. Using BGTool, we're just advertising on 37/8/9 and recording it with a sympathetic receiver in the correct PHY. The results received were concerning on a few fronts. Primarily, 2 items. 

1: The coded PHY seems to have an issue with packet loss when advertising. This has been repeated here in our lab in a multitude of setups/environments.

2. The long range - low power setup i had intended to create instead gave me similar RSSI but particularly poor packet rate across the board. This is counter to my expectations. This will be recreated again when it stops raining. 

Transmitter and Receiver: SILabs demo boards, X axis horizontal. Elevation of system, rooftop ~25ft. Sensors on plastic elevations ~4ft tall.

Receiver using BGTools, generic scanning mode with PHY set to match transmitter

5 minute scans.

+10dB

Coded PHY 300ft range

RSSI -79.9

Packet reception rate 40.1%

1M PHY at 300ft range

RSSI -80.8

Packet reception rate 79.4%

+0dB

Coded PHY 300ft range

RSSI -81.7

Packet reception rate 34%

1M PHY at 300ft range

RSSI -80.8

Packet reception rate 39%

That was the plan yes. We've verified that using the DTM tester (or API directly) will only put out pulses of the unmodulated carrier and not actual tones. And that's the case for modulated PN9 or unmodulated. 

There's some question that the DTM might have a bug that doesn't generate 100% duty cycle on the first command, but we've been unable to verify. 

We've found that the RAIL API allows us to generate a tone however. But it's difficult to control and we're not able to marry that function with the control we get with the DTM and phone app. 

We're using 2.8.1.0

Hi,

We're trying to achieve a test of our radiated antenna performance to verify tuning without wires. We have an enclosure which prevents access without compromising the test. As such, we need to be able to, without serial port lines for RAIL, accomplish a 100% TX output. We're able to do so with the RAIL application and a serial port, but that's not acceptable for the actual test.

What we envision is a device that comes out of reset and just generates a tone for around 5 minutes on a channel, moves to a new channel, waits 5 min, etc.

We found and tried gecko_cmd_test_dtm_tx(test_pkt_carrier,0,37,1) but that still appears to only generate pulse TX and not a continuous tone. 

Thanks in advance,

Jason