DW1830 wifi performance issues

[filequit]

syscl -

I got the DW1830 card as reccomended by you and am having some performance issues with it in sierra 10.12.3. It appears I can only get around 30mbit/s downstream on 5ghz, and 60mbit/s downstream on 2.4ghz . In windows i get full 300mbit download speed from my ISP with this card. Anything I am missing on my set up? I've included a debug output of deploy.sh . Any help would be appreciated

debug.txt

[furrybanana]

Hi,

I connected the 2 antennas on pin 1 and 2. Did you remove the tape on the antennas near the hinge?

Here is a speedtest on my 5GHz:

Possible error (and a joke): Do you use the new LG 5k Montior for Apple products? :) http://www.techradar.com/news/lgs-5k-monitor-for-macs-doesnt-like-being-near-routers

[filequit]

I resecured the tape on the hinge after connecting the antennas. I plugged them in the same position as the dw1820 it replaced, black cable plugged into where black triangle is, white cable plugged to where white triangle is on the label. I get full throughput of the card when I use win 10. Seems like you are having performance issues too. I wish I was rich enough for those 5k monitors to be the problem :) .

If you need any additional command output, feel free to let me know and I can provide. It's been several years since I did my last hackintosh but I'm comfortable in Linux environments so not afraid of the terminal.

On Feb 13, 2017 6:26 AM, "furrybanana" notifications@github.com wrote:

Hi,

I connected the 2 antennas on pin 1 and 2. Did you remove the tape on the antennas near the hinge?

Here is a speedtest on my 5GHz: [image: wifi_speeds] https://cloud.githubusercontent.com/assets/25349617/22883318/f28a44d8-f1ef-11e6-8f65-5bd07a00e0e2.jpg

Possible error (and a joke): Do you use the new LG 5k Montior for Apple products? :) http://www.techradar.com/news/lgs-5k-monitor-for-macs- doesnt-like-being-near-routers

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/syscl/XPS9350-macOS/issues/56#issuecomment-279374662, or mute the thread https://github.com/notifications/unsubscribe-auth/AYiKHa4WBvuQ2K6Zm27iokbK9dJVttcKks5rcEvcgaJpZM4L-i57 .

[mircoianese]

Follow. I ordered the same card and I'm interested in this 👍

[svindled]

@furrybanana @filequit try putting the white antenna on the grey triangle and the black one on either white or black. I get full wifi throughput in macOS like this. I haven't tested in Windows.

[filequit]

@squash- I tried it with grey/white and grey/black and still same results. what is odd is that the 2.4ghz performs better than the 5ghz, when typically its the opposite. Did you just follow latest deploy.sh from syscl or did you modify any other kexts?

[R1MnTnA]

@filequit I'm assuming you also checked your router settings, correct? I was not getting very good speed with my DD-WRT configuration so I had to change a few things on that to make it work for this card and MacOS. For example it doesn't like dd-wrt setting of Channel Width = VHT (80+80 MHz).

[filequit]

@R1MnTnA - that did fix the issue. However that means I won't be able to run at full ac bandwidth that my Netgear r7000 offers and some of my other clients (including this card) can take advantage of. Is this just a bug with the fakepciid kext or is it an incompatibility with OS X? Would hooking up the third antenna lead resolve the problem?

[filequit]

I should also note that while I'm getting close to 200mbit speeds on 5ghz now, it's still less than the 300mbit speed I get from my ISP and could obtain with 80mhz wide channels in Windows with the same card

[R1MnTnA]

@filequit wow I can't believe I guessed that was the same problem I had and you have the same router I do! Lol :-D cool. Yeah man I know it sucks don't know why Mac can't see it or use the 80mhz channel, but like you said Windows can. I don't know if it's a bug or if can be fixed. I doubt hooking up a 3rd antenna wire would fix the issue, because we know it works fine in Windows without it, so it's most likely the kext or some type of incompatibility in MacOS.

[filequit]

I did try removing the broadcom fakepciid kext and saw it reported as third party wireless card in system profiler, but still same performance degradation once I kick up to 80mhz channels. Im thinking it may be something with the airportbrcm4360 kext and the dw1830 running in 80mhz mode.

[R1MnTnA]

And now that I remember, my previous MacBook Pro (a real one) had no problems with the 80mhz. It was very fast. Unfortunately I don't have that MacBook anymore, so unfortunately I can't get any info to maybe help troubleshoot this problem, but maybe if someone else has one and is running on the same router setup, we could possibly get some useful info to fake it or modify a kext or patch the OS so this DW1830 could work.

