Bluetooth HCI araştırma günlüğü: Uzman açıklama [2026]

Bluetooth bağlantısı kopuyor, log dosyasında anlamsız hata kodları görüyorsan ve HCI katmanının ne anlattığını çözemiyorsan, sorunun kaynağına inmek zorlaşır. Bu araştırma günlüğünde Bluetooth HCI düzeyinde neleri izlemen gerektiğini, hangi olayların kritik olduğunu ve ham kayıtları nasıl anlamlandıracağını açık bir akışla anlatacağım. Kendi tecrübemle söyleyebilirim ki HCI loglarını doğru okumayı öğrendiğinde, saatler süren deneme yanılmayı ciddi biçimde kısaltırsın.

Bluetooth HCI katmanını doğru okumak neden fark yaratır

Bluetooth HCI, yani Host Controller Interface, işletim sistemi ile Bluetooth denetleyicisi arasındaki haberleşme katmanıdır. Uygulama seviyesinde yalnızca bağlantı hatası görürsün; HCI seviyesinde ise komut, olay ve veri akışını net biçimde yakalarsın. Bu fark, özellikle kopma, eşleşme sorunu, düşük hız, yüksek gecikme ve enerji tüketimi gibi başlıklarda çok değerlidir.

HCI günlükleri çoğu zaman şu üç veri tipini içerir:

– HCI Command: Host tarafının denetleyiciye gönderdiği komut
– HCI Event: Denetleyicinin host tarafına döndürdüğü olay
– ACL Data: Asenkron veri taşıyan paketler

Bluetooth Core Specification, HCI katmanını yıllardır net bir çerçeveyle tanımlar. Bluetooth SIG tarafından yayımlanan çekirdek dokümanlarda bağlantı kurma, bağlantı sonlandırma, reklam paketleri, tarama ve güvenlik olayları ayrıntılı biçimde yer alır. Bu yüzden araştırma yaparken ilk kural şudur: Hata yorumunu tahminle değil, olay dizisiyle kur.

Örneğin bir bağlantı kopmasında yalnızca Disconnect Complete olayına bakmak yetmez. Ondan önce gelen RSSI düşüşü, supervision timeout, authentication failure ya da connection parameter update zinciri sorunun gerçek nedenini açığa çıkarır. Yıllar süren protokol takibim gösteriyor ki tek bir hata koduna odaklanan incelemeler çoğu zaman yanlış teşhis üretir.

Bir HCI araştırma günlüğü nasıl tutulur

Araştırma günlüğü, sadece log toplamak değildir. Asıl amaç, olayları zaman ekseninde bağlayıp tekrar eden deseni yakalamaktır. Ben bu iş için her zaman aynı iskeleti kullanırım.

Zaman damgasını merkez al

İlk adımda her kayda milisaniye düzeyinde zaman damgası ekle. Çünkü HCI sorunlarının büyük kısmı sıradan değil, sıralı olay problemidir. Tarama başladıktan kaç ms sonra reklam paketi geldi, bağlantı isteği ne kadar sürede tamamlandı, şifreleme ne zaman devreye girdi, kopma hangi olaydan hemen sonra yaşandı; bu soruların cevabı zaman çizgisinde saklanır.

Özellikle BLE bağlantılarında interval, latency ve supervision timeout ilişkisi kritik önem taşır. Bluetooth Low Energy tasarımında güç tüketimi ile tepki süresi arasında doğrudan denge vardır. Akademik enerji profilleme çalışmalarında da bağlantı parametrelerinin pil ömrünü ciddi ölçüde etkilediği tekrar tekrar gösterildi. Bu yüzden günlük tutarken yalnızca hata değil, parametre değişimlerini de kaydet.

Her oturum için cihaz kimliğini sabitle

