I am creating a REDHAWK device for a GPS. I was looking at creating a FrontEnd Interface II (FE II)device for the GPS. I tried to use the REDHAWK 1.10 device wizard, but it only created a tuner device that included GPS. I found the GPS IDL, but I don't see any other information about a GPS FE II device.
Does the Frontend Interface II defined a standalone GPS device? Is GPS expected to be ancillary function in a FE II device?
As you noted, the Frontend Interfaces II IDL files include support for standalone GPS devices. However GPS support in the wizard is limited to the generation of Tuner devices with GPS input and output as an ancillary capability. The GPS IDL could be used to create a standalone GPS device. However, you will need to provide an implementation for the generated stub methods
Related
I'm trying to develop an application on Bluetooth Low Energy Peripheral based on Qt 5.7 on beaglebone-black using UART module CC2564MODA.
I'm able to advertise LE device & created services and characteristics.
Using BLE Scanner Application to realize implementation.
While trying to pair my peripheral with any device Linux kernel prints
Bluetooth: SMP security requested but not available
Where Linux kernel contains BlueZ v 5.41 .
I can see my services & all characteristics with pairing option.
But i wanted to add 4 pin pairing method.
Where i can set pin code.
Is there any article to study or any standard method to resolve this issue.
Thanks
My question is very basic.I need to know where does all Bluetooth profile such HID, HFP or HSP loaded in Bluetooth stack? Is it in Host layer or in Bluetooth Hardware Chipset such as USB dongle/module or in both Host and Chipset Side?
According to my understanding, we can implement Bluetooth profiles on Host side using packages like BlueZ but at same time Bluetooth chipset which is connected to Host should need some sort of firmware and logic(like CSVD, A-law ) inside its chipset.
A quote found in BlueZ Android package doc: "Wideband Speech support in HFP it is required that BT chip assumes mSBC codec". This means Host layer can implement that Profile only if BT chipset provides the low-level support like mSBC.
My Answer is like this: " We can build any Bluetooth Profile say 'X' on Host layer if BT chipset is equipped with underlining Low-level firmware which support the Profile 'X'".Please agree or disagree with my understanding.
PFA diagram of my understanding
Position of profile and its low-level firmware
I need to select a USB Bluetooth dongle compatible to Raspberry Pi and customize the HID and HFP using BlueZ.
Advance Thanks to all Bright minds!
There are multiple ways how Bluetooth functionality is implemented in a system based on how much is implemented in the controller and host.
Everything in the controller - App, Upper stack, may or may not HCI(lower and upper stacks communicate through HCI commands and events), Lower stack. Example: Most of Bluetooth Mouse, Keyboard etc, where a single controller is responsible for everything (Bluetooth, RTOS/scheduler, Controlling LED's in the device, etc)
App in Host and lower and upper part of stack in controller. May or may not implement HCI in controller.
Example: Where we use a dedicated Bluetooth chip and integrate it with the Device. Here device will transmit application data to the Dedicated Bluetooth chip. All the Bluetooth protocol related things will be done from BT controller/chip. If you are using an HC-05 module with Arduino module, Arduino will transfer the serial data to the HC-05 module.
App and upper stack in host and lower stack in the controller. Bluez, Bluedroid and all other stacks in Operating systems are of this type. This will communicate with the controller with HCI commands and events.
Example: Mobile phones, Computers, TV with Bluetooth etc (Devices having a powerful Application processor)
So lets assume you are asking about the 3rd type. In this case your assumption is correct. Here all profiles are implemented in the host only. But protocols/codec needed to support them will be implemented in the controller(either firmware or hardware block). For example GAP(For BR-EDR) is implemented in the host but encryption and decryption algorithms are implemented in the controller as Firmware or hardware blocks. For A2DP profiles audio codec/decoders will be implemented in the controller. BT chip then transfers this audio data to host with I2S or other protocols. For BLE Security manager profile, encryption/decryption algorithm is implemented in the host itself, But whitelist, auto connection etc, will be implemented in the controller.
My Answer is like this: " We can build any Bluetooth Profile say 'X' on Host layer if BT chipset is equipped with underlining Low-level firmware which supports the Profile 'X'".Please agree or disagree with my understanding.
For BlueZ use case this is correct. You need to use the controller with the required hardware capabilities(Firmware + hardware resources).
For the scenarios 1 and 2 the profiles and supporting protocols will be implemented in the controller.
I am using Bluez to set up a BLE beacon scanner on a standalone Linux box. I want it to do some form of self diagnosis on the radio (for some specific application reasons) and the way I'd like to do it is by transmitting a beacon (iBeacon or any other form) every so often and listening for this beacon on the same radio.
This is the setup that I have:
Unit 1: standard off-the-shelf iBeacon.
Unit 2: Ubuntu VM with CSR
BLE radio. Running an iBeacon scanner and an iBeacon transmitter.
Unit 3: Ubuntu VM with CSR BLE radio (different from the one in Unit
2). Running an iBeacon scanner.
Results:
Unit 3: is able to see Unit 1 and the iBeacon transmitted by Unit 2.
Unit 2: is able to see Unit 1 but NOT the iBeacon transmitted by Unit 2.
Should it be possible for Unit 2 to see itself? If not, why not?
No, a Bluetooth LE device cannot detect it's own transmission. This is nothing specific to BlueZ, Linux, or even the specific Bluetooth hardware you are using. All BLE devices work this way including those on Android, iOS, Windows, Mac and other embedded platforms.
The limitation is baked into the hardware and the design of the Bluetooth specification. Why? Because for non-experimental purposes, it just does not make sense to have a radio transmitter/receiver pick up its own transmission. Think of an old fashioned CB radio, which always turns off its receiver when transmitting.
You can, of course, add a second Bluetooth dongle on Linux, then use it to receive the transmission from the other interface.
I'm working on the iOS app to interact with Arduino boards. On Arduino side i use "transparent" serial implemented in HM-10/11 firmware. So i just wire HM-10/11 RT/TX pins with Arduino ones and it works just perfect and write to specific characteristic to send data and subscribe/read to some specific to read from BLE module. No need to use any SDK or BLE library in arduino sketch, no need to modify bootloader.
Now i need to support NRF51822 BLE chips. Nordic has implemented UART serial in firmware sources but for my NRF51822 board (purchased on ebay) it's not uploaded to the chip by default as i can't see 0001 service and 0002 and 0003 characteristics. Do i need to purchase NRF motherboard and compile and upload this firmware? Can i do it without purchasing this dev kit? Can i upload over USB only or over BLE too?
If your are using NRF51822 standalone module ,then to update its firmware through SWIO/SWCLK pins ,you need a compatible JTAG programmer/debugger (you can check in segger website) . You can use Keil IDE to upload your updated firm ware to the flash memory of NRF51822 .
Although you need to upload using a SWD programmer, you are not limited to Segger.
There are open source alternatives like the Black Magic Proble which you can flash into $5 hardware (stm32f103 boards) from ebay.
You are also not limited to Keil or IAR for your compiler toolchain.
Its possible to compile using Eclipse and GCC ( Nordic have a blog entry in how setup an Eclipse base dev environment)
You can even program these devices using the Arduino IDE.
It is possible to upload OTA, but you would need to flash an OTA bootloader onto the device first using SWD and even then, you would probably need to upload via a mobile phone, as Im not aware of any PC ble devices that support transfer via the DFU protocol ( though some may exist)
These devices do not natively support USB.
Some boards using these device have a separate processor that allows upload as if the chip was a mass storage device, but I am not aware of a motherboard into which you could plug this module, which has that functionality.
BTW. The module you linked to, is actually designed and manufactured by Waveshare.com . Take a look at their website, it has full documentation on the hardware including schematics
The nRF51 and nRF52 dev boards has an onboard Segger / JLink. So then you can develop on and debug on the nRF51822 and flash other nRF51822s as well.
i know that iBeacon use only advertising channel. which means there is no need connection.
im trying to make my own beacon module which send and receive data.
im curious about what makes the packet in iBeacon format(prefix /UUID / minor/ major/ TX) in communication ?
is it firmware?
let's assume that
when i make my iPhone act as iBeacon , it will send the advertising packet. which means it sends data in iBeacon format. but after turn off the app for iBeacon, i try to use my iphone
to send some files to laptop via Bluetooth low energy mode as usual.
then it will send data in bluetooth standard format. is this right?
given that situation, my iphone can be both iBeacon and just normal phone capable of bluetooth low energy.
i think also the beacon module can be like that. how about the product recently released? like estimote, redbearlab and so on. after connection, do they receive data?
Every iBeacon product works a little differently, but it is common for a product to be connectable for configuration purposes over Bluetooth LE.
Radius Networks' RadBeacon, for example, has firmware that sends out its advertisement as needed to be a standard iBeacon. The same firmware will allow a connection over Bluetooth LE, exchanging data with an external client (the RadBeacon app for iOS). This connectability is outside standard iBeacon functionality, using proprietary techniques that are still part of the larger Bluetooth LE standard.
Your understanding is therefore correct.
Full disclosure: I am Chief Engineer at Radius Networks.