BLE Extension Error when sending a list of strings using WriteStrings or WriteStringsWithReponse methods

[gerrikoio]

I am trying to send a large string via Bluetooth LE and have split my string into list of strings. 

I have tried using the BLE methods WriteStrings and WriteStringsWithReponse, and I'm getting the same run-time error

"Unable to convert BEGIN:VC2.1 of type gnu.lists.FString to type java.lang.String" 

The "BEGIN:VC2.1" just happened to be the first string in my list.

Any clues.

[Chris Ward]

Hi gerrikoio

Was the value "BEGIN:VC2.1" copied - pasted from another document? It could contain hidden (non-printing) characters.

[gerrikoio]

This is parsed text received via NFC which does not include any hidden non-printing chars unless of course these were added by the NFC component,

[gerrikoio]

hmmm... just thinking about it again, I did append "\r\n" (which are non-printing chars) to make my life easier on "the other side". I will remove and try again.

[gerrikoio]

Nope, as suspected that did not solve it.

If we look at the error message received there is a problem with the java conversion function from type gnu.lists.FString to type java.lang.String

[Chris Ward]

Yeah - so that means, although it failed on the first value, if we removed the first value it would probably fail on the next one? Whatever is used to parse the text needs to convert the final string before NFC receives it

Is that possible though?

I just read that you can't simply cast from gnu.lists.FString (which is a vector) to java.lang.String. Perhaps you can loop through the vector and build a String or avoid using  gnu.lists.FString.

[gerrikoio]

I just read that you can't simply cast from gnu.lists.FString (which is a vector) to java.lang.String. Perhaps you can loop through the vector and build a String or avoid using  gnu.lists.FString.

So, you've just confirmed there is a bug using lists of strings in .WriteStringsWithReponse method. 

[Evan Patton]

Internal to the BLE extension is a method called toList that coerces the inputs into a given input type to be passed deeper into the implementation. It should automatically cast FString (the Scheme string type) to String (the Java string type). The method itself dates back from June 2017, so it's been there for quite a while. I'm actually poking around in the extension for the next few days to support a workshop run by a collaborator here at MIT. If you have an example sketch I can use to test then I can try to include a fix in the next version.

Regards,

Evan 

[gerrikoio]

Evan

Thanks for the explanation. 

Without creating a distraction as this could be irrelevant, but when I created a workaround I found that the character limit for each string (when receiving the data from the peripheral) was 20 chars and that two of the strings in my list of strings were actually longer than 20 chars. It then seemed to cause some strange (non printable) bytes coming through. So, not sure if that is causing the strange behaviour on the java conversion side. At least the workaround is working and actually helped in other ways.

Anyhow, I will investigate further this end and also send an example sketch in a day or so.

Regards

Colin (Gerrikoio)