drimtajm / bluetooth

An embryo for an Erlang bluetooth application
Apache License 2.0
11 stars 3 forks source link

Running on Ubuntu? #1

Open brweber2 opened 9 years ago

brweber2 commented 9 years ago

I'm trying to get this project working on an Ubuntu vm (Linux vagrant-ubuntu-trusty-64 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux). Rebar was choking on compiling the c files initially. I've since pushed past that by explicitly adding the bluetooth includes in bluetooth_interface.c.

However, now I'm getting the following error:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/bluetooth$ rebar shell ==> bluetooth (shell) Erlang R16B03 (erts-5.10.4) [source] [64-bit] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V5.10.4 (abort with ^G) 1> bluetooth_interface:get_local_name(). \ exception error: no match of right hand side value {error,{other,97}} in function bluetooth_interface:get_local_name/0 (src/bluetooth_interface.erl, line 141)

I suspect that this is an issue with my VM not being able to properly access bluetooth from the host OS but I'm not sure yet. So, have you tried this on Ubuntu? Any suggestions? Thanks.

drimtajm commented 9 years ago

Hi Bryan,

Glad that you found my code. :) It's not much, but it's a start. Next thing I'll add is a length header so it's easier to send packet data.

I forgot to write Bluez 5.10 in the instructions, that is probably why you are having trouble compiling. I haven't tested any newer versions, but I guess they should work as well.

When I wrote my code, I found that the Raspbian repository contained an ancient version of Bluez that didn't work as expected. I could have tried to adapt my code, but instead I followed the first API description I could find. It worked well once I downloaded and compiled a newer Bluez.

You can check the version with "rfcomm -h | head -1" for example.

The deps directory is a left-over from when the code was in another repository. It's not even created since there are no dependencies to other repositories and git doesn't check in empty directories. So you can safely ignore that part. :)

Regards, /Angela

On Fri, Dec 26, 2014 at 10:09 PM, Bryan Weber notifications@github.com wrote:

I'm trying to get this project working on an ubuntu vm (Linux vagrant-ubuntu-trusty-64 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux). Rebar is choking on compiling the c files. I have bluez and libbluetooth-dev installed. So I'm wondering what is in your ../../deps directory that you refer to in rebar.config? Am I missing something there? I tried adding /usr/include to pick up the bluetooth headers but that didn't help either.

Here's a sample compile error (although I don't think it is particularly interesting because I don't think it is seeing the bluez headers?).

c_src/bluetooth_interface.c:138:15: error: ‘IREQ_CACHE_FLUSH’ undeclared (first use in this function) int flags = IREQ_CACHE_FLUSH;

Any help our ideas would be greatly appreciated. Thanks.

— Reply to this email directly or view it on GitHub https://github.com/drimtajm/bluetooth/issues/1.

voltcode commented 9 years ago

I have a similar problem - can't get it to work on debian running under VM (I want to develop as much as possible on vm before moving to pi).

I installed bluez-5.10 - rfcomm test returns 5.10 correctly hcitool lescan finds the sensortag OK - I guess that means that 5.10 has installed correctly

I had one problem with build - I removed conditional include so that the bluetooth files are always included. That passed compilation (rebar co).

when I run rebar shell and bluetooth_interface:get_local_name I get an error from NIF:

