AWR1843BOOST: Mutiple AWR Sensor Devices at the same time (preferably on same computer, if possible)

Hi,

Could you please provide more details?

There are usually two use cases:

       1) Collect raw data from multiple sensors and send it to a host

       2) Process the raw data on the sensor and then send the object data to a host

Which use case are you trying to implement?

Thank you

Cesar

Cesar,

Thanks for the quick response!  I apologize for the delay on my end but I wanted to look into a few things before responding to make sure I answer the question adequately. 

I'm currently trying to fill in the knowledge gaps so I have a few different milestones I'm hoping to achieve before creating a custom GUI/interface/HW solution.  My current goal is to sync up two sensors in realtime using an external trigger and, ideally see them on the same host (which is currently a PC).     

When I originally posted this, I assumed my main issue was going to be with dual devices but it looks like for our application, there are two different issues in place.  I've run into solutions for some of these goals individually but not all of them in a single solution (which is understandable).  Below are the two major issues

1) Dual board support

We currently have two AWR1843 boards and two DCA1000 boards.  It looks like it might be possible to run two separate instances of the automotive toolbox labs/GUIs on the same computer, which would allow us to see the realtime data of two different boards at the same time (I only have the first board onhand currently, waiting for the second to arrive.  Needed to confirm the first board would do what I needed it to do before ordering another).  It looks like this could provide us with a path forward for this portion. 

2)  External Trigger w/ realtime data visualization

It appears this is going to be the bigger problem for us. Below are some of the things I've tried:

mmWave Studio - (AWR1843/DCA1000, external trigger, not realtime data, single instance)

So far, I've used the mmWave Studio application to setup an external trigger, which was surprisingly easy to do once I got familiar with the tools (great job on the documentation and the development tools, they've been really helpful!).  The problem is that it will record data but will not allow me to look at it in realtime. 

Automotive toolbox examples/gui (AWR1843, realtime, SW trigger, multiple instances)

I've been able to get the automotive toolbox labs/GUIs to run in realtime on the board, but they don't seem to allow for use with an external trigger (not entirely sure how they're being triggered, to be honest.  I assume it's with a software command.  While the DCA1000 still comes in from a trigger signal, I'm not sure how these are (I'm having trouble issuing commands and scoping out the lines, going to need to get a second set of hands to help me with this one . . . heh).

I'm still hoping I can get a solution that meets all our requirements but  I don't think a tool exists to meet ALL of them (and that's understandable as it's a fairly niche requirement and we can always develop another application/HW approach to do everything down the road).  I think I can handle having two laptops hooked up side by side, if needed (if a tool doesn't already exist for dual board support) but I'm really, really hoping there's a path forward to being able to support some sort of realtime data viewing using an external trigger. 

If you have any suggestions, please let me know.  Thanks!

Hi,

Here are some answers:

Connecting two DCA1000 Boards to Same PC

The topic of connecting several DCA1000 boards to the same PC has been addressed in several times on the forum in the past.

Unfortunately it is not possible to connect several DCA1000 to the same PC.

Connecting two different AWR1843 EVMs to the same PC

This should not be a problem, two different COM ports can be open in the GUI application running on PC

Automotive Toolbox Demos Hardware Trigger

Currently all the Automotive Toolbox Demos use a SW trigger. This feature is controlled by one bit in the frameCfg. So it is easy to change the value of this bit in the frameCfg.

Automotive Toolbox Demos : How do Demos Start

In the Automotive Toolbox, the demos are configured/started in two ways.

                              1) Some demos are started in the same way as the mmWave SDK OOB demo. They have a profile.cfg that is sent to the demo from the PC GUI through the UART. The profile.cfg format is the same as for the OOB demo and is described in the mmWave SDK User's Guide provided here C:\ti\mmwave_sdk_03_05_00_04\docs\mmwave_sdk_user_guide.pdf (see "3. 4. Configuration (.cfg) File Format"). For these demos you will need to modify the frameCfg to use Hardware Trigger. It is important to notice that the mmWave SDK UG mentions that hardware trigger is not supported. I think this means that the demo was not tested with hw trigger. It does not mean that the sw configuration does not work. Let me check and get back to you.

                              2) Other demos have cfg parameters hard-coded in the application and the demo starts at boot time. For these demos one needs to identify where the trigger bit is initialized in frameCfg and change the initialization to "HW trigger"

