I'm using a Speedway Revolution R220 RFID reader from Impinj with the Speedway Connect software installed thereon. I am opening a TCP socket to the reader and am getting a list of all tag IDs read. This gets processed.
I also want to get a reading of the signal strength per tag as is possible with the MultiReader application. I'm developing an independent system running on Linux, and I can't use the MultiReader application. I just need to find a way of pulling the signal strength per tag so that I can make it visible in my application.
What should I do?
The Speedway Connect software should be able to deliver the Peak RSSI value for tag reads. You can find the documentation on that here: https://docs.impinj.com/display/PD/Speedway+Connect+Output+Settings
If you want more low-level control of the reader, it might be better to use the Impinj Octane SDK, that provides sample code for both C# (.NET, runs also in Xamarin Mono) and Java. You can see an example here:
https://support.impinj.com/hc/communities/public/questions/201142123-How-to-read-the-RSSI-value-using-Octane-SDK
Related
I want to implement a simple ble python program that will allow me to use my raspberrypi4 as a peripheral and my manjaro laptop as a central entity so I can send messages back and forth. Preferably both of these endpoints would be written python. I'm quite new to Bluetooth programming so I have tried to use the examples at pybluez (the refcomm server/client).
https://github.com/pybluez/pybluez/tree/master/examples/simple
After taking a closer look I saw this it doesn't use ble at all. Any good alternatives?
I want to create on my Linux desktop a small server listening to requests using Bluetooth. Clients (such as mobile phones or tablets) will connect to this server and exchange data back and forth.
It should be straightforward, but I'm unable to find an up-to-date tutorial for Bluez's new DBUS-based API, and Bluez documentation is basically just a huge data dump.
Any suggestions on how I should proceed? (The language used does not really matter, since there are DBUS bindings for all major languages.)
These are some useful links to get started, it's not much but it's a start.
Textual (and up-to-date) description of the DBus interfaces exposed by bluez5 : https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc
You can find example for gatt client/server in the prevous cgit at the following path : /tree/src/shared/
An overview of Bluez and it's dbus interfaces (conference given at the 2016 Open IoT Summit) : https://www.youtube.com/watch?v=tclS9arLFzk
If you need example for your dbus bindings, I suggest looking at their test files
As you said yourself, there are dbus bindings in many languages however the language does matter. For example, some old low-level C API are not advised (see for yourself the advices in the dbus tutorial on freedesktop.org)
I suggest the following steps to start (especially for LE) :
Read the adapter-api.txt (first link) description and try to build a proxy to interact the org.bluez.Adapter1 interface (when trying to build the proxy: name would be 'org.bluez' and object path '/org/bluez/hci0' as describded in adapter-api.txt). Call StartDiscovery and StopDiscovery
Once scanning is done, print your proxy introspection to find the devices discovered (you should see MAC addresses preceded by "dev_")
Build proxies to interact with the device (read the device-api.txt file description to find out what you need)
For LE, if you want to access the Services of a Device. Introspect your device proxy and you will find it'serices. Repeat the process to reach Characteristics and Descriptors.
I have a wider range question here, so if someone could point me to a doc or article that could explain this, that would suffice. Needless to say, a days worth of googling has gotten me nowhere, and I could use a helping hand.
I am connecting to a BeagleBoard with BlueZ 5.9, and my intent is to:
Create a Gatt server,
Load it up with some writeable attributes, and
Advertise that server to connect to an android device.
I've created the Android app that will connect and operate as the central, rendering 3 basically complete. I don't know how the commands - the literal things to type - to initiate a Gatt server / create attributes on the BeagleBoard. I am knew to hardware writ large, so it is possible I just have my terminology completely incorrect - that said, any help would be a appreciated in completing 1 and 2, even if it is just a shove in the right direction. Thanks!
Your terminology is mainly correct.
Typically, a GATT database has the services 0x1800 (Generic Access) and 0x1801 (Generic Attribute) at least. The Generic Access service contains two mandatory characteristics: Device Name and Appearance. The Generic Attribute service should be empty.
Therefore, the minimal GATT database looks like this:
Handle Description
0000 Service: Generic Access (1800)
0001 Characteristic: Device Name (2A00, readable)
0002 Characteristic Value (string)
0003 Characteristic: Appearance (2A01, readable)
0004 Characteristic Value (16bit enum)
0005 Service: Generic Attribute (1801)
After these two services, you can add your own services. In your case, you don't seem to target a well-known service, so you'll create an own one.
First, create a 128-bit UUID, for example using the uuidgen tool on your Mac's command line
$ uuidgen
DCDF2725-56C8-4235-A4BC-F7951D5C3762
This will be your service UUID
0006 Service: Custom defined Service (DCDF2725-56C8-4235-A4BC-F7951D5C3762)
Then, you mentioned that you want several writeable characteristics. So, let's create another UUID for that one.
$ uuidgen
4C06C6F4-C90D-4C58-8E31-20C8C74FF832
And add a characteristic to the service
0007 Characteristic: Custom Characteristic (4C06C...FF832, writeable)
0008 Characteristic Value (hex, 20 bytes)
Your characteristic value shouldn't exceed 20 bytes, and you should select "Write Request" to ensure that acknowledgments of writes are sent to the central. If you choose "Write Command", writes may be discarded by either your phone's stack or the peripheral.
After you have defined this characteristic, you are ready to start coding.
I don't know the BeagleBoard SDK, but typically, you start by initializing the GATT library and additional modules (for example, to support writes, you have to initialize a second part of the library).
After this initialization, you register your GATT database. If you don't have a nice tool for generating the binary data, you may have to write them yourselves. That's explained in the Bluetooth Core Spec V4.0. Let's hope you can find an API that does the transformation for you :-)
When the registration is successful, you'll have to set the advertising parameters and can start advertising (consult your SDK's documentation and samples for this, again).
What happens now, is that at some time, you will get a callback that a connection has been established, and later, you'll get an attribute request for a given handle. Then, you just have to process the request by looking at the handle, the supplied value and the type of the operation (read / write). Don't forget to always return a success value or an error code in response to the request, as otherwise, you'll lock up the Bluetooth communications.
Normally, those Bluetooth chips always work with asynchronous operations. You'll send a request, and then have to wait until the request is completed before sending the next one. Remember that when programming, it saves you time :-).
If you want to try on Android first because it's more familiar for you, you can try the Galaxy S 4 with Android 4.2. It also has an LE peripheral mode - I haven't tested its reliability, though. The most reliable smartphone stack at the moment to act as LE peripheral is currently in iOS 7 - so it may be worth picking up an iPod touch if it's affordable to play around with it.
Checkout bleno, it's a BLE peripheral stack library I created for node.js recently. It currently supports Linux (tested with BlueZ 4.101) and OS X 10.9.
There are examples of how to use it here and here.
The key to customize gatt service is the daemon program bluetoothd of bluez.
I have described how to customize a gatt service in my blogger, please check it.
I am experimenting with Bluetooth Low-Energy (BLE) for the purpose of connecting a hardware device to an Android application. My goal is to send a recognizable piece of data to an Android phone.
I am using the keyfob from Texas Instrument's CC2541 Mini-development kit, and am programming it using the IAR Workbench (which I am learning on the fly). My issue is that I cannot figure out what code should be used to send data from the keyfob to the phone.
I understand that this is somewhat vague, but because of the non-disclosure policies of my company I cannot share the code that I am working with. Does anyone have any references to code for the IAR Workbench that will allow the CC2541 to send a piece of data? Right now, I prefer to use GATT if that helps.
Thanks, and please ask me more questions if I need to clarify anything.
Assuming you're working from a pre-existing service profile, there is a function for every service called ServiceName_SetParameter(). Calling that function will change the characteristic value. When the characteristic is read by the phone, it will receive this value. If the characteristic supports notifications, and your phone has registered for notifications on that characteristic, the new value will be transmitted whenever SetParameter is called.
You can implement any proprietary protcol to connect to and interact with your beacon device. It can assume other roles than just the beacon task. It can also listen to and respond to connection attempts thus expanding into a lot more than a regular beacon.
If you study the cc2541 close you realize it is a pretty advanced IO controller that offers a lot of IO signal possibilities. That way you could use the cc2541 as the heart of an IO control application where you measure and control equipment. Mobile apps can then easily connect to your beacon/IO Controller device and interact with the machinery it is hooked up to. As you see, it´s a remarkably versatile system on chip and a cool circuit to learn to program.
We're about to embark upon implementing a device running Linux that (among other things) will be attached to a software defined FM/AM radio that can also receive RDS data describing playlists and other such stuff. It's a relatively stupid device that mostly contains a DSP or two that act as tuners and otherwise does very little processing of the signal.
I was thinking that kernel drivers for the device and then a userland hardware abstraction layer that provided a standardized interface and abstracted away the details of exactly when the RDS data was received and dealt with error handling and all the other messy stuff. Is there already a userland layer like this? It would be nice to either avoid making it at all, or make our stuff plug-compatible with something that already exists so we could use other projects for the radio UI if we wanted.
Radio support in linux
It sounds like you are creating a new hardware radio device? You'll probably need to build a driver for this device. Some help getting started can be found here, here, and here. If your device is not new, it may already have a driver in the Video4Linux2 project.
It looks like there are some RDS related projects based on the saa6588 kernel module currently.
According to this page, these cards are currently have a SAA6588 chipset:
Terratec Cinergy 600
KNC ONE TV-Station RDS
KNC One TV-Station DVR
TYPHOON TV TUNER CARD RDS
Sundtek MediaTV Pro (supported by the manufacturer)
Sundtek USB FM Radio (FM Transmitter/Receiver, supported by the manufacturer)
RDS specific information
I'd recommend to check out some of the projects related to Video4Linux2 (v4l2), there is an RDS decoding library. This library runs in userspace, so the RDS decoding work can be done there for you:
According to V4L2 specifications, raw data from RDS decoders is read
from the radio device. Data consists of blocks where each block is 3
bytes long. All decoding has to be done in user space.
RDS API
Here is a complete API reference for Video4Linux2. Here is an article series to get acquainted with it.
The particular section for the RDS API is here. This page provides information about how to get an update about whether RDS data is available:
Whether an RDS signal is present can be detected by looking at the rxsubchans field of struct v4l2_tuner: the V4L2_TUNER_SUB_RDS will be set if RDS data was detected.
SDR RDS decoder DSP in Gnu Radio Companion
Although it's not an official API I found one last small project that might be worth looking into:
RDS reception using SDR
Here are some more radio related projects worth looking into.
It may be worth looking into whether the GENIVI consortium (http://www.genivi.org/) has a standard application for this yet. They're developing standards of this sort specifically for automotive "infotainment" purposes, and this seems like it would fall within their area of standardization.
Unfortunately, they don't seem to publish their stuff publicly, so you may need to ask around or send them an email directly.
How about GNU Radio? They have hardware support for lots of software defined radio components, and a data flow easily connected via GUI with their "GNU Radio Companion" (GRC).
They use Python and C++ APIs that can be accessed for your UI layer. There are a number of examples to be found online.