Hi All,
Recently, inspired by the progress with the camera, I started an "investigation" on how the FM radio actually works on out Tattoos. Unfortunately I am not able to continue working on that (not atleast until March), so I decided to share the information on the FM radio that I have so one of you folks can try to get it working.
The FM radio on Tattoo is handled by the BRF6350 chip. It is actually responsible mainly for the Bluetooth, but it also handles the FM radio. I've decided to search a bit more about the chip and found that TI has released a library (brflinux available here). That library is actually compiled in the bts daemon (the daemon responsible for both Bluetooth and FM radio on the official 1.6 ROMs). To function, this library also needs "an init script" that is a proprietary file called FMInit_300.bts under /system/etc/firmware/ .
The BRF6350 chip has analog audio output that is connected to a switch, controllable by the sysfs interface. That switch is accessable by the file /sys/class/htc_accessory/fm/flag . If you read from it you can see the current state, if you write to it you can change the current state. The file can handle the following strings:
"disable" - Turn off audio output by the BRF6350 chip
"fm_headset" - Turn on audio and send it to the headphones
"fm_speaker" - Turn on audio and send it to the phone speaker
When FM radio is off the switch should always be set to "disable" and when the radio is turned on the state should be set to "fm_headset" (atleast that is what is done on the official ROMs).
To detect if the headset is connected (that is your anthenna). You should read the following sysfs file /sys/class/switch/h2w/state a number is written there (in ASCII), that describes the state of the headset. The bits in that number have the following meaning:
#define BIT_HEADSET (1 << 0)
#define BIT_HEADSET_NO_MIC (1 << 1)
#define BIT_TTY_FULL (1 << 2)
#define BIT_FM_HEADSET (1 << 3)
#define BIT_FM_SPEAKER (1 << 4)
#define BIT_TTY_VCO (1 << 5)
#define BIT_TTY_HCO (1 << 6)
#define BIT_35MM_HEADSET (1 << 7)
atleast bits 0 or 1 and 7 should be set if the headset is connected.
After I had this basic info gathered, I began to search for application of all that.
In the following topic an interface is described that could be used for the FM radio on ROMs for our Tattoos. If we can connect the brflinux library to the JNI interface at the base of the new CyanogenMod FM radio application, we can have the radio up and running.
In fact the interfaces of the JNI library (at the base of the FM radio app) and the brflinux library are very similar so it would be quite possible.
Hope this was useful.
Cheers,
Rosti (a.k.a pisaro)
thank you very much!!
Why is not this topic in the Click DEVELOPMENT forum?
thanks pisaro for your work. I hope some one could continue with it.
Thanks for your effort
pisaro said:
The FM radio on Tattoo is handled by the BRF6350 chip. It is actually responsible mainly for the Bluetooth, but it also handles the FM radio. I've decided to search a bit more about the chip and found that TI has released a library (brflinux available here). That library is actually compiled in the bts daemon (the daemon responsible for both Bluetooth and FM radio on the official 1.6 ROMs). To function, this library also needs "an init script" that is a proprietary file called FMInit_300.bts under /system/etc/firmware/ .
The BRF6350 chip has analog audio output that is connected to a switch, controllable by the sysfs interface. That switch is accessable by the file /sys/class/htc_accessory/fm/flag . If you read from it you can see the current state, if you write to it you can change the current state. The file can handle the following strings:
"disable" - Turn off audio output by the BRF6350 chip
"fm_headset" - Turn on audio and send it to the headphones
"fm_speaker" - Turn on audio and send it to the phone speaker
Click to expand...
Click to collapse
Much thanks ! Just the info I was looking for.
If I can get this FM audio routing working, I think I'll have FM radio working on my HTC legend, but I'd guess it'd work for many of the phones using BRF6300/BRF6350/BL6450 aka WL1271/1273/1281/1283 etc.
I have the hcitool commands that have the FM working I'm pretty sure. RSSI responds to tuning and antenna movement as I'd expect.
Now, where can I find FMInit_300.bts ? No results on google search. I'm not really convinced I need it, I have other files such as fm_rx_init_1273.2.bts and fmc_init_1273.2.bts, AND I think I've sent all the needed commands via hcitool, except perhaps for audio routing.
thank you very much!!
Looks good mate!
mikereidis said:
Much thanks ! Just the info I was looking for.
If I can get this FM audio routing working, I think I'll have FM radio working on my HTC legend, but I'd guess it'd work for many of the phones using BRF6300/BRF6350/BL6450 aka WL1271/1273/1281/1283 etc.
I have the hcitool commands that have the FM working I'm pretty sure. RSSI responds to tuning and antenna movement as I'd expect.
Now, where can I find FMInit_300.bts ? No results on google search. I'm not really convinced I need it, I have other files such as fm_rx_init_1273.2.bts and fmc_init_1273.2.bts, AND I think I've sent all the needed commands via hcitool, except perhaps for audio routing.
Click to expand...
Click to collapse
I attach the file FMInit_300.bts extracted from a HTC 1.6 ROM. I hope it helps you with your work.
http://www.megaupload.com/?d=NRMYDZI2
Looking forward to seeing more progress!
Our phones would show, with fm radio and gingerbread.
pisaro said:
Hi All,
Recently, inspired by the progress with the camera, I started an "investigation" on how the FM radio actually works on out Tattoos. Unfortunately I am not able to continue working on that (not atleast until March), so I decided to share the information on the FM radio that I have so one of you folks can try to get it working.
The FM radio on Tattoo is handled by the BRF6350 chip. It is actually responsible mainly for the Bluetooth, but it also handles the FM radio. I've decided to search a bit more about the chip and found that TI has released a library (brflinux available here). That library is actually compiled in the bts daemon (the daemon responsible for both Bluetooth and FM radio on the official 1.6 ROMs). To function, this library also needs "an init script" that is a proprietary file called FMInit_300.bts under /system/etc/firmware/ .
The BRF6350 chip has analog audio output that is connected to a switch, controllable by the sysfs interface. That switch is accessable by the file /sys/class/htc_accessory/fm/flag . If you read from it you can see the current state, if you write to it you can change the current state. The file can handle the following strings:
"disable" - Turn off audio output by the BRF6350 chip
"fm_headset" - Turn on audio and send it to the headphones
"fm_speaker" - Turn on audio and send it to the phone speaker
When FM radio is off the switch should always be set to "disable" and when the radio is turned on the state should be set to "fm_headset" (atleast that is what is done on the official ROMs).
To detect if the headset is connected (that is your anthenna). You should read the following sysfs file /sys/class/switch/h2w/state a number is written there (in ASCII), that describes the state of the headset. The bits in that number have the following meaning:
#define BIT_HEADSET (1 << 0)
#define BIT_HEADSET_NO_MIC (1 << 1)
#define BIT_TTY_FULL (1 << 2)
#define BIT_FM_HEADSET (1 << 3)
#define BIT_FM_SPEAKER (1 << 4)
#define BIT_TTY_VCO (1 << 5)
#define BIT_TTY_HCO (1 << 6)
#define BIT_35MM_HEADSET (1 << 7)
atleast bits 0 or 1 and 7 should be set if the headset is connected.
After I had this basic info gathered, I began to search for application of all that.
In the following topic an interface is described that could be used for the FM radio on ROMs for our Tattoos. If we can connect the brflinux library to the JNI interface at the base of the new CyanogenMod FM radio application, we can have the radio up and running.
In fact the interfaces of the JNI library (at the base of the FM radio app) and the brflinux library are very similar so it would be quite possible.
Hope this was useful.
Cheers,
Rosti (a.k.a pisaro)
Click to expand...
Click to collapse
Thanks for your info. Most of the solution to the FM Radio is what you said here some time ago, so I want to congratulate you for this previous vision you gave us
THANKS
Related
If you refer to page 23 (Tips and Tricks) of the Motorola Razr User guide (General Tips - last bullet point), it mentions an FM radio.
I know that though the chipset has the hardware for FM, the application is missing ? Or does anyone know if it is hidden anywhere ?
Yes I have post this many times to Motorola support but they don't want to reply
Also pages 30 and 32 mention the FM radio.
The application is present in software as part of the stock music app, but doesn't work.
Sent from my XT910 using xda premium
My guesses are:
1) The manual is copy/pasted from other model's.
2) No FM radio kernel module/driver yet for the current kernel version.
Since the manual had mentioned it, you complaint it to FTC or equivalent. If there no FM radio driver yet, then, we wait and see. The current Android 2.3.5 implementations in RAZR is horrible. Menu's color scheme has no consistency. Most probably the Motorola was rushing to push the RAZR into the market, hoping it can beat GNex.
The FM radio app is there...
1) Get Anycut
2) Create new -> Activity
3) Find FMplayer and create the shortcut in home screen. For the time being, enjoy the FM Radio app....
bahathir said:
My guesses are:
1) The manual is copy/pasted from other model's.
2) No FM radio kernel module/driver yet for the current kernel version.
Since the manual had mentioned it, you complaint it to FTC or equivalent. If there no FM radio driver yet, then, we wait and see. The current Android 2.3.5 implementations in RAZR is horrible. Menu's color scheme has no consistency. Most probably the Motorola was rushing to push the RAZR into the market, hoping it can beat GNex.
The FM radio app is there...
1) Get Anycut
2) Create new -> Activity
3) Find FMplayer and create the shortcut in home screen. For the time being, enjoy the FM Radio app....
Click to expand...
Click to collapse
Wow this is great thanks for the trick! So happy to have my fm radio. I wonder what other goodies are hiding
Tunein Radio Pro is a great app that allows you to listen to radio stations from all around the country, and it's reasonably priced. A one time $.99 charge.
If you dont want to commit to buying they have a free version you can use to see if you like it or not before you buy.
You can get tune in radio for free at Getjar.
Oaklands said:
You can get tune in radio for free at Getjar.
Click to expand...
Click to collapse
I always forget about getjar *facepalm*, only thing about getjar is they are very slow to release updates, if you recieve them at all.
So, is FM radio working for you? I can only enter to app, but radio can't find any station.
grubynawro said:
So, is FM radio working for you? I can only enter to app, but radio can't find any station.
Click to expand...
Click to collapse
Same here, all I get is the message: " Launching FM Radio please wait...."
Dont know.. but as my common sense says... if there is no APK in the system for the FM radio, then how can the FM radio application can tune in or even work..... food for thought????
Or I am a complete idiot??
There doesn't need to be a dedicated apk if it's built into another app, which it is in this case.
Again, people, the software is there, the hardware either isn't there at all or doesn't have the necessary drivers to work with said software. Best case scenario, the hardware is there and Moto liven it with an update.
Sent from my XT910 using xda premium
It's not hidden. The RAZR and Droid RAZR do not have FM radio hardware. The manual is wrong.
abesh said:
If you refer to page 23 (Tips and Tricks) of the Motorola Razr User guide (General Tips - last bullet point), it mentions an FM radio.
I know that though the chipset has the hardware for FM, the application is missing ? Or does anyone know if it is hidden anywhere ?
Click to expand...
Click to collapse
Well if it doesnt have it then us owners should go after them for advertising things that it doesnt have!
Snippets from dmesg...
Code:
<6>[ 3.803466] asoc: cpcap codec <-> omap-mcbsp-dai.2 mapping ok
<6>[ 3.804504] asoc: cpcap in-call <-> MODEM mapping ok
<6>[ 3.805145] asoc: cpcap fm <-> FMDummy mapping ok
<6>[ 3.805603] asoc: HDMI <-> hdmi-dai mapping ok
<6>[ 3.806610] asoc: cpcap bt-call <-> MODEM mapping ok
The FM feature is being mapped to FMDummy, ie, being disabled in kernel level.
From $ cat /proc/asound/pcm
Code:
00-00: Multimedia null-codec-dai-0 : : playback 1
00-01: McBSP3-Codec cpcap codec-1 : : playback 1 : capture 1
00-02: Modem-Codec cpcap in-call-2 : : playback 1 : capture 1
00-03: FMAudio cpcap fm-3 : : playback 1
00-04: HDMI HDMI-4 : : playback 1
00-05: Modem-BT cpcap bt-call-5 : : playback 1 : capture 1
00-06: McBSP3-BT cpcap bt-6 : : playback 1 : capture 1
00-07: SPDIF dit-hifi-7 : : playback 1
00-08: McBSP3-BP BPVoice-8 : : playback 1 : capture 1
00-09: FM cpcap stdac-9 : : playback 1
Here we can see there is FMAudio audio device exist, but since it being disabled during boot up. and I might be wrong,
I really hope Motorola can get the proper kernel module/driver for WL1285C chipset. because the boot loader is locked for developers to try newer or better driver.
Thank you.
bahathir said:
Snippets from dmesg...
Code:
<6>[ 3.803466] asoc: cpcap codec <-> omap-mcbsp-dai.2 mapping ok
<6>[ 3.804504] asoc: cpcap in-call <-> MODEM mapping ok
<6>[ 3.805145] asoc: cpcap fm <-> FMDummy mapping ok
<6>[ 3.805603] asoc: HDMI <-> hdmi-dai mapping ok
<6>[ 3.806610] asoc: cpcap bt-call <-> MODEM mapping ok
The FM feature is being mapped to FMDummy, ie, being disabled in kernel level.
From $ cat /proc/asound/pcm
Code:
00-00: Multimedia null-codec-dai-0 : : playback 1
00-01: McBSP3-Codec cpcap codec-1 : : playback 1 : capture 1
00-02: Modem-Codec cpcap in-call-2 : : playback 1 : capture 1
00-03: FMAudio cpcap fm-3 : : playback 1
00-04: HDMI HDMI-4 : : playback 1
00-05: Modem-BT cpcap bt-call-5 : : playback 1 : capture 1
00-06: McBSP3-BT cpcap bt-6 : : playback 1 : capture 1
00-07: SPDIF dit-hifi-7 : : playback 1
00-08: McBSP3-BP BPVoice-8 : : playback 1 : capture 1
00-09: FM cpcap stdac-9 : : playback 1
Here we can see there is FMAudio audio device exist, but since it being disabled during boot up. and I might be wrong,
I really hope Motorola can get the proper kernel module/driver for WL1285C chipset. because the boot loader is locked for developers to try newer or better driver.
Thank you.
Click to expand...
Click to collapse
Ok know im really confused, there is or isn´t hardware for FM radio??
You need proper kernel driver for FM device to be working in Android OS. For time being kernel is not "recognizes" the FM device yet.
I am not sure if the WL1285C chipset has no fm radio hw/circuitry, I cannot find the specs sheet yet.
Sent from my XT910 using XDA App
How is going this issue? Any update?
The chipsets from the ogdriod and on have been revisions of similar Texas instruments chips that include Bluetooth, wifi, and FM radio, on one chip, but it is very difficult to find drivers that will compile into a working kernal and not break everything else
Sent from my DROID RAZR using xda premium
I had a couple of questions about using Spirit FM Radio app on CM 7.2. And I would like to know in detail about it.
Firstly, When I ran the Spirit app on CM 7.2 i noticed that it doesn't switch on the Bluetooth. Does that mean that it uses the internal Broad com FM chip instead of Bluetooth to receive FM transmissions just like in the LG stock FM radio app?
Will the Spirit FM app still run properly if I UN-install the CM 7.2 Stock FM app? Or does it need the CM 7.2 Stock FM app to run properly?
In the setting of the app, within audio, I saw various options like cyanogen Mod, LG, lge-msm7x27,etc. Even tough i didn't see any difference in quality while going through different options. Which would be the ideal option for us and What do these options do?
CM9 hasn't got a radio am I right? (Btw I'm new to the forum I couldn't find a topic to write this I'm sorry
What phone are you using?
When Bluetooth is enabled FM is enabled too because they locate at the same chip. It's the easiest way to enable FM and so is CM radio doing. Spirit FM (and stock LG) does it little bit harder by only enabling FM thus saving some starting time and battery (battery part is not a 100% fact though, only my own speculation).
You can remove CM radio, it is not needed.
Recommended method by author in Spirit is CyanogenMod. I don't know exactly what are the differences between different methods but stick with CyanogenMod.
Spirit FM does use Bluetooth, only the icons aren't changed that's all.
Sent from my LG-P500 using xda premium
4silvertooth said:
Spirit FM does use Bluetooth, only the icons aren't changed that's all.
Sent from my LG-P500 using xda premium
Click to expand...
Click to collapse
I might be wrong but if Bluetooth is turned on i see no indication, not only in status bar, settings, no device discovers it (visible), i think i need an app to check the components...
Will check back whit the answer
Edit: It dose use bluetooth
moby_test said:
I might be wrong but if Bluetooth is turned on i see no indication, not only in status bar, settings, no device discovers it (visible), i think i need an app to check the components...
Will check back whit the answer
Edit: It dose use bluetooth
Click to expand...
Click to collapse
How did u finally come to that conclusion that it does use Bluetooth? And if it does... Does that mean that there is no big difference in the way Spirit, Cyanogen mod and LG FM radio app works?
I have my own thread for questions, 1st link in my sig: http://forum.xda-developers.com/showthread.php?p=13379669
And I respond to emails and PMs, but sometimes respond on my thread for all to benefit. Or just let me know a thread's been opened...
See below for answers:
sweettaniyaa said:
Firstly, When I ran the Spirit app on CM 7.2 i noticed that it doesn't switch on the Bluetooth. Does that mean that it uses the internal Broad com FM chip instead of Bluetooth to receive FM transmissions just like in the LG stock FM radio app?
Will the Spirit FM app still run properly if I UN-install the CM 7.2 Stock FM app? Or does it need the CM 7.2 Stock FM app to run properly?
In the setting of the app, within audio, I saw various options like cyanogen Mod, LG, lge-msm7x27,etc. Even tough i didn't see any difference in quality while going through different options. Which would be the ideal option for us and What do these options do?
Click to expand...
Click to collapse
Copied on my thread, because I did a lot of thinking and typing...
Yes you can remove the CM FM app.
On CM7, the default CyanogenMod audio method is generally best. It's the same method the CM7 FM app uses, so it's the most likely to work well, especially when dealing with things like phone calls coming in when FM is on.
If a CM ROM for any phone has a CM FM app, this method should work, but unfortunately that's not yet the case with CM9 ROMs. so low level methods are needed for now on CM9, and there are often issues, and many CM9 ROMs just don't support FM audio routing yet, or I haven't figured them out.
Re: Bluetooth: my app has many ways to access FM chips.
- The first method I supported was via Bluetooth (the HCI API), like the CM FM app. Like it, my app can run commands using the command line hcitool utility, and this is nice because my app can run without root/SU. But it's not too efficient, especially when using RDS where lots of data gets transferred.
- For better efficiency, with root, my app supports direct access to the HCI sockets, through a daemon, because apps don't have the privilege otherwise.
- But because many people were running stock or stock derived ROMs using the Broadcom proprietary BT stack, and I could find no way to send HCI commands with it, I created a "UART mode" that communicates directly with the Bluetooth/FM UART. The wireless part of Bluetooth is not switched on, which saves power. But this mode requires root (unless /dev/ttyHS0 or whatever is accessible from an app), and only works if BT is off.
- A new access method is available now on stock and stock derived ROMs that run the proprietary Broadcom BT stack and that supports the stock LG FM app. This can work on stock, unrooted devices. In this mode the characteristics of the stock FM stack are unavoidable, both positive and negative.
The Broadcom proprietary BT stack has a special mode where Bluetooth is considered off, but FM is on. This enables the Bluetooth HCI "UART" to provide a path to control the FM part of the chip.
- There are different device driver access methods used for dedicated FM chips not contained in a BT/FM combo chip, but those don't apply to the P500.
OK for SGA?
Can I use this FM radio app for my Samsung Galaxy Ace? I have Ice Cream Sunday ROM installed.
donzzy said:
Can I use this FM radio app for my Samsung Galaxy Ace? I have Ice Cream Sunday ROM installed.
Click to expand...
Click to collapse
Off-topic, and you should ask on my thread anyway, or check post 2 of my thread. Please don't respond here.
Canned response now:
The Simpsons taught me that among Hemingway's words of wisdom was:
“The shortest answer is doing the thing.”
IE, why don't you just try it ? It's free and only takes a minute or two I think.
There's even an intro that can be read and will give some useful information on configuration.
Then if you have trouble, you can come back, report it, and hope for an answer.
mikereidis said:
Copied on my thread, because I did a lot of thinking and typing...
Yes you can remove the CM FM app.
On CM7, the default CyanogenMod audio method is generally best. It's the same method the CM7 FM app uses, so it's the most likely to work well, especially when dealing with things like phone calls coming in when FM is on.
If a CM ROM for any phone has a CM FM app, this method should work, but unfortunately that's not yet the case with CM9 ROMs. so low level methods are needed for now on CM9, and there are often issues, and many CM9 ROMs just don't support FM audio routing yet, or I haven't figured them out.
Re: Bluetooth: my app has many ways to access FM chips.
- The first method I supported was via Bluetooth (the HCI API), like the CM FM app. Like it, my app can run commands using the command line hcitool utility, and this is nice because my app can run without root/SU. But it's not too efficient, especially when using RDS where lots of data gets transferred.
- For better efficiency, with root, my app supports direct access to the HCI sockets, through a daemon, because apps don't have the privilege otherwise.
- But because many people were running stock or stock derived ROMs using the Broadcom proprietary BT stack, and I could find no way to send HCI commands with it, I created a "UART mode" that communicates directly with the Bluetooth/FM UART. The wireless part of Bluetooth is not switched on, which saves power. But this mode requires root (unless /dev/ttyHS0 or whatever is accessible from an app), and only works if BT is off.
- A new access method is available now on stock and stock derived ROMs that run the proprietary Broadcom BT stack and that supports the stock LG FM app. This can work on stock, unrooted devices. In this mode the characteristics of the stock FM stack are unavoidable, both positive and negative.
The Broadcom proprietary BT stack has a special mode where Bluetooth is considered off, but FM is on. This enables the Bluetooth HCI "UART" to provide a path to control the FM part of the chip.
- There are different device driver access methods used for dedicated FM chips not contained in a BT/FM combo chip, but those don't apply to the P500.
Click to expand...
Click to collapse
Thank you for clearing it to me. But I don't know... something weird happened to me. I was using Spirit FM radio app whole day yesterday but the Blue-tooth icon never showed up. But today when tried the app again It has been showing the Blue-tooth icon. I don't get it. What changed? I tried re-booting and everything. Still the same.
Dear all,
I'm working on custom hardware built on Amlogic AML8726-MX SoC. I have the board working with Android 4.2.1 compiled with telephony support. We use standalone GSM module from Telit and I successfully implemented RIL and I'm able to make or receive calls. Unfortunately I'm stucked with routing the audio. The module has digital i2s interface and I connected it through I2S<->USB Audio converter to the SoC.
So now I have two Alsa devices - one is dedicated to analog interfaces (speaker, headphones, microphone) and is working in android applications. The second one represents USB audio and I'm able to use that on kernel level with command line interface. Now I need to to connect these two together to be able to play the voice call using analog interface.
Is there please anyone who can point me into right direction? I'm experienced in kernel development, but going into higher levels is new for me. Can such thing be done just by altering audio_policy.conf and related files or the issue is much more complicated that I expected?
best regards
Jan
I have a android car stereo. The mic is built into the device, so the capture sound is very else.
It supports usb host, so I found a usb microphone and connected it. But the devices Bluetooth HFP always take the inbuilt microphone. Is there a way I can change just the default audio input to the usb mic and output to the inbuilt audio output
Code:
# cat /proc/asound/cards
0 [smdk ]: HDA-Intel - HDA ATI SB
HDA ATI smdk at 0xfe8f4000 irq 16
1 [tera ]: USB-Audio
Guillemot Corporation Dualpix tera at usb-0000:00:12.2-2, high speed
# cat /proc/asound/devices
1: [ 0] : control
2: [ 0- 1]: digital audio playback
3: [ 0- 2]: digital audio capture
4: [ 1- 0]: digital audio capture
5: [ 1] : control
any help?
Send digital audio out of headunit
Dug around a lot and found no listing for this. It might help some folks so I am posting it expecting to get dumped on for not finding the needle in the haystack nearest the moon on Rygel 7. Fire away. Most Android based head units for cars have USB connectors on them. In the world of audio it is best not to convert audio from analogue to digital and back too many times. I like many have an offboard digital based signal processor between my headunit and power amps. I would like to send digital to the processor but most head units don't offer a digital output even as an option and the few that I have found that do source that signal before the volume control in the signal's path so you can't control your listening level with the volume control on your head unit. Apparently Android Kit Kat (4.??) has some driver compatibility with certain audio devices (sound cards?). Android 5 or Lollipop has more. With that do I assume that most USB audio sound cards would be plug and play? What would a head unit developer need to do in order to maintain function of the volume control of the existing head unit assuming it was a droid device of course.
simpleDSP installation into MTCD/E inside (ImprovedSound)
after in the summer of 2017 I disasseble the MTCB/C MCU firmware, I decided to try to improve the sound of these head units and bought a DSP test card based on the low-cost ADAU1401/1701 chip and started experiments with it to solve all the flaws in the sound settings of the Chinese head units.
In February 2018, Chinese vendors began the first sales of MTCE head units with internal DSP modules installed based on the ADAU1701 chip. A detailed analysis showed that the new hardware version of the head unit does not differ much from the previous one based on the sound processor BD3702, so I can try adding this module to me myself, because the Chinese refused to separately sell the DSP module for me.
[fig.1] photo of the main board of the new MTCE head unit with built-in DSP module
View attachment 4561586
[fig.2] photo of the main board of a typical MTCD/E head unit with a sound processor
View attachment 4561611
[fig.3] screenshot of the fake 9-band EQ of a typical MTCD/E head unit with a sound processor
View attachment 4561612
[fig.4] electrical circuit schematic of the sound processor of a typical MTCD/E head unit
View attachment 4561619
[fig.5] electrical circuit schematic of the sound switch of a typical MTCD/E head unit
View attachment 4561621
[fig.6] photo of the PX3(1GB) CPU coreboard of a typical MTCD/E head unit
View attachment 4561630
[fig.7] photo of the PX3/PX5 CPU coreboard of a typical MTCD/E head unit
View attachment 4561637
[fig.8] sigmaDSP ADAU1701 LQFP48 pinout
View attachment 4561645
[fig.9] sigmaDSP ADAU1401/1701 test board
View attachment 4561646
[fig.10] electrical circuit schematic of the ADAU1701 test board
View attachment 4561651
[fig.11] chinese built-in DSP ADAU1701 sub board
View attachment 4562327
As a result of comparing the MCU firmwares of the head units with the sound processor and with the integrated DSP module, we see that the same firmware is used.
When analyzing the behavior of the MCU firmware, it is found that after the start, it first polls the I2C bus on the sound processor chip and if it answers its own address, the head unit operates normally. If there is no sound processor, i.e. it does not respond to its own address, then the DSP chip is polled. If the DSP chip responds to its own address, then the head unit is already operating in the mode of improved sound with a real 15-band equalizer.
The sound processor chip BD37033 is powered by a 9-volt voltage source, and the AMS1117-3.3 stabilizer is used on the sigmaDSP test board, which allows operation from a voltage of up to 15 volts, so connect the DSP test board to the voltage of the sound processor chip on the main board. Disconnect from the I2C-bus of the MCU chip of the sound processor BD37033 and instead connect to the DSP chip ADAU1401/1701.
A real check showed that the software support of the DSP is in the MCU firmware from version 2.72 and higher and in Android builds versions 6.0.1, 7.1.2 and 8.0 and this mod is compatible with most MTCD/E head units
[fig.12] screenshot of the real 15-band EQ of a modified MTCD/E head unit with a DSP inside
View attachment 4562339
Since there is no electrical circuit schematic of the Chinese DSP module, then compare visually the board of the Chinese embedded DSP module with the DSP test board. The test board uses a onboard 12.288MHz crystal oscillator for clocking, and there is no resonator on the Chinese board and uses an 11.296MHz external clock from the CPU coreboard (I2S bit clock frequency for the sampling rate frequency of 44.1kHz).
Unsolder the crystal oscillator from the DSP test board, find the output of the clock signal on the CPU coreboard and provide a master clock signal to the 32-pin chip of the DSP chip ADAU1401/1701.
I and most my friends in the car listen only digital sounds from Android and analog sound from the FM radio tuner, so in the simplest version of the upgrade can do without using an analog audio switch that will simplify the finalization of the head unit.
On the new PX3/PX5 coreboards there are an additional 4 pins on which the I2S digital audio signals are output. These signals are connected to the DSP test board (the MCLKI signal of the external clock was already connected a little earlier).
[fig.13] digital I2S sound output from CPU coreboard
View attachment 4562387
On the older PX3(1GB) coreboars not are an additional pins for external output, but the I2S digital audio output can be founded on the onboard Wolfson audio codec chip pins. However, I have not connected such a coreboard yet and I do not know about real software compatibility with the Android build of version 5.1.1, but I suppose that this should be possible without much additional effort, but need to try...
[fig.14] digital I2S sound output from CPU to Wolfson audiocodec on coreboard
View attachment 4562396
Digital signals from Android sources must be connected to ADAU1401/1701 as follows:
-- Master CLOCK to 32 pin (MCLK) throu 100 Ohm resistor;
-- SDATA to 11 pin (MP0);
-- BLCK to 9 pin (MP5);
-- LRCLK to 8 pin (MP4)
The DSP chip has two built-in ADCs, so the analogue sound from the FM radio tuner can be connected to the sound processor pins as follows:
-- FM-R (pin 10) to 2 pin (ADC0);
-- FM-L (pin 11) to 4 pin (ADC1)
The DSP chip has four built-in DACs, so analog audio output can be connected for the power amplifier input to the sound processor pins as follows:
-- FR (pin 23) to 46 pin (DAC3);
-- FL (pin 22) to 45 pin (DAC2);
-- RR (pin 21) to 44 pin (DAC1);
-- RL (pin 20) to 43 pin (DAC0)
If do not need an additional output for an external subwoofer, then this is enough to enjoy improved sound due to the presence of a full 15-band equalizer, the ability to set delays, etc. (see screenshots at the end of this post), else if need to connect the external subwoofer, need to add the I2S DAC chip ES7144LV and connect it as follows:
-- Master CLOCK to pin 4 (CLKIN);
-- SDATA (MP6 pin 15) to pin 1;
-- SCLK (MP11 pin 19) to pin 2;
-- LRCLK (MP10 pin 16) to pin 3
[fig.15] electrical cuircuit schematic of the I2S DAC
View attachment 4562429
[fig.16] wire connections
View attachment 4564796
Verification showed that the improved sound is excellent
[fig.17]
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
[fig.18]
[fig.19]
[fig.20]
reserv1
reserv2
You are missing some pics there
[11]
[12]
[13]
in the process of filling information
[digital I2S sound output from CPU to Wolfson audiocodec on coreboard]
[digital I2S sound output from CPU coreboard]
[screenshot of the real 15-band EQ of a modified MTCD/E head unit with a DSP inside]
[...]
Xorit said:
You are missing some pics there
Click to expand...
Click to collapse
I did not forget these pictures, I just did not have time to cook them for posting in the thread -- coming soon...
cs-x(RU) said:
As a result of comparing the MCU firmwares of the head units with the sound processor and with the integrated DSP module, we see that the same firmware is used.
When analyzing the behavior of the MCU firmware, it is found that after the start, it first polls the I2C bus on the sound processor chip and if it answers its own address, the head unit operates normally. If there is no sound processor, i.e. it does not respond to its own address, then the DSP chip is polled. If the DSP chip responds to its own address, then the head unit is already operating in the mode of improved sound with a real 15-band equalizer.
Click to expand...
Click to collapse
Please correct me
The 7floor mod just re-routes and cuts some traces to control the in-build DSP directly and if i got it correct, people got full access to the DSP after.
You say that in the boot process the MCU polls it's hardware interfaces and if it detects the internal DSP it operates in "normal" mode.
Could this normal mode be modified to remove the config restriction and fully control the internal DSP? Or instead boot in "improved" mode?
// In my car (Opel Astra J) the HU is heavily mounted inside the dash and it's not fun to rip the whole thing apart every time.
Also I have a DVD drive installed and the space inside the silverbox is super limited due to that.
Or is this a "prove of concept" for people who don't have an in-built DSP and just a "stage" before you come up with a software solution? (You mentioned that in the other thread)
Xorit said:
Please correct me
The 7floor mod just re-routes and cuts some traces to control the in-build DSP directly and if i got it correct, people got full access to the DSP after.
You say that in the boot process the MCU polls it's hardware interfaces and if it detects the internal DSP it operates in "normal" mode.
Could this normal mode be modified to remove the config restriction and fully control the internal DSP? Or instead boot in "improved" mode?
// In my car (Opel Astra J) the HU is heavily mounted inside the dash and it's not fun to rip the whole thing apart every time.
Also I have a DVD drive installed and the space inside the silverbox is super limited due to that.
Or is this a "prove of concept" for people who don't have an in-built DSP and just a "stage" before you come up with a software solution? (You mentioned that in the other thread)
Click to expand...
Click to collapse
English is not native to me, so I apologize if I misunderstood you, but head units now have two options - with a sound processor and with a built-in DSP.
All the features of the sound processor are determined by the specific chip BD3702 / 37534/37033, etc, soldered on the HU mainboard. Since some of the audio presets are fixed in the MCU firmware, some do not like this sound and they want to customize it to their preferences. This can be achieved either by modifying the MCU firmware, or by direct control of the sound processor, for example, as in 7floor mod, but the audio capabilities are still low functional and are limited by the sound processor chip itself.
The possibilities of DSP for sound are very huge and diverse, but the Chinese sellers do not sell it separately for MTCD/E head units, so I suggested an alternative option by purchasing an affordable low-cost inexpensive DSP test board on Aliexpress and installing it inside the head unit to get a very improved sound, because all the software support has already been present and verified in the Android builds of versions from 6.0.1 to 8.0 and only need to connect the electrical circuits to the main board correctly.
I did it in practice and checked that it really works and it improves the sound very much, sorry, but if I did not answer your questions, please clarify them again for my understanding (my English is very pour)
cs-x(RU) said:
English is not native to me, so I apologize if I misunderstood you, but head units now have two options - with a sound processor and with a built-in DSP.
All the features of the sound processor are determined by the specific chip BD3702 / 37534/37033, etc, soldered on the HU mainboard. Since some of the audio presets are fixed in the MCU firmware, some do not like this sound and they want to customize it to their preferences. This can be achieved either by modifying the MCU firmware, or by direct control of the sound processor, for example, as in 7floor mod, but the audio capabilities are still low functional and are limited by the sound processor chip itself.
The possibilities of DSP for sound are very huge and diverse, but the Chinese sellers do not sell it separately for MTCD/E head units, so I suggested an alternative option by purchasing an affordable low-cost inexpensive DSP test board on Aliexpress and installing it inside the head unit to get a very improved sound, because all the software support has already been present and verified in the Android builds of versions from 6.0.1 to 8.0 and only need to connect the electrical circuits to the main board correctly.
I did it in practice and checked that it really works and it improves the sound very much, sorry, but if I did not answer your questions, please clarify them again for my understanding (my English is very pour)
Click to expand...
Click to collapse
Nah you got me completly right there and I fully understood what you wrote. (not a native english myself )
So basically this MOD provided by you is an alternative method of "super-improving" the sound with a standard car sound system (speaker connected to the radio directly).
This, because if you have a factory amp like bose preinstalled or you have already upgraded the sound system with a DSP/amp you don't want to have the audio processed in the HU, but rather have clean signals to your installed DSP in the car.
Let me shortcut:
version 1: add DSP board for standard sound system to be improved (THIS THREAD)
version 2: have full control of the standard sound processor already present to get rid of the MCU presets. (MY IDEA)
For me personally it would be super great to just have the 7floor mod in software. My factory amp does all the audio magic, but I need more control of the HU output and it would totally be enough to control the TDA7388 PDF file
This is my Witson seller MX HU W2-V5754
cs-x(RU) Could you share a picture of the installed ADAU1401/1701 chip in your unit, give us an idea what were looking at?, It all makes sense to me now.
Also in there a new amplifer.apk with the 15 band eq that you show in fig. 17 to fig. 20?
Octane70 said:
cs-x(RU) Could you share a picture of the installed ADAU1401/1701 chip in your unit, give us an idea what were looking at?, It all makes sense to me now.
Also in there a new amplifer.apk with the 15 band eq that you show in fig. 17 to fig. 20?
Click to expand...
Click to collapse
In the summer of 2017 I bought this DSP test board for experimentation and subsequent installation in my MTCC head unit, but a significant software change was needed, so I suspended these works before the New Year 2018, and put a test card in the garage.
In April 2018 I decided to go back to the experiments to connect the test board to the MTCE head unit, but for a long time I could not find the card in the garage and was able to find it only last week. Immediately my friend asked me to install this DSP test board in his head unit, so I lasted all last Saturday and checked it on his head unit, but did not do the photo, and on Sunday he installed in the car and now I can not take the photo. Therefore, I can only sketch and specify the soldering points on the main board, but I'm going to do the next modification with the sound switch and ordered another DSP test board on Aliexpress.
A new apk with the 15 band eq that shown in fig. 17 to fig. 20 already present in the original Chinese Android build versions from 6.0.1 to 8.0 for MTCE head units and do not need to add anything yourself, since to activate the improved equalizer mode, it is sufficient only that the MCU firmware detects a DSP chip on the I2C bus and sends the command to the Android device
Xorit said:
This, because if you have a factory amp like bose preinstalled or you have already upgraded the sound system with a DSP/amp you don't want to have the audio processed in the HU, but rather have clean signals to your installed DSP in the car.
For me personally it would be super great to just have the 7floor mod in software. My factory amp does all the audio magic, but I need more control of the HU output
Click to expand...
Click to collapse
I have plans to try to make a completely software solution similar to 7floor, but without soldering, but so far there is no time for such experiments, becouse need to debug everything well
For your case, can do it simply - set the zero frequency response and prevent it from changing, and only your external amplifier with DSP can control any frequency response (very small changes in the MCU firmware code needed and not need in Android build)
cs-x(RU) said:
I have plans to try to make a completely software solution similar to 7floor, but without soldering, but so far there is no time for such experiments, becouse need to debug everything well
For your case, can do it simply - set the zero frequency response and prevent it from changing, and only your external amplifier with DSP can control any frequency response (very small changes in the MCU firmware code needed and not need in Android build)
Click to expand...
Click to collapse
Would you maybe provide a version to test in the other thread? Would be happy to try!
No need to rush things tho!
Many thanks!
Will this mod work on an Intel Sofia mtcd unit? Thanks in advance
brickbeats said:
Will this mod work on an Intel Sofia mtcd unit? Thanks in advance
Click to expand...
Click to collapse
I do not know, because I do not have Intel Sofia and can not test -- tested only on Rockchip PX5 with Android 8.0 and on Rockchip PX3 with Android 7.1.2 and on Rockchip PX5 with Android 6.0.1, not tested on Rockchip PX3 with Android 5.1.1
Octane70 said:
cs-x(RU) Could you share a picture of the installed ADAU1401/1701 chip in your unit, give us an idea what were looking at?, It all makes sense to me now.
Click to expand...
Click to collapse
added wire connection (see fig.16) in the first post of the topic
P.S.
the chip of the sound processor can not be removed from the main board, but then you must unsolder its SDA and SCL pins (26 and 25 pin of the BD37033)
This looks very interesting. Out of interest is there a solution to get additional analogue audio? I use the aux input as well?
I use dab most of the time so could potentially do without fm if there was not an option to switch the analogue audio as well
Ben.suffolk said:
This looks very interesting. Out of interest is there a solution to get additional analogue audio? I use the aux input as well?
I use dab most of the time so could potentially do without fm if there was not an option to switch the analogue audio as well
Click to expand...
Click to collapse
in the current implementation there is one digital input for sounds from Android applications and one analog input for other sounds without a switch. Since I and my friends are listening to FM radio, I made the connection just for it. If you need another analog source, then instead of FM radio you can connect either AUX-input or DAB-radio according to your desire.
I ordered another same DSP test board on Aliexpress and in the next implementation I plan to add an analog audio switcher for the possibility of programmatically selecting any of the sound sources
cs-x(RU) said:
in the current implementation there is one digital input for sounds from Android applications and one analog input for other sounds without a switch. Since I and my friends are listening to FM radio, I made the connection just for it. If you need another analog source, then instead of FM radio you can connect either AUX-input or DAB-radio according to your desire.
I ordered another same DSP test board on Aliexpress and in the next implementation I plan to add an analog audio switcher for the possibility of programmatically selecting any of the sound sources
Click to expand...
Click to collapse
Ok great,
I assume that there must be a switcher built into the MTCE units with DSP, and I see your schematic for a switcher in the first post, but I will wait until you have figured out what it connects to so it works to switch the sources.
As it happens DAB is USB, so will be audio via the Android card (Digital), so I can use Aux and Digital, just meaning I don't have a fall back to FM if I loose DAB. Thats ok for the moment, and I'll upgrade to switched later.
Thanks for this mod.
Mind posting some pics of the board installed?
Thankyou so much for posting this, this is exactly what I have been looking for to improve sound quality of my unit. I have already ordered an ADAU1401 eval board.
I just wanted to confirm, if I add the ES7144LV as described, will I be able to control the sub channel selerately using the amp app on the unit without any additional modification?
Also, I am correct in thinking that if I make the correct electrical modifications the app will automatically identify the changes and I will not need to make any software changes?
Would it be possible to get a higher quality picture of where to connect the pins? I am finding the text hard to read in certain areas.
Thanks again!