• State Verified Answer
  • Replies 3 replies
  • Subscribers 67 subscribers
  • Views 823 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 233349
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Certain RPI hardware running bluepy incapable of 4.2-compatible MTU large frame support?

howard n2wx

So we have a great set of 52832-based set of products in the field that negotiate, agree to, and support MTUs larger than 23 bytes.  Nordic's is incidentally one of the least trouble-ridden SoCs and s/w stacks I've ever worked with. One of our products handles multiple peripherals simultaneously while also acting as a BLE central and periph.

Anyway I can't force nRF usage everywhere and have a need to talk to a class of periphs that come up short in 4.2 hardware compatibility with respect to supporting MTUs > 23 bytes even though they'll agree to it during negotiation. Does anyone have a pointer to the rpi/bluepy workaround for this issue? Failing that I'll fragment the messages myself and ask the other fellow to buffer until the end of message but a nice fix in the bluepy side would be a lot easier for all involved.

TIA Howard

  • 0

    Hi Howard

    It seems you are not the only one struggling with this, but apparently not much has happened since the issue was first reported 2 years ago...

    https://github.com/IanHarvey/bluepy/issues/228

    I did some asking around, but couldn't find anyone that has used the bluepy API's before. One of the Linux gurus in the group is coming back next week, and I will check with him as well. 

    Is your issue similar to the one described on Github, where you will send more than 20 bytes from the peripheral, but only see 20 bytes on the bluepy side?

    Are you able to capture a Bluetooth sniffer trace of the MTU exchange and the data transmission?

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Yes, that's it, the github link to the two year old bug is exactly the issue, from MTU negotiation accepting the too long MTU to the bluepy side (acting as a central though) silently truncating my periph's transmissions beyond the 20th payload byte.  It's so aggravating. You know I used to be a large white cat? I've now shrunk, lost weight, turned black, and my personality changed to talkative and cuddly when cold (which is never, I'm a Florida cat)

    I don't have access to the sniffer but the guy doing the other side of the link reported the problem precisely as described. Somewhat annoyingly he's willingly going to deploy the broken implementation because it's economical and too far down the dev process to fix :-(

  • +1 in reply to howard n2wx

    Hi Howard

    If no fix for bluepy exists, and replacing it with something else is not an option (bluez for instance), then the best would probably be simply to set the MTU to 23 through bluepy to avoid the nRF52 side thinking it can send more than 20 bytes of data at a time. 

    Then you can have your application do some fragmentation wizardry when it sees that the MTU is limited to 23. 

    howard n2wx said:
    I don't have access to the sniffer but the guy doing the other side of the link reported the problem precisely as described. Somewhat annoyingly he's willingly going to deploy the broken implementation because it's economical and too far down the dev process to fix :-(

    I feel your pain. Is it annoying to have to add workarounds to your own code because the other side is not following the specification ;)

    howard n2wx said:
    It's so aggravating. You know I used to be a large white cat? I've now shrunk, lost weight, turned black, and my personality changed to talkative and cuddly when cold (which is never, I'm a Florida cat)

    Hm, can't say I have a lot of experience with this issue...

    Have you considered moving to Minnesota? ;)

    Best regards
    Torbjørn

Related