Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
könntest Du für localsend kurz beschreiben, wie Du das zum Laufen gebracht hast? anonymous_writer
Von gleicher Performance hat niemand was geschrieben. Es geht lediglich ums mithalten. Wer kein Gigabite-Internet-Anschluß hat und nicht permanent große Daten im Netzwerk hin und herschiebt ist auch 2024 mit der Fenvi mehr als gut bedient.
Vor allem mit den ganzen giveaways in Bezug auf die Apple Dienste. Nativer Mobiler Hotspot und AirDrop wären mir auf einem mobilen Rechner mehr Wert als AX-Wlan.
Desktop Rechner brauch man garnicht großartig mit einziehen da gehe ich von aus das über 90% am LAN hängen.
In meinem Post geht s auch eher weniger darum das Fenvi gleich wie die Intel ist sondern eher darum das der Faktencheck seitens Arkturus nicht den Tatsachen entspricht.
Zur den Intel-Karten passt wohl die Aussage des OpenIntelWireless - Team am besten.
Is it a replacement of natively supported Broadcom Cards
No.
.... ich habe nicht behauptet, dass mein "Faktencheck" mit Blick ins Mesa-Diagramm Allgemeingültigkeit haben soll. Schön, wenns an deiner 6630 cable besser läuft, als bei meiner 7590. Ich werde die Fenvi jetzt auch nicht verschrotten, sondern habe lediglich meine hiesige Tatsachenfeststellung geschildert. Die dürfte allerdings nicht widerlegbar sein. Da habe ich wohl deutlich genug drauf hingewiesen. Pillenflitzer
Warum denn gerade die Fenvi so im zweistelligen Bereich rumdümpelt, weiß ich auch nicht so recht. Lässt sich auch nicht bewegen 5Ghz zu nutzen, außer ich schalte das 2,4 Ghz-Netz ganz ab. Vielleicht aus Solidarität mit dem H4654 der neben dem Desktop steht???
ich bin da ganz bei Dir.
Ist ja bekannt, dass die Fenvi's, baugleich BCM...NG's oder BCM...CD's nicht ganz die möglichen 865/866 Mbit/s im Hackintosh 5Ghz-Netzwerk mit 80 MHz erreichen, sie so um die 500 bis 600 erreichen, mal mehr, mal weniger. Hierbei sind die Anzeigen in der Fritz!Box-Softwre ohnehin nicht Aussagekräftig.
Dennoch funktioniert damit selbst mittels OCLP-Patches bis neuste Beta 14.4 noch alles mit dieser WLAN/BT-Karte, Airdrop in alle Richtungen (iFön und iPad zum Hacki und umgekehrt) geht alles und vieles mehr. Alle Apple-Services..., etc., pp..
Ich finde die neusten Entwicklungen Intel-Wlan ja auch nicht schlecht, wie generell alles Neue im Hackintosh-Bereich, (auch wenn ich Intel-Wlan nicht nutze), aber in wie weit ist hier der Intel-Chip betreffs der Apple-Services denn wirklich, was geht, was geht nicht, zwischen den Geräten?
Bislang war es ja so, dass WLAN ging, aber die Services eben nicht.
Natürlich braucht man hier auch von Version zu Version einen neuen Kext, aber der Intel alpha ist im Netz auch leicht zu finden.
könntest Du für localsend kurz beschreiben, wie Du das zum Laufen gebracht hast? anonymous_writer
Da ist nicht viel zu machen ausser auf jedem System das Programm zu installieren und zu starten. LocalSend gibt es für alle Betriebssysteme.
https://github.com/localsend/localsend/releases
Ergänzung: Im Appstore ist es auch zu finden. OSX und IOS.
Ist dann unter Teilen zu finden am iPhone oder ....
ich hab auf dem T460 und dem iPhone die apps gelöscht und dann nochmals aus dem Appstore neu installiert - als empfohlene Quelle. Jetzt klappt bestens. Wunderbar. Gerade mit der DW 1550 bzw. 1560 gab immer ein Lotteriespiel. Lediglich am KBL-Desktop mit der Fenvi919 geht Aidrop stabil. Dafür funzt mit der AX210 am T460 BT stabiler. Die JeTech Maus muss nicht nach jedem zweiten Boot neu angemeldet werden.
Danke nochmals für deinen Beitrag hier. anonymous_writer
Das mit BT ist mir auch aufgefallen. Intel BT 5.2 läuft äußerst stabile auch nach Sleep.
Als Variante zum AirportItlwm.kext auch mal den itlwm.kext mit dem HeliPort testen. Damit gehen unter Sonoma ein paar mehr Appledienste die in der AirportItlwm.kext Sonoma Variante nicht nicht gehen.
HeliPort für Sonoma diese Variante verwenden.
https://github.com/diepeterpan/HeliPort
Mit dem HeliPort funktioniert dann auch das Entsperren mit der AppleWatch.
ZitatDas mit BT ist mir auch aufgefallen. Intel BT 5.2 läuft äußerst stabile auch nach Sleep.
Sofort nach dem Sleep?
Nutze aktuelle ein Z690 System mit Ventura. Sleep/Wake funktioniert einwandfrei jedoch hab ich das Problem das nach dem aufwachen Bluetooth ewig brauch um hochzufahren. Unlock mit Apple Watch ist so nicht möglich das Hauptproblem ist aber eher das ich BT Tastatur und Maus nutze. Hab (denke) soweit alle richtig eingestellt aber BT brauch perdu locker 5-6sec bis es wieder da ist. Hätte nun noch testweise eine AX210 da aber der Einbau ist recht nervig.
Gibt es irgendwo eine Liste was funktioniert und was nicht?
Der Wlanpart ist mir eher unwichtig.
schau mal bitte hier
ich teile Deine Meinug habe auch der OOB Geschihte zu vie Gewicht gezollt und mit meinen blinden Blick zur intel WiFi Geschihte den WiFi6 Modus völlig ignoriert. Muss aber sagen hatte technische Möglichkeiten alles zu testen, das Ergbnis lag klar auf der Hand, und stark Kext Versio abhängig, ber gut, trotzallem werde ich mal wieder die intel WiFi6 Geschichte einarbeiten und ausbauen. Achso ja der Grund warum ich es nich hutzte, war, dass der interne USB2 Port für Blauzahn, keine Sleepmodus zu Stande kam! EGAL welches USB Mapping geamcht wird, so dass ich nur mit kastrierten Kexten arbeiten musste, dass ich nicht wollte! Aber gut, muss eben jeder für sich entscheiden, sauberes arbeiten mit langsamen Übertragungsgeschwindigkeiten 5 GHz 230 Mbit/s, oder rasantes W-Lan 6GHz 970 Mbit/s mit defektem Standby Modus.
Interesting 
Bei mir ist Intel BT nach Wake das Problem wogegen Wlan zuverlässig funktioniert.
Ich hatte am Anfang nur Wifi AX210 mit dem Airport kext Preview5 und dann 2.3.0 und einem BCM USB BT da war alles wie es soll, aber der Intel BT läuft besser auch mit dem alten Trackpad.
Also habe ich jetzt HeliPort 1.4.1 und itlwm. 2.20 alles via Intel AX210 mit dem einem Nachteil das nach Sleep BT einmal ausgeschaltet werden muss und wieder ein und dann läuft wieder alles.
An der Kiste kein Problem weil immer eine Maus mit dranhängt wegen Windows und meiner Zocker Kinder und das Keyboard wired ist.
Das WLAN läuft wesentlich schneller mit dem itlwm.kext ohne Airport und das BT ist auch besser also lebe ich damit.
(Internet war kein Problem, aber der Sync vom MBA auf den Hacky über Wlan war echt laaaangsaaaaam....)
Am Board im Bios habe ich alles mögliche an Optionen versucht und es gibt dazu viele (Energieoptionen Steuerung Bios/OS und Wecken durch USB wenn im Bios Mode etc. - habe jetzt OS Steuerung-Sleep ging aber auch wenn das wecken durch USB deaktiviert war) aber entweder geht er dann nicht in den Sleep Modus oder eben nach Wake ist BT wech, zwar wird alles angezeigt funktioniert aber nicht und muss eben einmal deaktiviert und wieder aktiviert werden.
USBMap.kext Port ist auf 255 also Intern.
Ist auch an einem Internem USB Port angesteckt da PCIE Karte und zeigt dann einen USB 2 Hub an ?
Alles anzeigenPrüft bitte mal ob die BT Ausfälle mit dem Dienst bluetoothd zusammenhängen. Sieht man in der Konsole.
Fällt dieser aus gibt es auch BT Probleme.
Auf meinem Lenovo hängen die bluetoothd Probleme mit der verbauten Webcam zusammen. Bei aktivierter Webcam gibt es massig bluetoothd Abstürzte. Deaktiviert über den USB-Port die Webcam kein einziger bluetoothd Absturz. Warum dem so ist, keine Ahnung.
Ob da Intel BT oder eine voll kompatibles BCM BT verbaut ist spielt keine Rolle, exakt das gleiche Verhalten. Die interne Webcam habe ich daher dauerhaft deaktiviert, am Lenovo Laptop, da ich die eh nie brauche. Und wenn doch kann man die ganz schnell auch aktivieren über einen Neustart.
Kein Absturz Bericht.
Ich habe aber dennoch wieder auf Airportitlwm.kext 2.3.0 und den BCM USB BT Stick gewechselt da WLAN vor Login verfügbar ist (Bildschirmfreigabe) und BT nach Sleep ohne Probleme läuft.
Ich nutze den Z490 aber eh selten eher als Backup und wie erwähnt als Gaming Station für meine Töchter wenn die im Büro abhängen wollen.
Ist ja auch einfach zu ändern jetzt:
Restart BT koppeln fertig
Hab auch keine Abstutzberichte in der Konsole zwecks bluetoothhd.
Gibt es irgendwie btw. eine Dokumentation zu -btlfxallowanyaddr?
Finde den boot-arg nirgends im Netz.
Rechner lässt sich per Bluetooth wecken aber startet dann Wifi und BT scheinbar neu. Das dauert irgendwie.
bei meinem KBL-Desktop funktioniert BT nach Sleep bestens, Kann den Rechner mit der BT-Maus von JETech aufwecken und die funktioniert dann auch wieder. scheinbar hat -btlfxallowanyaddr geholfen, BT von der Fenvi zu verbessern.
hm, netter switch, vielleicht bringt das auch die weiter, welche eine bt-tastatur im bootmenü nutzen wollen.
lg
bei meinem KBL-Desktop funktioniert BT nach Sleep bestens, Kann den Rechner mit der BT-Maus von JETech aufwecken und die funktioniert dann auch wieder. scheinbar hat -btlfxallowanyaddr geholfen, BT von der Fenvi zu verbessern.
Das mit dem Wecken via BT funktioniert bei mir wenn ich im Bios auf Energieverwaltung Bios setze und dann USB Wake einstelle.
Das Boot Arg hilft bei Problemen wenn 2 Geräte die gleiche Adresse haben:
https://github.com/acidanthera/BrcmPatchRAM#configuration
On macOS 12.4 and newer versions, a new address check has been introduced in bluetoothd, thus an error will be triggered if two Bluetooth devices have the same address. However, this check can be circumvented by adding the boot argument -btlfxallowanyaddr.
Das hier scheint bei Sleep Problemen zu helfen:
For example, to change mPostResetDelay to 400 ms, use the kernel boot argument: bpr_postresetdelay=400.
Note: Some with the typical "wake from sleep" problems are reporting success with: bpr_probedelay=100 bpr_initialdelay=300 bpr_postresetdelay=300. Or slightly longer delays: bpr_probedelay=200 bpr_initialdelay=400 bpr_postresetdelay=400.
There are a number of delays which can be changed with the following kernel boot arguments. You might change these values if you find BrcmPatchRAM is hanging during firmware load. Refer to the source for futher details on these delays.
bpr_initialdelay: Changes mInitialDelay, the delay in ms before any communication happens with the device. Default value is 100.bpr_handshake: Overrides mSupportsHandshake, firmware uploaded handshake support status. 0 means wait bpr_preresetdelay ms after uploading firmware, and then reset the device. 1 means wait for a specific response from the device and then reset the device. Default value depends on the device identifier.bpr_preresetdelay: Changes mPreResetDelay, the delay in ms assumed to be needed for the device to accept the firmware. The value is unused when bpr_handshake is 1 (passed manually or applied automatically based on the device identifier). Default value is 250.bpr_postresetdelay: Changes mPostResetDelay, the delay in ms assumed to be needed for the firmware to initialise after reseting the device upon firmware upload. Default value is 100.bpr_probedelay: Changes mProbeDelay (removed in BrcmPatchRAM3), the delay in ms before probing the device. Default value is 0.For example, to change mPostResetDelay to 400 ms, use the kernel boot argument: bpr_postresetdelay=400.
Note: Some with the typical "wake from sleep" problems are reporting success with: bpr_probedelay=100 bpr_initialdelay=300 bpr_postresetdelay=300. Or slightly longer delays: bpr_probedelay=200 bpr_initialdelay=400 bpr_postresetdelay=400.
On macOS 12.4 and newer versions, a new address check has been introduced in bluetoothd, thus an error will be triggered if two Bluetooth devices have the same address. However, this check can be circumvented by adding the boot argument -btlfxallowanyaddr.
Das bezieht sich doch aber auf die Verwendung von BrcmPatchRAM. FenviT919 nutzen doch keine zusätzlichen Kexte.
Ich hab mal ne Frage in die Runde.
Bin auf Sonoma 14.3.1 und hab mir jetzt ne Wi-Fi 6 AX210/AX211/AX411 160MHz Karte geholt.
Soweit so gut hab ich meine OpenCore mit den entsprechenden Kext versehen und die Config.plist angepasst.
Boot in Sonoma > Wifi funktioniert. BT funktioniert nicht.
Gegentest Boot auf meinem alten Monterey mit identischem Opencore: BT funktioniert.
Anbei ein paar Screenshots auch mit der Reihenfolge der Kext und den Versionen.
Hat jemand ne Idee wo das Problem bei BT unter Sonoma liegen könnte?
Ich nutze dieses Tool nicht, möglicherweise liege ich mit meiner Annahme falsch, als dort BlueToolFixup.Kext aktiviert wurde. Bitte mal deaktivieren und neu starten.
