目录

  • 1. IEEE 802.15.4
    • 1.1 T-Frame
    • 1.2 I-Frame
  • 2. message_t
    • 2.1 Headers
    • 2.2 Data
    • 2.3 Footer
    • 2.4 Metadata
  • 3. CC2420 Radio Stack
    • 3.1 层体系结构
    • 3.2 层描述
    • 3.3 CC2420 数据包结构和规范
      • 3.3.1 message_t 与802.15.4帧的对应关系
    • 3.4 CSMA/CA
      • 3.4.1 CCA 空闲信道检测
      • 3.4.1 Radio Backoff
    • 3.5 ACK
      • 3.5.1 硬件ACK vs 软件ACK
      • 3.5.2 DSN
    • 3.6 PacketLink
      • 3.6.1 在PacketLink层中编译
      • 3.6.2 使用
    • 3.7 LPL
    • 3.8 减少能量消耗

1. IEEE 802.15.4

  IEEE 802.15.4是一种技术标准,它定义了低速率无线个域网 (LR-WPAN)的协议。 它规定了LR-WPAN的物理层和媒体访问控制 ,并由IEEE 802.15工作组维护,该工作组在2003年定义了该标准。它是Zigbee的基础。

  802.15.4支持几种不同的源和目标寻址模式,因此具有可变大小的数据包报头。一个TinyOS设备必须支持具有16位短源地址和目的地址的数据包帧。一个TinyOS设备可能支持额外的802.15.4帧格式。

1.1 T-Frame

  TinyOS有两种802.15.4帧格式。
  第一种格式是T-Frame,适用于TinyOS网络,它不与其他无线网络架构共享信道。这种框架格式假设TinyOS 可以使用数据包的每一个比特,并且不需要声明它是一个TinyOS数据包。T-Frame代表着TinyOS 帧(TinyOS Frame)

  AM type是一个单独的字节字段,它指示了payload包含的活动消息类型。

1.2 I-Frame

  第二种格式是I-Frame,适用于与6lowpan网络共享信道的TinyOS网络。6lowpan为非6lowpan数据包的有效载荷的第一个字节保留了一系列代码。为了与6lowpan网络进行互操作。TinyOS I-Frames指定了这样一个字段。I-Frame代表着互操作帧(Interoperable Frame)

  AM type与T-Frame相同,6lowpan位是识别TinyOS包的NALP代码。NALP代码必须在0-63的范围内。TinyOS使用代码63。AM type 63 为T-Frame和I-Frame的保留项。TinyOS程序不能使用它。

2. message_t

  在TinyOS 2.x中,标准消息缓冲区(message buffer)为消息message_t,message_t 结构定义在 tos/types/message.h 中:

typedef nx_struct message_t {nx_uint8_t header[sizeof(message_header_t)];nx_uint8_t data[TOSH_DATA_LENGTH];nx_uint8_t footer[sizeof(message_footer_t)];nx_uint8_t metadata[sizeof(message_metadata_t)];
} message_t;

  这种格式使数据在平台上保持固定的偏移量。当在两个不同的链路层之间传递消息缓冲区时,这一点非常重要。对于不同的链路层,如果数据加载处于不同的偏移量。然后,在两个链路层之间传递数据包将需要memmove(3)操作。在实践中,Tinyos 2 x中的大多数数据链路层都提供了活动的消息传递,但是非AM堆栈与AM堆栈共享message_t是可能的。
  headerfootermetadata都是不透明的。源代码不能直接访问字段。取而代之是,数据链路层通过nesC接口提供对字段的访问。
  每个链路层定义了它的headerfootermetadata。这些结构必须是外部结构(nx struct),它们的所有字段必须是外部类型(nx * ),这有两个原因。首先,外部类型确保了跨平台兼容性。其次,它强制结构在字节边界上对齐。规避数据包缓冲区(message buffer)和字段偏移(field offsets )的对齐问题。metadata字段必须是nx structs,用于将完整的数据包转发到串口以便记录流量。
  TinyoS 2.x组件将数据包视为抽象数据类型(ADTs),而不是C结构。获得此方法的所有传统好处。首先,包层(packet layer)的客户端不依赖于特定的字段名或位置,允许实现选择包格式并进行各种优化。在基本数据链路层之上的组件必须通过接口访问数据包字段。引入新包字段的组件应该为其他组件感兴趣的字段提供接口。这些接口应该采用获取和返回值的get/set操作的形式,而不是直接进入结构。
  例如活动消息有一个名为AMPacket的接口,它提供对AM字段的访问命令。组件调用AMPacket.getAddress(msg)。这些接口中最基本的是数据包,它提供对包的访问。因此,它们可以实现为其他组件提供对字段访问的接口。

