Date   

Re: [Zephyr-devel] API meeting: Agenda

Steven Riedl <steve@...>
 

Question?

Would my two driver addition PR be in this meeting? If not could you direct me to the appropriate call/place?


--
Steven Riedl
(404) 205-9487
Skype: sriedl

"so you have a vested interest in maintaining the inefficient status quo" G. Niemeijer






On Jan 5, 2021, at 10:44 AM, Carles Cufi via lists.zephyrproject.org <carles.cufi=nordicsemi.no@...> wrote:

One extra item to the agenda:

- drivers: eeprom: mark the EEPROM API as stable
 - PR: https://github.com/zephyrproject-rtos/zephyr/pull/31076

-----Original Message-----
From: Cufi, Carles
Sent: 05 January 2021 13:08
To: devel@...; users@...
Subject: API meeting: Agenda

Hi all,

Agenda for today, taken from the Triage column in the project.

- API to correlate system time with external time sources and translate
uptime to wall-clock time
 - PR: https://github.com/zephyrproject-rtos/zephyr/pull/28977
- drivers: gpio: Combined drive strength flags
 - PR: https://github.com/zephyrproject-rtos/zephyr/pull/30331
- drivers: pwm: add functions for capturing pwm pulse width and period
 - PR: https://github.com/zephyrproject-rtos/zephyr/pull/26025

If you have additional items please let me know.

Teams link: https://teams.microsoft.com/l/meetup-
join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40threa
d.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-
b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-
5e334e88f6d8%22%7d

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-
Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-
8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles







Re: API meeting: Agenda

Carles Cufi
 

One extra item to the agenda:

- drivers: eeprom: mark the EEPROM API as stable
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/31076

-----Original Message-----
From: Cufi, Carles
Sent: 05 January 2021 13:08
To: devel@lists.zephyrproject.org; users@lists.zephyrproject.org
Subject: API meeting: Agenda

Hi all,

Agenda for today, taken from the Triage column in the project.

- API to correlate system time with external time sources and translate
uptime to wall-clock time
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/28977
- drivers: gpio: Combined drive strength flags
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/30331
- drivers: pwm: add functions for capturing pwm pulse width and period
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/26025

If you have additional items please let me know.

Teams link: https://teams.microsoft.com/l/meetup-
join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40threa
d.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-
b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-
5e334e88f6d8%22%7d

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-
Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-
8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: Network forum agenda

Jukka Rissanen
 

Hi all,

I am cancelling todays (5 Jan) Network forum meeting as there is no
topics to discuss.


Cheers,
Jukka

On Mon, 2021-01-04 at 09:51 +0200, Jukka Rissanen wrote:
Hi all,

There is a network forum meeting tomorrow Tue 5 Jan at 8AM PST /
17.00
CET.

Currently the agenda is empty, so if there is anything network
related
topics you want to discuss, please let me know.


Live Agenda/Minutes:
https://docs.google.com/document/d/1qFsOpvbyLzhflJbbv4Vl__497pKHDoUCy9hjAveyCX0/edit?usp=sharing

Shared Folder:
https://drive.google.com/drive/folders/1j6d0FLeOjiMil1Ellb59AsfHdzuWdAAc?usp=sharing

___________________________________________________________
Join Microsoft Teams Meeting (
https://teams.microsoft.com/l/meetup-join/19%3ameeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d
)
+1 321-558-6518 ( tel:+1 321-558-6518,,458216365# ) United States,
Orlando (Toll)
Conference ID: 458 216 365#
Local numbers (
https://dialin.teams.microsoft.com/325d775d-c910-441e-90d0-353ebaa56cdd?id=458216365
) | Reset PIN ( https://mysettings.lync.com/pstnconferencing ) |
Learn
more about Teams ( https://aka.ms/JoinTeamsMeeting ) | Meeting
options
(
https://teams.microsoft.com/meetingOptions/?organizerId=841a7c92-7816-4faf-9887-5e334e88f6d8&tenantId=af0096d9-700c-411a-b795-b3dd7122bad2&threadId=19_meeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw@thread.v2&messageId=0&language=en-US
)


Cheers,
Jukka







API meeting: Agenda

Carles Cufi
 


Re: Clock Control question

Chruściński, Krzysztof
 

Hi,

 

What do you mean when you say “the Clock”? clock control in case of Nordic is using single device and subsys argument determines the type of the clock (high frequency, low frequency, etc.). However, clock control API is assuming single user of the clock and in case of those clock types there are multiple users (e.g. Bluetooth or USB requests same HF clock subsys). Because of that, clock control API cannot be used directly but rather use onoff manager API which manages multiple requests.

 

Which clock you want to “extract”? Is it current system clock? For that check kernel API like “k_cycle_get_32” or “k_uptime_get”.

 

Regards,

Krzysztof

 

From: users@... <users@...> On Behalf Of Steven Ghekiere via lists.zephyrproject.org
Sent: Friday, January 1, 2021 4:54 PM
To: users@...
Subject: [Zephyr-users] Clock Control question

 

Hi!

 

First off, best wishes for 2021! :)

 

I've been struggling with using a Clock control. My aim is to be able to calibrate two clocks using BLE and nordic nrf52840 chipsets. 

 

I've looked through the Clock Control API and found the relevant device binding. 

But now I'm supposed to use a "clock_control_subsys_t​" struct which "is a type to identify a clock controller sub-system". A bit vague but I think I understand it. 

 

However I'm not sure how I can initialize this variable? Using this without any initialization results in an error when calling "clock_control_on​". Or maybe is my device binding "DT_LABEL(DT_INST(0, nordic_nrf_clock))" wrong? I found this in a couple related tests I think...

 

Also, since I'm using a Nordic device I assume I'm able to include the <include/drivers/clock_control/clock_control_​nrf.h>.

Since there isn't an example for this (there is for litex, which I'm not familiar with), I'm not too sure how the original Clock Control and the Nordic Clock Control work with each other.

The litex example also use totally different structs which makes me believe this isn't worth looking into.

 

So to sum up,

 

1) How do I setup the Clock? Am I doing something wrong? I can send snippets if needed.

 

