[参考译文] IWR6843ISK：我是否可以使用命令行提示符而不是点击&quot；record data&quot；来触发毫米波演示可视化工具？

尊敬的 Nate：

感谢您的提示。

我在工业可视化工具中找到了以下使用指南： https://dev.ti.com/tirex/explore/content/radar_toolbox_1_30_01_03/tools/visualizers/Industrial_Visualizer /docs/mm Wave_Industrial_Visualizer_User_Guide

一切都在 Python 中、这很棒。

据我所知、我所描述的捕获方法开箱即用、我需要更改工业 Viisualizer 的源代码才能实现此目的。 我的理解是否正确？

此外、工业可视化工具是否以与我一直使用的毫米波演示可视化工具相同的格式保存采集的数据？ 我是否还需要为此创建一个文件转换器以确保我现有的后处理管道能够继续工作？

感谢你的帮助。

此致、
Cagri

尊敬的 Nate：

我开始探索工业可视化工具、这看起来很有前景。 我注意到的一点是、文件以 json 格式而不是 bin 格式保存。

是否保存了有关 json 文件格式的文档？ 有一些字段是不言自明的,而其他字段不是那么清楚。

此致、

Cagri

您好、

在对工业可视化工具提供的*。bin 文件进行解码后、我有一个关于帧周期的后续问题。

解码 TLV 数据包时、我使用 timeCpuCycles_U32 和~1.67ns 的 DSP 时钟周期来计算 BIN 文件中每帧的捕获时间。 此计算得出的捕获周期为~33 毫秒、约为每秒 30 帧。 根据我的观察、对于每个捕获的数据包、这个周期在整个 bin 文件中是非常一致的。

问题是在开始捕获之前、我提供了一个配置文件、该文件指定帧周期（以 ms 为单位）为 100（作为 frameCfg 配置命令的一部分）。我附上了用于供您参考的配置文件。 因此、我希望能在 bin 文件中看到每 100 毫秒（而不是我看到的 33 毫秒）捕获一次每帧。

我在这里遗漏了什么吗？ 目前、我的配置文件中的帧周期似乎没有任何影响。

感谢你的帮助。

此致、

Cagri

e2e.ti.com/.../MMFi_5F00_xwr68xx_5F00_radar_5F00_base_5F00_config_5F00_07_2D00_04_2D00_2025.cfg

您好、

您能否在 UART 线路上使用逻辑分析仪进行检查、以确认时序是 33mSec/帧？

此致、

Nate

遗憾的是、我没有逻辑分析仪的访问权限。

我认为我提供的配置文件足以说明此问题。 我只想了解指定的 100ms 帧速率与 BIN 文件中报告的帧速率之间存在差异的原因。

此致、

Cagri  

您好、

我只是在尝试确认时序实际上是 33 毫秒/帧。 您还可以在可视化工具上计算周期数以确保这一点。  根据您给我的 cfg 文件、我预计会看到 100 毫秒的帧周期。

您能否在可视化工具上进行测量并计算每秒帧数？ 雷达是以 10Hz 还是 30Hz 的频率运行、应该非常明显。

此致、

Nate

您好 Nathan、

感谢您的澄清。 我获取了更多信息、希望这些信息有所帮助。

我根据您的建议执行了两次捕获：

1 — 在我的配置文件中将帧周期设置为 50ms

2 — 在我的配置文件中将帧周期设置为  100ms

在第 1 种情况下、我在 15 秒内捕获了大约 300 个帧、而在第二种情况下、捕获的帧数按预期下降到 150 个。 这一切相加、并清楚地显示了我在配置文件中提供的是真实世界中的真实帧速率。

这让我想到了我的调查结果的第二部分、这真的令人困惑。

对于案例 1、当我对每个 TLV 帧中的 timeCpuCycles_U32 字段进行解码时、以下是我捕获的数据中前 5 个帧的结果（为简单起见，我使用了 Python 样式编号格式）：

帧索引   时间 CpuCycles_U32   与前一帧的差异

0             471_447_450           不适用

1.             3_949_470_579         3_478_023_129

2.             3_959_475_120         10_004_541

3.             3_969_447_193         9_972_073

4.             3_979_457_993         10_010_800

对于案例 1、我还有 json 文件、在每个帧中都会报告一个名为“timestamp"的“的字段。 我包括前 5 个帧的字段（正如我在上面进行比较时所做的那样）：

   json 文件中的帧索引时间戳      与上一帧的差异

0             1754590363441.3767     不适用

1.            1754590363472.6309     31.254150390625

2.            1754590363503.8838.     31.25296875

3.            1754590363535.1377     31.25390625

4.            1754590363566.3904     31.252685546875

您可以看到、根据我到目前为止提供的时间数据 、timeCpuCycles_U32 和 timestamp 字段具有完全不同的值。 更重要的是、我无法看到如何将这些字段转换为在配置文件中设置的 50ms 帧周期。

现在让我为我提供相同的时间信息 情形 2 （即 100ms 帧周期情况 )。

以下是 每个 TLV 帧中的 timeCpuCycles_U32 字段、对于情况 2（同样，为了简单起见，我使用了 Python 样式编号格式）：

帧索引   时间 CpuCycles_U32   与前一帧的差异

0             387_363_722           不适用

1.             407_379_615           20_015_893

2.             427_356_881           19_977_266

3.             447_429_411            20_072_530

4.             467_396_736           19_967_325

在情况 2 中、以下是 json 文件时间戳值。 如上所述、我包括前 5 个帧的该字段：

   json 文件中的帧索引时间戳      与上一帧的差异

0            1754590452991.9429    不适用

1.            1754590453054.4485     62.505615234375

2.            1754590453116.9573     62.5087890625

3.            1754590453179.463       62.505615234375

4.            1754590453241.9692     62.50634765625

与第 1 种情况类似、我看不出上述时间测量值与第 2 种情况中预期的 100ms 帧周期有何关系。  

不过、我确实看到了在这种情况下 2 次时间测量（对于 json 时间戳以及 TLV  timeCpuCycles_U32 值）的一致性、正好是情况 1 中的两倍、这很合理。

在以上详细介绍之后、我有 3 个问题：

1 — 如何将 json 时间戳和 TLV  timeCpuCycles_U32 转换为正确的帧周期？

2 — 第一个帧 TLV timeCpuCycles_U32 有时似乎太小、这似乎是一种异常。 为了保持一致性、我是否应该忽略前几个帧？

3 — 对于 TLV  时间 CpuCycles_U32、当我从帧间时间差和预期帧周期（在本例中为 50ms 和 100ms）反向工作时、我将计算出 200MHz 的 CPU 频率。 这会响铃吗？ （我知道 DSP 频率是 600MHz、但我不确定 200MHz 指的是什么）

感谢您对此提供的帮助和指导。

此致、

Cagri

谢谢 Nathan。

您是否还对第一个要点提供了反馈 — 尤其是关于我如何使用 json 时间戳计算真实帧周期的反馈？ 这些  值似乎与 TLV timeCpuCycles_U32 的值大不相同、但在 我目前观察到的情况下、一致性明显更好。

此致、

Cagri

您好、

我在 10Hz 频率下运行类似实验时看到的时间戳显示时间戳以毫秒为单位。  您是否正在使用最新的 RTB 软件 (3.20)？