2.1 Headers

  message_t 报头字段是一个字节数组,其大小为平台的数据链路报头的联合体大小。因为无线电堆栈通常更喜欢连续存储数据包,因此数据包在内存中的溢出并不一定反映其nesC结构的布局。数据包的报头可以在message_t 开头之外的某个地方开始。例如,参考Telos平台:

// tos/platforms/telosa/platform_message.h
typedef union message_header {cc2420_header_t cc2420;serial_header_t serial;
} message_header_t;typedef union TOSRadioFooter {cc2420_footer_t cc2420;
} message_footer_t;typedef union TOSRadioMetadata {cc2420_metadata_t cc2420;serial_metadata_t serial;
} message_metadata_t;


  CC2420和串行堆栈都没有包footer,而且串行堆栈没有任何metadata元数据。链路层的数据包不一定从message_t 的开头开始。相反,它从数据字段的一个负偏移量开始。当链路层组件需要读取或写入协议头字段时。它必须以数据字段的负偏移量计算报头的位置。例如,串行堆栈标头具有活动消息字段,如AM type。返回AM type的命令AMPacket.type()。

serial_header_t* getHeader(message_t* msg){return (serial_header_t*)(msg->data -sizeof(serial_header_t));
}command am_id_t AMPacket.type(message_t* msg){serial_header_t* hdr = getheader(msg);return hdr->type;
}

  因为计算负偏移量有点笨拙,所以串行堆栈使用内部辅助函数getHeader()。许多单跳堆栈都采用这种方法,因为nesC很可能将函数内联,从而消除了可能的开销。在大多数情况下,C编译器还将调用编译为简单的内存偏移负载。
  下面的代码是不正确的,因为它直接强制转换了header字段。这是不能做的一个例子:

serial_header_t* getHeader(message_t* msg){return (serial_header_t*)(msg->header);
}

  在这种情况下,将导致包布局看起来像这样:

2.2 Data

  message_t 数据字段存储单跳数据包payload。它是 TOS_DATA_LENGTH 字节长度,默认大小是28字节。TinyOS应用程序可以重新定义TOS_DATA_LENGTH 。因为这个值可以重新配置,所以应用程序的两个不同版本可能具有不同的MTU(最大传输单元)大小。如果数据包层接收到一个数据包,其有效载荷大小大于 TOS_DATA_LENGTH 数据长度。它必须丢弃这个包。由于报头与数据有效负载的开始对齐,平台上所有链路层的数据有效负载从消息缓冲区开始的相同固定偏移量开始。

2.3 Footer

  message_t 的footer字段确保message_t 当有mtu大小的包时有足够的空间存储所有底层链路层的footer。与header一样,footer也不一定存储在C结构所指示的位置:相反,它们的位置取决于实现。单跳层可以将footer与数据区域连续存储。对于短数据包,这可能意味着footer将实际存储在数据字段中。

2.4 Metadata

  message_t 的metadata元数据字段存储单跳栈使用或收集但不传输的数据。这种机制允许数据包层存储每个包的信息,如RSSI或时间戳。例如,CC2420元数据结构:

