I'm trying to use a WiPy board as a BLE scanner and we're detecting some extrange behaviours on radius Network Dot beacons.
We are trying with several beacon manufacturers, all emiting as iBeacon with an advertising interval of 100ms (10 per second). In the board we detected every second at least 4-5 advertising packets of this beacons, but most of the times 0 or 1 of the radius beacon dot.
We've tried with both altBeacon or iBeacon configuration and the results are similar.
This is a screenshot of the configuration with the RadBeacon app:
Are we configuring something wrong or are the beacons having an unexpected behaviour?
Not 100% of advertising packets send out by a Bluetooth LE device will be detected by receiving devices. The actual percentage received depends on a number of factors including:
Transmitter power level
Distance between the two devices
Radio noise in the area
Bluetooth radio congestion
Antennas on both transmitter and receiver
Orientation of antennas
Under good conditions (close range, high transmitter power), I typically see 80-90% of packets get detected by Android and iOS devices which allow you to easily count individual BLE packets.
Since your detection rate is much lower, you may want to try a number of things:
Increase your transmitter power level from -18 dBm to 3 dBm. Having the weakest power output configured is the most likely cause of your issue.
Bring your transmitter and receiver closer together.
If the above two suggestions don't help, I would use an independent tool such as an Android phone to actually count the number of BLE packets detected. I have an bare-bones app you can run on Android to do this here, but you'll need a copy of Android Studio to build and run it.
Related
I have established a connection between an nRF52 which has the advertising interval set at 20ms and iOS software, but the packages are only received every second roughly. Has anyone had this issue before/knows any tricks to speed up the frequency? Many thanks.
Its depending on nRF52 or other peripheral advertising interval in firmware. Also depends on data/packets transfer speed/distance.
If there is write characteristic available on peripheral for set time, then send/write values and speed up for this. Some device has this property for advertising interval time set but iOS/Android app.
To test bluetooth scalability, I want the same device (a Raspberry Pi or a laptop) to emit several BLE advertisements. So far, I have tried using bleno (NodeJS), hcitool and CoreBluetooth for OSX, but I can not setup more than one.
Is this a hardware/system/bluetooth limitation? Has somebody managed to do this?
Different bluetooth devices have different maximum advertising rates. These typically range from 10Hz to 40Hz. Some bluetooth devices have the ability to spoof their MAC address so different advertisements appear to come from different physical devices. This is often important for scalability testing, because some receivers keep track of unique devices by MAC address.
As #Emil says in his answer, it is possible to "interleave" advertisements such that you change the advertisement (and ideally the MAC address) every few hundred milliseconds so it appears by receiving devices that there are multiple advertisers around. I have done this with both Raspberry Pi and iOS transmitters, but in neither case could I alter the MAC address.
It is important to understand, though, that the actual number of packets received when you do this does not change. So while you may be testing scalability of unique advertisements detected, you will not be doing the same thing as testing with multiple physical advertisers.
That's not possible by the Bluetooth specification. However you can start off with one data then set a timer in your app that stops advertising. Then you start off again with the next data. And so on.
My requirement is as follows:
I need to send Proximity Sensor (Reed Switches/Magnetic Sensor) reading (On/Off) from two Input Pins to a central PC.
I need to use coin cell. So basically the app should be in sleep mode and once there is any interrupt on any of these two pins it should wake up to send its state to the central PC.
I have DA18450 chip and development board (murata ZY type) with me.
Dialog Semiconductor 18450
Murata Bluetooth Smart Development Board
I am a beginner to bluetooth technology and started reading about it just a week back.
Could someone guide me about the most apt Profile/Service suitable for my application?
If you want the device to actually sleep then it'd probably be best for it to just transmit data via advertising packets when the device awakens. Otherwise you have to maintain a connection which requires staying awake at some level. However, advertising packets are broadcast and the device can't know if anything received those packets (you could have it broadcast several times for a fixed period of time or have it constantly broadcast while the proximity alert is valid). Also, on the receiving end, with no connection there's no way of knowing the transmitting device is even there when nothing is being transmitted.
The advertising packets have a section for limited information and that's where you'd transmit data if you don't want to establish a connection.
I am making an android application that requires me to detect the user's motion.
My application also requires me to use an external sensor, which is a Bluetooth smart sensor, for some other purposes.
Now I have two options:
to use the accelerometer and gyrometer of the android phone
fetch motion information from the bluetooth smart sensor.
I understand that Bluetooth Smart (ble) is more energy efficient than Bluetooth sensors.
However, I am confused as to which of the above options will provide me a more energy efficient solution on the Android device. EDIT: I am presently not concerned with the energy efficiency of the bluetooth device.
Also, please see that I want this comparison only because I don't want to detect accurate user motion, otherwise an external device(bluetooth low energy device) would have been better hands down.
The accelerometer and gyrometer will take roughly the same amount of power whether it's on the phone or the external device. The difference is the external device has to transmit that information over a radio signal to the phone. It makes more sense to just use the Phone's existing information if that's sufficient because it won't require any radio transmissions and will require less power. Also, the phone will have a much larger battery.
The sensors on the phone have nothing to do with Bluetooth... they're incorporated right into the hardware.
EDIT: The difference between Bluetooth and BLE is that BLE uses the radio much more sparingly. Radio transmissions take a good chunk of power. So, using on-board sensors is going to (most likely) take far less power than using a radio to communicate with an external sensor. Also, I have a feeling that the accelerometers are always on on the cellphone so getting readings from those is going to take no more power than is already being used, too.
I have an Arduino project for solar tracker running. Initially I used the serial monitor to view data with my laptop. Now I'm moving my project about 1000 meters from my home. I want to remotely monitor the data from solar tracker parameter like date, time, track angle, coordinates, etc. updated every 15 minutes.
What would the best best protocol used for long distance transmission? Should I do zigbee, wireless, ethernet, modbus? If particular protocol suggested let me know why it being suggested. I also want to use the least number of pins to do this.
I Googled it and I found an ethernet shield with SD card. I never wanted it to get recorded on a SD card. The data should go directly to the PC.
if you can use a cable connection, as they are the most reitable.
RS485 is the best for bucket (100 kbit/s at 1200 m), optical fiber is very expansive but optimal.
classic ethernet has range of 100meter, wifi without special equipment about 50/100m, some zibee has a maximal range of 1Km, so MAY be the solution, but are at their limit.
Modbus is a "high level" protocol that can be used over RS485 (or other connection)