• State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 75 subscribers
  • Views 1865 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 277578
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to use upstream zephyrproject-rtos/zephyr instead of nrf-zephyr fork

jakkra

Hi I need the upstream Zephyr project for direction finding functionality and bug fixes. Those are not present in nrf-zephyr fork.

How do I get that to work? Just replacing nrf-zephyr with upstream zephyr does not build (Target "partition_manager" not found etc...).

I have searched around both nRFConnect and Zephyr documentation for how to set up the environment but cannot find something that works.

I found this https://devzone.nordicsemi.com/f/nordic-q-a/77257/relationship-sdk-zephyr-and-zephyhrproject-zephyr/319141#319141 where you suggest cherry-picking, but that's not going to work as it's so many commits spread out and I don't see that solution scale.

I can see lot's of development in Zephyr project main branch from nordic developers, what is their environment and how can I set up the same environment? 

Thank you alot,

Jakob

Parents
  • 0

    Hi Jakob,

    I'll try to help you, but I wanted to start from asking some questions.

    1. Are the bugs you have mentioned related with direction finding?

    2. Did you find any bugs in DF code?

    3. Are you interested in DF connectionless mode?

    4. What is current version of NCS-SKD you are using currently?

    BR,

    Piotr

  • 0 in reply to Piotr

    Hi, thanks for taking the time.

    1. Yes related to DF. Bugs and missing features are the main reason I want to develop and use upstream master.

    2. Yes two:
    Setting max_cte_count to 0 in bt_df_per_adv_sync_cte_rx_param does not work as it will cause this if  https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_sync.c#L671 to never execute. According to documentation setting max_cte_count to 0 means sample continiously 
    And the second one is that 1US slots did not work as DF_AOA_RX_1US_SUPPORT(X) was incorrectly implemented (however I saw that is fixed on master)
    Those are not a problem and I fixed them locally easily.
    However there are features on master branch I'd like to use, such as sending AUX_SYNC_IND. For example the 
    bt_df_adv_cte_tx_param -> cte_count is not working on 1.7.0, I'm expecting it to send cte_count times AUX_SYNC_IND in each periodic adv. event. And looking in master code this seems to be implemented now.
    Also I have some random crashes that I have not digged to deep into, but wanted to see if they where gone using latest code.
    3. Connectionless using periodic advertisements yes.
    4. I'm using master branch of https://github.com/nrfconnect/sdk-zephyr (west init -m https://github.com/nrfconnect/sdk-nrf --mr master) and before that SDK 1.7.0.
    Other things I found while migrating from baremetal DF (most are due to BT SIG HCI interface definition that I don't like, but it is what it is) is that you are limiting the antenna switching pattern to be dependant on the number of pins, I don't see spec. setting this limit, I think it's valid that you have patterns that don't only contain unique antennas. Let's say you have 10 antennas (4 gpios), then you cannot do a switch pattern auch as antennas 1,2,3,4,5,1,2,3,4,5,6,7,8,9,10,6,7,8,9,10 but instead need to make use of wraparound of switch pattern so you get (1,2,3,4,5,6,7,8,9,10) x 2. Because max ant_len is set by how many antennas theoretically you can have with 4 gpios. Sure you can re-organise IQs etc, but still. It's trivial to make that change myself, but I'd like to do as little modifications to Zephyr as I can to simplify when upgrading SDK version.
    Thank you,
    Jakob
  • +1 in reply to jakkra

    Hi Jakob,

    Thank you for answering for questions. Now I've got better view on the situations.

    1. Referring to Zephyr.

    Use of upstream Zephyr within nRF SDK would be complicated, as you have already spotted. Recent version of sdk-zephyr in NCS playground hasn't got number of commits related with DF. Unfortunately cherry-picking of all changes done from last downmerge from upstream would be a bit time consuming. There are two options I can propose:

    - wait for next NCS release, then you will most of the stuff done for connectionless DF there. 

    - switch temporarily from NCS environment to Zephyr only environment, but then you may miss some features that are provided by NCS and in regards of support you are depending on community.

    2. About bugs:

    - max_cte_count issue, I've created a PR for that: https://github.com/zephyrproject-rtos/zephyr/pull/39214. Thank you for reporting the issue.

    - antenna switchng pattern, it is limited to 12 (by default) but can be changes. Please take a look on thic Kconfig option: BT_CTLR_DF_MAX_ANT_SW_PATTERN_LEN. nRF SOC support antenna switch pattern length up to 39. Values that are used for antenna switching are dependent on the GPIOs count. To get more information about it please look here: https://github.com/nrfconnect/sdk-nrf/blob/master/samples/bluetooth/direction_finding_connectionless_rx/README.rst#id44.

    BR,

    Piotr

  • 0 in reply to Piotr

    Hi and thank you. For now I'll try to strip away parts that depend on NCS from the application and develop using Zephyr environment until next NCS release.

    Do you have any estimate/idea when next NCS release is that includes the connectionless DF functionality mentioned?

    Jakob

  • 0 in reply to jakkra

    Hello,

    I have no information about timeline for NCS release.

    BR,

    Piotr

  • 0 in reply to Piotr

    Ok thank you a lot for the help. Will resolve the ticket.

Reply Children
No Data
Related
Terms of service