typedef nx_struct cc2420_metadata_t {nx_uint8_t rssi;nx_uint8_t lqi;nx_uint8_t tx_power;nx_bool crc;nx_bool ack;nx_bool timesync;nx_uint32_t timestamp;nx_uint16_t rxInterval;
/** Packet Link Metadata */
#ifdef PACKET_LINKnx_uint16_t maxRetries;nx_uint16_t retryDelay;
#endif
} cc2420_metadata_t;

  message_t针对具有固定大小header和footer的数据包进行了优化。可变footer通常很容易实现。可变大小的header有点困难。有三种通用的方法可以使用。

  • 如果底层链路硬件是基于字节(byte-based)的。header可以存储在message_t的开头,给它一个已知的偏移量。头和数据区域之间可能存在填充,但假设是基于字节的发送路径,这只需要调整索引。
  • 如果底层链路硬件是基于分组(packet-based)的。那么协议栈可以包含元数据声明头的开始或者它可以在接收和传输把头放在一个固定的位置并使用memmove(3)。
  • 在后一种情况下。在接收时,数据包从报头结构的偏移处开始被连续地读入message_t 中。一旦数据包被完全接收,可以对报头进行解码,计算其长度,并且数据包的数据区域可以移动到data字段。在传输时,情况相反,数据区域(如果需要的话,还有footer)被移动到与header相邻的位置。注意,在传输完成后,需要将它们移回。另外,射频协议栈可以在底层建立一个单一副本。

3. CC2420 Radio Stack

  TI/Chipcon CC2420 Radio是一个复杂的设备,负责传输和接收数据包的许多低级细节。CC2420射频堆栈硬件需要一个定义良好的Radio Stack实现。尽管射频芯片本身的大部分功能是可用的,但在实现灵活的、通用的Radio Stack时,仍有许多因素需要考虑。驱动CC2420 Radio的软件Radio Stack由位于应用程序和硬件之间的许多层组成。Radio Stack的最高级别修改每个数据包中的数据和报头,而最低级别决定实际的发送和接收行为。通过理解栈的每一层的功能以及层本身的体系结构,可以轻松地扩展或压缩CC2420无线电堆栈以满足项目需求。

3.1 层体系结构

  CC2420 Radio Stack由相互堆叠的功能层组成,以提供修改、筛选、传输和控制入站和出站消息的完整机制。每一层都是一个独立的模块,可以提供和使用与实际Radio Stack相关的三组接口:Send、Receive、SplitControl。如果一个通用层提供其中一个接口,那么它也会在堆栈中使用它下面层中的接口。
  CC2420 Radio Stack的实际连线是在堆栈的最高级别内部完成的,位于CC2420ActiveMessageC。这个配置定义了三个分支:Send、Receive和SplitControl。注意,不是所有的层都需要提供和使用所有这三个接口。

3.2 层描述

CC2420 Radio Stack层次顺序如下:

  • ActiveMessageP
      这是堆栈中的最高层,负责填写信息包报头中的详细信息,并向应用程序级别提供关于该信息包的信息。因为CC2420射频芯片本身在硬件中使用802.15.4报头,因此该层也不可能重新排列报头字节。

  • UniqueSend
      这层生成一个唯一的数据序列号(DSN)字节的数据包报头。这个字节每输出数据包增加一次,从伪生成的数字开始。接收器可以通过比较接收包的源和DSN字节与以前的包来检测重复的包。DSN在802.15.4规范中定义。

  • PacketLink
      该层提供了自动重发功能,当没有听到来自接收者的确认ACK时,它负责包的重发。PacketLink是基于消息前激活的,这意味着即将离开的数据包不会使用PacketLink,除非它提前配置。与硬件自动ACK相比,当软件ACK启用时,PacketLink是最可靠的。

  • CC2420AckLplP/CC2420NoAckLplP
      这些层提供异步低功耗监听实现。CC2420DutyCycleP同时支持它们。DutyCycleP组件负责打开和关闭radio以及执行接收检查。当检测发生后,DutyCycleP将移交给LowPowerListeningP来执行一些事务,并在方便时关闭radio。
      低功率侦听传输是基于消息前激活的,并且该层将持续地重新传输完整的出站包,直到从接收者的响应被听到或传输时间过期。AckLplP实现支持低功率侦听分组序期间的确认间隙。它允许发射机提前停止,但惩罚接收检查长度。AckLplP低功率监听是最佳的高传输,长接收检查间隔网络的方案。
      NoAckLplP实现不支持在包序期间的ACK。它连续调制信道,允许接收器执行最小的可能的接收检查。NoAckLpl低功率监听对于低传输、短接收检查间隔网络是有效的。

  • UniqueReceive
      这一层维护它收到的过去几个包的源地址和DSN字节的历史,并帮助过滤掉重复收到的包

  • TinyosNetworkC
      这一层允许TinyOS 2.x Radio Stack与其他非tinyos网络互操作。提议的6LowPAN规范包括在标准802.15.4报头之后的网络标识符。如果使用了互操作性帧,那么分派层提供了在传出数据包上设置网络字节和过滤非tinyos传入数据包的功能。

  • CsmaC
      这一层负责定义出站包的802.15.4 FCF字节信息,当射频检测通道被占用时提供默认的回退时间。以及定义Radio 的开机/关机程序。

  • TransmitP/ReceiveP
      负责通过SPI总线、中断和GPIO线与Radio的直接交互。