Thank you

Cesar

Cesar,

Thanks for your help with looking into this!  I was able to find the frame information for the SW/HW in a file called cfg.c in the medium range radar in the common folder of source.  It looks easy enough to toggle.  Unfortunately, I'm not entirely sure how to compile this project (I've mainly been working with the prebuilt binary and haven't quite figured out how to open this with code composer though (I assume that's what is used to compile this, but I could be wrong).  What's the best way to open and compile this program?

I realize that if it's not setup in some of the other files, this might still not work but hopefully, it's as easy as changing that bit and recompiling!  Let me know if you find out if it's supported!

Hopefully, I can find one of these demos that can support the range profile like in the OOB demo!  At first glance, it appears if the medium range radar doesn't support this (I'll have to take a look at the other demos). 

One last question, are any of these labs able to be ran using the Demo Visualizer App or is there another firmware that should be loaded to work with the demo visualizer?  Not sure if it's a general purpose GUI or if there's a specific firmware that should be loaded onto it (which seems to be what is suggested from what I read)?

Thanks for all your help!

Hi,

No, there is not another demo that supports the range profile. The MRR code supports this in the code. It just has to be enabled in the matlab GUI. You would need  a matlab license to develop with matlab. I think I can provide you with a short sample code that performs that.

The Demo Visualizer only works with the mmWave SDK OOB demo. Most of the other demos use matlab GUIs.

I think your meaning for "firmware" is what I call "demo"

thank you

Cesar

I just want to make I understand and am on the same page as you.  I assume all the visualizers/GUIs are Matlab programs that I would need Matlab to edit (which I can get my hands on if I need to so I can update the GUI as necessary), if I follow what you're saying. 

The "demo" you're referring to I'm assuming is the firmware we're updating (made up of the MSS and DSS files, which are uploaded via mmWave studio).  I assume the demo/prebuilt binaries are created from source files in code composer which configures the MSS and DSS sections of the code?

If I'm wrong on any of the above, please let me know as that would cause some fundamental understanding issues on my end!  Heh . . .

So, assuming all the above is correct, my understanding is that the Demo Visualizer is a GUI made in matlab, that seems to have all the information I need (including the range profile).  It's currently setup using SW requests and the device is collecting the radar data, sending the raw data to the computer via a UART (over the USB connection) and the GUI processes the data and updates the display in realtime, essentially. 

So if I want it to work with the GUI, I need to have the correct firmware on it to work with the visualizer and I need to update the code so it's using HW triggers instead of SW triggers (not sure if I'd need them to be setup at the same interval as the SW requests to ensure there are no timeouts, but maybe that's not necessary).  I assume the same GUI code would work if it's getting the info from the radar via the UART, as long as the HW trigger is set and received by the radar correctly. 

If all the above is correct, I believe I need to update the firmware/binary/demo code to accept HW triggers.  I went ahead and used uniflash to program the "xwr18xx_mmw_demo.bin" file from the mmwave sdk V3.5, set the appropriate SOP jumpers, and have it running with the data visualizer.  Everything seems to be working, so that's good. 

From looking at other profile.cfg files from different labs (like the MRR lab), it looks like the SW trigger value is 1 in the advCFG section.  According to page 84 of the mmWave radar interface guide, it looks like I need to set this value to 2 for HW triggering.  When I'm looking at the settings of the demo visualizer, it shows" adcCfg 2 1".  I assume the 1 is referring to SW triggering. 

So, with all this information (in combination with your previous posts), what is the best way to get access to HW triggering with realtime data (particularly with the range profile)?  If there's a way to setup the demo visualizer (maybe to update the code that can be downloaded) so it can be used with HW triggering, it seems like that might be one way (assuming the demo binary is setup to utilize HW triggering), that might be an easy approach.  Alternatively, you had suggested you might be able to provide code for a simple GUI that might be able to be used to see HW triggered data in realtime (not sure what firmware/preconfigured binary/demo we would need to run of if all the them might support HW triggering). 

Any information you can give me would be greatly appreciated!  I think it looks like we might have a few potential paths but I assume you probably know the quickest approach for this.  Thanks for all your help and patience!  Sorry for the delayed response, I wanted to take enough time to look over what you've written and make sure I understand. 

