雷达知识四之应用案例—体征检测(2)
在百度上搜索,同样出来一堆的内容!于是经过一周的学习总结,总算有些眉目了!
哪些内容有借鉴价值呢?首先需要大量阅读,其次就需要火眼金睛。如果肚子里没货,那么肯定分辨不出来!网上很多文章确实也只是一知半解!如果遇到好文章,那就要仔细的学习。
阅读多篇比较后,发现此篇文章的借鉴意义最大,让我们一起深入分析。
项目的测试平台!
IWR6843ISKEVM+DCA1000EVM!
DAC1000仅从雷达经LVDS接口获取信号后转发给电脑,核心就是IWR6843!
毫米波雷达!
雷达配置:一帧2个chirp,一帧50ms,ADC采样点为200个,采样率为4Msps,数据处理时仅采用每帧的第一个chirp。(详看下图的参数)疑问:采样率为4Msps,200个点时长为50微秒啊!需要看雷达给出的chirp指标!后来才知道一帧确实是50ms,一帧里面可以设置好多个chirp,这里只设置2个chirp。ADC采样点为200个是指每个chirp的采样点数200。调频斜率:S=64.985MHz/us(~65e17) 有效带宽B=ts*S=3.24925GHz≈3.25GHZ 2024年7月,项目组遇到的问题是,DSP的函数无法 正确解析出信号中的呼吸率和心率。计算机用MATLAB软件可以正确的计算出心率和呼吸率,但是算法又极其的复杂,无法在DSP中实现。那么如何能够使得这款DSP里面有可用的程序就成了当务之急,这个问题是成为产品路途中的拦路虎。项目中之所以选择此款平台,我想肯定对开发板中的 DSP 的适用性进行过调研。早期选择开放平台肯定需要论证,本人没有参与。但项目组肯定是有充足的理由来支持这样的选型。一般项目选择硬件平台可以从以下几个方面入手:- 明确您的应用目标和任务,例如是进行信号处理、图像处理、数据分析还是其他类型的任务。
- 确定任务所需的计算性能,例如每秒需要处理的数据量、处理速度要求、精度要求等。
- 运算能力:查看 DSP 的时钟频率、指令集架构、数据处理宽度等,以了解其基本的运算能力。例如,检查是否能够快速执行乘法、加法、逻辑运算等基本操作。
- 内存容量和带宽:评估 DSP 内部的内存大小以及与外部存储器的数据传输带宽,确保能够满足数据存储和访问的需求。
- 中断响应和处理能力:如果应用需要实时响应外部事件和中断,检查 DSP 的中断处理机制和响应时间。
- 开发环境:了解是否有易于使用的开发工具,如编译器、调试器、仿真器等,以及它们对 DSP 的支持程度。
- 库和函数资源:查看是否有可用的库函数和函数库,以加速开发过程,例如数字信号处理库、图像处理库等。
- 技术文档和社区支持:丰富的技术文档和活跃的开发者社区可以在开发过程中提供很大的帮助。
- 成本因素:考虑基于该平台的开发成本,包括硬件成本、开发工具成本等。
- 功耗要求:如果应用对功耗有限制,评估 DSP 在运行时的功耗水平是否符合要求。
- 检查您现有的软件代码或算法是否能够轻松移植到 DSP 平台上,或者是否需要进行大量的修改和优化。
- 进行一些基本的测试用例,如简单的信号处理算法、数据处理任务等,以实际测量 DSP 的性能和功能。
- 与其他类似的 DSP 平台进行对比测试,了解其在相同任务下的性能表现。
如果您的应用是对毫米波雷达数据进行实时处理和分析,那么首先要确定数据处理的速度要求(如每秒处理多少帧雷达数据)和精度要求(如距离测量精度、角度测量精度等)。然后,查看平台中 DSP 的时钟频率、指令周期、内存大小和带宽等性能指标,判断是否能够满足数据处理速度和存储需求,也就是要细看下面这个性能配置图。接着,评估开发工具如 CCS(Code Composer Studio)对该型号 DSP 的支持情况,以及是否有相关的毫米波雷达数据处理库可供使用。同时,考虑成本因素,包括硬件采购成本和开发工具的授权费用等。最后通过实际编写一些简单的雷达数据处理代码,在开发板上运行和测试,查看实际的处理效果和性能表现。先对网上的这篇好文进行程序验证吧!本文是边写边测试边直播,也极具价值!