3.3 CC2420 数据包结构和规范

  CC2420包结构是在CC2420.h中定义的。默认的I-Frame CC2420报头采用以下格式:

typedef nx_struct cc2420_header_t {nxle_uint8_t length;nxle_uint16_t fcf;nxle_uint8_t dsn;nxle_uint16_t destpan;nxle_uint16_t dest;nxle_uint16_t src;    // CC2420 802.15.4 header ends herenxle_uint8_t network;// I-Frame 6LowPAN interoperability bytenxle_uint8_t type;
} cc2420_header_t;
  1. length到src字段都是802.15.4指定的字段,并在CC2420硬件本身中使用。
  2. network字段是一个6LowPAN互操作性规范,只有当6LowPAN TinyosNetwork层被包括时才被包括。
  3. type字段是TinyOS特定的字段。TinyOS T-Frame数据包不包括network字段,也不包括在分派层中发现的设置和检查network字段的功能。
  4. 没有为CC2420 radio定义软件包footer。一个2字节的CRC字节被CC2420无线电硬件本身自动附加到每个出站包。
  5. 包的最大大小是128字节,包括它的报头和CRC,这符合802.15.4规范。增加数据包的大小会增加TinyOS应用程序的数据吞吐量和RAM消耗,也会增加干扰导致数据包被销毁并需要重新传输的可能性。TOSH_DATA_LENGTH可以修改预处理器变量,以增加message_t 在编译时负载的大小。

3.3.1 message_t 与802.15.4帧的对应关系


下表为Telosb平台下的无线包各字段的含义与赋值位置:

字段 类型 含义 802.15.4帧字段 默认值 赋值组件
length uint8_t 帧长度 PHR 12(header)+28(payload)+2(crc) -1 CC2420ActiveMessageP
fcf uint16_t 帧控制字段 MHR FCF CC2420ActiveMessageP
dsn uint8_t 数据序列号 MHR DSN UniqueSendP
destpan uint16_t 网络组号 Pan ID MHR Address Information 0x22 CC2420ActiveMessageP
dest uint16_t 目标地址 MHR Address Information CC2420ActiveMessageP
src uint16_t 源地址 MHR Address Information CC2420ActiveMessageP
network uint8_t I-Frame 6LowPAN ID MHR Address Information 0x3F CC2420TinyosNetworkP
type uint8_t AM层类型 TinyOS特定字段 MHR Address Information CC2420ActiveMessageP
payload [uint8_t ] 有效负载 MAC Payload 默认28个字节 应用层用户自行赋值

3.4 CSMA/CA

3.4.1 CCA 空闲信道检测

  默认情况下,CC2420 Radio Stack在发射前执行clear channel assessment (CCA)。如果信道不空闲,Radio 会后退一段短的、随机的时间,然后再试图发送。当通道是空闲时,CC2420芯片本身提供了一个切换指令来传输数据包。
  为了指定是否使用空闲通道评估CCA进行传输,CC2420TransmitP通过RadioBackoff接口在每条消息的基础上请求CCA回退输入。默认情况下,每个数据包将在启用CCA的情况下传输。
  如果CSMA 层之上的层希望在传输前禁用CCA,他们必须拦截该消息的RadioBackoff.requestCca(…)事件,并使用RadioBackoff.setCca(FALSE)来回调。

