9.7 Implementation and Analysis of
Binary Search Trees
As described earlier, binary search
trees perform well only if the tree remains balanced.
Unfortunately, keeping a binary search tree balanced is a more
difficult problem than it may at first appear. Nevertheless,
there are a few clever approaches one can take. One of the
best approaches is to implement the tree as an AVL tree.
An AVL (Adel'son-Vel'skii and Landis) tree is
a special type of binary tree that stores an extra piece of
information with each node: its balance factor. The balance factor of a node is the
height of the subtree rooted at its left child minus the
height of the subtree rooted at its right child (see Figure
9.9). As nodes are inserted, an AVL tree adjusts itself so
that all balance factors stay +1, -1, or 0. A subtree whose
root node has a balance factor of +1 is said to be left-heavy. A subtree whose root node
has a balance factor of -1 is said to be right-heavy. A subtree whose root
node has a balance factor of is considered balanced. By
keeping its subtrees nearly balanced, an AVL tree stays approximately balanced overall.
The basic means of searching and inserting
nodes in an AVL tree is the same as described earlier.
However, when we insert a node into an AVL tree, we have some
additional work to do after the node descends to its
appropriate position. First, we must account for the change in
balance factors that occurs as a result of the insertion.
Also, if any balance factor becomes ±2, we must rebalance the
tree from that point down, which is done by performing an
operation called a rotation.
9.7.1 Rotations in AVL Trees
A rotation
rebalances part of an AVL tree by rearranging nodes while
preserving the relationship wherein the left is smaller than
the parent and the parent is smaller than the right, which
must be maintained for the tree to remain a binary search
tree. After the rotation, the balance factors of all nodes in
the rotated subtree are +1, -1, or 0.
There are only four types of rotations that
ever have to be performed. These are the LL (left-left), LR (left-right), RR (right-right), and RL (right-left) rotations. The functions
rotate_left and rotate_right, presented later in Example
9.5, implement each of these rotations. To understand when
we need to apply each rotation, let x represent the node we have just
inserted into its proper location in an AVL tree, and let
A be the nearest ancestor of
x whose balance factor has
changed to ±2.
<IP_ADDRESS> LL rotation
We perform an LL, or left-left, rotation when
x lies in the left subtree of the left subtree of A (see Figure
9.10). Let left be the left
child of A. To perform an LL
rotation, we set the left pointer of A to the right child of left, the right pointer of left to A, and the pointer referencing A to left. After the rotation, we set the
balance factors of both A and
left to 0. All other balance
factors do not change.
<IP_ADDRESS> LR rotation
We perform an LR, or left-right, rotation
when x lies in the right subtree of the left subtree of A (see Figure
9.11). Let left be the left
child of A and grandchild be the right child of
left. To perform an LR
rotation, we set the right child of left to the left child of grandchild, the left child of grandchild to left, the left child of A to the right child of grandchild, the right child of grandchild to A, and finally the pointer
referencing A to grandchild.
Adjusting the balance factors of nodes after
an LR rotation depends on the original balance factor of grandchild. Figure
9.12 illustrates the three cases to consider. If the
original balance factor of grandchild was +1, we set the balance
factor of A to -1 and left to 0. If the original balance
factor of grandchild was 0, we
set the balance factors of both A and left to 0. If the original balance
factor of grandchild was -1, we
set the balance factor of A to
and that of left to +1. In all
cases, we set the new balance factor of grandchild to 0. All other balance
factors do not change.
<IP_ADDRESS> RR rotation
We perform an RR, or right-right, rotation
when x lies in the right subtree of the right subtree of A. The RR rotation is symmetric to
the LL rotation. Let right be
the right child of A. To
perform an RR rotation, we set the right pointer of A to the left child of right, the left pointer of right to A, and the pointer referencing A to right. After the rotation, we set the
balance factors of both A and
left to 0. All other balance
factors do not change.
<IP_ADDRESS> RL rotation
We perform an RL, or right-left, rotation
when x lies in the left subtree of the right subtree of A. The RL rotation is symmetric to
the LR rotation. Let right be
the right child of A and grandchild be the left child of right. To perform an RL rotation, we
set the left child of right to
the right child of grandchild,
the right child of grandchild
to right, the right child of
A to the left child of grandchild, the left child of grandchild to A, and finally the pointer
referencing A to grandchild.
Adjusting the balance factors of nodes after
an RL rotation depends on the original balance factor of grandchild. There are three cases to
consider. If the original balance factor of grandchild was +1, we set the balance
factor of A to and that of
right to -1. If the original
balance factor of grandchild
was 0, we set the balance factors of both A and left to 0. If the original balance
factor of grandchild was -1, we
set the balance factor of A to
+1 and that of left to 0. In
all cases, we set the new balance factor of grandchild to 0. All other balance
factors do not change. These adjustments are symmetric to
those shown in Figure
9.12 for an LR rotation.
The structure BisTree is the binary search tree data
structure. A good way to implement a binary search tree is to
use the binary tree abstract datatype discussed earlier. Thus,
BisTree is implemented as a typedef to
BiTree (see Example
9.4). In addition to simplicity, using a typedef has the
benefit of making the binary search tree somewhat polymorphic,
just as described for stacks and queues (see Chapter
6). This means that we can use binary tree operations on a
binary search tree in addition to those operations defined
specifically for binary search trees.
Since keeping a binary search tree balanced
requires that each node store more than just the data placed
in the tree, a structure, AvlNode, is defined
for each node to contain (see Example
9.4). An AvlNode structure consists of three members:
data is the data stored in the node,
hidden is a member used to mark a node when it
is removed, and factor is the node's balance
factor. The implementation presented here also uses
identifiers to represent the possible values for balance
factors. Example
9.4 equates AVL_LEFT_HEAVY to 1,
AVL_BALANCED to 0, and
AVL_RGT_HEAVY to -1.
Example 9.4.
Header for the Binary Search Tree Abstract Datatype /*****************************************************************************
* *
* ------------------------------- bistree.h ------------------------------ *
* *
*****************************************************************************/
#ifndef BISTREE_H
#define BISTREE_H
#include "bitree.h"
/*****************************************************************************
* *
* Define balance factors for AVL trees. *
* *
*****************************************************************************/
#define AVL_LFT_HEAVY 1
#define AVL_BALANCED 0
#define AVL_RGT_HEAVY -1
/*****************************************************************************
* *
* Define a structure for nodes in AVL trees. *
* *
*****************************************************************************/
typedef struct AvlNode_ {
void *data;
int hidden;
int factor;
} AvlNode;
/*****************************************************************************
* *
* Implement binary search trees as binary trees. *
* *
*****************************************************************************/
typedef BiTree BisTree;
/*****************************************************************************
* *
* --------------------------- Public Interface --------------------------- *
* *
*****************************************************************************/
void bistree_init(BisTree *tree, int (*compare)(const void *key1, const void
*key2), void (*destroy)(void *data));
void bistree_destroy(BisTree *tree);
int bistree_insert(BisTree *tree, const void *data);
int bistree_remove(BisTree *tree, const void *data);
int bistree_lookup(BisTree *tree, void **data);
#define bistree_size(tree) ((tree)->size)
#endif
9.7.2 bistree_init
The bistree_init operation initializes a
binary search tree so that it can be used in other operations
(see Example
9.5). Since a binary search tree is a binary tree, we call
bitree_init to initialize it.
The compare member is set to
compare by hand because this member is not
used by binary trees and therefore is not set by bitree_init.
The runtime complexity of bistree_init is the same as bitree_init, or O (1).
9.7.3 bistree_destroy
The bistree_destroy operation destroys a
binary search tree (see Example
9.5). To do this, we employ the support of two additional
functions, destroy_left and destroy_right, which recursively
destroy the left and right subtrees beneath a node. These
functions work similarly to the bitree_rem_left and bitree_rem_right functions defined
previously for binary trees. Separate functions are required
for binary search trees so that we can destroy the data
referenced by a node's AvlNode structure as
well as free the AvlNode structure itself.
The runtime complexity of bistree_destroy is the same as bitree_destroy, or O (n),
where n is the number of nodes
in the tree.
9.7.4 bistree_insert
The bistree_insert operation inserts a
node into a binary search tree (see Example
9.5). The operation works by recursively calling insert to descend to the point at
which the actual insertion should be made. Once we insert the
node, we update balance factors on our way back up the tree as
the recursion unwinds. If, in so doing, any balance factor
reaches ±2, we perform a rotation.
We begin by checking whether we are inserting
a node into an empty tree. If this is
the case, we simply insert the node and set its balance factor
to AVL_BALANCED. Otherwise, we compare the
data to be inserted with that of the current node to determine
the direction in which to move. We proceed as we described
earlier for inserting a node into a binary search tree. When
the data we are inserting is less than that of the current
node we are traversing, we make a recursive call that moves us
to the left. When the data is greater, we make a recursive
call that moves us to the right. Once we locate the point at
which to make the insertion, we allocate an
AvlNode structure and insert it into the tree
as the appropriate child of the current node. If the data to
be inserted matches that of a node hidden as a result of being
removed, we destroy the data currently in the node, insert the
new data in its place, and mark the node as no longer hidden.
In this case, rebalancing is not required.
Except after replacing a previously hidden
node, we next determine how the balance of the tree has been
affected so that we can make repairs if necessary. Whether we
have inserted the node to the left or right, we set
balanced to to indicate that the insertion may
have upset the balance of the tree. This causes a switch
statement to be executed that adjusts the balance factor of
the current node. Adjusting the balance factor of the current
node may, in turn, upset the balance factors of nodes higher
in the tree. Thus, as we reenter each activation of insert, we update the balance factor
of the node traversed at that level, provided
balanced is still 0. Once we determine that no
more updates are required, we set balanced to
to inform previous activations of this decision.
The switch statements that determine how to
update balance factors also determine when rotations should be
performed. The actual function we call to perform the
rotation, either rotate_left or
rotate_right, determines the
type of rotation to apply: either LL or LR if we call rotate_left, or RR or RL if we call
rotate_right. Since rotations
change the balance factors of nodes, each rotation function
also adjusts balance factors. The best way to understand the
process of updating balance factors and performing rotations
is to trace through the example in Figure
9.13.
Earlier it was mentioned that the runtime
complexity of inserting a node into a perfectly balanced
binary search tree is O (lg
n). However, since an AVL tree
keeps itself only approximately balanced, one might wonder how
this affects performance. It turns out that the worst-case
running time of inserting a node into an AVL tree is T (n)
= 1.5k lg n, where k is some constant, n is the number of nodes in the tree,
and T (n) = k
lg n is the time to
insert a node into a perfectly balanced binary tree. Just as
with insertion into a perfectly balanced tree, this results in
a runtime complexity of O (lg
n). However, the constant of
1.5 does influence performance somewhat in practice.
9.7.5 bistree_remove
The bistree_remove operation removes a
node from a binary search tree (see Example
9.5). For this operation, we apply a rather simplistic
heuristic termed lazy removal, in which we hide nodes instead of
actually removing them. To hide a node, we set the
hidden member of its AvlNode
structure to 1. If we insert the same data again later, we
simply make the node visible again by setting its
hidden member back to (see bistree_insert). In practice, this
approach is acceptable if we do not expect to remove many
nodes relative to the number we insert. If we plan to remove a
large number of nodes, we might consider actually removing the
node and adjusting the tree. To locate the node to hide, we
recursively call hide until we reach the node we are looking
for. Once we hide the node, there is no need to rebalance the
tree because we did not change its structure. Thus, we set
balanced to 1.
The analysis of removing a node from an AVL
tree is the same as for inserting a node. Thus, the runtime
complexity of bistree_remove is
O (lg n).
9.7.6 bistree_lookup
The bistree_lookup operation searches for
a node within a binary search tree and returns a pointer to
the data member of its AvlNode structure (see
Example
9.5). The operation works by calling lookup recursively to descend through
the tree until the desired node is found. At each level, we
first check if we have reached the end of a branch. If we
reach the end of a branch, the node we are looking for does
not exist. Otherwise, we move to either the left or right in
the same manner as described for bistree_insert. The recursion
terminates once we encounter the desired node, at which point
we return 0.
The analysis of searching an AVL tree is the
same as for inserting a node. Thus, the runtime complexity of
bistree_lookup is O (lg n).
9.7.7 bistree_size
This macro evaluates to the size of a set
(see Example
9.4). It works by accessing the size
member of the BisTree structure.
The runtime complexity of bistree_size is O (1) because accessing a member of a
structure is a simple task that runs in a constant amount of
time.
Example 9.5.
Implementation of the Binary Search Tree Abstract Datatype
/*****************************************************************************
* *
* ------------------------------- bistree.c ------------------------------ *
* *
*****************************************************************************/
#include <stdlib.h>
#include <string.h>
#include "bistree.h"
static void destroy_right(BisTree *tree, BiTreeNode *node);
/*****************************************************************************
* *
* ------------------------------ rotate_left ----------------------------- *
* *
*****************************************************************************/
static void rotate_left(BiTreeNode **node) {
BiTreeNode *left,
*grandchild;
left = bitree_left(*node);
if (((AvlNode *)bitree_data(left))->factor == AVL_LFT_HEAVY) {
/**************************************************************************
* *
* Perform an LL rotation. *
* *
**************************************************************************/
bitree_left(*node) = bitree_right(left);
bitree_right(left) = *node;
((AvlNode *)bitree_data(*node))->factor = AVL_BALANCED;
((AvlNode *)bitree_data(left))->factor = AVL_BALANCED;
*node = left;
}
else {
/**************************************************************************
* *
* Perform an LR rotation. *
* *
**************************************************************************/
grandchild = bitree_right(left);
bitree_right(left) = bitree_left(grandchild);
bitree_left(grandchild) = left;
bitree_left(*node) = bitree_right(grandchild);
bitree_right(grandchild) = *node;
switch (((AvlNode *)bitree_data(grandchild))->factor) {
case AVL_LFT_HEAVY:
((AvlNode *)bitree_data(*node))->factor = AVL_RGT_HEAVY;
((AvlNode *)bitree_data(left))->factor = AVL_BALANCED;
break;
case AVL_BALANCED:
((AvlNode *)bitree_data(*node))->factor = AVL_BALANCED;
((AvlNode *)bitree_data(left))->factor = AVL_BALANCED;
break;
case AVL_RGT_HEAVY:
((AvlNode *)bitree_data(*node))->factor = AVL_BALANCED;
((AvlNode *)bitree_data(left))->factor = AVL_LFT_HEAVY;
break;
}
((AvlNode *)bitree_data(grandchild))->factor = AVL_BALANCED;
*node = grandchild;
}
return;
}
/*****************************************************************************
* *
* ----------------------------- rotate_right ----------------------------- *
* *
*****************************************************************************/
static void rotate_right(BiTreeNode **node) {
BiTreeNode *right,
*grandchild;
right = bitree_right(*node);
if (((AvlNode *)bitree_data(right))->factor == AVL_RGT_HEAVY) {
/**************************************************************************
* *
* Perform an RR rotation. *
* *
**************************************************************************/
bitree_right(*node) = bitree_left(right);
bitree_left(right) = *node;
((AvlNode *)bitree_data(*node))->factor = AVL_BALANCED;
((AvlNode *)bitree_data(right))->factor = AVL_BALANCED;
*node = right;
}
else {
/**************************************************************************
* *
* Perform an RL rotation. *
* *
**************************************************************************/
grandchild = bitree_left(right);
bitree_left(right) = bitree_right(grandchild);
bitree_right(grandchild) = right;
bitree_right(*node) = bitree_left(grandchild);
bitree_left(grandchild) = *node;
switch (((AvlNode *)bitree_data(grandchild))->factor) {
case AVL_LFT_HEAVY:
((AvlNode *)bitree_data(*node))->factor = AVL_BALANCED;
((AvlNode *)bitree_data(right))->factor = AVL_RGT_HEAVY;
break;
case AVL_BALANCED:
((AvlNode *)bitree_data(*node))->factor = AVL_BALANCED;
((AvlNode *)bitree_data(right))->factor = AVL_BALANCED;
break;
case AVL_RGT_HEAVY:
((AvlNode *)bitree_data(*node))->factor = AVL_LFT_HEAVY;
((AvlNode *)bitree_data(right))->factor = AVL_BALANCED;
break;
}
((AvlNode *)bitree_data(grandchild))->factor = AVL_BALANCED;
*node = grandchild;
}
return;
}
/*****************************************************************************
* *
* ----------------------------- destroy_left ----------------------------- *
* *
*****************************************************************************/
static void destroy_left(BisTree *tree, BiTreeNode *node) {
BiTreeNode **position;
/*****************************************************************************
* *
* Do not allow destruction of an empty tree. *
* *
*****************************************************************************/
if (bitree_size(tree) == 0)
return;
/*****************************************************************************
* *
* Determine where to destroy nodes. *
* *
*****************************************************************************/
if (node == NULL)
position = &tree->root;
else
position = &node->left;
/*****************************************************************************
* *
* Destroy the nodes. *
* *
*****************************************************************************/
if (*position != NULL) {
destroy_left(tree, *position);
destroy_right(tree, *position);
if (tree->destroy != NULL) {
/***********************************************************************
* *
* Call a user-defined function to free dynamically allocated data. *
* *
***********************************************************************/
tree->destroy(((AvlNode *)(*position)->data)->data);
}
/**************************************************************************
* *
* Free the AVL data in the node, then free the node itself. *
* *
**************************************************************************/
free((*position)->data);
free(*position);
*position = NULL;
/**************************************************************************
* *
* Adjust the size of the tree to account for the destroyed node. *
* *
**************************************************************************/
tree->size--;
}
return;
}
/*****************************************************************************
* *
* ----------------------------- destroy_right ---------------------------- *
* *
*****************************************************************************/
static void destroy_right(BisTree *tree, BiTreeNode *node) {
BiTreeNode **position;
/*****************************************************************************
* *
* Do not allow destruction of an empty tree. *
* *
*****************************************************************************/
if (bitree_size(tree) == 0)
return;
/*****************************************************************************
* *
* Determine where to destroy nodes. *
* *
*****************************************************************************/
if (node == NULL)
position = &tree->root;
else
position = &node->right;
/*****************************************************************************
* *
* Destroy the nodes. *
* *
*****************************************************************************/
if (*position != NULL) {
destroy_left(tree, *position);
destroy_right(tree, *position);
if (tree->destroy != NULL) {
/***********************************************************************
* *
* Call a user-defined function to free dynamically allocated data. *
* *
***********************************************************************/
tree->destroy(((AvlNode *)(*position)->data)->data);
}
/**************************************************************************
* *
* Free the AVL data in the node, then free the node itself. *
* *
**************************************************************************/
free((*position)->data);
free(*position);
*position = NULL;
/**************************************************************************
* *
* Adjust the size of the tree to account for the destroyed node. *
* *
**************************************************************************/
tree->size--;
}
return;
}
/*****************************************************************************
* *
* -------------------------------- insert -------------------------------- *
* *
*****************************************************************************/
static int insert(BisTree *tree, BiTreeNode **node, const void *data, int
*balanced) {
AvlNode *avl_data;
int cmpval,
retval;
/*****************************************************************************
* *
* Insert the data into the tree. *
* *
*****************************************************************************/
if (bitree_is_eob(*node)) {
/**************************************************************************
* *
* Handle insertion into an empty tree. *
* *
**************************************************************************/
if ((avl_data = (AvlNode *)malloc(sizeof(AvlNode))) == NULL)
return -1;
avl_data->factor = AVL_BALANCED;
avl_data->hidden = 0;
avl_data->data = (void *)data;
return bitree_ins_left(tree, *node, avl_data);
}
else {
/**************************************************************************
* *
* Handle insertion into a tree that is not empty. *
* *
**************************************************************************/
cmpval = tree->compare(data, ((AvlNode *)bitree_data(*node))->data);
if (cmpval < 0) {
/***********************************************************************
* *
* Move to the left. *
* *
***********************************************************************/
if (bitree_is_eob(bitree_left(*node))) {
if ((avl_data = (AvlNode *)malloc(sizeof(AvlNode))) == NULL)
return -1;
avl_data->factor = AVL_BALANCED;
avl_data->hidden = 0;
avl_data->data = (void *)data;
if (bitree_ins_left(tree, *node, avl_data) != 0)
return -1;
*balanced = 0;
}
else {
if ((retval = insert(tree, &bitree_left(*node), data, balanced))
!= 0) {
return retval;
}
}
/***********************************************************************
* *
* Ensure that the tree remains balanced. *
* *
***********************************************************************/
if (!(*balanced)) {
switch (((AvlNode *)bitree_data(*node))->factor) {
case AVL_LFT_HEAVY:
rotate_left(node);
*balanced = 1;
break;
case AVL_BALANCED:
((AvlNode *)bitree_data(*node))->factor = AVL_LFT_HEAVY;
break;
case AVL_RGT_HEAVY:
((AvlNode *)bitree_data(*node))->factor = AVL_BALANCED;
*balanced = 1;
}
}
} /* if (cmpval < 0) */
else if (cmpval > 0) {
/***********************************************************************
* *
* Move to the right. *
* *
***********************************************************************/
if (bitree_is_eob(bitree_right(*node))) {
if ((avl_data = (AvlNode *)malloc(sizeof(AvlNode))) == NULL)
return -1;
avl_data->factor = AVL_BALANCED;
avl_data->hidden = 0;
avl_data->data = (void *)data;
if (bitree_ins_right(tree, *node, avl_data) != 0)
return -1;
*balanced = 0;
}
else {
if ((retval = insert(tree, &bitree_right(*node), data, balanced))
!= 0) {
return retval;
}
}
/***********************************************************************
* *
* Ensure that the tree remains balanced. *
* *
***********************************************************************/
if (!(*balanced)) {
switch (((AvlNode *)bitree_data(*node))->factor) {
case AVL_LFT_HEAVY:
((AvlNode *)bitree_data(*node))->factor = AVL_BALANCED;
*balanced = 1;
break;
case AVL_BALANCED:
((AvlNode *)bitree_data(*node))->factor = AVL_RGT_HEAVY;
break;
case AVL_RGT_HEAVY:
rotate_right(node);
*balanced = 1;
}
}
} /* if (cmpval > 0) */
else {
/*************************************************************************
* *
* Handle finding a copy of the data. *
* *
*************************************************************************/
if (!((AvlNode *)bitree_data(*node))->hidden) {
/********************************************************************
* *
* Do nothing since the data is in the tree and not hidden. *
* *
return 1;
}
else {
/********************************************************************
* *
* Insert the new data and mark it as not hidden. *
* *
********************************************************************/
if (tree->destroy != NULL) {
/*****************************************************************
* *
* Destroy the hidden data since it is being replaced. *
* *
*****************************************************************/
tree->destroy(((AvlNode *)bitree_data(*node))->data);
}
((AvlNode *)bitree_data(*node))->data = (void *)data;
((AvlNode *)bitree_data(*node))->hidden = 0;
/********************************************************************
* *
* Do not rebalance because the tree structure is unchanged. *
* *
********************************************************************/
*balanced = 1;
}
}
}
return 0;
}
/****************************************************************************
* *
* --------------------------------- hide -------------------------------- *
* *
****************************************************************************/
static int hide(BisTree *tree, BiTreeNode *node, const void *data) {
int cmpval,
retval;
if (bitree_is_eob(node)) {
/**************************************************************************
* *
* Return that the data was not found. *
* *
**************************************************************************/
return -1;
}
cmpval = tree->compare(data, ((AvlNode *)bitree_data(node))->data);
if (cmpval < 0) {
/**************************************************************************
* *
* Move to the left. *
* *
**************************************************************************/
retval = hide(tree, bitree_left(node), data);
}
else if (cmpval > 0) {
/**************************************************************************
* *
* Move to the right. *
* *
**************************************************************************/
retval = hide(tree, bitree_right(node), data);
}
else {
/**************************************************************************
* *
* Mark the node as hidden. *
* *
**************************************************************************/
((AvlNode *)bitree_data(node))->hidden = 1;
retval = 0;
}
return retval;
}
/****************************************************************************
* *
* -------------------------------- lookup ------------------------------- *
* *
****************************************************************************/
static int lookup(BisTree *tree, BiTreeNode *node, void **data) {
int cmpval,
retval;
if (bitree_is_eob(node)) {
/**************************************************************************
* *
* Return that the data was not found. *
* *
**************************************************************************/
return -1;
}
cmpval = tree->compare(*data, ((AvlNode *)bitree_data(node))->data);
if (cmpval < 0) {
/**************************************************************************
* *
* Move to the left. *
retval = lookup(tree, bitree_left(node), data);
}
else if (cmpval > 0) {
/**************************************************************************
* *
* Move to the right. *
* *
**************************************************************************/
retval = lookup(tree, bitree_right(node), data);
}
else {
if (!((AvlNode *)bitree_data(node))->hidden) {
/***********************************************************************
* *
* Pass back the data from the tree. *
* *
***********************************************************************/
*data = ((AvlNode *)bitree_data(node))->data;
retval = 0;
}
else {
/***********************************************************************
* *
* Return that the data was not found. *
* *
***********************************************************************/
return -1;
}
}
return retval;
}
/****************************************************************************
* *
* ----------------------------- bistree_init ---------------------------- *
* *
****************************************************************************/
void bistree_init(BisTree *tree, int (*compare)(const void *key1, const void
*key2), void (*destroy)(void *data)) {
/****************************************************************************
* *
* Initialize the tree. *
* *
****************************************************************************/
bitree_init(tree, destroy);
tree->compare = compare;
return;
}
/****************************************************************************
* *
* ---------------------------- bistree_destroy -------------------------- *
* *
****************************************************************************/
void bistree_destroy(BisTree *tree) {
/****************************************************************************
* *
* Destroy all nodes in the tree. *
* *
****************************************************************************/
destroy_left(tree, NULL);
/****************************************************************************
* *
* No operations are allowed now, but clear the structure as a precaution. *
* *
****************************************************************************/
memset(tree, 0, sizeof(BisTree));
return;
}
/****************************************************************************
* *
* ---------------------------- bistree_insert --------------------------- *
* *
****************************************************************************/
int bistree_insert(BisTree *tree, const void *data) {
int balanced = 0;
return insert(tree, &bitree_root(tree), data, &balanced);
}
/****************************************************************************
* *
* ---------------------------- bistree_remove --------------------------- *
* *
****************************************************************************/
int bistree_remove(BisTree *tree, const void *data) {
return hide(tree, bitree_root(tree), data);
}
/****************************************************************************
* *
* ---------------------------- bistree_lookup --------------------------- *
* *
****************************************************************************/
int bistree_lookup(BisTree *tree, void **data) {
return lookup(tree, bitree_root(tree), data);
}
|


