What's the difference between 1M and non-1M firmware in releases? Is it related to Bluetooth relay?

[Haicaji]

As the title states, I'm encountering issues while trying to reproduce Bluetooth relay functionality. My hardware knowledge is limited, and I'm unsure if this is firmware-related.

---

Reproduction Environment

Let me briefly describe my reproduction environment.

Hardware & Software

• Hardware: Two LP-CC1352P7-1 boards
• Software: Python scripts and firmware (sniffle_cc1352p7.hex) from v1.11.0

Flashing Method

I'm using uniFlashGUI on Ubuntu for flashing.

---

Issues with Bluetooth Relay

I'm attempting to relay Bluetooth signals with this setup to control Bluetooth devices. I can successfully relay advertising data, but when I try to connect, it fails, and I'm unable to retrieve GATT service information.

I noticed that in the program output, there is only Bluetooth traffic from C to P, but no traffic from P to C. It seems that my Bluetooth device is not connected to the relay device. Based on the captured pcap file, I only saw broadcast and connection request Bluetooth traffic from the device.

---

Attempted Solutions

Using Firmware with 1M Suffix

I'm not entirely sure what 1M refers to here. Flash? PHY?

I tried flashing firmware with the 1M suffix, but the device doesn't seem to operate normally. After running scanner.py, I get no results even after a long wait.

XDS110 UART Latency

I considered the XDS110 UART Latency mentioned in the README. However, the README refers to version 3.0.0.28, while my version is 3.0.0.38. I'm not familiar with firmware modifications; perhaps I should revert to an earlier version?

I reverted to version 3.0.0.28 and modified and flashed the firmware, but it did not improve the relay performance.

Network Channel Latency

In the relay script, the reported test latency is around 4ms. I'm wondering if this could be the issue.

Do you have any suggestions on how I should continue troubleshooting to successfully reproduce Bluetooth relay?

[Haicaji]

Today, I wrote a simple Bluetooth device using an ESP32-C3 to replace the previous one. Initially, it still couldn't relay the Bluetooth signal. However, after I repositioned both the peripheral and the phone connected to the ESP32, I was surprised to find that the relay started working.

By the way, I forgot to mention earlier: due to the limited space in my home, I couldn't place the two devices far apart. So I tried wrapping both the master device and the ESP32 Bluetooth device in aluminum foil, and moved the phone and the peripheral as far as possible from them. Unfortunately, the shielding wasn’t perfect—some residual BLE signal still leaked through. Although the signal was too weak to establish a reliable connection, I'm wondering whether this residual signal might be the cause of the relay failure.

Later on, I switched back to the original Bluetooth device. In this setup, the master device was able to relay the advertisement and scan response packets from the peripheral to the phone, but the connection still couldn’t be successfully established. I'm not sure if leftover residual signals from the earlier setup were causing interference. Do you have any suggestions on how to improve the reliability of the link-layer relay?

[sultanqasim]

The 1M firmware builds just use 921600 baud instead of 2M baud. It's meant for people using USB-Serial adapters that don't support 2M baud (i.e. CatSniffer dongles and certain pandemic-era Sonoff dongles). Use the regular (non-1M) firmware builds unless your hardware doesn't support 2M baud; if the regular releases work at all, your hardware supports 2M baud.

As for your intermittent relay issues, there are a few plausible causes that come to mind:

1. When the legitimate advertiser and the relay advertiser both are in signal range of the legitimate initiator, the legitimate initiator may connect to either depending on which advertisement it chooses to respond to with a connection request. Having the relay broadcast advertisements more frequently can help tilt the probabilities, as would weakening the legitimate advertiser signal sufficiently to interfere with its reception by the legitimate initiator. However, completely blocking the legitimate advertiser's signal would prevent the relay initiator (relay master) from connecting to it, so you can't do that.
2. Right now, the relay advertiser (relay slave) keeps broadcasting stale advertisements even after you end the script, which can cause confusion with stale MAC addresses and result in a dummy device that doesn't respond properly when you connect to it. I plan to modify the relay advertiser (slave) script to stop advertising on exit to avoid this confusion in the future.
3. Connection establishment isn't 100% reliable, and depending on how crowded the RF environment is, could be less than 50% reliable in some cases. The relay code assumes connection initiation works on the first try, but in practice it doesn't. Real devices will usually retry connecting if the first attempt fails, but finding out a connection attempt failed, waiting till the next advertisement, and then trying to connect again takes time, enough time to sometimes cause issues when relaying. Thus, I don't plan to implement connection retries by the relay initiator (master) code for now.

[sultanqasim]

The UART latency is rather critical, and unmodified XDS110 firmware causes relaying to fail for some controllers. For reliable relaying you will either need to use my modified XDS110 firmware (following the instructions in the README to edit the old XDS110 firmware release) or use a device with a low-latency USB-UART bridge like a Sonoff dongle.