You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Aditya Xavier <ad...@me.com> on 2018/01/02 10:30:48 UTC

Re: Information regarding blemesh implementation

Thanks, I think I have a better understanding of how this works now.

So, in order to receive a String / byte array instead of a single byte; am I correct that I would need to make the following changes ?

1.	In Status function..
	
	Line :- 172
	struct os_mbuf *msg = NET_BUF_SIMPLE(3); // Change this to a higher number ?

2.	In Set Function
	
	Line :- 203
	gen_on_off_state = buf->om_data[0]; // Retrieve more data than only the 0th position in the array ?

3.	Am not sure whats the purpose of net_buf_simple_pull_le16 etc are.. Would I need that for e.g. being utilised in Level..
	level = (int16_t) net_buf_simple_pull_le16(buf);

If I did miss something or completely wrong about it.. please do let me know.

Thanks,
Aditya Xavier.




> On 29-Dec-2017, at 5:34 PM, Łukasz Rymanowski <lu...@codecoup.pl> wrote:
> 
> Hi,
> 
> On 29 December 2017 at 07:22, Aditya Xavier <ad...@me.com> wrote:
>> Hello, am I correct in my understanding that the BLE Mesh implementation would require us to follow one of the Models as specified?
> You need to create model, but you are not limited to the one specified by BT SIG
> 
>> 
>> For e.g. in my case I need to implement a REST client over BLE Mesh. I believe this can be easily on Bluetooth, however am not sure how to do so on blemesh.
> 
> Probably you need to design your own model for this. In blemesh
> application in main.c you can find example of vendor model which
> implements generic on/off but you can implement your own one.
> 
>> 
>> Please do point me in the right direction if I missed something.
>> 
>> Thanks,
>> Aditya Xavier.
> 
> Hope that helps
> 
> Łukasz


Re: Information regarding blemesh implementation

Posted by Aditya Xavier <ad...@me.com>.
Thanks for explaining.. Yes I am experimenting, and have create a different vendor module to test the same.

However, am still confused about the following aspects..

From my understanding, in BLE; we can transfer data upto 23 bytes in a single packet. 
Incase I want to read all the 20 bytes into a buffer and then process the same.. for e.g. receive a JSON String to parse, would the following approach be correct ?

In vnd_command_set

char value[];
Char data_length
for(int i = 0; i < = buf->om_len; i++){
	value[i] = buf->om_data[i];
}
data_length = buf->om_len;

Or should I be using os_mbuf_pullup ?



And would the status message use os_mbuf_append(om, &val, sizeof(val)); inorder to push the value into the buffer ?

It would be extremely helpful if you could let me know the method to retrieve and push a large string into the mbuf.