2) How should I use both nRF and normal Clock Control?

 

3) How can I 'extract' the clock value (to send it using Bluetooth) and set it on the receiving end.

 

Greatly appreciated,

 

Steven


Network forum agenda

Jukka Rissanen
 


Newbie question: K64F with SD card

Dave Nadler <drn@...>
 

Hello all, Zephyr newbie here, sorry if this is a simple question...
I've used Freescale/NXP K64F for a number of successful projects using FreeRTOS.
Considering using Zephyr because of driver/OS integration, however...

Looking at "K6F Freedom" board, which we've used often as a starting point,
SDcard driver plus a few other things seem to be missing?
What are the steps to add drivers to support:

1) ~POSIX file operations to the SD card?
2) USB OTG?
3) internal DAC?

If that's too hard, can anyone recommend an ARM chip with already well-supported
SD card, USB (especially device), I2C+SPI, serial UART, internal ADC and DAC.

Thanks in advance for any pointers,
Best Regards, Dave

-- 
Dave Nadler, USA East Coast voice (978) 263-0097, drn@..., Skype 
 Dave.Nadler1


Clock Control question

Steven Ghekiere <steven.ghekiere@...>
 

Hi!


First off, best wishes for 2021! :)


I've been struggling with using a Clock control. My aim is to be able to calibrate two clocks using BLE and nordic nrf52840 chipsets. 


I've looked through the Clock Control API and found the relevant device binding. 

But now I'm supposed to use a "clock_control_subsys_t​" struct which "is a type to identify a clock controller sub-system". A bit vague but I think I understand it. 


However I'm not sure how I can initialize this variable? Using this without any initialization results in an error when calling "clock_control_on​". Or maybe is my device binding "DT_LABEL(DT_INST(0, nordic_nrf_clock))" wrong? I found this in a couple related tests I think...


Also, since I'm using a Nordic device I assume I'm able to include the <include/drivers/clock_control/clock_control_​nrf.h>.

Since there isn't an example for this (there is for litex, which I'm not familiar with), I'm not too sure how the original Clock Control and the Nordic Clock Control work with each other.

The litex example also use totally different structs which makes me believe this isn't worth looking into.


So to sum up,


1) How do I setup the Clock? Am I doing something wrong? I can send snippets if needed.


2) How should I use both nRF and normal Clock Control?


3) How can I 'extract' the clock value (to send it using Bluetooth) and set it on the receiving end.


Greatly appreciated,


Steven


Re: West init error

Carles Cufi
 

Hi there,

 

Try unsetting your ZEPHYR_BASE environment variable. west will use that to look for a workspace.

 

Carles

 

From: users@... <users@...> On Behalf Of CHANDRANSHU GUPTA via lists.zephyrproject.org
Sent: 26 December 2020 13:41
To: users@...
Subject: [Zephyr-users] West init error

 

Hello,

 

I cloned Zephyr project using west init -m <webpage> but didn't specify any local directory.

Now when I am again trying to use 'west init zephyrproject' command I am receiving an error saying " already initialized to /home/chandranshu " aborting.

 

I have even tried to uninstall west using pip uninstall and deleted west related directory in /.local/bin path but still, I am getting this error again and again.

 

Please help me with this. How can I resolve this issue? Is there any way using which I can completely remove west from my system and start from fresh? 

 

 

 


West init error

CHANDRANSHU GUPTA <2019pcs0018@...>
 

Hello,

I cloned Zephyr project using west init -m <webpage> but didn't specify any local directory.
Now when I am again trying to use 'west init zephyrproject' command I am receiving an error saying " already initialized to /home/chandranshu " aborting.

I have even tried to uninstall west using pip uninstall and deleted west related directory in /.local/bin path but still, I am getting this error again and again.

Please help me with this. How can I resolve this issue? Is there any way using which I can completely remove west from my system and start from fresh? 




Bypassing shell wilcard feature #uart

antoker@...
 

Hi,

Is it possible to pass ? or * without shell interpreting those characters as wildcards? I literally want to pass ? or * to a shell command

BR


Re: Zephyr Low Level BLE Radio question

Chettimada, Vinayak Kariappa
 

> Since I’m changing the behaviour of the BLE protocol quite a bit with this, this means that it won’t comply to the Bluetooth specs anyway? Meaning the first advertisement can be omitted if I’d really like so?

 

If you do not comply to Bluetooth standards, if your changes void backwards compatibility and interoperability, do not use the term to associate your changes.

 

> I’m not sure what ‘apply’ means. You’re sadv_uggesting I create a seperate “ull_adv_aux_ptr“ function and use this by changing the Zephyr code? Or creating another copy of the ll_aux.c and make sure I use that version?

 

I mean, assign the channel index derived from your algorithm in the function instead of the the now hardcoded value of 0, (the fixme comment thats present).

 