The on_load function for module bluetooth_interface returned {{badmatch, {error, {load_failed, "Failed to load NIF library: '/root/sensors/bluetooth/priv/bluetooth_interface.so: undefined symbol: ba2str'"}}}, [{bluetooth_interface, on_load,0, [{file,...}, {...}]},

any ideas? I'm running Linux Debian 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux

Regarding VM access to hub - I found that virtualbox does not work, but vm player works fine. You need a dongle with CSR chipset. Here are some other instructions helpful for diagnostics : elinux.org/RPi_Bluetooth_LE

voltcode commented 9 years ago

I have a similar problem - can't get it to work on debian running under VM (I want to develop as much as possible on vm before moving to pi).

I installed bluez-5.10 - rfcomm test returns 5.10 correctly hcitool lescan finds the sensortag OK - I guess that means that 5.10 has installed correctly

I had one problem with build - I removed conditional include so that the bluetooth files are always included. That passed compilation (rebar co).

when I run rebar shell and bluetooth_interface:get_local_name I get an error from NIF:

The on_load function for module bluetooth_interface returned {{badmatch, {error, {load_failed, "Failed to load NIF library: '/root/sensors/bluetooth/priv/bluetooth_interface.so: undefined symbol: ba2str'"}}}, [{bluetooth_interface, on_load,0, [{file,...}, {...}]},

any ideas? I'm running Linux Debian 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux

Regarding VM access to hub - I found that virtualbox does not work, but vm player works fine. You need a dongle with CSR chipset. Here are some other instructions helpful for diagnostics : elinux.org/RPi_Bluetooth_LE

drimtajm commented 9 years ago

Hi,

I'm excited to see that people are downloading my code and I will do my best to help you get it working for your purposes. :)

I designed the code to be compiled on ARM target architecture (as you saw) and the rebar.config.src file specifically checks for armv61. If you want to run it somewhere else, you should also add "-lbluetooth" to the LDFLAGS variable in the rebar.config file (and comment out the conditional code like you already did). Please let me know if that solves your problem.

The reason why I checked for ARM is that it allowed me to run unit tests on a PC without having bluetooth libraries installed. Back then, the project was inside another project. But I guess I plan on adding unit tests to this project as well.

Anyway, I am currently trying to make the test client/server code work between a Radxa Rock (armv7 and on-chip bluetooth adapter) and a Raspberry Pi and I ran into some problems with authentication. So I guess what I am trying to say is that my implementation is a bit simple and naive right now and there could be some problems with it. But my strategy is to solve any problems along the way, so I see it more as "incomplete" rather than faulty.

By the way, it doesn't matter if you have Ubuntu or Debian as long as you have Bluez 5.10 or newer. I have only tested the code on Raspbian, Pi! and Linaro, but I see no reason why it shouldn't work "everywhere", as long as you have your hci device correctly set up.

You can always run the command line tools to test your setup.

Regards, /drimtajm

voltcode commented 9 years ago

Thanks a lot! I managed to get much further - -lbluetooth was crucial. I now get past get_local_name() successfully, however the discover() call does not return any devices. At the same time hcitool lescan shows devices correctly. I'm using bluez 5.10 as suggested (although it was a manual install via wget, ./configure make and make install rather that apt-get.

Any ideas?

drimtajm commented 9 years ago

Hi again,

I have not had a look at the low energy settings. You could try a "normal" scan with hcitool scan and compare the outcome. Did you set both of the devices in piscan mode?

Also, if you want to see what's going on, you should install hcidump and run sudo hcidump -X in a separate window. You will see if the discovery gives you any devices in Bluez.

Finally, you can call discover([{num_discovery_cycles, N}]), which allows you to set the number of discovery cycles (i.e. the duration of the discovery).

Regards, /drtimtajm

On Sun, Jan 4, 2015 at 2:37 PM, voltcode notifications@github.com wrote:

Thanks a lot! I managed to get much further - -lbluetooth was crucial. I now get past get_local_name() successfully, however the discover() call does not return any devices. At the same time hcitool lescan shows devices correctly. I'm using bluez 5.10 as suggested (although it was a manual install via wget, ./configure make and make install rather that apt-get.

Any ideas?

— Reply to this email directly or view it on GitHub https://github.com/drimtajm/bluetooth/issues/1#issuecomment-68633132.

voltcode commented 9 years ago

OK, that explains a lot. Somehow I thought your project was about Bluetooth Low Energy :) I understand BLE is different bit of API in bluez so naturally that won't work out of the box with standard bluetooth.

I suppose we can close this issue and perhaps some future visitors will use this knowledge for troubleshooting (or it gets moved to the main page: tips about -lbluetooth in rebar.config and using VMPlayer instead of VirtualBox in case of problems).

Thanks for help!