Aynı ortamda birden fazla cihaz varsa MAC adresi, rastgele adres, public address ya da identity resolving bilgilerini not et. Aksi halde başka cihazın reklam paketini kendi test cihazınla karıştırırsın. Özellikle BLE gizlilik özellikleri açıkken adres dönüşümü kafa karıştırır.

Burada kısa bir pratik not vereyim: Eğer Android HCI snoop log ya da Linux btmon çıktısı inceliyorsan, cihaz adını değil adres davranışını takip et. Çünkü ad yayınları tutarsız olabilir, adres değişimi ise protokol mantığı içinde daha açıklayıcı bir iz bırakır.

Komut ve olay eşleşmesini birlikte incele

HCI Command Complete ve HCI Command Status olayları, komutun kaderini anlamak için temel veridir. Sadece komutu görmek yetmez. Komut gerçekten kabul edildi mi, denetleyici yoğun olduğu için reddetti mi, geçersiz parametre mi aldı; bunları olay cevabı söyler.

Sık görülen örnekler:

– LE Set Scan Enable komutu gelir, ardından Command Complete başarılı döner
– LE Create Connection komutu gelir, ardından bağlantı denemesi başlar
– Authentication Requested sonrası güvenlik olayları akar
– Disconnect komutu gelir, ardından Disconnect Complete ve reason code görünür

Bu eşleşme zinciri olmadan yapılan yorum, eksik kalır.

Hata kodlarını çıplak sayı gibi görme

Bluetooth hata kodları bağlama göre anlam kazanır. Örneğin 0x08 Connection Timeout çoğu kullanıcı için tek başına “sinyal zayıf” gibi görünür. Oysa bazı vakalarda sorun RF paraziti değil, agresif güç tasarrufu ayarı, yanlış connection interval beklentisi ya da firmware kaynaklı zamanlama problemidir.

Tarihsel saha kayıtlarında en sık görülen kopma nedenleri arasında timeout, user terminated connection, authentication failure ve remote device termination öne çıkar. Farklı çipset üreticileri kendi firmware davranışlarıyla aynı hata kodunun öncesinde farklı olay izleri bırakabilir. Bu yüzden araştırma günlüğüne sadece kodu değil, koddan önceki 10 ila 20 olayı da ekle.

HCI log analizinde adım adım inceleme yöntemi

Bir HCI kaydını anlamlandırmak için ben şu sırayı izlerim. Bu sıra, dağınık veriyi karar verebileceğin bir çerçeveye dönüştürür.

1. Olayın başlangıç noktasını seç

İlk soru şu olsun: Asıl problem ne? Eşleşme mi başarısız, bağlantı mı kopuyor, veri mi yavaş, reklam paketi mi görünmüyor? Başlangıç noktasını net koymazsan yüzlerce satır log içinde kaybolursun.

Örnek:
– Reklam paketi görünmüyor
– Bağlantı kuruluyor ama 5 saniye sonra düşüyor
– Eşleşme tamamlanıyor ama servis keşfi başlamıyor

Bu sınıflandırma analiz yönünü belirler.

2. Öncesindeki HCI komutlarını tara

Sorundan önce host hangi komutları göndermiş, buna bak. Tarama açılmış mı, bağlantı girişimi başlatılmış mı, reklam parametresi değişmiş mi? HCI seviyesinde host davranışı çoğu zaman uygulama mantığındaki hatayı ele verir.

Örneğin uygulama arka planda taramayı kapatıp hemen yeniden açıyorsa, kısa süreli görünmezlik yaşarsın. Android ve Linux tarafında toplanan saha loglarında bu tip yarış durumu sık görünür. Özellikle yoğun cihaz ortamlarında tarama penceresi ve tarama aralığı ayarları sonucu doğrudan etkiler.

3. Olay zincirini neden-sonuç ilişkisiyle kur

Bağlantı kurulumunda tipik bir zincir şöyledir:

– LE Set Scan Enable
– LE Advertising Report
– LE Create Connection
– LE Connection Complete
– MTU ya da özellik keşfiyle ilgili üst katman akışı
– Security Manager tetiklemeleri
– Veri alışverişi

