CPU Stick: preliminary tests for the anti-losing project

CPU Stick pairs:set up for testing

Overview

This post is a translation of the original one written in Italian by me here. Even though the anti-losing project is now over, I would like to share this preliminary tests I did because I hold the opinion that they may be useful for some of you.

First of all, I suggest you all to have a look at the CPU Stick official page here. As the authors state, "CPUStick™ is a 1”x4” very low cost standalone USB embedded computer, pre-loaded with StickOS BASIC, based on the Freescale MCF52252 ColdFire MCU and MC13201 ZigFlea Wireless Transceiver, similar in size and form to a USB “memory stick” and suitable for use in soldered or solderless-breadboard applications" and the operative system that provides an interactive environment with the user is called StickOS BASIC.

On this website, you can also find a well-organized forum where you can meet lots of people waiting for helping you.

This is a descriptive report that aims to sum up tests done by a pair of CPUSticks in order to evaluate the feasibility of the anti-losing project. 

Feasibility Study

The answer is simple: yes we can!

I shortly remind the technical specifications of the project:

1. a master device you can hold capable to to check the status  of one or more slave devices (embedded in objects we do not want to lose).
2. after a determined distance between master and slave, the former must signalize this event.
3. normally the slave device transmits and the master device receives
4. the master device can also transmit from time to time to each slave devices in order to check their localization.
5. defining different distances  for each slave is possible (the relation between master and each slave should be configurable)
6. adding a master device should enable/disable the control function with each associated slave (sometimes the user does not want to hold every object).
7. reduced dimensions for both type of device.

  As you may notice, the dimensions of the CPUStick board are not willingly reduced for practical reasons during the designing of prototypes which have to interface with it. I hold the opinion that all needed devices for the realization of the master and slave (micro-controller, transceiver, antenna), can have place on a pcb smaller of the CPUStick board. The transceiver is the Freescale MC13201 and it works with the Zigbee protocol. It can also work in different operative modes, either active or in low power. We are interested in TX-MODE (only transmission), RX-MODE (only reception) and ED/CCA-MODE (energy detection and clear channel assessment). In particular, the latter looks like being designed for the purpose of this project, but details will be written later in this post. The micro-controller is the Freescale MCF52259 and it can be set in different operative modes  in low-power set up that, with the PLL frequency, plays an important role on the total consumption of the board. This aspect will also be described onward in this post. Among its functions, the micro-controller has an interface SPI (serial peripheral interface) that allows the communication with the transceiver on the CPUStick board. Unfortunately, during the my tests I faced some StickOS limitations, the operative system that manage all the services on the board. Indeed, StickOS does not allow to exploit the low-power mode offered by the micro-controller and it does not allow the transmission/ reception of a single data packet and contemporary reading the RSSI from the transceiver. Generally speaking, I would say that StickOS exploits the potential of all devices on the board at an high level, but it does not exploits all offered services.

Current Consumption

The following picture shows how I measured the current consumption of the CPUStick Board. Simply, I used a tester as an amperometer  with its tips on the jumper J2. I exploited some taps because I did not have nothing at that moment. 

Measuring current consumption

As I switched it on, the board consumes about 206 mA and it is a lot of current for the purpose of this application.  This fact is justified by the fact that the transceiver is in RX-MODE  that consumes typically 37 mA with a pick of 35 mA. The micro-controller is set up to work at a PLL frequency equals to 80 MHz with a correspondent consumption of  118 mA, but it can reach 185 mA. It is possible to establish the PLL frequency according to the fact that the board has an quartz oscillator of 48 MHz as frequency, and by setting the correct values in the registers SYNCR (Synthesizer Control Register), CCHR (Clock Control High Register) , LPDR (Low Power Divider Register). StickOS allows to do that by defining and by setting the values of variables with the command "let". For example:

dim cchr as byte at address 0x40120008 
let cchr=0x2

 The consumption can be reduced up to 70 mA if the PLL frequency is set at 8 MHz, therefore the micro-controller consumes about 35 mA. A lower consumption can be reached by totally disabling the PLL and by exploiting only the frequency of the quartz. This can be done by dealing with the pins CLKMOD0 and CLKMOD1 on the jumper j4. Unfortunately, I could not run this test because this jumper is not present on the board. The micro-controller  may set the operative mode with low energy consumption  and the STOP-mode consumption effect might have been interesting for us (around 10 mA according to the manual).

I said "might have been" because the StickOS does not allow the set up of this function.

The idea behind a significant reduced current consumption of a slave device might be in the fact that the transceiver might be in the "idle" state for most of the time (about 1 uA) and the micro-controller at the  STOP-MODE (less than 10 mA). A periodic interrupt might be set (every 2-3 seconds) in order to switch the micro-controller in RUN-MODE and the transceiver to in TX-MODE. This state should last only the time necessary to send a packet containing a device ID and the device can come back to "sleep". on the contrary, the master device should be always "awake", so the WAIT mode might be useful (the device simply waits for new packets). This latter mode further reduces the current consumption when compared to the RUN mode. However, I think that the total current consumption of the master cannot be lower than 40 mA even though the PLL is off.

