Bluetooth Support

[LaneaLucy]

Hi, we made rnode Bluetooth ready now

https://github.com/LaneaLucy/RNode_Firmware/tree/mobile_T-Beam

Can you please make reticulum, especially the android version, Bluetooth compatible? Thx

[SebastianObi]

Hi,

I am currently working on the reticulum interfaces for this. On a Rasberry Pi it already works without errors. On Android the connect works, but the received data is corrupt. Sometimes, however, error-free data arrives.

@markqvist We would like to help you with the further development. When our code is ready and bug free we would like to make an pull request for it. You can then review and accept it or give us advice on how to improve it.

Currently i can't get the problem solved when receiving data on Android. Perhaps you can also provide specific support here.

Here is my interface defintion: https://github.com/SebastianObi/Reticulum/blob/master/RNS/Interfaces/Android/RNodeBTInterface.py

I would also add this new interface type to the Sideband GUI. I would copy all settings 1:1 from the existing RNode. Then we have 2 RNode Interfaces (RNode USB & RNode BT). If you want it done in a certain way then please give me instructions.

[markqvist]

Hi @SebastianObi and @LaneaLucy

Before dumping a wall of text on you here, I really want to say thanks for the efforts and initiative here. I am really grateful for that, but there is a lot of unconsidered things with this implementation, and there should have been a proper discussion of all of this before the work was started, probably ;)

For reference, I am going to include the response I also gave over on the discussion pages thread here as well.

[markqvist]

While I understand the eagerness to get this up and running, I would appreciate it if everyone can take a step back and look at the overall picture here, before more time and effort is spent in this direction.

Before starting work on such an integral feature as this, it would have been a great idea to discuss this with the maintainer of all of the software, yours truly ;) In that case we could have coordinated the efforts much better, and you would have had an idea of the expectations to the implementation beforehand.

While I have no doubts that the implementation of Bluetooth connectivity you have put together actually works, it is also a quick hack, and not a well-considered solution to the overall problem of Bluetooth/wireless connectivity. I really, really don't say this to degrade your efforts or work, and hope you wont take it as such. But doing things fast instead of right always leads to misery down the line in software and hardware projects.

I have spent a lot of time carefully planning and considering how to properly implement wireless (both Bluetooth and WiFi) connectivity between RNodes and hosts, and while I know it is with the best intentions, your implementation ploughs right through that to simply implement the something that "just works right now", as easily and quickly as possible.

In its current form, I will not be able to accept pull requests for this into neither Reticulum, nor the RNode firmware or related config tools, for the following reasons:

• Having "#defines" in the firmware that needs to be toggled manually to build a specific type of firmware, where this is not integrated with the overall build system is simply a no-go.
• Having a specific firmware that is "Bluetooth only" is not a good solution, and a dirty hack to just get something working quickly ;)
• The above two means that users must manually flash a specific "bluetooth firmware" to use bluetooth, and flash it back to the normal firmware if they want to use serial. This is just horrible from a user standpoint, and completely unneccesarry. There is no technical limitations of the firmware platform that makes this necessary.
• Enabling Bluetooth or WiFi host connectivity must be a configurable setting that persists across powerdows/reboots of the device, and it should be configurable with the standard tools like rnodeconf, and also from within Sideband, also allowing control over pairing ability.
• Cluttering up Reticulums interface system with an "RNodeBT" interface is not a good design pattern.
  • This effectively doubles the amount of interface code that needs to be maintained when changes/improvements to the firmware is made
  • Furthormore, from a users perspective, it is confusing and unneccesarry. The user should simply be able to specify a bluetooth endpoint in the normal RNode configuration, and the interface should cleanly take care of the rest.
• I don't see any actual handling of device pairing/unpairing anywhere here, apart from just blindly accepting whatever connections.
  • In the same vein, I don't see any handling of multiple Bluetooth SPP connections. It looks like this code is wide-open to malicious intercepts of the RNode traffic and radio control from literally anyone.
