IQ sample of BLE signal from Lopy4

  • Hi,
    I am now trying to use software defined radio(SDR) to sample the BLE signal from Lopy4. The shape of the received radio seems to be incorrect. Could you help me have a look?
    ![alt text](92c2e497-2611-4642-9a62-27d88b21d32c-image.png image url)
    ![alt text](1b2999d9-b84f-42bc-86d5-e3375c4f2ff9-image.png image url)
    The upper image is the real received signal and the lower one is the BLE signal simulated using MATLAB. I capture the signal in channel 39 only. The sampling rate is 8M samples per second and the bandwidth is 2M.
    Since there is preambles in the beginning of each BLE packet, repeated patterns should appear in the beginning of the packet(just as the simulated BLE signal shows). However, there is now no repeated patterns.
    Thanks for your time

  • @yongyuan-wang I would be surprised if you didn't have any other devices sending out BLE advertisements at hand. Nearly any phone would, for instance. Most if not all Macs, many PCs, tablets, TV boxes... In an urban environment it's actually difficult to not see BLE advertisements all over the place, probably even more than Wi-Fi.

  • Right, but you still have the issue of signal scattering and receiving out of phase components (except if you're measuring in a anachoic chamber, but then you would probably not be asking the question here :) ). What you could perhaps try is feed of the BLE signal from the Lopy4 from the external antenna connector into the SDR using an attenuator in between (not sure about your SDR capabilities). That should at least remove most environment variables

    How can you be sure the start of the signal you plot is correct to the time the signal is sent?

    I'd also highly suggest you to take a look at something like this:

    Again, I do not have any expertise in the PHY BLE layer, but the ESP32 microcontroller is widely used and I do not believe the hardware is outputting an incorrect signal there.

  • @jcaron said in IQ sample of BLE signal from Lopy4:

    @yongyuan-wang as the ESP32 is certified and able to communicate with other BLE devices, it seems unlikely it’s signal is incorrectly modulated, and more likely there’s an issue with the way you capture the signal.

    Have you tried capturing the signal of other BLE devices? Are you capturing on the right frequency?

    I only have Lopy4 on my hand and test 3 devices having the same issue. I set the sdr with center frequency 2.48Ghz and bandwidth 2MHz, which should perfectly fit the channel 39 of BLE

  • @yongyuan-wang as the ESP32 is certified and able to communicate with other BLE devices, it seems unlikely it’s signal is incorrectly modulated, and more likely there’s an issue with the way you capture the signal.

    Have you tried capturing the signal of other BLE devices? Are you capturing on the right frequency?

  • @Gijs Thanks for your reply. Please let me talk about what I am trying to do now.
    The figure above shows the packet format of the LE uncoded PHYs that is used in lopy4. I use the following codes to send BLE advertisement packets.

    from network import Bluetooth
    from machine import Pin
    import time
    BT = Bluetooth()
    BT.set_advertisement_params(adv_int_min=0x20, adv_int_max=0x20)

    Please just look at the first two parts of the BLE packets(preamble and Access Address). I looked up the specification of BLE and find that the value of preamble and Access Address are the same for each packet. The preamble should be 10101010 or 01010101 and the value of Access Address should be 10001110100010011011111011010110b (See the following figures)
    My project is to collect this part of BLE packets that send the same value(or data). I have 10 lopy4 here and I want to use CNN to distinguish each devices(signal waveforms may be not the same due to hardware imperfections, though sending the same data).
    My question is since the whole packet is modulated in the same method(GFSK), there is no reason the preamble looks totally different from the Access Address part.
    Besides, the simulated signal also shows the preamble part should have some ripples, instead of a descending curve.
    The sample rate I set is 8M samples per second and the symbol rate of BLE is 1M symbol per second. 8 samples per symbol and the preamble has 8 symbols (1 symbol equals 1 bit here). Therefore, the first 64 samples should be the preamble and it appears that the first 64 samples are not similar to the following samples. So I am not sure if there are problems with the modulation of the preamble or just my misunderstanding of this topic
    Thanks for your time

  • Im having a hard time getting up to speed here as you've probably been working on this longer than me.. Could you elaborate on what you are trying to achieve?

    Online you can find various sources on how to decode the BLE signal with an SDR that could probably help you better than I can.

    We have had no issues (as far as I know) with BLE connections, so Im assuming there is no issue with the actual signal

  • Hi,
    I have not do any corrections yet, but my purpose is not to decode or recover the signal.I did the auto-correlation to the whole received frame to detect the start point of the BLE packet. The originally received frame should be like this:
    Besides, one thing to be curious is that the first 64 samples should be the preamble part of BLE packet. I can see there are phase shift in the simulated data but no phase shift in the real received data. I do understand the noise or environment will affect what I received, but I do not understand why there seems to be no phase inverse in the first 64 samples and apparent phase inverse in the rest 256 samples with the same type of modulation (GFSK)
    Thanks for your time
    Yongyuan Wang

  • Hi,
    I have no experience with the low-level signalling of BLE, but I do know some things about RF propagation.
    Did you do any processing to the signal you received on the SDR? The transmitted signal will get reshaped by reflections (different path lengths), phase distortion, scattering, diffraction etc. Perhaps try to auto-correlate the received signal and/or apply some noise corrections. Did you do any sample clock or phase corrections? Also, absolute vs real/imag could throw you off there.

    It is very hard to accurately sample the BLE signal and there's a lot of signal processing that goes into receiving such a signal on chip.
    Let me know!

Log in to reply

Pycom on Twitter