提问问题及错误

GNU Radio 具有一个很陡峭的学习曲线

GNU Radio 是一个大而复杂的项目。用好它需要耐心和技巧。GNU Radio 社区有益于大家,但是更希望大家能试图自己帮助自己。自主解决问题能够激发一种责任。而且,请记住没有人是付酬来回答你的问题的。即便是一个特别好的问题,也有可能招致几天,几个星期甚至如同石沉大海般的无人问津。

这篇文档有好多建议。对花费了很大的功夫来问题似乎不太公平然而,想想这些:你所提出这些问题招致成百上千的拥有十几年的通信、信号处理及相关行业经验的专家工程师(的努力)。如果有一个好的问题也提问得体,便可能使他们中间很多人花费很多时间去思考、反馈、也有可能做很多额外工作。所有这些都是免费。有经验的同等水平的咨询可是很昂贵的。

邮件列表提问之前应尝试的几件事情   

首先,安装一个从版本管理器(Subversion)那儿下载的干净的最新的GNU Radio安装系统代码,完全按照以下两个链接的文档的步骤。来试试问题是否还是出现。目前,人们在 GNU Radio 邮件列表上更感兴趣“美化时兴的事物”,而不感兴趣支持较早(过时)的版本或者诊断一个个性化系统中的问题。

其次,查看是否可以自己帮助自己或者寻求其他有过相同的问题的人。

  • 仔细的阅读所有的输出去查找出错的信息。这极有可能发现是什么导致错误的线索。
  • 如果错误信息来自 Python 程序,从下自上仔细读读。最后的输入会发现导致错误的原因,它上面的程序行告诉错误如何发生。
  • 请教身边的了解GNU Radio或通信技术的朋友、同事、教授等。这可能使得你在短时间内问很多的问题并能得到回答。
  • 使用 GNU Radio Wiki 的搜索。(http://gnuradio.org/redmine/search/index/gnuradio)
  • 搜索 GNU Radio 邮件列表档案 GNU Radio mailing list archive.
  • 在互联网上搜索
  • 读你正在用的代码。
如果如上罗列还不能帮助你,你下一步要做的是确信你对 GNU Radio 和 USRP有所了解。否则提问 FAQ 或邮件列表上的提问会招致没人理睬。
最后,你应当对 GNU Radio 的各个组成部分和其理论基石有所了解。你的问题有可能是需掌握 GNU Radio 所用的知识并不是 GNU Radio 本身。如果你对 Python、C++、Unix、基本信号处理原理、FPGA 设计、模拟射频(RF)电子学、或其它技术有疑惑,你可以考虑到相关的技术论坛寻求帮助。如果你的问题是明确同 GNU Radio、USRP 系列相关、或关联软件定义无线电的概念,discuss-gnuradio 也许是你求助的最好的论坛。无论如何先从教科书和网络中寻求答案。相关的参考书请参阅:参考读物SuggestedReading).

做完如上工作还是有问题,如何寻求帮助?

如果你的问题提问方式得体并能提供足够多的信息让我们能诊断你的问题,你便有可能从邮件列表中得到满意的答复。请仔细阅读并试图理解 How To Ask Questions The Smart Way. 我们至少需要知道:
  • 你是如何操作的招致代码无法工作?(如果你运行程序,我们需要所有的命令操作,"printenv" 的输出也许能帮助你做这些;如果你在你自己的程序中调用一些现成的代码,我们需要知道你的代码或至少那些导致错误的代码;如果你的问题是关于 GRC 流程图,那请你提供 GRC 生成的 .grc XML 文件和 .py 代码。)
  • 如果有可能的话,提供得到的出错信息。
  • 代码的效果同你的期望值如何不同?
  • 如果有的话,到目前为止,你使用那些 GNU Radio 软件?试一下其中一些例程,比如 usrp_fft.py。
  • 如果错误来自于 GUI 程序,请保存或截图,并把它保存到 WEB 或 FTP 服务中,给我们一个链接。
