标签: Simblee

经过上次的初步测评（ 【 Simblee 试用体验】 + 初步测评 ）实际针对 Simblee 系统的评价基本无望，只能针对 AS6200 传感器 进行测试。 一、测试方案： 将产品 sensor 处贴上测温热电偶，并整体至于温箱内，温箱设置不同温度，待温度稳定一段时间后，对比测试结果。 1. 热电偶粘贴位置如下（使用安规标准的 Satlon 胶），粘贴在 sensor 处以及主芯片上： Satlon 胶 热电偶粘贴位置（上部sensor，下部MCU） 产品放在温箱内，用塑料盒子装上 2. 热电偶测试设备 MX100 ： 3. 温箱温度程序设置： 二、温度测试结果： -5 ℃ 5 ℃（以下仅列出数据不付图） Sensor处热电偶温度：4.9 MCU处热电偶温度：5.3 被测设备手机显示温度：4.688 15℃ Sensor处热电偶温度：15.0 MCU处热电偶温度：15.4 被测设备手机显示温度：14.750 25℃ Sensor处热电偶温度：24.7 MCU处热电偶温度：25.4 被测设备手机显示温度：24.562 35℃ Sensor处热电偶温度：34.9 MCU处热电偶温度：35.4 被测设备手机显示温度：34.500 45℃ Sensor处热电偶温度：44.3 MCU处热电偶温度：44.9 被测设备手机显示温度：44.062 55℃ Sensor处热电偶温度：54.0 MCU处热电偶温度：54.8 被测设备手机显示温度：53.875

完成硬件搭建后，下一步就是用手机连接了，结果很不幸，找不到？！设计参考手册上写的是到 google app store 上搜索，但是大陆的尿性是上不了的，所以这条路封死了。随后我搜了一下 www.simblee.com 这个官网，结果也连不上搜不到；再搜索其母公司 RF Digital ，官网也没了；随后发现已经被 AMS 在 2016 年收购了，然后所有的资料在 2017 年最后更新以后，就全部停滞了。 现在在 AMS 上查到的所有关于传感器 AS6200 的资料中第一页都用大大的字写着： RF Digital 已经是我们的了。 但是在 AMS 上也下载不到软件，二维码扫了也识别不了，提示我“扫描器没问题，但是就是不给访问这个二维码”。于是翻 - 墙去 google ，因为账号久远，基于安全性要验证，但是大陆的手机号全部不支持验证，失败告终。最后查到 apkpure 这个网站可以下载 google app store 里面的软件，终于安装成功。 但是初步使用结果来看，虽然显示的精度很高，但是并不是特别的准，可能是因为没有校准的事情，而且反应很慢。下图是我手指肚的表面温度，明显感觉偏低。 我在 14:18 分进入一个没有空调的室内环境，显示 34.375 （下左图），同时用 TES1310 铂金电极来校对，这个套件一直到 14:25 左右才慢慢稳定，稳定的时候显示 36.815 和 36.875 （下右图）之间跳变，从这个结果来看，其分辨率应该是在0.05℃左右，而数据手册中给出的精度是0.4℃，实际显示到小数点后3位，这是怎么得出来的哩？ 而 TES1310 在几秒钟之内就稳定到 38.9~39.1 之间。 所以，经过简单的调试对比，基本功能能够实现并完成通讯，且今天所收集到的资料和程序，也已经上传到下载中心里，供大家使用。趁这几天休息好好想想要如何做下一步的工作。

前些日子参加论坛的活动，获得了一块 SimBlee 开发板，做一下简单的开箱评测。 SimBlee 是一个蓝牙模块的开发板，我之前没接触过蓝牙开发，以下以小白的角度来写，评测过程如有偏颇，读者见谅。 首先上几个开箱照吧： 图 1 SimBlee 开箱 1 图 2 SimBlee 开箱 2 图 3 SimBlee 开箱 3 粗略看来，该套件包含四件东西： 1.RFD77201 SimBlee RF Adapter（特点是低功耗低延时） 2.RFD77313 ams AS6200 温度传感器 3.RFD22121 USB 编程器 4.RFD22126 2xAAA 电源 Adapter 5. 配一条 USB 线 再来看看网友们的简介： https://www.leiphone.com/news/201502/RktOPDrf2unjicfw.html 图 3 网上资料 这个可能是网上唯一的中文信息了。 之后，我还在 github 上找了下有用的代码信息： https://github.com/edodm85/Simblee-BLE-Arduino https://github.com/OpenHAK/Simblee https://github.com/robomaniac/robotics-drone-gate 除以上信息外，没其他了。你没看错，真的没有其他信息。即使扫包装盒上的二维码，访问上面的网址 www.simblee.com ，都得不到任何信息。（访问网址直接就打不开） 好吧，既然这样，我只有 Fan 墙出去看看了。 然后在一个 arduino 论坛里，有网友这样说： https://forum.arduino.cc/index.php?topic=526686.0 图 4 网上资料 2 看来不好卖然后删库跑路了是实锤了。那这款开发板就等于没厂商继续支持了。看来还得继续在墙外徘徊一段时间，看看外面的开发者之前录的视频了，否则这东西玩不转啊。最主要是缺主控的 spec/datasheet 啊！ 共享些我目前找到的资料，方便下还在用此款开发板的朋友（估计国内玩这个的人真心不多啊）。 链接： https://pan.baidu.com/s/1TIs4ALsMTakMshrqmKI8ow 提取码： ubyl

