I was wondering if there is a way to make a Windows Mobile (6.5, if that matters) ignore a specific cell/tower.
The problem I'm trying to solve is that in the area I'm living in I am having issues only when connected to a specific tower (I know, this is a provider issue - they are probably having problems with that tower, but...) - so I'm trying to make my phone (HTC Touch HD/Blackstone) ignore that tower completely.
The usual suspects:
1. The radio software itself
2. The RIL (Radio Interface Layer) - is there any validation callback from the RIL when the cell configuration changes ?
TIA for any info on this matter...
As far I know you can't do anything about it. This stuff is buried deep in the radio ROM itself.
There is nothing in the standard RIL library that deals with it. The call backs are for requests for information via RIL_xxxxxxx calls. There is a possibility that it has been implemented through the driver catch all function RIL_DeviceSpecific(), but as this is defined by the OEM as the device and driver is built, you have to know the parameters to pass, and what gets delivered back to the callback routine.
Even if this stuff is there, it tends to be undocumented, and may change from OEM to another, and maybe even from one phone model to the next.
stephj said:
As far I know you can't do anything about it. This stuff is buried deep in the radio ROM itself.
Click to expand...
Click to collapse
That's what I feared ..
Thanks for the info.
Hi,
does anybody knows, where could be bug? When I establish data connection on my raphael, any incoming call or message in most cases cause reset of device. I have no idea, what to check on..
kaliginium
kaliginium said:
Hi,
does anybody knows, where could be bug? When I establish data connection on my raphael, any incoming call or message in most cases cause reset of device. I have no idea, what to check on..
kaliginium
Click to expand...
Click to collapse
Can you give more informatiom?
Is your phone GSM or CDMA?
What ROM are you using?
Have you added any other apps?
Hi! It is important if you can tell us if this is a newer problem or if this had always been the case with your device. Also, if this always happened to your knowledge, can you tell us when you had acquired the device?
Here are a few suggestions:
1) If you can back up all your files/contacts/etc. and try to flash the stock ROM, assuming you are using the original ROM. It could be possible that software could be affecting it. This would be best to wipe evrything away and begin with a cleaner slate.
2) How about, if you can do this on your own, try to install HardSPL, and flashing it to a customized ROM. Chances are if there is a bug in the stock software it could be coming from the stock ROM that is being used (if the first way does not work for you).
3) could it be a virus? I would suggest to install an anti-virus program (I use Lookout Mobile for Windows Mobile - its free and has a pretty good security suite). I can't say how effective its anti-virus program is but it has been pretty good for me. Even install one that is only a trial (ESET for Mobile, Kaspersky for Mobile, etc.) and have it scan your device. If anyone know how good Lookout Mobile is please let me know!
4) Could it be a radio firmware issue? I am not too familiar with this I would hope someone can answer this and maybe they can help you get the proper radio verison and flash it (I believe that you would need to unlock the BIOS - HardSPL basically - to ensure safe flashing of the radio firmware).
5) If the software is not a problem, chances are it could be a hardware issue, as in maybe the GSM chip is bad. I would be more inclined that it is a software problem rather than hardware but you can not rule out hardware.
This is assuming that you are using the GSM version (not CDMA version as I believe there is a separate forum for that).
I hope i am able to help you! Yes I agree with johnjctt1 - It could be an application you have installed that would be simple enough to rememdy, maybe try uninstalling each app, beginning with the newest one you had installed, and try data/voice simultaneously to see if an app was causing the reboot of the device.
Good luck and let us know the progress! This is the best advice I can give you without knowing a little more about your device. johnjctt1 was correct in asking those set of questions. I love how we all can support one another!
What exactly is it about android that makes developing new roms so difficult? For example, most ICS roms for the G2x are somewhat unstable, is that just because devs need to write drivers from scratch, or is it something else that I'm missing?
Another way of saying this would be, what makes "installing" Android different from installing Windows on a PC? (I understand Android needs to flash roms and windows can just install from a disk, but beyond that?)
Also, I don't mean to complain at all, I very much appreciate all the hard work the devs have been putting into these roms; I'm just curious what specifically makes it so challenging?
the problem most of the time comes from how the rom interacts with the hardware.
when an app needs to do something, it calls a function (for example turn on wifi) the rom gets this call and passes it to the kernel. the kernel then passes this call to the hardware which powers on the wifi.
APP>ROM>KERNEL>HARDWARE
a problem can occur at any point in that chain. the app can call a function that does not exist in that version of android, or the rom can call part of the kernel which is not there, or the kernel can try to do something that cant be done hardware wise.
oversimplifying it, porting a version of android is basically matching the function calls from the rom, to that of a kernel that works for this phone.
Now, alot of the problems we have been having with ICS on our phones is because of Hardware Acceleration. we have no offical kernel that supports it. without that we have no way for the calls from the rom to get to the hardware.
the INCREDIBLE devs at Cyanogen figured this out, they wrote those functions themselves. the part that makes this incredible is the fact that they did not know what to call, or where to send it. they had to guess at EVERYTHING! unfornately this also causes problems, while they may have gotten the functions 90% correct, 10% is still wrong. and that is what is most likely causing problems for us. (a stupid example i saw once is that they made a new brightness driver, but it was off by 1 number, so most of the brightness settings would work, but if you tried to set it to 0, it would really set it to -1 and all hell would break loose)
The reason it works so well for windows, is because when a hardware manufacturer makes a piece of hardware (wifi card) they also provide drivers that are pre-made for that version of windows, that way windows can call on standard functions, and that driver will answer those calls! unlike computers, phones very rarely switch hardware, so the hardware manufacturers only give the information of how to make drivers to the phone manufacturers
i hope you get what im trying to say.... i tend to ramble
Klathmon said:
the problem most of the time comes from how the rom interacts with the hardware.
when an app needs to do something, it calls a function (for example turn on wifi) the rom gets this call and passes it to the kernel. the kernel then passes this call to the hardware which powers on the wifi.
APP>ROM>KERNEL>HARDWARE
a problem can occur at any point in that chain. the app can call a function that does not exist in that version of android, or the rom can call part of the kernel which is not there, or the kernel can try to do something that cant be done hardware wise.
oversimplifying it, porting a version of android is basically matching the function calls from the rom, to that of a kernel that works for this phone.
Now, alot of the problems we have been having with ICS on our phones is because of Hardware Acceleration. we have no offical kernel that supports it. without that we have no way for the calls from the rom to get to the hardware.
the INCREDIBLE devs at Cyanogen figured this out, they wrote those functions themselves. the part that makes this incredible is the fact that they did not know what to call, or where to send it. they had to guess at EVERYTHING! unfornately this also causes problems, while they may have gotten the functions 90% correct, 10% is still wrong. and that is what is most likely causing problems for us. (a stupid example i saw once is that they made a new brightness driver, but it was off by 1 number, so most of the brightness settings would work, but if you tried to set it to 0, it would really set it to -1 and all hell would break loose)
The reason it works so well for windows, is because when a hardware manufacturer makes a piece of hardware (wifi card) they also provide drivers that are pre-made for that version of windows, that way windows can call on standard functions, and that driver will answer those calls! unlike computers, phones very rarely switch hardware, so the hardware manufacturers only give the information of how to make drivers to the phone manufacturers
i hope you get what im trying to say.... i tend to ramble
Click to expand...
Click to collapse
That's a very good explanation! Makes perfect sense to me.
Sure does!!!
Sent from my LG-P999 using xda premium
So you already tried everything that's available on the web to fix your Chinese phone GPS after a stock/custom ROM Flashing, and problably your device is a MT6572, MT6577, MT6582, MT6589(T), MT6592, MT6753 or any other media tek.
You already tried:
1 - The classic method, that shouldn't even be mentioned in a case like this, and felt like an idiot:
* DOWNLOAD EPO AND ENABLE AGPS.
2 - The Plan B Method: Used Faster GPS app to create or manually changed your GPS.config file.
3 - The plan C Method: Deleted mtkgps file and restarted.
4 - The plan D Method: Searched for a NVRAM file on the Web and tried to restore it using MTK Tools.
5 - The plan E Method: You downloaded/replaced the file libmnlp_mt6572 in your system/xbin folder.
6 - The plan F Method: You Downloaded/replaced the files mtk_agpsd from bin folder, agps_profiles_conf.xml from etc folder, android.hardware.location.gps.xml from etc/permissions folder, gps.default.so from lib/hw folder and mtk_stp_gps.ko from lib/modules folder.
7 - The plan G Method: Perhaps you tried some African ritual...
8 - You climbed Mount Fuji to get some signal, and had to keep your screen ON in the GPS APP during 2 hours.
9 - You tried some Native Indian ritual...
10 - You hacked you GPS Antenna, building a custom one as it is shown YouTube tutorials, and it works... for the guys who made the videos.
Your GPS was working before flashing, even if weak, so you know your hardware is not broken or something.
11 - You tried to transform into Mumm Ra the ever living!
12 - Like me, it's been over 1 week since you decided to fix this issue, and you're about to pull all your hair. In my case I'm spending hours on this, I'm really trying to get a solution.
AND NOTHING WORKED AFTER DELETING, REPLACING, DOWNLOADING.
You even learnt and tried using EXPELLIARMUS!!!
Still didn't work...
And your GPS still can't get a lock, even with all the network aid, all the tutorials you found in the web. If you religious, you even asked Jesus to help you (At least that was my case). But your phone is still the same.
Now you feel like an idiot that is never, ever again going to buy another Chinese phone anymore in your life, but you don't want to discard your phone, what you're going to do?
Well I -- STILL -- haven't found a solution, but I found a clue that may lead to a solution. Since I'm not a smart ass programmer that knows basically everything about Androids, I humbly come here now to open this discussion and see if we can finally find a solution for this problem that I believe it already annoyed at least 1 hundred people around the globe.
My clue is:
1 - I saw some people saying that when they restored their NVRAM backup after flashing the stock ROM, they got their GPS working again. So it is related to NVRAM, but with what in NVRAM?
2 - Today I was testing some hacks, when I disabled my SIM card, I the GPS TEST app could not find any satellites anymore, and I was using wifi, so it makes no sense at all, I mean, could the GPS be using the 3G/GMS/WCDMA band?
I believe the GPS device is operating in a different frequency, probably the same as the SIM CARD, and that's why people can't get a lock.
That's related to NVRAM. Perhaps with the 900/2100 and 850/2100 operator frequencies.
Let's discuss and see if we can find a definitive solution for this case, please.
Found this in another forum:
we were discussing this point also in the thread regarding unlocking the 3G bands.
it seems that neither the NVRAM nor the ROM alone has much effect regarding to the GPS, but it seems that if either one does not match the other you can also have trouble with your GPS.
how it's connected i do not know - actually as you said it should not be connected at all.
but it's pretty much clear now that the 850/2100 and 900/2100 phone have at minimum different radio hardware.
We were not able to determine how the bands were locked/opened through the firmware (since it would make sense that in theory both are available but can be turned on or off by the manufacturer, because its more expensive for MTK to produce actually different radio hardware) so that suggest that there is a hw difference. that could be connected to the GPS also.
in other threads people had reported that by upgrading the firmware they nuked their NVRAM (lost IMEIs, changing MAC address etc.) and most of them had problems with the GPS afterwards.
better safe than sorry. if you really want to try this out, please make sure to have a working backup of your NVRAM beforehand.
Click to expand...
Click to collapse
So a site about developers doesn't have a developer that could ever solve that issue?
My unit allowed me to pair multiple phones (my wife and daughter also drive) but the Bluetooth system would only reconnect to the last phone used.
So if I drove the car last, and then my wife drives, it won't connect to her phone without manually selecting it from the list of devices. It will be stuck trying to find my phone which isn't in the car.
I complained to the manufacturer about this silly bug (Atoto) and they issued an update that made it search for other phones. It seems to work pretty well now, but I'm wondering - is this normal behavior for FYT units? If so, what did Atoto do to fix it? I got a Bluetooth update file, it only flashed the BT system and not the rest of Android. I'm not sure what it did, but wondering if I purchase a different FYT unit, will I run into this yet again?
dishe2 said:
My unit allowed me to pair multiple phones (my wife and daughter also drive) but the Bluetooth system would only reconnect to the last phone used.
So if I drove the car last, and then my wife drives, it won't connect to her phone without manually selecting it from the list of devices. It will be stuck trying to find my phone which isn't in the car.
I complained to the manufacturer about this silly bug (Atoto) and they issued an update that made it search for other phones. It seems to work pretty well now, but I'm wondering - is this normal behavior for FYT units? If so, what did Atoto do to fix it? I got a Bluetooth update file, it only flashed the BT system and not the rest of Android. I'm not sure what it did, but wondering if I purchase a different FYT unit, will I run into this yet again?
Click to expand...
Click to collapse
can you confirm which update you got?
is there a specific patch name i could quote when i talk to them?
i just updaed to the 2023/02/02 release and still have this issue
It's strange they did not include this bug fix in the latest firmware update
thanks for any info you can provide
How do you check for updates?
The Bluetooth 1 system is separate from the rest of the Android OS.
Bt2 is the standard Android stack that you'd normally find on a phone or tablet, But BT1, in order to receive an incoming signal from your phone, is external hardware that exists outside of Android and seems to interface via an app that they call BT1. This does not get updated the same way as the OS does.
In other words, the firmware updates are usually only targeting the Android partition and does not update the MCU, Bluetooth, or other external components. You need to ask them for a Bluetooth update, It is performed by going into BT1 and then clicking on update Bluetooth firmware from within that screen with the file on a storage card or USB. It does not format the rest of the system, it really just update BT1 alone and can be done while the device is on. However I think that they recommend you reboot after performing the update since it is pretty heavily tied into how the rest of the radio operates.
The only thing that I don't like about the way Atoto handles customer support is their updates. They say they are going to be getting better about this in the future hopefully, but right now you need to specifically ask them for updates and there is no way to check for them.
dishe2 said:
The Bluetooth 1 system is separate from the rest of the Android OS.
Bt2 is the standard Android stack that you'd normally find on a phone or tablet, But BT1, in order to receive an incoming signal from your phone, is external hardware that exists outside of Android and seems to interface via an app that they call BT1. This does not get updated the same way as the OS does.
In other words, the firmware updates are usually only targeting the Android partition and does not update the MCU, Bluetooth, or other external components. You need to ask them for a Bluetooth update, It is performed by going into BT1 and then clicking on update Bluetooth firmware from within that screen with the file on a storage card or USB. It does not format the rest of the system, it really just update BT1 alone and can be done while the device is on. However I think that they recommend you reboot after performing the update since it is pretty heavily tied into how the rest of the radio operates.
The only thing that I don't like about the way Atoto handles customer support is their updates. They say they are going to be getting better about this in the future hopefully, but right now you need to specifically ask them for updates and there is no way to check for them.
Click to expand...
Click to collapse
i have reached out to Atoto. in order to asist in getting the correct file from them, can you please quote the filename they gave you, as a the moment they dont seem to know what i am talking about. this may help them find what it is i need.
thanks in advance
@dishe2
did it take long for you to get a response form them and the file in question?
they keep responding at the speed of only 1 email per day
between 5-6 am
constantly asking more info from me about my order
instead of telling me everything they need from me
its extreemly frustrating
have you been able to find the name of the file they shared with you?
so i can let them know exactly what I am looking for?
Maybe if you share the bluetooth update files people can review what this is about as I have not heard about BT update only.
roti86 said:
Maybe if you share the bluetooth update files people can review what this is about as I have not heard about BT update only.
Click to expand...
Click to collapse
yeah, thats all i wanted, was the file/files
at least their names
anyways, support has gotten back to me
I will provide the info I have as well as what hey expect from you in case any of you need the same fix
I figure the least I can do is share the info I have
they did not give me a file to be used in the BT files menu
wha they gave me was a config.txt and lsec6316update
lsec6316update appears to be the same file that is found in a normal update and triggers an actual update process
config.txt seems to simply contain system values and their configs, some of them not even available in the hidden menu
_____the config.txt appears to be specific to your device model
this did seem to trigger a "normal" , "full" update
but as soon as it hit the fastboot/adb/update screen
it simply seemed to apply the config file and then ask to unplug the drive
it then proceedd to boot
after booting the unit will now still search for last connected phone
but if not found within ~10-15 seconds
it tries the next one in the list and so on
I have reached back to support to thank them and ask about future updates
I still sont know if this "change" will be included in the next firmare update or not
or
if at that time a different "fix" may be needd
or
if you simply need to include the config file with the nex upate, as that seems to just be part of the structure
I will follow up when i ge more answers from Atoto
now for details needed when reaching out to them
so you dont have to struggle like I did 1 email at a time with no insight
1- screenhot of the "about device" in sysem showing the MCU version
2- further deails of the MCU by tapping 4 times and scrolling to the bottom of the black screen with all the details
3- date and vendor/site your unit was ordered from
4- order number
5- exact full model number of your unit
6- screenshot showing order and unit exact model
Bluetooth reconnects OK for me, but only on days ending with y
Uis7862 mcu type 116 fyt. Rock on.
pchtc said:
they did not give me a file to be used in the BT files menu
wha they gave me was a config.txt and lsec6316update
lsec6316update appears to be the same file that is found in a normal update and triggers an actual update process
config.txt seems to simply contain system values and their configs, some of them not even available in the hidden menu
_____the config.txt appears to be specific to your device model
Click to expand...
Click to collapse
Would you care to share the contents of the config.txt file?
That appears to be something I haven't seen before.
j0hn83 said:
Would you care to share the contents of the config.txt file?
That appears to be something I haven't seen before.
Click to expand...
Click to collapse
here are the contents of theconfiguration file
nothing really sands out in terms of a parameter that would forcefully scan other paired devices, but its working now
pleas keep in mind that my unit is an A6 PF (performance)
#test
ro.fyt.launcher = com.android.launcher8
sys.fyt.bluetooth_type=1
ro.sys.touchGesture=1
sys.fyt.systemobd=true
persist.lsec.enable_a2dp=true
ro.lsec.btname=Bluetooth 2
ro.fyt.subwoof=5
ro.fyt.message=0
sys.fyt.ec_version=6
persist.sys.ahd = 1
ro.build.go_lasttop=true
ro.fyt.splitscreen=0
sys.fyt.bluetooth_show_voice=true
persist.fyt.alwaysshowsim=false
persist.fyt.showgesture=false
persist.btpair.ssp=1
ro.fyt.amsens=22
ro.fyt.def.sb.aux=2
ro.fyt.def.sb.radio=9
ro.fyt.def.sb.player=5
persist.bta2dpvol.gain=7
persist.fyt.buildnumber=AICE UI 11.0
persist.fyt.productseries=Device Name:ATOTO A6 Performance
ro.fixed.wifi=1
ro.fyt.uiid=2
persist.fyt.enablebtvoice=true
ro.fyt.backcar_radar_enable=0
# persist.syu.backui3rd = true
persist.btmic.gain=4
persist.btautoconnect.count=3
persist.syu.single360=false
bt#ATOTO#0000
# true/false ÊÇ·ñµÚÈý·½µ¹³µÓ¦Óã¬Ä¬ÈϹØ(false)
# sys.syu.reserving_service_pkg = "com.envo.mono.android"
#µÚÈý·½µ¹³µÓ¦ÓðüÃû ±±¾©Ë«÷Ùöè°üÃû£º"com.sjs.vrbackcarapp"
# sys.syu.reserving_service_action = "com.envo.mono.android.service.MonoService"
#µÚÈý·½µ¹³µÓ¦ÓÃaction ±±¾©Ë«÷Ùöèaction£º"com.sjs.vrbackcarapp.AutoStartService"
Thanks for sharing. I don't understand coding but it seems its specific for ATOTO A6 Performance. I suppose its not a copy paste for others units. It has to be adapted. I wonder why other manufactures don't apply a patch like this. Could it be hardware related?
Battoussai said:
Thanks for sharing. I don't understand coding but it seems its specific for ATOTO A6 Performance. I suppose its not a copy paste for others units. It has to be adapted. I wonder why other manufactures don't apply a patch like this. Could it be hardware related?
Click to expand...
Click to collapse
I think it is the property "persist.btautoconnect.count=3".
If you can't find the first, go to the 2nd, and optionally go to the 3rd
surfer63 said:
I think it is the property "persist.btautoconnect.count=3".
If you can't find the first, go to the 2nd, and optionally go to the 3rd
Click to expand...
Click to collapse
Hello Surfer63.
Sorry for this and i'm trying not to be a PITA but your code skills are impressive so my question (and feel free to don't reply) is:
My config.txt only contains this:
bt#VW-PHONE#0000
ro.fyt.launcher=com.android.launcher6
sys.fyt.bluetooth_type=6
sys.lsec.carplay.OTGHdPort=3
sys.syu.dvd_external=1
persist.fyt.selectcolor=3
# ÅäÖÃÀ¶ÑÀÀàÐÍ
# 0£ºÄÚÖÃÀ¶ÑÀ£»
# 1£ºRDA£»
# 2£ºIVT£»
# 3£ºWQRDA£»
# 4: WQBC5
#
sys.syu.dvd_external (9853Íâ¹ÒµúºÏ) 0,1
Should I edit and add the line you refered to "persist.btautoconnect.count=3" after the "persist.fyt.selectcolor=3"? Or it is not that simple?
Thanks in advance.
Battoussai said:
Should I edit and add the line you refered to "persist.btautoconnect.count=3" after the "persist.fyt.selectcolor=3"? Or it is not that simple?
Click to expand...
Click to collapse
First of all: I am not sure that this is the correct property. This one is also new to me, but it is not one of the other properties. So it is an educated guess that this is the correct one.
It doesn't matter where you put the line. There is no specific order. So you can put the line wherever you want in the config.txt.
Hey, OP here. Just wanted to clarify a few things:
I originally asked the question because it came to my attention that the Atoto units handle Bluetooth a little bit differently than other FYT devices.
I was curious to see how others handle it and if they have the same reconnect issues that the Atoto ones do. I'm fairly certain that very little (if anything) would translate over to other brands, however I'm not fully aware of how other brands do it (I've owned 4 Atoto units so far and can't vouch for any others aside from what I've read here). And even stranger, the "fix" differs between Atoto's own devices (the A6 PF is a 8581 devices, and the S8 is a 7862- I own both units and both have BT updates to change how this works after I explained the problem to them, however the updates are very different).
In Atoto's platform, there are two bluetooth UIs:
1) BT2, which is the standard Android Bluetooth stack. It can be used like any other BT connection in an Android device, good for things like a keyboard or other input devices, OBDii dongles, file transfers, internet tethering, etc.
2) BT1, which is a customized Bluetooth UI to act as a receiver (all the headunit-related functions such as handsfree calls and streaming audio, which aren't part of the AOSP Bluetooth stack). They call this custom one BT1, while the standard Android Bluetooth system gets demoted to BT2, probably because they assume this is the most often used one for anyone expecting headunit-style functionality.
I'm not familiar with other FYT units, but it is my understanding that they have only one unified Bluetooth system, and it is likely a customized one only which is why I see people complaining about only being able to use "official" branded OBD readers instead of allowing any standard BT connection like Atoto (@surfer63, is that about right?).
I'm not 100% sure how it works, but it appears that BT1 might actually rely on separate hardware that exists externally from the rest of the Android system, and only interfaces with it via an app (similar to the way the FM tuner works). Essentially it is a Bluetooth receiver that goes into the MCU mixer and controlled inside the app called BT1. The proof to me that this is the case is that:
1) You can "see itself" when searching for bluetooth devices in BT2. I haven't tried this because it feels like a paradox that would unravel the universe at first, but apparently BT2 can see BT1 as an available Bluetooth speaker, and connect to it for audio.
2) After a factory reset, BT1 retains its paired devices information (because it exists outside of Android).
3) BT1 UI has its own "reset" and sometimes even "update" function (S8 Ultra, more on that in a minute), which implies it is operating on a different set of rules than the rest of the system.
When they initially made the update for my S8 Ultra, I was given a file to "flash the firmware of the bluetooth module". It is NOT a system update, but an update that must be initiated only inside of BT1. It does not effect the rest of the system, it does not even reboot the system. You click update, wait for it to finish, then click reset Bluetooth for good measure.
On the A6 pf (5851 device), I was given an actual firmware update to test when they "fixed" it. And not just a new lsec6316update and config file, but a full blown update. It could be that the rest of the update wasn't necessary and just a line in the config was changed, but I'd doubt that since they said the unit currently did not work the way I asked, and their engineers had to "work on a fix".
Either way, the bottom line here is that the Atoto units work different from each other (S8 vs A6 pf) and both of those work differently from every other FYT device I think, so none of this is cross-device useful IMO. I believe this is why they recommended I tell people to contact customer support rather than share the fix online for others, it appears to be very device specific. And for the record, it works much better on the S8 than the A6. The A6 gets stuck if it sees the previous device when it boots up, whereas the S8 can tell when it gets disconnected to start searching for other previous devices. The systems don't work the same way.
dishe2 said:
I'm not familiar with other FYT units, but it is my understanding that they have only one unified Bluetooth system, and it is likely a customized one only which is why I see people complaining about only being able to use "official" branded OBD readers instead of allowing any standard BT connection like Atoto (@surfer63, is that about right?).
Click to expand...
Click to collapse
The FYTs do indeed have one BT app and a "crippled" bluetooth stack. As I do not have an Atoto I can't say anything about the other parts of your theory/explanation, other then that it sounds quite logical.
dishe2 said:
.'m not familiar with other FYT units, but it is my understanding that they have only one unified Bluetooth system, and it is likely a customized one only which is why I see people complaining about only being able to use "official" branded OBD readers instead of allowing any standard BT connection like Atoto
Click to expand...
Click to collapse
Other FYT units operate the exact same.
They have 2 Bluetooth systems installed that behave the same way as your Atoto.
Either way, the bottom line here is that the Atoto units work different from each other (S8 vs A6 pf) and both of those work differently from every other FYT device I think, so none of this is cross-device useful IMO
Click to expand...
Click to collapse
The config.txt commands to change the behaviour of the Bluetooth pairing are FYT config lines and shouldn't be specific to Atoto.
I'll have a play with my unit later and try see how they change the behaviour but I suspect they will have similar outcomes.
j0hn83 said:
Other FYT units operate the exact same.
They have 2 Bluetooth systems installed that behave the same way as your Atoto.
Click to expand...
Click to collapse
@dishe2 mentions "In Atoto's platform, there are two bluetooth UIs:"
On my Mekede 500s I only have one 190000010_com.syu.bt.apk, and it doesn't have an alternative UI for "BT1" and "BT2". Neither is there an second BT apk, nor can I access it from the Settings.
This is already a 7 year old issue that prevents us to connect anything else than the "allowed" BT devices.
Can you please explain how I get to the other other UI with the standard BT functionality?
On my Mekede M500s you can access "Bluetooth 2" by using Marios shortcut app or using his FYT management centre app.
It's a completely separate Bluetooth chip to the BLINK Bluetooth app that handles calls (190000010_com.syu.bt.apk).
The 2 Bluetooth devices have different mac addresses.