[R1MnTnA]

@filequit I think I may have found the answer to our problem. Although I can't try this now, but maybe you can. - Someone on the forums had the same issue, here is what he did- Changed the country code. - https://www.tonymacx86.com/threads/guide-airport-pcie-half-mini-v2.104850/page-143#post-1127441

[R1MnTnA]

Something like this might work as well. - http://apple.stackexchange.com/questions/9768/change-mac-os-x-wireless-card-country-code/129681#129681

[syscl]

@R1MnTnA Nice! I will look into it and add the patches if it works.

Thank you, syscl

[syscl]

Hi @filequit @furrybanana @ZombieTheBest @squash- @R1MnTnA Please try the latest config.plist under my Clover/

Here's the new patch I add in the config.plist

<dict>
    <key>Comment</key>
    <string>AirPortBrcm4360 5Ghz US-FCC</string>
    <key>Disabled</key>
    <false/>
    <key>Find</key>
    <data>QYP8/3QsSA==</data>
    <key>MatchOS</key>
    <string>10.11,10.12</string>
    <key>Name</key>
    <string>AirPortBrcm4360</string>
    <key>Replace</key>
    <data>ZscGVVPrKw==</data>
</dict>

Thanks for @R1MnTnA 's tip, this patch fix my Precision M3800 slow Wi-Fi issue, though I haven't had Wi-Fi issue on XPS 13 9350(maybe I'm in United States?).

Wish this help! syscl

[R1MnTnA]

@syscl Excellent! Glad I could be of assistance. Obviously the guys that discovered this are truly the ones we need to thank. But Wow, That was fast! Thanks for updating this so quickly. I'll have to try it later today when I get home. I'll let you know how it goes. Thanks again!

[furrybanana]

Hi, did the latest deploy. On 5Ghz the channel changed from Channel ID 100 to 36, still at 80Mhz. Country still at US (my fritzbox should be a German wifi "standard"). I get my providers max Download tough, it's just about 120 MBit/s. Tx Rate did go down from 867 MBit/s to 351 MBit/s MCS-Index from 9 to 3 - whatever it is.

Biggest thing now: Display Brightness with F11 and F12 does not work any longer for me. :(

[filequit]

Didn't fix the slowness for me on 80mhz channel, and f11/f12 brightness broken here as well. My country code before the new config.plist showed as US in system profiler too. What is interesting is that the channel number shows as 161 then -1 which doesnt appear to be a valid wifi channel

[R1MnTnA]

@furrybanana try these patches for the keyboard brightness keys, in your DSDT. You'll have to use MaciASL or other DSDT editors and patch it manually. Go to the following thread and scroll down to Set OSIS to linux (credit ) instructions. After you do that patch then the next patch under that will be the main keyboard patch. -

https://tonymacx86.com/threads/guide-dell-xps-13-9360-on-macos-sierra-10-12-x-lts-long-term-support-guide.213141/

[R1MnTnA]

@filequit see above for keyboard patch. As for the 80mhz and 161 channel, have you set up your router as described in these instructions as well? http://www.instructables.com/id/Install-and-Configure-a-DD-WRT-Kong-Router/step11/Setup-5-GHz-80211ac-Wi-Fi/

[filequit]

@R1MnTnA - I am using the stock r7000 firmware so only setting i have is up to 600mbit/ up to 1300mbit for 5ghz (which is equivalent of 40mhz channel to 80mhz channel)

[filequit]

When trying on a different router/ISP I get still slow downloads with 80mhz channel, but upstream i was pulling over 200mbit on a fiber ISP (att gigapower)... so it appears the issue is isolated just to the downstream portion

[furrybanana]

@R1MnTnA don't know what changed, but I am waiting for a fix from @syscl - it was working before this wifi change was made. wifi seems to be worse on my 1830 since I did the last deploy.

[syscl]

@furrybanana Re dump all your ACPI tables, remove all your old and patched ACPI tables, re run the deploy.sh

That's it.

No more fixed need.

syscl

[furrybanana]

@syscl been there, done that. ;) doing it ever since, when updating your script. still does not work

[syscl]

@furrybanana I don't know what you change, brightness key has been fixed for quiet a long time.

Double check which driver you use, and if system has some other touchpad driver that cause the brightness malfunction.

syscl

[filequit]

I had to revert to the commit before you switched backlight kext to get it back for me On Sat, Feb 18, 2017 at 10:03 AM Zhou Yating notifications@github.com wrote:

@furrybanana https://github.com/furrybanana I don't know what you change, brightness key has been fixed for quiet a long time.

Double check which driver you use, and if system has some other touchpad driver that cause the brightness malfunction.

syscl

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/syscl/XPS9350-macOS/issues/56#issuecomment-280854718, or mute the thread https://github.com/notifications/unsubscribe-auth/AYiKHc7zz02J7SVp-UaMQb2nGyUCTa1bks5rdxZBgaJpZM4L-i57 .

[syscl]

@furrybanana @filequit do you have 1920x1080p model?

If yes, then I need to add id for your panel. Because I don't have 1920x1080p model, I need your help to provide correct information for me. Thank you!

Seems I forget to add PNLF id for your models. Please provid information after executing the follwing in terminal

uid=10
ioreg -n AppleBacklightDisplay -arxw0>/tmp/syscl.plist
id=`/usr/libexec/PlistBuddy -c "Print :0:DisplayProductID" /tmp/syscl.plist`
id=`printf "F%02dT%04x" $uid $id`
echo $id

I will add injector for you!

Thank you, syscl

[filequit]

MacBook-Pro:~ clayton$ uid=10 MacBook-Pro:~ clayton$ ioreg -n AppleBacklightDisplay -arxw0>/tmp/syscl.plist MacBook-Pro:~ clayton$ id=/usr/libexec/PlistBuddy -c "Print :0:DisplayProductID" /tmp/syscl.plist MacBook-Pro:~ clayton$ id=printf "F%02dT%04x" $uid $id MacBook-Pro:~ clayton$ echo $id F10T1449

[filequit]

BTW - is there any reason some of the SSDT's that are generated by deploy won't disassemble with error AE_NAMESPACE_ALREADY_EXISTS? Am I not disassembling them right in iasl? Was trying to see if there was anything in them relating to 80mhz wifi and hit a roadblock there.

[syscl]

@filequit That's what I am looking for, nice.

Try the latest deploy.sh and report here.

syscl

[syscl]

@filequit Nice to hear that.

Yes, you can explore it and I will be very happy :) Because I have exam this months and have 2 dues. So I am busy doing that.