-Vinayak

 

From: steven ghekiere <stevenghekiere@...>
Sent: 18 December 2020 21:04
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>; users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

 

Hi there

 

Still waiting for your answer!

 

Thanks,

Steven

 

From: steven ghekiere
Sent: woensdag 16 december 2020 20:46
To: Chettimada, Vinayak
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

> Yes., thats against the specification and inter-operability.

 

Since I’m changing the behaviour of the BLE protocol quite a bit with this, this means that it won’t comply to the Bluetooth specs anyway? Meaning the first advertisement can be omitted if I’d really like so?

 

> Not override, but apply the channel_index from your own frequency hopping algorithm here. This will be compliant as a implementation specific channel selection.

 

I’m not sure what ‘apply’ means. You’re sadv_uggesting I create a seperate “ull_adv_aux_ptr“ function and use this by changing the Zephyr code? Or creating another copy of the ll_aux.c and make sure I use that version?

 

And if you guys would be interested, I’d be happy to share this (once finished of course, if its worth anything).

It’s a bit more than just a frequency hopping change, but since this is the only low level thing, it’s been a blocker for weeks now.

 

Sorry for all the questions, I don’t really have any other person to ask such questions.

For sure first time dealing with such low level stuff…

 

Steven

 

 

 

From: Chettimada, Vinayak
Sent: woensdag 16 december 2020 19:12
To: steven ghekiere
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

> What you’re saying is sending only the bigger second part of the message is against Bluetooth’s specifications?

 

Yes., thats against the specification and inter-operability.

 

> So what you’re suggesting is that I somehow override this function, or change the behaviour myself?

 

Not override, but apply the channel_index from your own frequency hopping algorithm here. This will be compliant as a implementation specific channel selection.

You are welcome to contribute the implementation if you desire so.

 

-Vinayak

 

 

From: steven ghekiere <stevenghekiere@...>
Sent: 16 December 2020 19:02
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Vinayak,

 

Sorry for the late reply, been busy working today

 

> There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

What you’re saying is sending only the bigger second part of the message is against Bluetooth’s specifications?

 

I dug a bit deeper into the code and I’m still confused.

 

Dyou mean the code on line 796:

aux_ptr->chan_idx = 0U;

 

So what you’re suggesting is that I somehow override this function, or change the behaviour myself?

 

Maybe I can make things more clear, I need to create my own frequency hopping algorithm. To do this my first step would be to send data over a set frequency (I thought). Afterwards I can add logic to the channel selection etc.

 

Thanks a lot, really!

 

Steven

 

From: Chettimada, Vinayak
Sent: woensdag 16 december 2020 5:30
To: steven ghekiere
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

> I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

Refer to Bluetooth Specification V5.2, Vol 6, Part B, section 4.4.2.1 Advertising channel index selection:

 

Advertising events use three predefined primary advertising physical channels.

Primary advertising channel indices are either used or unused.

For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising

channel index used in the Channel Index subfield of the AuxPtr field is

implementation specific. It is recommended that sufficient channel diversity is

used to avoid collisions.

 

In the Zephyr BLE controller, advertising extensions is experimental, and the function that fills the advertising channel can be found here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/ll_sw/ull_adv_aux.c#L788

 

 

>Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.

 

Correct.

 

>Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

These bits decide the `advertising event` on the primary channels, to use channel 37, 38, and 39. The `small header` is repeated in these channels inside a standard `advertising event`, and that is what is selected by these bits.

For further details please refer to Bluetooth specifications.

 

-Vinayak

 

From: steven ghekiere <stevenghekiere@...>
Sent: 15 December 2020 20:51
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>; Marciano Preciado <marciano@...>
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

 

Hey Vinayak,

 

Thanks for the reply!

 

I had a quick look at the extended advertising links you mentioned.

 

I assumed the general GAP protocol does similar stuff (as you showed) but doubted that it could just set data on a set channel.

I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

(Wrote this as I was reading through your provided documentation)

As I understand, the ‘bt_le_adv_param parameter of the create method’ has a 32 bit options field (0-17 actually used?).

In these options we have:

  • Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.
  • Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

 

Thanks!

 

Steven

 

 

From: Chettimada, Vinayak
Sent: dinsdag 15 december 2020 20:17
To: stevenghekiere@...; Marciano Preciado
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hi,

 

If you are building a Bluetooth Low Energy application using Zephyr, then you should use the public APIs, not call internal subsystem functions unless you know what you are doing.

 

I think you are looking for the below mentioned options when calling bt_le_ext_adv_create (https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.bt_le_ext_adv_create)

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

 

These are for the primary advertising channels, auxiliary PDU channels selection is controller implementation specific.

 

If you are not using Bluetooth Low Energy stack, then you should refer to nRF52840 product specification for implementing your proprietary radio protocol.

 

>The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too

 

Contributions to improve the code, comments and add new features are always welcome.

 

Regards,

Vinayak

 

 

From: users@... <users@...> On Behalf Of steven ghekiere via lists.zephyrproject.org
Sent: 15 December 2020 19:48
To: Marciano Preciado <marciano@...>
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

 

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 

 

 

 

 


Re: Zephyr Low Level BLE Radio question

steven ghekiere <stevenghekiere@...>
 

 

Hi there

 

Still waiting for your answer!

 

Thanks,

Steven

 

From: steven ghekiere
Sent: woensdag 16 december 2020 20:46
To: Chettimada, Vinayak
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