lib
/
com.github.thibaultbee.srtdroid.enums
/
SockStatus
/
BROKEN
BROKEN
BROKEN
The socket was connected, but the connection was broken.


Dear Mediville Client,
This is your authentication link to mediville buyer dashboard
Please Go to Buyer Dashboard To access your orders.
Alternatively, you can paste the following link in your browser's address bar:
{{ link }}
Sincerely,
The {{ config.APP_NAME }} Team
Note: replies to this email address are not monitored.


SDOF system response to Impulsive Loads
An impulsive load is characterized by a short duration and is usually analyzed under the assumption of negligible effects of damping.
Simple analytical solutions can be given for an half-sine impulse, a rectangular impulse and a triangular impulse.
The results of our analyses can be summarized in a shock-spectrum, a graph of the peak values of the response ratio.
For really short impulse a very good approximation to the peak response is given by a simple formula, based on an approximation to the value of the system's momentum.
Intro to Step by Step methods
We are able to compute numerically the response of a SDOF using either the Duhamel integral or the frequency response function plus the DFT, but these methods hold only for linear systems, being based on the superposition of effects. Many applications require taking into account different sources of non-linear behaviour. A reasonable solution is given by the use of linear methods to compute the solution in a short time step, during which the characteristics of the system can be held constant.
It is recognized that if we want to restart our computations in a generical moment, we have to know the position AND the velocity of our linear system. These two quantities are said to constitute a state vector of the linear system. For a non-linear system, the state vector must be augmented with some other info, e.g., plastic deformation, cumulated plastic deformation, etc.
A simple step-by-step method is the so called piecewise-linear method: the loading is assumed to have a linear behaviour during a time step, identified by its initial and final values, so that the state of the system at the end of the current step can be computed in terms of these two values and of the initial state.
Materials available for this class:
- the slides i used for my lesson
- a ready to print version of the slides,
- a notebook with the exercise about the free vibration of an elastoplastic SDOF, both a print-out and a static rendering of the same material (note that you can download the notebook using the page toolbar),
- a notebook with the aliasing example, both a print-out and a static rendering in the browser.


