I am new to RFID transmission and would love some help! In setting up an RFID system, the questions I have are:
1.) Can an RFID reader transmit data to a remote online server/cloud?
(e.g. an tag is read in Texas and transmitted to Vermont)
2.) Can multiple servers be hooked up to an individual reader
(e.g. if tag meets criteria 1, query server 1, if tag meets
criteria 2, query server 2)
3.) If yes to 1 or 2, does this require a specific type of reader?
Any supporting materials would be much appreciated -- this resource has been particularly useful so far Link
In general yes. Some advanced (and expensive) readers have Linux onboard and allow you to run apps inside reader. So technically you can achieve it.
Usually readers are not that smart, so they only track tags and store their info inside reader's memory to be read by any external client (com, usb or ethernet)
Most readers don't allow multiple client connections. So you primary scenario is to place one server close to reader and make it poll reader for nearby tags. Once server receive tag data from reader it then share it with other servers.
Yes.
Related
What is the difference between broadcaster and beacons? From what I understand a broadcaster is a role in the GAP which sends out advertisements which contain data and are unable to make connections. They usually work in tandem with observers. Beacons do the same thing so what is the difference?
It's a bit like asking what is the difference between a HTTP server and a Web Server. A Web Server is a computer that stores web sites which it makes available over the internet, while a HTTP server is a piece of software that implements the server part of the HTTP protocol.
A Broadcaster is a role in the GAP specification which simply sends out advertisements, just as you say. It's defined in section 2.2.2.1 of the GAP chapter (in the Core v5.3 specification). Observer is the opposite role.
The word "beacon" is not present anywhere in the >3000 pages long Bluetooth Core specification. It's a term made up by industry, presumably because it works good in marketing or is generally a good name to describe this type of product. Beacons typically send out their positions using BLE advertisements for location tracking purposes but can also be connectable for various purposes.
Broadcaster is just a technical term and Broadcasters do not have a specific product purpose, which beacons on the other hand usually have. For example, iBeacon is a product which uses a specific data format containing identifiers. This product then uses the Broadcaster role and sends this data over BLE.
There is no difference. While broadcaster is a technical term used in the Bluetooth specification, beacon is simply the name of a class of products based on Bluetooth LE technology.
I'd like to know if I can limit what cards can be read with an NFC reader. Maybe with some kind of prefix on the cards, I could say e.g. "If the card doesn't start with 90H, reject it immediately."
To be clear, I want to restrict access in a way where even if the reader itself was plugged into another computer, it still couldn't be used except with cards that I've encoded myself. Could this be done via a certain configuration to the reader? I'd really like to know if it's possible before I dive into my project.
I'm using the ACR122U USB NFC reader with RFID cards. My goal is to use it with an online application to authenticate cards and grant access to certain services.
Typical smartcard readers are rather dumb devices that only take commands from a host system (e.g. PC) and use them to access (contactless) smartcards. Hence, you cannot reprogram the smartcard reader to deny access to certain cards. Instead, this is something you would need to do on the host side (and/or card side).
So you would typically write your application (that uses the ACR122U to access cards) in a way that it only talks to certain cards. Moreover, depending on the smartcard, you might also want to setup authentication keys that are only known to your application in order to prevent access to the card from other applications.
I am working on fpga firmware, in which i want to have very fast data transfer using ethernet . I got help from FPGA forum they say that suggest designs for data transfer using light weight internet protocol (LWIP).
How this is different from transfering the data using NDIS. I will be grateful if you can suggest me some guide to interface my visual c++ application to the network guide and tranfer the data.
many greeting in advance.
LWIP is a library for talking IP on a network.
NDIS is a specification for how an OS talks to network cards.
Neither is necessarily what you appear to want.
If you want to transfer data very simply and quickly point-to-point using Ethernet, you need to understand how Ethernet works at the packet level, and form your data into some Ethernet packets. You can make up your own protocol for this if you have control over both ends of the link.
If you want to transfer the data over an existing network topology, you would be better doing it using an existing protocol. UDP/IP might be one such protocol, depending on your requirements for data-rate, latency, software complexity, reliability etc. LWIP is one library which implements UDP, so might be of use.
In Bluetooth, specifically 4.0 LE (if this changes anything), what is the way to send data both ways, from master to slave and from slave to master?
What kind of protocol is it better to design? Can you please provide an example of an application level protocol that is typically used in this scenario?
In this case, should the peripheral run two services, one used for sending data to the device and another to receive data from the device? (The "device" is the peripheral/slave).
The most forward way of doing this would be to define a custom service which defines the data types and fields and access you need as characteristics, and implement this on both the peripheral and central. If you are looking for a symmetric system, you can implement the same service on both sides. If there is differences in how the two devices access/send data, you can implement two different services, suiting your needs. Either way, you will need both the slave and master peripherals to support both GATT server and GATT client.
Depending on what you want to do, you could either push data using notifications (unconfirmed, you may miss updates on the receiving side) or indications (confirmed, the receiving side will have to acknowledge the push), or you could pull the data using read commands. You could also combine these in various ways, and you could implement access to different data in different ways in your service(s).
I recommend taking a look at the different Bluetooth Low Energy vendors' dev kits and APIs, as well as the different phone/tablet APIs and examples, depending on which platform you aim to develop on/ are familiar with.
I have an application where I have about 10,000 pieces of monitoring equipment across the US that periodically dials into a bank of 32 phone lines. I have two receivers of 16 lines each that answer the call and temporarily stores a small alpha string. I then have a computer that polls the receivers and parses the string and copies it to a database.
I am looking to replace the phone lines and the receivers with a voip solution and rewrite the software to parse the data string.
Any ideas on where to get started?
Tom's suggestion about Asterisk is a good one for the overall system.
However you will still need to decode the data sent from your remote equipment from an audio signal to a data signal. That task is what the "dem" part of Modem stands for (Modulate/Demodulate). Either you do this with a canned hardware/software package (as you are currently doing with a commercial modem) or you have to emulate the modem in software yourself which will be extremely tricky to code at the very least if you attempt it yourself (heaps of standards that you have to comply with for a general modem solution, plus the solution needs to work in real time)
For the software approach could start with this page Linmodems.org (just a something I saw on google prompted by your question). Alternatively do lots of searches on google for software modems. Getting someone else's code is the best approach for this sort of code :)
Whatever you end up doing I suspect it will be rather custom.
A good place to start is probably Asterisk PBX.
I take it you don't want to replace the modems at the client sites (the easiest thing on the server side would be each clients had its own IP software stack, and used its modem to call an ISP and establish an internet connection, and then talk to your server using TCP or UDP or HTTP or whatever).
Assuming that you don't have IP capability on the client sites, Googling suggests that the relevent technology is called "Modem over IP" or "MoIP" (which Wikipedia seems to be confusing with "Mobile over IP").
VoIP consists of SIP for signalling (e.g. for call set-up and call tear-down) plus some codecs (e.g. H.323) for traffic (encoded voice) while the call is established.
I'm guessing that MoIP can keep the SIP signalling, but needs to use some different codecs.
V.150 Modem over IP White Paper looks like an introduction to the technologies. I don't know what vendors there are.
I presume you are looking to find a way to do this without mofidying the modem hardware at your remote sites. If this is the case you will have to find or write signal processing software to demodulate the encoded signal from the modem. Fortunately, signal encodings on a modem are designed to be easy to do this with.
Maybe somebody makes software modem libaries that do this sort of thing. The other parts of the problem will be emulating the handshaking on the modem so it plays nicely with the remote sites.
If you can modify the software (really just the number to dial, but it would have to include the data you want to transfer) at the 10000 sites (not likely!), you could in theory use DTMF in the "dial" string to key the data over into Asterisk. Ok, more than a bit hackey, but it would avoid having to have a software modem. Note: you'd want a checksum!! (and maybe send it multiple times) And a way to tell the caller if it was received correctly. Like I said, hackey but cute.