[Hackrf-dev] A BTLE (Bluetooth Low energy)/BT4.0 radio packet sender

Fri Aug 22 09:07:31 EDT 2014

I agree that some code on the ARM would be required.  Additionally,
there are probably ways to improve the tuning and rx/tx switch timing
even from the ARM.  We haven't done much to optimize those things.
There may be a lot of time that could be saved by speeding up SPI or I2C
communication or by eliminating unnecessary commands being issued by the
ARM to the other chips.  It may even be possible to parallelize some
things that are now done in sequence.

Overall, I'm pretty sure that the timing required for LE operation is
achievable, but I'm not sure how close our current code is to being fast
enough.

Mike

On Wed, Aug 06, 2014 at 09:55:13AM +0800, Jiao Xianjun wrote:
>
> Hi Ryan,
> 
> Thanks a lot for your offering the information. You are mastery on BTLE
> protocol! I should learn more.
> 150us seems too fast for computer, and should consider on-board processing.
> 
> BR
> 
> Jiao Xianjun
> 
> 
> On Wed, Aug 6, 2014 at 9:46 AM, Mike Ryan <mikeryan at lacklustre.net> wrote:
> 
> > It is possible to hop at such a low rate, but the timing of the
> > beginning of each connection event (where the master and slave transmit
> > on each channel) has to be very precise. Additionally, a master and
> > slave must have a TX-to-RX and RX-to-TX turnaround time of 150 +/- 2 us.
> >
> > In other words, after a master transmits, it must be able to receive the
> > slave's reply within 150 us. A slave must be able to switch from
> > receiving the master's packet to transmitting its reply within 150 us.
> >
> > On Wed, Aug 06, 2014 at 09:30:19AM +0800, Jiao Xianjun wrote:
> > > You are correct on that USB latency. I did a quick experiment just now to
> > > test fastest switching speed of my BTLE packet sender via hackrf (Set
> > Space
> > > field to 1, means that I want it be 1ms). It is around 60ms. (See the
> > > snapshot attached, time stamp of the last three packets).
> > >
> > > 60ms maybe not so bad for real BTLE frequency hopping? I just do a quick
> > > search for this to verify that (see attached two .pdf, and search hopping
> > > in them). Seems that hopping speed requirement is not so high, and 60ms
> > is
> > > OK. Just paste some related words here:
> > >
> > > "For a new connection event, master and slave use a new data channel
> > > frequency, which is computed
> > > by using the frequency hopping algorithm. The time between the start of
> > two
> > > consecutive connection
> > > events is specified by the connInterval parameter, which is a multiple of
> > > 1.25 ms in the range between
> > > 7.5 ms and 4 s. Another important parameter is connSlaveLatency, which
> > > defines the number of
> > > consecutive connection events during which the slave is not required to
> > > listen to the master and thus
> > > can keep the radio turned off. This parameter is an integer between 0 and
> > > 499 and should not cause a
> > > supervision timeout. A supervision timeout happens when the time since
> > the
> > > last received packet
> > > exceeds the connSupervisionTimeout parameter, which is in the range
> > between
> > > 100 ms and 32 s. The
> > > purpose of this mechanism is to detect the loss of a connection due to
> > > severe interference or the
> > > movement of a device outside the range of its peer.
> > > "
> > >
> > > "The frequency retention time in the frequency hopping method shall be
> > 0.4
> > > second or less. For
> > > the radio equipment that uses the frequency hopping method excluding a
> > > combination of the
> > > spread spectrum method and OFDM, the total sum of the frequency retention
> > > time in any frequency
> > > within the time obtained by multiplying the diffusion rate by 0.4 second
> > > shall be 0.4 second or
> > > shorter.
> > > "
> > >
> > >
> > >
> > > 
> > >
> > >
> > >
> > >
> > > On Wed, Aug 6, 2014 at 8:54 AM, Mike Ryan <mikeryan at lacklustre.net>
> > wrote:
> > >
> > > > I suspect the radio hardware is capable of retuning very quickly, but
> > > > the USB latency is too high for real-time channel hopping. It would be
> > > > necessary to enqueue packets on the HackRF and have the ARM MCU control
> > > > the timing of channel hops.
> > > >
> > > > I didn't mean to sound too negative. Your development is very
> > > > interesting, and I definitely think it could be used as the basis of a
> > > > more robust BLE device emulator.
> > > >
> > > > On Wed, Aug 06, 2014 at 08:50:09AM +0800, Jiao Xianjun wrote:
> > > > > Exactly.
> > > > >
> > > > > What I do is just offering  a tool. Those example is just a simple
> > > > > verification.
> > > > >
> > > > > I think the tool and hackrf do have the full ability, because hackrf
> > can
> > > > > switch from channel to channel very quickly (less than several us?
> > Maybe
> > > > > Ossmann can give some number?).
> > > > >
> > > > > You may define a packet sequence with each packet starting with
> > different
> > > > > channel number as you want, then hackrf will transmit a hopping
> > channel
> > > > > packet sequence.
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Aug 6, 2014 at 12:02 AM, Mike Ryan <mikeryan at lacklustre.net>
> > > > wrote:
> > > > >
> > > > > > Crackle will crack the pairing that is found in *any* PCAP file, it
> > > > just
> > > > > > so happens that Ubertooth is the best tools for producing these.
> > > > > >
> > > > > > The sample packets provided by Jiao Xianjun do not include a
> > pairing
> > > > > > sequence, just the encryption start sequence. Lacking the pairing,
> > > > > > Crackle can't do anything here.
> > > > > >
> > > > > > Also, the sample packets are not part of a legal BLE connection.
> > The
> > > > > > HackRF sits on a single channel (physical channel 9) and sends them
> > > > out.
> > > > > > A real BLE connection hops among the data channels as it transmits,
> > > > only
> > > > > > sending a single packet per channel.
> > > > > >
> > > > > > On Tue, Aug 05, 2014 at 08:26:10AM -0400, Luke Berndt wrote:
> > > > > > > Nicely done! Does anyone know if it would be possible to get
> > CrackLE
> > > > > > running against this? It was designed for UberTooth so I am not
> > sure
> > > > if it
> > > > > > needs some HW.
> > > > > > > https://github.com/mikeryan/crackle/
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Sent from my iPhone
> > > > > > >
> > > > > > > > On Aug 5, 2014, at 2:15 AM, Jiao Xianjun <putaoshu at gmail.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > A BTLE (Bluetooth Low energy)/BT4.0 radio packet sender ( build
> > > > based
> > > > > > on hackrf_transfer: https://github.com/mossmann/hackrf  )
> > > > > > > >
> > > > > > > > See project here: https://github.com/JiaoXianjun/   repo BTLE
> > > > > > > >
> > > > > > > > All link layer packet formats are supported. (Chapter 2&3,
> > PartB,
> > > > > > Volume 6, Core_V4.0.pdf :
> > > > > >
> > > >
> > https://www.google.fi/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCAQFjAA&url=https%3A%2F%2Fwww.bluetooth.org%2Fdocman%2Fhandlers%2Fdownloaddoc.ashx%3Fdoc_id%3D229737&ei=ui3gU4GkC-up0AW4q4GwBw&usg=AFQjCNFY1IFeFAAWwimnoaWMsIRZQvPDSw&sig2=wTgMMxNPJ52NHclpsQ4XhQ&bvm=bv.72197243,d.d2k
> > > > > >  )
> > > > > > > >
> > > > > > > > It can be used to transmit arbitrary pre-defined BTLE
> > signal/packet
> > > > > > sequence, such as raw bits to GFSK modulator, iBeacon packet,
> > > > Connection
> > > > > > establishment procedure packet in TI's website:
> > > > > > http://processors.wiki.ti.com/index.php/BLE_sniffer_guide , or any
> > > > other
> > > > > > packets you want. Together with TI's packet sniffer, you will have
> > > > full TX
> > > > > > and RX abilities. See video demo 1 http://youtu.be/Y8ttV5AEb-g
> > > > (outside
> > > > > > China) or video demo 2
> > http://v.youku.com/v_show/id_XNzUxMDIzNzAw.html
> > > > > > (inside China)
> > > > > > > >
> > > > > > > > ----Build:
> > > > > > > >
> > > > > > > >     cd host
> > > > > > > >     mkdir build
> > > > > > > >     cd build
> > > > > > > >     cmake ../
> > > > > > > >     make
> > > > > > > >     sudo make install  (or not install, just use btle_tx in
> > > > > > hackrf-tools/src)
> > > > > > > >
> > > > > > > > ----Usage method 1:
> > > > > > > >
> > > > > > > >     btle_tx packet1 packet2 ... packetX ...  rN
> > > > > > > >
> > > > > > > > ----Usage method 2:
> > > > > > > >
> > > > > > > >     btle_tx packets.txt
> > > > > > > >
> > > > > > > > In method 2, just those command line parameters (packet1 ...
> > rN) in
> > > > > > method 1 are written/grouped in a .txt file as input of btle_tx
> > tool.
> > > > One
> > > > > > parameter one line. A line start with "#" is regarded as comment.
> > See
> > > > > > packets.txt example in hackrf-tools/src.
> > > > > > > >
> > > > > > > > "packetX" is one string which describes one packet. All packets
> > > > > > compose a packets sequence.
> > > > > > > >
> > > > > > > > "rN" means the sequence will be repeated for N times. If it is
> > not
> > > > > > specified, the sequence will only be sent once.
> > > > > > > >
> > > > > > > > ----Format of packet descriptor "packetX"
> > > > > > > >
> > > > > > > >
> > > > channel_number-packet_type-field-value-field-value-...-Space-value
> > > > > > > >
> > > > > > > > Each descriptor string starts with BTLE channel number (0~39),
> > then
> > > > > > followed by packet_type (RAW/iBeacon/ADV_IND/ADV_DIRECT_IND/etc.
> > See
> > > > all
> > > > > > format examples at the end), then followed by field-value pair
> > which is
> > > > > > packet_type specific, at last there is Space-value pair (optional)
> > > > where
> > > > > > the value specifies how many millisecond will be waited after this
> > > > packet
> > > > > > sent.
> > > > > > > >
> > > > > > > > ----iBeacon example: (iBeacon principle:
> > > > > > http://www.warski.org/blog/2014/01/how-ibeacons-work/ )
> > > > > > > >
> > > > > > > >     ./btle_tx
> > > > > >
> > > >
> > 37-iBeacon-AdvA-010203040506-UUID-B9407F30F5F8466EAFF925556B57FE6D-Major-0008-Minor-0009-TxPower-C5-Space-100
> > > > > >     r100
> > > > > > > >
> > > > > > > > Above command sends iBeacon packet and repeats it 100 times
> > with
> > > > 100ms
> > > > > > time space (If you have "Locate" app in your iPhone/iPad, it will
> > > > detect
> > > > > > the packet and show the iBeacon info.). The packet descriptor
> > string:
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > 37-iBeacon-AdvA-010203040506-UUID-B9407F30F5F8466EAFF925556B57FE6D-Major-0008-Minor-0009-TxPower-C5-Space-100
> > > > > > > >
> > > > > > > > 37 -- channel 37 (one of BTLE Advertising channel 37 38 39)
> > > > > > > >
> > > > > > > > iBeacon -- packet format key word which means iBeacon format.
> > > > > > (Actually it is ADV_IND format in Core_V4.0.pdf)
> > > > > > > >
> > > > > > > > AdvA -- Advertising address (MAC address) which is set as
> > > > 010203040506
> > > > > > (See Core_V4.0.pdf)
> > > > > > > >
> > > > > > > > UUID -- here we specify it as Estimote’s fixed UUID:
> > > > > > B9407F30F5F8466EAFF925556B57FE6D
> > > > > > > >
> > > > > > > > Major -- major number of iBeacon format. (Here it is 0008)
> > > > > > > >
> > > > > > > > Minor -- minor number of iBeacon format. (Here it is 0009)
> > > > > > > >
> > > > > > > > Txpower -- transmit power parameter of iBeacon format (Here it
> > is
> > > > C5)
> > > > > > > >
> > > > > > > > Space -- How many millisecond will be waited after this packet
> > > > sent.
> > > > > > (Here it is 100ms)
> > > > > > > >
> > > > > > > > ----Connection establishment example: (See "Connection
> > > > establishment"
> > > > > > part of http://processors.wiki.ti.com/index.php/BLE_sniffer_guide
> > )
> > > > > > > >
> > > > > > > >     ./btle_tx
> > > > > >
> > > >
> > 37-ADV_IND-TxAdd-0-RxAdd-0-AdvA-90D7EBB19299-AdvData-0201050702031802180418-Space-1000
> > > > > >
> > > > > >
> > > >
> >  37-CONNECT_REQ-TxAdd-0-RxAdd-0-InitA-001830EA965F-AdvA-90D7EBB19299-AA-60850A1B-CRCInit-A77B22-WinSize-02-WinOffset-000F-Interval-0050-Latency-0000-Timeout-07D0-ChM-1FFFFFFFFF-Hop-9-SCA-5-Space-1000
> > > > > >
> > > > > >
> > > >
> >  9-LL_DATA-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-DATA-X-CRCInit-A77B22-Space-1000
> > > > > > > >
> > > > > > > > Above simualtes a Connection establishment procedure between
> > > > device 1
> > > > > > and device 2.
> > > > > > > >
> > > > > > > > The 1st packet -- device 1 sends ADV_IND packet in channel 37.
> > > > > > > >
> > > > > > > > The 2nd packet -- After device 2 (in scanning state) receives
> > the
> > > > ADV
> > > > > > packet from device 1, device 2 sends CONNECT_REQ packet to request
> > > > > > connection setup with device 1. In this request packet, there are
> > > > device 2
> > > > > > MAC address (InitA), target MAC address (device 1 MAC address
> > AdvA),
> > > > Access
> > > > > > address (AA) which will be used by device 1 in following packet
> > > > sending in
> > > > > > data channel, CRC initilization value for following device 1
> > sending
> > > > > > packet, Hopping channel information (ChM and Hop) for data channel
> > > > used by
> > > > > > device 1, etc.
> > > > > > > >
> > > > > > > > The 3rd packet -- device 1 send an empty Link layer data PDU in
> > > > > > channel 9 (decided by hopping scheme) according to those connection
> > > > request
> > > > > > information received from device 2. (One "X" after field "DATA"
> > means
> > > > there
> > > > > > is no data for this field )
> > > > > > > >
> > > > > > > > Time space between packets are 1s (1000ms). Tune TI's packet
> > > > sniffer
> > > > > > to channel 37, then above establishment procedure will be captured.
> > > > > > > >
> > > > > > > > ----Packet descriptor examples for all formats:
> > > > > > > >
> > > > > > > > RAW packets: (All bits will be sent to GFSK modulator directly)
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > 13-RAW-AAD6BE898E5F134B5D86F2999CC3D7DF5EDF15DEE39AA2E5D0728EB68B0E449B07C547B80EAA8DD257A0E5EACB0B
> > > > > > > >
> > > > > > > > ADVERTISING CHANNEL packets:
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > 37-IBEACON-AdvA-010203040506-UUID-B9407F30F5F8466EAFF925556B57FE6D-Major-0008-Minor-0009-TxPower-C5
> > > > > > > >
> > > > > >
> > > >
> > 37-ADV_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-AdvData-00112233445566778899AABBCCDDEEFF
> > > > > > > >
> > > > > >
> > 37-ADV_DIRECT_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-InitA-0708090A0B0C
> > > > > > > >
> > > > > >
> > > >
> > 37-ADV_NONCONN_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-AdvData-00112233445566778899AABBCCDDEEFF
> > > > > > > >
> > > > > >
> > > >
> > 37-ADV_SCAN_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-AdvData-00112233445566778899AABBCCDDEEFF
> > > > > > > >
> > > > 37-SCAN_REQ-TxAdd-1-RxAdd-0-ScanA-010203040506-AdvA-0708090A0B0C
> > > > > > > >
> > > > > >
> > > >
> > 37-SCAN_RSP-TxAdd-1-RxAdd-0-AdvA-010203040506-ScanRspData-00112233445566778899AABBCCDDEEFF
> > > > > > > >
> > > > > >
> > > >
> > 37-CONNECT_REQ-TxAdd-1-RxAdd-0-InitA-010203040506-AdvA-0708090A0B0C-AA-01020304-CRCInit-050607-WinSize-08-WinOffset-090A-Interval-0B0C-Latency-0D0E-Timeout-0F00-ChM-0102030405-Hop-3-SCA-4
> > > > > > > >
> > > > > > > > DATA CHANNEL packets:
> > > > > > > >
> > > > > > > >
> > > > 9-LL_DATA-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-DATA-X-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > > >
> > 9-LL_CONNECTION_UPDATE_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-WinSize-02-WinOffset-000F-Interval-0050-Latency-0000-Timeout-07D0-Instant-0000-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > > >
> > 9-LL_CHANNEL_MAP_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-ChM-1FFFFFFFFF-Instant-0001-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > > >
> > 9-LL_TERMINATE_IND-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-ErrorCode-00-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > > >
> > 9-LL_ENC_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-Rand-0102030405060708-EDIV-090A-SKDm-0102030405060708-IVm-090A0B0C-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > > >
> > 9-LL_ENC_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-SKDs-0102030405060708-IVs-01020304-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > 9-LL_START_ENC_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > 9-LL_START_ENC_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > > >
> > 9-LL_UNKNOWN_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-UnknownType-01-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > > >
> > 9-LL_FEATURE_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-FeatureSet-0102030405060708-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > > >
> > 9-LL_FEATURE_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-FeatureSet-0102030405060708-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > 9-LL_PAUSE_ENC_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > 9-LL_PAUSE_ENC_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > > >
> > 9-LL_VERSION_IND-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-VersNr-01-CompId-0203-SubVersNr-0405-CRCInit-A77B22
> > > > > > > >
> > > > > >
> > > >
> > 9-LL_REJECT_IND-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-ErrorCode-00-CRCInit-A77B22
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > HackRF-dev mailing list
> > > > > > > > HackRF-dev at greatscottgadgets.com
> > > > > > > > http://nine.pairlist.net/mailman/listinfo/hackrf-dev
> > > > > >
> > > > > > > _______________________________________________
> > > > > > > HackRF-dev mailing list
> > > > > > > HackRF-dev at greatscottgadgets.com
> > > > > > > http://nine.pairlist.net/mailman/listinfo/hackrf-dev
> > > > > >
> > > > > >
> > > >
> >
> >
> >
> >
> >
> >

> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> http://nine.pairlist.net/mailman/listinfo/hackrf-dev