HDMI output findings in CRESPO GIT? - Nexus S Q&A, Help & Troubleshooting

Been browsing the Crespo GIT searching for some info and found something interesting, It may not mean anything at all, here it is
The following is disabled in the libcamera Android.mk
"
28 #Enable the below code to show the video output (without GUI) on TV
29 #ifeq ($(BOARD_USES_HDMI), true)
30 #LOCAL_CFLAGS+=-DENABLE_HDMI_DISPLAY \
31 # -DBOARD_HDMI_STD=$(BOARD_HDMI_STD)
32 #
33 #LOCAL_C_INCLUDES += $(LOCAL_PATH)/../include
34 #LOCAL_SHARED_LIBRARIES+= libhdmi
35 #endif
"
Im nowhere near a dev or something but there's been some talk about TV-OUT, maybe someone with more insight can look into this.
[device/samsung/crespo.git]
http://android.git.kernel.org/?p=device/samsung/crespo.git;a=blob;f=libcamera/Android.mk;h=ebbd37b6e08d546f4ee075cc52e7339ebd57bd3c;hb=HEAD

it seems to me that HDMI output might be possible..

Related

TI FM Radio

Preface
Hi !
In my reading of various threads it's become apparent that there are MANY people who passionately
desire a "real FM radio" app. Not all of us live in data dense areas, or can afford the costs of
streaming audio. And not all of us have given up on RF broadcasts, either due to our tastes,
local available programming, lack of commercials or whatever. And many of us very much desire
the ability to transmit on the FM band for various reasons.
I want this thread to deal with TI FM radios on all devices that contain TI chips. My observation is that
there is a great deal of commonality in the TI chips supporting FM in the last 4-6 years.
I don't generally want to deal with the Broadcom FM chips here, but the audio routing issues will be similar.
I also WOULD like to create a list of devices containing the FM chips they use, so people can more quickly
determine their FM chip type.
To non-devs who want FM yesterday: Yes, I know. No need to post about it. I'll do my best to create some
kind of app ASAP, but first some fundamentals need to be figured out. I'd think and hope that others will also
be able to create FM radio apps from the info here and elsewhere.
This thread is in a developer forum, and as such it would be preferable to limit discussion to technical
aspects, preferrably by those who are developers or thereabouts in terms of technical skills. It's hard
work sometimes to slog through near 100 page threads such as the one for the Nexus One FM radio.
If you have simple questions, comments, requests, corrections or additions to this, please consider
PMing me directly and I'll do my best to incorporate that into the thread, giving acknowledgement
if you so desire.
That said, I've posted FM Receiver and FM Transmitter scripts below. If you feel you have a reasonable
capability to try these scripts on your device, please do, and report here or via PM on success or failure
if you might be among the first few to try these on your device/model.
I will try to keep these first posts updated with the latest information, so hopefully you won't need to post
questions about whether or not your device works by referring to the "Devices" post.
---------------------
Introduction
I've enabled the FM radio functions on my HTC Legend. It is also known to work on HTC Tattoo.
Scouring the web looking for the magic incantations to enable FM audio I'm finding myself overwhelmed with all the things I don't know.
Much of the information needed is kept under wraps by TI and their customers. To get TI's information requires signing an NDA,
and perhaps other legal documents. Signing such an NDA limits how much you can say publicly, and I'd prefer to not be under
such constraints. I'm not even sure if an NDA would be sufficient for a person not employed by TI or a TI customer.
Thus this thread, to share with you the information I've found, and to ask for your help in correcting it or adding to it.
If there is any similar thread on any site, that is TI specific, but not device model specific, please let me know.
I've seen and read through a number of mega-threads here and elsewhere that are device specific, but much of the information
contained therein is useful for all devices with TI FM chips.
The chips in question are usually named: WL1271, WL1273, WL1281 and WL1283. The first two have WF + BT + FM and the latter two add GPS.
TI also calls these WiLink or BlueLink 5.0, 6.0 and 7.0, as well as BRF6300, BRF6350 and BL6450.
TI also sells various evaluation boards carrying these chips, and some TI partners produce modules, sometimes with similar numbers.
AFAICT there is no FM functionality in some of the predecessor chips such as the WiLink 4.0 chips: BRF6100 (WL1251) & BRF6150 (WL1253).
Just so you better know my knowledge level:
- I'm new to Android, smartphones and post 1995 PDAs, although I've read some on these subjects over the years.
I'm diving straight in to learn as much as I can as quickly as I can. I'm not currently employed but hope to
transition myself to what appears to be the rapidly expanding Android world.
- I've worked in software development on "semi-embedded" Linux VOIP and security appliances since 1997, with a good bit
of low level kernel/driver stuff. Not much low level stuff recently, mostly daemons and command line utilities.
At home I've recently worked on a home Asterisk VOIP box and MythTv and XBMC based HTPCs. I also manage the 5 Ubuntu
PCs our family uses, as well as one lonely 5 year old HP WinXp tablet.
- My background in electronics and computing goes back to the mid 1970's with 8080 and SCMP. I designed and built a variety
of computer, electronics and even RF devices in those days, and can still wield a mean soldering pencil when needed.
-----------------------------------------------------------------------------------------------------------------------------------------------------
Here is some information about which chips being discussed here. Note that the terms BlueLink and WiLink can be somewhat confusing as some chips are both.
TI's Wireless Connectivity Solutions page:
http://focus.ti.com/general/docs/wt...lateId=6123&navigationId=12493&contentId=4637
Note at left that GPS (NaviLink), Bluetooth (BlueLink) and Wireless (WiLink) are represented.
FM radio seems to be the neglected "step child" that gets little mention or notice.
It's a small add-on feature that just happens to come along with Bluetooth sometimes, if at all.
Generally, the WiFi, BT, FM and GPS components in these multi-function chips tend to be independent of each other.
They can be powered up or down individually and usually have seperate control paths. They are called "IP"s, eg.
the WiFi IP or BT IP. I haven't yet determined what IP stands for, LOL.
FM is the exception though; it seems to piggyback on the BT IP. To power up FM you must first power up BT
(although some doc implied BT can then be powered down). FM has it's own I2C control path, but that is usually
not used, in favor of sharing the BT HCI interface.
Some docs I've read discourage the use of FM. Perhaps it can cause issues ?
Note that some of these chips may indicate support for Wireless-N, but that doesn't mean the device manufacturer
enabled it in their stack etc. It might be possible to enable N, perhaps with different Wireless firmware or init
scripts. While an interesting prospect, despite the expectation of vastly increased battery consumption, I don't
want to get into the Wireless issues, except as they might impact FM.
------------------------------------------------------------------------
Predecessor single function products upon which the later integrated products are based:
2004: BRF6100 / BRF6150 = BT only
http://focus.ti.com/pdfs/wtbu/TI_brf6100_6150.pdf
2005: WiLink 4.0 mWLAN (WL1251 and WL1253) = WF only
WL1251 = 802.11 b/g/e/i/d/k
WL1253 = 802.11 a/b/g/e/i/d/k/h/j
http://focus.ti.com/pdfs/wtbu/wl1251_1253_prod_bulletin.pdf
2005: BlueLink 5.0 BRF6300 = BT only
http://focus.ti.com/pdfs/wtbu/ti_bluelink_5_brf6300.pdf
------------------------------------------------------------------------
Combined products. All seem to support FM Rx and Tx:
2007: BlueLink 6.0 BRF6350 = BT + FM
http://focus.ti.com/pdfs/wtbu/ti_bluelink_6_brf6350.pdf
200?: WiLink 5.0 = WiLink 4.0 mWLAN + BlueLink 6.0 = WF + BT + FM
http://focus.ti.com/general/docs/wt...ateId=6123&navigationId=12661&contentId=15402
2010: WiLink 6.0 = WF + BT + FM (Bluetooth (2.1?) Low Energy Specification 4.0 + EDR)
WL1271 = 802.11 b/g/n (2.4 GHz)
WL1273 = 802.11 a/b/g/n (2.4 & 5 GHz)
http://www.ti.com/lit/swmt013
2010.1: BlueLink / WiLink 7.0 BL6450 = BT 2.1 (+EDR) + FM (No WF)
http://focus.ti.com/pdfs/wtbu/BlueLink7_BL6450_swmt014d.pdf
2010.2: WiLink 7.0 = WF + BT + FM + GPS
WL1281 / WL1283 = 802.11 a/b/g/n + BT 3.0 + FM + GPS 3GPP
http://focus.ti.com/pdfs/wtbu/WiLink7_WL1283_swmt016.pdf
Sources
Sources
The source of information I've found include:
- Documents from TI or customers. Usually these contain limited information.
- Source code from TI, TI's customers or other parties, including ROM builders.
- Threads/Posts on forums including this one, as well as TI support forums.
- Miscellaneous random sources such as IRC logs for HTC-Linux.
The most comprehensive and easily useful sources I've found so far are the source codes
for a Linux WL1271 driver being produced by a Nokia employee, and somewhat similar
source codes from TI.
The "Texas Instruments WL1273 FM radio" Linux driver is under development by Matti J. Aaltonen
of Nokia. I believe the Nokia N900 uses a TI chip under Maemo->Meego, and perhaps other Nokia
devices too. Various patches and discussions are underway, and can be googled, and parts of it
are slowly appearing in the latest kernel source. If you want to see the latest, the only easy way
seems to be downloading one of the latest kernels at https://lkml.org/ .
There's an ancient first version from and some discussion from April here:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/18449
I used http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.37.tar.bz2 and
http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.37.bz2 but I see there's a 2.6.38 RC5
there as well.
Finding and downloading TI code has been a pain, but they have a lot there.
TI WL 128x FM V4L2 driver:
There's a git repository for what appears to be an alternate V4L driver at http://dev.omapzoom.org/pub/scm/manju/L24x-btfm.git
Some discussion: http://www.spinics.net/lists/linux-media/msg28310.html
I'm not sure why there appear to be two efforts underway to create FM V4L2 drivers, the one by Nokia and the other by TI.
This appears to be source for TI's fmapp test utility and fm_stack library in a form that can be viewed by browser:
http://git.omapzoom.org/?p=platform...2a9dcca2dced00e724a2eb1dec578152f5beb;hb=HEAD
I managed to download the older 0.12 version of fmapp and fm_stack source code from somewhere, but can't recall where.
The "fmapp" utility has a LOT of functionality for testing just about every exposed FM feature, including RDS.
There is also a recently released "Android Froyo DevKit V2" at:
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_tii/TI_Android_DevKit/02_00_00/index_FDS.html
You have to sign in for that but it should be easy to create an account. I already had one via a previous TI adventure.
The K2 BM6350 module PDFs have some further info:
http://www.ktwo.co.in/index.php?option=com_content&task=view&id=178&Itemid=465
http://www.ktwo.co.in/pdf/K2BM6350_Datasheet.pdf
http://www.ktwo.co.in/pdf/K2-BM6350 StarterKit UserManual.pdf
Forum threads:
[TUTORIAL] Reverse engineering HTC FM Radio for noobs (on EVO 4G)
http://forum.xda-developers.com/showthread.php?t=725870
Decompiled HTC Radio app
http://martinmarinov.info/HTCRadio.rar
Some words about bluetooth....
http://forum.xda-developers.com/showthread.php?t=816019
[Q] FM Radio app, Broadcom BCM4329 chipset
http://forum.xda-developers.com/showthread.php?t=837691
[THINK TANK] Enabling the Nexus One FM radio ...
http://forum.xda-developers.com/showthread.php?t=707404
FM Radio on 2.x ROMs - An Idea
http://forum.xda-developers.com/showthread.php?p=11366697
Devices
Devices
List of devices and FM chips. At this time I'd like to limit this to Android devices, but might consider others.
Would be useful to list limitations here. For example, some Motorola Droid owners were understandably disheartened,
after much work, to find they had no Fm Rx antenna connection, and could not make one without opening up the cans, etc.
on the board. So technically they had Fm Rx, practically, they had none.
Also, some boards may have no Tx antenna, but might possibly work within a few inches of an external FM receiver antenna.
--------------------------------------------------------------------------------
TI FM devices:
--------------------------------------------------------------------------------
HTC Legend: WL1273
HTC Tattoo/Click WL1271?
HTC Dream/Google G1 WL1271?
HTC Sapphire/Hero BRF6300 = WL1271?
HTC Diamond/Raphael/Blackstone BRF6350 (Windows Mobile?)
Motorola Droid WL1271
Motorola Backflip WL1271?
Motorola Milestone WL1273?
Nokia N900 WL1273? (Maemo?)
Barnes & Noble Nook Color WL1273?
--------------------------------------------------------------------------------
Broadcom FM devices:
--------------------------------------------------------------------------------
HTC Nexus One: 43xx
--------------------------------------------------------------------------------
FM Apps and APIs
FM Apps and APIs
Many handset manufacturers provide their own proprietary FM radio apps. Some people have managed to get an
FM radio app meant for another device working on theirs. Most, however, have library or other issues with a foreign app.
AFAICT, Google has not released any sanctioned FM radio API, nor do they intend to. I'd guess FM radio likely
won't bring much revenue to Google or the carriers.
In an ideal world, Android apps would use the same API as on Linux: the "Video For Linux version Two" aka V4L2.
This API makes use of a /dev/radioX device. This is somewhat similar to the /dev/videoX devices that some devices
appear to support for cameras.
If the V4L2 API was available on Android, Android FM radio apps could then be ported more easily from Linux.
Alas, there are relatively few Linux radio apps. GnomeRadio hasn't been touched in over 2 years and Gnome
doesn't run on Android anyway of course. Some command line apps could be ported, but that doesn't make for
an Android app.
So thus far, the defacto "API" for FM radio on Android has been vendor specific commands over HCI, the
Bluetooth interface. This is more or less similar to the way it can be done via I2C, but apparently
most FM chips are not wired via 12C; they use the existing HCI UART. Once again, FM radio is the
poor neglected "step-child".
One advantage of using HCI is that no new kernel drivers are needed. A disadvantage is that some mediation
driver would be required to use bluetooth and FM at the same time; the only alternative being drivers for
both smashed together, but that would be an Android specific hack and is not a good idea.
I've noted that one individual created an API spec and an app for Windows devices a few years back.
I believe it was called GFMRadio and XFMRadio or similar. That project was apparently abandoned.
MIUI released a GPL licensed FM app for some phones based on broadcom chips; HTC Desire and Nexus One.
The source code contains the string "/dev/radio", but AFAICT it doesn't appear to actually use V4L API.
It speaks directly to the broadcom FM chip via HCI.
Since MIUI source is GPL and available it could be used as a base for a TI, or TI and broadcom specific app.
In theory patches could be submitted to MIUI but I'm not sure they are open to that and the language barrier
from English to Chinese and back may be difficult.
Some interesting posts on MIUI here: http://forum.xda-developers.com/showthread.php?t=837691
http://www.miui.com/thread-1687-1-1.html
Using hcitool commands, or similar, one could write a radio app in bash or Perl etc. LOL.
TI has an "fmapp" command line testing utility that relies on libfm_stack.so .
This app won't run on my Legend because it depends on snd_ctl_* APIs in libaudio.
"strings libfm_stack.so" produces lots of interesting detail and embedded BTS scripts.
The source code I've found for TI fmapp, and it's FM stack library does not seem to have all
the functionality I've seen in the binary fmapp I found. So they may have stripped much code
for the publicly released source code.
Audio routing
Audio routing
On HTC phones, FM analog audio routing can be achieved by:
# Default
adb shell 'echo "disable" > /sys/class/htc_accessory/fm/flag'
# Headset
adb shell 'echo "fm_headset" > /sys/class/htc_accessory/fm/flag'
# Speaker
adb shell 'echo "fm_speaker" > /sys/class/htc_accessory/fm/flag'
# View
adb shell cat /sys/class/htc_accessory/fm/flag
Firmware, TI BTS file, HCI and I2S/I2C issues, tools etc.
Firmware, TI BTS file, HCI and I2S/I2C issues, tools etc.
The Nokia V4L driver loads radio-wl1273-fw.bin, although the code does indicate it may not be necessary.
I can't find this firmware file anywhere. As with many other firmwares, it may simply be a known firmware
file renamed. This has been noted with other firmware files for the TI radio.
Information on firmware for these TI chips seems scattered and incomplete. Same with the BTS Bluetooth script files
which are usually important for accessing the FM functionality.
I think one of the reasons for this lack of information is that most parties do not want us messing with the available functionality.
- Device manufacturers do not want their devices used in violation of FCC or other regulatory body rules.
For example, FM transmission at higher power levels or improper frequencies. Also RDS transmissions with bogus data.
- Device manufacturers and carriers want us to buy newer or more expensive products for additional functionality.
They also would rather we use voice minutes instead of FM "walkie talkies".
- Google and carriers want us to stream music via data rather than pick it up for free from over the air.
...
Where do I find utilities to dump/decode/encode BTS files ?
....
HCI is usually used to access FM functions, but I2C might be usable on some devices.
...
fm_rx_init_6350.1.bts
fm_rx_init_6350.2.bts
fm_rx_init_6450.1.bts
fm_tx_init_6450.1.bts
fmc_init_6350.1.bts
fmc_init_6350.2.bts
fmc_init_6450.1.bts
tiinit_0.0.0.bts
tiinit_5.2.34.bts
tiinit_5.3.53.bts
tiinit_6.1.24.bts
tiinit_6.2.31.bts
HCI/I2C Commands
HCI/I2C Commands
Most of this information is gleaned from:
- The Linux WL1271 FM Radio source code written by a Nokia employee.
- TI source code for fmapp/fmstack, etc.
Various forum posts also make it clear there is a bewildering array of commands etc. not referenced in the source codes above.
Some information can also be retrieved by looking inside BTS, firmware, app, utility and library etc. files.
...
Vendor Specific Opcodes for the various FM-related commands over HCI. (_FmcCoreTransportFmCOmmands)
_FMC_CMD_I2C_FM_READ 0x0133
_FMC_CMD_FM_I2C_FM_READ_HW_REG 0x0134
_FMC_CMD_I2C_FM_WRITE 0x0135
?0x136
_FMC_CMD_FM_POWER_MODE 0x0137
?0x138
_FMC_CMD_FM_SET_AUDIO_PATH 0x0139
_FMC_CMD_FM_CHANGE_I2C_ADDR 0x013A
Format of an HCI READ/WRITE command to FM over I2C is:
HCI Header:
- HCI Packet Type: (Added internally by the HCI Transport Layer)
- HCI Opcode: 2 bytes (LSB, MSB - LE)
- HCI Parameters Total Len: 1 byte (total length of all subsequent fields)
HCI Parameters:
- FM Opcode: 1 byte
- FM Parameters Len: 2 bytes (LSB, MSB - LE)
- FM Cmd Parameter Value: N bytes
For "simple" (non-RDS) read commands "FM Parameters Len" is always "2, 0" (2).
...
HCI/I2C Commands/Opcodes, registers, values
HCI/I2C Opcodes, registers, values.
Most of this information is gleaned from:
- The Linux WL1271 FM Radio source code written by a Nokia employee.
- TI source code for fmapp/fmstack, etc.
---------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
The most important "commands":
----------
0x137 FM_POWER_MODE: FM Core power up (last byte 0=down, 1=up)
Usage:
# FM_POWER_MODE: FM Core power up
adb shell hcitool cmd 0x3f 0x137 0x01 0x01
# FM_POWER_MODE: FM Core power down
adb shell hcitool cmd 0x3f 0x137 0x01 0x00
----------
0x133 FM_READ
Examples:
# FM_READ: POWER (Register 0x20)
adb shell hcitool cmd 0x3f 0x133 0x20 0x02 0x00
# FM_READ: RSSI (Register 0x01)
adb shell hcitool cmd 0x3f 0x133 0x01 0x02 0x00
----------
0x135 FM_WRITE
Examples:
# FM WRITE: POWER: Rx on (This actually seems to be "audio enable" !
adb shell hcitool cmd 0x3f 0x135 0x20 0x02 0x00 0x00 0x02
# FM WRITE: POWER: Rx on plus RDS
adb shell hcitool cmd 0x3f 0x135 0x20 0x02 0x00 0x00 0x03
----------
------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
The "registers": (some call them opcodes, but they seem to be registers IMO)
0x00 0 WL1273_STEREO_GET FMC_FW_OPCODE_RX_STEREO_GET
0 FM_STEREO_MODE mono (or no signal ?)
1 FM_MONO_MODE stereo signal
0x01 1 WL1273_RSSI_LVL_GET FMC_FW_OPCODE_RX_RSSI_LEVEL_GET
(-128) SCHAR_MIN FM_RX_RSSI_THRESHOLD_MIN See also WL1273_SEARCH_LVL_SET
127 SCHAR_MAX FM_RX_RSSI_THRESHOLD_MAX
0x02 2 WL1273_IF_COUNT_GET FMC_FW_OPCODE_RX_IF_COUNT_GET
# changes: 1, 2, 3, ff, fe, 0
0x03 3 WL1273_FLAG_GET FMC_FW_OPCODE_CMN_FLAG_GET
? = Event masks ?
#define FM_FR_EVENT (1 << 0)
#define FM_BL_EVENT (1 << 1)
#define FM_RDS_EVENT (1 << 2)
#define FM_BBLK_EVENT (1 << 3)
#define FM_LSYNC_EVENT (1 << 4)
#define FM_LEV_EVENT (1 << 5)
#define FM_IFFR_EVENT (1 << 6)
#define FM_PI_EVENT (1 << 7)
#define FM_PD_EVENT (1 << 8)
#define FM_STIC_EVENT (1 << 9)
#define FM_MAL_EVENT (1 << 10)
#define FM_POW_ENB_EVENT (1 << 11)
0x04 4 WL1273_RDS_SYNC_GET FMC_FW_OPCODE_RX_RDS_SYNC_GET
0 WL1273_RDS_NOT_SYNCHRONIZED
1 WL1273_RDS_SYNCHRONIZED
0x05 5 WL1273_RDS_DATA_GET FMC_FW_OPCODE_RX_RDS_DATA_GET
64 FMC_FW_RX_RDS_THRESHOLD (*1 or *3) See also FMC_FW_OPCODE_RX_RDS_MEM_SET_GET
85 FMC_FW_RX_RDS_THRESHOLD_MAX Used as FMC_FW_RX_RDS_THRESHOLD_MAX*RDS_BLOCK_SIZE for mem size.
? Set to 3e 16 ? (15894)
0x06 ? Set to 1 ?
------------------------------------------------------------------------------------------
Codes 6-9 missing
------------------------------------------------------------------------------------------
0x0a 10 WL1273_FREQ_SET FMC_FW_OPCODE_RX_FREQ_SET_GET
base + freq / 50Khz
0 0x000 87500 WL1273_BAND_OTHER_LOW
410 0x19a 108000 WL1273_BAND_OTHER_HIGH
0 0x000 76000 WL1273_BAND_JAPAN_LOW
280 0x118 90000 WL1273_BAND_JAPAN_HIGH
? #define FM_UNDEFINED_FREQ 0xFFFFFFFF
0x0b 11 WL1273_AF_FREQ_SET FMC_FW_OPCODE_RX_AF_FREQ_SET_GET
0x0c 12 WL1273_MOST_MODE_SET FMC_FW_OPCODE_RX_MOST_MODE_SET_GET ! MOST = "MOno/STereo"
0 WL1273_RX_STEREO Stereo according to blend
1 WL1273_RX_MONO Force mono output
0 FM_STEREO_MODE
1 FM_MONO_MODE
0x0d 13 WL1273_MOST_BLEND_SET FMC_FW_OPCODE_RX_MOST_BLEND_SET_GET
0 Switched blend & hysteresis
1 FM_STEREO_SOFT_BLEND Soft blend
Now set to 1 = Soft blend
0x0e 14 WL1273_DEMPH_MODE_SET FMC_FW_OPCODE_RX_DEMPH_MODE_SET_GET
0 FM_RX_EMPHASIS_FILTER_50_USEC
1 FM_RX_EMPHASIS_FILTER_75_USEC
0x0f 15 WL1273_SEARCH_LVL_SET FMC_FW_OPCODE_RX_SEARCH_LVL_SET_GET
7 WL1273_DEFAULT_SEEK_LEVEL
(-128) SCHAR_MIN See also WL1273_RSSI_LVL_GET
127 SCHAR_MAX
0x10 16 WL1273_BAND_SET FMC_FW_OPCODE_RX_BAND_SET_GET
0 WL1273_BAND_OTHER 87.5-108 Mhz North America, Europe, generally rest of world besides Japan
1 WL1273_BAND_JAPAN 76-90 Mhz Japan (perhaps soon US also)
0x11 17 WL1273_MUTE_STATUS_SET FMC_FW_OPCODE_RX_MUTE_STATUS_SET_GET
0 ........ FMC_FW_RX_MUTE_UNMUTE_MODE
bit0 0x01 WL1273_MUTE_SOFT_ENABLE FMC_FW_RX_MUTE_RF_DEP_MODE
bit1 0x02 WL1273_MUTE_AC FMC_FW_RX_MUTE_AC_MUTE_MODE
bit2 0x04 WL1273_MUTE_HARD_LEFT FMC_FW_RX_MUTE_HARD_MUTE_LEFT_MODE
bit3 0x08 WL1273_MUTE_HARD_RIGHT FMC_FW_RX_MUTE_HARD_MUTE_RIGHT_MODE
bit4 0x10 WL1273_MUTE_SOFT_FORCE FMC_FW_RX_MUTE_SOFT_MUTE_FORCE_MODE
Set to one of these:
2 0x02 FM_RX_AC_MUTE_MODE Mute On But enable soft/attenuate ?
0 0x00 FM_RX_UNMUTE_MODE Mute Off
16 0x10 FM_RX_SOFT_MUTE_FORCE_MODE Mute Attenuate
Then optionally logically "OR" ('|') this:
bit0 0x01 FM_RX_RF_DEP_MODE
Optional bits ?
bit2 0x04 FM_RX_HARD_MUTE_LEFT_MODE
bit3 0x08 FM_RX_HARD_MUTE_RIGHT_MODE
? #define FM_MUTE_OFF 0
? #define FM_MUTE_ON 1
? #define FM_MUTE_ATTENUATE 2
? #define FM_RX_RF_DEPENDENT_MUTE_ON 1
? #define FM_RX_RF_DEPENDENT_MUTE_OFF 0
0x12 18 WL1273_RDS_PAUSE_LVL_SET FMC_FW_OPCODE_RX_RDS_PAUSE_LVL_SET_GET
? Set to 5 ?
0x13 19 WL1273_RDS_PAUSE_DUR_SET FMC_FW_OPCODE_RX_RDS_PAUSE_DUR_SET_GET
? Set to 0x0c = 12
0x14 20 WL1273_RDS_MEM_SET FMC_FW_OPCODE_RX_RDS_MEM_SET_GET
64 FMC_FW_RX_RDS_THRESHOLD (*1 or *3) See also FMC_FW_OPCODE_RX_RDS_DATA_GET
85 FMC_FW_RX_RDS_THRESHOLD_MAX Used as FMC_FW_RX_RDS_THRESHOLD_MAX*RDS_BLOCK_SIZE for mem size.
Set to 0x55 = 85 = Max Thresh
0x15 21 WL1273_RDS_BLK_B_SET FMC_FW_OPCODE_RX_RDS_BLK_B_SET_GET
0x16 22 WL1273_RDS_MSK_B_SET FMC_FW_OPCODE_RX_RDS_MSK_B_SET_GET
0x17 23 WL1273_RDS_PI_MASK_SET FMC_FW_OPCODE_RX_RDS_PI_MASK_SET_GET
0x18 24 WL1273_RDS_PI_SET FMC_FW_OPCODE_RX_RDS_PI_SET_GET
0x19 25 WL1273_RDS_SYSTEM_SET FMC_FW_OPCODE_RX_RDS_SYSTEM_SET_GET
0 FM_RDS_SYSTEM_RDS
1 FM_RDS_SYSTEM_RBDS
0x1a 26 WL1273_INT_MASK_SET FMC_FW_OPCODE_CMN_INT_MASK_SET_GET
0x1b 27 WL1273_SEARCH_DIR_SET FMC_FW_OPCODE_RX_SEARCH_DIR_SET_GET
0 FM_SEARCH_DIRECTION_DOWN
1 FM_SEARCH_DIRECTION_UP
0x1c 28 WL1273_VOLUME_SET FMC_FW_OPCODE_RX_VOLUME_SET_GET
880 0x370 ........ FMC_FW_RX_FM_GAIN_STEP ? 35 steps ?
0 0x00 ........ FMC_FW_RX_FM_VOLUMN_MIN
30904 0x78b8 WL1273_DEFAULT_VOLUME FMC_FW_RX_FM_VOLUMN_INITIAL_VALUE
61808 0xf170 ........ FMC_FW_RX_FM_VOLUMN_MAX
65535 0xffff WL1273_MAX_VOLUME ........
- #define FM_RX_VOLUME_MIN 0
? #define FM_RX_VOLUME_MAX 70
? #define FM_RX_VOLUME_GAIN_STEP 0x370
0x1d 29 WL1273_AUDIO_ENABLE FMC_FW_OPCODE_RX_AUDIO_ENABLE_SET_GET
bit0 0x01 WL1273_AUDIO_ENABLE_I2S FMC_FW_RX_FM_AUDIO_ENABLE_I2S
bit1 0x02 WL1273_AUDIO_ENABLE_ANALOG FMC_FW_RX_FM_AUDIO_ENABLE_ANALOG
bit0|1 0x03 ........ FMC_FW_RX_FM_AUDIO_ENABLE_I2S_AND_ANALOG
0 ........ FMC_FW_RX_FM_AUDIO_ENABLE_DISABLE
0x1e 30 WL1273_PCM_MODE_SET FMC_FW_OPCODE_CMN_I2S_CLOCK_CONFIG_SET_GET
0 0x00 WL1273_PCM_DEF_MODE ? I2S protocol, left channel first, data width 16 bits
0x1f 31 WL1273_I2S_MODE_CONFIG_SET FMC_FW_OPCODE_CMN_I2S_MODE_CONFIG_SET_GET
0x0145= WL1273_IS2_RATE_48K(0) | IS2_TRI_OPT(0) | IS2_SDOWS_RF(0x0100) |
IS2_SLAVEW(0x0040) | IS2_FORMAT_STD(0) | IS2_WIDTH_50(0x0005)
0 0x0 WL1273_IS2_WIDTH_32
1 0x1 WL1273_IS2_WIDTH_40
2 0x2 WL1273_IS2_WIDTH_22_23
3 0x3 WL1273_IS2_WIDTH_23_22
4 0x4 WL1273_IS2_WIDTH_48
5 0x5 WL1273_IS2_WIDTH_50
6 0x6 WL1273_IS2_WIDTH_60
7 0x7 WL1273_IS2_WIDTH_64
8 0x8 WL1273_IS2_WIDTH_80
9 0x9 WL1273_IS2_WIDTH_96
10 0xa WL1273_IS2_WIDTH_128
bits0-3 0xf WL1273_IS2_WIDTH 0xf Mask
........
0 0x00 WL1273_IS2_FORMAT_STD (0x0 << 4)
16 0x10 WL1273_IS2_FORMAT_LEFT (0x1 << 4)
32 0x20 WL1273_IS2_FORMAT_RIGHT (0x2 << 4)
48 0x30 WL1273_IS2_FORMAT_USER (0x3 << 4)
........
0 0x00 WL1273_IS2_MASTER (0x0 << 6)
64 0x40 WL1273_IS2_SLAVEW (0x1 << 6)
........
0 0x00 WL1273_IS2_TRI_AFTER_SENDING (0x0 << 7)
128 0x80 WL1273_IS2_TRI_ALWAYS_ACTIVE (0x1 << 7)
........
0 0x00 WL1273_IS2_SDOWS_RR (0x0 << 8)
256 0x100 WL1273_IS2_SDOWS_RF (0x1 << 8)
512 0x200 WL1273_IS2_SDOWS_FR (0x2 << 8)
768 0x300 WL1273_IS2_SDOWS_FF (0x3 << 8)
........
0 0x00 WL1273_IS2_TRI_OPT (0x0 << 10)
1024 0x400 WL1273_IS2_TRI_ALWAYS (0x1 << 10)
........
0 0x00 WL1273_IS2_RATE_48K (0x0 << 12)
4096 0x1000 WL1273_IS2_RATE_44_1K (0x1 << 12)
8192 0x2000 WL1273_IS2_RATE_32K (0x2 << 12)
16384 0x4000 WL1273_IS2_RATE_22_05K (0x4 << 12) ?! No 0x3, 0x6-0x7, 0xb-0xe ?
20480 0x5000 WL1273_IS2_RATE_16K (0x5 << 12)
32768 0x8000 WL1273_IS2_RATE_12K (0x8 << 12)
36864 0x9000 WL1273_IS2_RATE_11_025 (0x9 << 12)
40960 0xa000 WL1273_IS2_RATE_8K (0xa << 12)
61440 0xf000 WL1273_IS2_RATE (0xf << 12) Mask
........
0 WL1273_I2S_DEF_MODE WL1273_IS2_WIDTH_32| WL1273_IS2_FORMAT_STD| WL1273_IS2_MASTER| WL1273_IS2_TRI_AFTER_SENDING|
WL1273_IS2_SDOWS_RR| WL1273_IS2_TRI_OPT| WL1273_IS2_RATE_48K
0x20 32 WL1273_POWER_SET FMC_FW_OPCODE_RX_POWER_SET_GET
0 WL1273_POWER_SET_OFF FMC_FW_RX_POWER_SET_FM_AND_RDS_OFF
! 0 just seems to mute output. RSSI still responds and all registers remain set.
bit0 0x01 WL1273_POWER_SET_FM FMC_FW_RX_POWER_SET_FM_ON_RDS_OFF
bit1 0x02 WL1273_POWER_SET_RDS ........
bit0|1 0x03 ........ FMC_FW_RX_POWER_SET_FM_AND_RDS_ON
bit4 0x10 WL1273_POWER_SET_RETENTION ........
0x21 33 WL1273_INTX_CONFIG_SET FMC_FW_OPCODE_CMN_INTX_CONFIG_SET_GET
0x22 34 WL1273_PULL_EN_SET FMC_FW_OPCODE_CMN_PULL_EN_SET_GET
? Set to 0xff = 255 ?
0x23 35 WL1273_HILO_SET FMC_FW_OPCODE_RX_HILO_SET_GET
0 0x0 FM_RX_IFFREQ_TO_HI_SIDE
1 0x1 FM_RX_IFFREQ_TO_LO_SIDE
2 0x2 FM_RX_IFFREQ_HILO_AUTOMATIC
Set to 1 = FM_RX_IFFREQ_TO_LO_SIDE
0x24 36 WL1273_SWITCH2FREF FMC_FW_OPCODE_CMN_SWITCH_2_FREF_SET
0x25 37 WL1273_FREQ_DRIFT_REPORT FMC_FW_OPCODE_CMN_FREQ_DRIFT_REPORT_SET TI fmc_fw_defs.h error defines as 0x24
0x28 40 WL1273_PCE_GET FMC_FW_OPCODE_CMN_PCE_GET
Set to 0x0f = 15
0x29 41 WL1273_FIRM_VER_GET FMC_FW_OPCODE_CMN_FIRM_VER_GET
Set to 2
0x2a 42 WL1273_ASIC_VER_GET FMC_FW_OPCODE_CMN_ASIC_VER_GET
Set to 2
0x2b 43 WL1273_ASIC_ID_GET FMC_FW_OPCODE_CMN_ASIC_ID_GET
Set to 0x1273 = 4723
0x2c 44 WL1273_MAN_ID_GET FMC_FW_OPCODE_CMN_MAN_ID_GET
Set to 0x17 = 23
0x2d 45 WL1273_TUNER_MODE_SET FMC_FW_OPCODE_RX_TUNER_MODE_SET
0 TUNER_MODE_STOP_SEARCH FMC_FW_RX_TUNER_MODE_STOP_SEARCH
1 TUNER_MODE_PRESET FMC_FW_RX_TUNER_MODE_PRESET_MODE
2 TUNER_MODE_AUTO_SEEK FMC_FW_RX_TUNER_MODE_AUTO_SEARCH_MODE (AUTONOMOUS)
3 TUNER_MODE_AF FMC_FW_RX_TUNER_MODE_ALTER_FREQ_JUMP
4 TUNER_MODE_AUTO_SEEK_PI ........
5 TUNER_MODE_AUTO_SEEK_BULK ........
0x2e 46 WL1273_STOP_SEARCH FMC_FW_OPCODE_RX_STOP_SEARCH
0x2f 47 WL1273_RDS_CNTRL_SET FMC_FW_OPCODE_RX_RDS_CNTRL_SET
1 FMC_FW_RX_RDS_FLUSH_FIFO
------------------------------------------------------------------------------------------
Codes 48-51 (0x30-0x33) missing
------------------------------------------------------------------------------------------
0x32 ? Set to 0xC000 = 49152
------------------------------------------------------------------------------------------
0x34 52 WL1273_SOC_INT_TRIGGER
------------------------------------------------------------------------------------------
Code 53 (0x35) missing
Code 54 (0x36) and up are mostly TX, except:
0x57 87 WL1273_RX_ANTENNA_SELECT ........
and the common/CMN values 100-102, 254, 255
------------------------------------------------------------------------------------------
0x36 54 WL1273_TX_AUDIO_INPUT_LEVEL_RANGE_SET
0x37 55 WL1273_CHANL_SET FMC_FW_OPCODE_TX_CHANL_SET_GET
freq / 10Khz
7600 0x1db0 76000 WL1273_BAND_TX_LOW
10800 0x2a30 108000 WL1273_BAND_TX_HIGH
0x38 56 WL1273_SCAN_SPACING_SET FMC_FW_OPCODE_TX_CHANL_BW_SET_GET
1 WL1273_SPACING_50kHz FMC_FW_TX_CHANNEL_BW_50_KHZ
2 WL1273_SPACING_100kHz FMC_FW_TX_CHANNEL_BW_100_KHZ
4 WL1273_SPACING_200kHz FMC_FW_TX_CHANNEL_BW_200_KHZ
Set to 4 = 200 KHz
1 0x1 FM_CHANNEL_SPACING_50KHZ
2 0x2 FM_CHANNEL_SPACING_100KHZ
4 0x4 FM_CHANNEL_SPACING_200KHZ
0x39 57 WL1273_REF_SET ........
0x3a 58 WL1273_POWER_ATT_SET ........
0x3b 59 WL1273_POWER_LEV_SET FMC_FW_OPCODE_TX_POWER_LEVEL_SET_GET
Set to 4
/* Range for TX power level in units for dB/uV */ ! 122-pwr
#define FM_PWR_LVL_LOW 91
#define FM_PWR_LVL_HIGH 122
/* Chip specific default TX power level value */
#define FM_PWR_LVL_DEF 4
0x3c 60 WL1273_AUDIO_DEV_SET ........
0x109 = 265 ?
0x3d 61 WL1273_PILOT_DEV_SET ........
0x1b = 27
0x3e 62 WL1273_RDS_DEV_SET ........
8
0x3f 63 WL1273_AUDIO_IO_SET FMC_FW_OPCODE_TX_AUDIO_IO_SET
0 WL1273_AUDIO_IO_SET_ANALOG FMC_FW_TX_AUDIO_IO_SET_ANALOG
1 WL1273_AUDIO_IO_SET_I2S FMC_FW_TX_AUDIO_IO_SET_I2S
0x40 64 WL1273_PREMPH_SET FMC_FW_OPCODE_TX_PREMPH_SET_GET
0 FM_TX_PREEMPH_50US FM TX Pre-emphasis filter default ?
1 FM_TX_PREEMPH_OFF
2 FM_TX_PREEMPH_75US
0x41 65 TX_BAND_SET !!??
0x42 66 WL1273_MONO_SET FMC_FW_OPCODE_TX_MONO_SET_GET
0 WL1273_TX_MONO
1 WL1273_TX_STEREO
1 by default
0x43 67 WL1273_MPX_LMT_ENABLE
0x44 68 ........ FMC_FW_OPCODE_TX_PI_CODE_SET_GET
0x45 69 WL1273_ECC_SET FMC_FW_OPCODE_TX_RDS_ECC_SET_GET
0x46 70 WL1273_PTY FMC_FW_OPCODE_TX_RDS_PTY_CODE_SET_GET
0x47 71 WL1273_AF FMC_FW_OPCODE_TX_RDS_AF_SET_GET
------------------------------------------------------------------------------------------
Code 72 (0x48) missing
------------------------------------------------------------------------------------------
0x49 73 WL1273_TX_AUDIO_LEVEL_TEST_THRESHOLD ........
0x4a 74 WL1273_DISPLAY_MODE FMC_FW_OPCODE_TX_RDS_PS_DISPLAY_MODE_SET_GET
0 FMC_FW_TX_RDS_PS_DISPLAY_MODE_SCROLL_OFF
1 FMC_FW_TX_RDS_PS_DISPLAY_MODE_SCROLL_ON
0x4d 77 WL1273_RDS_REP_SET FMC_FW_OPCODE_TX_RDS_REPERTOIRE_SET_GET
0x4e 78 WL1273_TA_SET FMC_FW_OPCODE_TX_RDS_TA_SET
0x4f 79 WL1273_TP_SET FMC_FW_OPCODE_TX_RDS_TP_SET
0x50 80 WL1273_DI_SET FMC_FW_OPCODE_TX_RDS_DI_CODES_SET_GET
0x51 81 WL1273_MS_SET FMC_FW_OPCODE_TX_RDS_MUSIC_SPEECH_FLAG_SET_GET
0x52 82 WL1273_PS_SCROLL_SPEED FMC_FW_OPCODE_TX_RDS_PS_SCROLL_SPEED_SET_GET
0x53 83 WL1273_SOC_AUDIO_PATH_SET ........
0x54 84 WL1273_SOC_PCMI_OVERRIDE ........
0x55 85 WL1273_SOC_I2S_OVERRIDE ........
0x56 86 WL1273_I2C_DEV_ADDR_SET ........
default 0x22 = 34 (Nokia: #define RX71_FM_I2C_ADDR 0x22)
0x57 87 WL1273_RX_ANTENNA_SELECT ........
0x58 88 WL1273_REF_ERR_CALIB_PARAM_SET ........
0x0c = 12
0x59 89 WL1273_REF_ERR_CALIB_PERIODICITY_SET ........
0x5a 90 WL1273_POWER_ENB_SET FMC_FW_OPCODE_TX_POWER_ENB_SET
0 FMC_FW_TX_POWER_DISABLE
1 FMC_FW_TX_POWER_ENABLE
0x5b 91 WL1273_PUPD_SET FMC_FW_OPCODE_TX_POWER_UP_DOWN_SET
0 WL1273_PUPD_SET_OFF FMC_FW_TX_POWER_DOWN
bit0 1 WL1273_PUPD_SET_ON FMC_FW_TX_POWER_UP
bit4 0x10 WL1273_PUPD_SET_RETENTION ........
0x5c 92 WL1273_MUTE FMC_FW_OPCODE_TX_MUTE_MODE_SET_GET
0 FMC_FW_TX_UNMUTE
1 FMC_FW_TX_MUTE
0x5d 93 WL1273_PI_SET ........
0x5e 94 WL1273_RDS_DATA_ENB FMC_FW_OPCODE_TX_RDS_DATA_ENB_SET_GET
0 FMC_FW_TX_RDS_ENABLE_STOP
1 FMC_FW_TX_RDS_ENABLE_START
0x5f 95 WL1273_RSSI_BLOCK_SCAN_FREQ_SET ........
0x60 96 WL1273_TX_AUDIO_LEVEL_TEST ........
0x61 97 WL1273_RSSI_BLOCK_SCAN_START ........
0x62 98 WL1273_RDS_CONFIG_DATA_SET FMC_FW_OPCODE_TX_RDS_CONFIG_DATA_SET
0x63 99 WL1273_RDS_DATA_SET FMC_FW_OPCODE_TX_RDS_DATA_SET
0x64 100 WL1273_WRITE_HARDWARE_REG FMC_FW_OPCODE_CMN_HARDWARE_REG_SET_GET
0x65 101 WL1273_CODE_DOWNLOAD FMC_FW_OPCODE_CMN_CODE_DOWNLOAD
0x66 102 WL1273_RESET FMC_FW_OPCODE_CMN_RESET
0x0f00 = 3840
------------------------------------------------------------------------------------------
Code 103 (0x67) missing
------------------------------------------------------------------------------------------
0x68 104 WL1273_READ_FMANT_TUNE_VALUE ........ TX tuning capacitor value
?
/* FM TX antenna impedence values */
#define FM_TX_ANT_IMP_50 0
#define FM_TX_ANT_IMP_200 1
#define FM_TX_ANT_IMP_500 2
------------------------------------------------------------------------------------------
Codes 105-253 (0x69-0xfd) missing
------------------------------------------------------------------------------------------
0xfe 254 WL1273_FM_POWER_MODE ........
0 FMC_FW_RX_FM_POWER_MODE_DISABLE
1 FMC_FW_RX_FM_POWER_MODE_ENABLE
0xff 255 WL1273_FM_INTERRUPT ........
------------------------------------------------------------------------------------------
?
5 WL1273_RSSI_BLOCK_SCAN_DATA_GET RSSI_BLOCK_SCAN_DATA_GET
------------------------------------------------------------------------------------------
/*
Maximum length of data that may be sent in a single RDS data set command
Once FM FW team removes internal limitations, HCI limitations (much
longer) may apply.
In case a longer RDS data should be sent to the chip, it is divided into
multiple chunks, each chunk being up to FMC_FW_TX_MAX_RDS_DATA_SET_LEN
bytes long
*/
#define FMC_FW_TX_MAX_RDS_DATA_SET_LEN ((FMC_UINT)30)
/*
Defines the max length of data that can be written to FM Hardware register
*/
#define FMC_FW_WRITE_HARDWARE_REG_MAX_DATA_LEN ((FMC_UINT)HCI_CMD_PARM_LEN)
? HCI_CMD_PARM_LEN ?
------------------------------------------------------------------------------------------
Event masks:
bit, 2 hex bytes, (1), (2)
0 0x0001 WL1273_FR_EVENT FMC_FW_MASK_FR Tuning Operation Ended
1 0x0002 WL1273_BL_EVENT FMC_FW_MASK_BL Band limit was reached during search
2 0x0004 WL1273_RDS_EVENT FMC_FW_MASK_RDS RDS data threshold reached in FIFO buffer
3 0x0008 WL1273_BBLK_EVENT FMC_FW_MASK_BBLK RDS B block match condition occurred
4 0x0010 WL1273_LSYNC_EVENT FMC_FW_MASK_LSYNC RDS sync was lost
5 0x0020 WL1273_LEV_EVENT FMC_FW_MASK_LEV RSSI level has fallen below the threshold configured by SEARCH_LVL_SET
6 0x0040 WL1273_IFFR_EVENT FMC_FW_MASK_IFFR Received signal frequency is out of range
7 0x0080 WL1273_PI_EVENT FMC_FW_MASK_PI RDS PI match occurred
8 0x0100 WL1273_PD_EVENT FMC_FW_MASK_PD Audio pause detect occurred
9 0x0200 WL1273_STIC_EVENT FMC_FW_MASK_STIC Stereo indication changed
10 0x0400 WL1273_MAL_EVENT FMC_FW_MASK_MAL Hardware malfunction
11 0x0800 WL1273_POW_ENB_EVENT FMC_FW_MASK_POW_ENB Tx Power Enable/Disable
12 0x1000 WL1273_SCAN_OVER_EVENT FMC_FW_MASK_INVALID_PARAM
13 0x2000 WL1273_ERROR_EVENT !! One of the above is wrong !!
---------------------------------------------------------------------------------------------------------
FM Receiver script
---null set---
FM Transmitter script
---null set---
I think you are doing an awsome job and I really hope that you'll succeded. But the reason why I'm writing this post is to get this thread on the first page again for a while, so maybe more developers will see it, and can contribute !
Good luck!
EDIT: Perhaps it just needs more outstandig title, maybe Unviersal FM radio for android devices with TI WL chips, or something that would get people to read it.
qzem said:
I think you are doing an awsome job and I really hope that you'll succeded. But the reason why I'm writing this post is to get this thread on the first page again for a while, so maybe more developers will see it, and can contribute !
Good luck!
EDIT: Perhaps it just needs more outstandig title, maybe Unviersal FM radio for android devices with TI WL chips, or something that would get people to read it.
Click to expand...
Click to collapse
It's already off the first page, LOL.
My plan has been to post a link to this thread in the various existing threads for different devices using the TI FM chips. I'm sure that will get this thread some notice. I think a lot of devs and dev types stick to the forums for their devices and don't look at this general section.
At least there are so many potentially matching keywords in the first 10 posts that google searches on the subject are likely to link here.
I agonized over the thread title name for some time and "TI FM Radio" is best description I could think of, technically at least. I don't know if I can rename the thread, but it might help to put the names of popular devices with TI chips in the title.
As I posted on the Legend thread, I now have an App Inventor app up and running with functionality to tune, scan, change volume and see signal strength. The audio routing is the last major piece of the puzzle, but it may be different on different devices.
I'll spend a few more days at most to try and get audio routing working, and then, whether working or not, I'll post in a few threads looking for further info and people who want to try the app I'm building.
Would be nice to see the RDS and transmitter working soon too.
Regarding merging the bluetooth and FM drivers, TI's solution appears to be what they call a shared transport line discipline driver. The way this should work, each driver has what appears to it to be dedicated access to it's respective core, and the line discipline driver takes care of any queueing or delaying of commands & such that has to happen to keep them from stepping on each others toes.
Oh, and "IP" is "Intellectual Property" in this case. So the core, generally you'd say the WL127x has a wifi core, bluetooth core, etc. and 128x has a gps core as well. An IP core uses a description language (it used to be VHDL) to describe the layout of the core, so for instance if a company wants to build wifi onto their own chip, they can buy use of the IP core from TI instead of having to buy a phyiscal chip and interface to it.
I've got a debian install wedged onto my Droid 2 Global, I'm going to look into the "ti-st" V4L2 FM drivers, and see if I can get a module that will insert. The kernel can't be replaced on D2G yet, but as far as I know if I get a 2.6.32.9 kernel tree, and get ti-st driver to compile under it, I don't see why it shouldn't insert as a module just fine. Also, I'll look REAL closely to see if I can discern how it gets audio out, so I might have an hcitool command or two to add if that pans out.
hwertz said:
Regarding merging the bluetooth and FM drivers, TI's solution appears to be what they call a shared transport line discipline driver. The way this should work, each driver has what appears to it to be dedicated access to it's respective core, and the line discipline driver takes care of any queueing or delaying of commands & such that has to happen to keep them from stepping on each others toes.
Oh, and "IP" is "Intellectual Property" in this case. So the core, generally you'd say the WL127x has a wifi core, bluetooth core, etc. and 128x has a gps core as well. An IP core uses a description language (it used to be VHDL) to describe the layout of the core, so for instance if a company wants to build wifi onto their own chip, they can buy use of the IP core from TI instead of having to buy a phyiscal chip and interface to it.
I've got a debian install wedged onto my Droid 2 Global, I'm going to look into the "ti-st" V4L2 FM drivers, and see if I can get a module that will insert. The kernel can't be replaced on D2G yet, but as far as I know if I get a 2.6.32.9 kernel tree, and get ti-st driver to compile under it, I don't see why it shouldn't insert as a module just fine. Also, I'll look REAL closely to see if I can discern how it gets audio out, so I might have an hcitool command or two to add if that pans out.
Click to expand...
Click to collapse
Thanks for the info hwertz .
OK I understand "IP" now; never heard it used in that way to designate blocks on a chip.
Yes I read something about the line discipline. Some block diagrams: http://omappedia.org/wiki/Wilink_ST
If you know of any HCI commands dealing with audio routing, please post or pm whatever info you can share.
So I'd guess your opinion is that the v4l2 api is the best route to support FM radios on Android ? That was among my first thoughts until I saw that there is currently virtually no such support on any Android ROM I've heard of. HCI seems to work fine, but it requires chip specific commands of course.
Clearly though, at least Nokia and TI both are working on efforts to bring V4L2 apis for the TI chip in the embedded linux or Android environments.
I'm not sure how audio routing would be configured on Android when using v4l2 apis. The PC environment requires moving digital data from source to destination. But SOC devices often can move digital or analog data directly and without software support.
FM Transmitting Radius
So I hope this question is not too basic for this forum, but I'm new to it and wonder how large the FM transmitting radius of such a chip might be. I basically just need to get an idea, but of course I'd also be thankful if you can refer me to all sorts of literature, specs, overviews, etc.
Thanks!
Lipton1 said:
So I hope this question is not too basic for this forum, but I'm new to it and wonder how large the FM transmitting radius of such a chip might be. I basically just need to get an idea, but of course I'd also be thankful if you can refer me to all sorts of literature, specs, overviews, etc.
Thanks!
Click to expand...
Click to collapse
This thread is over 2 years old now. The original purpose was to try and find others interested in sharing the undocumented secrets of TI's FM chip.
But after my info dump, nobody showed up to share with me, and likely nobody will, so I will close it after this post.
Any further discussion about FM can move to the Spirit FM thread in my sig.
These chips put out tiny amounts of power in transmit mode, maybe 10-30 milliwatts or so. The only phones I have that transmit have to have their headset cable antenna wrapped around the receiver antenna to get anything resembling decent quality.
So I'd call the transmit radius a few centimetres at most. Little wonder then, perhaps, why so few Android devices support transmit.

AOSP on Pandaboard, BlueZ config

Hi everybody,
I'm developing on a Pandaboard ES. I compiled AOSP 4.0.4 and a kernel from scratch, everything working quite good so far.
As I need to connect some weird bt-devices I have to change the default bt-class.
This is what I get from hciconfig -a:
Code:
/ # hciconfig -a
hci0: Type: BR/EDR Bus: UART
BD Address: 1C:E2:XX:XX:XX:XX ACL MTU: 1021:4 SCO MTU: 180:4
UP RUNNING PSCAN
RX bytes:2148 acl:0 sco:0 events:92 errors:0
TX bytes:1472 acl:0 sco:0 commands:92 errors:0
Features: 0xff 0xfe 0x2d 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF
Link mode: SLAVE ACCEPT
Name: 'BlueZ'
[COLOR="Red"]Class: 0x1a0000[/COLOR]
Service Classes: Networking, Capturing, Object Transfer
[COLOR="red"]Device Class: Miscellaneous, [/COLOR]
HCI Version: 4.0 (0x6) Revision: 0x0
LMP Version: 4.0 (0x6) Subversion: 0x1f22
Manufacturer: Texas Instruments Inc. (13)
By default there is no main.conf in /etc/bluetooth/. But I can find two different ones in the sources from where I'm compiling.
1: /external/bluetooth/bluez/src/main.conf
2: /system/bluetooth/data/main.conf
I modified one, pushed it to the pandaboard and rebooted, but the file is ignored. Neither the class nor the name change as expected.
Changing the class with hcitool works, but this is, of course, not permanent. (When changing the class I can connect my "weird" device without problems.)
Why is the file ignored? File owner and rights are the same as on my Nexus S. Here the file exists. (Unfortunately I can't check if its really parsed here, because it's my productive phone, so it is unrooted and stock 4.0.4)
Below you find the content of /etc/bluetooth and main.conf which I pushed to the pandaboard.
Code:
/ # ls -al /etc/bluetooth/
-r--r----- bluetooth bluetooth 1699 2012-05-11 10:31 audio.conf
-rw-r----- system system 1536 2012-05-11 10:31 auto_pairing.conf
-r--r--r-- net_bt net_bt 401 2012-05-11 10:31 blacklist.conf
-r--r----- bluetooth bluetooth 262 2012-05-11 10:31 input.conf
-r--r--r-- bluetooth bluetooth 2802 2012-06-25 09:44 main.conf
-r--r----- bluetooth bluetooth 120 2012-05-11 10:31 network.conf
PHP:
[General]
# List of plugins that should not be loaded on bluetoothd startup
#DisablePlugins = network,input
# Default adaper name
# %h - substituted for hostname
# %d - substituted for adapter id
Name = "Panda"
# Default device class. Only the major and minor device class bits are
# considered.
Class = 0x400210
# How long to stay in discoverable mode before going back to non-discoverable
# The value is in seconds. Default is 180, i.e. 3 minutes.
# 0 = disable timer, i.e. stay discoverable forever
DiscoverableTimeout = 120
# How long to stay in pairable mode before going back to non-discoverable
# The value is in seconds. Default is 0.
# 0 = disable timer, i.e. stay pairable forever
PairableTimeout = 0
# Use some other page timeout than the controller default one
# which is 16384 (10 seconds).
PageTimeout = 8192
# Discover scheduler interval used in Adapter.DiscoverDevices
# The value is in seconds. Defaults is 30.
DiscoverSchedulerInterval = 30
# What value should be assumed for the adapter Powered property when
# SetProperty(Powered, ...) hasn't been called yet. Defaults to true
InitiallyPowered = true
# Remember the previously stored Powered state when initializing adapters
RememberPowered = true
# Use vendor, product and version information for DID profile support.
# The values are separated by ":" and VID, PID and version.
DeviceID = android:generic:1.5
# Do reverse service discovery for previously unknown devices that connect to
# us. This option is really only needed for qualification since the BITE tester
# doesn't like us doing reverse SDP for some test cases (though there could in
# theory be other useful purposes for this too). Defaults to true.
ReverseServiceDiscovery = true
# Enable name resolving after inquiry. Set it to 'false' if you don't need
# remote devices name and want shorter discovery cycle. Defaults to 'true'.
NameResolving = true
# Enable runtime persistency of debug link keys. Default is false which
# makes debug link keys valid only for the duration of the connection
# that they were created for.
DebugKeys = false
# Enable Low Energy support if the dongle supports. Default is false.
# Enable/Disable interleave discovery and attribute server over LE.
EnableLE = false
# Enable the GATT Attribute Server. Default is false, because it is only
# useful for testing. Attribute server is not enabled over LE if EnableLE
# is false.
AttributeServer = false
# The link policy for connections. By default it's set to 0x000f which is
# a bitwise OR of role switch(0x0001), hold mode(0x0002), sniff mode(0x0004)
# and park state(0x0008) are all enabled. However, some devices have
# connection stability issue or fail to setup SCO when the link is in park
# state, which requires park state bit cleared.
DefaultLinkPolicy = 0x000f
bump
Nobody an idea?
Bumping this a last time as this topic is still not solved.
Any help would be great.

[Q] GT-I930x: State of HDMI/MHL implementation for AOSP based ROMs

Hi folks,
i did a little research these days and tried to sort out,
what in fact is missing to make HDMI/MHL work in AOSP based ROMs for the S3 series.
It is really hard to find some useful stuff about it.
All i noticed were some ancient posts about attaching MHL cable causing reboots.
Everyone keeps repeating MHL will not work on AOSP.
I know that HDMI/MHL is weird stuff and reference manual for MHL transceiver SII9244 is not available.
On the other hand this chip is only working as a phy and should be set up correctly at kernel level.
I also know that there'd been many attempts to make it work but i am to dumb to find some reference to tech talks about it.
So it really seems that most parts are implemented and ready to be put together.
At least that's the way it seems to me... and might be bit noobish of course.
Anyway i found something, which might be another key to solve this issue.
Some snippets from the sources at kernel level.
mach-midas.c:
Code:
#ifdef CONFIG_SAMSUNG_MHL
/* I2C15 */
static struct i2c_gpio_platform_data gpio_i2c_data15 = {
.sda_pin = GPIO_MHL_SDA_1_8V, /* GPB2, I2C5_SDA */
.scl_pin = GPIO_MHL_SCL_1_8V, /* GPB3, I2C5_SCL */
.udelay = 3,
.timeout = 0,
};
struct platform_device s3c_device_i2c15 = {
.name = "i2c-gpio",
.id = 15,
.dev = {
.platform_data = &gpio_i2c_data15,
}
};
static struct i2c_board_info i2c_devs15_emul[] __initdata = {
};
/* I2C16 */
#if !defined(CONFIG_MACH_T0) && !defined(CONFIG_MACH_M3) \
&& !defined(CONFIG_MACH_GD2)
static struct i2c_gpio_platform_data gpio_i2c_data16 = {
.sda_pin = GPIO_MHL_DSDA_2_8V,
.scl_pin = GPIO_MHL_DSCL_2_8V,
};
struct platform_device s3c_device_i2c16 = {
.name = "i2c-gpio",
.id = 16,
.dev.platform_data = &gpio_i2c_data16,
};
#endif /* !defined(CONFIG_MACH_T0) */
static struct i2c_board_info i2c_devs16_emul[] __initdata = {
};
#endif
midas-mhl.c:
Code:
static int __init midas_mhl_init(void)
{
int ret;
#define I2C_BUS_ID_MHL 15
ret = i2c_add_devices(I2C_BUS_ID_MHL, i2c_devs_sii9234,
ARRAY_SIZE(i2c_devs_sii9234));
if (ret < 0) {
printk(KERN_ERR "[MHL] adding i2c fail - nodevice\n");
return -ENODEV;
}
#if defined(CONFIG_MACH_T0_EUR_OPEN) || defined(CONFIG_MACH_T0_CHN_OPEN)
sii9234_pdata.ddc_i2c_num = 6;
#elif defined(CONFIG_MACH_P4NOTE) || defined(CONFIG_MACH_SP7160LTE) || defined(CONFIG_MACH_T0) \
|| defined(CONFIG_MACH_KONA) || defined(CONFIG_MACH_TAB3) || \
defined(CONFIG_MACH_GD2) || defined(CONFIG_MACH_GC2PD)
sii9234_pdata.ddc_i2c_num = 5;
#else
sii9234_pdata.ddc_i2c_num = (system_rev == 3 ? 16 : 5);
#endif
#ifdef CONFIG_MACH_SLP_PQ_LTE
sii9234_pdata.ddc_i2c_num = 16;
#endif
ret = i2c_add_devices(sii9234_pdata.ddc_i2c_num, &i2c_dev_hdmi_ddc, 1);
if (ret < 0) {
printk(KERN_ERR "[MHL] adding ddc fail - nodevice\n");
return -ENODEV;
}
return 0;
}
This could be found in the AOSP source trees of the Android hal:
https://github.com/omnirom/android_...ynos4/hal/libhdmi/libsForhdmi/libddc/libddc.c
Code:
/**
* @brief DDC device name.
* User should change this.
*/
#ifdef DDC_CH_I2C_1
#define DEV_NAME "/dev/i2c-1"
#endif
#ifdef DDC_CH_I2C_2
#define DEV_NAME "/dev/i2c-2"
#endif
#ifdef DDC_CH_I2C_7
#define DEV_NAME "/dev/i2c-7"
#endif
So i really wonder if someone ever tried to add device "i2c-15" here and compile.
See the implementation for odroid-u3 here as well (which is the base for NamelessROM):
https://github.com/codewalkerster/android_hardware_samsung_slsi_exynos4
Additionally this should be added to the S3 BoardConfig.mk then:
Code:
BOARD_USES_HDMI_SUBTITLES := true
BOARD_USES_HDMI := true
BOARD_HDMI_STD := STD_720P
BOARD_HDMI_DDC_CH := DDC_CH_I2C_15
BOARD_USES_FIMGAPI := true
Please leave some comments and help me to understand what in fact is missing to watch TV with AOSP ROMs :angel:
Regards,
scholbert
That'd be awesome thing having HDMI/MHL out in AOSP. That's the main reason why I'm using stock rom. @codeworkx is the guy you need to talk to but he's no longer in the cyanogenmod team.
Hi [email protected],
thanks for your reply!
I'll try to contact codeworkx, though it seems he had not only left CM team but XDA-devs as well.
[email protected] said:
That'd be awesome thing having HDMI/MHL out in AOSP. That's the main reason why I'm using stock rom. @codeworkx is the guy you need to talk to but he's no longer in the cyanogenmod team.
Click to expand...
Click to collapse
Anyway, i know that there are many parts of code involved to make the MHL interface work, so the main part for me is to know about the missing link.
I guess i'll try to get a better understanding about the kernel side the next days, as there are:
- do we have all parts to map the virtual I2C port for SII9244
- does the initialization of the SII9244 look complete
- what's the state of the HPD GPIO
Next would be of course, to understand how the interaction of framebuffer mapping takes place.
There's the GPU MALI stuff which uses parts of RAM and some framebuffer as well
The internal HDMI logic of Exynos needs some mapping of course to get access to this memory.
This could be the most complex part and maybe this information is missing or done by proprietary stuff...
Let's see if we could get more detailed information about it in the next weeks.
So please help out with useful comments
Best regards,
scholbert
You can find him in the BBQlinux IRC channel. He's the developer of that distro.
Hi there,
again thanks for the reply so far.
I did some further research on this issue on my own....
- Yes, there are proprietary files which handle HDMI (TVOUT) in stock ROMs
- Yes, these libs and services do not seem to match the AOSP implementation
After some investigation on the proprietary files and searching for some ASCII snippets in the binaries, it seems that at least some parts, or better call it functionality, is covered in the HAL present in the AOSP source tree, which had been released for the SMDK4412.
My guessing is that the "framework" is little different in these sources and some of the libraries of the AOSP version have other names, if we manage to compile them.
I still wonder, if someone did ever try to set all necessary compile flags for HDMI and give it a try with the settings i posted in my first thread. So i guess i'll have to do it...
Maybe it's all nonsense and the sources of Exynos HAL which are used by the AOSP ROMs are completely unusable, if it comes to HDMI implementation.
On the other hand there's Hardkernel's odroid platform which has a working HDMI port.
So what's the secret here?
Cheers,
scholbert
@pulser_g2 here please
Seems there is already something on its way
https://gerrit.nameless-rom.org/#/c/13927/
Gesendet von meinem GT-N7105 mit Tapatalk
Hi DerTeufel1980,
thanks for pointing to this patchset... i've already seen some other related patches some days ago.
Looks promising and hopefully this time these hacks will be successful!
Though i'm not sure about the management of the i2c ports at kernel level or maybe i just don't understand its mapping.
While it is correct that the MHL PHY is connected to the physical interface i2c-5 (the pins), it seems that the kernel uses some virtualisation based on the devices address connected to this port...
AFAIK Exynos 4412 got five physical I2C ports, which are used by a variety of physical devices (the real chips).
Each physical device should have a unique i2c address to get addressed by the CPU.
In the end we got multiple chips with different addresses connected to the physical ports which are presented as virtual device starting from i2c-0 up to i2c-21.
So if i interpret the sources correctly, the device id for DDC function should be i2c-15 at userland, or better spoken: Android world.
But as already stated maybe i'm wrong here...
Time will show
Thanks for contributing!!
EDIT:
Just contacted one of the hard working developers at Nameless ROM and he pointed me to another more frustrating issue, which is the missing source code for HWC.
See this information (which is quite old, but you need to find it ) which covers the Exynos CPU's in general:
https://plus.google.com/+AndrewDodd/posts/DHg5z62CHHu
So this snippet says it all:
Edit - HDMI
Insignal's latest reference source has new HDMI code. However, it's tightly integrated with HWC. As covered above, HWC is totally broken in their source release. No HWC, no HDMI.
Click to expand...
Click to collapse
EDIT2:
Some more tech talk to understand the flaw:
https://jira.cyanogenmod.org/browse/ESDB-1
Cheers,
scholbert
Hey there... it's me again
I thought about missing source code and how all stuff get's arranged in the variety of ROM's.
Especially MALI, HWC and proprietary stuff...
Quite irritating though because i'm no hardcore software developer :angel:
Anyway found this:
http://forum.xda-developers.com/showpost.php?p=55809089&postcount=1508
In other words, there is some HWC source code for exynos4.
Why was it dropped then and latest release of Nameless Lollipop ROM stepped back to the older MALI release?
This led to a more proprietary codebase.
I read about r4p0 would not be the best choice for mobile device or is there another reason
Please leave a comment, if you know more about it.
Would be nice to have some open discussion here anyway...
Have fun!
scholbert
The problem came with r4p0 when the proprietary HWC blob was made working with the kernel rebase from fni1 source drop of n7100. The amount of glitches occurring were too high, and the r4p0 drivers used in the device were blobs. There aren't any display related open source Hals for exynos to have a reference from and fix the graphics part having glitches.
As is already notable with chrome, GPU rasterization is broken and had even more issues with newer blobs, which actually even I'm not sure of why so. R3p2 drivers we use actually are based on a newer api as compared to r4p0 and as a result, the blobs are more updated than the r4p0 taken from the Odroid board.
̿ ̿̿’̿’\̵͇̿̿\з==(*͡° ͜ʖ ͡°)==ε/̵͇̿̿/’̿’̿ ̿ ̿̿*

Modify firmware/disable postprocessing on Vizio hdtv via serial U-Boot

Backstory: I have an old (2008?) vizio VA22L FHDTV10T. 1920x1080 60hz panel. I want to connect it to my pc, but if I use anything other than the VGA port (eg HDMI) it overscans and applies all this crap to the image. It's clear and crisp and beautiful if I use VGA (tested with old VGA gpu), but alas, my pc doesn't have a VGA output. (Yes I tried all the settings, no they don't fix it. Yes, I tried adjusting the graphics driver settings, no they haven't fixed it without being a PITA every time I turn the tv off.)
On to the important stuff: I can access the tv with a serial connection via "Service port" and can see a Das U-boot boot sequence and issue commands. I just don't know linux and can't get anywhere past the help menus. If someone could guide me on modifying this thing I'd be rather grateful!
For starters, here's the output when I first turn it on whilst pc is plugged in via VGA, wait for it to finish booting, and press enter.
PS: using PuTTY @ 115200baud
Code:
▒Boot-
Bank 0 : DQS(3 ~ 42), Size 39, Middle = 22
Bank 1 : DQS(-1 ~ 41), Size 42, Middle = 20
DRAM is set as 16 bits
Boot
Starting C main
0x00001b04
LZHS addr:0x00001b80
LZHS size:0x0002fcd8
LZHS checksum:0x00000084
U-Boot 1.1.4 (Oct 9 2009 - 12:58:21)
U-Boot code: 00D00000 -> 00D2FCD8 BSS: -> 00D7430C
RAM Configuration:
Bank #0: 00000000 64 MB
Detect flash #0: MXIC(25L320)
Flash: 4 MB
0.0.0.0
In: serial
Out: serial
Err: serial
DramSizing: 0x02000000
Finding Image...
Decompression image to 0x00010000...
Booting
Nucleus Heap is at 0x00603208(0x00be5f80)
Main task stack is at 0x00603218 (0x00002000)
============================================
Memory for Image at 0x00010000(0x005eda08):
Memory for OSAI at 0x00605228(0x00ae5f80)
Memory Reserved for ARM lib at 0x010ec000(0x00100000)
Memory Reserved for FBM at 0x011ec000(0x00e10000)
Memory Reserved for MMU at 0x01ffc000(0x00004000)
Find panel index 102(PANEL_LG_LM215WF1) from GPIO
TunerInit.....................MUSBStack-S v2.303 Init pBase = 0x20029000.
Image ROBase:0x0001099c ROLimit:0x004483f4
Protect readonly memory from 0x00000000 to 0x004483e8
MMU protect: 0x01ffc000 ~ 0xfffffff8
Successed to initialize Memory Intrusion Detection!
DTV>Detect flash #0: MXIC(25L320)
[SRM] DISP CTRL 0 0 0 0
[SRM] DISP CTRL 0 1 0 0
[DM] VT = 1111 (1111)
DM Panel V(1089 1099 1200) H(1999 2175 2239) P(120000000 143472527 175000000) F(50 75)
DM H MIN(1800 2048) H MAX(2624)
DM OK V(1111) H(2176) F(60)
[DM] VT = 1111 (1111)
DM OK HS(254)
[DM] VT = 1111 (1111)
DM Panel V(1089 1099 1200) H(1999 2175 2239) P(120000000 143472527 175000000) F(50 75)
DM H MIN(1800 2048) H MAX(2624)
DM OK V(1111) H(2176) F(60)
[DM] VT = 1111 (1111)
DM OK HS(254)
Watchdog enable:405000000
W: 1920 H: 1080 Rate: 60 DSH:800 DSV: 800 USH: 800 USV: 800 VSP: 0 TUNE: 0 bStackSize: 1
[Help]
cd: Change current directory
do: Repeat command
alias(a): Add/Show current alias
read(r): Memory read(word)
write(w): Memory write(word)
basic_(b): basic command
mtktool(0): mtktool command
customer(cust): Get customer name
pmx: pmx (scpos) command
musb: MUSB command
sif: Sif command
eeprom: Eeprom command
nim: Nim command
ir: Ir command
rtc(rtc): RTC commands
aud: Aud command
nptv(n): Nptv command
dbs: Dbs command
dmx(d): Demux commands
memtest: Memory test
pdwnc(pdwnc): PDWNC commands
bwt: BWT command
gpio: Gpio interface
DTV>
Again, thanks in advance!
Mmm, so right after posting, I figured out that I had to change directory to one of the commands listed in the first help in order to issue commands from the sub-help of each one instead of using them as arguments. EG: cd pmx [enter] pattern 1 [enter] would turn on the test pattern instead of pmx pattern or pmx pattern 1 or pmx -p and other such variants. There's probably a guide for this out there somewhere but most of my searches just turned up historical info on German submarines... Oh, and this thread which is kinda along the same lines: https://forum.xda-developers.com/android/software/rooting-mediatek-based-linux-smart-tv-t3150281
I guess now I just have to find which setting(s) fix my apparent problem, then I'll need to append the firmware, assuming I can't do it from the serial console. And that'll be the part I definitely need help with.
Maybe I can just use commands to do this, but I don't know what most of this is, and my searches aren't yielding much... That said, I can run the commands and post back the results since I don't expect anyone to have this same model.
Here's the menu and submenus with my comments in quotes:
Code:
cd: Change current directory "Figured out this one"
do: Repeat command "Self explanatory"[HIDE]
Usage: do loop cmd ex: do 10 read 0x200 0x10
CLI Command Return Value (-1)[/HIDE]
alias(a): Add/Show current alias "not quite sure what this does"
read(r): Memory read(word) "I guess these are self explanatory? no output if I just run the commands"
write(w): Memory write(word)
basic_(b): basic command [HIDE]
[Help]
stop: Stop RS232 transparent mode
sv: System mode detection
version(ver): System version/build date
reboot: System reboot/restart
getpllclk(gpc): close loop, gpc [cpu|sys|ps|vo|adc|b2r|apl1|apl2] [[band num]]
backup(bk): backup command
[/HIDE]
mtktool(0): mtktool command "the help kinda explains?[HIDE]
[Help]
et: Enter RS232 transparent mode
ft: Set RS232 factory mode
st: Stop RS232 transparent mode[/HIDE]
customer(cust): Get customer name "returns [TPV] and nothing more"
pmx: pmx (scpos) command "looks promising?"[HIDE]
[Help]
enable(e): enable/disable LVDS
pattern(p): enable/disable test pattern
list(l): show panel list
query(q): dump pmx(scpos) info
set(s): set parameter
[/HIDE]
musb: MUSB command "probably controls the usb port on the back?" [HIDE]
[Help]
debug_on(d_on): MUSB.d_on
debug_off(d_off): MUSB.d_off
debug_level(d_l): MUSB.d_l
init(i): MUSB init
speed(speed): MUSB speed
hmsd(hm): MUSB host msd test
htst(ht): MUSB host compilance test
suspend(s): USB bus suspend
resume(r): USB bus resume
[/HIDE]
sif: Sif command "I know what edid is basically, maybe I could make the computer think this is a non-hdtv type connection?"[HIDE]
[Help]
init(i): Sif init
read(r): Sif read
write(w): Sif write
writebyte(wb): Sif write byte
hdcp: Sif write HDCP SRAM default value
rhdcp: Sif read HDCP
wbhdcp: Sif write byte to HDCP
rbhdcp: Sif read byte from HDCP
wallhdcp(wah): Sif write all 320 bytes to HDCP
rallhdcp(rah): Sif read all 320 bytes from HDCP
edid: Sif write EDID default value
redid: Sif read EDID
walledid(wae): Sif write all 256 bytes to EDID
ralledid(rae): Sif read all 256 bytes from EDID
tunerread(tr): Tuner I2C No-sub-addr read
tunerwrite(tw): Tuner I2C No-sub-addr write
multipleread(mr): Multiple sub-addr I2C read
multiplewrite(mw): Multiple sub-addr I2C write
scan1(s1): Scan BUS0 (System I2C)
scam2(s2): Scan BUS1 (Tuner I2C)
sif_x_read(xr): fully functional sif read
sif_x_write(xw): fully functional sif write
edidreadbyte(edidrb): edid read byte
[/HIDE]
eeprom: Eeprom command "there's an 8 pin eeprom on the mainboard" [HIDE]
[Help]
readbyte(rb): eeprom.rb [eeprom-offset]
writebyte(wb): eeprom.wb [eeprom-offset] [byteval]
uartwrite(uw): Get data from Uart and write to eeprom.[/HIDE]
nim: Nim command "I assume this controls the onboard tv tuner"[HIDE]
[Help]
id: Set Tuner ID
ver: Tuner version
dtd: Nim dtd
atd: Nim atd
d_l: Set Debug Level
go: Start Nim
up: Channel Up
down: Channel Down
channel: Channel Set
freq: Freq Set
init(i): Nim init
open(o): Nim open
close(c): Nim close
setcable(sc): Nim set cable parameters
setBW(sbw): Nim set BW
getcablelevel(gclv): Nim get cable signal level
getcablesignal(gcsc): Nim get cable signal parameter
getcablelock(gclk): Nim get cable lock status
detachmw(dm): Nim Detach MW
detachi2c(dei2c): Detach Tuner I2C
[/HIDE]
ir: Ir command "InfraRed as in the remote I s'pose" [HIDE]
rx(rx): RX commands
[/HIDE]
rtc(rtc): RTC commands "returns [HELP] and nothing more. Real Time Clock I'd wager unless that has another meaning"
aud: Aud command "onboard speakers and other audio functions"[HIDE]
[Help]
ptsdly(ptsd): Delay audio startup by increasing PTS
dd_banner(banner): DD banner turn on for DD Test
spdif: spdif command
adac: adac command
interdac: inter dac command
dsp: dsp command
uop: audio uop
cfg: configuration
t: test
Clip: Aud Clip
factory(fac): Factory mode
[/HIDE]
nptv(n): Nptv command "not the foggiest idea of what these do."[HIDE]
[Help]
Ycproc(ycproc): YCPROC Command
TVD(tvd): TVD Command
NR(nr): NR Command
SCART(scart): SCART Command[/HIDE]
dbs: Dbs command "not this either"[HIDE]
[Help]
init(i): Dbs init
print(p): Dbs print at once
reset(r): Dbs reset[/HIDE]
dmx(d): Demux commands "This looks like the solution, except... the one command does nothing..."[HIDE]
[Help]
query(q):[/HIDE]
memtest: Memory test[HIDE][Help]
run(r): Memory test[/HIDE]
pdwnc(pdwnc): PDWNC commands "another one that just returns [Help]. no idea what it is"
bwt: BWT command "BandWidth Testing. not what I'm looking for I don't think"[HIDE]
[Help]
init: BandWidth Testing Preliminaries
testing: BandWidth Testing (BWT)
report: BandWidth Testing Report
chgchannel: Change Channel Number
dtv: BWT for DTV
atv: BWT for ATV
cvbs: BWT for CVBS
ypbpr: BWT for YPbPr
hdmi: BWT for HDMI
vga: BWT for VGA
src: Get current input source
mtime: Set BWT measure time
pippop: BWT for PIP/POP[/HIDE]
gpio: Gpio interface "General Purpose I/O. Don't think this is what I need either as it's hardware" [HIDE]
[Help]
output(out): gpio.out [gpio num] [[0|1]]
input(in): gpio.in [gpio num]
servo(servo): gpio.servo [0-4][/HIDE]
Wake times are also over 10 seconds, and the bright blue when there's no signal is rather jarring, so I suppose I'll need to extract and modify the firmware. Can anybody help with this?
Bump I s'pose. Still stuck, so for now I'm working on other things till I find someone who can help with this. I'd rather not drop $25 on a chinese basic mainboard for the panel or whatever I can get away with paying for a dubious identical-looking universal mainboard.
So I'm at it again trying to make this work. Glad I posted everything I did since I totally forgot how to work this thing... Still need help. I'm trying to dump the firmware with u boot so I can try to modify and reupload it with my custom values.
I also have this TV and would like to disable overscan. How should I connect my PC to one of its service ports? It has two service ports: a type A USB port and some port that I think is called 'ISP' or something like that. For what it's worth, I already have several USB to RS232 adapters (male USB type A on one end of the cable, male RS232 on the other end of the cable), but this TV doesn't have an RS232 port. I've already downloaded a third-party PuTTy app ("PuTTy (Unofficial)", if I recall correctly, from the Microsoft Store).
Edit: Made a correction.
I also have an adapter that is USB type B on both ends. It is called "SharkPort", IIRC. It was designed for connecting a PC to a PlayStation 2 to transfer PS2 game save files. It *might* be a USB host-to-host adapter. It is probably USB 1.0 or 1.1.
Big love for this thread even though I'm probably useless at the moment.
I'm ambitiously following some of your footsteps to tinker with my all-but-entirely defunct Vizio E3D420VX.
Curious how this story played out though; it looks like it relies more on TV knowledge than Linux-- these settings are pretty dense.

Software Development Developing an OBD2/Canbus data logger

So I wanted to implement something like TeslaMate for my UIS7862. The idea being to be able to visualize trips, and various vehicle stats from Grafana (and maybe a live location tracker).
My original plan was to use TorquePro to log vehicle stats + GPS location, and then to send those logs to a listening webserver for storage in Prometheus and display via Grafana. I found an Automate script to hook this into HomeAssistant here: here. However, I wanted a few additional items:
I don't have a SIM card in my radio and do not normally have it connected to my phone as a hotspot, so internet connection is intermittent and I didn't want to lose data
I wanted to be able to upload to different IP addresses depending on whether I'm connected to the home network (i.e. at home) or otspot (i.e I'm driving)
I wanted to be able to store stats from the media canbus (like fuel level) that don't seem to be available on OBD-II (at least I haven't found them for my GTI)
I wanted to learn Kotlin and write a 'real' Android app
I was successful in writing an app that would send all unsent Torque data to my home server once it connects via wifi (basically reproducing Rob's Automate script), but getting the canbus data out of the radio required more work.
I decompiled 190000000_com.syu.canbus.apk and set about learning how it worked, and trying to connect my own app.
What I found so far:
Unlike the MKC/D units which appear to communicate with the canbus module via a serial port, the FYT radios seem to use I2C
The com.syu.ms.apk is responsible for the hardware communication
the com.syu.canbus.apk connects to the com.syu.ms.toolkit Intent to access hardware data.
This Service provides a getRemoteModule() procedure which seems to provide 4 different interfaces:
0: the 'Main' interface
4: the Sound interface
7: the Canbus interface
14: the 'CanUp' interface (no idea what this is)
each interface (IRemoteModule) provides 4 commands: cmd, get, register, unregister
The 'register' command registers a callback to a specific ID. That callback will be called when the value at the ID changes.
For instance, on my GTI, ID '6' of the canbus module is the fuel-level. I can register a callback at ID=6, and that callback will be called whenever the value changes
I haven't spent time to look at the other modules, nor what the 'get' or 'cmd' functions do
With the above, I now have a rudimentay application that will fetch the Fuel level from the radio (via the Canbox). My plan is to incorporate this with the OBDII capture to create a composte data-set to upload to my prometheus database. Interestingly, the com.syu.ms.toolbox only responds back to me if I use the 'com.syu.ipc.[IModuleCallback|IRemoteModule|IRemoteToolkit' descriptor.
I will make everything above available on GitHub once I've cleaned it up a bit. It should be possible to extract any canbus data the radio has (along with other internal state depending on what the other modules expose). However, what I've learned is that every CanBox has a different interface and presents diferent data, so the effort to make a generic interface would be very high and beyond the scope of what I plan to do. There are about 2500 unique CanBoxes listed in FinalCanbus. I see about 600 unique classes implementing these modules, each of which implements a different set of registerable IDs.
I plan to add an interface to register any ID if you know what you are looking for to my app. I think @surfer63 could do the same to FytHwOneKey if they were so inclined, but without a table of which features are available it would only likely benefit programmers.
I'll update this post with a GitHub link once available, but I thought there might be some interest in the canbus analysis stuff.
Here is the GitHub repository for the Canbus access library: https://github.com/AxesOfEvil/FYTCanbusMonitor
The CanBox ID is specified by ID=1000.
The low 16 bits appear to specify the canbox type, and the upper 16bits seem to represent the car make/model. This mapping happens in syu.ms.module.canbus.HandlerCanbus with the name mapping in module.canbus.FinalCanbus
Here is an example of the IDs for (some) Reise RZS CanBox to give an idea of what type of data is available:
Code:
U_CUR_OIL_EXPEND 0
U_MISC_BEGIN 0
U_LOW_OIL_WARN 1
U_LOW_BATTERY_WARN 2
U_LIFE_BELT_WARN 3
U_CLEAN_FLUIT_WARN 4
U_HANDLE_BRAKE_WARN 5
U_RESIDUAL_OIL 6
U_BATTERY_VOLTAGE 7
U_DRIVE_MILE 8
U_PARK 9
U_RADAR_MUTE 10
U_CUR_SPEED 11
U_ENGINE_SPEED 12
U_OUT_TEMP 13
U_AIR_BEGIN 14
U_AIR_POWER 14
U_MISC_END 14
U_AIR_BIG_WIND_LIGHT 15
U_AIR_LITTLE_WIND_LIGHT 16
U_AIR_AC 17
U_AIR_MAX 18
U_AIR_CYCLE 19
U_AIR_DUAL 20
U_AIR_REAR 21
U_AIR_BLOW_UP 22
U_AIR_BLOW_BODY 23
U_AIR_SHOW 24
U_AIR_BLOW_FOOT 25
U_AIR_WIND_LEVEL 26
U_AIR_TEMP_LEFT 27
U_AIR_TEMP_RIGHT 28
U_AIR_AQS 29
U_AIR_SEAT_HEAT_LEFT 30
U_AIR_REAR_LOCK 31
U_AIR_AC_MAX 32
U_AIR_SEAT_HEAT_RIGHT 33
U_AIR_TEMP_OUT 34
U_AIR_AUTO 35
U_AIR_END 36
U_DOOR_BEGIN 37
U_DOOR_ENGINE 37
U_DOOR_FL 38
U_DOOR_FR 39
U_DOOR_RL 40
U_DOOR_RR 41
U_DOOR_BACK 42
U_DOOR_END 43
U_AIR_FRONT 44
U_AIR_BLOW_MODE 45
U_CNT_MAX 46
AxesofEvil said:
I plan to add an interface to register any ID if you know what you are looking for to my app. I think @surfer63 could do the same to FytHwOneKey if they were so inclined, but without a table of which features are available it would only likely benefit programmers.
Click to expand...
Click to collapse
Nice work you are doing here.
But I do not know what you mean with above statement.
For further reading: lbdroid did some reverse engineering in 2006.
You might take a look at some of his repos: https://github.com/lbdroid/MCUd
In that github/readme are 5 other repos. They are outdated, but might still give you some clues.
surfer63 said:
Nice work you are doing here.
But I do not know what you mean with above statement.
For further reading: lbdroid did some reverse engineering in 2006.
You might take a look at some of his repos: https://github.com/lbdroid/MCUd
In that github/readme are 5 other repos. They are outdated, but might still give you some clues.
Click to expand...
Click to collapse
Sorry, maybe that was inappropriate. I guess I was thinking about ways to give users access to the canbox data since Tasker doesn't seem able to hook into services this way. One use case would be direct access to steering wheel buttons from the canbox (my understanding is that in some cases FwHwOneKey can't handle canbus related buttons...maybe I'm wrong). Or, perhaps there isn't really any use at all for this info to trigger user applications.
I know there was a request to access Canbox data for widgets (for instance to be able to display the outside temperature on a custom screen). This method should be able to support something like that, but I have no idea if there is an existing app that could make use of it. Maybe I could write a proxy that would turn service updates into system broadcast events? Just spitballing here.
Wow, it’s really communicate with canbus from user apps?
May be there is way to read can data, like we can see in develop mode
Sdese2000 said:
Wow, it’s really communicate with canbus from user apps?
May be there is way to read can data, like we can see in develop mode
Click to expand...
Click to collapse
To be clear, I only have access to whatever the canbox has already decoded (and the radio has accepted), at least on my vehicle, thee is a lot more CAN traffic that is ignored. What CAN data do you see in develop mode? I am not aware of this.
AxesofEvil said:
Sorry, maybe that was inappropriate. I guess I was thinking about ways to give users access to the canbox data since Tasker doesn't seem able to hook into services this way. One use case would be direct access to steering wheel buttons from the canbox (my understanding is that in some cases FwHwOneKey can't handle canbus related buttons...maybe I'm wrong). Or, perhaps there isn't really any use at all for this info to trigger user applications.
Click to expand...
Click to collapse
Not inappropiate at all. I just didn't get what you meant.
And yes: The BT like commands are still a big misunderstanding (for me that is). I think that could very well be a combi of activity, canbus and "something else"
But as my unit doesn't have buttons anymore, and neither my previous one, I don't spend time on my own app anymore.
AxesofEvil said:
To be clear, I only have access to whatever the canbox has already decoded (and the radio has accepted), at least on my vehicle, thee is a lot more CAN traffic that is ignored. What CAN data do you see in develop mode? I am not aware of this.
Click to expand...
Click to collapse
In Head Unit settings there is trigger, if turn on it, can logs will appear on the screen.
If found some code in com/syu/util/DebugViev.jave that provide it
Spoiler
package com.syu.util;
import android.content.Context;
import android.graphics.Canvas;
import android.graphics.Paint;
import android.support.p000v4.internal.view.SupportMenu;
import android.view.View;
import android.view.WindowManager;
import java.util.Locale;
public class DebugView extends View {
private int CELL_HEIGHT = 35;
int[] COLOR = {SupportMenu.CATEGORY_MASK, -1, -16711936, -256, -16776961};
private final int MAX = 16;
private final int TEXT_SIZE = 23;
/* access modifiers changed from: private */
public int[] mColors = new int[16];
/* access modifiers changed from: private */
public int mCount;
private boolean mDbg = false;
/* access modifiers changed from: private */
public int mLastIndex;
private WindowManager.LayoutParams mLp = ToolkitApp.buildOverlayLayoutParams(-1, -1);
/* access modifiers changed from: private */
public int mMsgCnt;
/* access modifiers changed from: private */
public String[] mMsgs = new String[16];
private Paint mPaint = new Paint();
public DebugView(Context context) {
super(context);
init();
}
private void init() {
this.mPaint.setAntiAlias(true);
this.mPaint.setTextSize(23.0f);
this.mPaint.setColor(-1);
}
public void setDbg(boolean flag) {
this.mDbg = flag;
}
public boolean isDbg() {
return this.mDbg;
}
public WindowManager.LayoutParams getWindowLayoutParams() {
return this.mLp;
}
public void msg(String msg) {
if (this.mDbg && msg != null) {
HandlerUI.getInstance().post(new MessageHelper(msg));
}
}
public void msg2(String msg) {
if (this.mDbg && msg != null) {
HandlerUI.getInstance().post(new MessageHelper(msg));
}
}
public void msgHex(String str, byte[] data, int start, int length) {
if (this.mDbg && data != null) {
if (data.length - start < length) {
length = data.length - start;
}
String msg = String.valueOf(str) + " * ";
for (int i = 0; i < length; i++) {
String c = Integer.toHexString(data[start + i] & 255).toUpperCase(Locale.CHINA);
if (c.length() < 2) {
c = "0" + c;
}
msg = String.valueOf(msg) + c + " ";
}
HandlerUI.getInstance().post(new MessageHelper(msg));
}
}
public void msgHex(String str, int[] data, int start, int length) {
if (this.mDbg && data != null) {
if (data.length - start < length) {
length = data.length - start;
}
String msg = String.valueOf(str) + " * ";
for (int i = 0; i < length; i++) {
String c = Integer.toHexString(data[start + i] & 255).toUpperCase(Locale.CHINA);
if (c.length() < 2) {
c = "0" + c;
}
msg = String.valueOf(msg) + c + " ";
}
HandlerUI.getInstance().post(new MessageHelper(msg));
}
}
private class MessageHelper implements Runnable {
private String mMessage;
public MessageHelper(String msg) {
this.mMessage = msg;
}
public void run() {
DebugView debugView = DebugView.this;
debugView.mLastIndex = debugView.mLastIndex + 1;
DebugView debugView2 = DebugView.this;
debugView2.mCount = debugView2.mCount + 1;
if (DebugView.this.mLastIndex > 15) {
DebugView.this.mLastIndex = 0;
}
if (DebugView.this.mCount > 16) {
DebugView.this.mCount = 16;
}
DebugView debugView3 = DebugView.this;
debugView3.mMsgCnt = debugView3.mMsgCnt + 1;
DebugView.this.mMsgs[DebugView.this.mLastIndex] = String.format("%06d @ %s", new Object[]{Integer.valueOf(DebugView.this.mMsgCnt), this.mMessage});
DebugView.this.mColors[DebugView.this.mLastIndex] = DebugView.this.COLOR[DebugView.this.mLastIndex % DebugView.this.COLOR.length];
DebugView.this.invalidate();
}
}
/* access modifiers changed from: protected */
public void onDraw(Canvas canvas) {
if (this.mCount != 0) {
int count = this.mCount;
int firstIndex = (this.mLastIndex - count) + 1;
if (firstIndex < 0) {
firstIndex += 16;
}
if (firstIndex + count > 16) {
int rightCount = 16 - firstIndex;
int leftCount = count - rightCount;
for (int i = 0; i < rightCount; i++) {
int index = firstIndex + i;
this.mPaint.setColor(this.mColors[index]);
canvas.drawText(this.mMsgs[index], (float) 5, (float) ((i + 1) * this.CELL_HEIGHT), this.mPaint);
}
for (int i2 = 0; i2 < leftCount; i2++) {
this.mPaint.setColor(this.mColors[i2]);
canvas.drawText(this.mMsgs[i2], (float) 5, (float) ((rightCount + i2 + 1) * this.CELL_HEIGHT), this.mPaint);
}
return;
}
for (int i3 = 0; i3 < count; i3++) {
int index2 = firstIndex + i3;
this.mPaint.setColor(this.mColors[index2]);
canvas.drawText(this.mMsgs[index2], (float) 5, (float) ((i3 + 1) * this.CELL_HEIGHT), this.mPaint);
}
}
}
}
I have updated the OP with a link to the GitHub library (here). The library is not really meant to be used standalone, but instead to be incorporated into other projects. I haven't posted the code for the logger as there is still quite a bit more to do on that side.
The library repo does include an example application which will simply log every message received to the screen/logfile (in /Downloads). It is very inefficient since it just blindly asks for every possible ID regardless of whether it is actually available for a given CanBox or not, but is meant to give a quick idea of what data is available and a short example of how to use the library. The latest compiled APK can be found here: https://github.com/AxesOfEvil/FYTCanbusMonitor/releases
I found this interesting tidbit today:
It seems to be that arbitrary commands can be sent to the canbus through the radio via sys.ms by calling ToolkitDev.writeMcu(0xE3, PID, data-len, data0, data1, ...) (where data can be 1-8 bytes).
Edit: ToolkitDev.writeMcu(0xE3, ...) seems to write commands to the canbox module. As I don't have the source for teh module, I'm not sure how it handles these commands, but they don't g out verbatim on the canbus itself.
There is also ToolkitDev.writeCanbusDirect, but this may send commands via an OBDII dongle...Edit: this seems to just directly send raw commands to the CanBox. It is similar to the above but requires manually calculating the entire packet (including checksum)
I have not found a way to pass arbitrary data from an external app through an intent to allow other apps to send arbitrary canbus commands, but with a hacked syu.ms, it probably means I can eliminate the DynAudio AMP control box I had to make to get my audio working. And that with more hacking, it may be possible to send GPS directions and music info to the HUD.
AxesofEvil said:
The CanBox ID is specified by ID=1000.
The low 16 bits appear to specify the canbox type, and the upper 16bits seem to represent the car make/model. This mapping happens in syu.ms.module.canbus.HandlerCanbus with the name mapping in module.canbus.FinalCanbus
Here is an example of the IDs for (some) Reise RZS CanBox to give an idea of what type of data is available:
Code:
U_CUR_OIL_EXPEND 0
U_MISC_BEGIN 0
U_LOW_OIL_WARN 1
U_LOW_BATTERY_WARN 2
U_LIFE_BELT_WARN 3
U_CLEAN_FLUIT_WARN 4
U_HANDLE_BRAKE_WARN 5
U_RESIDUAL_OIL 6
U_BATTERY_VOLTAGE 7
U_DRIVE_MILE 8
U_PARK 9
U_RADAR_MUTE 10
U_CUR_SPEED 11
U_ENGINE_SPEED 12
U_OUT_TEMP 13
U_AIR_BEGIN 14
U_AIR_POWER 14
U_MISC_END 14
U_AIR_BIG_WIND_LIGHT 15
U_AIR_LITTLE_WIND_LIGHT 16
U_AIR_AC 17
U_AIR_MAX 18
U_AIR_CYCLE 19
U_AIR_DUAL 20
U_AIR_REAR 21
U_AIR_BLOW_UP 22
U_AIR_BLOW_BODY 23
U_AIR_SHOW 24
U_AIR_BLOW_FOOT 25
U_AIR_WIND_LEVEL 26
U_AIR_TEMP_LEFT 27
U_AIR_TEMP_RIGHT 28
U_AIR_AQS 29
U_AIR_SEAT_HEAT_LEFT 30
U_AIR_REAR_LOCK 31
U_AIR_AC_MAX 32
U_AIR_SEAT_HEAT_RIGHT 33
U_AIR_TEMP_OUT 34
U_AIR_AUTO 35
U_AIR_END 36
U_DOOR_BEGIN 37
U_DOOR_ENGINE 37
U_DOOR_FL 38
U_DOOR_FR 39
U_DOOR_RL 40
U_DOOR_RR 41
U_DOOR_BACK 42
U_DOOR_END 43
U_AIR_FRONT 44
U_AIR_BLOW_MODE 45
U_CNT_MAX 46
Click to expand...
Click to collapse
Where did these IDs come from? Did you find one for Illumination/Headlights?
The IDs came out of the source code for 190000000_com.syu.canbus.apk
The IDs are canbox and probably vehicle specific, so such info may be available, but you need to identify exactly what you are looking for.
Use JadX or BytecodeViewer or a similar application to analyze the apk file above, and look in app/src/main/java/module/canbus for the appropriate Canbox for your vehicle

Categories

Resources