使用无线串口搭建星型网络

无线串口产品品类多,功率覆盖也比较全面,于是想利用这种模块来搭建星型网络。

花了几天时间把协议栈写出来了,并且在PC上用socket也仿真好了,效果非常好。但是后来移植到真实的无线串口时,问题就出来了,当数据节点多了后,丢包就多了,似乎内部就没有实现碰撞机制。更严重的是TX/RX切换特别慢,一个来回需要至少50ms时间,而传统的蓝牙4.0或者zigbee只需要2ms。

但好在简单的1-1不会丢包,看来协议栈还需要特殊优化。

时间: 2024-08-07 04:12:07

使用无线串口搭建星型网络的相关文章

「ZigBee模块」协议栈-串口透传,打造无线串口模块

前面写比较仔细,后面一个么因为和前面重复了,不多说了,还有个原因...我懒...O(∩_∩)O哈哈~ 串口透传,打造无线串口模块 一.实验目的 两台PC机各使用串口连接一个zigbee模块,连接正确后打开串口调试助手发送信息.利用zigbee将从串口接收到的数据无线传送给另一个zigbee模块,另一个zigbee模块通过串口将数据传给PC端并在屏幕上显示. 二.实验平台 硬件:两个zigbee模块,两台PC机(其实一台也许,连接不同串口即可),编译器,方口转USB数据线两根 软件:基于Z-sta

多数据中心的高可用结构【环状星型数据库架构】

贴一些比较老的内容,文章是新写的,技术可能都是大家熟悉的,给入门的兄弟们参考.高手轻拍原文请见:http://www.muduo.net/index.php/u ... space-itemid-318728 二.多数据中心的高可用结构[环状星型数据库架构]在介绍该结构之前,我们首先了解一下mysql复制的有关内容.在<highperformance mysql>的第一版中,作者介绍了这样的一种数据库结构:                              三个mysql的daemon

搭建Ntopng监控网络流量情况

ntopng是高速的基于Web的流量分析与集流工具.ntopng是ntop的新一代版本,官方原先版本的ntop已经不再更新.用户可以使用网页浏览器浏览查看网络中的流量信息,从而分析网络瓶颈. 1. 环境描述: 本文使用操作系统CentOS6.4-64bit,采用源码(Source code)的方式安装,本文使用ntop-1.1版本,ntopng下载地址:ntopng下载 http://www.ntop.org/get-started/download/. 2.安装依赖 rpm -ivh epel

Web用户控件开发--星型评分控件

本文中分享一个实现简单,使用方便的星型评分控件. 一:贴几张测试图片先: 二.星型评分控件的实现: RatingBar.ascx: <%@ Control Language="C#" AutoEventWireup="true" CodeBehind="RatingBar.ascx.cs" Inherits="UserControls.Controls.RatingBar" %> <style type=&q

Fact表的星型结构

声明:原创作品,转载时请注明文章来自SAP师太技术博客:www.cnblogs.com/jiangzhengjun,并以超链接形式标明文章原始出处,否则将追究法律责任!原文链接:http://www.cnblogs.com/jiangzhengjun/p/4295660.html 传统星型模型是将主数据与维度表放在一起,同一主数据在不同的交易数据维度表中存储多次,达不到复用,不灵活,主数据发生变化后,修改非常不便: BW里的星型模型采用的是扩展星型模型:维度表里存储的不是主数据本身,而是主数据的

事务码 ListSchema:查看Cube星型结构Schema

声明:原创作品,转载时请注明文章来自SAP师太技术博客:www.cnblogs.com/jiangzhengjun,并以超链接形式标明文章原始出处,否则将追究法律责任!原文链接:http://www.cnblogs.com/jiangzhengjun/p/4295666.html 可以通过事务码ListSchema,查看某个Cube的星型结构组成的所有表名  

《BI那点儿事》数据仓库建模:星型模式、雪片模式

数据仓库建模 — 星型模式Example of Star Schema 数据仓库建模 — 雪片模式Example of Snowflake Schema 节省存储空间 一定程度上的范式 星形 vs.雪花型 Which one is better? 长期以来的争论 两种观点各有支持者 争论在继续…… 目前看来,大部分更加倾向于星型 支持星形维度的论点 事实表总会是很大的,在维度表上节省的空间相对来说是很小的 增加了数据模型的复杂度 查询操作概念上更复杂了 从数据仓库到多维数据库的加载时间会更长 因

星型结构 和 雪花型结构

在多维分析的商业智能解决方案中,根据事实表和维度表的关系,又可将常见的模型分为星型模型和雪花型模型.在设计逻辑型数据的模型的时候,就应考虑数据是按照星型模型还是雪花型模型进行组织. 当所有维表都直接连接到“ 事实表”上时,整个图解就像星星一样,故将该模型称为星型模型, 如图 2 . 星型架构是一种非正规化的结构,多维数据集的每一个维度都直接与事实表相连接,不存在渐变维度,所以数据有一定的冗余,如在地域维度表中,存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录,那么国家

Oracle——星型查询

星型转换的基本思路是尽量避免直接去扫描星型模式中的事实表,因为这些事实表总会因为存有大量数据而十分庞大,对这些表的全表扫描会引起大量物理读并且效率低下.在典型的星型查询中,事实表总是会和多个与之相比小得多的维度表发生连接(join)操作.典型的事实表针对每一个维度表会存在一个外键(foreign key),除去这些键值(key)外还会存在一些度量字段譬如销售额度(sales amount).与之对应的键值(key)在维度表上扮演主键的角色.而事实表与维度表间的连接操作一般都会发生在事实表上的外键