Have a good night!

"I just want to make I understand and am on the same page as you.  I assume all the visualizers/GUIs are Matlab programs that I would need Matlab to edit (which I can get my hands on if I need to so I can update the GUI as necessary), if I follow what you're saying."

[Answer]

Yes, most of the GUIs we provide for the demos available on the mmWave Software TI Resource Explorer are implemented in Matlab. You would need a Matlab license to modify them

"The "demo" you're referring to I'm assuming is the firmware we're updating (made up of the MSS and DSS files, which are uploaded via mmWave studio).  I assume the demo/prebuilt binaries are created from source files in code composer which configures the MSS and DSS sections of the code?"

[Answer]

The demo code is built as binaries which are flashed on the on board flash memory. It is not uploaded with mmWave Studio. The firmware uploaded with mmWave Studio is RF firmware used to configure the device. Usually when we use mmWave Studio we don't run demo code on the sensor, we only configure the RF parameters of the sensor.

"So, assuming all the above is correct, my understanding is that the Demo Visualizer is a GUI made in matlab, that seems to have all the information I need (including the range profile).  It's currently setup using SW requests and the device is collecting the radar data, sending the raw data to the computer via a UART (over the USB connection) and the GUI processes the data and updates the display in realtime, essentially."

[Answer]

This understanding is not correct.

First thing that is not correct: As I mentioned previously the MRR GUI that is released does not support the range profile.

I can provide you a matlab code snippet that shows you how to implement this feature in the MRR matlab GUI. You would need to make these updates.

Second thing that is not correct: The radar sensor does not send the raw data through UART. The data is processed on the board and only processed data is sent to the host through UART. What type of processed data is sent through UART depends on the demo. Some demos only send the detected points, other demos send also heatmaps, other demos send also the range profile. The host PC only displays the data, does not process it.

"So, with all this information (in combination with your previous posts), what is the best way to get access to HW triggering with realtime data (particularly with the range profile)?  If there's a way to setup the demo visualizer (maybe to update the code that can be downloaded) so it can be used with HW triggering, it seems like that might be one way (assuming the demo binary is setup to utilize HW triggering), that might be an easy approach.  Alternatively, you had suggested you might be able to provide code for a simple GUI that might be able to be used to see HW triggered data in realtime (not sure what firmware/preconfigured binary/demo we would need to run of if all the them might support HW triggering). "

I think that first thing you need to do is decide which demo you want to use for your experiments.

My previous understanding was that you want to use the MRR demo. Is this correct?

Thank you

Cesar

Ok, I think all the pieces are coming together now!  So when we're writing the binaries, that's just the configurations that's effectively informing the firmware how to setup the RF parameters rather than updating the firmware itself (which allows all the functionality to be configured for different applications).  Effectively, it's setting up the triggers, the data being taken and processed, and the frame format of the output (which is why the GUI's would need to be configured differently based on the config of the sensor as the output format would be changing). 

I think I understand a bit better as the GUI itself is not setup to display the data as the MRR setup isn't actually setup to process the data for the range profile (and as such, wouldn't make sense for it to be implemented into the GUI).  So ideally, I would need to be able to flash an updated prebuilt binary with the HW trigger enabled, as well as edit the Matlab GUI code to be able to decode the newly processed data (that would include the range profile, for instance). 

You are correct that the MRR project is the one I would ideally like to use, if possible.  It does look like the source code is provided and it does appear that the common folder has a cfg.c file that has the frame setup information in it.  There's a line in the Cfg_AdvFrameCfgInitParams() function that is currently setup as a SW trigger:

ptrAdvFrameCfg->frameSeq.triggerSelect = 1;//SW Trigger

According to the radar interface control guide, it looks like I should be able to set this value to 2 and it would be setup for a HW trigger (which I've been able to test using mmWave Studio and an external pulse generator).  Admittedly, I haven't spent enough looking at the rest of it so I'll likely need to identify what parameters to change for it to process the the range profile information.  I'll also need to find out where in the documentation it discusses the frame format as well (likely in the radar interface control guide as well, it seems to outline just about everything else).  Realistically, any Matlab snippets you provide will probably help me understand that point as well. 

Overall, assuming my statements above are correct, this makes a bit more sense and I think I have a good path on how to be able to make some progress with this. 

I do have a few additional questions though:

1) Is the firmware intended to be largely controlled by TI so that most changes that are to be made are done via flash configuration rather than alterations to the firmware (so, from a customer standpoint, it works more like an ASIC than a microcontroller)?  I assume that's the intention (especially considering the potential complexity of the firmware). 