Getting the RSSI

Tests I have performed with the goal to get the RSSI (Received Signal Strength) did not successful  results because of the following reasons. Anyway, I think that describing my tests might be useful for whom is interested in. First of all, I set up one CPUStick as nodeid 1 and the other one as nodeid 2.
This is the program for nodeid 1:

10 dim led as remote on nodeid 2 
20 while 1 do
30 let led = !led
31 sleep 1000 ms
40 endwhile end

This is the program for nodeid 2:

10 dim led as pin dtin0 for digital output
15 dim rxtxen as pin fec_txclk for digital output
20 dim cs as pin qspi_cs0 for digital output
30 dim irq as pin irq1* for digital input
50 dim cmd as byte
60 dim control_a as short, rx_status as short, cca_thresh as short
70 dim irq_status as short, value as short
80 // start
90 let rxtxen = 0
100 // setting cca_threshold
110 let cmd = 0x4 // writing on 0x4 register (CCA_Thresh)
120 let value = 0xa49d //cca_vt=0xa4, power_comp=0x9d
130 let cs = 0
140 qspi cmd, value
150 let cs = 1
160 //setting control_a
170 let cmd = 0x6 // writing on 0x6 register (Control_A)
180 let value = 0x411 // cca_mask=1, cca_type=01, xcvr_seq=01
190 let cs = 0
200 qspi cmd, value
210 let cs = 1
220 let rxtxen = 1
221 on !irq do gosub read_registers
230 while 1 do
240 assert rxtxen
260 endwhile
270 end
280 sub read_registers
290 let rxtxen = 0
310 let cmd = 0x86 // reading 0x6 register (Control_A)
320 let cs = 0
330 qspi cmd, control_a
340 let cs = 1
350 print "CONTROL A REGISTER ", hex control_a
360 let cmd = 0x84 // reading 0x4 register (CCA_Thresh)
361 let cs = 0
362 qspi cmd, cca_thresh
363 let cs = 1
370 print "CCA THRESH REGISTER ", hex cca_thresh
380 let cmd = 0xad // reading 0x2d register (RX_STATUS)
390 let cs = 0
400 qspi cmd, rx_status
410 let cs = 1
420 print "RX_STATUS ", hex rx_status
430 let cmd = 0xa4 // reading register 24 (IRQ_STATUS)
440 let cs = 0
450 qspi cmd, irq_status
460 let cs = 1
470 print "IRQ_STATUS ", hex irq_status
480 let rxtxen = 1
490 return
500 endsub

CPUStick: setup of nodeid 2

The aim of this test is to make a led on the pin dtin0 of nodeid2 blinking with a period of 1 second by sending the blink command from the nodeid1. Since I would like to read the power of the received signal, it is necessary to set the transceiver at CCA mode, Clear Channel Assessment. It is worthwhile to note that it was possible to set the ED mode (Energy Detection) too, but the CCA mode allows to set a threshold useful in case you want to signalize the state under/over this value. The reading and the writing operations on the transceiver registers are possible by the spi interface (command "qspi") and two variables ("cmd" and "value"). At the beginning, the program disables the reception-transmission of the transceiver (rxtxen=0) in order to set up the desired mode (CCA). The first operation is to write in the register CCA_THRES (address 0x04) the threshold value (cca_vt[7:0]) and a compensation value (power_comp[7:0]) that is exploited later for the calculus of the power of the signal. Basically, I write the value suggested non the manual because I am not interested in this particular function, but in reading the signal power. Then, I set some bit (cca_mask, cca_type[1:0], xcvr_seq[1:0]) in the register Control_A_Register (address 0x06) which represent the desired configuration  for the transceiver, the configuration for enabling an interrupt after the calculus of the received signal power. Next, there is the definition of a subroutine that the program calls each time the re is an interrupt, in other words each time the value of the signal power is up to date. This subroutine is written to read all registers involved in the process and particularly that one containing the RSSI value. This register is called RX_STATUS and its address is 0x2D. After the execution, results are not those ones I expected. The effect I got is to lose the communication between the devices and sometimes StickOS get jammed. Therefore, I asked for assistance to Rich Testardi (my "guru" in this field) and as far as I understood StickOS does not have this functions for these kind of test. The problem is that both my BASIC program and StickOS try to access to the transceiver registers synchronously. Consequently, the result is not predictable. 

Conclusions

In this post I briefly showed the test I performed on the CPUStick. Surely, I have to admit that it is a good board designed for prototyping and that StickOS provides an user-friendly interface.