05-24-2021
07:14 AM
- last edited on
03-20-2025
01:57 PM
by
Content Cleaner
Hi,
Before starting to explain what im trying to do i want to make clear that i use LabVIEW 2020 community version on linux. The community version should be equivalent to the pro commercial edition, however form the research i made the linux version might be a bit different, especially in terms of functions available. I mainly use linux, so perfer if it can be done on this OS, but if not than I shall move to a virtual box and work on form there.
I recently bought a roland electric piano that can be paired with any device using bluetooth. The company developed 3-5 different apps to interact with their different models. In general the apps are of very low quality. each app has some unique features and some overlapping features with the others. On top of that, some models can connect to certain apps and some can't.
On one of the apps that my model can't access I saw that there is a function that allow to export recorded music from the piano hardware to my device/cloud. The app that does pair with my piano model does not have this feature.
I already sent an email to the company and the app developer to add this feature, but im not optemistic that they will even reply, let alone implement this new feature, so i though it might be a nice practice to try and create a VI that does exactly this one thing - pairing to the device and exporting the recorded piece.
I started to look through threads and help documantation of LabVIEW, but I cant seem to find the pallet that is for bluetooth connection. I saw that microsoft bluetooth is being mentioned a lot, but can't see a reason why a linux bluetooth manager can't do the job just as well.
These are the sources was reading:
2) https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LNcSAM&l=en-IL
Any advices on how to start? How do I create a bluetooth connection? I searched the word bluetooth on the "functions" window and it returned an empty list. Ideas?
Thanks in advance
05-24-2021 08:06 AM - edited 05-24-2021 08:09 AM
Well, there are two pieces here. One is how bluetooth is managed on a platform. That is entirely outside of LabVIEW and you should not even try to look about that in any NI documentation and definitely not for Linux. NI has limited support for Bluetooth on the Windows computer. Even there Bluetooth has always been a problem and that is not just because NI doesn't want to support it but mainly because Microsoft never had a clear strategy how to support Bluetooth at all. In the beginning it was mostly in the hands of Bluetooth adapter manufacturers who all developed their own standard of how to approach their adapters before Microsoft took a bit of a lead and more or less adapted one of the solutions as standard in Windows. But it was never a real Microsoft product, its implementation was flaky in many areas and the support you could get from Microsoft about it was almost non-existent. So Bluetooth while kind of omnipresent in the handheld device market is in fact a step child under all Windows versions. BLE didn't make it better as Microsoft choose a very different approach to add BLE support to Windows than the classic Bluetooth interfaces.
LabVIEW for Windows only supports the so called socket interface to Bluetooth. That is basically a driver that integrates Bluetooth adapters into the socket network stack as simply another network protocol layer besides Ethernet devices. The idea is not really bad but also not necessarily straightforward. In addition there are some non-official BLE toolkits floating around that use the Microsoft BLE API to provide functionality. They work very different.
I'm not sure if the Linux version of LabVIEW supports the socket interface for Bluetooth too. Theoretically it shouldn't be much extra work since the Winsock interface is basically simply a reinterpretation of the standard Berkeley socket interface that is also used in Linux. But with Linux being what it is, it is likely that there might not have been an official Bluetooth socket driver for Linux at the time this functionality was added to LabVIEW (~2000 or so) and therefore NI didn't bother to add it to the non-Windows platforms? As can be seen in this old document, it's unlikely that LabVIEW for Linux supports the Bluetooth nodes. Disregard the Pocket PC 2003 and Palm OS references. as they are not relevant at all anymore (Pocket PC was the predecessor for long gone Windows Phone OS and Palm OS was never more than an experimental LabVIEW target and long gone) but the fact that MacOS X is stated as not supporting the Bluetooth nodes almost certainly indicates that the Linux version of LabVIEW faces the same faith. And those socket based interfaces are anyhow totally irrelevant to modern day BLE devices (which your Roland keyboard may or may not be).
Linux of course supports Bluetooth but in traditional Linux fashion it is buried deep in some drivers in the system, with some semi-optional command line tools that can be used to control it. Your best bet is to first forget anything about LabVIEW and NI and simply research how you can get the Linux Bluetooth system to pair with your Roland device through the use of Linux command line tools. Before you have managed that, any other work in getting to talk to your device under Linux is doomed already.
05-24-2021 09:43 AM
Wow thanks for the detailed answer!
Will check the connection from my laptop to the roland keyboard through vommand line first.
The BT on my keyboard is BT 5.0, and at the moment i am able to connect my laptop BT to the piano through the GUI.
Dont know if it make any sense, but the piano has 2 BT clients i can connect to -
1) an audio client where i can use the speakers to play music etc. Like a mobile speaker.
2) a midi client. This is the connection all the apps go for to send/receive data - it change parameters of the piano, it knows what key i press and can show it to me, etc.
I need to connect to the midi client. Connecting usong my android phone or laptop doent allow me to do anything. I wonder if i connect there can i send the built-in commands that the proprietary apps are using.
Anyway, i wanted to do this project on LV to practice. If it is way too complicated i might try to create an android app (though i never tried it before). Is connecting via my laptop to the BT the way i described is what you meant i should succeed in doing first?
05-24-2021 10:30 AM - edited 05-24-2021 10:32 AM
Well, my experience with Bluetooth is limited and rather mixed, to put it mildly. Generally while the idea behind Bluetooth sounds interesting, the reality is that it usually doesn't work right away or sometimes never. And the reasons why are often obscure and seemingly random. My personal feeling is that the Bluetooth consortium tried to create a standard that was supposed to be open but at the same time tried to keep full control (and according revenues), hampering its broad adoption. The result is, well unsatisfactory.
My experience with sound and especially Midi devices is 0%. Back in the old days with Atari ST (yes I'm that old), I did dabble with Midi a bit but found it kind of frustrating to get it even to work.
As to trying to communicate over Bluetooth with your Roland keyboard with a protocol that is only implemented in those proprietary apps: I'm VERY sceptical! Without a clear description of the protocol messages you can send to the device and the expected responses, you are almost in the realms of throwing up the proverbial 1 million letters into the air and hoping to end up with a masterpiece like one of Shakespeare's writings. It's not totally impossible but so close to impossible that it doesn't matter in the span of a human lifetime or even the span of 1000 generations of humans!
Your best bet is to try to get a real protocol documentation from Roland itself. Failing that you could try to find open source projects that try to communicate to the device and have reverse engineered (part) of the protocol. I would imagine that there is a community about these devices that has at least attempted that. Then you can study the source code of those projects and try to understand how you can communicate to the device. After that you ONLY will need to find out how to access that protocol interface from LabVIEW. If you know which interface to use, you can always work with the Call Library Node to access the according shared library interface, but that is another low level challenge to tackle, so if there are other alternatives that would be for almost everyone easier to tackle.