Don't hesitate to report any of your progress, I will look into it...later.

Thank you, syscl

[R1MnTnA]

Tried the wifi patch on my XPS-9360 w/DW1830 and my 5ghz with VHT 80mhz channel width I was able to connect where as before it would not be able to, so thank you @syscl for fixing that part, but the only thing that is still strange is that it still can't get higher than 866Mbps. Still very good and I'm happy with that, although I know with other 5ghz wifi cards, I am able to get 1300Mbps. Not sure, but starting to wonder if it could be a power problem.

Edit: I think it's because we don't have a grey wire hooked up to it. The grey connection is used for MIMO - multiple-input and multiple-output - "It's a method for multiplying the capacity of a radio link using multiple transmit and receive antennas to exploit multipath propagation." Quoted from here. - https://en.m.wikipedia.org/wiki/MIMO

[syscl]

@R1MnTnA What's the output on your XPS 13 9360?

uid=10
ioreg -n AppleBacklightDisplay -arxw0>/tmp/syscl.plist
id=`/usr/libexec/PlistBuddy -c "Print :0:DisplayProductID" /tmp/syscl.plist`
id=`printf "F%02dT%04x" $uid $id`
echo $id

Thank you, syscl

[furrybanana]

@syscl @filequit working again. thank you very much 👍

echo $id on my 1920x1080p was the same as @filequit 's one: F10T1449

/EDIT: Full/ max brightness after reboot, does not save brightness state like it did before.

[R1MnTnA]

@syscl id: F10T144a

[R1MnTnA]

@syscl @filequit please see my comment that I edited above, about the wifi issue.

[syscl]

@furrybanana Do you use rc script? Install latest Clover choose 'RC Script'.

syscl

[R1MnTnA]

@syscl do you include this patch for Coredisplay for QHD resolution in your script? sudo perl -i.bak -pe 's|\xB8\x01\x00\x00\x00\xF6\xC1\x01\x0F\x85|\x33\xC0\x90\x90\x90\x90\x90\x90\x90\xE9|sg' /System/Library/Frameworks/CoreDisplay.framework/Versions/Current/CoreDisplay sudo codesign -f -s - /System/Library/Frameworks/CoreDisplay.framework/Versions/Current/CoreDisplay

