Bluez - bluetoothctl vs hcidump

#1

Hi,

I have successfully developed an “ruuvicollector” but removing the hcidump/tool dependency in my raspberry pi 3 b+. I use only java libs.
The issue that I am dealing with is that bluetoothctl does capture a lot less advertising events from my ruuvitags (comparing to hcitool/hcidump). It seems that bluetoothctl / bluez stack as a kind of “10 sec frequency update”. This works ok in RAWv2_Slow because it as 6 sec updates.

I have search in the internet, in order to have the same events captured by bluetoothctl, I found that I can change the discovery filter (https://stackoverflow.com/questions/36607626/how-to-use-bluetoothctl-like-hcitool-lescan-to-report-repeated-proximity-beacons) or even change the frequency interval (https://stackoverflow.com/questions/21124993/is-there-a-way-to-increase-ble-advertisement-frequency-in-bluez). I also update bluez to 5.50 and no success.

Can you help? Do you have any idea how to sort this out?

Thanks and Regards,
Ricardo

#2

I understand that hcidump is deprecated only because the original author has no plans to continue to work on it ( not that it is “bad”).
I plan to stick with hcitool/hcidump for a while since it works.
But that’s only me :slight_smile:

PS Did you post this as Uriel on ruuvi.slack ?

#3

hcitool/hcidump works pretty well.
But since I am starting a new “pet” project, I guess I will try to follow the most future proof approach. Also parsing a stdout is not the best scenario.

Since hci tools are deprecated (https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=b1eb2c4cd057624312e0412f6c4be000f7fc3617), I guess that bluez some point in the future will not be compatible.
Also the replacement for hcidump is btmon (https://wiki.archlinux.org/index.php/bluetooth#Installation). You can parse the output from this tool.

I am not Uriel, This is my first post. :smiley: By the way I love ruuvitags!!

Still, is there anyone that overcome this problem?

1 Like
#4

Can any one from Ruuvi give support on this?

I am using tinyb java lib.

Thanks,

#5

Hard to tell without seeing the code, but I guess TinyB does not fully support this use-case of reading non-connectable undirected advertisements (which is how RuuviTags send the measurements with on the default firmware), as TinyB is intended for GATT use.

I’m not sure but I guess TinyB probably updates the visible manufacturer specific data in the advertisements once every 10 seconds or something, which is not an issue when you’re scanning for devices to connect to with GATT.

#6

Thanks for your feedback.
What you describe its pretty much the behavior I am having.

I have publish the code here: https://github.com/kardoo/ruuvitag-scanner-scala .
I did the app in Scala… but its easy to understand. Feel free to point out any idea! :smiley:

So, there is no good java lib alternative to hcidump? In the future we should use the bluez stack, Am I correct?

#7

I haven’t really used Scala myself so I may be reading it wrong, but it looks like you’re sleeping for 10 seconds in your main loop, which means your app processes something only once every 10 seconds, so that’s probably at least one issue.

None that I know of, TinyB is the closest one I know, and it’s not the same. It’s also using native binaries under the hood through JNI, which currently means it can only be run on Linux (x86/x64 or arm) with specific required packages installed, as it uses the very same BlueZ stack.

In the past, and in the foreseeable future, yes. BlueZ is the Linux kernel bluetooth stack, so more or less everything uses it, unless they’re working on very low device level.
hcitool, hcidump, bluetoothctl, btsnoop, tinyb, etc all use BlueZ in the end

#8

I haven’t really used Scala myself so I may be reading it wrong, but it looks like you’re sleeping for 10 seconds in your main loop, which means your app processes something only once every 10 seconds, so that’s probably at least one issue.

You’re are right, but even if I decrease the sleep time, it returns the same values. It seems that the Bluez stack updates like every 10 sec… So its pointless to try to get values in smaller interval.

I also tried to use bluetoothctl output… again the frequency of updates seems to hit the 10sec mark. I tried to clear all filters and other stuff… but no sucess.

Regarding Scala, if you know JAVA well enough… you will probably like it. Some stuff is much more simpler to do. It still uses Java bytecode underneath.