decawave/mynewt-dw1000-core

[DEPRECATED] Use https://github.com/Decawave/uwb-core for new designs.

mynewt-dw1000-core's Issues

The split linker script wrong

In the hw/bsp/dwm1001/bsp.yml file:
bsp.part2linkerscript: "hw/bsp/dwm1001/split-nrf52-thingy.ld" --> split-nrf52.ld

If use the mynewt splitty, can't open split-nrf52-thingy.ld, it's may be split-nrf52.ld in this floder.
If this one is not right, can copy the mynewt-core/hw/bsp/nrf52dk/split-nrf52dk.ld file.

risk overflow associated with uint32_t type of repeat_dly

Hi,
in rtdoa_node.c line 365
risk overflow associated with uint32_t type of repeat_dly
Instead of
(repeat_dly << 16)(1.0l - wcs->skew)
Shouldn't it be sth like :
frame->rpt_count((uint64_t)rtdoa->config.tx_holdoff_dly<<16)*(1.0l - wcs->skew)
as further below when computing tx_timestamp (line 374)?

Decawave release date for Mynewt

Hi everyone,

Im using DWM1001-DEV with MyNewt OS. Some sample codes don’t work but some are working. When I looked at the decawave core bsp codes I thought it was not complete. am i right ? if im right, do u know a release date for core codes ?

Best Regards
Enes

Multiranging only mobile nodes/tags

Good evening,
I have have dwm1001 devices.
I want to build a system where each tag can measure it's relative distance with surrounding tags, and in some particular condition report this distance to a master anchor.
Obviously tags have to be discover this master anchor, because there are different master anchor in different room.
Thank you for your consideration and kindness

TWR complete_cb called before transmission

Hi,

I have noticed in the TWR libraries that the complete_cb callbacks are called before the transmission of the final message. As an example here is an extract of the code from the SS TWR library:

mynewt-dw1000-core/lib/twr_ss/src/twr_ss.c

Lines 322 to 339 in d6b1414

	uwb_set_delay_start(inst, final_tx_delay);
	if (uwb_start_tx(inst).start_tx_error){
	dpl_sem_release(&rng->sem);
	if (cbs!=NULL && cbs->start_tx_error_cb)
	cbs->start_tx_error_cb(inst, cbs);
	}
	else{
	STATS_INC(g_stat, complete);
	dpl_sem_release(&rng->sem);
	struct uwb_mac_interface * cbs = NULL;
	if(!(SLIST_EMPTY(&inst->interface_cbs))){
	SLIST_FOREACH(cbs, &inst->interface_cbs, next){
	if (cbs!=NULL && cbs->complete_cb)
	if(cbs->complete_cb(inst, cbs)) continue;
	}
	}
	}

This can lead to ranging issues when operating the transceiver (putting it to sleep for example) straight after the completion callback.

For cases where the ranging ends with a transmission, I suggest to call the complete_cb callbacks on tx_complete_cb. Going back to the code above I replaced the code inside the else with a line that sets a global variable: g_wait_for_tx = true;. Also I have implemented the tx_complete_cb callback:

static bool
tx_complete_cb(struct uwb_dev * inst, struct uwb_mac_interface * cbs)
{
    if (!g_wait_for_tx) return false;
    g_wait_for_tx = false;

    struct uwb_rng_instance * rng = (struct uwb_rng_instance *)cbs->inst_ptr;
    STATS_INC(g_stat, complete);
    dpl_sem_release(&rng->sem);
    {
        struct uwb_mac_interface * cbs = NULL;
        if(!(SLIST_EMPTY(&inst->interface_cbs))){
            SLIST_FOREACH(cbs, &inst->interface_cbs, next){
            if (cbs!=NULL && cbs->complete_cb)
                if(cbs->complete_cb(inst, cbs)) continue;
            }
        }
    }
    return true;
}

The issue is that the tx_complete_cb in uwb_rng.c gets called first and prevents any following callback to be called:

mynewt-dw1000-core/lib/uwb_rng/src/uwb_rng.c