> Yes., thats against the specification and inter-operability.

 

Since I’m changing the behaviour of the BLE protocol quite a bit with this, this means that it won’t comply to the Bluetooth specs anyway? Meaning the first advertisement can be omitted if I’d really like so?

 

> Not override, but apply the channel_index from your own frequency hopping algorithm here. This will be compliant as a implementation specific channel selection.

 

I’m not sure what ‘apply’ means. You’re sadv_uggesting I create a seperate “ull_adv_aux_ptr“ function and use this by changing the Zephyr code? Or creating another copy of the ll_aux.c and make sure I use that version?

 

And if you guys would be interested, I’d be happy to share this (once finished of course, if its worth anything).

It’s a bit more than just a frequency hopping change, but since this is the only low level thing, it’s been a blocker for weeks now.

 

Sorry for all the questions, I don’t really have any other person to ask such questions.

For sure first time dealing with such low level stuff…

 

Steven

 

 

 

From: Chettimada, Vinayak
Sent: woensdag 16 december 2020 19:12
To: steven ghekiere
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

> What you’re saying is sending only the bigger second part of the message is against Bluetooth’s specifications?

 

Yes., thats against the specification and inter-operability.

 

> So what you’re suggesting is that I somehow override this function, or change the behaviour myself?

 

Not override, but apply the channel_index from your own frequency hopping algorithm here. This will be compliant as a implementation specific channel selection.

You are welcome to contribute the implementation if you desire so.

 

-Vinayak

 

 

From: steven ghekiere <stevenghekiere@...>
Sent: 16 December 2020 19:02
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Vinayak,

 

Sorry for the late reply, been busy working today

 

> There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

What you’re saying is sending only the bigger second part of the message is against Bluetooth’s specifications?

 

I dug a bit deeper into the code and I’m still confused.

 

Dyou mean the code on line 796:

aux_ptr->chan_idx = 0U;

 

So what you’re suggesting is that I somehow override this function, or change the behaviour myself?

 

Maybe I can make things more clear, I need to create my own frequency hopping algorithm. To do this my first step would be to send data over a set frequency (I thought). Afterwards I can add logic to the channel selection etc.

 

Thanks a lot, really!

 

Steven

 

From: Chettimada, Vinayak
Sent: woensdag 16 december 2020 5:30
To: steven ghekiere
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

> I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

Refer to Bluetooth Specification V5.2, Vol 6, Part B, section 4.4.2.1 Advertising channel index selection:

 

Advertising events use three predefined primary advertising physical channels.

Primary advertising channel indices are either used or unused.

For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising

channel index used in the Channel Index subfield of the AuxPtr field is

implementation specific. It is recommended that sufficient channel diversity is

used to avoid collisions.

 

In the Zephyr BLE controller, advertising extensions is experimental, and the function that fills the advertising channel can be found here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/ll_sw/ull_adv_aux.c#L788

 

 

>Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.

 

Correct.

 

>Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

These bits decide the `advertising event` on the primary channels, to use channel 37, 38, and 39. The `small header` is repeated in these channels inside a standard `advertising event`, and that is what is selected by these bits.

For further details please refer to Bluetooth specifications.

 

-Vinayak

 

From: steven ghekiere <stevenghekiere@...>
Sent: 15 December 2020 20:51
To: Chettimada, Vinayak <
vinayak.kariappa.chettimada@...>; Marciano Preciado <marciano@...>
Cc:
users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

 

Hey Vinayak,

 

Thanks for the reply!

 

I had a quick look at the extended advertising links you mentioned.

 

I assumed the general GAP protocol does similar stuff (as you showed) but doubted that it could just set data on a set channel.

I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

(Wrote this as I was reading through your provided documentation)

As I understand, the ‘bt_le_adv_param parameter of the create method’ has a 32 bit options field (0-17 actually used?).

In these options we have:

  • Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.
  • Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

 

Thanks!

 

Steven

 

 

From: Chettimada, Vinayak
Sent: dinsdag 15 december 2020 20:17
To: stevenghekiere@...; Marciano Preciado
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hi,

 

If you are building a Bluetooth Low Energy application using Zephyr, then you should use the public APIs, not call internal subsystem functions unless you know what you are doing.

 

I think you are looking for the below mentioned options when calling bt_le_ext_adv_create (https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.bt_le_ext_adv_create)

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

 

These are for the primary advertising channels, auxiliary PDU channels selection is controller implementation specific.

 

If you are not using Bluetooth Low Energy stack, then you should refer to nRF52840 product specification for implementing your proprietary radio protocol.

 

>The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too

 

Contributions to improve the code, comments and add new features are always welcome.

 

Regards,

Vinayak

 

 

From: users@... <users@...> On Behalf Of steven ghekiere via lists.zephyrproject.org
Sent: 15 December 2020 19:48
To: Marciano Preciado <
marciano@...>
Cc:
users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

 

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 

 

 

 

 


SDK 0.12.0 Release

Kumar Gala
 

Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.12.0

NOTE: In some cases changes are required to utilize SDK 0.12.0 with Zephyr (for example building for xtensa)

Please download and try things out and report any issues.

• General:

• Updated to using buildkite for CI
• Updated yocto 3.1.1
• Build aarch64 (arm64) linux host toolchains.
• Moved to using a zephyr fork of crosstool-ng
• Update bossa to 1.9.1+ + SAM4L support
• cmake: Set HOST_TOOLS_HOME based on OS_PLATFORM
• tweaks to installer script
• QEMU:

