On Thu, Jun 29, 2017 at 10:44 AM, Jan Mulder <jlmul...@xs4all.nl> wrote: > > I verified your patch to select the proper notify characteristic, and that > works correctly. I suppose that this patch does not break other already > working BLE devices, so this one should go in master I think.
Sure, but if it didn't actually fix anything for you, it's pointless. > Yes, did that, and then the receiving/reading of data is still no yet > working (not surprising as I had the correct notify characteristic hard > coded selected). I found out that BLEObject::characteristcStateChanged() is > never called in my situation, so no incoming packets are seen. Not sure why > (yet). Ok, so then it's something else that is wrong. Possibly the Looking at the terminal IO document you posted, I see "In order to receive UART data, the Terminal I/O client has to entitle the Terminal I/O server to send data by granting UART credits via writing the number of credits to be granted to the UART credits RX characteristic (see 6.5)." So I think you need to do a one-byte write with the RX credits to that third characteristic: UART Credits RX Characteristic UUID: 00000003-0000-1000-8000-008025000000 to let the other side know your receive buffer size (aka "credits"). I think that might as well be 255. In fact, it looks like the thing needs that to be refreshed as you empty the buffer, so it needs to be written every time you read a packet. So it does look like that terminal uart needs a specific setup quirk, and only then might my patch be relevant. I think I'll need an actual test target ostc (unless you want to try to hack a patch up as per my suspicion above)? Linus _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface