CoAP + DigiMesh - how viable is it?

Hey, I am looking to experiment with the DigiMesh stuff from XBee (probably this https://www.digi.com/products/xbee-rf-solutions/embedded-rf-modules-modems/xbee-pro-900hp)

Is there a recommended approach for carrying CoAP over the DigiMesh protocol in mbed OS? I’m not finding any documentation on the coap_service library (https://github.com/ARMmbed/coap-service) . Is CoAP + DigiMesh viable? Should I be looking into different libraries?

I see Digi has made a whole suite of mbed OS libraries, however they seem to be a little “off the beaten path” and don’t implement EthInterface & friends. Is that going to affect my ability to use the aforementioned coap libraries?

p.s. my short term goal does not involve sending / receiving these CoAP packets over the internet.

DigiMesh (as far as I know) does not use an IP stack, but rather has it’s own MAC layer. So the mbed OS CoAP layer will not work out of the box (because it wants IP sockets). If the data rate is high enough you can probably implement CoAP over DigiMesh, but you probably don’t want to do that, as these ISM-band protocols in general use their own MAC layer to limit energy usage / packet size / enable some specific features; and sending multiple 200+ bytes packets is not recommended (plus it might be impossible to do fast roundtrips if you are in an area where duty-cycle limitations apply - like the EU).

Just FYI, CoAP can be implemented even over SMS ;-).

OK very interesting indeed! My problem domain is similar to the fleet management scenario, I was thinking rather than invent my own service protocol I could use CoAP ( + CBOR). I hate reinventing stuff! Should I be thinking of a different technique?

I do expect a fair bit of packet traffic, though generally much smaller than 200 bytes each (excluding whatever overhead exists outside of CoAP). Potentially dozens of nodes. I’m planning to use (as linked) the ~900 MHz range here in the US as distance is important. I’d never heard of the duty-cycle limitation before!

Do you feel the approach is fundamentally flawed?

EDIT: p.s. I do have some limited but positive experience already with YaCoAp lib

Sorry, didn’t see this reply until now :slight_smile:

If you want ‘raw’ CoAP then yeah, go for it. Just requires a data channel. I was assuming you also want an addressing layer like 6LoWPAN for transport, and those packets in general are too big for these ISM-band LPWAN networks.

FYI, here’s a demo of using the mbed CoAP stack over UDP: https://developer.mbed.org/teams/sandbox/code/coap-example/.

1 Like

@janjongboom thank you for this. The native non-ip addressing of DigiMesh should do the job for me.

I was combing through the M2M mbed client code for clues/canon on using the mbed coap libs. Your example will save me a lot of time!

Any potential to partially use the M2M libs as sort of a C++ wrapper for the coap libs, or do too many other functions come along for the ride?

Probably not worth the trouble… Not sure how complex your application will be though.

For the future: the mbed Client team is working on a version of the CoAP library that is more suitable for outside use w/o any of the Client code in between, but I’m not sure when it will be done.

OK, this is very good to know. With this knowledge, I will resist the urge to build a big C++ helper lib for the existing mbed coap code. I presume the new CoAP lib will eventually supplant the existing one? Or a layer on top? Perhaps I can contribute.