{empty name="uid" } {include file='../application/common/view/IndexHeader.html' /} {else/} {include file='../application/common/view/Header.html' /} {/empty}
{block name="container"} {/block} {empty name="uid" } {include file='../application/common/view/IndexFooter.html' /} {else/} {include file='../application/common/view/Footer.html' /} {/empty}


NOM
Search
Recipes
Restaurants
Recipes for
Pizza
Arugula Margherita Pizza
Take me to the NOM
Basil and Strawberry Summer Pizza
Take me to the NOM
Garlic Canadian Ham Pizza
Take me to the NOM
Roasted Heirloom Galette
Take me to the NOM
Green Olive Prosciutto Pizza
Take me to the NOM
Roasted Rosemary Three Cheese Pizza
Take me to the NOM


Icloud Activation Bypass Tool V1 4 Review
Icloud Activation Bypass Tool Version 1 4 Download Review
An Impartial Review Of Icloud Activation Bypass Tool V1 4
Icloud Activation Bypass Tool Version 1 4 Review Guide And Alternative
Download Icloud Activation Bypass Tool V1 4 Phones And Computers
The Right Way To Bypass The Icloud Activation Lock By Doulci Medium
Icloud Bypass Tool Download Mac Peatix
Ios 13 4 Icloud Bypass By Ulap Bypass Tool V1 5 4 Youtube
Top 14 Best Icloud Bypass Activation Lock Removal Tools 2021
Icloud Activation Bypass Tool V 1 4rr Unlock Iphone Free Unlock Iphone Iphone Unlock Code
Icloud Bypass Tool Download Mac Sitebud
Icloud Activation Bypass Tool Latest Version Download Xdarom Com
Icloud Lock Bypass Tool Page 3 Line 17qq Com
All In One Icloud Bypass Tool V1 0 Free Download For Windows Computer Cruzersoftech
Icloud Bypass Tool Mac Download Peatix
Working 14 Best Icloud Bypass Activation Lock Removal Tools 2020 No 1 Tech Blog In Nigeria
Iphone Activation Lock Bypass Tool Download Amashusho Images
Download Icloud Remover Tool 2020 Bypass Unlock Icloud Activation Free Mygsmtech All Gsm Solutions In One Place
Icloud Bypass Tool Icloud Activation Lock Bypass Service For All Apple Devices
Icloud Activation V4 1 4 Icloud Activation Youtube
Icloud Activation Bypass Tool Version 1 4 Download
All In One Icloud Bypass Tool V1 0 Supported Windows Free Download
New Version Of Icloud Bypass Tool Bypass Icloud In Full Free Fix Everything 100 Working
Icloud Unlocker V1 01 Latest Icloud Unlock Tool 2020 Free Download
Icloud Activation Bypass Tool Version 1 4 Download For Mac Beastwestern
Icloud Bypass Tool V1 4 Download Peatix
Downloadicloud Bypass Ios 12 4 3 13 3 Windows Shiftkey Tool File Information File Name Icloud Bypass Ios 12 4 3 13 Icloud Windows Computer Email Software
Free Windows Tool To Bypass Icloud Ios 13 3 By Shiftkey All About Icloud And Ios Bug Hunting
Ios 14 Icloud Bypass Untethered Windows 10 Free Iphone Activation Unlock Tool 99media Sector
Bypass Icloud Activation Lock Ios 14 Irogerosx Tools Free Download