• Updated to QEMU 5.1.0
• Added icount support for ARC
• Backport RISC-V PMP fixes from upstream qemu
• OpenOCD:

• Updated to 20201109 snapshot [e44539d66c8929679321704768125df9ba7d5f67]
• newlib:

• Updated to version 3.3
• Updated xtensa to version 3.3 (in sync with all arch's)
• Change default builds to be built with -O2
• binutils:

• updated to version 2.35.1
• gcc:

• Updated to version 10.2.0
• Fix bug in libgcc builds w/regards to ARM cmse support
• gdb:

• Updated to version 9.2
• xtensa:

• remove HAL from SDK build

Thanks to all that contributed fixes and enhancements to this version of the SDK.


k_sleep() and C++

Kim Bønderga rd <kim@...>
 

I posted this (slightly modified) on slack a week ago, but didn't really get any response (on my primary problem)
Hope this is better

I'm mixing CPP and threads.

I've made a C++ 'thread'-class wrapping some of the normal k_thread functions.

The 'entry' function is a static function within the class, using first argument to denote the actual instance of my thread object.Something like this:
From the constructor:
id = k_thread_create(&zThread,zStack, K_THREAD_STACK_SIZEOF(zStack),
runner,
this, p1, p2,
priority, 0, K_FOREVER);
The stack is defined in my thread class like this:
private:
K_KERNEL_STACK_MEMBER(zStack, 4000);
The static runner:
private:
static void runner(void *p0, void *p1, void *p2);void thread::runner(void* p0, void* p1, void* p2)
{
thread* inst = static_cast<thread*>(p0);
inst->runnerInst(p1, p2);
}
and the instance-specific runner:
private:
void runnerInst(void *p1, void *p2);voidt hread::runnerInst(void* p1, void* p2)
{
threadFunc(p1, p2); // This is a virtual function being overwritten by classes deriving from thread
}

threadFunc is a private method like this (example):
private:
void threadFunc(void* p1, void* p2) {
while (!stopCondition()) {
:
k_sleep(K_MSEC(1000));
}
}


It has been working fine on Zephyr 2.2 but now on Zephyr 2.4 I often see crashes with BUS ERRORs.
It seems to always come if a thread calls k_sleep() (but not everytime I call k_sleep())
Inspired by samples/cpp_synchronization I tried changing my k_sleep()'s to k_timer_status_sync() . It made my sample project work again.

I can live with that, but eventually I'll call something calling k_sleep()
Can anyone explain if I'm doing something wrong (and why) or is it a coincidence that k_timer_status_sync() approach is working?

/Kim Bøndergaard


Re: Zephyr Low Level BLE Radio question

steven ghekiere <stevenghekiere@...>
 

> Yes., thats against the specification and inter-operability.

 

Since I’m changing the behaviour of the BLE protocol quite a bit with this, this means that it won’t comply to the Bluetooth specs anyway? Meaning the first advertisement can be omitted if I’d really like so?

 

> Not override, but apply the channel_index from your own frequency hopping algorithm here. This will be compliant as a implementation specific channel selection.

 

I’m not sure what ‘apply’ means. You’re sadv_uggesting I create a seperate “ull_adv_aux_ptr“ function and use this by changing the Zephyr code? Or creating another copy of the ll_aux.c and make sure I use that version?

 

And if you guys would be interested, I’d be happy to share this (once finished of course, if its worth anything).

It’s a bit more than just a frequency hopping change, but since this is the only low level thing, it’s been a blocker for weeks now.

 

Sorry for all the questions, I don’t really have any other person to ask such questions.

For sure first time dealing with such low level stuff…

 

Steven

 

 

 

From: Chettimada, Vinayak
Sent: woensdag 16 december 2020 19:12
To: steven ghekiere
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

> What you’re saying is sending only the bigger second part of the message is against Bluetooth’s specifications?

 

Yes., thats against the specification and inter-operability.

 

> So what you’re suggesting is that I somehow override this function, or change the behaviour myself?

 

Not override, but apply the channel_index from your own frequency hopping algorithm here. This will be compliant as a implementation specific channel selection.

You are welcome to contribute the implementation if you desire so.

 

-Vinayak

 

 

From: steven ghekiere <stevenghekiere@...>
Sent: 16 December 2020 19:02
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Vinayak,

 

Sorry for the late reply, been busy working today

 

> There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

What you’re saying is sending only the bigger second part of the message is against Bluetooth’s specifications?

 

I dug a bit deeper into the code and I’m still confused.

 

Dyou mean the code on line 796:

aux_ptr->chan_idx = 0U;

 

So what you’re suggesting is that I somehow override this function, or change the behaviour myself?

 

Maybe I can make things more clear, I need to create my own frequency hopping algorithm. To do this my first step would be to send data over a set frequency (I thought). Afterwards I can add logic to the channel selection etc.

 

Thanks a lot, really!

 

Steven

 

From: Chettimada, Vinayak
Sent: woensdag 16 december 2020 5:30
To: steven ghekiere
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

> I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

Refer to Bluetooth Specification V5.2, Vol 6, Part B, section 4.4.2.1 Advertising channel index selection:

 

Advertising events use three predefined primary advertising physical channels.

Primary advertising channel indices are either used or unused.

For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising

channel index used in the Channel Index subfield of the AuxPtr field is

implementation specific. It is recommended that sufficient channel diversity is

used to avoid collisions.

 

In the Zephyr BLE controller, advertising extensions is experimental, and the function that fills the advertising channel can be found here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/ll_sw/ull_adv_aux.c#L788

 

 

>Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.

 

Correct.

 

>Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

These bits decide the `advertising event` on the primary channels, to use channel 37, 38, and 39. The `small header` is repeated in these channels inside a standard `advertising event`, and that is what is selected by these bits.

For further details please refer to Bluetooth specifications.

 

-Vinayak

 

From: steven ghekiere <stevenghekiere@...>
Sent: 15 December 2020 20:51
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>; Marciano Preciado <marciano@...>
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

 

Hey Vinayak,

 

Thanks for the reply!

 

I had a quick look at the extended advertising links you mentioned.

 

I assumed the general GAP protocol does similar stuff (as you showed) but doubted that it could just set data on a set channel.

I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

(Wrote this as I was reading through your provided documentation)

As I understand, the ‘bt_le_adv_param parameter of the create method’ has a 32 bit options field (0-17 actually used?).

In these options we have:

  • Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.
  • Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

 

Thanks!

 

Steven

 

 

From: Chettimada, Vinayak
Sent: dinsdag 15 december 2020 20:17
To: stevenghekiere@...; Marciano Preciado
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hi,

 

If you are building a Bluetooth Low Energy application using Zephyr, then you should use the public APIs, not call internal subsystem functions unless you know what you are doing.

 

I think you are looking for the below mentioned options when calling bt_le_ext_adv_create (https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.bt_le_ext_adv_create)

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

 

These are for the primary advertising channels, auxiliary PDU channels selection is controller implementation specific.

 

If you are not using Bluetooth Low Energy stack, then you should refer to nRF52840 product specification for implementing your proprietary radio protocol.

 

>The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too

 

Contributions to improve the code, comments and add new features are always welcome.

 

Regards,

Vinayak

 

 

From: users@... <users@...> On Behalf Of steven ghekiere via lists.zephyrproject.org
Sent: 15 December 2020 19:48
To: Marciano Preciado <marciano@...>
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

 

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 

 

 

 


Re: Zephyr Low Level BLE Radio question

Chettimada, Vinayak Kariappa
 

> What you’re saying is sending only the bigger second part of the message is against Bluetooth’s specifications?

 

Yes., thats against the specification and inter-operability.

 

> So what you’re suggesting is that I somehow override this function, or change the behaviour myself?

 

Not override, but apply the channel_index from your own frequency hopping algorithm here. This will be compliant as a implementation specific channel selection.

You are welcome to contribute the implementation if you desire so.

 

-Vinayak

 

 

From: steven ghekiere <stevenghekiere@...>
Sent: 16 December 2020 19:02
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Vinayak,

 

Sorry for the late reply, been busy working today

 

> There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

What you’re saying is sending only the bigger second part of the message is against Bluetooth’s specifications?

 

I dug a bit deeper into the code and I’m still confused.

 

Dyou mean the code on line 796:

aux_ptr->chan_idx = 0U;

 

So what you’re suggesting is that I somehow override this function, or change the behaviour myself?

 

Maybe I can make things more clear, I need to create my own frequency hopping algorithm. To do this my first step would be to send data over a set frequency (I thought). Afterwards I can add logic to the channel selection etc.

 

Thanks a lot, really!

 

Steven

 

From: Chettimada, Vinayak
Sent: woensdag 16 december 2020 5:30
To: steven ghekiere
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

> I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

Refer to Bluetooth Specification V5.2, Vol 6, Part B, section 4.4.2.1 Advertising channel index selection:

 

Advertising events use three predefined primary advertising physical channels.

Primary advertising channel indices are either used or unused.

For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising

channel index used in the Channel Index subfield of the AuxPtr field is

implementation specific. It is recommended that sufficient channel diversity is

used to avoid collisions.

 

In the Zephyr BLE controller, advertising extensions is experimental, and the function that fills the advertising channel can be found here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/ll_sw/ull_adv_aux.c#L788

 

 

>Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.

 

Correct.

 

>Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

These bits decide the `advertising event` on the primary channels, to use channel 37, 38, and 39. The `small header` is repeated in these channels inside a standard `advertising event`, and that is what is selected by these bits.

For further details please refer to Bluetooth specifications.

 

-Vinayak

 

From: steven ghekiere <stevenghekiere@...>
Sent: 15 December 2020 20:51
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>; Marciano Preciado <marciano@...>
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

 

Hey Vinayak,

 

Thanks for the reply!

 

I had a quick look at the extended advertising links you mentioned.

 

I assumed the general GAP protocol does similar stuff (as you showed) but doubted that it could just set data on a set channel.

I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

(Wrote this as I was reading through your provided documentation)

As I understand, the ‘bt_le_adv_param parameter of the create method’ has a 32 bit options field (0-17 actually used?).

In these options we have:

  • Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.
  • Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

 

Thanks!

 

Steven

 

 

From: Chettimada, Vinayak
Sent: dinsdag 15 december 2020 20:17
To: stevenghekiere@...; Marciano Preciado
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hi,

 

If you are building a Bluetooth Low Energy application using Zephyr, then you should use the public APIs, not call internal subsystem functions unless you know what you are doing.

 

I think you are looking for the below mentioned options when calling bt_le_ext_adv_create (https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.bt_le_ext_adv_create)

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

 

These are for the primary advertising channels, auxiliary PDU channels selection is controller implementation specific.

 

If you are not using Bluetooth Low Energy stack, then you should refer to nRF52840 product specification for implementing your proprietary radio protocol.

 

>The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too

 

Contributions to improve the code, comments and add new features are always welcome.

 

Regards,

Vinayak

 

 

From: users@... <users@...> On Behalf Of steven ghekiere via lists.zephyrproject.org
Sent: 15 December 2020 19:48
To: Marciano Preciado <marciano@...>
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

 

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 

 

 


Re: Zephyr Low Level BLE Radio question

steven ghekiere <stevenghekiere@...>
 

Hey Vinayak,

 

Sorry for the late reply, been busy working today

 

> There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

What you’re saying is sending only the bigger second part of the message is against Bluetooth’s specifications?

 

I dug a bit deeper into the code and I’m still confused.

 

Dyou mean the code on line 796:

aux_ptr->chan_idx = 0U;

 

So what you’re suggesting is that I somehow override this function, or change the behaviour myself?

 

Maybe I can make things more clear, I need to create my own frequency hopping algorithm. To do this my first step would be to send data over a set frequency (I thought). Afterwards I can add logic to the channel selection etc.

 

Thanks a lot, really!

 

Steven

 

From: Chettimada, Vinayak
Sent: woensdag 16 december 2020 5:30
To: steven ghekiere
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

> I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

Refer to Bluetooth Specification V5.2, Vol 6, Part B, section 4.4.2.1 Advertising channel index selection:

 

Advertising events use three predefined primary advertising physical channels.

Primary advertising channel indices are either used or unused.

For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising

channel index used in the Channel Index subfield of the AuxPtr field is

implementation specific. It is recommended that sufficient channel diversity is

used to avoid collisions.

 

In the Zephyr BLE controller, advertising extensions is experimental, and the function that fills the advertising channel can be found here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/ll_sw/ull_adv_aux.c#L788

 

 

>Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.

 

Correct.

 

>Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

These bits decide the `advertising event` on the primary channels, to use channel 37, 38, and 39. The `small header` is repeated in these channels inside a standard `advertising event`, and that is what is selected by these bits.

For further details please refer to Bluetooth specifications.

 

-Vinayak

 

From: steven ghekiere <stevenghekiere@...>
Sent: 15 December 2020 20:51
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>; Marciano Preciado <marciano@...>
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

 

Hey Vinayak,

 

Thanks for the reply!

 

I had a quick look at the extended advertising links you mentioned.

 

I assumed the general GAP protocol does similar stuff (as you showed) but doubted that it could just set data on a set channel.

I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

(Wrote this as I was reading through your provided documentation)

As I understand, the ‘bt_le_adv_param parameter of the create method’ has a 32 bit options field (0-17 actually used?).

In these options we have:

  • Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.
  • Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

 

Thanks!

 

Steven

 

 

From: Chettimada, Vinayak
Sent: dinsdag 15 december 2020 20:17
To: stevenghekiere@...; Marciano Preciado
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hi,

 

If you are building a Bluetooth Low Energy application using Zephyr, then you should use the public APIs, not call internal subsystem functions unless you know what you are doing.

 

I think you are looking for the below mentioned options when calling bt_le_ext_adv_create (https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.bt_le_ext_adv_create)

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

 

These are for the primary advertising channels, auxiliary PDU channels selection is controller implementation specific.

 

If you are not using Bluetooth Low Energy stack, then you should refer to nRF52840 product specification for implementing your proprietary radio protocol.

 

>The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too

 

Contributions to improve the code, comments and add new features are always welcome.

 

Regards,

Vinayak

 

 

From: users@... <users@...> On Behalf Of steven ghekiere via lists.zephyrproject.org
Sent: 15 December 2020 19:48
To: Marciano Preciado <marciano@...>
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

 

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 

 

 


Re: Zephyr Low Level BLE Radio question

Chettimada, Vinayak Kariappa
 

> I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

There are no standard HCI interface to set application defined radio frequency, this will be against the Bluetooth specifications.

 

Refer to Bluetooth Specification V5.2, Vol 6, Part B, section 4.4.2.1 Advertising channel index selection:

 

Advertising events use three predefined primary advertising physical channels.

Primary advertising channel indices are either used or unused.

For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising

channel index used in the Channel Index subfield of the AuxPtr field is

implementation specific. It is recommended that sufficient channel diversity is

used to avoid collisions.

 

In the Zephyr BLE controller, advertising extensions is experimental, and the function that fills the advertising channel can be found here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/ll_sw/ull_adv_aux.c#L788

 

 

>Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.

 

Correct.

 

>Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

These bits decide the `advertising event` on the primary channels, to use channel 37, 38, and 39. The `small header` is repeated in these channels inside a standard `advertising event`, and that is what is selected by these bits.

For further details please refer to Bluetooth specifications.

 

-Vinayak

 

From: steven ghekiere <stevenghekiere@...>
Sent: 15 December 2020 20:51
To: Chettimada, Vinayak <vinayak.kariappa.chettimada@...>; Marciano Preciado <marciano@...>
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

 

Hey Vinayak,

 

Thanks for the reply!

 

I had a quick look at the extended advertising links you mentioned.

 

I assumed the general GAP protocol does similar stuff (as you showed) but doubted that it could just set data on a set channel.

I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

(Wrote this as I was reading through your provided documentation)

As I understand, the ‘bt_le_adv_param parameter of the create method’ has a 32 bit options field (0-17 actually used?).

In these options we have:

  • Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.
  • Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

 

Thanks!

 

Steven

 

 

From: Chettimada, Vinayak
Sent: dinsdag 15 december 2020 20:17
To: stevenghekiere@...; Marciano Preciado
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hi,

 

If you are building a Bluetooth Low Energy application using Zephyr, then you should use the public APIs, not call internal subsystem functions unless you know what you are doing.

 

I think you are looking for the below mentioned options when calling bt_le_ext_adv_create (https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.bt_le_ext_adv_create)

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

 

These are for the primary advertising channels, auxiliary PDU channels selection is controller implementation specific.

 

If you are not using Bluetooth Low Energy stack, then you should refer to nRF52840 product specification for implementing your proprietary radio protocol.

 

>The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too

 

Contributions to improve the code, comments and add new features are always welcome.

 

Regards,

Vinayak

 

 

From: users@... <users@...> On Behalf Of steven ghekiere via lists.zephyrproject.org
Sent: 15 December 2020 19:48
To: Marciano Preciado <marciano@...>
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

 

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 

 


Re: Zephyr Low Level BLE Radio question

steven ghekiere <stevenghekiere@...>
 

 

Hey Vinayak,

 

Thanks for the reply!

 

I had a quick look at the extended advertising links you mentioned.

 

I assumed the general GAP protocol does similar stuff (as you showed) but doubted that it could just set data on a set channel.

I still do not see any parameter where I can set my own frequency… This is the main part that I have been working on for a while now.

Does this mean I DO have to use the ll_sw files?

 

(Wrote this as I was reading through your provided documentation)

As I understand, the ‘bt_le_adv_param parameter of the create method’ has a 32 bit options field (0-17 actually used?).

In these options we have:

  • Bit 10 telling to make use of the extended advertising (which I assume are the 255 byte payload messages). It usually sends a smaller header packet first on the primary channels that points to the actual data packet.
  • Bit 15-17 disable the advertising on the normal advertising channels. Does this mean that the previous process behaves differently? Or just skip the first ‘small header’ part?

 

 

Thanks!

 

Steven

 

 

From: Chettimada, Vinayak
Sent: dinsdag 15 december 2020 20:17
To: stevenghekiere@...; Marciano Preciado
Cc: users@...
Subject: RE: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hi,

 

If you are building a Bluetooth Low Energy application using Zephyr, then you should use the public APIs, not call internal subsystem functions unless you know what you are doing.

 

I think you are looking for the below mentioned options when calling bt_le_ext_adv_create (https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.bt_le_ext_adv_create)

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

https://docs.zephyrproject.org/latest/reference/bluetooth/gap.html#c.@...

 

These are for the primary advertising channels, auxiliary PDU channels selection is controller implementation specific.

 

If you are not using Bluetooth Low Energy stack, then you should refer to nRF52840 product specification for implementing your proprietary radio protocol.

 

>The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too

 

Contributions to improve the code, comments and add new features are always welcome.

 

Regards,

Vinayak

 

 

From: users@... <users@...> On Behalf Of steven ghekiere via lists.zephyrproject.org
Sent: 15 December 2020 19:48
To: Marciano Preciado <marciano@...>
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Marciano,

 

Thanks for the quick reply!

I’d have to agree on the acronyms and such.

 

What do you mean that ‘somebody can help us’?

 

Thanks

 

Steven

 

 

 

From: Marciano Preciado
Sent: dinsdag 15 december 2020 19:15
To: stevenghekiere@...
Cc: users@...
Subject: Re: [Zephyr-users] Zephyr Low Level BLE Radio question

 

Hey Steven!

 

I’d have to agree! The low-level bluetooth controller is tragic. I’m sure it’s incredibly useful, but the use of nicknames and acronyms at every corner are not useful. Perhaps if there were comments that could help too, but there aren’t. 😭

 

I hope somebody can help us out.

 

Best,

Marciano Preciado
Embedded Systems Engineer
PassiveLogic Inc.
Mobile 801-800-1184

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

 

On Dec 15, 2020, at 7:11 AM, steven ghekiere via lists.zephyrproject.org <stevenghekiere=hotmail.com@...> wrote:

 

 

Hey there,

 

I’m a student working on a project using a Nordic nRF52840 device.

 

The past month or so I’ve been trying countless times to implement some BLE low level methods, first using Nordic SDK and now Zephyr.

More specific, I’d like to be able to set and receive the frequency to transmit data using the bigger 255 byte non-connectable broadcast beacons.

 

I asked about this on the Nordic SDK QA, which pointed me to use the newer low level BLE Zephyr API. (https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth/controller/ll_sw/nordic)

I got some advice in the #Bluetooth channel in the Zephyr Project Slack, who pointed me to use the “lll_chan_set()” method.

However documentation is lacking, to say the least. 

I’ve been struggling and doing this the trial-and-error way but I simply cannot make sure I send something correctly if I can’t receive anything.

 

Therefore, I would really really appreciate it for some clear guidelines, documentation, code snippets, or maybe even a chat on Slack with someone who knows how this works.

Since I’m working with deadlines I’m getting quite stressed and agitated so I REALLY would appreciate some help 😊.

 

Looking forward to your answer,

Steven Ghekiere

 

 

p.s: You can find me on the Zephyr Project Slack (email steven.ghekiere@..., name Steven Ghekiere). Feel free to respond there if this seems easier.

 

 

 

 

341 - 360 of 2727