AWR1843BOOST: AWR1843 frequency drift

Hello Aleksa,

Our expert will look into your concern and get back to you in 2 days time.

Thankyou for your patience.

Regards,

Ishita

Could you measure the frequency signal using some other mechanism instead of another radar device (may be oscilloscope) ?

There is multiple variables here in your current experiment.

And can you list down the API which you use to achieve continuous mode (CW)?

rlSetContModeConfig is the API to set CW mode.,

Seems like there is a call to rlSetContModeConfig in there because I set dfeDataOutputMode to Continuous mode. It's part of the SDK, so I didn't mess too much with it.

I haven't changed anything related to the front end initialization starting from the high-accuracy lab, I just set 0 as chirp slope in the profileCfg command.  

Continuous chirping mode is not supported by the mmw demo application.

Please see mmWave SDK user guide

Regards,

Jitendra

Sorry Jitendra my bad,

I set dfeDataOutputMode to 1, so it's frame-based chirps. 

Hi Aleksa,

For CW mode, best to use mMWave Studio. User guide of this tool explains the steps to configure the device in continuous mode.

Please try to use this tool for your experiment.

Regards,

Jitendra

Hi Jitendra,

I am not sure if I was clear enough. My goal is to figure out what could be the cause of frequency drift. Up to this point, I have concluded that reset of a sensor induces drift, and it seems like a bad power supply affects it also(or non-full battery when I use a battery as a power supply). Now I'd like to know if there are any other known issues that could be the cause of it? 

I have a sensor working in CW, and I have run tests for a couple of hours where these frequencies would stay really stable. But sometimes, they seem to glitch. And they always make a drift at the startup of about 200kHz (which is a rather small value compared to the 80GHz), but I want to make these frequencies as stable as possible. 

Cheers,

Aleksa

Hello Aleksa,

This drift in frequency is because to temperature change as the device operates (current consumption causes heating). The 40Mhz crystals have a frequency shift due to temperature change. A 1 Mhz shift at 80Ghz is 12 ppm, so that is easily possible by the heating.

If the same device transmitter and receiver is used then this does not matter, since the same drift happens on both Tx and Rx. When you use separate devices for Tx and Rx then the drifts could be different, causing the issue you are seeing. To avoid it you can sync the two devices with the same 40Mhz reference clock by feeding external clock on the CLKP pin.

Regards,
vivek

Hello Vivek,

The temperature was my first guess too. So I have logged and plotted temperature on both of the sensors and didn't notice any significant drift due to it. Although the API for temperature reading from rl_sensor.h seems to update the value only on the sensor startup? I've kind of sorted this with the introduction of a software reset and a autostart after the software reset of the sensor(it was a requirement for the project anyway). 

But as you say, it makes the most sense that temperature is the reason behind this drift.

Anyway, I think this can be closed, if you guys don't have some other ideas about what I should check.

Cheers,

Aleksa