@()(implicit request: RequestHeader, messages: Messages)
Already have an account?
Hi,
Keep track of your expenses.


Cloud Vision V1 API - Class Google::Cloud::Vision::V1::AnnotateFileRequest (v0.6.4)
Reference documentation and code samples for the Cloud Vision V1 API class Google::Cloud::Vision::V1::AnnotateFileRequest.
A request to annotate one single file, e.g. a PDF, TIFF or GIF file.
Inherits
- Object
Extended By
- Google::Protobuf::MessageExts::ClassMethods
Includes
- Google::Protobuf::MessageExts
Methods
#features
def features() -> ::Array<::Google::Cloud::Vision::V1::Feature>
- (::Array<::Google::Cloud::Vision::V1::Feature>) — Required. Requested features.
#features=
def features=(value) -> ::Array<::Google::Cloud::Vision::V1::Feature>
- value (::Array<::Google::Cloud::Vision::V1::Feature>) — Required. Requested features.
- (::Array<::Google::Cloud::Vision::V1::Feature>) — Required. Requested features.
#image_context
def image_context() -> ::Google::Cloud::Vision::V1::ImageContext
- (::Google::Cloud::Vision::V1::ImageContext) — Additional context that may accompany the image(s) in the file.
#image_context=
def image_context=(value) -> ::Google::Cloud::Vision::V1::ImageContext
- value (::Google::Cloud::Vision::V1::ImageContext) — Additional context that may accompany the image(s) in the file.
- (::Google::Cloud::Vision::V1::ImageContext) — Additional context that may accompany the image(s) in the file.
#input_config
def input_config() -> ::Google::Cloud::Vision::V1::InputConfig
- (::Google::Cloud::Vision::V1::InputConfig) — Required. Information about the input file.
#input_config=
def input_config=(value) -> ::Google::Cloud::Vision::V1::InputConfig
- value (::Google::Cloud::Vision::V1::InputConfig) — Required. Information about the input file.
- (::Google::Cloud::Vision::V1::InputConfig) — Required. Information about the input file.
#pages
def pages() -> ::Array<::Integer>
-
(::Array<::Integer>) — Pages of the file to perform image annotation.
Pages starts from 1, we assume the first page of the file is page 1. At most 5 pages are supported per request. Pages can be negative.
Page 1 means the first page. Page 2 means the second page. Page -1 means the last page. Page -2 means the second to the last page.
If the file is GIF instead of PDF or TIFF, page refers to GIF frames.
If this field is empty, by default the service performs image annotation for the first 5 pages of the file.
#pages=
def pages=(value) -> ::Array<::Integer>
-
value (::Array<::Integer>) — Pages of the file to perform image annotation.
Pages starts from 1, we assume the first page of the file is page 1. At most 5 pages are supported per request. Pages can be negative.
Page 1 means the first page. Page 2 means the second page. Page -1 means the last page. Page -2 means the second to the last page.
If the file is GIF instead of PDF or TIFF, page refers to GIF frames.
If this field is empty, by default the service performs image annotation for the first 5 pages of the file.
-
(::Array<::Integer>) — Pages of the file to perform image annotation.
Pages starts from 1, we assume the first page of the file is page 1. At most 5 pages are supported per request. Pages can be negative.
Page 1 means the first page. Page 2 means the second page. Page -1 means the last page. Page -2 means the second to the last page.
If the file is GIF instead of PDF or TIFF, page refers to GIF frames.
If this field is empty, by default the service performs image annotation for the first 5 pages of the file.