[syscl]

@furrybanana The patch for CoreDisplay is discovered by me, why do you think I don't include this patch for non-Iris QHD model(yes, Iris do not require QHD patch)?

You should pay attention to the piece of code in my deploy

function _unlock_pixel_clock()
{
    if [ $gMINOR_VER -ge $gDelimitation_OSVer ];
      then
        #
        # 10.12+
        #
        gTarget_rhd_Framework="$gMountPoint/System/Library/Frameworks/CoreDisplay.framework/Versions/Current/CoreDisplay"
      else
        #
        # 10.12-
        #
        gTarget_rhd_Framework="$gMountPoint/System/Library/Frameworks/IOKit.framework/Versions/Current/IOKit"
    fi

    sudo perl -i.bak -pe 's|\xB8\x01\x00\x00\x00\xF6\xC1\x01\x0F\x85|\x33\xC0\x90\x90\x90\x90\x90\x90\x90\xE9|sg' ${gTarget_rhd_Framework}
    _tidy_exec "sudo codesign -f -s - ${gTarget_rhd_Framework}" "Patch and sign framework for Recovery HD"
}

and here

function _getEDID()
{
    #
    # dump kext load status
    #
    local gKextStatus=$(kextstat)
    #
    # Whether the Intel Graphics kernel extensions are loaded in cache?
    #
    if [[ ${gKextStatus} == *"AppleIntelSKLGraphicsFramebuffer"* && ${gKextStatus} == *"AppleIntelSKLGraphics"* ]];
      then
        #
        # Yes. Then we can directly assess EDID from ioreg.
        #
        # Get raw EDID.
        #
        gEDID=$(ioreg -lw0 | grep -i "IODisplayEDID" | sed -e 's/.*<//' -e 's/>//')

        #
        # Get native resolution(Rez) from $gEDID.
        #
        # Get horizontal resolution. Arrays start from 0.
        #
        # Examples:
        #
        # 00ffffffffffff004c2d240137314a4d0d1001036c221b782aaaa5a654549926145054bfef808180714f010101010101010101010101302a009851002a4030701300520e1100001e000000fd00384b1e510e000a202020202020000000fc0053796e634d61737465720a20
        #                                                                                                                     ^
        #                                                                                                                 ^^
        #                                                                                                                           ^
        #                                                                                                                       ^^
        gHorizontalRez_pr=${gEDID:116:1}
        gHorizontalRez_st=${gEDID:112:2}
        gHorizontalRez=$((0x$gHorizontalRez_pr$gHorizontalRez_st))
        #
        # Get vertical resolution. Actually, Vertical rez is no more needed in this scenario, but we just use this to make the
        # progress clear.
        #
        gVerticalRez_pr=${gEDID:122:1}
        gVerticalRez_st=${gEDID:118:2}
        gVerticalRez=$((0x$gVerticalRez_pr$gVerticalRez_st))
      else
        #
        # No, we cannot assess EDID from ioreg. But now the resolution of current display has been forced to the highest resolution as vendor designed.
        #
        gSystemRez=$(system_profiler SPDisplaysDataType | grep -i "Resolution" | sed -e 's/.*://')
        gSystemHorizontalRez=$(echo $gSystemRez | sed -e 's/x.*//')
        gSystemVerticalRez=$(echo $gSystemRez | sed -e 's/.*x//')
    fi

    #
    # Patch IOKit/CoreDisplay?
    #
    local gIntelGraphicsCardInfo=$(ioreg -lw0 |grep -i "Intel Iris Graphics" |sed -e "/[^<]*<\"/s///" -e "s/\"\>//")
    if [[ "${gIntelGraphicsCardInfo}" == *"Iris"* ]];
      then
        #
        # Iris version, no IOKit/CoreDisplay patch require
        #
        gPatchIOKit=${kBASHReturnFailure}
      else
        if [[ $gHorizontalRez -gt 1920 || $gSystemHorizontalRez -gt 1920 ]];
          then
            #
            # Yes, We indeed require a patch to unlock the limitation of flash rate of IOKit to power up the QHD+/4K display.
            #
            # Note: the argument of gPatchIOKit is set to 0 as default if the examination of resolution fail, this argument can ensure all models being powered up.
            #
            gPatchIOKit=${kBASHReturnSuccess}
          else
            #
            # No, patch IOKit is not required, we won't touch IOKit(for a more intergration/clean system since less is more).
            #
            gPatchIOKit=${kBASHReturnFailure}
        fi
    fi
    #
    # Passing gPatchIOKit to gPatchRecoveryHD.
    #
    gPatchRecoveryHD=${gPatchIOKit}
}

