See comments in line. On Mon, Nov 9, 2015 at 5:18 PM, Iluta V <[email protected]> wrote:
> Hi, Xianjun, > > Thank you for your response and suggestions. Here are command lines both > for RX and TX and outputs. BTLE discovery mode works the best. For othr > commands there are interesting questions. :) > > *RX:* > > 1. *btle_rx -c 37 -g 6 -a 89ABCDEF -k 555555 -v -r*, and also *btle_rx > -c 37 -g 6 -a 89ABCDEF -k 0000acce -v -r* > > I tried with different channels, different gains, it gives out seg fault > message: Segmentation fault (core dumped) > > I can reproduce this. Maybe you can try to step-by-step debug. I use hackrf release "hackrf-2015.07.2". You can also try this. AND REMEMBER: CHANGE: lib_device->transfer_count to 4 lib_device->buffer_size to 4096 in hackrf driver: hackrf.c. You should do that change to your HACKRF source code and re-compile, re-install hackrf software. Then build my tools. <https://github.com/mossmann/hackrf> > > 2. I got a readable message with just default descriptions in command > line, and I got RX working on my HackRF now: > > *btle_rx -c chan -g gain -a access_addr -k crc_init -v -r* > > Cmd line input: chan 0, freq 2404MHz, access addr 00000000, crc init > 00acce raw 12 verbose 1 rx 1dB ((null)) > > 406us Pkt1 Ch0 AA:0000acce > Raw:4d0001002093d408e03311503281c0502242028ae4e04858241002c0041c922c0c11b207049405821c08 > 6487874us Pkt2 Ch0 AA:0000acce > Raw:02918600b0880000491345804580300283800008a8584400005044a00e0c814140102b10008040100014 > > *TX:* > > 1. As non root: > > * btle_tx packets.txt* > num_repeat 1 > num_packet 3 > > packet 0 > channel_number 37 > pkt_type ADV_IND > payload_len 17 > num_info_bit 192 > after crc24 > aad6be898e00119992b1ebd7900201050702031802180418a85def > after scramble 216 0 > aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc > num_phy_bit 216 > num_phy_sample 880 > space 1000 > INFO bit:aad6be898e00119992b1ebd7900201050702031802180418 > PHY bit:aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc > PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt > IQ_sample_byte.txt > save_phy_sample: fopen failed! > save_phy_sample: fopen failed! > save_phy_sample_for_matlab: fopen failed! > save_phy_sample_for_matlab: fopen failed! > > packet 1 > channel_number 37 > pkt_type CONNECT_REQ > payload_len 34 > num_info_bit 328 > after crc24 > > aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa948da02 > after scramble 352 0 > > aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b > num_phy_bit 352 > num_phy_sample 1424 > space 1000 > INFO > bit:aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa9 > PHY > bit:aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b > PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt > IQ_sample_byte.txt > save_phy_sample: fopen failed! > save_phy_sample: fopen failed! > save_phy_sample_for_matlab: fopen failed! > save_phy_sample_for_matlab: fopen failed! > > 2. As root: > > *btle_tx packets.txt* > > packet 0 > channel_number 37 > pkt_type ADV_IND > payload_len 17 > num_info_bit 192 > after crc24 > aad6be898e00119992b1ebd7900201050702031802180418a85def > after scramble 216 0 > aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc > num_phy_bit 216 > num_phy_sample 880 > space 1000 > INFO bit:aad6be898e00119992b1ebd7900201050702031802180418 > PHY bit:aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc > PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt > IQ_sample_byte.txt > > packet 1 > channel_number 37 > pkt_type CONNECT_REQ > payload_len 34 > num_info_bit 328 > after crc24 > > aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa948da02 > after scramble 352 0 > > aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b > num_phy_bit 352 > num_phy_sample 1424 > space 1000 > INFO > bit:aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa9 > PHY > bit:aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b > PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt > IQ_sample_byte.txt > > See the difference of outputs when as non root and as root. > > This should be due to your linux file system access rights setting. You may check by yourself. > 3. *btle_tx packets_discovery.txt* > num_repeat 40 > num_packet 1 > > packet 0 > channel_number 37 > pkt_type DISCOVERY > AA 8 > 0101-0101 > 0101-0101 > D6BE898E 32 > 0110-1011 0111-1101 1001-0001 0111-0001 > 0110-1011 0111-1101 1001-0001 0111-0001 > ADVA buffer begin from 7 > 010203040506 48 > 0110-0000 1010-0000 0010-0000 1100-0000 0100-0000 1000-0000 > 0110-0000 1010-0000 0010-0000 1100-0000 0100-0000 1000-0000 > display buffer begin from 15 > CA1308 11950 22.626 113.823 8 232 > 1100-0010 1000-0010 1000-1100 1100-1100 0000-1100 0001-1100 0000-0100 > 1000-1100 1000-1100 1001-1100 1010-1100 0000-1100 0000-0100 0100-1100 > 0100-1100 0111-0100 0110-1100 0100-1100 0110-1100 0000-0100 1000-1100 > 1000-1100 1100-1100 0111-0100 0001-1100 0100-1100 1100-1100 0000-0100 > 0001-1100 > 1100-0010 1000-0010 1000-1100 1100-1100 0000-1100 0001-1100 0000-0100 > 1000-1100 1000-1100 1001-1100 1010-1100 0000-1100 0000-0100 0100-1100 > 0100-1100 0111-0100 0110-1100 0100-1100 0110-1100 0000-0100 1000-1100 > 1000-1100 1100-1100 0111-0100 0001-1100 0100-1100 1100-1100 0000-0100 > 0001-1100 > length and AD_TYPE 16 > 0111-1000 1001-0000 > 0111-1000 1001-0000 > payload_len 37 > num_info_bit 352 > num_info_byte 44 > before crc24 > > aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038 > > aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038 > after crc24 > > aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038314121 > > aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038314121 > after scramble 376 47 > > aad6be898ecff751a439a464b16b385209a744c8db66d89ae9ab6313ea88b63e16fd1bcd4090da6d5afc89215d1c6d > > aad6be898ecff751a439a464b16b385209a744c8db66d89ae9ab6313ea88b63e16fd1bcd4090da6d5afc89215d1c6d > num_phy_bit 376 > num_phy_sample 1520 > space 200 > INFO > bit:aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038 > PHY > bit:aad6be898ecff751a439a464b16b385209a744c8db66d89ae9ab6313ea88b63e16fd1bcd4090da6d5afc89215d1c6d > PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt > IQ_sample_byte.txt > > r0 p0 at 0us > r1 p0 at 299024us > r2 p0 at 298557us > r3 p0 at 300177us > r4 p0 at 298612us > r5 p0 at 298388us > r6 p0 at 298671us > etc.... > > 4. > *btle_tx packet1 packet2 ... packetX ... r-1*num_repeat -1 > num_packet 5 > > packet 0 > Getting channel number failed! It should be 0~39. > failed! > You should replace packetX with valid description. Maybe you should read readme carefully. > > What you think? > > Sincerely, > > Iluta > > On Mon, Nov 9, 2015 at 2:33 AM, Jiao Xianjun <[email protected]> wrote: > >> Hi, >> >> Very glad to see my first "customer ". Two suggestions: >> 1. Can you paste me the exact btle_tx parameters/command-line? Let me >> check if this is a bug. >> >> 2. For btle_rx and btle_rx, not recommend you use like 00000000/11111111 >> as access address. Because in my program, this sequence acts as a unique >> word/preamble to do packet detection. It needs to be some "random". >> >> On Mon, Nov 9, 2015 at 00:39 Iluta V <[email protected]> wrote: >> >>> Dear Xianjun, >>> >>> Thank you very much for the great work you did! >>> >>> I already tried out your packet sniffer. Just installed it. Could you >>> please have a look at my output. Did I get the packet 0 and packet 1 the >>> right way, and did packet 2 failed or because of something else. >>> >>> Maybe you could tell why it is so, and what else I could do to improve. >>> Here is the output for BTLE packets: >>> >>> *packet 0* >>> channel_number 37 >>> pkt_type ADV_IND >>> payload_len 17 >>> num_info_bit 192 >>> after crc24 >>> aad6be898e00119992b1ebd7900201050702031802180418a85def >>> after scramble 216 0 >>> aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc >>> num_phy_bit 216 >>> num_phy_sample 880 >>> space 1000 >>> INFO bit:aad6be898e00119992b1ebd7900201050702031802180418 >>> PHY bit:aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc >>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt >>> IQ_sample_byte.txt >>> >>> *packet 1* >>> channel_number 37 >>> pkt_type CONNECT_REQ >>> payload_len 34 >>> num_info_bit 328 >>> after crc24 >>> >>> aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa948da02 >>> after scramble 352 0 >>> >>> aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b >>> num_phy_bit 352 >>> num_phy_sample 1424 >>> space 1000 >>> INFO >>> bit:aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa9 >>> PHY >>> bit:aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b >>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt >>> IQ_sample_byte.txt >>> >>> *packet 2* >>> channel_number 9 >>> pkt_type LL_DATA >>> get_next_field_bit: Half octet is encountered! num_hex 1 >>> X >>> Invalid packet content for specific packet type! >>> failed! >>> >>> Please let me know what you think! Thank you again, >>> >>> Sincerely, >>> >>> Iluta >>> >>> >>> On Sat, Nov 7, 2015 at 6:16 PM, Jiao Xianjun <[email protected]> wrote: >>> >>>> BTLE packet sniffer/scanner/sender. Some updates: >>>> http://sdr-x.github.io/BTLE-SNIFFER/ >>>> >>>> Now all BTLE channels (0~39, bothe ADV and DATA channels) are >>>> supported. You can use btle_tx and btle_rx to send or sniff on any BTLE >>>> channel. >>>> >>>> Raw mode are now supported on both btle_tx and btle_rx. Under this mode >>>> of btle_rx, after access address is detected, following raw 42 bytes >>>> (without descrambling, parsing) are printed out. By this way, you can do >>>> other experiments or communication between HACKRF boards easily. >>>> Have fun. >>>> >>>> >>>> On Wed, Nov 4, 2015 at 1:27 AM, Jiao Xianjun <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Based on my previously released BTLE packet sender, now I have done a >>>>> initial version of BTLE packet sniffer/scanner (Just like TI's packet >>>>> sniffer). See here: http://sdr-x.github.io/BTLE-SNIFFER/ >>>>> >>>>> Regarding the latency/real-time processing, I did some experiments and >>>>> tries, and believe that even implementation via USB (instead of on board >>>>> MCU), we still have chance to follow those "slow" frequency hopping link. >>>>> I >>>>> did see many BTLE link was setup as hopping interval >15ms/20ms/30ms by >>>>> packet sniffer. >>>>> >>>>> Main efforts are: >>>>> 1. Algorithm optimization for real-time processing, such as fixed >>>>> point, CRC table, scrambling table, etc. >>>>> 2. change lib_device->transfer_count to 4 and lib_device->buffer_size >>>>> to 4096 in hackrf driver: hackrf.c. Original buffer size and buffer count >>>>> is very big so that latency is pretty big. By this modified driver, >>>>> according to my experiment, seems that tx and rx can be done in less than >>>>> 10ms: processing latency is about 3~4ms, and worst case buffer delay is >>>>> around 4ms. >>>>> >>>>> Snapshots of HACKRF BTLE packet sniffer VS TI's packet sniffer under >>>>> fastest flow of continuous/non-gap BTLE packets sequence to demonstrate >>>>> full real-time processing ability. They capture the same amount of packets >>>>> and contents: >>>>> >>>>> http://sdr-x.github.io/media/mine-btle-sniffer2.png >>>>> http://sdr-x.github.io/media/TI3.png >>>>> >>>>> youtube: https://youtu.be/9LDPhOF2yyw >>>>> >>>>> Besides, >>>>> A new packet type "Discovery" is added, which can display any names >>>>> and services via btle_tx to your App like LightBlue. ( I use this packet >>>>> type in the "ADS-B BTLE Air Relay" http://sdr-x.github.io/abar/ to >>>>> display flight information) >>>>> >>>>> >>>>> On Fri, Aug 22, 2014 at 9:07 PM, Michael Ossmann <[email protected]> >>>>> wrote: >>>>> >>>>>> 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 <[email protected]> >>>>>> 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 < >>>>>> [email protected]> >>>>>> > > 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 < >>>>>> [email protected]> >>>>>> > > > > 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 < >>>>>> [email protected]> >>>>>> > > > > 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 >>>>>> > > > > > > > > [email protected] >>>>>> > > > > > > > > http://nine.pairlist.net/mailman/listinfo/hackrf-dev >>>>>> > > > > > > >>>>>> > > > > > > > _______________________________________________ >>>>>> > > > > > > > HackRF-dev mailing list >>>>>> > > > > > > > [email protected] >>>>>> > > > > > > > http://nine.pairlist.net/mailman/listinfo/hackrf-dev >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> > > > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> >>>>>> > _______________________________________________ >>>>>> > HackRF-dev mailing list >>>>>> > [email protected] >>>>>> > http://nine.pairlist.net/mailman/listinfo/hackrf-dev >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> HackRF-dev mailing list >>>> [email protected] >>>> >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev >>>> >>>> >>> >
_______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
