cybiko:undocumentedsdk

RF

The following calls allow the RF power of the cybiko to be adjusted.

  • 1 = High power
  • 0 = Low power
 __cyos 1145 void set_power(int mode);
 __cyos 710 int get_power();

Interestingly, this call is defined in 'cyber-rf.h', but is not mentioned anywhere in the SDK documentation. I wonder what else is lurking in these .h files?

__cyos 1340 long get_gate_cyid (void); 
__cyos 716 int get_rfchannel (void); 
__cyos 707 char* get_ping_listener (void); 
__cyos 1141 void set_ping_listener (char * app_name); 
__cyos 1039 void reset_ping_listener (char * app_name); 
__cyos 1150 void set_rfchannel (int no); 
__cyos 718 bool get_server_mode (void); 
__cyos 1152 void set_server_mode (bool enable); 
__cyos 1341 bool is_gate_visible (void); 
__cyos 1269 void update_rf_time (void); 

Battery Charge

You can use this functions for obtaining battery charge:

 __cyos 632 unsigned int get_battery_charge(); 
 __cyos 805 bool is_battery_charging(); 

Define this function prototypes in your program and call them. More correct way is in the example:

 #include  
 
 __cyos 929 void* cyos_charger; 
 __cyos 632 int get_battery_charge( void* charger ); 
 __cyos 805 bool is_battery_charging( void* charger ); 
 
 int main() 
 { 
   TRACE( "is_battery_charging : %d",  is_battery_charging( cyos_charger ) ); 
   TRACE( "get_battery_charge : %d",  get_battery_charge( cyos_charger ) ); 
   return 0; 
 } 

But if you want to get batteries charge in millivolts define function

 __cyos 1455 unsigned get_ubat( void* charger );

and use the same way as function get_battery_charge().

Setting Alarms

Define and use functions:

 __cyos 1318 bool Time_get_alarm( struct Time* ptr_time ); 
 __cyos 1319 bool Time_set_alarm( struct Time* ptr_time );

Signal Strength

Message has been sended by deliver method in contrast to post method must be delivered to another Cybiko in the fixed timeout. But post method is faster and good in pinging. send_msg() function sends a message to another application in the same Cybiko computer using local message queue.

There are two types of channels numbering. First is for low level close to hardware. Total sum of these channels is 64 numbered from 0 to 63. This number included in every frame put on the air. Another numbering of the same channels starts from 1 for debugging radio part created several programs. It is “physical” channels corresponded with certain value of transmission frequency. Unfortunatly these channel slightly overlap each other. For applications only 30 channels were choosen from 64 with purpose of prevent overlaping and leaving permissible frequency range. They are numbered from 0 to 29. On different cybiko devices these channels can correspond with different physical channels. For example, on one device tenth application channel can be 22th physical channel on the another function get_appchannel_of(cyid of the first device) can return another application channel, e.g. 12th. However it is the same physical channel. For these concepts division “appcahnnel” was introduced into practice. For the application programmers zero is the base channel.

For those applications that have not specialized channels there are special groups of channels: for games - RF_GROUP_GAMES, for applicaions RF_GROUP_APPS. Notice again, it is not channels. It is groups of channels. Channels from these groups can be selected by index inside group (start from 0) using function

 byte_t set_groupchannel(byte_t channel_group, byte_t channel).

Number of channel in the group can be obtained from function byte_t get_group_size(byte_t group). However the most proper method is to request CyOS to set the least busy channel from the certain group by calling function byte_t set_best_appchannel(byte_t group). Order of two cyiko device transition to separate channel can be following: two devices are taking part - one starts the game: M (master), another answers with agree: S (slave).

  • Located on the base channel (appchannel(0)).
  • M: send invitation (select_partner()) and with the aid of it determine CyID of the opponent S.
  • M: switch to separated channel by calling set_best_appchannel( RF_GROUP_GAMES ).
  • M: send S message that it is time to change channel too.
  • S: when receive message change channel by calling function
set_appchannel(get_appchannel_of(master_cyid))
  • Start transmission.

The question is that on the step 4 device M know (remember) on what channel device S is situated. Device S just after receiving message from M will know on what channel device M is switched and will change channel to it.

Our device has half-duplex transmit-receiver. In the same time it can receive or send using one frequency. Therefore “working” channel is the frequency that device listens the most part of time. Other part of time it spends to transmitting. Device can transmit not only on “working” channel. On the base channel it sends pings once in five seconds. On the “working” channel pings are sent only if device did not send any packets more then 5 seconds.

To measure signal strength define function:

 __cyos 1357 unsigned int get_device_level( cyid_t cyid );

Returns device's avarage RSSI. RSSI - Received Signal Strength Indicator. Result is in range 0..100.

Serial Console I/O

From a note of groups.yahoo.com We suspect that the comport.dl is perhaps the cause of leaks/hangups, might be interesting to try these. It also used the comport.dl. If you are thinking of making a console app you might also note there are several undocumented functions for communicating with the console. The prototypes are in the sdk header files. They are:

 __cyos 407 int cgetch (clock_t timeout);
 __cyos 408 int cgets (char* buff,size_t max_size,clock_t timeout);
 __cyos 479 void cputch (char chr,clock_t timeout);
 __cyos 480 void cputs (char* str,clock_t timeout);

You wouldn't need the comport.dl and I'm guessing that's what Cybiko used themselves used.“

These functions are used to send information to the cybiko console, which is itself a serial application. How do these differ from those in comport.dl?
  • cybiko/undocumentedsdk.txt
  • Last modified: 2009/11/27 17:54
  • by 127.0.0.1