Lines 838 to 858 in d6b1414

	static bool
	tx_complete_cb(struct uwb_dev * inst, struct uwb_mac_interface * cbs)
	{
	if (inst->fctrl != FCNTL_IEEE_RANGE_16)
	return false;
	struct uwb_rng_instance * rng = (struct uwb_rng_instance *)cbs->inst_ptr;
	if(dpl_sem_get_count(&rng->sem) == 1) {
	// unsolicited inbound
	return false;
	}
	switch(rng->code) {
	case DWT_SS_TWR ... DWT_DS_TWR_EXT_END:
	RNG_STATS_INC(tx_complete);
	return true;
	break;
	default:
	return false;
	}
	}

A workaround in this case is to change line 853 and to return false in order to allow following tx_complete_cb callbacks to be called.

The solution now works but I have only handled SS TWR. I am sure a more generic solution can be developed.

Does anyone have any thoughts on this?

Thanks

read/write from/to sub-address 128?

Unless I am mistaken, some read and write operations might fail if sub-address is 128.

The following code (or similar) appears on multiple places:

    dw1000_cmd_t cmd = {
        .reg = reg,
        .subindex = subaddress != 0,
        .operation = 0, //Read or write
        .extended = subaddress > 128,
        .subaddress = subaddress
    };

    uint8_t header[] = {
        [0] = cmd.operation << 7 | cmd.subindex << 6 | cmd.reg,
        [1] = cmd.extended << 7 | (uint8_t) (subaddress),
        [2] = (uint8_t) (subaddress >> 7)
    };

    uint8_t len = cmd.subaddress?(cmd.extended?3:2):1;

if sub-address is 128 the extended bit is (accidentally?) set correctly due to
high value an no bit mask, but only the two first header bytes are sent.
eg. header sent is [0xNN, 0x80] instead of [0xNN, 0x80, 0x01].

About the skew calculation in rng.c

In rng.c there are two ways to calculate the skew (https://github.com/Decawave/mynewt-dw1000-core/blob/master/lib/rng/src/rng.c#L648-L653) , if WCS is enabled then skew calculation is based on prediction from timescale lib, otherwise it's based on instantaneous register value. Is the timescale one more accurate than the register one?

Auto-FCS Transmission is not handled

The function dw1000_write_tx does not handle auto-FCS transmission. In the current implementation TX frame length does not include the length of the CRC from auto-FCS transmission. I suppose the use case of suppressing auto-FCS transmission is not common so the quickest fix would be to add the length of the CRC from auto-FCS transmission (2 bytes) as in dw1000_write_tx_fctrl. If handling Auto-FCS Transmission suppression really has an application a check of the SFCST field from the System Control Register is required.

Support for DWM1001's LIS2DH12 IMU

I'm using the DWM1001 RTDOA example. Is there any way to enable support for the LIS2DH12 accelerometer? I see that in the syscfg.yml for the RTDOA example, there are parameters LSM6DSL_ONB, LIS2MDL_OSB, and LPS22HB_ONB, but unfortunately not for DWM1001's onboard LIS2DH12.

Looking through the code, I see that IMU data is periodically printed out. Is the IMU data used at all in the RTDOA solution, or is it just informational? If it isn't needed by the RTDOA algorithm, then I won't be concerned so much.

Error while building Mynewt apps based examples

Greetings
I went through getting started and tutorial guide of Mynewt.
I was successfully able to build the blinky example.
But while building Decawave apps as given on the website: https://github.com/Decawave/mynewt-dw1000-apps

I get the following error.

Building target targets/dwm1001_boot1
Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
Error: repos/apache-mynewt-core/boot/bootutil/src/image_ec.c:24:15: error: missing binary operator before token “(”
#if MYNEWT_VAL(BOOTUTIL_SIGN_EC)
^
image_ec.o: repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
os/mynewt.h

Kindly help me out to solve this issue

Thanks & regards
Asmita

BSP support for TREK1000

Hi!

When trying to compile the included ttk1000 bsp example I get errors about not finding the dpl libraries. Seems like the bsp example is incomplete. Has this example ever been successfully compiled and if not how do I add the dpl library to the bsp?

I've also asked the same question on the decawave forums with more info:
https://decaforum.decawave.com/t/mynewt-library-compilation-on-trek1000-hardware/6773

A few questions

Hi,
I have the following questions.

1. When do you plan to do release 2 for PANS library?
2. If we use this core, can we send custom messages through UWB?
3. I intend to use IMU with a tag. It seems that you already have that in the plan. Any release dates for that?

Duplicate HAL in porting

Hi,

I have noticed under porting that dpl_hal is duplicated in dpl_os. Is there a reason for this?

Thanks