NRF.setServices Datatypes

EspruinoHub definitely shouldn't fail that way, and I have just fixed it - but I think you'd still hit issues either way.

A service can only hold a maximum of 20 bytes in normal Bluetooth LE, so the write would fail. Your message seems to be 60ish elements long, or lots of characters.

If you want to use characteristics, I'd:

• Convert your array of floats into an array of bytes. So multiply all the numbers by 10 and round them
  
• Send an array of 20 items at a time - same way you're doing it now as a string representing an array (but with the updated EspruinoHub). It'll be recognized as valid JSON and then parsed and sent as an array.
  
• Send a 'special' message to tell the Puck to take what you have and output it. Maybe that could just be 255, or a totally blank message.
  
  

nus_tx will send the command as a string and automatically splits it every 20 bytes, so you don't hit that issue when using it.

How "looks" the evt.data Object of the onWrite function?

It's an ArrayBuffer

How can one read that console.log as long as the puck is connected to the IDE?

You mean if you're not connected to the IDE?

If you're using EspruinoHub you can send a MQTT message to /ble/notify/c7:f9:36:dd:b0:ca/nus/nus_rx every few seconds, and then it'll send back the contents of the console via /ble/data/c7:f9:36:dd:b0:ca/nus/nus_rx.

You can also connect via serial as well, which is easier if you have the USB-TTL converter to do it. Failing that you'd have to save evt.data to a variable and view it later