That's it. syscl

[furrybanana]

@syscl

Do you use rc script? Install latest Clover choose 'RC Script'.

I did nothing special to my clover or xps. Just run your script. Ever since the intel backlight was added I had problems witch backlight buttons, now it is fixed, but not after a reboot always at max 100 brightness. I don't even know what I would need them RC scripts for or how I could have activated them. Don't even have my iMessage fixed as of now. I am on the latest r4003.

I'll reset the machine and do a reinstall if I find the time for it. I plan to try the latest 1.4.13 bios too.

Fixes- N/A Enhancements-

1. Enhance TypeC port usage
2. Stability of Dock WD15

[R1MnTnA]

@syscl and @furrybanana I think there was some confusion here on who wrote the question about the Coredisplay patch. I'm sorry syscl I had not known you had originally wrote that patch. I was just merely asking the question because it came up in the 9360 guide on the forums that someone recently posted and so I was just curious and too lazy or didn't have time to look through your script. Thanks for clarifying that info and again amazing job with writing and figuring out that patch. How long ago did you write it?

[mircoianese]

So, Slow WiFi issue has been fixed? I should still buy DW 1830 or 1560 is better? Thank you :) @R1MnTnA So, it's getting full 800Mbps troughtput in 5Ghz? :)

[kultigspritzig]

I just installed DW1830 and wifi connection is seriously bad. ping to router is in tens of seconds with packages often dropped altogether. It seems to settle sometimes and works for a short while with pings in milliseconds.

Worth noting is that my other devices at home have speeds close to 1300MBps and ping constantly in milliseconds - and it's no surprise since I use Ubiquity UniFy access point.

[mircoianese]

@kultigspritzig Using latest Deploy/config.plist? How did u connected the two antenna Wires?

[filequit]

I have resolved the problem! Changed the country to code #a from US, and applied the 94352 fcvo patch, both obtained from @the-darkvoid 's config.plist for the 9530. Getting full 867mbps as expected with two antenna leads in Sierra on my FHD 9350. I'm not sure if the fcvo one is actually needed, as I attempted both patches at once, but it is working now for me! Here are the relevant entries in my config.plist:

<dict>
                <key>Comment</key>
                <string>AirPortBrcm4360 5Ghz #a country code</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                QYP8/3QsSA==
                </data>
                <key>MatchOS</key>
                <string>10.11,10.12</string>
                <key>Name</key>
                <string>AirPortBrcm4360</string>
                <key>Replace</key>
                <data>
                ZscGI2HrKw==
                </data>
            </dict>
<dict>
                <key>Comment</key>
                <string>AirPortBrcm4360 - fcvo attempt dw1830</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                gflSqgAAdSk=
                </data>
                <key>MatchOS</key>
                <string>10.12</string>
                <key>Name</key>
                <string>AirPortBrcm4360</string>
                <key>Replace</key>
                <data>
                gflSqgAAZpA=
                </data>
            </dict>

[mircoianese]

@syscl I think you should include @filequit fix in your git! 👍

[kultigspritzig]

@filequit this fixes my issue as well, the connection seems much more stable with pings closer to 1-3ms, although every now and then I get response time in hundreds of ms. So although still not as good as under Windows, it's passable. Thanks!

EDIT: Strangely, it seems now to fallback to 2.4GHz connection more eagerly than before. Essentially it connects at 5GHz but then continues to run at 2.4GHz all the time.

[R1MnTnA]

@filequit and @ZombieTheBest He actually has the fcvo patch already, but those of us in the US had issues withe #a fix so he changed it to US. Maybe when he has time he can put in an option in the script to ask the user if they are in the US or outside the US to incorporate the correct patch.

[filequit]

My config plist did not have the fcvo patch before from deploy.sh and the country code patch made it set to us, where I am located and it didn't fix anything. Putting the fcvo patch for the 94352 and changing the country code to the global #a allowed my dw1830 to connect beyond 300mbps to 867mbps which is what is max expected with 2 antennas