Re: [Ubertooth-general] Some Initial test results

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Quite a range. There are a couple things that you might be seeing.

- Adaptive frequency hopping can cause a piconet to use some
frequencies and not others (avoid wifi), and it can change.
- -z20 might be a little high (I know it's what I gave as an example)
... try 6 or 8.
- Bluetooth packets on certain channels might really be getting
squashed by wifi or something else.
- What triggers the capture might not be bluetooth, so if squelch is
strong, you might actually get more packets where there is more noise.

Your noise levels are way below what I see. Do you still have the HGM off?

Here's my very unscientificly collected bunch of stats
(count,channel,avg(noise)). There are some hot channels that see a lot
more bluetooth packets, but it's not related to the packets. Either
something on the board or something in the environment. Haven't tried
to figure it out. There's some interesting spacing in the hot channels
(a bunch are 8MHz apart). The CC2400 has a 16MHz crystal. My dog is 8
years old. I don't know.

486|0|-89.0
398|1|-88.0
741|2|-86.0
484|3|-86.0
512|4|-86.0
540|5|-86.0
1222|6|-81.0
400|7|-85.0
475|8|-86.0
513|9|-85.0
612|10|-85.0
505|11|-86.0
495|12|-86.0
521|13|-86.0
1117|14|-76.0
335|15|-85.0
358|16|-86.0
423|17|-87.0
516|18|-87.0
471|19|-87.0
459|20|-88.0
487|21|-88.0
1323|22|-84.0
336|23|-88.0
397|24|-88.0
415|25|-88.0
594|26|-89.0
1032|27|-89.0
1606|28|-89.0
598|29|-88.0
536|30|-71.0
500|31|-87.0
673|32|-87.0
587|33|-88.0
638|34|-84.0
544|35|-88.0
558|36|-87.0
601|37|-88.0
657|38|-80.0
912|39|-87.0
598|40|-88.0
536|41|-88.0
576|42|-84.0
607|43|-88.0
580|44|-89.0
321|45|-89.0
306|46|-78.0
151|47|-90.0
243|48|-89.0
146|49|-89.0
495|50|-87.0
370|51|-90.0
207|52|-89.0
207|53|-90.0
774|54|-87.0
268|55|-90.0
243|56|-90.0
290|57|-90.0
478|58|-87.0
344|59|-90.0
284|60|-90.0
331|61|-90.0
1704|62|-76.0
238|63|-90.0
182|64|-90.0
206|65|-90.0
235|66|-89.0
218|67|-90.0
216|68|-90.0
275|69|-91.0
1686|70|-82.0
157|71|-91.0
129|72|-90.0
162|73|-90.0
185|74|-89.0
208|75|-91.0
254|76|-91.0
266|77|-91.0
1143|78|-78.0

On Wed, Apr 11, 2012 at 7:49 PM, Andrew Campbell <me...@an...> wrote:
> Running 507 with sweep mode and squelch set to 20.
>
> Ran the test for about 3 hours playing music over bluetooth and
> captured 11655 records.
>
> I copied the MYSQL output to pastebin for those interested.
>
> SELECT rx_channel,  avg(signal_level) as avg_rssi,  avg(noise_level)
> as avg_noise_level,  avg(snr) as avg_snr,  COUNT(*) AS `count`  FROM
> rawdump  GROUP BY rx_channel ORDER BY count DESC;
>
> http://pastebin.com/xjTWwhXU
>
>
>
> On Fri, Apr 6, 2012 at 12:17 PM, Will Code <wil...@gm...> wrote:
>> Try the latest firmware to see if it levels out the channels while
>> still using HGM. For sweep mode, a positive threshold (e.g.,
>> ubertooth-util -z20) will be interpreted as a max-to-iir threshold.
>> CC2400 CS and rssi thresholding are then set per-hop during sweep
>> mode. Note that outside sweep mode, a positive value is really a
>> positive (e.g. +20dBm) threshold, so remember to set it to something
>> sane (e.g., -z-70) or you won't get any packets (except the
>> keepalives). Negative values for threshold still work as before.
>>
>> This is a little hackish. If it works well, I'll try to fix it up some time.
>>
>> On Thu, Apr 5, 2012 at 9:26 AM, Michael Ossmann <mi...@os...> wrote:
>>> On Thu, Apr 05, 2012 at 12:59:16PM +1000, Andrew Campbell wrote:
>>>>
>>>> Got a much better result commenting out "HGM" under cc2400_rx.
>>>
>>> Good.  The drawback is that you lose some ability to detect weak/distant
>>> transmissions.
>>>
>>>> Channels 40,75,29,27,42,36,46,37,41,38 captured between 101-to-125
>>>> records with RSSI -54/-64/-79 (max/avg/min)
>>>>
>>>> Channels 44,73,77,78,31,34,39,26,30,74 captured between 79-to-97
>>>> records with RSSI -57/-69/-81(max/avg/min)
>>>>
>>>> Results based on capture of 4022 packets from single host transmitting
>>>> music over bluetooth.
>>>
>>> If you get a chance to do a longer test, I would love to know the
>>> results.  Over short periods of time (seconds, minutes), there can be
>>> quite a bit of repetition in the hopping sequence, so the two sets of
>>> channels you identified may be channels that a repetitive hopping
>>> sequence assigned more often to master vs. slave.  A longer test (hours)
>>> would likely distribute channels more evenly between the transmitting
>>> devices.
>>>
>>> ------------------------------------------------------------------------------
>>> Better than sec? Nothing is better than sec when it comes to
>>> monitoring Big Data applications. Try Boundary one-second
>>> resolution app monitoring today. Free.
>>> http://p.sf.net/sfu/Boundary-dev2dev
>>> _______________________________________________
>>> Ubertooth-general mailing list
>>> Ube...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Ubertooth-general mailing list
>> Ube...@li...
>> https://lists.sourceforge.net/lists/listinfo/ubertooth-general
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Ubertooth-general mailing list
> Ube...@li...
> https://lists.sourceforge.net/lists/listinfo/ubertooth-general