• Why should closing the SPP connection hard reset the MCU? This will break future stand-alone functionality. Also, anyone will just be able to connect and disconnect, causing a hard reset and stopping all communications for the actual user.
• Anything in the code marked as a "workaround" is not going to get included in the main branches, unless there is a very, very good reason ;)
• How are you handling added dependencies to RNS for this? As you might have noticed, RNS is extremely light on external dependencies, and so far, every added dependency has been only happened if there was no way to avoid it.
  • Maybe it is unavoidable in the case of Bluetooth, but I actually don't think so, since interacting with the OS BT layers is quite easy through standard utilities and sockets. This might be a better solution.
  • Or it may be worth including necesarry libraries packaged within Reticulum, if they have compatible licenses.
• So far this only supports the old RFcomm Bluetooth Serial Port Profile, and not BLE, which is probably not ideal, since device connections are greatly simplified (from a users perspective) over BLE.
• How realiable is this? Have you tested it enough to be certain that it in no way interferes with interrupts from the SPI bus, or that said interrupts does not interfere with reading data from the BT serial port?
• How does this handle intermittency, devices moving out of range, and back into range?
• How realiable is the transport between device and host? have you done any measurements of frame error rates at bulk transfer volumes (several hundreds of megabytes)?

As a quick hack to test out Bluetooth functionality, it is totally great and probably enough to try it out, and "see it working", but at this point, we just can't put this into RNS and Sideband. As it stands now, it has a long way to go.

Implementing this funcionality has been on the roadmap for a long time, and I can definitely understand the excitement to get it working. While I am also really eager for this functionality myself, we need to do it right the first time.

[markqvist]

Also, just so it doesn't seem like it is just wasted work, we can definitely use great parts of this, and will be happy to merge that in so you are also listed as contributors on the repos :) We just need to recontextualise it all into its proper places.

[LaneaLucy]

Hi, The first 3 points I already wanted to change and will be changed in my next commit, with no extra firmware for Bluetooth. Pairing is in the moment solved by connect to the device and press a button inside 10 seconds. If you have connected a OLED display, it even shows the pin for comparison. And until you remove the pairing from your phone or computer, you still be paired and can connect without anything to do. What should be configurable there?

Next point sounds reasonable, maybe I can help Sebastian with it.

Device pairing is implemented in my version of the firmware, but should be tweaked more. At the moment I'm using a button to accept the pairing, and if the pairing isn't accepted after 10 seconds, it gets declined. What do you mean with multiple connections? Multiple active connections on the same time, or multiple paired devices?

With implemented pairing, only paired users would be able to dos.

What workaround? The one I commented out in the pairing?

To the implementation in rns I can't say anything yet, except that on Linux you could do it without any new interface together with rfcomm, if there would be a no reboot option for the rnode interface, because if the rnode reboots, the Bluetooth connection breaks.

Yes, at the moment it only support's classic Bluetooth, but this is nothing, which couldn't be changed in near future. It just would be cool for everyone to at least already have something working, that don't need any cable's to connect the rnode. For example, I don't have enough USB cables for development with more then 1 rnode at the time, which makes it hard to debug.

For testing, I didn't had enough time to test it yet, but that's a next thing, why I want you to implement this in a extra branch, so everyone here, can test it and we have a central location to discuss or open issues, if something don't work. Don't understand me wrong, I don't want you to directly merge everything from us to master, but I would like if you could test it, and after this a broughter audience could test it, so finding bugs is so much faster.

I have no idea. But as it just replaces the serial class, it should be handed exactly like a intermittency on serial.

And for the last point, I have no idea how to do it....

I understand but would like to work together with you.

[markqvist]

Thanks for the in-depth reply and explanation! I answered over on the discussion thread. Let's keep it all over there so we can coordinate and plan in one place.

https://github.com/markqvist/Reticulum/discussions/127#discussioncomment-3958077