2) Is there a way to debug the firmware or open the project with an IDE like Code Composer to easier step through how the code is structured? I've been able to open the code in Code Composer and use some of the basic IDE functions, so that helps.  Not sure if it makes sense to try and compile the code and step through it, if I'd need a debugger, etc, or if the best way to work with making configuration changes it to just look at the scope output. 

3) If I made changes to the cfg.c file to change the HW trigger setting as well as any changes to take data for the range profile, how would I create an updated binary to burn to the device? 

Anyway, this is probably enough for now.  Thanks for your time and patience, Cesar!  I really appreciate it!

I think you are 100% right!  I can't believe I missed this document, I thought I had read everything int he MRR folder but I clearly missed this.  I've even been in this folder to learn how to flash binaries but somehow missed that developer guide . . . really sorry about that!  This guide looks very well written and that combined with the information you've provided me should be enough to jump in. 

Thank you so much for all the information you shared, definitely helps me see how everything fits together!  I might still have some questions when I get deeper but I think you've given me more than enough to get started.  Thanks again!

Cesar,

Thanks for all your help and patience explaining everything!  Looking back on some of my questions (having had a chance to dig a lot deeper, I see how silly some of these questions were . . . that said, your explanations helped a lot when seeing the big picture initially!

I got a chance to work with the matlab gui's, the data visualizer (which is obviously a very different approach code wise), and the code composer firmware.  Still putting all the pieces together but I think being able to dig deeper into the debugging will help a lot. 

I did come up with a number of other questions based on things I ran into.  I'll try and break them down into sections:

Debugging

1) I was trying to take a look at some of the data before it gets sent to the UART (I understand how it's been received and handled on Matlab's end but I was hoping to backtrack through the code so I understand the whole signal chain). Unfortunately, I couldn't get the GUI to receive any data when i was in debugging mode.  Is this because the Aux Data Port is being used by the debugger?  If that's the case, I assume it won't get a SW trigger from the software and that's why it's not updating.  Does this mean using a HW trigger would be best in order to trigger the interrupt?  Or am I unable to look at this while SW debugging and need to burn the xwr demo firmware in order for this functionality to work? 

2) When I'm stepping through the code, the code seems to skip around while I'm stepping through it.  For instance, if I'm stepping through the MmwDemo_populateMRR function in dss_main.c, stepping through may go from line to 1491 to 1492 to 1487, for instance.  Is this normal or is this potentially a result of optimization settings?

Project Specific Questions (MRR lab 7)

3) For my application (MRR HW triggering and range profile), is there a preference between lab 7 and lab 11?  I came across a thread that says lab 7 uses the HWA for the 1d and 2d processing while lab 11 uses DSP for both.  For my application, is there one I should use over the other or would they both work the same?

4)  I assume the labs aren't currently setup to change the CFAR thresholds like they are in the data visualizer section, is this correct?  I found the following lines that look like it's hardcoded (which is fine) but I thought I'd ask if there's a way to dynamically change this currently in place (I don't believe there is but I thought I'd ask all the same).  It's not a huge deal, changing a value in a *.h file is a pretty easy change to make. 

5)  There is a common folder with several documents including a cfg.c file with a lot of configuration data (as well as the different chirp design profiles).  If I change the rf configuration (as mentioned in the developer guide), do I need to change it in both folders or would the mss common folder be the dominant library since that's compiled second (as recommended by the guide)?  If they are completely independent and I need to change them both, would I want the HW trigger to be in the mss or dss folder (or both)?

Additional support request

6)  Is the offer to make a small matlab program to read the range profile information still on the table?  You had mentioned the labs support this functionality so you should just need some matlab code to interpret it.    I tried to go through the data visualizer to see how it's done there and was able to look through the code but the structure is so different (and the demo visualizer gui doesn't appear to have the source code).  If so, this would be a huge help (and would also help me fill in some of the additional knowledge gaps along with the questions above).

Thank you so much for all your help, Cesar, I really do appreciate it!