@o11111 thanks for answer.
The ENABLE_I2S_OUTPUT i had already defined
PcmPioConfig: does not work.
Pcm1PioConfig: works only when i jump the i2s to embedded PCM5102 in the dev board and use the IIS_OUT (P2 Jack). (the audio works perfectly)
I'll try to test my ES9838 board, maybe he has some defect.
It''s the length of the wires between I2S out and DAC can cause significantly dada loss?
@LOGICSB have you tried connecting your DAC to other I2S sources (i.e. Raspberry Pi)?
I had took a quick look at ES9038PRO datasheet and it seems to require I2C control, so you'll need to implement it. Refer to headset/src/peripherals
/audio_i2s_SSM2518.c and implement same functions i.e. in audio_i2s_device.c (or you can create separate file and guard it with INCLUDE_ES9038PRO_DAC or something similar).
I had took a quick look at ES9038PRO datasheet and it seems to require I2C control, so you'll need to implement it. Refer to headset/src/peripherals
/audio_i2s_SSM2518.c and implement same functions i.e. in audio_i2s_device.c (or you can create separate file and guard it with INCLUDE_ES9038PRO_DAC or something similar).
No, i'm using directly. This case of VCC is strange for me. IS this use ground loop for something? Because with separated power sources does not work. The DAC's board needs 5v, but works fine with 3v3 providade by dev board
I2S is digital signal, so it needs to have same ground level, otherwise DAC will receive garbage data. So it's not actually ground loop (which shouldn't be a problem for digital audio), it's quite the opposite. I'm not totally sure if this is the case, but at least it would make sense if so.
Maybe DAC itself doesn't need 5V (according to datasheet it needs 3.3V and 1.2V), probably there's some sort of LDO, you might google IC markings to know for sure.
It's totally sense. I have tested with a simple DAC, the only audio heard is a wheezing audio, btw the board with the ES9038 DAC supress it and create total silence doing a fake impression that's not working. Now audio is working like a charm. So... now, the last part is integration with ESP32 S3 via I2C. Thanks @o11111
Is there any publicly available Aptx-compatible BT Transmitter on the market right now? I've got some assembled units off Amazon and eBay but I am hoping to get just a module by itself because it's going into a really tight space.
I bought a QCC 3008 module but from reading this thread it seems that isn't going to work for what I need, and almost all of the talk I've seen here has been in regards to receivers so I figured it'd be best to simply ask.
Thank you!
I bought a QCC 3008 module but from reading this thread it seems that isn't going to work for what I need, and almost all of the talk I've seen here has been in regards to receivers so I figured it'd be best to simply ask.
Thank you!
Last edited:
I just assembled a PCB containing the BTM875-E and the CODEC and making the firmware now.
Where can I find these APIs? I can't find anything in the sample sink project (speaker.xiw) for xIDE.
Thanks for the information!
I realize I didn't specify that I'm looking for Aptx-ll in particular, and I dont know where to go digging for firmware files either.
I opened up a transmitter that I got a while ago and found that it has a qcc3040 module inside of it, so I looked up the module's part number and found a pinout for it and a very broad datasheet.
This chip does exactly what I need, but I don't see the contact points for the connections the SPI programmer uses. Would I be able to connect the USB data lines and USB v-bus to interface with it in order to extract the firmware? The module seems to be pretty readily available online so for the small number of units I'd need it for it would be a simple solution but I don't know if the software tools that are available here are compatible with this chip.
And why do you think they should be there?
Probably no. It might be encrypted.
audio/qcc518x_qcc308x/kalimba_ROM_14612/kymera/prebuilt_dkcs/maor_rom_release/download_aptx_low_latency_encode.edkcs is the aptX LL encoder. You can refer to how other codecs are implemented (starting from searching how i.e. download_aptx_adaptive_encode.edkcs is used).
Search in my previous posts, I've shared firmware source code and tools for QCC chipsets.
Didn't really expect them to be, but with how general the datasheets I found were I wasn't sure if some of the PIO ports were also the SPI connection points but just not called out as such. I've seen people mention in this thread that some chips can connect via USB so I figured that must be it and I could just copy what I need from it, but:
Bummer, but makes sense that it would probably be protected since the USB data lines on this unit were originally connected directly to the charge port.
I'm assuming that's in the software that was in the dropbox near the beginning of the thread? I installed a version of the APK and Bluesuite a bit ago based on some scrounging from things I saw on TinyOsShop, but my SPI Programmer hasn't arrived so when I launch the software it asks what connection to use, sees nothing, then just leaves the software up with empty windows. I'd use a USB device if I had one but all I have right now is my 3008 and 3040 that's likely encrypted.
Will do, thank you! I'm starting from scratch here so every resource I find is absolutely golden.
There's SPI in some sense (hardware supports it and you can use it in firmware for i.e. communicating with SPI LDC), but one cannot use it for programming.
No, Dropbox is only for old CSR stuff. This file is part of firmware sources, which I've shared previously.
You can't (probably) dump firmware from end device, but you can flash clean module (I'd recommend going for BTM581 or BTM551 at the very least) with firmware built from sources.
That one as far as I remember is the one that is supposed to have kalimba take direct control of the PIO port and use timers to simulate an I2C master signal. If you are also making your own kalimba code you can probably include that file your project and find a way to call it through kalimba. In this case whatever data is coming in through the SDA line will have to be read in through kalimba as well
There is a ../tools/include/firmware/i2c.h for the VM, there should be some comments in this file for explanation. This should probably be used in conjunction with the I2C settings in the pskey
I saw that too. Thanks for pointing it out. Would I just include this file in the VM sink project (speaker.xip/soundbar.xip) main.c and then call the functions in the i2c.h in the main function?
I know how to code C/Assembly. I’m just unaware of where exactly I should call the i2c.h functions.
In another CSR8675 device with firmware already developed for it, I noticed in the ADK config tool that the I2C settings allow you to select a plugin type: The Qualcomm User-defined I2C control plugin, Qualcomm SSM_2518 I2S development board and Customer developed plugin. using the the Qualcomm User-defined I2C control plugin and the Qualcomm SSM_2518 I2S development board just crashed the device, and the Customer developed plugin doesn’t crash it, but the I2C commands don’t work on the slave device (I have checked and they are correct commands).
I’m assuming I have to make my own “Customer developed” plugin, but how exactly is that achieved? I found nothing in the docs supporting this. Is what I suggested earlier regarding the main.c and calling the i2c.h functions there correct?
Yes that's probably how it is supposed to be used. I haven't used it myself so I don't any personal experience to share, but if you have worked with CSR I'm sure you have seen that sometimes you just can't predict how the chip will react to calling some of their functions, but in general, the way you described is how such a library function would be used. Just make sure to go through the comments in i2c.h file and read between the lines if there any hints at all, regarding how to use this function. Also make sure you set all the proper pskeys in pstool. I think the i2c.h mentions something about an external pull up for the i2c pins, so you probably need to look into that as well.
If you have the source code for this firmware you can search for all calls to the i2c function in the source code, and may be it will show the method of using this function. If not, if this custom firmware is based on the sink project, may be just look for calls to the i2c function in the VM code for the sample sink project and find something out from there.
If nothing works at all, personally I would suggest just using the kalimba i2c.asm program because with that, at least you know exactly which pio pins are being turned on and off and for exactly what duration of time. You will also be able to tweak it to your liking. You will need to find a way to integrate i2c.asm with your current kalimba project and also find out how to call it at the appropriate time. You will probably need to adjust your VM code so that it sends a message to kalimba at the moment you want the I2C communication to happen. Also I think there is a pskey setting or a library function call or something, that you need to do first in order to let kalimba take direct control of the pio pins, so you'll have to look into that as well. It might get a bit complicated but I think it's doable.
@goose_ader does your ADK version have something called display library? If there is an ADK\src\lib\display folder then there probably is. I think this is ultimately supposed to control an LCD display, although just looking at the display.c and display.h source code may not make it apparent. You will need to dig around a bit, but this library should send a series of VM messages that ultimately calls a function that will do an I2C transfer to an LCD device. But how to use the display library functions directly in your VM project may not easy to see, so I suggest instead to reverse engineer the VM message sequence that it generates, and reach the point where it actually calls the I2C library function, and just use that as a reference on how to actually use the library function.
If your ADK version has a file called display_plugin_cns10010.c, look for lcd_write() function inside this file. If not, there might be something equivalent. Or you could install an older ADK version (ADK3.x or ADK4.x < ADK4.2) which should have this file, and use it as a reference.
If your ADK version has a file called display_plugin_cns10010.c, look for lcd_write() function inside this file. If not, there might be something equivalent. Or you could install an older ADK version (ADK3.x or ADK4.x < ADK4.2) which should have this file, and use it as a reference.
For starters you could call this function in a button press handler in your VM project and check the I2C signals in an oscilloscope or logic analyzer, if you haven't tried this already. Since this is master at the very least it should generate a clock signal if the function call is working.
Last edited: