Hello, friend. Why you so sure about "i2s slave" mode you need from QCC3008? As i understand, if you want to transmit audio FROM QCC3008 to ADAU, you need i2s as master from QCC and i2s as slave in ADAU. i'ts not critical for ADAU , becouse it can use i2s in both directions in slave and master mode, but very critical for QCC, becouse normally it transmit audio to i2s output only in master mode.
I recommend you to check ADAU docs how to use i2s input in slave mode.
btw, i trying to use i2s in opposite direction: i want to send audio from web-player CPU to QCC3008 module via i2s, and get analog audio after processing in QCC LINE OUT, so using it as DAC for my WEB+BT-loudspeaker.. But, i cant find a way to swith i2s of QCC into slave mode. Only LINE input is possible now, but i dont want to make triple conversion for my web-stream (CPU - ext.DAC - analog - ADC\DAC in QCC)...
So, if you or anyone could help my with advise, i'll be very-very glad)
How can I enable 2.1 soundbar on CSR8675 ??? Already I connect PCM5102A with I2S port..... Please give me Dump file......
can please someone help me,
At this point I just don't know what to do..
I got the Tinyo module (5.0 multipoint with the csr6875)
I got it working, can program the dsp and can get in to ADK
BUT
I got a volume problem.. When the volume is set to "DSP" it changes the volume everytime I boot, and I cant change it.. When I change the volume on my phone, often the dsp doesn't change volume.. so when I boot in to -29DB then that's all I got..
I cant get volume buttons to work and when I change the volume settings to "HArdware" the dsp is set to 0.00db (wich is fine I can change the volume on my phone) But then the system volume (SVol) changes everytime I boot .. it changes between 13 14 and 15..
can someone help me?
What I want is the same volume everytime I boot..
At this point I just don't know what to do..
I got the Tinyo module (5.0 multipoint with the csr6875)
I got it working, can program the dsp and can get in to ADK
BUT
I got a volume problem.. When the volume is set to "DSP" it changes the volume everytime I boot, and I cant change it.. When I change the volume on my phone, often the dsp doesn't change volume.. so when I boot in to -29DB then that's all I got..
I cant get volume buttons to work and when I change the volume settings to "HArdware" the dsp is set to 0.00db (wich is fine I can change the volume on my phone) But then the system volume (SVol) changes everytime I boot .. it changes between 13 14 and 15..
can someone help me?
What I want is the same volume everytime I boot..
Found it, apperently I had the setting "turn off absolute volume" turned on on my phone... so this is solved,
Before I get started on this, and end up smashing my head against a brick wall, does anyone know how you use the I2C module built into the QCC3008 ADK?
It all seems fairly straight forward until I realised I've absolutely no idea how to get the module to send an I2C stop command.
So you can apparently enter a long string of bytes to send through the I2C interface, to talk to an external chip, but without the ability to send a stop command this looks fairly useless.
Anyone any ideas?
It all seems fairly straight forward until I realised I've absolutely no idea how to get the module to send an I2C stop command.
So you can apparently enter a long string of bytes to send through the I2C interface, to talk to an external chip, but without the ability to send a stop command this looks fairly useless.
Anyone any ideas?
Okay so previously I had a true wireless stereo configuration with the QC3008 using its analogue outputs going into a small class D amp. Think Bluetooth speakers powered off a single li-ion cell.
This worked, albeit with caveats. The main caveat was that the hybrid volume control didn't work (I'm not sure why). The only option was to use the DSP volume control. Not a particularly good idea when you're limited to the 16 bit processing pipeline inside the device. Still it worked.
I figured that if you moved to an I2S input class D amplifier, and used I2C control, you'd sort this out but it seems not. For some reason the QCC3008 is defaulting to using the DSP to adjust the volume in this situation. What's peculiar is that it's also sending an I2C command every volume press too. It's like it doesn't know what it's doing.
Has anyone else encountered this problem and has any idea how to fix it? Or if anyone else is more au-fait with the actual source code know what's going on?
Just to clarify the QCC3008 does exactly what you'd expect when it's working as a stand-alone device in stereo. The hybrid volume control works. Or if you are using an I2C controlled amplifier in stand-alone stereo that works too. The DSP volume control stays out of the picture. It's only when using TWS that things go awry.
This worked, albeit with caveats. The main caveat was that the hybrid volume control didn't work (I'm not sure why). The only option was to use the DSP volume control. Not a particularly good idea when you're limited to the 16 bit processing pipeline inside the device. Still it worked.
I figured that if you moved to an I2S input class D amplifier, and used I2C control, you'd sort this out but it seems not. For some reason the QCC3008 is defaulting to using the DSP to adjust the volume in this situation. What's peculiar is that it's also sending an I2C command every volume press too. It's like it doesn't know what it's doing.
Has anyone else encountered this problem and has any idea how to fix it? Or if anyone else is more au-fait with the actual source code know what's going on?
Just to clarify the QCC3008 does exactly what you'd expect when it's working as a stand-alone device in stereo. The hybrid volume control works. Or if you are using an I2C controlled amplifier in stand-alone stereo that works too. The DSP volume control stays out of the picture. It's only when using TWS that things go awry.
Last edited:
I know I'm answering my own questions here but here goes.
From reading through the source files and a bit of browsing on the internet.
The DSP on the Bluetooth devices is more than just capable of audio processing. You can, in fact, write code for it to do any number of different things. I figured it was hard coded to do the things it can currently do, like a fixed process flow, as it were, but that's not the case. For example you can code for it to handle I2C communications in software if you wish.
Anyone who has tried using these chips, in standard vs TWS mode, will immediately notice that the two operational modes work in quite different ways. Now I understand why. TWS is handled, and controlled, via the DSP chip. Whereas normal mode uses the main processor. From what I can gather the DSP is called the DSP process and then the main process is called the VM process, which I'm guessing stands for virtual machine.
When you make a volume adjustment on your device, in TWS mode, this is first handled by the DSP. It then sends a call back to the VM to let it know what's happened. This is in contrast to without TWS where the VM handles the volume change first and then communicates to the DSP if necessary.
As standard the VM is what communicates with all the hardware peripherals on board the Bluetooth module. It is responsible for adjusting the analogue volume control on the inbuilt DAC and is what's responsible for communicating with the I2C bus to send volume control commands to a separate I2S device. When operating without TWS you send a communication to alter the volume and the VM handles it, sending a message through the I2C line or altering the attenuator within the internal DAC to handle the volume change. I don't think the DSP is even involved with this unless you're using the Hybrid or DSP based volume control setting and digital attenuation is required. Then the VM sends a message to the DSP to adjust the digital attenuation.
Now because TWS requires perfect synchronisation between the two audio devices I'm guessing this is why the DSP has been tasked with handling the TWS protocol. The DSP is where the data streams are inherently handled and it's also probably what's got the necessary speed and lack of latency to keep things synchronised. Not to mention that when streaming audio the DSP is fully powered up but the VM probably goes into a lower power state, to save power, until it's called upon to do something. If the VM was handling synchronisation it may have to be fully powered up at all times, along with the DSP, increasing power consumption.
So the DSP handles TWS and its synchronisation. Along with this synchronisation it's also, apparently, important that the volume changes across the synchronised devices occur at exactly the same time. To this end the volume is altered, digitally, in the DSP as only a DSP process can, hopefully, ensure perfect synchronisation to volume changes. These volume changes are sent to the VM too, so the VM knows the volume the system is running at, but it doesn't control any hardware with this information. Presumably if the VMs on two devices were doing wildly different things, one could end up changing the volume 0.1 second later than another and this would be deemed a big sacrifice to the quality of life of the user.
To this end Qualcomm have decided that perfectly synchronised volume changes are a complete priority over giving the flexibility to allow for hardware volume changes when using TWS. As the VM is notified of volume changes anyway I don't understand why they couldn't have still given you the option to use hardware volume controls and lived with the out of sync volume changes.
This is more of a problem on the devices that only operate with a 16 bit internal architecture as any digital attenuation, in the DSP, directly impacts the quality of the sound by reducing the effective number of bits the system is working at. The 24 bit parts, on the other hand, can apply 48dB of digital attenuation before bits are thrown away.
As far as I can see this is entirely a software issue and that someone, who knew what they were doing with the source code, could probably change TWS to use hardware volume changes rather easily. It would probably be something as simple as commenting out the initial DSP volume control change and then running the required function, within the VM, upon receiving the volume change update from the DSP, that it's going to receive anyway.
As this is all software related there's no telling exactly how things are handled in other devices either. It's all very well looking at the specifications of the Bluetooth modules, and deciding if you need certain features, but if one devices software ADK package has been designed in a better way that could more be the deciding factor.
I've just got a couple of QCC3040 modules. These seem specifically designed for TWS applications. They are mono by default, have the BT 5.2 standard and true wireless mirroring instead. There's no telling how the ADK will work in controlling this mind you. But it does bring up the question of if the Bluetooth modules that contain more internal/powerful processors work in different intrinsic ways.
Either way this is as good as a recommendation as any to avoid the 16 bit devices if you want to use TWS as you only get a digital volume control.
From reading through the source files and a bit of browsing on the internet.
The DSP on the Bluetooth devices is more than just capable of audio processing. You can, in fact, write code for it to do any number of different things. I figured it was hard coded to do the things it can currently do, like a fixed process flow, as it were, but that's not the case. For example you can code for it to handle I2C communications in software if you wish.
Anyone who has tried using these chips, in standard vs TWS mode, will immediately notice that the two operational modes work in quite different ways. Now I understand why. TWS is handled, and controlled, via the DSP chip. Whereas normal mode uses the main processor. From what I can gather the DSP is called the DSP process and then the main process is called the VM process, which I'm guessing stands for virtual machine.
When you make a volume adjustment on your device, in TWS mode, this is first handled by the DSP. It then sends a call back to the VM to let it know what's happened. This is in contrast to without TWS where the VM handles the volume change first and then communicates to the DSP if necessary.
As standard the VM is what communicates with all the hardware peripherals on board the Bluetooth module. It is responsible for adjusting the analogue volume control on the inbuilt DAC and is what's responsible for communicating with the I2C bus to send volume control commands to a separate I2S device. When operating without TWS you send a communication to alter the volume and the VM handles it, sending a message through the I2C line or altering the attenuator within the internal DAC to handle the volume change. I don't think the DSP is even involved with this unless you're using the Hybrid or DSP based volume control setting and digital attenuation is required. Then the VM sends a message to the DSP to adjust the digital attenuation.
Now because TWS requires perfect synchronisation between the two audio devices I'm guessing this is why the DSP has been tasked with handling the TWS protocol. The DSP is where the data streams are inherently handled and it's also probably what's got the necessary speed and lack of latency to keep things synchronised. Not to mention that when streaming audio the DSP is fully powered up but the VM probably goes into a lower power state, to save power, until it's called upon to do something. If the VM was handling synchronisation it may have to be fully powered up at all times, along with the DSP, increasing power consumption.
So the DSP handles TWS and its synchronisation. Along with this synchronisation it's also, apparently, important that the volume changes across the synchronised devices occur at exactly the same time. To this end the volume is altered, digitally, in the DSP as only a DSP process can, hopefully, ensure perfect synchronisation to volume changes. These volume changes are sent to the VM too, so the VM knows the volume the system is running at, but it doesn't control any hardware with this information. Presumably if the VMs on two devices were doing wildly different things, one could end up changing the volume 0.1 second later than another and this would be deemed a big sacrifice to the quality of life of the user.
To this end Qualcomm have decided that perfectly synchronised volume changes are a complete priority over giving the flexibility to allow for hardware volume changes when using TWS. As the VM is notified of volume changes anyway I don't understand why they couldn't have still given you the option to use hardware volume controls and lived with the out of sync volume changes.
This is more of a problem on the devices that only operate with a 16 bit internal architecture as any digital attenuation, in the DSP, directly impacts the quality of the sound by reducing the effective number of bits the system is working at. The 24 bit parts, on the other hand, can apply 48dB of digital attenuation before bits are thrown away.
As far as I can see this is entirely a software issue and that someone, who knew what they were doing with the source code, could probably change TWS to use hardware volume changes rather easily. It would probably be something as simple as commenting out the initial DSP volume control change and then running the required function, within the VM, upon receiving the volume change update from the DSP, that it's going to receive anyway.
As this is all software related there's no telling exactly how things are handled in other devices either. It's all very well looking at the specifications of the Bluetooth modules, and deciding if you need certain features, but if one devices software ADK package has been designed in a better way that could more be the deciding factor.
I've just got a couple of QCC3040 modules. These seem specifically designed for TWS applications. They are mono by default, have the BT 5.2 standard and true wireless mirroring instead. There's no telling how the ADK will work in controlling this mind you. But it does bring up the question of if the Bluetooth modules that contain more internal/powerful processors work in different intrinsic ways.
Either way this is as good as a recommendation as any to avoid the 16 bit devices if you want to use TWS as you only get a digital volume control.
Hello im trying conect programer to CSR chip in BTI031 aliexpres module (transmiter TX/RX)
Im hav pins connect:
GND
CLK
MOSI
MISO
CSB
and no conect:
PIN
SYNC
POUT
PCLK
MFB
5V
I miss pins 3.3V power supply SPI_ enable (and the like) I have to look for a layout on the PCB, or should I connect any of the following not connected
Im hav pins connect:
GND
CLK
MOSI
MISO
CSB
and no conect:
PIN
SYNC
POUT
PCLK
MFB
5V
I miss pins 3.3V power supply SPI_ enable (and the like) I have to look for a layout on the PCB, or should I connect any of the following not connected
Red and blue of tsa6175 not alternative blink
Hello, i read all post but i have a problem before programming.
When i connect the tc025 cable the led blink blue and not blue-red.
The software csr64xxx universal front end and blue flash read the bluetooth item but i cannot programming it.
I can read the firmware version with blue flash, but i cannot flash the chipset because, after i choose the file, the flash button is not clickable.
Why? Many thanks and best regards
Hello, i read all post but i have a problem before programming.
When i connect the tc025 cable the led blink blue and not blue-red.
The software csr64xxx universal front end and blue flash read the bluetooth item but i cannot programming it.
I can read the firmware version with blue flash, but i cannot flash the chipset because, after i choose the file, the flash button is not clickable.
Why? Many thanks and best regards
Update....
I have flashed with blue flash the tsa6175 tinysine with firmware available on eric cloud( many thanks).
The leds blink red blue now!
I can use ps tools and blue flash....but universal front end not work.
@eric what is the correct adk version to use with tsa6175 flashed with your firmware?
( If i flash the tsa6175 with the firmware on tinysine site, the led blink onlu blue)...
Best regards and many thanks
I have flashed with blue flash the tsa6175 tinysine with firmware available on eric cloud( many thanks).
The leds blink red blue now!
I can use ps tools and blue flash....but universal front end not work.
@eric what is the correct adk version to use with tsa6175 flashed with your firmware?
( If i flash the tsa6175 with the firmware on tinysine site, the led blink onlu blue)...
Best regards and many thanks
I'm not entirely sure how to register with the 52bluetooth forums is anyone able to grab from somewhere, what I can only assume is available (from thread titles), what would be the software for working with the QCC3040?
I've tried the development stuff for the QCC5125 and 3031 but these do not work. I've unlocked the QCC3040, as far as the USB guides show and it appears in the device manager as expected, but it isn't detected in any of the software and I can only assume that my 3040s don't yet have any firmware on either.
Many thanks.
I've tried the development stuff for the QCC5125 and 3031 but these do not work. I've unlocked the QCC3040, as far as the USB guides show and it appears in the device manager as expected, but it isn't detected in any of the software and I can only assume that my 3040s don't yet have any firmware on either.
Many thanks.
The page at Software | QCC3040 | Entry-Level TrueWireless Bluetooth Audio BGA SoC | Qualcomm sort of hints that this can be programmed using Qualcomm® Audio Development Kit (ADK) Toolkit (although the lowest version mentioned there is 1.2.5.30)
There is an ADK_Toolkit_1.0.1.19_x64.exe download available at Dropbox - BT STUFF - Simplify your life (this link is from one of the replies to this thread, probably somewhere in page 6)
Perhaps it's worth giving this a shot if you haven't tried it already
There is an ADK_Toolkit_1.0.1.19_x64.exe download available at Dropbox - BT STUFF - Simplify your life (this link is from one of the replies to this thread, probably somewhere in page 6)
Perhaps it's worth giving this a shot if you haven't tried it already
Have you seen this by the way (needs google translate)?
https://blog.csdn.net/wzz4420381/article/details/106773005
2. Software environment
PC: win10
MDE: (C:\weiyun\ Sidu Technology\QCC30xx_QCC51xx development board information\3. Development environment\qualcomm_mde.win.2.4_installer_2.4.0.158.zip)
ADK Tool: (C:\weiyun\ Sidu Technology\QCC30xx_QCC51xx development board information\4. Official ADK\ADK20.1\adk_toolkit.win.1.0_installer_1.0.1.19.zip)
Project: (C:\weiyun\ Sidu Technology\QCC30xx_QCC51xx development board information\4. Official ADK\ADK20.1\qcc514x-qcc304x-src-1-0_qtil_standard_oem_earbud.rar)
3. Hardware environment
Debugger Adapter: TRBI200 or USB
Platform: I love Bluetooth network QCC30XX/51XX development board * 2 + QCC3040 module * 2
Chip: QCC3040
---- ORIGINAL
2. 软件环境
PC: win10
MDE: (C:\weiyun\ 思 度 科 技 \QCC30xx_QCC51xx 开 发 板 资 料 \3. 开 发 环 境\qualcomm_mde.win.2.4_installer_2.4.0.158.zip)
ADK Tool: (C:\weiyun\ 思 度 科 技 \QCC30xx_QCC51xx 开 发 板 资 料 \4. 官 方ADK\ADK20.1\adk_toolkit.win.1.0_installer_1.0.1.19.zip)
Project: (C:\weiyun\ 思 度 科 技 \QCC30xx_QCC51xx 开 发 板 资 料 \4. 官 方ADK\ADK20.1\qcc514x-qcc304x-src-1-0_qtil_standard_oem_earbud.rar)
3. 硬件环境
Debugger Adapter: TRBI200 或 USB
Platform: 我爱蓝牙网 QCC30XX/51XX 开发板 * 2 + QCC3040模块 * 2
Chip: QCC3040
————————————————
版权声明：本文为CSDN博主「NiceBT」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wzz4420381/article/details/106773005
https://blog.csdn.net/wzz4420381/article/details/106773005
2. Software environment
PC: win10
MDE: (C:\weiyun\ Sidu Technology\QCC30xx_QCC51xx development board information\3. Development environment\qualcomm_mde.win.2.4_installer_2.4.0.158.zip)
ADK Tool: (C:\weiyun\ Sidu Technology\QCC30xx_QCC51xx development board information\4. Official ADK\ADK20.1\adk_toolkit.win.1.0_installer_1.0.1.19.zip)
Project: (C:\weiyun\ Sidu Technology\QCC30xx_QCC51xx development board information\4. Official ADK\ADK20.1\qcc514x-qcc304x-src-1-0_qtil_standard_oem_earbud.rar)
3. Hardware environment
Debugger Adapter: TRBI200 or USB
Platform: I love Bluetooth network QCC30XX/51XX development board * 2 + QCC3040 module * 2
Chip: QCC3040
---- ORIGINAL
2. 软件环境
PC: win10
MDE: (C:\weiyun\ 思 度 科 技 \QCC30xx_QCC51xx 开 发 板 资 料 \3. 开 发 环 境\qualcomm_mde.win.2.4_installer_2.4.0.158.zip)
ADK Tool: (C:\weiyun\ 思 度 科 技 \QCC30xx_QCC51xx 开 发 板 资 料 \4. 官 方ADK\ADK20.1\adk_toolkit.win.1.0_installer_1.0.1.19.zip)
Project: (C:\weiyun\ 思 度 科 技 \QCC30xx_QCC51xx 开 发 板 资 料 \4. 官 方ADK\ADK20.1\qcc514x-qcc304x-src-1-0_qtil_standard_oem_earbud.rar)
3. 硬件环境
Debugger Adapter: TRBI200 或 USB
Platform: 我爱蓝牙网 QCC30XX/51XX 开发板 * 2 + QCC3040模块 * 2
Chip: QCC3040
————————————————
版权声明：本文为CSDN博主「NiceBT」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wzz4420381/article/details/106773005
Also, about the 52bluetooth forum, I had managed to make an account there and download a pdf file a few years ago. Haven't visited it since and can't seem to log in anymore for some reason, but that forum has some kind of virtual currency system for downloading files. Some files seemed to be free (with limit on maximum downloads per day) and for some you needed to have enough of the virtual currency. You could either buy the currency or you get some for free if others like your post, your uploaded files get enough downloads, or something like that. I remember it was a hassle to get the account created in the first place. So unless you find something there that you absolutely need, I wouldn't bother trying to make an account because the file download might not be free anyway.
Thank you for that. I noticed you needed to use some sort of currency to buy the code to register an account in the first place but wasn't sure what kind of payment method it wanted. If you need virtual currency to download files that's even more of a headache.
I was lying in bed last night mulling this over, as you do, and it occurred to me that the ADK configuration tool thing is probably fairly agnostic to the chip you have connected. All it does is notice the registry keys present and then spool up a configuration selection based off of that. This is cool if there's firmware already present on the chip you are using but if there isn't you need the actual source code development tools in order to get something onto the chip.
It occcurred to me that even though you have the USB connected up that unless you have a battery connected the actual 'Vbat' power line isn't powered up and neither is the system boot pin. It's possible that even though the USB bridge to the chip was recognised that maybe the software on the chip hasn't been running. I was basing my thought that no firmware is on my chips because the LEDs aren't lighting up and no Bluetooth devices are being available for pairing either. I'm not sure what happens if no firmware is present but certainly the ADK wouldn't work.
The QC website indicates that the QCC302x suite would work for the 3040 but unless there's a 3040 specific sink app in the source code development it's not going to work I don't think. One fundamental difference is the 3040 has onboard flash memory as opposed to a separate chip so I'd have thought the difference in memory map would need to be taken into consideration. I'll have to look more into this. It's possible the 3040 wasn't being recognised by the DFU because the system wasn't booted but who knows. I'll keep things updated.
I was lying in bed last night mulling this over, as you do, and it occurred to me that the ADK configuration tool thing is probably fairly agnostic to the chip you have connected. All it does is notice the registry keys present and then spool up a configuration selection based off of that. This is cool if there's firmware already present on the chip you are using but if there isn't you need the actual source code development tools in order to get something onto the chip.
It occcurred to me that even though you have the USB connected up that unless you have a battery connected the actual 'Vbat' power line isn't powered up and neither is the system boot pin. It's possible that even though the USB bridge to the chip was recognised that maybe the software on the chip hasn't been running. I was basing my thought that no firmware is on my chips because the LEDs aren't lighting up and no Bluetooth devices are being available for pairing either. I'm not sure what happens if no firmware is present but certainly the ADK wouldn't work.
The QC website indicates that the QCC302x suite would work for the 3040 but unless there's a 3040 specific sink app in the source code development it's not going to work I don't think. One fundamental difference is the 3040 has onboard flash memory as opposed to a separate chip so I'd have thought the difference in memory map would need to be taken into consideration. I'll have to look more into this. It's possible the 3040 wasn't being recognised by the DFU because the system wasn't booted but who knows. I'll keep things updated.