In my previous article on this topic, we discussed how I'm using a 29-GPIO Simblee breakout board to control my cunning Chronograph.   29-GPIO Simblee breakout board (Source: Max Maxfield / Embedded.com)   Cunning Chronograph (Source: Max Maxfield / Embedded.com)   In the image above, the large blue board (front left) is my Arduino Mega. On top of this is my audio spectrum analyzer shield. At the back on the large breadboard we see one of Adafruit's ChronoDot Ultra-Precise Real-Time Clock (RTC) modules. In the fullness of time, this will be augmented with a temperature/pressure sensor module and a 9DOF (nine degrees of freedom) module boasting a 3-axis accelerometer, a 3-axis gyroscope, and a 3-axis magnetometer. The RTC and these sensor modules will all be mounted on a custom shield, but that's a tale for a future blog.   The smaller breadboard (front right) contains the Simblee breakout board. The 10mm x 7mm x 2mm Simblee chip itself is seen in the nearside corner of the breakout board. This chip boasts a 32-bit ARM Cortex-M0 microcontroller coupled with a Bluetooth Smart engine. As we've previously discussed, I'm using my Simblee to receive commands from my iPad, and to then present corresponding control signals to my Arduino.   Recently, I've been talking to quite a few people who are using Simblees. My impression is that approximately half of them are using their Simblees as stand-alone modules. By this I mean that the Simblee performs all of the processing functions and all of the interfacing to the outside world. The other half are doing what I'm doing -- using their Simblees to control other microcontrollers.   Now, I'm still a beginner at all of this, but I've created what I believe to be a rather cunning interface, and the folks I've already shared this with have said that they've found it to provide a useful starting point for their own projects, so I thought I'd share my current offering with you here.   Max's magnificent hierarchical interface Let's start by reminding ourselves that we program the Simblee using the Arduino IDE (Integrated Development Environment). A regular Arduino program has two main functions: setup() and loop() . In the case of a Simblee program, we augment this with two more functions: ui() and ui_event() .   The ui() function is where the majority of the SimbleeForMobile User Interface (UI) is defined in textual format. For example, we might call a function that says "Draw a switch at this XY location on the screen and make its ON color green," and so on for other objects like buttons, sliders, and so forth. This is the interface that will be uploaded to the mobile platform -- smartphone or tablet -- where it will be rendered (presented) as a Graphical User Interface (GUI).   The ui_event() function provides the callback mechanism by which the GUI on the mobile platform can communicate any actions back into the body of the sketch. We might think of this as acting a bit like an interrupt service routine (ISR). When the user performs some action on the mobile platform's screen, the system communicates this information back to the ui_event() function in our sketch.   One important point to note -- and one that wasn't clear to me at the beginning -- is that we don’t actually call the ui() and ui_event() functions ourselves. Instead, these are called by other functions hidden in the depths of the Simblee library.   Each graphical object we instantiate is automatically assigned its own unique identifier (ID). The ui_event() function supports a single parameter of type event_t , which is a pointer to a structure that contains all sorts of useful information, including the ID of the object being affected, the type of event, the value currently associated with the object, and so forth.   Now, before I show you this code, let's first take a look at my interface as it appears on my iPad:   Main modes (Source: Max Maxfield / Embedded.com)   This top-level menu reflects the fact that my Cunning Chronograph has (or, at least, it's going to have) eight main modes: Clock, Calendar, Lunar Calendar... and so forth. Before I transmit the mode I wish to display to the Arduino, I binary encode it into a 4-bit field (obviously, I only need three bits for eight modes, but I added an extra bit for future expansion). Selecting a new mode on this interface immediately causes the Cunning Chronograph to reflect that selection.   One point is that -- in the case of my Cunning Chronograph -- there must always be one mode selected. Thus, when you look at my code, you'll see that if I try to turn the currently selected mode off by dragging its switch, then the code ignores this and turns that switch back on again.   Each of my modes can have up to eight options. If you click the "Options" button associated with the "Music Wow" mode, for example, then you'll be presented with the following sub-menu:   Music Wow sub-menu (Source: Max Maxfield / Embedded.com)   As always when creating a program, there are multiple ways to do everything. For example, I could have created nine completely separate menus, each with their own switches and text annotations. In my case, however, I decided to re-use the same switches for all of the menus and to simply change the text annotations associated with the switches. Observe, for example, that the "Options" annotation associated with the bottommost switch in the top-level menu has been updated to read "Main Menu" in this sub/options-menu.   Now let's quickly skim through a couple of high-points in my interface (if you right-mouse Click Here and select the "Open in a separate window" option, you will be presented with a text file containing the full program in a pop-up window; also, you can Click Here to access a compressed ZIP file containing the program in the form of an Arduino *.ino file).   I'm assuming that you've opened the text file in a separate window as discussed above, so we can just talk about things here. We start off with a few definitions, including numStatePins and numOptionPins , which define the number of GPIOs we're using to present the current state and its associated options to the outside world. Also, numSwitches says that we have nine switches in all, while numStates and numOptions say that eight of these switches are used to specify the current state or options depending on where we are in the menu hierarchy.   Next, we declare some global variables as follows: menu is used to keep track of the menu level we're in (0 = the main menu; 1 = one of the options menus associated with the modes in the main menu) and state is used to keep track of what state (mode) we're in. Of particular interest is the options array, which is used to keep track of which options have been selected for each main mode. As we'll see, this means that we can pop up and down between the top-level screen and options screens without losing track of any options we've previously selected.   Now we declare the GPIOs that will interface to the outside world: pinsState specifies the four pins we are using to represent the currently selected state, while pinsOptions specifies the eight options associated with the currently selected state. Meanwhile, pinValid is used to inform whatever MCU we are communicating with whether or not the information on the other pins is currently valid or not (0 = Invalid; 1 = Valid).   Next up are the xySwitches and xyLabels arrays. These contain the XY coordinates of our nine switches and nine text annotations on the screen. The only reason for doing things this way is that, later on, we can use a simple for() loop to draw everything at the desired locations on the screen.   Remember we said that every object we draw on the GUI is automatically assigned a unique ID number? Well, the idSwitches and idLabels arrays are going to be used to store the IDs associated with our switches and labels, respectively.   Next, we see two arrays of pointers to text strings: *labelsStates and *labelsOptions . These are the text strings that will be displayed on the screen. If you refer back to the screenshots shown above, this will all start to make sense.   OK, let's skip the setup() and loop() functions and bounce over to the ui() function. Let's start with what's between the beginScreen() and endScreen() functions, which is where we actually describe what's going to be in our interface.   First of all, we draw the gray rectangle and black outline that's going to sit behind our switches; also, we write the name of this GUI ("Cunning Chronograph"). Next, we loop around drawing our nine switches along with their associated text annotations. In both cases, we store the unique IDs of these objects that are returned by the drawSwitch() and drawText() functions.   Actually, one clever part of all this occurs in the two statements following the endScreen() function call. Let's assume that we've just powered up our Simblee and launched this interface for the first time. In this case, the state will be 0 (indicating that we're in the Display Time mode. Now observe the updateValue() function call: updateValue(idSwitches ,1); This sends a command to the GUI to update the value of the switch whose ID is pointed to by state with a value of 1, which automatically turns this switch to its On position.   Now, let's assume that we start playing with our interface, moving between different states and setting the various options associated with each of those states. It would be a pain to lose all of these settings when we exit this GUI on the mobile platform.   This is the part that can be tricky to wrap one's brain around. Suppose we are currently in the Display Music Wow mode ( state = 6 ); maybe we are even in this mode's Options sub-menu. Now suppose we exit the GUI on the mobile platform. At this time, nothing is going to happen with the Cunning Chronograph -- the Simblee is just going to keep on working away.   But what happens when we re-connect the Simblee app? Well, when we re-launch the GUI, it will call our ui() function again. Once we've re-drawn all of our switches, we set menu = 0 to ensure we're on the top level menu. This time, state = 6 , so this is the switch that will be affected by the updateValue() function, thereby ensuring that our GUI reflects the currently selected state in the Simblee. Pretty cool, eh?   Finally, we arrive at the event_ui() function. This is where I originally made a mistake, because all I did was check for my switches being pressed. What I hadn’t realized is that every object in the GUI will trigger an event when it's touched, and this includes the rectangles I'm using to bound the switches and the text annotations. Thus, I added a quick test right at the beginning of this function to check whether or not the event was associated with one of my switches; if not, I simply ignore that event and move on with my life.   If it was one of my switches that were pressed, then there are four possibilities that need to be handled as follows: - We're on the main screen and we press the "Options" switch. In this case we need to move to the corresponding sub-menu, change the text annotations associated with the switches, and update the switches to reflect the currently active options. Note that nothing is happening here to affect the outside world. - We're on the main screen and we press one of the mode (state) switches. The first thing we need to do is to check that we aren’t trying to disable the currently-selected mode -- if we are, then we need to turn that switch back on again and not do anything else (basically, we're making our switches emulate "Radio Buttons"). If we have selected another mode, then we need to place our pinValid GPIO in its invalid state, wait a few milliseconds for the other MCU to see this, update the values on the pinsState and pinsOptions GPIOs, wait a few more milliseconds for the other MCU to catch up, then return the pinValid GPIO to its active state. - We're on one of the options screens and we press the "Main Menu" switch. In this case, all we need to do is re-draw the text annotations and update the switches to reflect the currently selected state. Once again, nothing is happening here to affect the outside world. - We're on one of the options screens and we press one of the options switches. In that case, all we need to do is store the new value associated with this option in the appropriate location in our options array, and also to change the state on the corresponding pinsOptions GPIO. Note that, in this case, we don’t need to play around with the pinValid GPIO. This is because the way my Cunning Chronograph works is that for each main mode, it loops around performing that function, and it checks the state of the options pins each time around the loop.   Well, I think that's enough for now. Based on the descriptions above, I think you should be able to work out what's happening in my code. If you have any questions, or if you spot something you think I should have done differently (or better), please don’t hesitate to let me know in the comments below.

I just had an epiphany. It didn't hurt though so don't worry. I was sitting down at the time. This is all to do with the Internet of Things (IoT).   I know that the IoT is a buzz-word everyone is throwing around these days, but I firmly believe that -- in the very near future -- the underlying concepts embodied in the IoT are going to change just about every aspect of our lives.   So, the root of my epiphany is this: from a 30,000 foot perspective, the IoT can be viewed as two separate beasts -- the Internet itself, and the "things" that are connected to it. What? You think that's obvious? You want more? OK, take a deep breath and hold onto your hat, because here we go...   The IoT is jolly exciting whichever way you look at it. We are seeing new developments on an almost daily basis with regard to sensor technology (including sensor hubs and sensor fusion) and incredibly low power microcontrollers. We're becoming acquainted with concepts like "processing on the edge" and "security on the edge," where "the edge" refers to the nodes that are interfacing with the real world, observing (sensing) things and controlling them. And, of course, we're also seeing major strides with regard to things like The Cloud and Big Data.   There is just one small fly in the soup, as it were. Up until now, most people tend to think of the "things" part of the IoT as being CBTFFUBTM.   Of course you don’t know what CBTFFUBTM means -- I just made it up. It stands for "Created by the few for use by the many." What I mean by this is that -- generally speaking -- creating an intelligent, wireless-enabled "thing" for use with the IoT requires a lot of expertise and knowledge. The end result is that most of us take it for granted that any capriciously cunning "things" have to be conceived, designed, and deployed by unkempt, badly dressed, socially inept embedded systems designers with size-16 brains (the ones with "go faster" stripes on the sides).   But all of this is about to change, because we are starting to see emerging tools and technologies that support the concept of the IoT4EE (the Internet of Things for Everyone and Everything). The idea is that anyone -- Engineers, Artists, Makers, Dreamers (even the French) -- should be able to conceive and create their own "things" for use with the IoT.   Of course, anything sounds easy if you say it fast enough and wave your arms around a lot, but IoT4EE tools and technology really are here. Take the folks at RF Digital, who are pioneers in IoT4EE Space (where no one can hear you scream). These little scamps have created something called Simblee, which turns out to be one of the most amazing things I've seen all week. Actually, the Simblee moniker encompasses a whole range of things, including the Simblee Cloud, the Simblee Ecosystem, and Simblee Modules. Below we see a Simblee BLE Module, which is tiny in size (10mm x 7mm x 2.2mm) and awesome in potential.     Now, the interesting thing here is that -- just a few minutes ago as I pen these words -- a package arrived in my office from the folks at RF Digital. As you can see in this video , this is a rather impressive package for a module that purports to be the size of one's thumbnail.     It may be that the folks at RF Digital pride themselves on their packaging skills. Alternatively, it could be that one of the minions at RF Digital's top-secret underground command and control bunker is over-enthusiastic (and/or over-caffeinated). As soon as I finish writing and posting this blog I will investigate further; all I can say is that I am squirming in excitement and prolonging the moment.   I truly believe that IoT4EE technology like the Simblee is going to change the way we think about the IoT. If you want to learn more, check out this blog I posted earlier, which explains things in excruciating detail.   When you discover just how cunning these little rascals are (I'm talking about the Simblee concept in general and Simblee Modules in particular, not the folks at RF Digital, although now I come to think about it…), I think you'll be joining me in thinking of all sorts of "things" we can build for use with the IoT. I certainly know what I'm going to be doing this coming weekend!