Bu zincirde kırılma nerede yaşanıyor? Eğer Advertising Report geliyor ama Connection Complete gelmiyorsa RF koşulları, beyaz liste, filtre politikası ya da çakışan bağlantı denemeleri devrede olabilir. Eğer Connection Complete geliyor ama kısa süre sonra kopuyorsa supervision timeout, parametre uyumsuzluğu veya güvenlik pazarlığına bakmak gerekir.

4. Parametreleri spesifik olarak karşılaştır

Sadece olay adını değil, olay içindeki alanları da incele:

– Connection Interval
– Slave Latency
– Supervision Timeout
– PHY türü
– RSSI
– TX Power
– Encryption Change
– Error Reason

BLE tasarımında supervision timeout değeri, interval ve latency ile uyumlu olmalıdır. Uyum bozulursa kısa kesintiler bile kopmaya dönüşür. Teknik belgeler ve üretici uygulama notları bu konuda nettir: bağlantı parametresi seçimi, kararlılığı doğrudan etkiler. Kendi tecrübemle söyleyebilirim ki sahada “rastgele kopma” diye anlatılan vakaların büyük bölümü aslında kötü parametre pazarlığı yüzünden çıkar.

5. Ortam etkisini test notuna işle

Aynı logu farklı fiziksel koşullarda karşılaştır. Duvar, kalabalık 2.4 GHz ağları, USB 3.0 paraziti, kasanın metal yapısı ve pil seviyesi bile sonuç değiştirir. Intel ve diğer büyük donanım üreticileri, 2.4 GHz spektrumunda USB 3.0 kaynaklı parazitin kablosuz performansa etki edebildiğini yıllar önce teknik notlarla paylaştı. Bu veri, özellikle masaüstü ve gömülü sistemlerde çok işe yarar.

Araştırma günlüğünde şunları ayrıca not et:
– Test mesafesi
– Arada engel olup olmadığı
– Wi‑Fi kanal yoğunluğu
– Cihazların pil durumu
– Aynı anda bağlı cihaz sayısı

Sık görülen HCI sorun desenleri ve teknik açıklamaları

Bazı hata desenleri tekrar eder. Bunları tanırsan teşhis hızlanır.

Bağlantı zaman aşımı

LE Create Connection sonrası Connection Complete başarısız döner ya da bağlantı kurulduktan kısa süre sonra timeout olur. Burada önce reklam aralığı, tarama penceresi, sinyal seviyesi ve bağlantı parametresi pazarlığını incele. Düşük güçlü IoT cihazlarında agresif enerji ayarı bu tabloyu sık üretir.

Eşleşme ve kimlik doğrulama hataları

Authentication Failure ya da Pairing Failed benzeri olaylar, çoğu zaman anahtar uyumsuzluğu, yanlış IO capability bildirimi veya eski bond kaydı yüzünden çıkar. Özellikle cihaz yazılımı güncellendikten sonra eski eşleşme verisiyle yeni güvenlik davranışı çakışabilir. Böyle bir durumda bond temizleyip yeniden eşleşme test etmek gerekir.

Veri yavaş ama bağlantı kopmuyor

Burada HCI seviyesi sana PHY değişimi, veri uzunluğu güncellemesi ve bağlantı parametre güncellemesini anlatır. Eğer 2M PHY aktif olmuyor, data length extension devreye girmiyor ya da interval gereğinden yüksek kalıyorsa bant genişliği düşer. Bluetooth 5.x ile gelen iyileştirmeler teoride yüksek hız sunar; ama pratikte iki uç cihazın çipset, firmware ve yığın uyumu belirleyici olur.

Reklam paketi görünmüyor

