Has anyone tried out the TP-Link CPE210 and/or CPE510 with new AREDN firmware?
Quick view of CPE210 shows it to be very similar to NanoStation Loco M2. Some differences
noted are higher TX power (27dBm max.v 24dBm), beamwidth differences, and power requirement
(16v-27vdc versus 10.5v-25v). They list power comsumption as 10.5W max which seems high
compared to Loco M2. Downside is they can't run directly from 12-14vdc
At our end there is no push to move away from Ubiquiti; it is great equipment, though
it's good to have alternatives.
Dave
I've got a 510
I have a 510, the one thing I note on it is it seems to me the manufacture may have overstated the power output (the FCC test reports several DB lower, though it looks like it was done with an "average" power meter, but the MPE Equation also shows the lower value. TP-Link Support claims that FCC allows both methods, I'm not that familar with the test myself, all I know is when reading Ubiquiti reports ive generally seen numbers ABOVE the rated power [but below the 30dbm fed max limit] )
Specifically the chip appears to be programmed to permit several db lower than max power (and I'm not aware of an offs chip amplifier at the moment on these devices, but our knowledge of them is still evolving) because of this the 510 support max power is likely going to be less than the manufacture claims when running under AREDN.
Physically, while it is a similar factor to the NanoStation and NanoStation Loco it feels a little 'cheaper' made, specifically the cap over the Ethernet port, On a TP-Link it slides off very easily, on the Ubiquiti device you have to press a release clip, I have concerns how well the TP-Link cap will stay on in the field.
On the plus side of design however, the TP-Link devices do have a grounding lug at the device, instead of insisting you run shielded cable the whole way and use it for lightning ground, you can ground the device at the top of the tower. I would however still run shielded cable because Ubiquiti has found that inducted EMI can pose an issue to frying the chips. This begs the question of what issue grounding at both sides might have at a heavy RF site (Ground loop?) (of course I've just heard of an RF site a node is going up on that the site tower rules require the CAT5e cable to be grounded/bonded at every 90 degree bend)
Personally, like you, I plan to stick with Ubiquiti hardware for now, but I do enjoy seeing another vendor in the mix just to give us some more options for hardware.
Note: The above are my own personal opinions and should not be considered to reflect the opinions of the AREDN development team.
I bought two of them for testing/ & deployment. With the issue of the DTDlink being on the second port (in at least the b01 firmware), the one at my QTH isn't being used as all of the nodes on the tower come down to an POE ethernet switch and I'm reluctant to run (even temporarily) another Ethernet cable 50 feet down the tower. The other 210 is running at a standalone site a distance away, with b01 code on it (and running very well, too).
Will the DtDLink / Ethernet port issue be resolved in the b02 firmware? If so, I'll get that puppy upgraded, swivel it 180 degrees around the tower and it'll join the beta testing fray :-)
It is a limitation in the capabilities of the hardware and operating system as currently designed and is theirfor not a bug but rather a feature to implement. We are in feature freeze (happened about 1 month prior to the beta build ) where we will not add any new features to the release path and only bug fixes. As such this will not make it into 3.15.1.0 and work has not even started on this feature in the develop tree so it's hard to say when/if this will come along.
The best bet would be to assume this is the way it will have to be for a while with this particular hardware.
Good to know - thanks for the info.
I purchased a CPE210 to further assess that model. I agree with all the above comments. I found that while TPLink says the unit will output 27dBm, the AREDN firmware only shows up to 22dBm on channel -2 (2397MHz) at 5MHz band width. This places it slightly below the Loco. The price in Canada is $85 with a POE, from a significant computer vendor - this price is attractive for a new unit, compared to Ubiquiti prices here.
Very nice to have a choice.
Rick
Hi,
I have a TP-Link CPE210 that will not will not accept a firmware update.
I am logged in to it under TP-Link PHAROS and status shows:-
Device Name CPE210
Device Model CPE210 v1.1
Firmware Version 1.3.3 Build 20160705 Rel.52453 (it allowed me to update from 1.3.0 no problem)
The firmware I am trying to upload is AREDN-3.16.1.0b02-cpe210-220-510-520-squashfs-factory
The error message is The Hardware version is not supported.
Can anyone throw some light on this please.
73's
Robert M0NVQ
It looks to be that the CPE210 v1.0 works, but the v1.1 does not. There's a discussion of the problems with the underlying OpenWRT system here: https://github.com/freifunk-berlin/firmware/issues/313
I tried rebuilding AREDN using this info, and got something that would install, but wasn't functional; I suspect my build system.
Followed your suggestion and raised a ticket. Will wait and see what happens.
73's Robert M0NVQ
I have tried:-
AREDN-3.15.1.0b01-cpe210-220-510-520-squashfs-factory.bin
AREDN-3.15.1.0b02-cpe210-220-510-520-squashfs-factory
AREDN-3.15.1.0b03-cpe210-220-510-520-squashfs-factory
AREDN-3.15.1.0b04-cpe210-220-510-520-squashfs-factory
AREDN-3.15.1.0-cpe210-220-510-520-squashfs-factory
AREDN-3.16.1.0b01-cpe210-220-510-520-squashfs-factory
AREDN-3.16.1.0b02-cpe210-220-510-520-squashfs-factory
AREDN-3.16.1.0-cpe210-220-510-520-squashfs-factory
but still get the same error message - "The Hardware version not supported" I am not sure what will happen through the ticket I raised.
Are there any later or beta versions of firmware to try for this hardware CPE210 v1.1 ?
73's Robert
Andre, K6AH
The ticket controls the status of this, any open questions, raised concerns, required testing, etc will all be in the ticket, once all concerns are addressed and reports of no issues are in the ticket the ticket can be closed and it can make its way along the development course. (Workflow is: Ticket created -> Test fix in nightly builds -> Testing -> Repeat as necessary -> Ticket closed -> Available in next supported build)