3.4.1 Radio Backoff

  backoff是radio在尝试发送之前暂停的一段时间。当radio需要退出时,它可以选择三个退出周期之一:initialBackoff,congestionBackoff和IplBackoff。这些都是通过RadioBackoff接口实现的,该接口发出一个请求来指定回退周期。与CsmaBackoff接口不同,对调整回退感兴趣的组件可以使用RadioBackoff接口中的命令回调。这允许多个组件为它们专门侦听的数据包调整回退周期。回退周期越低,传输速度越快,但发射机占用信道的可能性就越大。此外,回退周期应尽可能随机,以防止两个发射机在同一时刻对信道进行采样。

  1. InitialBackoff是在第一次尝试传输数据包时请求的最短回退周期。
  2. CongestionBackoff是当发现信道正在使用时使用的较长的回退时间。在这种情况下,通过使用更长的回退周期,发射机不太可能不公平地占用信道。
  3. LplBackoff是用于低功率监听的数据包发送的回退周期。因为在避免干扰其他发射机的同时低功率监听需要信道被尽可能连续地调制,低功率侦听回退周期会针对性的更短。

3.5 ACK

3.5.1 硬件ACK vs 软件ACK

  最初,CC2420 Radio Stack仅使用由CC2420芯片本身提供的硬件生成自动确认。这导致了一些问题,如错误的Ack,射频芯片将要收到一个数据包,并回复其Ack,而微控制器实际上却没收到数据包。当前的CC2420堆栈使用软件Ack,其丢失百分比更高。当与UniqueSend和UniqueReceive接口一起使用时,丢弃的Ack比错误的Ack更可取。接收到的数据包总是在作为副本过滤之前得到确认。
  使用PacketAcknowledgements或PacketLink接口来确定包是否被成功确认。

3.5.2 DSN

  802.15.4规范在消息头中识别一个数据序列号(DSN)字节来过滤掉重复的包
  位于CC2420 Radio Stack顶部的UniqueSend接口负责设置DSN字节。在启动时,使用伪随机数生成器生成一个初始DSN字节,最大值为8位(256)。这个数字在每次发送数据包传输时增加。即使较低的级别,如PacketLink或低功率侦听重传数据包,数据包的DSN字节也保持相同。
  在CC2420 Radio Stack底部的UniqueReceive接口负责基于源地址和DSN过滤掉重复的消息。这个独特的接口并不能阻止复杂的重复攻击。
  当接收到数据包时,DSN和源地址信息被放置到一个数组元素中。来自先前记录的地址的后续消息会覆盖分配给该源地址的元素中的信息。这可以防止UniqueReceive的历史丢失来自不能经常访问信道的源的DSN字节信息。如果历史数组中的元素数量用完,UniqueReceive会尽最大的努力来避免替换最近更新的DSN/源信息条目。

3.6 PacketLink

  PacketLink是添加到CC2420 Radio Stack的一层,用于帮助单播数据包成功发送。在TinyOS Radio Stacks的早期版本中,如果应用程序确定消息没有被正确接收,则由应用层来重试消息传输。PacketLink层有助于消除应用程序层的可靠传递责任和功能包袱。

3.6.1 在PacketLink层中编译

  因为PacketLink层使用了额外的内存占用,所以默认情况下不会编译它。开发人员可以简单地定义预处理器变量PACKET LINK来编译CC2420栈中的PacketLink层的功能。

3.6.2 使用

  要使用PacketLink发送消息,必须提前调用PacketLink接口,在出站消息的元数据中指定两个字段:

command void setRetries(message_t *msg, uint16_t maxRetries);
command void setRetryDelay(message_t *msg, uint16_t retryDelay);

  第一个命令setRetries(…)将指定Radio Stacks停止传输之前发送消息的最大次数。
  第二个命令setRetryDelay(…)指定每次重试之间的延迟量(毫秒)。
  这两个命令的组合可以设置数据包按需要重试多少次,需要多久就重试多少次。因为PacketLink依赖于ACK,所以接收方发出的错误ACK将导致PacketLink失败。如果使用软件ACK,由于DSN空间有限,该区域内其他802.15.4 radios与同一目的地址等原因,仍然可能出现错误的ACK。

