I'm looking into NFC for use with Android phones and the newest iPhones. What I'm envisioning is some kind of NFC "broadcast" device plugged in via USB cable to a computer, so that it always sends out the most up-to-date information to whatever NFC-enabled phone is within close proximity. So far I've been seeing a whole lot of NFC "tags," which I assume are rather stupid devices that are pre-programmed with essentially static content. I'm wondering if there are any USB NFC devices on the market that can be more dynamic. Do such products exist? What's the best search keyword to find such a device? (What I've been searching for thusfar hasn't been turning up a whole lot of results.)
"NFC "broadcast" device plugged in via USB cable to a computer, so that it always sends out the most up-to-date information to whatever NFC-enabled phone is within close proximity" is your requirement. As I see in market there are NFC Readers with USB plugin to computer. They are active NFC devices generating 13.56MHz and mostly used for payment purposes. However they are putting these devices to ticketing, Office ID applications. When you bring your NFC Phone within this reader's proximity, the reader will read your phone's data and shall send it to the computer as encrypted data and will be verified in your Computer. In this process, phone acts as passive device while reader is active device.
You can also control this reader using your corresponding Software in computer which you wish as dynamic writing.
I think this might help you http://www.acs.com.hk/en/products/3/acr122u-usb-nfc-reader/
Related
I would like to ask for guidance on how to ideally communicate with a custom USB HID device on MacOS.
Use case
Modify a microphone volume via an external USB HID device.
Question
Can I use DriverKit (HIDDriverKit) for that or I need to use IOKit? I have read something here about audio limitation, but not sure what exactly is not supported.
DriverKit doesn’t support USB devices that manipulate audio or that
communicate wirelessly over Bluetooth or Wi-Fi. For those types of
devices, create a kernel extension using IOKit.
— Source
Would DriverKit still work in my case as I am not sending audio streams but controlling volume only?
Many thanks!
Cheers,
Tom
If I understand you correctly, you wouldn't even need to use DriverKit. (from experience: avoid it if you can!)
You can communicate with HID-compliant devices directly from user space processes. User space processes can generally also control the volume on audio devices.
So by far the easiest option would be to have a launch agent which uses IOKit matching as its launch condition so it starts up when your device is connected. Your agent can communicate with the device using the IOHIDManager API to receive events when your buttons are pressed, and then use the regular Core Audio APIs to control volume.
It doesn't have to be a launch agent, incidentally: a regular Cocoa app with a UI can do all of this as well. (And indeed, you may want to show some form of UI as feedback to the user pressing the buttons.)
I am using a raspberry pi hooked up to an PN532 NFC to print out the following information from an Android phone.
I was wondering if there is any way to also obtain the phone's number using NFC?
I am getting the impression that NFC does not allow this type of information to be present without third party tool, but I wanted to be certain whether or not this is impossible just using a PN532?
Thanks
Most mobile are primary designed as a NFC reader/writer for an end user OR as an emulated payment card in a secure section of the OS.
iOS has limited NFC support compared to Android.
For device to device communication you either need NFC Peer to Peer which iOS does not support and Android is dropping support for.
OR
You need one device to emulate a NFC card and one to be a reader/writer and iOS does not support Card emulation for anything but the OS payment App, where as Android does support card emulation.
This leaves the only common ground as the PN532 emulating a card which it can do and the mobile phone writing it's phone number to an emulated card.
The next hurdle iOS and Android don't natively broadcaster the sensitive info of their mobile number out via NFC, therefore you would have to write an App for that IF you app had permission and was able to read the phone number from the device (I'm note sure that is possible and is the subject of another question) but failing that you could just ask the user to enter in their phone number.
So overall, it might be possible to write various apps and the right software for the Raspberry Pi but a lot of work and require users to launch apps to transfer a mobile number.
I am writing the firmware for a USB HID device. When it is connected to a Windows PC (running Windows 8.1, if that makes any difference) it gets listed in Device Manager, under "Human Interface Devices", as "HID-compliant vendor-defined device". For obvious reasons it would be preferable for a nicer description to be shown.
I'd have guessed that the description would be taken from the USB string descriptor table, perhaps from the entry specified in the device descriptor as containing the product name. This doesn't appear to happen. Perhaps there is an error in my descriptors, but when I connect a USB analyser during enumeration it correctly identifies the manufacturer name, product name, and serial number string.
A little googling suggests that the Device Manager's descriptions can be controlled from a driver's .inf file, but this device doesn't have its own drivers.
Am I out of luck, or is there a way for an HID device to determine how it is described by the Device Manager? If there is, what is it?
(Related prior SO question: Rename a USB HID device under Windows. An answer to that question says that you need to write a Windows device driver to do this, but comments on the answer indicate that this shouldn't apply to HID devices, and the answerer concedes this. Unfortunately no further suggestions are to be found there. That question may actually be trying to ask essentially the same thing as I am, but if so it's ill-titled; I am not trying to rename anything.)
I am trying to connect a Bluetooth Low Energy enabled MIDI hardware to wirelessly send data to a Windows PC and get it to detect as a MIDI device in Windows. Currently, the device is able to pair with my Windows 10 laptop and I am able to read the incoming data off of it.
The same hardware is configured and working fine as a wireless MIDI device on Mac and iOS devices(which natively supports MIDI over Bluetooth). I am trying to get this feature implemented on Windows(which doesn't support MIDI over Bluetooth, although it was promised in Windows 10).
The device, when is paired, is showing up in the 'Bluetooth devices' section in device manager, I am trying to make this device showing up as a MIDI device in 'Sound, video and game controllers' section.
Any help/resources somebody can provide to help me crack this problem is highly appreciated.
Following is my current thought process to implement this.
Pair the device and read the data off of it. (Already implemented)
Create a virtual MIDI port. (Don't know how to implement this, I am currently checking out rtpMIDI)
Send the MIDI data which was read from the BLE device to the virtual MIDI port. (Still don't know how to implement this)
Any suggestions/comments on the above thought process as I am absolutely new to Windows Driver Development.
I'm looking for a very specific USB device for debugging systems that may use USB but not with a regular computer (proprietary hardware). I want a device that has a USB host controller and two USB device connections. The device to be debugged is connected to the USB host controller and one of the device connections is connected to another device with it's own host controller on it. The the other device connection is connected to a pc. The point being that all USB data travelling through the device (from the device connected to the host controller to the device connected to the first device connection) is reported to the pc.
I'll happily write software to do the logging (in fact I want to) but I can't seem to find a board like this anywhere. Can anyone help?
I have an Ellisys USB analyser, which isn't exactly what you describe internally, but does sit between a peripheral and a host and use a separate PC to collect the data.
(i.e. it has two 'B' and one 'A' connectors on it.)
Excellent product, and very helpful company.
Sniffing the USB shouldn't be too hard if you have the right hardware. And that is the tricky question. I haven't seen anything that describes the USB breakout box that you want. However I can say that this is in the realm of the following two magazines:
Nuts and Volts
Circuit Cellar
If they don't have a USB breakout box project in their archives, then at least they will have advertisements for small cheap single board computers that would have multiple USB ports that you can use for buffering the signals and reporting it back to your PC.
Alternatively is it possible to just wire your PC up to the middle of your two devices and write a custom drive that echos data back and forth while sniffing off a stream for you?
Sorry for the long delay in my reply -- I checked out one of our USB developer's toolchain, and he uses a Beagle USB Sniffer. He seems happy with it.
You're looking for a USB device with two upstream outputs. I think according to the USB spec, this is not possible. You will have two USB hosts trying to send messages and control the USB devices at the same time.
What if you were to look for a device which allowed you to view the data going through a hub via something other than a usb output?
If you're building something custom, take a look at this USB chip site. The chips are programmable via a windows application. Once you define how you want it to operate, it's saved on an EPROM on the dev board ($30-$50).
Sorry if this isn't helpful!