Changing the DELIMITER and DEVICE_CHARSET once device is connected?

[leoP0]

First of all I wanted to thank you for this project. I've used it to send commands between a phone(Android OS) and a device with a Bluetooth adapter.

I'm using react-native-bluetooth-classic 1.60.x version. However once the connection is made using await RNBluetoothClassic.connectToDevice(address: someAddress, options?: StandardOptions); how can the DELIMITER and DEVICE_CHARSET be changed? What are the StandardOptions and if no options are given?

The reason I asked is because I'm expecting certain ASCII characters at the buffer after a given command but I'm only getting "null" or "0 bytes available"

This is what I'm able to see from my terminal/console from the java side using 'adb logcat' :
05-17 16:39:49.478 21908 15031 D DelimitedStringDeviceConnectionImpl: Received 1 bytes from device 00:01:95:65:77:24
05-17 16:39:49.479 21908 15031 D DelimitedStringDeviceConnectionImpl: BluetoothEvent.READ listener is registered, providing data

Then as expected about 2 seconds later I know I'll get another character:
05-17 16:39:51.502 21908 15031 D DelimitedStringDeviceConnectionImpl: Received 1 bytes from device 00:01:95:65:77:24
05-17 16:39:51.502 21908 15031 D DelimitedStringDeviceConnectionImpl: BluetoothEvent.READ listener is registered, providing data

Reading manually:
let data = await RNBluetoothClassic.readFromDevice(someAddress); here data = null. why? I do not know, if I can see there is a byte coming every 2 seconds.

Any advice would be greatly appreciated.

Thank you!

[kenjdavidson]

There is no way to change the connection options once a connection is established. When I was re-writing I didn't see that having much of a use case. Generally if you're working with serial devices, you have a well established communication protocol - so whether you're using a custom device or a vendor device you should know well ahead of time what is required to communicate. This means that if for some reason your device is changing it's own protocol, you should be disconnecting and re-connecting with the new settings.

The standard options are documented https://kenjdavidson.com/react-native-bluetooth-classic/react-native/rn-bluetooth-device/#connect as well as available in the source, of which you have full access.

You have a BluetooothEvent.READ listener established, so why would you be making manual reads? You should either be doing:

• BluetoothEvent.READ listener
• BluetoothClassic.readFromDevice() on a timer

You should NOT be using both methods at the same time, as the read method becomes pretty pointless.

The BluetoothClassicExample application has both methods within the ConnectionScreen that you can toggle on and off based on setting the initial state in the code. But again, it's a EITHER OR and never a both.

Your onReadListener should be receiving that 1 byte(s) of data that the log is telling you it's sending.

[leoP0]

Yes you are absolutely correct. It is mentioned not to use bot methods of read at the same time. I should have been more clear about the test I have tried. I tried them one a the time, doing it manually I get "null" from read and “0 bytes available” when I used availableFromDevice() and no response from the BluetoothEvent.READ listener when is not manually but I know there is 1 byte of data coming in every 2 seconds as I previously shown. This is the reason why I asked about the delimiters.

Thanks for your response and the standard options documentation somehow I missed it.

[kenjdavidson]

I'm still confused on the issue then. You're still not seeing the data?

If you're getting NO data regardless of Listener or Manual Read, then something is most likely up with the delimiter, you are correct. But the log definitely shows 1 byte of data coming in every few seconds, which should be getting added to the Buffer appropriately.

The issue would then be the read, which if there is no delimiter then this would be a problem. Another problem is that you're getting 1 byte. How is that 1 byte delimited? If that one byte is the delimiter then it will get chopped off and thing would come back. Does that make sense?

So how exactly do you deliminate 1 byte of data as a string?

[kenjdavidson]

On thing that might have been lost in the conversion from 0.10.x to 1.60.x is an empty delimiter. I'm not sure if this was done:

• On purpose requiring a NonDelimitedStringDeviceConnection
• Or I just completely missed that use case

I don't think it would help you out in the case of manual reading, since if you skip a read, you would get back two messages. Something that might be good in this case is a FixedLengthStringDeviceConnection which you could then not even worry about a delimiter but reference messages by size:

• If buffer.length > fixedLength then send
• Available = buffer.length / fixedLength
• Read = buffer[0..fixedLength]

If you think this would make sense, feel free to pull request the appropriate device connection if you think others will use it. Or just have it internal to your own project and customize the Connection using the RNBluetoothClassicPackage.Builder

[leoP0]

Answering your first question: No, I'm not seeing any data.

I believe that 1 Byte of data is not getting delimited. This 1 byte is just an ASCII charter(which is a letter). I have a solution for this, I just need to do more testing, it will avoid reading this 1 byte that I cannot get to read.

If I have time I'll give it a try to the other solution mentioned in the last answer.

Thank you!

[kenjdavidson]

Hey, that's my point. If you have 1 byte of data which is an ASCII letter - how can it possibly be delimited? There are only a couple options that I can see:

• The ASCII data is the data you want received, in which case you're only getting 1 byte data and no delimiter. If there is no delimiter you will never get any "message data". For example, if you're expecting "A" it actually needs to be "A\n" which is 2 bytes, of which the last \n is the delimiter.
• It takes multiple 1 byte to create a full message, for example: 1 byte, 1 byte, 1 byte, delimiter. In this case, you need 3 messages in order to actually get the delimiter and have a full message

The way you explain it to me is that you do NOT want a delimited message, but instead you want a 1 byte fixed length message, which sadly this won't do.

There are two options:

1. Update the current DelimitedStringDeviceConnectionImpl to handle a NULL or Empty delimiter, which just sends back the full buffer.
2. Create a new FixedLenghtDeviceConnectionImpl which will return back the Buffer when it reaches X length, in this case 1.

Both of these could be implemented as they both serve a very specific purpose and would probably benefit a number of users.