3.7 LPL

  因为低功耗侦听层会消耗额外的内存占用,所以默认情况下不会编译它。开发人员只需定义预处理器变量LOW_POWER_LISTENING,就可以在CC2420堆栈中编译低功耗监听层的功能。
  LPL实现依赖CCA,以确定附近是否有发射机。这使得接收器能够在短时间内打开并确定没有发射机,而不是让收音机长时间打开以接收一个完整的数据包。
  发射机通过在接收机占空比周期的两倍时间内反复传输全包来执行消息传递。发送两倍的时间会增加信息被接收方探测到的可能性,并且允许接收方减少维持无线电的一小段时间。
  通常,单个数据包的传输随着时间的推移呈现如下形式:

  为了减少接收检查所需的时间,信道必须由发射机尽可能连续地进行调制。信道被调制的唯一时期是在包传输阶段。接收器必须连续采样CCA引脚,采样时间比LPL回退周期和Ack等待周期长一点,以重叠Packe传输周期。通过使LPL回退周期尽可能短,我们可以减少在执行接收检查时必须打开接收机radio的时间。
  如果两个发射机尝试使用低功率监听进行传输,如果LPL回退周期设置得太短,则其中一个发射机可能独占信道。同时传输的两个节点会产生干扰,从而阻碍彼此成功地将其信息传递给目标接收方。
  为了允许多个发射机同时传输低功率的侦听包,需要将LPL回退周期提高到高于所需的最小值。这就增加了接收机radio需要打开的时间,以执行接收检查,因为信道不再被尽可能连续地调制。换句话说,信道被允许在多个发射机之间共享,但以功耗为代价。

3.8 减少能量消耗

有以下几种方法,来减少CC2420 Radio Stack能量消耗:

  1. 无效数据包关闭: 通常情况下,信息包在无线电硬件级别被地址过滤掉。当一个接收器醒来,没有收到任何进入Radio Stack低功率接收层的数据包,它将自动回到睡眠一段时间后。作为次要备份,当无线电芯片上的地址解码被禁用时,如果收到三个包不属于该节点,低功率监听层将关闭radio。这有助于防止睡眠攻击或在有许多节点的点对点网络中发现的典型传输行为。
  2. 提前完成传输: 通常情况下,发送器发送数据包的时间是接收器接收检查周期的两倍。这增加了接收方检测到数据包的可能性。但是,如果发射机在其传输周期结束前收到确认信息,它将停止发送以节省能量。这是对以前的低功率监听实现的改进,以前的低功率监听实现在整个时间内传输,而不管接收方是否已经唤醒并接收到数据包。
  3. 自动关闭: 在启用低功率监听时,如果radio在一段时间内不发送或接收信息,radio将自动关闭,并在指定的占空比周期开始占空比循环。
  4. CCA采样策略: 实际的接收检查是在函数内部的循环中执行的,而不是旋转任务,这样可以连续地执行采样,目标是在不中断的情况下尽可能快地关闭radio。