> On 02-Jan-2018, at 8:20 PM, Łukasz Rymanowski <lu...@codecoup.pl> wrote:
> 
> Hi,
> 
> On 2 January 2018 at 11:30, Aditya Xavier <ad...@me.com> wrote:
>> Thanks, I think I have a better understanding of how this works now.
>> 
>> So, in order to receive a String / byte array instead of a single byte; am I correct that I would need to make the following changes ?
> 
> As you probably know, you should create own model and define own
> operation opcodes instead of using on/off model, but I understand you
> are doing some experiments which is fine
>> 
>> 1.      In Status function..
>> 
>>        Line :- 172
>>        struct os_mbuf *msg = NET_BUF_SIMPLE(3); // Change this to a higher number ?
> 
> Function gen_onoff_status() (refered above)  shows how to send message
> over the model as a response to some device (address already in ctx)
> In on/off model we have there 2 octets for opcode and one for status.
> So you can play around here as you suggested above.
> 
>> 
>> 2.      In Set Function
>> 
>>        Line :- 203
>>        gen_on_off_state = buf->om_data[0]; // Retrieve more data than only the 0th position in the array ?
> 
> Buf is struct os_mbuf * and to see how to use it I recommend to read
> this  https://mynewt.apache.org/v1_0_0/os/core_os/mbuf/mbuf/
> In general buf->om_data points to data sent by remote device.
> 
>> 
>> 3.      Am not sure whats the purpose of net_buf_simple_pull_le16 etc are.. Would I need that for e.g. being utilised in Level..
>>        level = (int16_t) net_buf_simple_pull_le16(buf);
> 
> Level is 2 octet value and according to Mesh spec it is sent in LE
> order. This helper decodes this and also moves data pointer in buf by
> 2.
> 
>> 
>> If I did miss something or completely wrong about it.. please do let me know.
>> 
>> Thanks,
>> Aditya Xavier.
>> 
> 
> Best
> \Łukasz
>> 
>> 
>> 
>>> On 29-Dec-2017, at 5:34 PM, Łukasz Rymanowski <lu...@codecoup.pl> wrote:
>>> 
>>> Hi,
>>> 
>>> On 29 December 2017 at 07:22, Aditya Xavier <ad...@me.com> wrote:
>>>> Hello, am I correct in my understanding that the BLE Mesh implementation would require us to follow one of the Models as specified?
>>> You need to create model, but you are not limited to the one specified by BT SIG
>>> 
>>>> 
>>>> For e.g. in my case I need to implement a REST client over BLE Mesh. I believe this can be easily on Bluetooth, however am not sure how to do so on blemesh.
>>> 
>>> Probably you need to design your own model for this. In blemesh
>>> application in main.c you can find example of vendor model which
>>> implements generic on/off but you can implement your own one.
>>> 
>>>> 
>>>> Please do point me in the right direction if I missed something.
>>>> 
>>>> Thanks,
>>>> Aditya Xavier.
>>> 
>>> Hope that helps
>>> 
>>> Łukasz
>> 


Re: Information regarding blemesh implementation

Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi,

On 2 January 2018 at 11:30, Aditya Xavier <ad...@me.com> wrote:
> Thanks, I think I have a better understanding of how this works now.
>
> So, in order to receive a String / byte array instead of a single byte; am I correct that I would need to make the following changes ?

As you probably know, you should create own model and define own
operation opcodes instead of using on/off model, but I understand you
are doing some experiments which is fine
>
> 1.      In Status function..
>
>         Line :- 172
>         struct os_mbuf *msg = NET_BUF_SIMPLE(3); // Change this to a higher number ?

Function gen_onoff_status() (refered above)  shows how to send message
 over the model as a response to some device (address already in ctx)
In on/off model we have there 2 octets for opcode and one for status.
So you can play around here as you suggested above.

>
> 2.      In Set Function
>
>         Line :- 203
>         gen_on_off_state = buf->om_data[0]; // Retrieve more data than only the 0th position in the array ?

Buf is struct os_mbuf * and to see how to use it I recommend to read
this  https://mynewt.apache.org/v1_0_0/os/core_os/mbuf/mbuf/
In general buf->om_data points to data sent by remote device.

>
> 3.      Am not sure whats the purpose of net_buf_simple_pull_le16 etc are.. Would I need that for e.g. being utilised in Level..
>         level = (int16_t) net_buf_simple_pull_le16(buf);

Level is 2 octet value and according to Mesh spec it is sent in LE
order. This helper decodes this and also moves data pointer in buf by
2.

>
> If I did miss something or completely wrong about it.. please do let me know.
>
> Thanks,
> Aditya Xavier.
>

Best
\Łukasz
>
>
>
>> On 29-Dec-2017, at 5:34 PM, Łukasz Rymanowski <lu...@codecoup.pl> wrote:
>>
>> Hi,
>>
>> On 29 December 2017 at 07:22, Aditya Xavier <ad...@me.com> wrote:
>>> Hello, am I correct in my understanding that the BLE Mesh implementation would require us to follow one of the Models as specified?
>> You need to create model, but you are not limited to the one specified by BT SIG
>>
>>>
>>> For e.g. in my case I need to implement a REST client over BLE Mesh. I believe this can be easily on Bluetooth, however am not sure how to do so on blemesh.
>>
>> Probably you need to design your own model for this. In blemesh
>> application in main.c you can find example of vendor model which
>> implements generic on/off but you can implement your own one.
>>
>>>
>>> Please do point me in the right direction if I missed something.
>>>
>>> Thanks,
>>> Aditya Xavier.
>>
>> Hope that helps
>>
>> Łukasz
>