Recently we have been thinking about what changes and new features would be good to have in the new version of the emonTx.
The general idea is that the next version will be pre-assembled with SMT electronics, we plan to keep the current features such:
- Arduino compatible Atmega 328 running at 3.3V
- RFM12B wireless
- 3 x CT channels
- Pulse counting - digital I/O
- low power
New features we are considering adding are:
Wireless:
- Xbee socket option, could also be used for WiFly Rover networks wifi module or XRF for extra range– RFM12B will still be the default wireless option.
- Option to use SMA antenna
Sensor connections:
- Terminal blocks for connecting eight DS18B20 temperature sensors - horizontal insertion?
Indication & buttons:
- Tri-colour indicator LED – green = good, red = bad (low battery etc..)
- Push button to be configured for pairing
- Reset button?
Power
- 3.7V Lipo battery compatibility – with USB charging (MAX1555 / MCP73833 or MCP73871 control IC?) JeeNode example, adafruit example
- Option to power from mini solar panel for remote installations - Adafruit example - need to check that switching frequencies from DC-DC converters don't interfere with analog CT readings.
- Option to fix 2xAA battery holder onto rear of PCB
Casing
Size the PCB to slide into an aluminum case such as the one below. An acrylic/ply-wood fascia can then easily be laser cut the accommodate the ports. See blog post on embodied energy of Aluminium Vs ABS plastic:
It would be great to hear your thoughts on our ideas.....
Re: emonTx New Version Dev Ideas
My opinion is that remote sensors must be as cheap as possible and the fancy staff will be at the internet-connected module - a Raspberry Pi for example. The WiFi or Zigbee stuff is good, but pricey and I personally wouldn't use it. I'd love to see dedicated micro sensors (attiny series) all around the house reporting things to the Raspberry Pi. Hopefully, there will be a LAMP port for it one day and it may host emoncms as well, so no need to have external hosting.
Re: emonTx New Version Dev Ideas
Yeah I agree, the idea we have is to add an Xbee holder onto the board but by default this would be un-populated, RFM12B is the cheapest option. We are trying to make the hardware as flexible and future proof as possible.
Re: emonTx New Version Dev Ideas
I really like the idea of adding more DS18B20 sensors. Is it worth exploring if other environmental sensors could be added as well or does that change the intention for the project? thinking of a counting module? humidity?
Re: emonTx New Version Dev Ideas
I like the idea of a IR sensor to read the data from electric meters with IRDA senders in them
Re: emonTx New Version Dev Ideas
I also think the aluminum casing suggested in post one will act as a shield to RF waves and may reduce and even cease signals. Give it a try.
Re: emonTx New Version Dev Ideas
Could you use the case as an aerial? Or is that a crazy idea as im finding the range of the current RF to be VERY small. Eg through 1 wall only.
Humidity sounds like a great idea although it may have to be a remote sensor not built on this maybe better suited to the GLCD. The DHTXX are worth a look at, iv got a couple im using to monitor inside and outside.
Gas meters. Could this be done. If were trying to monitor our energy consuption gas should be a part (although this may be a problem with regs)
Re: emonTx New Version Dev Ideas
I would like to see more CT input channels. The Brultech http://www.brultech.com/ energy monitor has 7 inputs and they are developing a new model with 32. More input channels allow you to monitor every individual circuit in your house.
Re: emonTx New Version Dev Ideas
I like this IR sensor idea but most times the emonTx will be a good distance from the electric meter. Anybody know how far you could run the wires and still get a good pulse from the IR sensor?
Re: emonTx New Version Dev Ideas
Here is what I think is the future for remote sensors, here is one temperature sender using ATTiny85's internal temperature sensor and RFM12B on the bottom; The PCB and schematic seem different from the end product but the idea is nice, coin cell sized battery operated remote sensor. Give that I2C connectivity (supported by Attiny84) and it is irresistible
http://olivier.gelux.ch/?q=taxonomy/term/41:
Re: emonTx New Version Dev Ideas
Leaving out the burden resistor in SMD but keep the possibility to add it later on for using different types of CT would work for me.
Re: emonTx New Version Dev Ideas
1 extra CT-sensor would be great, you could use, 3 for mains consumption (one per fase) and one for a PV system. An rs232/485 port for communication with an invertor would be a big plus. The tri-color led is a good feature to expand the feedback possibilities om the print.
A DIN-rail housing might be handy to use, it would fit into a household switchboard/fusepanel, and has lots of possibilities for connectors etc.
Re: emonTx New Version Dev Ideas
Thank you for all the ideas. Sorry for the delay in posting, Trystan and I have been travelling this last week. We now have stable internet, normal operation is resumed!
Case and antenna:
The idea is that we external SMA whip antenna would be used with the aluminium case. Such as http://cpc.farnell.com/jsp/level5/module.jsp?moduleId=cpc/407338.xml, that way the case won't effect the signal. I think the range could be improved be using a whip antenna since it's RF output is helical not as much RF power is lost upwards and downwards. We have had a bit of a debate going regarding the embodied energy in Aluminium, I did a blog post on this last night: http://openenergymonitor.blogspot.com/2012/05/embodied-energy-of-electronic-enclosure.html
Sensors:
Humidity sensors are interesting, I have experimented using the DHT11 humidity sensor, this sensor requires 3-5V and a single data line pulled high with a 5K resistor. It wouldn’t be difficult to wire in the sensor either into a JeePort or the pulse counting I/O. I'm not sure if humidity is important enough to merit it's own dedicated port on the emonTx.
Form factor:
I like the idea of lots of low power, small and cheap sensors such as the design posted by mharizanov. This form factor would be ideal for a distributed wireless temperature network. The emonTx however will need to larger to accommodate the number of I/O ports required.
Burden Resistor:
Great idea posted by prensel regarding having an interchangeable burden resistor for different CT's and measurement ranges. I think the best compromise is to have an SMT burden resistor and include the holes and pads to solder in a thru-hole burden resistor and de-solder the SMT if required.
Number of CT channels:
I think three is a good number, we haven’t really needed extra channels, the limiting factor is board space for any extra 3.5mm jacks, more channels would also increase the cost and probably only be utilised by a few users. If more channels are required it's quite easy to have multiple emonTx's on the same network. If there is free space I'll see if it's possible to squeeze one extra channel on.
Re: emonTx New Version Dev Ideas
Or even easier: a cuttable re-solderable link to the SMT burden.
(N.B. Bad link to the aluminium case blog).
Re: emonTx New Version Dev Ideas
Yup that would be even better. I think I will also do the same for the DS18B20 temperate pull up and pulse counting pull down resistors to add the flexibility of changing their values.
Link has been fixed, thanks.
Re: emonTx New Version Dev Ideas
There are cases where an ethernet port is available next to where emonTx is installed. We can avoid the RF link and have the footpring for an ethernet module like this one on emonTx: http://de.mouser.com/ProductDetail/WIZnet/WIZ820io/?qs=b%252bXOOdUOuvbhJrgcuv9kFavdJpKDMM33eUcvAcab6Bc%3d
it's just 12 pins = two 6pins headers
Re: emonTx New Version Dev Ideas
That's a great idea! I like that little Wiznet module. It's used on the Open Kontol Gateway, it's really tidy. Adding the headers will keep the connectivity options open with no extra cost.
Cheers Amin.
Re: emonTx New Version Dev Ideas
It would also be great to breakout two or three digital outputs (with PWM) on the side of emonTx board to screw terminals. I know the firmware does not allow it now, but we could add code in the future that makes it possible to control external relays mounted in the electrical box.
Re: emonTx New Version Dev Ideas
I agree that adding terminals or solder pads for other I/O would be good. Personally I am trying to use a digital input for monitoring pulses from a water meter (to record hot water usage), and a couple of inputs for temperature and humidity (inside and outside) so the system can calculate dew point and indicate when best to open windows as the humidity drops outside.
Re: emonTx New Version Dev Ideas
Rather than the aluminium case, could you use a PSU 'wall-wart' case (Like Maplin N04KH) and hack a 5V PSU from a phone charger into it, leaving space on a second level for the TX board.
Re: emonTx New Version Dev Ideas
I fancy the optional wireless header & Ethernet suggestion :)
But this kind of imposes equivalent upgrades to the emonBase and emonGLCD, right?
For power I'm planning on using Seeed Studio's Lipo Rider Pro, while there is no integrated solution. If you want, I can perform some tests to verify any impact resulting from interference caused by the DC-DC boost converter. However I don't predict any visible impact, since we already power our emon devices with switched-mode power supplies. Unless the proximity of such circuitry could have a different impact.
Four CT channels would be awesome, but please clarify, were these CT channels designed to separate energy consumption by type, rather than by phase? i.e. lighting / heating / devices within the *same* phase
I'm concerned as to how I can measure power usage on 3 distinct phases accurately, when we only have one AC input from the AC-AC transformer (Each phase has its own fluctuating voltage. Is my assumption correct?). And if space is a concern for an extra CT connector, I can't begin to imagine if we talked about extra AC inputs. But then again, I don't have three outlets installed next to each other and each with a different phase; maybe one needs to place the outlets right in the electrical board, and plug the transformers there?
I'm building the current version of emonTx very soon, it's probably best that I avoid further commenting before I spend some time with it ;)
Re: emonTx New Version Dev Ideas
Yes, in the ideal world where everything is perfectly balanced, all three phase voltages would be the same. But in the real world you are correct, different loads on different phases will cause the three line voltages and the neutral voltage to move relative to each other and to earth.
I imagine few people do. I would have concerns over safety in a domestic environment with up to 440 V between any two lines.
Re: emonTx New Version Dev Ideas
Hi!
I have recently buyed an Emontx + Nanode, and my goal is to measure currents and all the data possible on three phase installation in order to have the system in more "professional way".
I'm not sure if hardware will permit this, or maybe there's the need of small hardware tweaks, maybe one transformer and CT for each phase??
Regards, and excuse my English
Re: emonTx New Version Dev Ideas
To accurately measure voltage, current, real and apparent power on each of 3 phases you need to have 3 voltage inputs and 3 current inputs, therefore 3 voltage adapters and 3 CTs.
The EmonTx does not have the necessary 3 voltage inputs. But two analogue inputs are not used - ADC 4 on pin 27 and ADC5 on pin 28, I think it would be possible for you to repeat the circuit components that measure voltage (R11, R12, R13, R14, C10) two times on an external board and connect to these pins. I have to tried to do this, so I do not know whether it would work.
[Edit]
I modified a copy of EmonLib and wrote a test sketch to measure the voltages on ADC4 and ADC5 - these are available as SDA and SCK on the PWR/SER/I2C header on the EmonTx board. To test, I placed a jumper wire between P3 - AIO2 (the voltage input) and SDA or SCK, and I read the correct voltage. So I think it will work.
Re: emonTx New Version Dev Ideas
Hi Robert
Hi have the needed components to make two extra inputs, if my work permit I will try to duplicate the inputs and see...
Many thanks!
Re: emonTx New Version Dev Ideas
You will of course need to make a copy of EmonLib and edit it to (a) add the correct input pins for the new voltage inputs and (b) pair them with the correct CT to calculate the powers, possibly each with its own calibration factor and phase angle correction.
Re: emonTx New Version Dev Ideas
Am I right that in Europe (well, the UK specifically), we only need one voltage input (alongside the current measurement) in order to calculate real power from apparent?
Re: emonTx New Version Dev Ideas
You are right
Re: emonTx New Version Dev Ideas
The ultimate emonTx would have headers for an ethernet module, digital programmable outputs (screw terminals) but also something very important: I think there should be the possibility to connect up to 3 emonTx slaves to an emonTx master that would have ethernet connectivity.
This is the case for example when you have a massive circuits breakers board and you want to install more than 4 CTs, then one emonTx would have Ethernet (or maybe RFM12B), one AC voltage sensor, and would be connected over I2C to 1, 2 or 3 other emonTx's. The master would measure Vrms, 4CT's and communicate the Vrms value over I2C to slaves.
Slaves would have up to 4 CT's connected to them, no connectivity options other than the I2C communication with the master. This would take only two pins and one resistor.
Five connections must be made between the master and the slaves: SCL, SDA, GND, Vin and reset. I can imagine that a normal RJ 45 connector would be suitable.
With this we can have a very modular system that is also suitable for bigger installations
Re: emonTx New Version Dev Ideas
Hi, first post on the forum. I have been following your project for some time as I am searching for a good way to monitor my total energy use and production (PV panels on the roof). So far I have not yet found the perfect solution, so may I add some ideas for the next emonTx.
Additional pulse inputs
This would be great to measure all energy use. At least in the Netherlands we have a sort of 'E-closet' where electricity, gas and water enters the home. The last 2 can best be measured using pulse sensors. Additionally a pulse input could be used to differ between high and low electricity tariff, if applicable for some people (including myself).
So in short: 3 pulse inputs would be well appreciated
Offline local storage
Using a SD-card on the emonTx would give the opportunity to store the data locally, have it run fully autonomously, and retrieve data later. Possible setup could be like making data-files for each day, read those files on a local networked computer once a week and input that in a database. So no live view (which can be retained using the RFM12B anyway), but data-processing later.
Retain 1 open Jeeport
Jeelabs has wonderfull extension plugs available. If you could leave one Jeeport open, people can extend the emonTx with these plugs as required.
So far for my ideas. Any comments are appreciated.
Re: emonTx New Version Dev Ideas
I'm interested in helping out with the hardware. Let me know if you want anything tested or prototyped.
Matt
Re: emonTx New Version Dev Ideas
Hey people,
I needed an SMD version of emonTx, but with an ATMega 328, arduino shields compatibility and 4 CT's, so the new A32u4 based emonTx doesn't suit my needs.
This is my attempt to make an SMD emonTX with my above requirements (see attached schematics and board). I still need to include a master-slave method to interconnect several emonTx's, but I alreay had a hard time routing this board. It is more like an exercice to get a working SMD microcontroller design. All credit goes to the Arduino team, Trystan, Glyn and JCW of Jeelabs.
My final board will probably have a different layout and a master-slave bus.
If you have any comments or suggestions please share them :)
Re: emonTx New Version Dev Ideas
Very nice board, I would like to have one (I need 4 CTs)!
One question:
- how is the WIZ820 powered when it is mounted? I think it draws quite a lot of current (>100mA?). The power dissipation can possibly not be handled by the SOT23 version of MCP1703 and R5 would also prevent this.
Regards, Jörg.
Re: emonTx New Version Dev Ideas
Hey Jörg,
I also had my doubts about that, even though the datasheet says it can supply up to 200mA. I'll get one pcb made and test it, then maybe I'll have to choose another regulator or another resistor.
Now that I think about it, so you think another package than 0603 is more suitable for that resistor?
Re: emonTx New Version Dev Ideas
The original value of R5 56 Ohms was calculated for the Emontx power consumption without the extra 100mA of the WIZ820. Since the input is AC, C5 has to deliver the consumed current for roughly one periode means 20ms, until it is recharged again. The values for C5, R5 have to be recalculated for the much higher consumption with the WIZ820 module. This also depends on the voltage of the wall transformer.
Question is if the distortion of the input voltage is still within acceptable limits then. Perhaps Glyn could test this with his LTSpice simulation.
For the MCP1703 you could choose the SOT223 package which has a much lower thermal resistance and try to dump as much heat as possible into the GND plane.
Re: emonTx New Version Dev Ideas
I think my post here is on the same topic: http://openenergymonitor.org/emon/node/736#comment-5623. Good effort Amin, I'll get back to you with my thoughs on your design soon. Sorry, things are very busy at the moment. I need to get some sleep now.
Re: emonTx New Version Dev Ideas
Hello Joerg,
your guess was right! Even with an R5 value of 10R and a C5 of 470uF the MCP 1702 (that's what I'm using, but I didn't have the corrsponding eagle part), this power supply can not provide more than 126mA, which is too little.I noticed that the waveform distortion is not that important (very negligeable actually) even with a 126mA load. I have doubts that this is wrong.
I think a full wave rectifier design is necessary to power the extra modules (ethernet, etc), I'll do some reading and try to come up with an acceptable design.
I will share it here on the forum, or on a new topic. All help is appreciated, since I didn't do this before.
Re: emonTx New Version Dev Ideas
Main dilemna now is the choice of a regulator: Low-dropout regulator, or switching regulator. The latter heats up less, which may be a decisive factor here.
Any thoughts?
Re: emonTx New Version Dev Ideas
This regulator seems to be adequate: STMicroelectronics LF33CDT (Datasheet)
Especially these characteristics:
Output current: up to 500mA
Input voltage:16V
Should do the trick with a full wave rectifier no?
Re: emonTx New Version Dev Ideas
Amin Zayani
You cannot go to a full-wave rectifier without one of:
If you try to use a single winding transformer and a bridge rectifier, one way or another you end up shorting part of the bridge. (That's what Mark Beal's circuit, that was picked up and promoted elsewhere, did, with as a consequence a voltage wave that bore little resemblance to what came out of the power station!).
The whole purpose of the single supply was to remove the need for those things and the separate 5 V supply. If you want to have a high-powered radio or Ethernet, or multiple temperature sensors, then the single supply is simply not appropriate and was never intended for that purpose.
Re: emonTx New Version Dev Ideas
Amin,
the LF33 is a good choice although with a much higher quiescent current than the MCP1702. It is easy to use, does not need too much C on the output and the package allows for easy cooling.
If you want to keep the MCP1702 you could just use a second one for powering the WIZ820.
But Robert is certainly right with his remarks regarding the limitations of the single supply (and that the full wave rectified version will not work).
Re: emonTx New Version Dev Ideas
Robert, Joerg,
thanks for your comments. I am aware of the complications of using a full wave rectifier design, I'll try to find a center tapped design for later versions, for the moment back to the drawing board with 2 MCP 1702 in mind. I'll post my simulation files tomorrow.
Re: emonTx New Version Dev Ideas
Your problem will be finding a centre-tapped adapter. Your alternative is an on-board transformer that needs to remain well out of saturation at the UK maximum voltage of 253 V, and then you still have the attendant clearance problems etc.
Re: emonTx New Version Dev Ideas
.... with 2 MCP 1702 ...
I think this is a good idea (well known parts, keeps the number of different parts low, scalable, etc.). And please give them a bit of copper area (connected to one or several pins) where they can sink the heat. GND plane can also be used for this. Keeping the temperature low improves reliability and reduces output voltage drift.
Re: emonTx New Version Dev Ideas
This is my last attempt with only one MCP1702:
R5= 10 R, C1= 470uF and that should be good for a load of 120mA as shown in the simulation graph:
The AC adapter I use supplies up to 830mA so it shouldn't be the bottleneck. I just need to choose the right resistor, capacitor, and regulator packages for such an application.To my surprise, the waveform is not very much disturbed. Any thoughts on this one?
I uploaded the LTspice file (credt goes to Glyn) here if you need to experiment with it.
I have another thought in mind: what happens if a DC adapter is connected instead of AC? My educated guess is that it will also work properly. What do you think?
Re: emonTx New Version Dev Ideas
"what happens if a DC adapter is connected instead of AC? My educated guess is that it will also work properly."
Sorry, a bad guess and wrong. If you rectify the a.c., you won't be able to tell the difference between imported and exported power because you won't know the relative phase of voltage and current. And if your d.c. supply has a smoothing capacitor inside (most have), you've lost the ability to calculate true power too (for that, you need the average of the product of instantaneous voltage and current).
So you have at best a voltage that has some relationship to the peak voltage, and you can only get an estimate of VA with no knowledge of whether it's import or export.
"To my surprise, the waveform is not very much disturbed." - Yes, that's because you are taking the same energy over a longer time and drawing a lower current, hence the internal drop in the transformer (from both copper and iron) is less. A higher VA rating helps here with a lower source impedance, but it has no connection with the inherent distortion of the voltage waveform that arises from saturation effects in the tranformer core.
Re: emonTx New Version Dev Ideas
"Sorry, a bad guess and wrong. If you rectify the a.c., you won't be able to tell the difference between imported and exported power because you won't know the relative phase of voltage and current. And if your d.c. supply has a smoothing capacitor inside (most have), you've lost the ability to calculate true power too (for that, you need the average of the product of instantaneous voltage and current). "
That much is clear Robert :) I meant for the power supply. The board will be powered without problems, and it will be a current only monitor.
Re: emonTx New Version Dev Ideas
Amin,
this was also how I understood your question. You just have to make sure that + is on the right contact and that the power dissipation will be roughly doubled (if you use a wall supply with the same DC voltage as AC RMS).
And then, I am also suprised that the waveforem is not very much disturbed! I understood from Glyns post that 20mA will be the maximum before distortion will make the circuit useless?!? How does this fit together? (and this has absulutely nothing to do with transformer saturation at higher voltages?!?)
Re: emonTx New Version Dev Ideas
Sizing R5:
It seems to me that the maximum possible power dissipated by R5 is the maximum voltage times the max current (to stay on the safe side), so R5 should be able to handle 3.5W heat dissipation. It was impossible for me to find an SMD resistor that can dissipate so much heat, my options are:
Re: emonTx New Version Dev Ideas
Amin Zayani
I must be missing something! The whole purpose of the single supply was to give the option of a minimal performance 'bare bones' emonTx measuring real power without the need for both a.c. and d.c adapters. If you need more options that draw more power, then a separate d.c. supply was always envisaged. That's what the optional break / link on Glyn's layout is for!
If your extras need more current, or for another reason you do not want the single supply option, then you have no need to worry about R5, you leave it out and feed a clean smoothed d.c. supply across C1, and use the a.c. adapter for the voltage reference only.
JBecker
The specification was indeed for 20 mA - the ATmega328 and RFM12B at 14mA when the RF12B is transmitting, and 2.3 mA each for two DS18B20 temperature sensors. The components were chosen so that at that current and the minimum theoretical supply voltage and worst case component tolerances, the MCP1702 just ran out of headroom and failed to regulate. The distortion on the voltage sample was deemed acceptable, the harmonics introduced are around 1% and the change in rms value is minimal (or to put it another way, I could not discern a difference in the rms voltage readings when the supply was loaded with 20 mA and when it was not - the difference was swamped by normal fluctuations in the mains voltage, so in practice it is likely to be quite immaterial).
Re: emonTx New Version Dev Ideas
R5: I think I'll go ahead with such a 5W resistor:
and I simulated the thermal dissipation of the MCP 1702 at 120mA load, it should be around half a watt:
So I think I'll go with a TO92 package for this first try and clean up all this later.
Re: emonTx New Version Dev Ideas
Robert,
thanks for making the reason for 20mA clear. This is more or less as I understood it. More current can be drawn (with different component values) but distortion will certainly increase, possibly up to a level where everybody has to decide for himself if it is still acceptable for his purpose.
And you can clearly see in Amins simulation that the voltage drop in large parts of the positive halfwave is considerable. All this might 'average out' with calibration but will for sure increase the overall measurement error.
BR, Jörg.
PS: I understand Amins question regarding DC supply in that way that he wants to be able to use the exactly same hardware with AC and DC wall adapters (off course without voltage measurement with the DC adapter).
Re: emonTx New Version Dev Ideas
Could I make a request please for any future re-design of the EmonTX to have more space around the screw holes?
The current EmonTX board does not have sufficient clearence around the holes for an M3 nut plus spanner, making fixing it with nuts/bolts very tricky.
Thanks,
Martin
Re: emonTx New Version Dev Ideas
Hi Martin,
I've also had this problem, I'll fix it in future designs.
Thanks for flagging it up.
All the best,
Glyn.
Re: emonTx New Version Dev Ideas
I think the shop needs to stock 8BA mounting kits, because the holes in the existing are 3/32" diameter and that's 8BA clearance size
(For the metrically inclined, 8BA is between M2 and M2.5)
Re: emonTx New Version Dev Ideas
Something else you might consider:
The original emonTx has no over-voltage protection on the CT inputs. What happens if the CT sees a current of more than 100A? Or in fact, any current great enough for the voltage across the burden resistor to exceed Vcc/2? This will pull the analog input on the CPU outside the 0-Vcc allowed range.
The Atmel datasheet states that the absolute max voltage an any pin is from -0.5 to Vcc + 0.5.
This leads me to believe that it would rather easy to destroy the CPU if there was a current surge caused by a fault somewhere.
This would be especially true if using a larger burden resistor in order to increase the resolution when using the CT on a circuit with a smaller design current. E.g. on a PV inverter, the max expected current might be only 16A not 100A, it would be reasonable to scale up the burden resistor to match.
With the new design, if the op-amp is powered off the 3.3V supply, then I guess this is fine. If powered of 5V, then this could easily drive the analogue-in line above the 3.3+0.5 limit (assuming its output can swing up to the supply), when used on one of the higher gain settings.
Have you considered this? Should you add a couple of diodes to ov and Vcc to limit the swing?
Martin
Re: emonTx New Version Dev Ideas
You can probably ignore my last comment! I just check the specs of the lmv324, and I assume that you must be running it from 3.3 volts, so it can't possible over-drive the input.
However, the observation about the lack of over-voltage protection on the non-smd emonTx design still holds.
Re: emonTx New Version Dev Ideas
I drilled my holes out to 3mm (from 2.5) 'cos I only has m3 nuts/bolts to hand, and some m3 stand-offs. Then I discovered that the nuts were too big!
Re: emonTx New Version Dev Ideas
I think you need to consider the characteristics - particularly the VA rating - of the c.t., and the circuit around it. We know what happens when the c.t. sees a current up to 250 A (been there, done that!) and we know what happens when the burden is changed from the recommended value (been there, done that too!). And it's all documented.
That assumes a voltage source of sufficiently low impedance. Yes, it might over-volt the input, but the current available is just within the maximum current for the internal protection diodes. A simple series resistor of a couple of thousand ohms will limit the current to a safe value under all circumstances that I've been able to envisage.
No, it wouldn't be reasonable, again because the c.t. has a limited VA rating and you will overload the c.t. if you increase the burden resistance too much. (And before you point out the 30 A c.t. with the internal burden, I believe - but don't have evidence - that this is the same part as the 100 A, but with a burden resistor added).
But not any old diodes. They'd need to be Schottky to assure that they would take the lion's share of the current. A series resistor is cheaper and simpler (but maybe not as a retro-fit).
Re: emonTx New Version Dev Ideas
I just check the specs of the lmv324, and I assume that you must be running it from 3.3 volts, so it can't possible over-drive the input.
If supplied with 3.3V the upper level of the common mode input range is limited to 2.5V!! So be careful not to 'overdrive' the input.
Re: emonTx New Version Dev Ideas
My point was that we need to be careful not to over-drive the AtMega analogue input. A lmv324 run from 3.3 volts can't do that. The op-amp (and anlogue switch) input itself is probably safe from damage from an over-driven CT due to the series resistors.
The common-mode input voltage operating point is set at Vcc/2 which will be 1.65V. The high open-loop gain of the op-amp and feedback network will ensure that the op-amp input pins won't move much from that.
So in other words, it will work fine.
It's not so clear-cut with the old emonTx design, where the CT burden resistor is connected directly to the CPU with no series resistor or protection diodes or anything. Here, it looks as if we are relying on the CT secondary saturation current being small enough to be safely handled by the CPU's built-in protection diodes. It may be just-about ok with the standard 100A CT, but it's not a great piece of design in my opinion.
Martin
Re: emonTx New Version Dev Ideas
Martin,
fully understood and agreed. My remark was just meant as a general warning regarding the LMV324 (possibly a bit off-topic for the subject of this thread, the emontx smd, where the opamp will work fine, as you said).
Re: emonTx New Version Dev Ideas
robinsmh,
Seconded about the old emonTx input. Provided (big IF) the voltage across the burden remains more or less sinusoidal (which it won't), it is only the series impedance of the decoupling capacitor (10µF) at 50 Hz along with the limitations of the c.t that can keep the current within the absolute maximum rating for that input (if all 3 c.t's get saturated at the same time, it's also heading towards the per chip limit as well). I think it's just about OK on a good day, but as you say there's no certainty about it, and I'm just a little bit surprised we haven't seen blown up Atmel chips before now. It only needs a 1 kOhm series resistor to be pretty much guaranteed to be safe even if the burden resistor falls off, provided you have the 22 V zeners still across the c.t. secondary of course. If you're worried about those being absent (30 A c.t with internal burden removed?), the alternative is to clamp the input to the supply rails before the series resistor.
I've been meaning to make a Spice model of the YHDC c.t. so that we can explore that area a bit more thoroughly.
Re: emonTx New Version Dev Ideas
In the Netherlands almost everyone will soon (within a few years) have a "smart" electricity meter. The smart meter has a serial port on it (port P1) which supplies information about the metered electrical and gas usage. If we can interface P1 with OpenEnergyMonitor (and of course we should) then this will make it unnecessary to monitor electricity meter pulses. P1 also supplies gas meter information but that is only updated hourly.
There is some talk of this system becoming a European standard, but I have no idea how realistic that is.
Ref: http://www.netbeheernederland.nl/DecosDocument/Download/?fileName=a-n579CEVhC-PRRFqtN5bZIjj5OT0osfD6_rJVUBnU5V5SSv8hiUTEpArs1SnYWOgvEUytnuOapmyNRQgnv22w&name=Dutch-Smart-Meter-Requirements-v4-0-5-P2
Re: emonTx New Version Dev Ideas
We may want to reconsider this since the RFM12B won't be available anymore:
http://harizanov.com/2013/04/rfm12b-end-of-life/


created with an early demo of https://github.com/preciousforever/svg-stacker
| Name | Object | Code |
|---|---|---|
| audio-card | ||
| audio-input-microphone | ||
| battery | ||
| camera-photo | ||
| camera-video | ||
| computer | ||
| drive-harddisk | ||
| drive-optical | ||
| drive-removable-media | ||
| input-gaming | ||
| input-keyboard | ||
| input-mouse | ||
| media-flash | ||
| media-floppy | ||
| media-optical | ||
| multimedia-player | ||
| network-wired | ||
| network-wireless | ||
| printer | ||
| video-display |


{% extends 'base.html'%} {% block styles%} {{ super() }} {% endblock %}{% block content%}
The weather today is sunny. You can go out and bask in the sun
Pizza Place
Pizza Inn


{% extends "blogs/base.html" %} {% load bootstrap4 %} {% block page_header %}
File uploaded at: {{ uploaded_file_url }}


True adventure takes guts, so KTM’s rally experts brought out the big guns and packed 1.301cc, 140 Nm of torque and 160 hp into the world’s most advanced Travel Enduro chassis. This makes for a mile-munching omnivore, ready to carve its name into any terrain the tougher, the better.
This 1957 Chevrolet Bel Air hardtop is truly one of those no-compromises old cars. It's one of the most popular cars ever built and retains its awesome original look, stock 283, and factory suspension setup, so it drives and feels like a '57 should, not some modern hybrid. But it's also been upgraded with a few things that make motoring more pleasant if you're the kind of guy who hits the road on a moment's notice.
Dangerous, powerful, fast
The airframe was strengthened for low-level flight and fitted with an Antilope 5 radar, which is used for terrain following, navigation and ground mapping, and which can follow terrain at 1,112 km/h (691 mph).[citation needed] Other avionic features are twin INS units and moving map displays for both the pilot and weapon systems officer. The Mirage 2000N can carry one ASMP medium-range nuclear missile, and can also carry two MATRA
It’s safe to say that “cruiser” isn’t exactly the first word that comes to mind when I think of Ducati, or even the third, yet here we are with the XDiavel and its slightly dressier, “S” trim package that carries the brand into uncharted waters. The “X” is meant to signify the cross and blending of the two worlds — cruiser and sport — and the end result is what the factory calls a “Techno-cruiser” due to its melding of Italian performance DNA and a more cruise-tastic rider triangle than you normally see from this brand. Powered by a 1,262 cc Testastretta engine, the XDiavel duo put the “sport” in “sport-cruiser” and opens the performance field to folks that ordinarily wouldn’t have such an option.
Kuznetsov—commissioned on Dec. 25, 1990—is an older ship, but the vessel’s age is not the real issue. There are a good number of U.S. Navy carriers that are far older than Kuznetsov that operate perfectly well. Nimitz, Dwight D. Eisenhower, Carl Vinson, Theodore Roosevelt and Abraham Lincoln —are all older than the Russian ship. Moreover, USS Enterprise (CVN-65)—which was retired on Dec. 1, 2012, after more than 50 years in service—was just as ready to launch and recover aircraft on the day she was pulled out of service as she was the day she was first deployed in 1962.
The Topol-M is a cold-launched, three-stage, solid-propellant, silo-based or road-mobile intercontinental ballistic missile.[2] The missile's length is 22.7 m and the first stage has a body diameter of 1.9 m. The mass at launch is 47,200 kg, including the 1,200 kg payload. Topol-M carries a single warhead with an 800 kt yield[1] but the design is compatible with MIRV warheads. According to chief designer Yury Solomonov, the missile can carry four to six warheads along with decoys.[11] Its minimum range is estimated to be 2,000 km and the maximum range 10,500 km. It has three solid rocket stages with inertial, autonomous flight control utilizing an onboard GLONASS receiver.[12] It is reputed to have the highest accuracy of any Russian ICBM[13] with a CEP of 200m.[14] The body of the rocket is made by winding carbon fiber.
The reason why this new Chiron isn’t worthy of the Super Sport name is because the drivetrain carries over mostly unchanged. The chassis features a number of upgrades, but the engine remains in stock form, so performance is pretty much the same. But Bugatti made developments in a department that needed serious improvements since the days of the Veyron: the handling. The Chiron Sport is a much more agile car, and it’s better suited for track use. It’s also a bit lighter than the standard model and comes with industry-first windscreen wipers made from carbon-fiber. Let’s find out more about all these enhancements in the review below.
Dangerous, powerful, fast
The CH-53 was the product of the US Marine Corps' "Heavy Helicopter Experimental" (HH(X)) competition begun in 1962. Sikorsky's S-65 was selected over Boeing Vertol's modified CH-47 Chinook version. The prototype YCH-53A first flew on 14 October 1964.[5] The helicopter was designated "CH-53A Sea Stallion" and delivery of production helicopters began in 1966.[6] The CH-53A is equipped with two of the T64-GE-6 turboshaft engine and has a maximum gross weight of 46,000 lb (20,865 kg).
Dangerous, powerful, fast
Sea Huntress's interior layout sleeps up to 10 guests in 5 rooms, including a master suite, 4 twin cabins and 2 pullman beds. She is also capable of carrying up to 13 crew onboard to ensure a relaxed luxury yacht experience. Timeless styling, beautiful furnishings and sumptuous seating feature throughout to create an elegant and comfortable atmospher


Click here or type <Enter> to chat
Blue:
0
-
Red:
0
Blue flag:
home
-
Red flag:
home
Ping: 100
Kills/deaths: 0/0
Score: 0
Upgrades: 0
Use any of the following services to sign in
to save your account progress and
achievements.
Sign in with
We only require the absolute minimum
permission set that each platform provides.
See our
Privacy Policy for more.


Each November ELIXIR Europe organises BioHackathon Europe, which brings together bioinformaticians from around the world. The event takes place in different locations around Europe. The BioHackathon offers an intense week of hacking, with over 160 international participants who work on diverse and exciting projects. The week starts with a half-day symposium to introduce these projects, and is followed by five days of hacking with one sole aim: coding to address problems in bioinformatics.
You can find details of the previous BioHackathons on the ELIXIR website.


{{art_info.title}}
Abstract
{{art_info.abstract|safe}}
References:
{{art_info.references|safe|linebreaksbr}}


Come learn about me!
Summer 2019
September 2019 - December 2019
August 2019 - Present
Click here to see content created by server code.
Click this button to see my availibility.
Click here to see the server response directly.
Currently, I am a Junior at the University of Michigan, Ann Arbor studying Information Analytics through the School of Information. This summer I am focusing my energies toward my position as a TA in the Girls Who Code Summer Immersion Program, as a co-leader for the Deep Learning Research Team at UofM, and as a COO of Brain Friendly Reading, a tutor non-profit. My hobbies include being a part of the Michigan Marching Band, embroidering pictures of my friends and I and reading.


This page displays measures for the network Semantic Network [Threat Groups x Situational].
Network images have nodes colored by group and sized by betweenness centrality.
Threat Groups-Level Measures
These measures were run on the specified network, and produced a vector of values, one value for each Threat Groups node.
Input network: Semantic Network [Threat Groups x Situational]
Measure Min Mean Max Std.Dev Centrality, Hub 0 0.008 0.218 0.032 Centrality, Hub [Unscaled] 0 0.005 0.154 0.023 Centrality, Out-Degree 0 0.003 0.053 0.009 Centrality, Out-Degree [Unscaled] 0 0.367 6 1.024 Situational-Level Measures
These measures were run on the specified network, and produced a vector of values, one value for each Situational node.
Input network: Semantic Network [Threat Groups x Situational]
Measure Min Mean Max Std.Dev Centrality, Authority 0 0.019 0.149 0.044 Centrality, Authority [Unscaled] 0 0.013 0.105 0.031 Centrality, In-Degree 0 0.003 0.034 0.008 Centrality, In-Degree [Unscaled] 0 0.947 10 2.438 Overall Top-Ranked Threat Groups
This chart shows the Threat Groups nodes that are top-ranked overall using the node-level measures listed below. The value shown for a node is the average of its measure values, each of which is first converted into a z-score. The final scores are then normalized to be between zero and one.
There are 49 nodes in the nodeset.
Overall Score Measure List
Centrality, Hub [Semantic Network [Threat Groups x Situational]]
Centrality, Out-Degree [Semantic Network [Threat Groups x Situational]]
Centrality, Hub
A node is hub-central to the extent that its out-links are to nodes that have many in-links. Individuals or organizations that act as hubs are sending information to a wide range of others each of whom has many others reporting to them. Technically, an agent is hub-central if its out-links are to agents that have many other agents sending links to them. The scientific name of this measure is hub centrality and it is calculated on agent by agent matrices.
If the node of interest has a higher than normal value (greater than 1 standard deviation(s) above the mean) the row is colored red. The row is green if the node is within 1 standard deviation of the mean. Finally, the row is colored blue if the node has a lower than normal value (less than one standard deviation(s) below the mean).
Input network(s): Semantic Network [Threat Groups x Situational]
Rank Threat Groups Value Unscaled 1 deadeye_jackal 0.218 0.154 2 careto 0.038 0.027 3 ghostnet 0.038 0.027 4 dropping_elephant 0.036 0.026 5 unit_8200 0.036 0.026 6 ice_fog 0.002 0.001 7 shell_crew 0.002 0.001 8 vigilance 0.002 0.001 9 _acnmedia 0 0 10 anchor_panda 0 0 11 anunak 0 0 12 apt_29 0 0 13 aurora_panda 0 0 14 axiom 0 0 15 brisach 0 0 16 comment_crew 0 0 17 covellite 0 0 18 cyber_caliphate_army 0 0 19 darkhotel 0 0 20 denis 0 0 21 dependent 0 0 22 desde 0 0 23 energetic_bear 0 0 24 equation_group 0 0 25 flying_kitten 0 0 26 hacking_team 0 0 27 ixeshe 0 0 28 kimsuky 0 0 29 leviathan 0 0 30 lotus_panda 0 0 31 madi 0 0 32 martisen 0 0 33 mirage 0 0 34 molerats 0 0 35 muddywater 0 0 36 qaeda 0 0 37 red_october 0 0 38 sandworm 0 0 39 shabaab 0 0 40 silence_group 0 0 41 silent_chollima 0 0 42 sofacy 0 0 43 stone_panda 0 0 44 taidoor 0 0 45 terrorism 0 0 46 terrorist 0 0 47 threat 0 0 48 turla_group 0 0 49 wing 0 0
Value statistics Min: 0 Mean: 0.008 Lower quartile: 0 Max: 0.218 Std.dev: 0.032 Median: 0 Upper quartile: 0
Unscaled value statistics Min: 0 Mean: 0.005 Lower quartile: 0 Max: 0.154 Std.dev: 0.023 Median: 0 Upper quartile: 0 Centrality, Out-Degree
For any node, e.g. an individual or a resource, the out-links are the connections that the node of interest has to other nodes. For example, imagine an agent by knowledge network where the number of out-links an agent would have is the number of pieces of knowledge it is connected to. The scientific name of this measure is out-degree and it can be calculated on any network.
If the node of interest has a higher than normal value (greater than 1 standard deviation(s) above the mean) the row is colored red. The row is green if the node is within 1 standard deviation of the mean. Finally, the row is colored blue if the node has a lower than normal value (less than one standard deviation(s) below the mean).
Input network(s): Semantic Network [Threat Groups x Situational]
Rank Threat Groups Value Unscaled 1 deadeye_jackal 0.053 6 2 silence_group 0.026 3 3 careto 0.018 2 4 ghostnet 0.018 2 5 dropping_elephant 0.009 1 6 ice_fog 0.009 1 7 shell_crew 0.009 1 8 unit_8200 0.009 1 9 vigilance 0.009 1 10 _acnmedia 0 0 11 anchor_panda 0 0 12 anunak 0 0 13 apt_29 0 0 14 aurora_panda 0 0 15 axiom 0 0 16 brisach 0 0 17 comment_crew 0 0 18 covellite 0 0 19 cyber_caliphate_army 0 0 20 darkhotel 0 0 21 denis 0 0 22 dependent 0 0 23 desde 0 0 24 energetic_bear 0 0 25 equation_group 0 0 26 flying_kitten 0 0 27 hacking_team 0 0 28 ixeshe 0 0 29 kimsuky 0 0 30 leviathan 0 0 31 lotus_panda 0 0 32 madi 0 0 33 martisen 0 0 34 mirage 0 0 35 molerats 0 0 36 muddywater 0 0 37 qaeda 0 0 38 red_october 0 0 39 sandworm 0 0 40 shabaab 0 0 41 silent_chollima 0 0 42 sofacy 0 0 43 stone_panda 0 0 44 taidoor 0 0 45 terrorism 0 0 46 terrorist 0 0 47 threat 0 0 48 turla_group 0 0 49 wing 0 0
Value statistics Min: 0 Mean: 0.003 Lower quartile: 0 Max: 0.053 Std.dev: 0.009 Median: 0 Upper quartile: 0
Unscaled value statistics Min: 0 Mean: 0.367 Lower quartile: 0 Max: 6 Std.dev: 1.024 Median: 0 Upper quartile: 0 Overall Top-Ranked Situational
This chart shows the Situational nodes that are top-ranked overall using the node-level measures listed below. The value shown for a node is the average of its measure values, each of which is first converted into a z-score. The final scores are then normalized to be between zero and one.
There are 19 nodes in the nodeset.
Overall Score Measure List
Centrality, Authority [Semantic Network [Threat Groups x Situational]]
Centrality, In-Degree [Semantic Network [Threat Groups x Situational]]
Centrality, Authority
A node is authority-central to the extent that its in-links are from nodes that have many out-links. Individuals or organizations that act as authorities are receiving information from a wide range of others each of whom sends information to a large number of others.
If the node of interest has a higher than normal value (greater than 1 standard deviation(s) above the mean) the row is colored red. The row is green if the node is within 1 standard deviation of the mean. Finally, the row is colored blue if the node has a lower than normal value (less than one standard deviation(s) below the mean).
Input network(s): Semantic Network [Threat Groups x Situational]
Rank Situational Value Unscaled 1 impact 0.149 0.105 2 opportunity_for_criminal_acts 0.133 0.094 3 trap 0.067 0.047 4 vulnerabilities 0.008 0.006 5 alarm 0 0 6 commercial 0 0 7 crime 0 0 8 days 0 0 9 deployment 0 0 10 free 0 0 11 harm 0 0 12 investigation 0 0 13 parent-child_experience 0 0 14 party 0 0 15 social 0 0 16 sponsored 0 0 17 supervised 0 0 18 technical 0 0 19 war 0 0
Value statistics Min: 0 Mean: 0.019 Lower quartile: 0 Max: 0.149 Std.dev: 0.044 Median: 0 Upper quartile: 0
Unscaled value statistics Min: 0 Mean: 0.013 Lower quartile: 0 Max: 0.105 Std.dev: 0.031 Median: 0 Upper quartile: 0 Centrality, In-Degree
The number of links directed into a node normalized by the maximum number of such links. This measure is also called Column Degree Centrality because it is computed by taking the sum of the column values in the input network.
If the node of interest has a higher than normal value (greater than 1 standard deviation(s) above the mean) the row is colored red. The row is green if the node is within 1 standard deviation of the mean. Finally, the row is colored blue if the node has a lower than normal value (less than one standard deviation(s) below the mean).
Input network(s): Semantic Network [Threat Groups x Situational]
Rank Situational Value Unscaled 1 impact 0.034 10 2 vulnerabilities 0.017 5 3 opportunity_for_criminal_acts 0.007 2 4 trap 0.003 1 5 alarm 0 0 6 commercial 0 0 7 crime 0 0 8 days 0 0 9 deployment 0 0 10 free 0 0 11 harm 0 0 12 investigation 0 0 13 parent-child_experience 0 0 14 party 0 0 15 social 0 0 16 sponsored 0 0 17 supervised 0 0 18 technical 0 0 19 war 0 0
Value statistics Min: 0 Mean: 0.003 Lower quartile: 0 Max: 0.034 Std.dev: 0.008 Median: 0 Upper quartile: 0
Unscaled value statistics Min: 0 Mean: 0.947 Lower quartile: 0 Max: 10 Std.dev: 2.438 Median: 0 Upper quartile: 0


My projects
Skills
I've been described as a very creative person when a problem comes, I always try to get the easiest way to solve problems and improve the productivity and efficiency in my environment.
As developer, my favorite stack is Mongo, Express, Vue ( ❤ Javascript), but I enjoy learn every day new things, new languages, new ideas.


--- layout: page title: About header-img: "img/about-bg.png" ---
My name is Nyla and I am starting my journey into data science. Come join me on my quest to learn new skills.