TinyOS数据帧与CC2420 Radio Stack解读相关推荐

  1. Data Augmentation for Deep Learning-based Radio ModulationClassification解读(基于深度学习的无线电调制分类数据扩充)

    摘要:深度学习最近被应用于自动分类接收无线电信号的调制类别,而无需人工经验.然而,训练深度学习模型需要大量的数据.训练数据不足会导致严重的过度拟合问题,降低分类精度.为了处理小数据集,数据增强被广泛应 ...

  2. Contiki系统介绍

    本文内容来源为contiki英文介绍,自己为了学习,将其大致翻译成中文,以便了解. 欢迎转载,转载请注明来源,如果有什么翻译不合适的地方,请留言指出,相互交流学习. 介绍 Contiki是一个开放源码 ...

  3. Chakra-UI组件库介绍

    Chakra-UI是一个现代化React UI框架.它是用来构建用户界面的. Chakra-UI是一个简单的.模块化的易于理解的UI组件库.提供了丰富的构建React应用所需的UI组件. 其优点有下面 ...

  4. Reacr -- Chakra-UI

    Chakra-UI 介绍 Chakra UI 是一个简单的, 模块化的易于理解的 UI 组件库. 提供了丰富的构建 React 应用所需的UI组件. 文档: https://next.chakra-u ...

  5. React UI 组件库 Chakra UI - 05 案例实践

    案例实践 使用 create-react-app 新建项目. 表单 使用 Chakra UI 实现下图的表单: 构建注册表单 react-icons 是一个 React 流行图标库. // compo ...

  6. html5 gps 坐标转高德地图坐标,GPS坐标转百度地图坐标的方法

    首先需要认识一下GPS的坐标系.GPS坐标系遵循WGS-84标准,在这个标准下,GPS芯片可以发出不同的数据包格式.根据其数据帧帧头的不同,GPS数据可以分类为GPGGA.GPGSA.GPGSV.GP ...

  7. GPS坐标转百度地图坐标的方法

    转自:GPS坐标转百度地图坐标的方法 - 程序员大本营 首先需要认识一下GPS的坐标系.GPS坐标系遵循WGS-84标准,在这个标准下,GPS芯片可以发出不同的数据包格式.根据其数据帧帧头的不同,GP ...

  8. Pandas 秘籍:6~11

    原文:Pandas Cookbook 协议:CC BY-NC-SA 4.0 译者:飞龙 六.索引对齐 在本章中,我们将介绍以下主题: 检查索引对象 生成笛卡尔积 索引爆炸 用不相等的索引填充值 追加来 ...

  9. Java Review - Queue和Stack 源码解读

    文章目录 Pre 概述 Queue Deque ArrayDeque 一览 构造函数 属性 方法 addFirst() addLast() pollFirst() pollLast() peekFir ...

  10. ML:MLOps系列讲解之《MLOps Stack Canvas堆栈画布之MLOps Stack CanvasCRISP-ML(Q)》解读

    ML:MLOps系列讲解之<MLOps Stack Canvas堆栈画布之MLOps Stack Canvas&CRISP-ML(Q)>解读 目录 MLOps系列讲解之<ML ...

最新文章

  1. 计算机里的音乐都是什么名字,PAPI
  2. android 之DatePicker以及TimePicker的用法
  3. lnmp环境搭建:Centos7 + Nginx1.12.2 + Mysql-5.6.38 + PHP7.2.0
  4. JAVA学习:maven开发环境快速搭建How to download J2EE API (javaee.jar) from Maven
  5. Day1 了解web前端
  6. python中__init__函数以及参数self
  7. 随笔27 面向对象的五大基本原则
  8. Java每次输入一个字符+高精度取整计算(记洛谷P2394题WA+TLE+RE的经历,Java语言描述)
  9. 严重的“Access:7”供应链漏洞影响100多家厂商150多款联网设备等产品
  10. 375.猜数字大小II
  11. 五款服务器配置管理工具
  12. Angular动态加载组件报错:No component factory found for XXXXComponent. Did you add it to
  13. postgresql注册表删除_【清理注册表】删除SQL Server注册表
  14. android+自定义跑马灯,Android自定义图文跑马灯效果
  15. 模电十:555定时器
  16. oracle用par文件导出dmp文件及导入dmp文件
  17. Spring Boot + ECharts
  18. html rfftq15.gif,STM32F4系列完整固件库
  19. vagrant的同步文件配置,配置虚拟机ip映射
  20. Python中的numpy.cumsum()

热门文章

  1. React高级(五)
  2. OSChina 周五乱弹 —— 埃塞俄比亚的远房大表姐
  3. AP AUTOSAR ——Diagnostic Management
  4. mysql修改my.ini_MySQL配置文件(my.ini)详解
  5. 推荐一款强大的在线编译器
  6. 解析DNA甲基化临床科研 | 无论什么科室,一定要有project的经典视角|易基因
  7. 如何看懂源代码--(分析源代码方法)
  8. turtle库画超立方体 难度1
  9. 华为交换机配置ntp服务时间 自动同步不成功unsynchronized
  10. 学习平面设计有哪些前途