It is currently available at MediaMarkt in Germany for € 13,99, even lower than initially (still limited to two devices)
The only issue is that is has just one ethernet port and no external antenna. - But maybe we could start some tuning of the device for that price. - BTW... I just ordered yesterday 1 for 17,99€ and was angry, that after Easter-Monday the price rose from 15€-17,99€ and dropped today to 13,99€. I will try to send back the device for 17,99€. - At the moment I still compare the device with the Xiaomi RM1800 and need to say the Xiaomi-Device with the IPQ6018 chipsets is still nearly double the speed of the nice DAP- X1860. - So hopefully the drivers for the MT7915 will get an development-Improvement.
This topic was intended for adding support for this specific device.
Since official 22.03 images are available now, I will set a timer for this topic to close.
Why?
Because specific problems for this device with official releases are better handled in separate topics, in order to make finding relevant information easier. Who is going to read the previous 100-something postings, if he has a specific problem with 22.03 and wifi?
Therefore: Please open new topics for any open issues with this device.
Thanks!
Hi i just tried to flash the Version 22.03.4 using Chrome and Edge and i get to the Screen Upgrade complete! Rebooting ... but nothing happened for about 10 Minutes. I tried to reload the page and then it said Upgrade failed.
What i am supposed to do on the Upgrade complete! page?
Hi @Tiraga. If you followed this flash procedure, then LuCI should come up at http://192.168.1.1
Simply refreshing the page will not work, as you have to change your clients IP adress to something like 192.168.1.x (instead of 192.168.0.x).
Also, if this was your first time flashing the device, I hope you have used the factory.bin file.
Was this a downgrade from snapshot?
I used the first and not the second file from the firmware selection page... Now it worked, thanks!
I think the dts could be wrong here.
GPL source from D-Link says (see twproduct.h
):
GPIO_LED_POWER_OK=16
GPIO_LED_POWER_NG=8
GPIO_LED_INTERNET_OK=3
GPIO_LED_INTERNET_NG=4
GPIO_BUTTON_WIFI_ONOFF=7
GPIO_BUTTON_RESET=15
GPIO_BUTTON_WPS=18
whereas OpenWrt dts says:
led_power_red: power_red {
label = "red:power";
gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
};
led_power_orange: power_orange {
label = "orange:power";
gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
default-state = "on";
};
rssihigh {
label = "green:rssihigh";
gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
};
rssimedium {
label = "green:rssimedium";
gpios = <&gpio 23 GPIO_ACTIVE_LOW>;
};
rssilow_orange {
label = "orange:rssilow";
gpios = <&gpio 26 GPIO_ACTIVE_LOW>;
};
rssilow_green {
label = "green:rssilow";
gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
};
I might have missed it, but do you have the URL for the GPL source for the DAP-X1860 at hand?
https://dlink-gpl.s3.amazonaws.com/GPL2100068/COVR-X1860_A1_V1.01B05_GPLCode_20211119.tar.gz
(from here: https://tsd.dlink.com.tw/)
Thanks, I could only find the various manuals when searching for DAP-X1860 (and wasn't sure about COVR-X1860).
Sure.
Check FCC documents; they often use the same hardware with different model names (for different regions).
hmm, I'm not sure this one is identical. external photos are quite different...
https://fccid.io/KA2COVRX1860A1
That was my problem here, as there are differences (two ethernet ports, different for factor of the PCB). There is certainly some family resemblance, but it doesn't appear to be identical (I did see source for the DAP-1860 (802.11ac) as well, which is probably closer). But neither of my attempts got me closer to finding the GPIO for the green power LED so far (I did try the known ones used by similar devices already).
maybe ask D-Link for sources?
I had asked D-Link for sources already (using the form on the technical support download site mentioned above) for DAP-X1860, hoping they might accidentally forget a private key for firmware signing in there.
COVR-X1860 is indeed a completely different device, manufactured by SGE/T&W (thus twproduct.h
), while DAP-X1860 is made by Acelink/Edimax. The only thing they have in common is the chips used, otherwise the structure of the source code should be quite different.
I have support for COVR-X1860, but still hope the image could be encrypted (all details are known), but this might require a different format and lots of hacks, to make the UBI image be accepted by the OEM updater (which is based on OpenWrt sysupgrade).
Again: There is no green power/status LED in DAP-X1860. They incorrectly populated orange for green.
Just open the device and check the LEDs on the PCB
Maybe an issue of communication with the Chinese manufacturer ("but we want it to be red in that case, and orange in that case" -> not knowing that orange would be achieved by illuminating green and red at the same time (this is how all the other DAP wall plug repeaters do it), they apparently populated red and orange, to satisfy the customers demands )
// edit: this requires further investigation, see posts below
Weird, I was almost certain that the LED could be green (but I only had the OEM firmware running for a basic functionality check, less than half an hour - marvelling how bad an OEM webif could be) and videos about it on youtube seemed to confirm that. Thanks for confirming that there is no green LED.
I did the same thing as slh. Was running the OEM only for a very short time, 5 months ago, so my memory is foggy. I could have sworn they were green, but whatever.
Weird, I have re-opened one of the devices again to look at the PCB (currently without removing the front heatsink), and the LED placement does look a bit awkward, it seems there are three tiny dots in total, as if the bottom LED were indeed one of does dual-color ones, that change color based on polarity (i.e. two antiparallel diodes in one case).
If that is the case here, controlling the LED would be a little more challenging (e.g. if two separate GPIOs were required to turn it to green; OpenWrt does not currently support this).
But maybe the wiring is yet different, seems like heatsink needs to go and some testing with microscope & multimeter is required here
Thanks for spotting this! Seems like I only saw those two 0603 packages on the PCB, and considered those to be just two LEDs.
Turns out the bottom one is indeed a bi-color LED, mechanically connected to the upper red LED in one package, though the two are not electrically connected.
The chip on the left is the orange color that we currently use on GPIO 8, when attaching something around 3V in the other direction, it will dimly illuminate in green. So the other pin is not the +3.3V rail, but another GPIO, which probably happens to be in output high state (or just high-impedance input, if that is sufficient for driving the LED?).
So, in order to find the remaining GPIO, we cannot just try all pins and look for the LED to eventually turn green, but need to find the one that would turn the orange one off first (i.e. pull both sides down to GND) while it is illuminated. Then GPIO8 could be set to high (=turn orange off) to make it illuminate green, but they cannot be orange and green at the same time (except with PWM, but that would reduce the brightness of both).
I can spend some time on this later in the evening, currently the weather is just too nice outside
But feel free to conduct further experiments here!
Maybe we can use gpio-hog
or something on the missing GPIO to pull it low permanently, so that GPIO 8 can be changed from ACTIVE_LOW
to ACTIVE_HIGH
, to control the green rather than orange LED for the OpenWrt boot sequence, which probably looks nice and is closer to other supported DAP devices (e.g. DAP-1330, which uses green for boot and running, and red for reset / firmware upgrade etc.)
GPIO 3 is the pin for the green LED
And it is active low, just like the others - turns out the package is not two separate LEDs with one being bi-color, but three LEDs in a single package with a common anode pin, so they can indeed be controlled separately (not sure if orange is really needed though, since it can be achieved with red + green).
I'm preparing a patch to remap the led-boot
and led-running
aliases to use the green LED now, as with other DAP devices (e.g. DAP-1330)
Thanks everyone for being persistent with believing in the green LED, I must have totally missed it when adding the device