Tarama aktif görünür ama Advertising Report gelmez. Filtre politikası, pasif tarama seçimi, yönlü reklam, gizlilik adresleri ve kısa tarama penceresi burada ana şüphelilerdir. Özellikle kısa burst reklam yapan cihazlarda tarama penceresi yetersiz kalırsa cihaz fiziksel olarak yakında olsa bile görünmez.

Bu tür teknik ayrımları düzenli test notlarıyla birleştirmek istersen, Ankara Destek gibi teknik içerik odaklı kaynaklarda benzer analiz yaklaşımını temel alman işini kolaylaştırır.

Sahada işe yarayan kayıt düzeni ve yorumlama alışkanlıkları

Ben gerçek incelemelerde logu tek başına bırakmam; yanında kısa bir araştırma günlüğü tutarım. Bu günlük çok basit görünür ama hatayı tekrar üretirken büyük avantaj sağlar.

1. Testin amacı
Bağlantı kopması mı, düşük hız mı, eşleşme problemi mi? Tek cümlede yaz.

2. Donanım ve yazılım sürümü
Çipset, işletim sistemi, firmware tarihi, uygulama sürümü. Aynı hata farklı firmware’de bambaşka sebep taşır.

3. Ortam koşulu
Mesafe, engel, pil seviyesi, yakın Wi‑Fi erişim noktaları.

4. Hata anı zaman damgası
Sorunu gördüğün saniyeyi not et. Sonra logda o noktaya dönmek çok hızlanır.

5. Öncesindeki son 20 olay
Asıl teşhis burada çıkar.

Yıllar süren saha incelemelerim gösteriyor ki düzenli günlük tutan ekipler, düzensiz log toplayan ekiplere göre çok daha hızlı kök neden bulur. Bunun nedeni basit: ham veri değil, bağlam fark yaratır.

Pratik yorumlama alışkanlıkları da önemlidir:
– Aynı testi en az 3 kez tekrarla
– Tek bir logla hüküm verme
– Başarılı oturumla hatalı oturumu yan yana karşılaştır
– Firmware güncellemesinden önce ve sonra aynı senaryoyu koş
– HCI logunu uygulama logu ve sistem loguyla eşleştir

Burada Ankara Destek okurlarına özellikle şu öneriyi veririm: Eğer kurumsal cihaz parkında Bluetooth sorunu izliyorsan, standart bir günlük şablonu oluştur. Farklı ekiplerin farklı not stili kullanması, teşhisi yavaşlatır.

Sıkça Sorulan Sorular

Bluetooth HCI tam olarak ne işe yarar?

Host ile Bluetooth denetleyicisi arasındaki komut, olay ve veri akışını yönetir. Sorun analizi için en görünür teknik katmanlardan biridir.

HCI logları hangi sorunlarda en çok işe yarar?

Bağlantı kopması, eşleşme hatası, reklam görünmezliği, düşük hız ve gecikme sorunlarında çok işe yarar.

Connection Timeout her zaman zayıf sinyal mi demektir?

Hayır. Yanlış bağlantı parametresi, firmware zamanlaması, parazit ve güç tasarrufu davranışı da aynı sonuca yol açabilir.

BLE reklam paketi neden logda görünmeyebilir?

Tarama penceresi kısa kalabilir, filtre politikası devrede olabilir, cihaz gizlilik adresi kullanabilir ya da yönlü reklam yayınlayabilir.

HCI log analizinde ilk bakılması gereken şey nedir?

Sorun anından önce gelen olay zinciri. Tek bir hata kodu çoğu zaman yeterli bilgi vermez.

HCI günlüklerini uygulama loglarıyla birlikte tutmak gerekir mi?

Evet. HCI logu alt katmanı anlatır, uygulama logu ise üst katmandaki tetikleyiciyi gösterir. İkisi birleşince teşhis netleşir.

Eğer elinde belirli bir HCI hata kodu, btmon çıktısı ya da Android snoop kaydı varsa en çok takıldığın satırı paylaş. Bir sonraki incelemede o olay zincirini satır satır yorumlayabiliriz.