Anyone got any ideas or have we given up on this?
Cheers.
On Tue, May 17, 2011 at 1:45 PM, Eponymous - <[email protected]> wrote:
> lsusb:
>
> Bus 001 Device 041: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> Bluetooth Dongle (HCI mode)
> Bus 001 Device 040: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> Bluetooth Dongle (HCI mode)
>
> These are definitely plain USB devices. There is no /dev/ttyUSBxx like
> you would get with the FTDI USB->Serial converters.
>
> I've checked over dmesg and the messages (of which there are many
> since I have eight of these devices) says they are USB.
>
> I don't want to become sidetracked from the issue though. Is there
> anyway to debug this issue without using l2test or any other
> upperlayers program? The issue I have seen was at the HCI level
> remember so I'm thinking introducing the upperlayers is going to make
> things unnecessarily complicated.
>
> Cheers.
>
>
> On Tue, May 17, 2011 at 12:50 PM, Anderson Lizardo
> <[email protected]> wrote:
>> Hi,
>>
>> On Tue, May 17, 2011 at 3:13 AM, Eponymous - <[email protected]> wrote:
>>> The chips are CSR Bluecores. In order to get upperlayers access rather
>>> ?than HCI over USB you have to configure a key in the firmware.
>>>
>>> As soon as I enable upperlayers access the devices disappear from hciconfig.
>>
>> As I said, there are various development/prototype devices out there
>> that use UART (usually CDC ACM or FTDI over USB) transport instead of
>> "plain" USB. If you post the relevant lines from "dmesg" and "lsusb"
>> somewhere (after you configure the firmware key), we might be able to
>> identify the transport.
>>
>> For UART, you need to use hciattach on a e.g. /dev/ttyUSBX device
>> created when plugging the device.
>>
>> HTH,
>> --
>> Anderson Lizardo
>> Instituto Nokia de Tecnologia - INdT
>> Manaus - Brazil
>>
>
Ok well this has been a complete waste of time. I guess we should just
ignore a potential bug then,...
Is this project dead or something? I can't believe an entire mailing
list can't be bothered to even e-mail back or try and help with this.
On Tue, May 24, 2011 at 9:12 AM, Eponymous - <[email protected]> wrote:
> Anyone got any ideas or have we given up on this?
>
> Cheers.
>
> On Tue, May 17, 2011 at 1:45 PM, Eponymous - <[email protected]> wrote:
>> lsusb:
>>
>> Bus 001 Device 041: ID 0a12:0001 Cambridge Silicon Radio, Ltd
>> Bluetooth Dongle (HCI mode)
>> Bus 001 Device 040: ID 0a12:0001 Cambridge Silicon Radio, Ltd
>> Bluetooth Dongle (HCI mode)
>>
>> These are definitely plain USB devices. There is no /dev/ttyUSBxx like
>> you would get with the FTDI USB->Serial converters.
>>
>> I've checked over dmesg and the messages (of which there are many
>> since I have eight of these devices) says they are USB.
>>
>> I don't want to become sidetracked from the issue though. Is there
>> anyway to debug this issue without using l2test or any other
>> upperlayers program? The issue I have seen was at the HCI level
>> remember so I'm thinking introducing the upperlayers is going to make
>> things unnecessarily complicated.
>>
>> Cheers.
>>
>>
>> On Tue, May 17, 2011 at 12:50 PM, Anderson Lizardo
>> <[email protected]> wrote:
>>> Hi,
>>>
>>> On Tue, May 17, 2011 at 3:13 AM, Eponymous - <[email protected]> wrote:
>>>> The chips are CSR Bluecores. In order to get upperlayers access rather
>>>> ?than HCI over USB you have to configure a key in the firmware.
>>>>
>>>> As soon as I enable upperlayers access the devices disappear from hciconfig.
>>>
>>> As I said, there are various development/prototype devices out there
>>> that use UART (usually CDC ACM or FTDI over USB) transport instead of
>>> "plain" USB. If you post the relevant lines from "dmesg" and "lsusb"
>>> somewhere (after you configure the firmware key), we might be able to
>>> identify the transport.
>>>
>>> For UART, you need to use hciattach on a e.g. /dev/ttyUSBX device
>>> created when plugging the device.
>>>
>>> HTH,
>>> --
>>> Anderson Lizardo
>>> Instituto Nokia de Tecnologia - INdT
>>> Manaus - Brazil
>>>
>>
>