In fairness to OSDP: I think IPv6 'fixes' a potential issue with IPv4 that can be solved other ways (like bit borrowing in LANs, for example), but OSDP 'fixes' Wiegand problems that cannot be fixed by 'tweaking' Wiegand otherwise.
There is adoption and its on the roadmap in a number of large enterprises. In these cases there is a valid business case for the transition. Not sure there is the same business (cyber and privacy) risk imperative in the broad market. It is also something new to sell and that takes time as well. The OSDP secure channel specification is settling down now from an international standard perspective to where you can assess compatibility and interoperability across a fairly wide feature set. All of these things point to healthy adoption imbo (in my biased opinion ;-).
In my region at least, many new tenders and bids still do not specify OSDP for new greenfiled installations. How is it like in the US and Europe when it comes to new tenders and bids? It would be interesting to know how often OSDP is actually specified.
you know the end users, they don't really have thorough knowledge. I've seen three types of tenders:
1. The first stage tender, when the end user picks the auditor/system designer and this company cannot participate in the second stage, installation.
2. The integrator creates an RFQ/RFP on an end-user behalf, makes it hard or impossible to win by someone else (corruption). Example - you require the integrator to have at least 5 ABCD certified employees, and you know that there are 3 companies in the region that are qualified. You make a deal with those guys, provide the quotes so they just need to submit the numbers and solution you have prepared. You win this bidding, they will win the next one with their customer.
3. The mix of the previous two, when the same owners use their companies to participate in the design and then implement the solution. Again, kickbacks and bribes usually involved.
And it's in any industry when the customer has a lot of money to spend.
PS that was Eastern Europe. Now, in NA, people just like, "we need access control" and the sales guy design something that installers are struggling to implement later. Usually, no professional estimators or pre-sale engineers are involved. Unless it's a 200+ door project.
Wiegand' is the 'protocol', although I've been corrected that 'protocols' are usually bi-directional where Wiegand is not.
is it wrong though to say that a given 125khz card is Wiegand encoded, and that the data read from that card is (at least when first read) in Wiegand format, even when that reader uses OSDP to communicate to the controller?
it seems sometimes Weigand refers to the wiring scheme, but sometimes to the data format, but maybe I’m confused.
TCP/IP cabling is a label that generalizes the cabling specific to ethernet.
In 2019, Wiegand is not a format. It previously also described a contactless card format, but it has not been a 'format' for many years/decades, so in common access use it describes only the data link between reader and controller.
Wiegand is essentially analog; every voltage drop on the line is registered as a 'bit' by the controller, where OSDP essentially is digital with structured, packetized data.
That's a bit of a generalization that ignores how the Wiegand / OSDP signal is modulated and timed, but it helps to visualize the difference along those lines.
You can configure readers directly using the comset command with OSDP, in addition there are a number of other commands that allow you to test, LEDs, Buzzer, and also to get reader information such as make, model, serial number and firmware independently. There is open source to be able to do this as well as the Eidola product that we provide. There is also the ability to do file transfer and update readers.
Depending on the vendor there is some configuration that can be done independently of the access control system. As Brian points out ii is easier to do for readers than controllers. At IDmachines we have developed tools specifically to fill this gap.
The problem with replacing the MR51e with the LP1501 is the limitation of inputs. If you originally used the MR51e for (2) door control with a REX and DC on each door, you'll have to install (2) LP1501's since the LP1501 only has two inputs. Also, both the LP1501 and MR62e are either POE or POE+ capable. By using POE+, that increases the 12V output on the board to 1.25A on the LP1501 and 1A on the MR62e which gives you more overall available power for a fully POE solution.
I'm still surprised Mercury didn't give the MR62e Weigand support as now we are stuck with the LP1501 for a POE and Weigand solution. I have seen OSDP to Weigand convertors for sale to mitigate the compatibility issue, just everything I have seen has been cost prohibitive.
You would have to transition to POE+ to get more power no matter what controller you were using. The MR51e doesn't natively support POE+, so you're stuck with the ~.66A output unless you use a POE+ power extractor to power the MR51e and other door equipment. The MR62e gives you ~.66A on POE and 1A on POE+, so at least the ability to deliver additional power is built in. Just sucks you also have to look at card reader compatibility now with the MR62e.
Access management vendors often do not design their own readers and credentials Controller (and vice versa), and the necessary 3rd party interoperability has been handled by Wiegand for several decades.
It should be between the readers & Controller. Since the OSDP protocol is being used in this area. correct me if i'm wrong.
(re-read this since this posting will likely be discussed next week at ISC East.)
I've not seen the A1001 do secure channel. 2017 firmware update, eh? Will retest that.
Not sure the wiring feedback is accurate. Many vendors use green/white for tx +/- and they still use red/black for +12/ground. That thing from proxy in your photo has weird cabling. Wiring is certainly a complexity, I'm not trying to claim it's all perfect.
Due to many platforms not offering nor supporting OSDP (examples like pdk, Proxy, Openpath), they will not be eligible.
However, even among those claiming OSDP support, the spec they've chosen to adopt is mixed and often not defined. For example, Verkada claims OSDP, as does their AD31 reader (test report coming next week), but they are adopting OSDP v1.0, not 'Secure Channel) OSDP v2.1.7+ that many platforms like Mercury Security and HID support.