From admin at lissyara.su Wed Jul 9 20:10:57 2008 From: admin at lissyara.su (Alex Keda) Date: Wed Jul 9 20:11:27 2008 Subject: bluetooth stack ported from NetBSD Message-ID: <48751292.7080902@lissyara.su> Subj. http://forum.lissyara.su/viewtopic.php?t=9100&st=0&sk=t&sd=a&start=50#p79571 may be very useful - simply and think than realized in FreeBS? From maksim.yevmenkin at gmail.com Wed Jul 9 20:57:18 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Jul 9 20:57:24 2008 Subject: bluetooth stack ported from NetBSD In-Reply-To: <48751292.7080902@lissyara.su> References: <48751292.7080902@lissyara.su> Message-ID: > Subj. > http://forum.lissyara.su/viewtopic.php?t=9100&st=0&sk=t&sd=a&start=50#p79571 > may be very useful - simply and think than realized in FreeBS? interesting. i'm actually kinda working in the direction of convergence netbsd and freebsd bluetooth stacks. user space mostly. i'm curious what is "hard" in freebsd bluetooth stack and why netbsd stack is "more simple"? thanks, max From maksim.yevmenkin at gmail.com Wed Jul 9 21:17:52 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Jul 9 21:17:59 2008 Subject: bluetooth stack ported from NetBSD In-Reply-To: References: <48751292.7080902@lissyara.su> Message-ID: 2008/7/9 Maksim Yevmenkin : >> Subj. >> http://forum.lissyara.su/viewtopic.php?t=9100&st=0&sk=t&sd=a&start=50#p79571 >> may be very useful - simply and think than realized in FreeBS? > > interesting. i'm actually kinda working in the direction of > convergence netbsd and freebsd bluetooth stacks. user space mostly. > i'm curious what is "hard" in freebsd bluetooth stack and why netbsd > stack is "more simple"? i took very quick look - good effort :) there are however, few locking issues, and, some utilities are missing. also, original thread seems to be about some bluetooth gps device. bluetooth gps should work just fine with freebsd. i have one myself and it works without any problems. most (all?) blueooth gps devices simply use serial port profile, so rfcomm_sppd will work just fine for this. thanks, max From admin at lissyara.su Wed Jul 9 21:58:28 2008 From: admin at lissyara.su (Alex Keda) Date: Wed Jul 9 21:58:35 2008 Subject: bluetooth stack ported from NetBSD In-Reply-To: References: <48751292.7080902@lissyara.su> Message-ID: <48753475.5040402@lissyara.su> >i took very quick look - good effort :) there are however, few locking >issues, and, some utilities are missing. hmm, what issues ? >also, original thread seems to be about some bluetooth gps device. the thread about ported netbt stack to freebsd not gps ;) why netbt ? becouse native stack freebsd not support SCO audio rfcomm_sppd i's first step >bluetooth gps should work just fine with freebsd. i have one myself >and it works without any problems. most (all?) blueooth gps devices >simply use serial port profile, so rfcomm_sppd will work just fine for >this. From maksim.yevmenkin at gmail.com Wed Jul 9 22:26:42 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Jul 9 22:26:49 2008 Subject: bluetooth stack ported from NetBSD In-Reply-To: <48753475.5040402@lissyara.su> References: <48751292.7080902@lissyara.su> <48753475.5040402@lissyara.su> Message-ID: On Wed, Jul 9, 2008 at 2:58 PM, Alex Keda wrote: >>i took very quick look - good effort :) there are however, few locking >>issues, and, some utilities are missing. > hmm, what issues ? for one - socket's layer is not properly locked. i also suspect (but not yet 100% sure) there is something fishy might be going on when packets cross boundary between usb and netbt. usb is giant locked, and there is very little locking in netbt. i saw the author simply replaced few splxxx/splx calles with mtx_xxx calls in few places, but i'm pretty sure this is not all of it. >>also, original thread seems to be about some bluetooth gps device. > > the thread about ported netbt stack to freebsd > not gps ;) > why netbt ? > becouse native stack freebsd not support SCO audio 1) i'm willing to give out the code that i have to anyone who has the desire to work on this; 2) i'm willing to help with the code and commit all the produced patches; 3) all the credit will go the person how will do the work; > rfcomm_sppd > i's first step that's fine. furthermore, i want to go on the record here and say that if netgraph (due to its complexity, etc.) is a big problem here, and, prevents people from working on bluetooth in freebsd, i'm prepared to seriously consider netbt stack as alternative. the userspace part of both stacks has a lot of shared code. also it would be beneficial for all bsd-family operating systems. thanks, max From plunky at rya-online.net Thu Jul 10 08:40:24 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Thu Jul 10 08:40:31 2008 Subject: bluetooth stack ported from NetBSD In-Reply-To: References: <48751292.7080902@lissyara.su> <48753475.5040402@lissyara.su> Message-ID: <1215679186.775945.722.nullmailer@galant.ukfsn.org> On Wed, 9 Jul 2008, Maksim Yevmenkin wrote: > furthermore, i want to go on the record here and say that if netgraph > (due to its complexity, etc.) is a big problem here, and, prevents > people from working on bluetooth in freebsd, i'm prepared to seriously > consider netbt stack as alternative. netgraph I considered too much work to look at and was no interest to have it in NetBSD or OpenBSD. Then I think after some years nobody had stepped up to make it work in DragonflyBSD so they have imported the netbt stack also. personally, I think that diversity is always good. The vast majority of applications use L2CAP or RFCOMM and the API for these are almost exactly similar across the whole range of open OS's (BlueZ included). I think even that there are some things in NetBSD that are still wrong (I think that using a raw socket for HCI is not correct, we should address devices directly -- but that is not going to change) or incomplete (SCO support is not great though it does work on some platforms) and nobody else picked up on libprop(3) so that has meant some rewriting down the line (there are bthcid/btkey implementations in OpenBSD without libprop) The way that the OS handles devices is always going to be different and that will make more rewriting, so I would think that FreeBSD importing the netbt stack "to gain SCO support" would not in the end necessarily make anything simpler. iain From awnishupadhyay at gmail.com Wed Jul 23 15:02:39 2008 From: awnishupadhyay at gmail.com (awnish upadhyay) Date: Wed Jul 23 15:02:49 2008 Subject: bluetooth link quality and rssi ? Message-ID: Hi , In BlueZ, what does 'hcitool rssi
' return? does it return the actual RSSI value or is the output similar to the result of the HCI_Read_RSSI command as mentioned in the BT spec? The BT spec says that HCI_Read_RSSI will read the value for the difference between the measured Received Signal Strength Indication (RSSI) and the limits of the Golden Receive Power Range for a connection handle to another Bluetooth device. Put in other words, will 'hcitool rssi
' return this difference or does it give the exact RSSI value which is compared with the GRPR? I ran some test between an Nokia, Windows MObile and a Belkin BT USB device. I was measuring the RSSI value as seen by the belkin BT device (connected to a PC) while the mobiles weres moved to different locations (I was not doing any data transfer.. but I had the two devices connected and collected the data in a file). I noticed that the RSSI values were highly variable. Even two sets of observations with identical conditions were giving very different values for RSSI. So, my next question is how accurate is the RSSI value? I know the BT spec says that there can be a 6dB +/- variation. Is the result value in dB? Can I use RSSI to quantify the distance between two BT devices? Meaning lower values of RSSI -> higher distance? I was looking at other parameters (link quality, transmit power) and found that the link quality seemed to be a better indicator of the distance.. with increasing separation between the devices, the command 'hcitool lq
' was giving lower values.. meaning there was a degradation in the link quality. Any comments on this? i wanted to know the unit of link quality.and what is the relation between rssi and link quality ? also can we predict the distance depending upon the link quality and rssi.. In Bluetooth, the transmitted power for a link is adjustable and the LM can change the power of a link depending on the conditions. So again, can the transmit power level (hcitool tpl
) be used as an indicator of the distance? In my tests, I did see a variation in the tpl value for different positions. And one last question.. do any of these values depend on the manufacturer - i.e. for the same distance and identical environmental conditions.. will a 3COM device, Belkin device and say a cisco device give different values? -- Awnish Upadhyay Msc. Mobile and Radio Communication, 07809682838. From plunky at rya-online.net Wed Jul 23 16:34:39 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Wed Jul 23 16:34:46 2008 Subject: bluetooth link quality and rssi ? In-Reply-To: References: Message-ID: <1216830824.448647.547.nullmailer@galant.ukfsn.org> On Wed, 23 Jul 2008, awnish upadhyay wrote: > In BlueZ, what does 'hcitool rssi
' return? does it return the > actual RSSI value or is the output similar to the result of the > HCI_Read_RSSI command as mentioned in the BT spec? > > The BT spec says that HCI_Read_RSSI will read the value for the difference > between the measured Received Signal Strength Indication (RSSI) and the > limits of the Golden Receive Power Range for a connection handle to another > Bluetooth device. > > Put in other words, will 'hcitool rssi
' return this difference or > does it give the exact RSSI value which is compared with the GRPR? (FreeBSD is not BlueZ btw) It returns the value that the controller supplies (from Read_RSSI command) > I noticed that the RSSI values were highly variable. go figure > is how accurate is the RSSI value? I know the BT spec says that there can > be a 6dB +/- variation. Is the result value in dB? it is dB above or below the Golden Receive Power Range (whatever that might be :) > Can I use RSSI to quantify the distance between two BT devices? Meaning > lower values of RSSI -> higher distance? Not with any guarantee of precision. Radio waves bounce off walls and and are absorbed by furniture or human bodies. I think the reasoning for providing this value is that you can use it to compare different links and choose the strongest ones (eg for a mesh network) rather than interpreting it on its own. > And one last question.. do any of these values depend on the manufacturer - > i.e. for the same distance and identical environmental conditions.. will a > 3COM device, Belkin device and say a cisco device give different values? nothing is absolute regards, iain From maksim.yevmenkin at gmail.com Wed Jul 23 16:44:08 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Jul 23 16:44:14 2008 Subject: bluetooth link quality and rssi ? In-Reply-To: References: Message-ID: On 7/23/08, awnish upadhyay wrote: > Hi , > > In BlueZ, what does 'hcitool rssi
' return? does it return the this mailing lists is for discussing bluetooth on freebsd and not linux :) you might be better off to sending your questions to proper linux bluez mailing list. > actual RSSI value or is the output similar to the result of the > HCI_Read_RSSI command as mentioned in the BT spec? i would image it would be the result of the hci read_rssi command. > The BT spec says that HCI_Read_RSSI will read the value for the difference > between the measured Received Signal Strength Indication (RSSI) and the > limits of the Golden Receive Power Range for a connection handle to another > Bluetooth device. > > Put in other words, will 'hcitool rssi
' return this difference or > does it give the exact RSSI value which is compared with the GRPR? read_rssi command returns a measure of the received signal strength indication of a link between the local and a remote bluetooth devices. the returned value provides a relative measure of the rssi and the "golden receive power range." the golden receive power range is the range of desired received signal power resulting in minimal error. a received signal with too little or too much power results in an inability to accurately decode the transmitted signal. > I ran some test between an Nokia, Windows MObile and a Belkin BT USB device. > I was > measuring the RSSI value as seen by the belkin BT device (connected to a PC) > while the mobiles weres moved to different locations (I was not doing any > data > transfer.. but I had the two devices connected and collected the data in a > file). > I noticed that the RSSI values were highly variable. Even two sets of > observations with identical > conditions were giving very different values for RSSI. So, my next question > is how accurate is the RSSI value? I know the BT spec says that there can > be a 6dB +/- variation. Is the result value in dB? theoretically, there exists an inverse proportional relationship between the received signal and the distance from the receiving station that can be represented linearly. unfortunately, various phenomena like multipath fading and shadowing make it impossible to establish a precise relationship. for practical purposes, this technique involves determining the path loss function based on statistical analysis. > Can I use RSSI to quantify the distance between two BT devices? Meaning > lower values of RSSI -> higher distance? please read above. > I was looking at other parameters (link quality, transmit power) and found > that the link quality seemed to be a better indicator of the distance.. > with increasing separation between the devices, the command 'hcitool lq >
' was giving lower values.. meaning there was a degradation in the > link quality. Any comments on this? i wanted to know the unit of link > quality.and what is the relation between rssi and link quality ? > also can we predict the distance depending upon the link quality and rssi.. theoretically. you probably should look at all 3: Get_Link_Quality, Read_RSSI and Read_Transmit_Power_Level value. some of those could be manufacturer specific (imo). > In Bluetooth, the transmitted power for a link is adjustable and the LM can > change the power of a link depending on the conditions. So again, can the > transmit power level (hcitool tpl
) be used as an indicator of the > distance? In my tests, I did see a variation in the tpl value for different > positions. please read above. > And one last question.. do any of these values depend on the manufacturer - > i.e. for the same distance and identical environmental conditions.. will a > 3COM device, Belkin device and say a cisco device give different values? yes, imo. thanks, max