一些关联 GNU Radio 的特定事情,我们也必须知道:
  • 你使用什么样的操作系统?(Linux, BSD, Mac OS X, Windows, 或其他? 那种发行版? 版本号? 32- 或 64-位?)
  • 你用什么样的计算机运行 GNU Radio? (什么 CPU 构架?单处理器还是 SMP?)
  • 如果你使用 USRP,使用哪种子板?如果没有使用 USRP ,使用什么平台(数字化的硬件)?
  • 什么样的模拟硬件(天线、放大器、滤波器等)同你的平台的输入相连?

需要规范的信息表达吗?

How To Ask Questions The Smart Way 对此有很好的指导。以下所列的是一些常见的不雅行为。尤其是对 Outlook 或 PDAs 用户,这些规范也许同你在工作或学习中的感觉不同。但这些约定至少是自上个世纪八十年代以来 Unix 用户和新闻讨论组所一直遵从的。
  • 不要给列表发送大的附件。gnu.org 的服务器只有有限的带宽。如果你需要展示一些大的文件。把它们放在 web 和 ftp 服务器上。
  • 不要发送整个 python 脚本或整块代码。你可以把一小段相互关联的代码内联在你的文本中,但千万请把大块的代码或整个源文件作为附件发送。可能的话最好是放在 web 或 ftp 服务器上。
  • 不要发送 HTML 格式的邮件。好多用户使用的是基于文本格式的邮件阅读器。所以发送 HTML 格式的邮件到邮件列表是不雅行为。诸如色彩的华丽格式会被丢失。
  • 不要 top-post。它使得延伸讨论变得困难 
  • 裁剪一下你的回复。在做回复时,去掉不关联的内容,比如:签字和你没有回答的问题。
  • 不要使得回复不关联的信息而导致新的话题。这使得邮件线索阅读器产生困惑。(如有需要用将不关联的话题)设置一个新的话题。
  • 相反的,在一个已有的线索内回复问题,使用邮件的回复功能而不要在相同的主题下编辑一个新的信息。邮件线索阅读器依靠-头 In-Reply-To  来工作。使用回复功能它将被保留,但编辑新的邮件将没有此-头-标志。
  • 如果你的信息包括到特定文章的网络链接或discuss-gnuradio的线索(threads ),还应当该文章的主题。总是试图链接到 official gnu.org archive  上而不是诸如 ruby-forums.org 或 Nabble - 这些网站好像随时都会消失或改变 ULR 路径,这可能会使你的链接变得无意义。
  • 如果你想加入到 discuss-gnuradio 的讨论,请用规范化的选项对每个到来的信息个别发送的方式来订阅列表。不要每日摘要的格式。个别回复,而不是摘要式的回复。使用可以发送和回复的真实的邮件地址,而不是诸如 ruby - forum.org 的网络工具。 

问题的提问没有得到答复,该如何办?

问题发表后常常好几天没有答复。在等待的过程中,请继续研究问题;发现答案便请发表到列表上。不要重复提交同一问题,不要直接写信给列表上的邮件地址去询问。

常常得不到回答的原因是没有遵守这篇文章的建议。如果遵守这里的建议,回复的概率将被大大的提升。

如果确实着急或者发表问题到列表好几个星期一直没有被答复而且一点解决的方法都没有,那唯一的解决方法便是寻求咨询。这将会很昂贵。坊间有那么一些通信设计和信号处理的咨询公司;GNU Radio 尽管对其中没有任何偏好,但是 GNU radio 的网站维护者有时也做咨询: Corgan Enterprises 

分享答案

如果发现了问题的答案,与人分享是美德。用答案发布一个结束贴。这有如下好处:

  • 帮助其他有同样问题的人发现答案。
  • 它向所有其他助人为乐者展示他们的帮助得到回报,从而激发他们更加助人为乐。
  • 它给予你的问题的构造的额外的信息,这也可能有益于别人。 

道声谢谢

帮助别人应当得到鼓励。如果别人的支持很有用。道声谢谢。你将会得到更多的业分。







注:Asking Questions and Reporting Errors(原文出处,翻译整理仅供参考! )