Package org.bitcoinj.utils
Class Threading
- java.lang.Object
-
- org.bitcoinj.utils.Threading
-
public class Threading extends java.lang.Object
Various threading related utilities. Provides a wrapper around explicit lock creation that lets you control whether bitcoinj performs cycle detection or not. Cycle detection is useful to detect bugs but comes with a small cost. Also provides a worker thread that is designed for event listeners to be dispatched on.
-
-
Nested Class Summary
Nested Classes Modifier and Type Class Description static class
Threading.UserThread
-
Field Summary
Fields Modifier and Type Field Description static com.google.common.util.concurrent.CycleDetectingLockFactory
factory
static java.util.concurrent.Executor
SAME_THREAD
A dummy executor that just invokes the runnable immediately.static com.google.common.util.concurrent.ListeningExecutorService
THREAD_POOL
A caching thread pool that creates daemon threads, which won't keep the JVM alive waiting for more work.static java.lang.Thread.UncaughtExceptionHandler
uncaughtExceptionHandler
An exception handler that will be invoked for any exceptions that occur in the user thread, and any unhandled exceptions that are caught whilst the framework is processing network traffic or doing other background tasks.static java.util.concurrent.Executor
USER_THREAD
An executor with one thread that is intended for running event listeners on.
-
Constructor Summary
Constructors Constructor Description Threading()
-
Method Summary
All Methods Static Methods Concrete Methods Modifier and Type Method Description static com.google.common.util.concurrent.CycleDetectingLockFactory.Policy
getPolicy()
static void
ignoreLockCycles()
static java.util.concurrent.locks.ReentrantLock
lock(java.lang.String name)
static void
setPolicy(com.google.common.util.concurrent.CycleDetectingLockFactory.Policy policy)
static void
throwOnLockCycles()
static void
waitForUserCode()
Put a dummy task into the queue and wait for it to be run.static void
warnOnLockCycles()
-
-
-
Field Detail
-
USER_THREAD
public static java.util.concurrent.Executor USER_THREAD
An executor with one thread that is intended for running event listeners on. This ensures all event listener code runs without any locks being held. It's intended for the API user to run things on. Callbacks registered by bitcoinj internally shouldn't normally run here, although currently there are a few exceptions.
-
SAME_THREAD
public static final java.util.concurrent.Executor SAME_THREAD
A dummy executor that just invokes the runnable immediately. Use this over more complex executors (e.g. those extendingExecutorService
), which are overkill for our needs.
-
uncaughtExceptionHandler
@Nullable public static volatile java.lang.Thread.UncaughtExceptionHandler uncaughtExceptionHandler
An exception handler that will be invoked for any exceptions that occur in the user thread, and any unhandled exceptions that are caught whilst the framework is processing network traffic or doing other background tasks. The purpose of this is to allow you to report back unanticipated crashes from your users to a central collection center for analysis and debugging. You should configure this before any bitcoinj library code is run, setting it after you started network traffic and other forms of processing may result in the change not taking effect.
-
factory
public static com.google.common.util.concurrent.CycleDetectingLockFactory factory
-
THREAD_POOL
public static com.google.common.util.concurrent.ListeningExecutorService THREAD_POOL
A caching thread pool that creates daemon threads, which won't keep the JVM alive waiting for more work.
-
-
Method Detail
-
waitForUserCode
public static void waitForUserCode()
Put a dummy task into the queue and wait for it to be run. Because it's single threaded, this means all tasks submitted before this point are now completed. Usually you won't want to use this method - it's a convenience primarily used in unit testing. If you want to wait for an event to be called the right thing to do is usually to create aSettableFuture
and then call set on it. You can then either block on that future, compose it, add listeners to it and so on.
-
lock
public static java.util.concurrent.locks.ReentrantLock lock(java.lang.String name)
-
warnOnLockCycles
public static void warnOnLockCycles()
-
throwOnLockCycles
public static void throwOnLockCycles()
-
ignoreLockCycles
public static void ignoreLockCycles()
-
setPolicy
public static void setPolicy(com.google.common.util.concurrent.CycleDetectingLockFactory.Policy policy)
-
getPolicy
public static com.google.common.util.concurrent.CycleDetectingLockFactory.Policy getPolicy()
-
-


Utils¶
irisreader.utils.download¶
-
irisreader.utils.
download
(obs_identifier, target_directory, type='all', uncompress=True, open_obs=True, mirror=None)[source]¶ Downloads a given IRIS observation.
- Parameters
obs_identifier (str) – Observation identifier in the form yyyymmdd_hhmmss_oooooooooo, e.g. 20140323_052543_3860263227
target_directory (str) – Path to store downloaded observation to (defaults to home directory)
type (str) – Type of data to download: ‘all’: all data ‘sji’: only SJI files ‘raster’: only raster files
uncompress (bool) – Uncompress files after download? (automatically set to True if open_obs is True)
open_obs (bool) – Immediately open observation and return observation object? Otherwise a boolean indicating download success is returned
mirror (str) – Mirror to be used: ‘lmsal’: LMSAL (http://www.lmsal.com/solarsoft/irisa/data/level2_compressed/) ‘uio’: University of Oslo (http://sdc.uio.no/vol/fits/iris/level2/)
- Returns
- Return type
An open observation handle or a boolean indicating download success.
irisreader.utils.animate¶
-
irisreader.utils.
animate
(data_cube, raster_pos=None, index_start=None, index_stop=None, interval_ms=50, gamma=0.4, figsize=(7, 7), cutoff_percentile=99.9, save_path=None)[source]¶ Creates an animation from the individual images of a data cube. This function can be pretty slow and take 1-2 minutes. Faster alternatives than matplotlib will be researched in the future.
- Parameters
data_cube (iris_data_cube) – instance of sji_cube or raster_cube
raster_pos (int) – If not None, only display images at raster postion raster_pos
index_start (int) – index where to start animation (defaults to None -> will be set to 0)
index_stop (int) – index where to stop animation (defaults to None -> will be set to n)
interval_ms (int) – number of milliseconds between two frames
gamma (float) – gamma correction for plotting: number between 0 (infinitely gamma correction) and 1 (no gamma correction)
figsize (tuple) – figure size: (width,height)
cutoff_percentile (float) – Often the maximum pixels shine out everything else, even after gamma correction. In order to reduce this effect, the percentile at which to cut the intensity off can be specified with cutoff_percentile in a range between 0 and 100.
save_path (str) – path to file where animation output will be written to (use .mp4 extension)
- Returns
HTML object with the animation
- Return type
IPython.HTML
irisreader.utils.date.from_Tformat¶
irisreader.utils.date.to_Tformat¶
-
irisreader.utils.date.
to_Tformat
(date, milliseconds=True)[source]¶ Converts from a datetime object to the FITS date format ‘%Y-%m-%dT%H:%M:%S’.
- Parameters
date (datetime) – Python datetime object
milliseconds (bool) – Whether to include milliseconds in the output (separated with a dot)
- Returns
date_str – FITS date string with ‘T’ between date and time.
- Return type
str


Rogellia:
Wait a moment... Youngster, I think I made a mistake.
I cannot send an innocent soul like yours into the harsh world. See me again after you have gained more experience.
(Only characters level 18 and above may undertake this quest.)


Possible Misspelling: MYVARIABLE may not be assigned. Did you mean MY_VARIABLE?
MY_VARIABLE="hello world"
echo "$MYVARIABLE"
MY_VARIABLE="hello world"
echo "$MY_VARIABLE"
ShellCheck has noticed that you reference a variable that is not assigned in the script, but which has a name similar to another known variable. You should verify that the variable name is spelled correctly.
Note: This error only triggers for environment variables (all uppercase variables), and only when they have names similar to another known variable in the script. If the variable is script-local, it should by convention have a lowercase name, and will in that case be caught by [SC2154] whether or not it resembles another name.
If you've double checked and ensured that you did not intend to reference the specified variable, you can disable this message with a [[directive]]. The message will also not appear for guarded references like ${ENVVAR:-default}
or ${ENVVAR:?Unset error message here}
.


Custom HTML Attributes¶
The PixieDust JS runtime listens to click events on any HTML element that has one or more of the custom attributes below, and then transforms the attribute values into a kernel request. The following section describes all the custom attributes available, and how they affect the kernel request executed when a click event is received.
pd_options¶
List of key-value pairs that define transient states for the kernel request, according to the following format: pd_options="key1=value1;key2=value2;..."
. For example, you can use pd_options to dispatch the current screen to another view. When you use pd_entity
, then the pd_options are interpreted as display()
API options (more details below).
Note
You can also use a shorter syntax to define options using the following attribute pattern: option_key1="value1"
.
Note
To build the pd_options value for display(), use the display() API in a separate cell. When the correct chart is created, simply copy the options from the cell metadata. (You’ll need to use the View/Cell Toolbar/Edit Metadata menu to show the “edit metadata” button.) You will also need to transform the JSON to the pd_options attribute format, e.g., no quote in the value, semi-colon separator, and “key=value” format.
You can now alternatively use JSON notation to configure pd_options. To do so, simply create a pd_options child element and directly store the JSON options as text. For example:

<pd_options>
{
"mapboxtoken": "XXXXX",
"chartsize": "90",
"aggregation": "SUM",
"rowCount": "500",
"handlerId": "mapView",
"rendererId": "mapbox",
"valueFields": "IncidntNum",
"keyFields": "X,Y",
"basemap": "light-v9"
}
</pd_options>

pd_entity¶
Use the pd_entity attribute only if you want to invoke the display() API on specific data. In this case, pd_options must be display-options-specific to the visualization you want to show. The output will be returned by display(), but without the UI chrome. The value of pd_entity is interpreted as a field to the PixieApp class, e.g., pd_entity="filteredDataFrame"
, and requires that the PixieApp instance has a field named filteredDataFrame. If the field is not present, then an error will be raised.
Note
the entity passed by the caller in the run method is stored in a special field called pixieapp_entity
. Therefore, using pd_entity="pixieapp_entity"
will direct PixieDust to use the entity passed by the caller. For convenience, the user can also simply use pd_entity (without any value) to do the same thing.
pd_target¶
By default, the output of a kernel request takes over the entire UI–or output cell or dialog depending on the runInDialog
option). However, you can use pd_target="elementId"
to specify a target element that will receive the output. (Of course the elementId must exist in the current view.) For example:

<input type="button" pd_options="handlerId=dataframe" pd_entity pd_target="myTarget{{prefix}}" value="click me"/>
In the example above, we define a placeholder div with id "myTarget{{prefix}}"
and use it as a target in the input button.
Note
{{prefix}}
is a Jinja2 notation that means “use the value of the prefix variable, which PixieDust automatically creates to provide a unique id.” We need this value to avoid a conflict in case a user calls the PixieApp multiple times within the same notebook.
Note
You can define multiple targets for a particular kernel request. In this case, you’ll want to create one or more <target>
elements as children (see the Custom PixieApp Elements section for more info).
pd_script¶
PixieDust lets you run arbitrary Python code using the pd_script
attribute. For example: pd_script="self.filteredDataFrame=self.createFilteredDataFrame()"
. pd_script can be used even if pd_entity is used. In this case, the Python script will be executed before the display() call. This behavior can be useful, for example, in creating a sub entity that will be used in the display() call. For example:

<input type="button" pd_options="handlerId=dataframe" pd_entity="filteredDataFrame" pd_script="self.filteredDataFrame=self.createFilteredDataFrame()" pd_target="myTarget{{prefix}}" value="click me"/>
Note
You can use the self
keyword, which points at the current PixieApp instance.
Note
You can only use one-line Python code (similar to Python lambda). If you need to run more than one line of code, then you’ll need to use the pd_script element as a child (see the Custom PixieApp Elements section for more info).
pd_render_onload¶
This attribute should be used when you want to trigger a kernel request upon loading, as opposed to when a user clicks on an element like in the example above. You should combine pd_render_onload
with any other attribute that defines the request, like pd_options or pd_script. It is important to note that you can only use a div element with this attribute and that the output of the kernel request will be placed as a child element of the div. For example:
from pixiedust.display.app import *
@PixieApp
class RenderOnLoad():
@route()
def mainScreen(self):
return """

"""
RenderOnLoad().run()
pd_refresh¶
There are two ways of using the pd_refresh
attribute:
- No value specified: When you only have the pd_script attribute without pd_target, PixieDust will not refresh the output but will simply execute the pd_script. Using pd_refresh will force the output to refresh with the current view.
- Specify a value: The value must be a valid HTML id element that defines a kernel request (pd_options, pd_script, etc.). In this case, when the element is activated on click, the target element is refreshed according to its pd attributes. For example:
from pixiedust.display.app import *
@PixieApp
class Refresh():
def setup(self):
self.counter=0
def incrCounter(self):
self.counter+=1
print(self.counter)
@route()
def mainScreen(self):
return """
<input type="button" pd_refresh="counter{{prefix}}" value="Refresh Counter">

"""
Refresh().run()
pd_norefresh¶
Similar to pd_refresh, pd_norefresh
forces PixieDust to not refresh the current output target.
pd_stop_propagation¶
Use the pd_stop_propagation
attribute to tell PixieDust that in the case where it couldn’t find anything to execute in the current element, to stop searching parent elements. This can be useful when the content of an element is dynamically generated via a route which has no execution info and you want to prevent accidental execution of a parent element configuration.
pd_refresh_rate¶
Use the pd_refresh_rate
attribute to repeat the execution at a specified interval expressed in milliseconds. This is useful for when you want to poll the state of a particular variable and show the result in the UI. For example:


Order
Payment
Confirm
Placeholder
How many trackers?
Placeholder
Billing frequency
Product
Quantity
Unit
Cost
Tracker
{{numberOfTrackers}}
£199
£{{numberOfTrackers * 199}}
{{getBillingType()}}
{{numberOfTrackers}}
£{{getBillingPrice()}}
£{{getBillingTotal()}}
Total Cost Today
£{{price}}
Show Payment Screen


active team
name: {{teamPSI().session.name}}
color: {{teamPSI().session.color}}
score: {{teamPSI().instance.score}}
active player
name: {{playerPSI().person.name}}
role: {{playerPSI().session.role}}
score: {{playerPSI().instance.score}}
contracts
game_grid
{{word}}


The Aichi Biodiversity Targets Task Force was established to provide a platform for agencies to coordinate their activities in support of implementation of the Strategic Plan for Biodiversity 2011-2020 and its Aichi Biodiversity Targets at global and national levels during the United Nations Decade on Biodiversity.
A Memorandum of Cooperation (MoC) signed on 20 September 2011 between the Secretariat of the Convention on Biological Diversity (CBD) and 27 international agencies, organizations and environmental conventions, aims to achieve and implement the Strategic Plan for Biodiversity and its Aichi Targets. Two more organizations have joined since.
An intergovernmental organization, FAO has 194 Member Nations, two associate members and one member organization, the European Union. Its employees come from various cultural backgrounds and are experts in the multiple fields of activity FAO engages in. FAO’s staff capacity allows it to support improved governance inter alia, generate, develop and adapt existing tools and guidelines and provide targeted governance support as a resource to country and regional level FAO offices. Headquartered in Rome, ItaFAO is present in over 130 countries >
IDLO is the only intergovernmental organization with an exclusive mandate to promote the rule of law. Governments, multilateral organizations, private foundations and sector support our work >
UNDP works in more than 170 countries and territories, helping to achieve the eradication of poverty, and the reduction of inequalities and exclusion. We help countries to develop policies, leadership skills, partnering abilities, institutional capabilitieresilience in order to sustain development results >


Consider adding a default *) case, even if it just exits with error.
case "$1" in
start) start_service ;;
stop) stop_service ;;
restart|reload|force-reload)
stop_service;
start_service;;
esac
case "$1" in
start) start_service ;;
stop) stop_service ;;
restart|reload|force-reload)
stop_service;
start_service;;
*)
echo >&2 "Invalid choice: $1"
exit 1
esac
ShellCheck found a case
statement that may not be considering all possible cases. This may mean that only the happy paths are accounted for.
Consider adding a default case to handle other values. If you don't know what to do or don't believe it'll ever happen, exiting with an error is good, fail-fast practice.
The example is adapted from a real world Debian init script, which due to a missing default case reports success on any misspelled command (here with underscore instead of dash):
$ /etc/init.d/screen-cleanup force_reload && echo success
success
This suggestion only triggers in verbose mode (-S verbose
).
If you don't have a default case because the default should be to take no action, consider adding a comment to other humans:
case "$(uname)" in
CYGWIN*) cygwin=1;;
MINGW*) mingw=1;;
*) ;; # No special workarounds identified
esac
If you believe that it's impossible for the expression to have any other value, it's considered good practice to add the equivalent of an assert(0)
to fail fast if this assumption should turn out to be incorrect in the current or future versions:
case "$result" in
true) proceed;;
false) cancel;;
*) echo >&2 "Submit bug report: '$result' should be true or false."
exit 127
esac


Lifelong student, avid traveler, and overzealous foodie continually exploring new subjects, cities, and dishes; psychology nerd who enjoys listening to and learning about others; empathic leader known for promoting and maintaining a positive attitude - always, with a smile.
Synonyms: trace, tray, traceface, tracecakes, t-squared, catrace
To learn more, click here.


309_crwkjbc.py
class Solution:
def countRestrictedPaths(self, n: int, edges: List[List[int]]) -> int:
dist = [0]*(n+1)
res = 0
graph = defaultdict(list)
for u,v,w in edges:
graph[u].append((v,w))
graph[v].append((u,w))
queue = [(w, v) for v, w in graph[n]]
heapq.heapify(queue)
visited = set([n])
while queue:
w, u = heapq.heappop(queue)
if u in visited:
continue
dist[u] = w
visited.add(u)
for v, w in graph[u]:
if v not in visited:
heapq.heappush(queue, (dist[u] + w, v))
# print(dist)
count = [0] *(n+1)
@lru_cache(None)
def dfs(u):
if u == 1:
return 1
res = 0
for v, _ in graph[u]:
if dist[u] < dist[v]:
res += dfs(v)
return res %(10**9+7)
return dfs(n)


OneBadFish
This is a rookie blog, hoping to make progress through learning, strengthen through communication, and become a mature programmer here.
Communication in GitHub
Pellentesque sagittis feugiat massa, vitae blandit elit dictum in. Nam eleifend nunc dui, sed cusus justo molestie id. Vestibulum vel sagittis justo.
READ MOREThis is a web front-end development learner's blog. I am a web front-end development enthusiast who loves learning and communicating.
Learning project
This is one of my projects. Please give me your advice and leave your valuable comments.
READ MORE


For Resident Indians and NRIs - Privacy for Consumers at Citi
Our goal is to maintain your trust and confidence while handling personal information about you.
You have Choices
As a Citi customer, you have the opportunity to make choices about how personal information about you may be shared. As you consider this, we encourage you to make choices that enable us to provide you with quality products and services, that help you meet your financial needs and objectives.
Security of Personal Information
The security of personal information about you is our priority. We protect this information by maintaining physical, electronic, and procedural safeguards that meet applicable law. We train our employees in the proper handling of personal information. When we use other companies to provide services for us, we require them to protect the confidentiality of personal information they receive.
Citi Online Privacy Statement
Our Online Privacy Statement does not cover information you provide to the websites we advertise on and may link to. We encourage you to read the privacy policies on these sites.
Our Online Privacy Statement describes below how we may collect, use and share information you provide when you visit this website, receive our emails or interact with advertisements we have on third-party websites.
We collect two types of online information: Non-Personal and Personal.
Non-Personal Information
When you visit our site, we collect the IP address of the device you use to connect to the Internet. In addition, we gather information such as what browser and which version of it you're using, the type of operating system you have, and which site you came from. This information helps us provide an online experience that matches your device.
When you browse our site or receive one of our emails, Citi and companies we work with, use cookies and/or pixel tags to collect information and store your online preferences. Cookies are widely used and most browsers are set up to accept them automatically. If you would prefer, you can choose to not accept cookies.
It's important to note that cookies and pixel tags do not capture any information that can personally identify you. The information they gather helps us improve your online experience and may include:
We may also supplement the information we collect with information we receive from other companies. For example, we may use marketing segments developed by us or other companies to customize certain services to your local area and provide relevant Citi offers tailored to you.
Personal Information
In addition to the information described in the previous section, we may also gather personal information that you provide to us such as your name, address, phone number, and email. Collecting this personal information enables us to offer you online experiences that help you with your financial needs. For example, we collect personal information when you are:
If you've enrolled in Citi services, such as online bill payment, we collect personal information about your transactions, and how you interact with third parties such as those you pay like a utility company or phone company. Collecting this information enables us to provide you these services. You can refer to the Terms and conditions for your account or service to learn how your information is collected and used.
If we have personal information from you, or information that's publicly available from other sources, we may use it in combination with the information that Citi has collected online. We can use this information to better tailor and personalize our service and marketing communications with you, both online and offline.
The personal information you provide online is held by the Citi business that maintains your account or is processing your application for a new product or service. You can access and/or change information in connection with your account or application by logging on to your account online or telephoning customer service.
Citi uses the information we collect about and from you to manage our business and to offer an enhanced, personalized online experience on our site and third-party websites.
The information we collect allows us to:
Companies we work with place and track advertisements on third-party websites.
Like most advertisers, we place advertisements where we think they will be most relevant to customers. We place advertisements by developing and using our own marketing segments that may combine online and offline information about our current and prospective customers. In addition, we may use marketing segments provided by online publishers and network advertising companies.
Network advertising companies that provide these services have their own privacy policies and are not subject to our Online Privacy Statement. Many of these companies provide ways to avoid targeted advertising provided by, or thru, them.
It's important to note that the information we use about you helps us provide you with products, services and experiences that benefit you. You have the ability to control how your non-personal information is collected and used online.
Cookies
You can control whether to accept cookies or not. If you decide to not accept cookies, some features and services on our site may not work properly because we may not be able to recognize and associate you with your Citi account(s). In addition, the offers we provide when you visit us may not be as relevant to you or tailored to your interests.
If you would prefer not to accept cookies, you can:
Notice of changes
From time to time, we may change this Online Privacy Policy. The effective date of this policy, as stated below, indicates the last time this policy was revised or materially changed. Checking the effective date below allows you to determine whether there have been changes since the last time you reviewed the policy.
Effective Date
This policy was last modified in Sep, 2011.
citibank.com/india and citinri.com is managed by Citibank India and enable online access to account information and transaction services for clients of Citibank India. In addition, citibank.com/india, citinri.com and asia.citi.com accepts applications for Citibank India. This disclosure does not address how information is handled by or the policy of any other affiliate or third party site that may be linked to these sites.
This comprehensive privacy policy ("Privacy Policy") provides the practices and policies of Citibank N.A. ("Citibank") for handling of or dealing in customer information ("Customer Information"), including Sensitive Personal Data of the Customer (as defined below) that has been lawfully collected by Citibank from its customers ("Customers"). It also provides the type of Sensitive Personal Data collected by Citibank, the purpose of collection and usage of such data, their disclosure norms and the reasonable security practices and procedures adopted by Citibank in this regard. This Privacy Policy is applicable to all Customer Information collected by Citibank. Citibank reserves the right to amend its prevailing Privacy Policy from time to time at its sole discretion and shall place any such amendments on this website.
If a Customer does not wish to receive any marketing material / information from us, they can contact us to remove their name from our list.
Customers can contact us by writing to us at the mailing address given below:
Citibank N.A.,
P.O. Box 4830,
Anna Salai P.O.,
Chennai - 600 002.
Request for access to Sensitive Personal Data or correction of Sensitive Personal Data or for information regarding policies and practices and kinds of data held should be addressed to: Ms. Nisha Shriram on principal.nodal.officer@citi.com


wall_in Path: CARNOT/loads/wall_floor
Purpose Wall models for a house.
Description
See wall_out.
Parameters and Dialog Box


Janus
Janus is a Machine Learning API used to conduct time series predictions and forecasting on supplied data. It utilizes a Long Short-Term Memory Recurring Neural Network model to make these predictions.
API Endpoints:
-
GET: "/" : Entry page with Definitions
-
GET: "/entry" : Entry page with Definitions
-
POST: "/api/janus/post" : API Endpoint to execute time series forecasting. Supply data via the body of this request in the format defined below.
Request Body Data Format:
-
X Axis "x" : An Array containing timestamps in the format MM/DD/YYYY
-
Y Axis: "y" : An Array containing historical data mapping to timestamps in the x axis
-
Predicted Days Count: "dayCount" : Number of days in the future that you wish to predict


Action Web Service — Serving APIs on rails
Action Web Service provides a way to publish interoperable web service APIs with Rails without spending a lot of time delving into protocol details.
Features
- SOAP RPC protocol support
- Dynamic WSDL generation for APIs
- XML-RPC protocol support
- Clients that use the same API definitions as the server for easy interoperability with other Action Web Service based applications
- Type signature hints to improve interoperability with static languages
- Active Record model class support in signatures
Defining your APIs
You specify the methods you want to make available as API methods in an ActionWebService::API::Base derivative, and then specify this API definition class wherever you want to use that API.
The implementation of the methods is done separately from the API specification.
Method name inflection
Action Web Service will camelcase the method names according to Rails Inflector rules for the API visible to public callers. What this means, for example, is that the method names in generated WSDL will be camelcased, and callers will have to supply the camelcased name in their requests for the request to succeed.
If you do not desire this behaviour, you can turn it off with the ActionWebService::API::Base inflect_names option.
Inflection examples
:add => Add :find_all => FindAll
Disabling inflection
class PersonAPI < ActionWebService::API::Base inflect_names false end
API definition example
class PersonAPI < ActionWebService::API::Base api_method :add, :expects => [:string, :string, :bool], :returns => [:int] api_method :remove, :expects => [:int], :returns => [:bool] end
API usage example
class PersonController < ActionController::Base web_service_api PersonAPI def add end def remove end end
Publishing your APIs
Action Web Service uses Action Pack to process protocol requests. There are two modes of dispatching protocol requests, Direct, and Delegated.
Direct dispatching
This is the default mode. In this mode, public controller instance methods implement the API methods, and parameters are passed through to the methods in accordance with the API specification.
The return value of the method is sent back as the return value to the caller.
In this mode, a special api action is generated in the target controller to unwrap the protocol request, forward it on to the relevant method and send back the wrapped return value. This action must not be overridden.
Direct dispatching example
class PersonController < ApplicationController web_service_api PersonAPI def add end def remove end end class PersonAPI < ActionWebService::API::Base ... end
For this example, protocol requests for Add and Remove methods sent to /person/api will be routed to the controller methods add and remove.
Delegated dispatching
This mode can be turned on by setting the web_service_dispatching_mode option in a controller to :delegated.
In this mode, the controller contains one or more web service objects (objects that implement an ActionWebService::API::Base definition). These web service objects are each mapped onto one controller action only.
Delegated dispatching example
class ApiController < ApplicationController web_service_dispatching_mode :delegated web_service :person, PersonService.new end class PersonService < ActionWebService::Base web_service_api PersonAPI def add end def remove end end class PersonAPI < ActionWebService::API::Base ... end
For this example, all protocol requests for PersonService are sent to the /api/person action.
The /api/person action is generated when the web_service method is called. This action must not be overridden.
Other controller actions (actions that aren’t the target of a web_service call) are ignored for ActionWebService purposes, and can do normal action tasks.
Layered dispatching
This mode can be turned on by setting the web_service_dispatching_mode option in a controller to :layered.
This mode is similar to delegated mode, in that multiple web service objects can be attached to one controller, however, all protocol requests are sent to a single endpoint.
Use this mode when you want to share code between XML-RPC and SOAP clients, for APIs where the XML-RPC method names have prefixes. An example of such a method name would be blogger.newPost.
Layered dispatching example
class ApiController < ApplicationController web_service_dispatching_mode :layered web_service :mt, MovableTypeService.new web_service :blogger, BloggerService.new web_service :metaWeblog, MetaWeblogService.new end class MovableTypeService < ActionWebService::Base ... end class BloggerService < ActionWebService::Base ... end class MetaWeblogService < ActionWebService::API::Base ... end
For this example, an XML-RPC call for a method with a name like mt.getCategories will be sent to the getCategories method on the :mt service.
Customizing WSDL generation
You can customize the names used for the SOAP bindings in the generated WSDL by using the wsdl_service_name option in a controller:
class WsController < ApplicationController wsdl_service_name 'MyApp' end
You can also customize the namespace used in the generated WSDL for custom types and message definition types:
class WsController < ApplicationController wsdl_namespace 'http://my.company.com/app/wsapi' end
The default namespace used is ‘urn:ActionWebService’, if you don’t supply one.
ActionWebService and UTF-8
If you’re going to be sending back strings containing non-ASCII UTF-8 characters using the :string data type, you need to make sure that Ruby is using UTF-8 as the default encoding for its strings.
The default in Ruby is to use US-ASCII encoding for strings, which causes a string validation check in the Ruby SOAP library to fail and your string to be sent back as a Base-64 value, which may confuse clients that expected strings because of the WSDL.
Two ways of setting the default string encoding are:
- Start Ruby using the -Ku command-line option to the Ruby executable
- Set the $KCODE flag in config/environment.rb to the string ‘UTF8‘
Testing your APIs
Functional testing
You can perform testing of your APIs by creating a functional test for the controller dispatching the API, and calling invoke in the test case to perform the invocation.
Example:
class PersonApiControllerTest < Test::Unit::TestCase def setup @controller = PersonController.new @request = ActionController::TestRequest.new @response = ActionController::TestResponse.new end def test_add result = invoke :remove, 1 assert_equal true, result end end
This example invokes the API method test, defined on the PersonController, and returns the result.
Scaffolding
You can also test your APIs with a web browser by attaching scaffolding to the controller.
Example:
class PersonController web_service_scaffold :invocation end
This creates an action named invocation on the PersonController.
Navigating to this action lets you select the method to invoke, supply the parameters, and view the result of the invocation.
Using the client support
Action Web Service includes client classes that can use the same API definition as the server. The advantage of this approach is that your client will have the same support for Active Record and structured types as the server, and can just use them directly, and rely on the marshaling to Do The Right Thing.
Note: The client support is intended for communication between Ruby on Rails applications that both use Action Web Service. It may work with other servers, but that is not its intended use, and interoperability can’t be guaranteed, especially not for .NET web services.
Web services protocol specifications are complex, and Action Web Service client support can only be guaranteed to work with a subset.
Factory created client example
class BlogManagerController < ApplicationController web_client_api :blogger, :xmlrpc, 'http://url/to/blog/api/RPC2', :handler_name => 'blogger' end class SearchingController < ApplicationController web_client_api :google, :soap, 'http://url/to/blog/api/beta', :service_name => 'GoogleSearch' end
See ActionWebService::API::ActionController::ClassMethods for more details.
Manually created client example
class PersonAPI < ActionWebService::API::Base api_method :find_all, :returns => [[Person]] end soap_client = ActionWebService::Client::Soap.new(PersonAPI, "http://...") persons = soap_client.find_all class BloggerAPI < ActionWebService::API::Base inflect_names false api_method :getRecentPosts, :returns => [[Blog::Post]] end blog = ActionWebService::Client::XmlRpc.new(BloggerAPI, "http://.../xmlrpc", :handler_name => "blogger") posts = blog.getRecentPosts
See ActionWebService::Client::Soap and ActionWebService::Client::XmlRpc for more details.
Dependencies
Action Web Service requires that the Action Pack and Active Record are either available to be required immediately or are accessible as GEMs.
It also requires a version of Ruby that includes SOAP support in the standard library. At least version 1.8.2 final (2004-12-25) of Ruby is recommended; this is the version tested against.
Download
The latest Action Web Service version can be downloaded from rubyforge.org/projects/actionservice
Installation
You can install Action Web Service with the following command.
% [sudo] ruby setup.rb
License
Action Web Service is released under the MIT license.
Support
The Ruby on Rails mailing list
Or, to contact the author, send mail to bitserf@gmail.com


{{ js_resources|indent(4)|safe }} {{ css_resources|indent(4)|safe }} {{ plot_script|indent(4)|safe }}
{% if didFail == "True" %} {% endif %}The Scale Liquid Remaining IOT is an Internet of Things device that is used to collect weight data from scales to get the percentage of how full containers are that are placed on top of the scales.
{{ plot_div|indent(4)|safe }}


{% extends "includes/layout.html" %} {% from "govuk/components/error-summary/macro.njk" import govukErrorSummary %} {% from "govuk/components/fieldset/macro.njk" import govukFieldset %} {% from "govuk/components/input/macro.njk" import govukInput %} {% from "govuk/components/button/macro.njk" import govukButton %} {% from "widgets/addresslookup.html" import addressFinder %} {% block content %}


"""Featurization functions for amino acids."""
# Graphein
# Author: Arian Jamasb<EMAIL_ADDRESS>Eric Ma
# License: MIT
# Project Website: https://github.com/a-r-j/graphein
# Code Repository: https://github.com/a-r-j/graphein
import logging
from functools import lru_cache
from pathlib import Path
import pandas as pd
log = logging.getLogger(__name__)
[docs]@lru_cache()
def load_expasy_scales() -> pd.DataFrame:
"""
Load pre-downloaded EXPASY scales.
This helps with node featuarization.
The function is LRU-cached in memory for fast access
on each function call.
:returns: pd.DataFrame containing expasy scales
:rtype: pd.DataFrame
"""
log.debug(
f"Reading Expasy protein scales from: {Path(__file__).parent / 'amino_acid_properties.csv'}"
)
df = pd.read_csv(
Path(__file__).parent / "amino_acid_properties.csv", index_col=0
)
return df
[docs]@lru_cache()
def load_meiler_embeddings() -> pd.DataFrame:
"""
Load pre-downloaded Meiler embeddings.
This helps with node featurization.
The function is LRU-cached in memory for fast access
on each function call.
:returns: pd.DataFrame containing Meiler Embeddings from Meiler et al. 2001
:rtype: pd.DataFrame
"""
log.debug(
f"Reading meiler embeddings from: {Path(__file__).parent / 'meiler_embeddings.csv'}"
)
df = pd.read_csv(
Path(__file__).parent / "meiler_embeddings.csv", index_col=0
)
return df
[docs]def expasy_protein_scale(n, d) -> pd.Series:
"""
Return amino acid features that come from the EXPASY protein scale.
Source: https://web.expasy.org/protscale/
:param n: Node in a NetworkX graph
:param d: NetworkX node attributes.
:returns: pd.Series of amino acid features
:rtype: pd.Series
"""
df = load_expasy_scales()
amino_acid = d["residue_name"]
return df[amino_acid]
[docs]def meiler_embedding(n, d) -> pd.Series:
"""
Return amino acid features from reduced dimensional embeddings of amino acid physicochemical properties.
Source: https://link.springer.com/article/10.1007/s008940100038
doi: https://doi.org/10.1007/s008940100038
:param n: Node in a NetworkX graph
:param d: NetworkX node attributes.
:returns: pd.Series of amino acid features
:rtype: pd.Series
"""
df = load_meiler_embeddings()
amino_acid = d["residue_name"]
return df[amino_acid]


Notifications
All caught up !
Arjun Amgain
<EMAIL_ADDRESS>Home
People
Photos
Communities
Locations
Event
Hangouts
All
All
What's Hot
Nearby
Following
Family
Friends
Acquaintances
Arjun Amgain
Public - 34 minutes ago
Maney faces of Jhon Malkovich.
Best 90+ WordPress, Magneto, Open Cart e-Commerce Themes
moarthemes.com
+1


Methods
(inner) forEach(forEachCb, forEachThisArgopt) → {undefined}
Perform function on each stored value according to iteration sequence.
Parameters:
| Name | Type | Attributes | Description |
|---|---|---|---|
forEachCb |
forEachCb | Function to execute on each stored value. | |
forEachThisArg |
object |
<optional> |
Zero-based index **before which** to end extraction. |
Returns:
Undefined.
- Type
- undefined
(inner) getAsArray() → {Array}
Get stored values as array
Returns:
Array of stored values.
- Type
- Array
(inner) getByIndex(iObjectIndex) → {*}
Get value at index.
Parameters:
| Name | Type | Description |
|---|---|---|
iObjectIndex |
number | Index of value. |
Returns:
Value stored at index.
- Type
- *
(inner) getByName(iObjectName) → {*}
Get value by name.
Parameters:
| Name | Type | Description |
|---|---|---|
iObjectName |
string | Name of value. |
Returns:
Value stored at index.
- Type
- *
(inner) getIndexByName(iObjectName) → {number}
Get index of named value.
Parameters:
| Name | Type | Description |
|---|---|---|
iObjectName |
string | Name of value. |
Returns:
Index of named value.
- Type
- number
(inner) getLength() → {number}
Get number of stored values.
Returns:
Number of stored values.
- Type
- number
(inner) getNameByIndex(iObjectIndex) → {string}
Get name of value at index.
Parameters:
| Name | Type | Description |
|---|---|---|
iObjectIndex |
number | Index of value. |
Returns:
Name of value at index.
- Type
- string
(inner) indexOf(iObjectValue) → {*}
Returns the first index at which the given value can be found in the iteration sequence.
Parameters:
| Name | Type | Description |
|---|---|---|
iObjectValue |
* | Value to locate. |
Returns:
First index at which the given value can be found in the iteration sequence.
- Type
- *
(inner) nameOf(iObjectValue) → {*}
Returns the name of the first value in the iteration sequence to match the given value.
Parameters:
| Name | Type | Description |
|---|---|---|
iObjectValue |
* | Value to locate. |
Returns:
Name of the first value in the iteration sequence to match the given value.
- Type
- *
(inner) pop() → {*}
Removes the last value from the iteration sequence and returns that value.
Returns:
Removed element or undefined if the array was empty.
- Type
- *
(inner) push(iObjectName, iObjectValue) → {number}
Add a value to the end of the iteration sequence and return the number of stored values.
Parameters:
| Name | Type | Description |
|---|---|---|
iObjectName |
string | Name of value. |
iObjectValue |
* | Named value. |
Returns:
Number of stored values.
- Type
- number
(inner) setByIndex(iObjectIndex, iObjectValue)
Set value at index.
Parameters:
| Name | Type | Description |
|---|---|---|
iObjectIndex |
number | Index of value. |
iObjectValue |
* | Value at index. |
(inner) setByName(iObjectName, iObjectValue)
Set value by name.
Parameters:
| Name | Type | Description |
|---|---|---|
iObjectName |
string | Name of value. |
iObjectValue |
* | Named value. |
(inner) shift() → {*}
Removes the first value from the iteration sequence and returns that value.
Returns:
Removed element or undefined if the array was empty.
- Type
- *
(inner) slice(sliceBeginopt, sliceEndopt) → {Array}
Returns an excerpt of the iteration sequence as values in an array.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
sliceBegin |
number |
<optional> |
0 | Zero-based index at which to begin extraction. A negative index can be used, indicating an offset from the end of the sequence. |
sliceEnd |
number |
<optional> |
Zero-based index before which to end extraction. A negative index can be used, indicating an offset from the end of the sequence. Defaults to this.getLength(); |
Returns:
Array containing the extracted values.
- Type
- Array
(inner) unshift(iObjectName, iObjectValue) → {number}
Add a value to the start of the iteration sequence and return the number of stored values.
Parameters:
| Name | Type | Description |
|---|---|---|
iObjectName |
string | Name of value. |
iObjectValue |
* | Named value. |
Returns:
Number of stored values.
- Type
- number
Type Definitions
forEachCb(currentValue, index, array)
Callback for this.forEach.
Parameters:
| Name | Type | Description |
|---|---|---|
currentValue |
number | Stored value provided from a cloned array. |
index |
number | Index of current value. |
array |
number | Array containing stored values. Changes to array iteration order will not impact iteration order of stored values. |


WITNESS LIST
Transportation Committee
August 26, 2014 - 9:00 AM
County Authority to Utilize Tax Increment Financing/TRZ's
For:
Cassidy, C. Brian (Self)
Conley, Will (Hays County Commissioners Court)
On:
Bass, Robert (County Judges and Commissioners Association of Texas)
Dixon, Don (Self)
Gordy, Duane (CDEF)
LeBas, James (TxOGA)
Registering, but not testifying:
On:
Lee, Donald (Texas Conference of Urban Counties)
Rabeaux, Julie (Texas Department of Transportation)
Implementation of a Single Vehicle Inspection/Registration Sticker
On:
Bowie, RenEarl (Texas department of public safety)
Brewster, Whitney (TxDMV)
Findeisen, Les (Texas Trucking Association)
Registering, but not testifying:
On:
Kuntz, Jeremiah (Texas Department of Motor Vehicles)
Implementation of Legislation on Oversize/Overweight Vehicles
On:
Brewster, Whitney (TxDMV)
Harbeson, William (Txdmv)
Nordloh, Chris (Texas Department of Public Safety)
Registering, but not testifying:
On:
Archer, Jimmy (Texas Deparment of Motor Vehicles)
Rail, Grade Crossing Maintenance, Safety, and Closures
On:
Grindstaff, Elizabeth (Self; Texas Pacifico Transportation, ltd)
Steavens, Erik (Texas Department of Transportation)
Travis, Robert (Texas Department of Transportation)
State Funds for Roads in Areas Impacted by Energy Sector
On:
LeBas, James (TxOGA)
1
WITNESS LIST
On:
Mamula, Deb (Texas Oil and Gas Association)
Mamula, Debbra (Texas Oil and Gas Association)
Marek, Mark (Texas Department of Transportation)
Registering, but not testifying:
On:
Moseley, Jeff (Texas Transportation Commission)
TxDOT "Turn Back" Program
For:
Jordan, Jungus (Texas Municipal League)
On:
Dixon, Don (Self)
Marek, Mark (Texas Department of Transportation)
TxDOT Overview
On:
Barton, John (Texas Department of Transportation)
Moseley, Jeff (Texas Transportation Commission)
2


Submitted by Edro (not verified) on Fri, 13/01/2012 - 04:49.
Do you have a complete list of materials for both the input and output and all other caveats? We'd like to build our own, but want to make sure we get all of the appropriate materials. Thanks!
»
Re: Input modules
Submitted by voodoo (not verified) on Tue, 12/04/2011 - 02:16.
Can you recommend me which Hardware I require to develop a small project to measure Energy saved not too dissimliar to yours.
Having read your forum I'm already thinking you will save me a lot of work since the system you have is not too dissimar but I have not purchase any hardware yet and it looks like the arduino route is the way to go but which one ?
I have a system which currently switches off AC and lighting circuits for rental homes when the client is out of the premisses using a simple keyfob Timer and Relay circuit. I would like to develop a monitoring systems to show me energy saved using the efergy sensors which I already own.
I wish to Measure 2 analogue sources of Current (like 2x 110v on each line) using a small loop sensor which give me a small voltage change. Then I need to record the values and compare them to values obtained prior to them removing the keyfob which generates another signal to tell me to start counting time and multiplying that by time elapsed and the energy used thus giving me the amount of KWH saved between Client out and Client In.
I wish to store the results to show me how much energy has been saved since the last reset say and display this on a LCD (Louis project with 16 x2 chars LCD should do) which could also show me lapsed energy saved until the key is returned on the keyfob.
I have looked at the Arduino Uno option with Makershield but there are other options which seems more attractive given that I will want a more permanent solution once developped.
I Have yet to purchase any of these but would like guidance as to which combination I should use to develop then build my boards--- given that I might want to make about 20 of these to hand out to my clients. The Programming side looks fairly comprehensible as I was a C programmer.
I will start with building a dual Current sensor module using your code as guidance and see how I do before I need help.
Background : I'm Responsible for switching over 100KW of energy (Client cannot leave without taking key and AC and lights switch off automatically once they are gone) in 25 rental homes in a tourist town in Costa Rica and live here during the UK winters - this project is to pay for my beers and to give something back to the environment !
Jean
»
Re: Input modules
Submitted by Stelios (not verified) on Sat, 19/06/2010 - 11:22.
Hello Trystan.
I would like to try and replicate your project but using a different uC.
I haven't figured out how fast you need to sample the ADC for the CT clamp. I would like to know this number since it will help me select a proper uC.
Thanks,
Stelios
»
Re: Input modules
Submitted by TrystanLea on Fri, 25/06/2010 - 09:45.
Hello Stelios
In the sketch the part
for (int n=0; n<numberOfSamples; n++) { ... }
takes 1121ms for 3000 readings = 2674Hz
But this included all the analog reading, summing, multiplying, digital high pass etc
The ADC sample rate of the ATmega 328 is set at its default rate which corresponds to about 9600Hz.
Trystan
»
Re: Input modules
Submitted by Dave (not verified) on Tue, 15/06/2010 - 00:27.
I just started working on this, I have it breadboarded for a single CT (100A) and managed to calibrate it for current. I can't find the sketch for version 3. I am having a ton of trouble calibrating it under version 2. I'm in the US and where I live we have peak demand metering. This means that during peak periods they take the highest hour's KWH usage and charge you a ton for that single hour. Needless to say a meter that tells me the instantaneous usage would save me a ton of money. My plan is to use contactors to shed load as the load increases. I already shed the water heater during peak periods but I need to be able to tell what is being used NOW, not an hour ago like the meter reading tells me. When I can get the device calibrated somewhat I'll add a second CT and move it to the meter location.
Help me find the version 3 sketch please.
dave
»
Re: Input modules
Submitted by TrystanLea on Tue, 15/06/2010 - 09:07.
Hello Dave
Its on the how to build it page. But here is the link to save time: basicmonitor.tar.gz
All the best with your project!
Trystan
»
Re: Input modules
Submitted by Dave (not verified) on Wed, 16/06/2010 - 20:33.
Thanks, got the files and completed the breadboard for a single CT. Works great. Power factor is an annoying item. I went through the same iterations as you in integrating voltage and current and getting a good figure for real power. Similarly, I integrated power and then averaged it and tried to calculate the power factor.  I agree with you that the CT sensor and the power transformer both add inductance to the circuit that affect the power factor measurement. Interestingly, I did some checking on the killawatt and found that it has trouble with power factor, especially when the power levels are low.
Now a question. In your opinion should I just tie the two CTs in series and adjust the burden resistor for the split phase power in the US, or should I integrate the two of them separately? There's trade offs to both methods, but the big one seems to be processing time since we have to use float in the various calculations.
Also, the low pass filter you discovered and implemented is fantastic. That thing adjusts itself and removes the harmonics from the digital sampling really well. I implemented a complete measurement program without it and worked through the calibration and had exactly the same problems you did with various noise sources making the readings erratic. That filter eliminated that problem completely.
Really good job on this, thanks again.
»
Re: Input modules
Submitted by Michael (not verified) on Mon, 19/04/2010 - 12:18.
Hi Tristan,
Excellent website - have build a PDU (PowerDistributionUnit) for 19" Racks based on your code with 10
Current Transformers.
Data is polled by a Perl script and stored in a RRD Database. Graphs are generated by rrd.cgi on a Webserver...
Submitted by TrystanLea on Tue, 27/04/2010 - 15:47.
Hey Micheal, that's really cool, excellent work! Google translate works really well so I can follow what your doing. Like I said to Ben below, and I know you have your own site, but if you ever want to use the openenergymonitor blog to tell people about your work, even just a link through to your site you would be welcome, just email me.
Trystan
»
Re: Input modules
Submitted by Guest (not verified) on Sat, 17/04/2010 - 14:35.
Fantastic project. I have built it up and started logging data to mySQL using an ethernet shield. I've also brought your "scope" code into the main monitoring code, so I can see the waveform while monitoring.
Re: Input modules
Do you have a complete list of materials for both the input and output and all other caveats? We'd like to build our own, but want to make sure we get all of the appropriate materials. Thanks!
Re: Input modules
Can you recommend me which Hardware I require to develop a small project to measure Energy saved not too dissimliar to yours.
Having read your forum I'm already thinking you will save me a lot of work since the system you have is not too dissimar but I have not purchase any hardware yet and it looks like the arduino route is the way to go but which one ?
I have a system which currently switches off AC and lighting circuits for rental homes when the client is out of the premisses using a simple keyfob Timer and Relay circuit. I would like to develop a monitoring systems to show me energy saved using the efergy sensors which I already own.
I wish to Measure 2 analogue sources of Current (like 2x 110v on each line) using a small loop sensor which give me a small voltage change. Then I need to record the values and compare them to values obtained prior to them removing the keyfob which generates another signal to tell me to start counting time and multiplying that by time elapsed and the energy used thus giving me the amount of KWH saved between Client out and Client In.
I wish to store the results to show me how much energy has been saved since the last reset say and display this on a LCD (Louis project with 16 x2 chars LCD should do) which could also show me lapsed energy saved until the key is returned on the keyfob.
I have looked at the Arduino Uno option with Makershield but there are other options which seems more attractive given that I will want a more permanent solution once developped.
1) Ardweeny + Protoshield
2) Prototino
3) Boardwino
I Have yet to purchase any of these but would like guidance as to which combination I should use to develop then build my boards--- given that I might want to make about 20 of these to hand out to my clients. The Programming side looks fairly comprehensible as I was a C programmer.
I will start with building a dual Current sensor module using your code as guidance and see how I do before I need help.
Background : I'm Responsible for switching over 100KW of energy (Client cannot leave without taking key and AC and lights switch off automatically once they are gone) in 25 rental homes in a tourist town in Costa Rica and live here during the UK winters - this project is to pay for my beers and to give something back to the environment !
Jean
Re: Input modules
Hello Trystan.
I would like to try and replicate your project but using a different uC.
I haven't figured out how fast you need to sample the ADC for the CT clamp. I would like to know this number since it will help me select a proper uC.
Thanks,
Stelios
Re: Input modules
Hello Stelios
In the sketch the part
for (int n=0; n<numberOfSamples; n++) { ... }
takes 1121ms for 3000 readings = 2674Hz
But this included all the analog reading, summing, multiplying, digital high pass etc
The ADC sample rate of the ATmega 328 is set at its default rate which corresponds to about 9600Hz.
Trystan
Re: Input modules
I just started working on this, I have it breadboarded for a single CT (100A) and managed to calibrate it for current. I can't find the sketch for version 3. I am having a ton of trouble calibrating it under version 2. I'm in the US and where I live we have peak demand metering. This means that during peak periods they take the highest hour's KWH usage and charge you a ton for that single hour. Needless to say a meter that tells me the instantaneous usage would save me a ton of money. My plan is to use contactors to shed load as the load increases. I already shed the water heater during peak periods but I need to be able to tell what is being used NOW, not an hour ago like the meter reading tells me. When I can get the device calibrated somewhat I'll add a second CT and move it to the meter location.
Help me find the version 3 sketch please.
dave
Re: Input modules
Hello Dave
Its on the how to build it page. But here is the link to save time: basicmonitor.tar.gz
All the best with your project!
Trystan
Re: Input modules
Thanks, got the files and completed the breadboard for a single CT. Works great. Power factor is an annoying item. I went through the same iterations as you in integrating voltage and current and getting a good figure for real power. Similarly, I integrated power and then averaged it and tried to calculate the power factor.  I agree with you that the CT sensor and the power transformer both add inductance to the circuit that affect the power factor measurement. Interestingly, I did some checking on the killawatt and found that it has trouble with power factor, especially when the power levels are low.
Now a question. In your opinion should I just tie the two CTs in series and adjust the burden resistor for the split phase power in the US, or should I integrate the two of them separately? There's trade offs to both methods, but the big one seems to be processing time since we have to use float in the various calculations.
Also, the low pass filter you discovered and implemented is fantastic. That thing adjusts itself and removes the harmonics from the digital sampling really well. I implemented a complete measurement program without it and worked through the calibration and had exactly the same problems you did with various noise sources making the readings erratic. That filter eliminated that problem completely.
Really good job on this, thanks again.
Re: Input modules
Hi Tristan,
Excellent website - have build a PDU (PowerDistributionUnit) for 19" Racks based on your code with 10
Current Transformers.
Data is polled by a Perl script and stored in a RRD Database. Graphs are generated by rrd.cgi on a Webserver...
http://www.komputer.de/wordpress/?p=8
Sorry but it's in german
Michael
Re: Input modules
Hey Micheal, that's really cool, excellent work! Google translate works really well so I can follow what your doing. Like I said to Ben below, and I know you have your own site, but if you ever want to use the openenergymonitor blog to tell people about your work, even just a link through to your site you would be welcome, just email me.
Trystan
Re: Input modules
Fantastic project. I have built it up and started logging data to mySQL using an ethernet shield. I've also brought your "scope" code into the main monitoring code, so I can see the waveform while monitoring.
http://energy.bbarker.co.uk
I think I may try a display unit next - I've been looking at how you built yours.
Thanks for the writeup,
Ben


|
Livox SDK API
V2.2.0
|
Go to the source code of this file.
Typedefs | |
| typedef void(* | DeviceBroadcastCallback) (const BroadcastDeviceInfo *info) |
| typedef void(* | DeviceStateUpdateCallback) (const DeviceInfo *device, DeviceEvent type) |
| typedef void(* | DeviceInformationCallback) (livox_status status, uint8_t handle, DeviceInformationResponse *response, void *client_data) |
| typedef void(* | DataCallback) (uint8_t handle, LivoxEthPacket *data, uint32_t data_num, void *client_data) |
| typedef void(* | CommonCommandCallback) (livox_status status, uint8_t handle, uint8_t response, void *client_data) |
| typedef void(* | ErrorMessageCallback) (livox_status status, uint8_t handle, ErrorMessage *message) |
| typedef void(* | GetDeviceIpInformationCallback) (livox_status status, uint8_t handle, GetDeviceIpModeResponse *response, void *client_data) |
| typedef void(* | SetDeviceParametersCallback) (livox_status status, uint8_t handle, DeviceParameterResponse *response, void *client_data) |
| typedef void(* | GetDeviceParametersCallback) (livox_status status, uint8_t handle, GetDeviceParameterResponse *response, void *client_data) |
| typedef void(* | DeviceResetParametersCallback) (livox_status status, uint8_t handle, DeviceParameterResponse *response, void *client_data) |
| typedef void(* | HubQueryLidarInformationCallback) (livox_status status, uint8_t handle, HubQueryLidarInformationResponse *response, void *client_data) |
| typedef void(* | HubSetModeCallback) (livox_status status, uint8_t handle, HubSetModeResponse *response, void *client_data) |
| typedef void(* | HubQueryLidarStatusCallback) (livox_status status, uint8_t handle, HubQueryLidarStatusResponse *response, void *client_data) |
| typedef void(* | HubSetExtrinsicParameterCallback) (livox_status status, uint8_t handle, HubSetExtrinsicParameterResponse *response, void *client_data) |
| typedef void(* | HubGetExtrinsicParameterCallback) (livox_status status, uint8_t handle, HubGetExtrinsicParameterResponse *response, void *client_data) |
| typedef void(* | HubRainFogSuppressCallback) (livox_status status, uint8_t handle, HubRainFogSuppressResponse *response, void *client_data) |
| typedef void(* | HubQuerySlotPowerStatusCallback) (livox_status status, uint8_t handle, HubQuerySlotPowerStatusResponse *response, void *client_data) |
| typedef void(* | HubFanControlCallback) (livox_status status, uint8_t handle, HubFanControlResponse *response, void *client_data) |
| typedef void(* | HubGetFanStateCallback) (livox_status status, uint8_t handle, HubGetFanStateResponse *response, void *client_data) |
| typedef void(* | HubSetPointCloudReturnModeCallback) (livox_status status, uint8_t handle, HubSetPointCloudReturnModeResponse *response, void *client_data) |
| typedef void(* | HubGetPointCloudReturnModeCallback) (livox_status status, uint8_t handle, HubGetPointCloudReturnModeResponse *response, void *client_data) |
| typedef void(* | HubSetImuPushFrequencyCallback) (livox_status status, uint8_t handle, HubSetImuPushFrequencyResponse *response, void *client_data) |
| typedef void(* | HubGetImuPushFrequencyCallback) (livox_status status, uint8_t handle, HubGetImuPushFrequencyResponse *response, void *client_data) |
| typedef void(* | LidarGetExtrinsicParameterCallback) (livox_status status, uint8_t handle, LidarGetExtrinsicParameterResponse *response, void *client_data) |
| typedef void(* | LidarGetFanStateCallback) (livox_status status, uint8_t handle, LidarGetFanStateResponse *response, void *client_data) |
| typedef void(* | LidarGetPointCloudReturnModeCallback) (livox_status status, uint8_t handle, LidarGetPointCloudReturnModeResponse *response, void *client_data) |
| typedef void(* | LidarGetImuPushFrequencyCallback) (livox_status status, uint8_t handle, LidarGetImuPushFrequencyResponse *response, void *client_data) |
| typedef void(* CommonCommandCallback) (livox_status status, uint8_t handle, uint8_t response, void *client_data) |
Function type of callback with 1 byte of response.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 183 of file livox_sdk.h.
| typedef void(* DataCallback) (uint8_t handle, LivoxEthPacket *data, uint32_t data_num, void *client_data) |
Callback function for receiving point cloud data.
| handle | device handle. |
| data | device's data. |
| data_num | number of points in data. |
| client_data | user data associated with the command. |
Definition at line 159 of file livox_sdk.h.
| typedef void(* DeviceBroadcastCallback) (const BroadcastDeviceInfo *info) |
SetBroadcastCallback
response callback function.
| info | information of the broadcast device, becomes invalid after the function returns. |
Definition at line 73 of file livox_sdk.h.
| typedef void(* DeviceInformationCallback) (livox_status status, uint8_t handle, DeviceInformationResponse *response, void *client_data) |
Function type of callback that queries device's information.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 138 of file livox_sdk.h.
| typedef void(* DeviceResetParametersCallback) (livox_status status, uint8_t handle, DeviceParameterResponse *response, void *client_data) |
DeviceResetParameters'
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 431 of file livox_sdk.h.
| typedef void(* DeviceStateUpdateCallback) (const DeviceInfo *device, DeviceEvent type) |
SetDeviceStateUpdateCallback
response callback function.
| device | information of the connected device. |
| type | the update type that indicates connection/disconnection of the device or change of working state. |
Definition at line 87 of file livox_sdk.h.
| typedef void(* ErrorMessageCallback) (livox_status status, uint8_t handle, ErrorMessage *message) |
Callback of the error status message. kStatusSuccess on successful return, see LivoxStatus for other
| handle | device handle. |
| response | response from the device. |
Definition at line 242 of file livox_sdk.h.
| typedef void(* GetDeviceIpInformationCallback) (livox_status status, uint8_t handle, GetDeviceIpModeResponse *response, void *client_data) |
Callback function that gets device's IP information.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 300 of file livox_sdk.h.
| typedef void(* GetDeviceParametersCallback) (livox_status status, uint8_t handle, GetDeviceParameterResponse *response, void *client_data) |
GetDeviceParameters'
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 366 of file livox_sdk.h.
| typedef void(* HubFanControlCallback) (livox_status status, uint8_t handle, HubFanControlResponse *response, void *client_data) |
HubFanControl
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 633 of file livox_sdk.h.
| typedef void(* HubGetExtrinsicParameterCallback) (livox_status status, uint8_t handle, HubGetExtrinsicParameterResponse *response, void *client_data) |
HubGetExtrinsicParameter
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 559 of file livox_sdk.h.
| typedef void(* HubGetFanStateCallback) (livox_status status, uint8_t handle, HubGetFanStateResponse *response, void *client_data) |
HubGetFanControl
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 656 of file livox_sdk.h.
| typedef void(* HubGetImuPushFrequencyCallback) (livox_status status, uint8_t handle, HubGetImuPushFrequencyResponse *response, void *client_data) |
HubGetImuPushFrequency
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 760 of file livox_sdk.h.
| typedef void(* HubGetPointCloudReturnModeCallback) (livox_status status, uint8_t handle, HubGetPointCloudReturnModeResponse *response, void *client_data) |
HubGetPointCloudReturnMode
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 708 of file livox_sdk.h.
| typedef void(* HubQueryLidarInformationCallback) (livox_status status, uint8_t handle, HubQueryLidarInformationResponse *response, void *client_data) |
HubQueryLidarInformation
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 465 of file livox_sdk.h.
| typedef void(* HubQueryLidarStatusCallback) (livox_status status, uint8_t handle, HubQueryLidarStatusResponse *response, void *client_data) |
HubQueryLidarStatus
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 506 of file livox_sdk.h.
| typedef void(* HubQuerySlotPowerStatusCallback) (livox_status status, uint8_t handle, HubQuerySlotPowerStatusResponse *response, void *client_data) |
HubQuerySlotPowerStatus
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 615 of file livox_sdk.h.
| typedef void(* HubRainFogSuppressCallback) (livox_status status, uint8_t handle, HubRainFogSuppressResponse *response, void *client_data) |
HubRainFogSuppress
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 589 of file livox_sdk.h.
| typedef void(* HubSetExtrinsicParameterCallback) (livox_status status, uint8_t handle, HubSetExtrinsicParameterResponse *response, void *client_data) |
HubSetExtrinsicParameter
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 533 of file livox_sdk.h.
| typedef void(* HubSetImuPushFrequencyCallback) (livox_status status, uint8_t handle, HubSetImuPushFrequencyResponse *response, void *client_data) |
HubSetImuPushFrequency
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 734 of file livox_sdk.h.
| typedef void(* HubSetModeCallback) (livox_status status, uint8_t handle, HubSetModeResponse *response, void *client_data) |
HubSetMode
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 486 of file livox_sdk.h.
| typedef void(* HubSetPointCloudReturnModeCallback) (livox_status status, uint8_t handle, HubSetPointCloudReturnModeResponse *response, void *client_data) |
HubSetPointCloudReturnMode
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 682 of file livox_sdk.h.
| typedef void(* LidarGetExtrinsicParameterCallback) (livox_status status, uint8_t handle, LidarGetExtrinsicParameterResponse *response, void *client_data) |
LidarGetExtrinsicParameter
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 829 of file livox_sdk.h.
| typedef void(* LidarGetFanStateCallback) (livox_status status, uint8_t handle, LidarGetFanStateResponse *response, void *client_data) |
LidarGetFanState
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 882 of file livox_sdk.h.
| typedef void(* LidarGetImuPushFrequencyCallback) (livox_status status, uint8_t handle, LidarGetImuPushFrequencyResponse *response, void *client_data) |
LidaGetImuPushFrequency
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 950 of file livox_sdk.h.
| typedef void(* LidarGetPointCloudReturnModeCallback) (livox_status status, uint8_t handle, LidarGetPointCloudReturnModeResponse *response, void *client_data) |
LidaGetPointCloudReturnMode
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 916 of file livox_sdk.h.
| typedef void(* SetDeviceParametersCallback) (livox_status status, uint8_t handle, DeviceParameterResponse *response, void *client_data) |
SetDeviceParameters'
response callback function.
| status | kStatusSuccess on successful return, kStatusTimeout on timeout, see LivoxStatus for other error code. |
| handle | device handle. |
| response | response from the device. |
| client_data | user data associated with the command. |
Definition at line 333 of file livox_sdk.h.
| livox_status AddHubToConnect | ( | const char * | broadcast_code, |
| uint8_t * | handle | ||
| ) |
Add a broadcast code to the connecting list and only devices with broadcast code in this list will be connected. The broadcast code is unique for every device.
| broadcast_code | device's broadcast code. |
| handle | device handle. For Livox Hub, the handle is always 31; for LiDAR units connected to the Livox Hub, the corresponding handle is (slot-1)*3+id-1. |
| livox_status AddLidarToConnect | ( | const char * | broadcast_code, |
| uint8_t * | handle | ||
| ) |
Add a broadcast code to the connecting list and only devices with broadcast code in this list will be connected. The broadcast code is unique for every device.
| broadcast_code | device's broadcast code. |
| handle | device handle. The handle is the same as the order calling AddLidarToConnect starting from 0. |
| livox_status DeviceResetAllParameters | ( | uint8_t | handle, |
| DeviceResetParametersCallback | cb, | ||
| void * | client_data | ||
| ) |
Reset LiDAR/Hub's All Parameters, see DeviceParamKeyName for all parameters.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status DeviceResetParameters | ( | uint8_t | handle, |
| DeviceParamKeyName * | keys, | ||
| uint8_t | num, | ||
| DeviceResetParametersCallback | cb, | ||
| void * | client_data | ||
| ) |
Reset LiDAR/Hub's Parameters, see DeviceParamKeyName for all parameters.
| handle | device handle. |
| keys | keys to reset, see DeviceParamKeyName for all parameters. |
| num | num of keys to reset. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| void DisableConsoleLogger | ( | ) |
Disable console log output.
| livox_status DisconnectDevice | ( | uint8_t | handle, |
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Disconnect divice.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status GetConnectedDevices | ( | DeviceInfo * | devices, |
| uint8_t * | size | ||
| ) |
Get all connected devices' information.
| devices | list of connected devices' information. |
| size | number of devices connected. |
| livox_status GetDeviceIpInformation | ( | uint8_t | handle, |
| GetDeviceIpInformationCallback | cb, | ||
| void * | client_data | ||
| ) |
Get device's IP mode.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| void GetLivoxSdkVersion | ( | LivoxSdkVersion * | version | ) |
Return SDK's version information in a numeric form.
| version | Pointer to a version structure for returning the version information. |
| livox_status HubControlSlotPower | ( | HubControlSlotPowerRequest * | req, |
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Toggle the power supply of designated slots.
| req | request whether to enable or disable the power of designated slots. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubExtrinsicParameterCalculation | ( | bool | enable, |
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Turn on or off the calculation of extrinsic parameters.
| enable | the request whether enable or disable calculating the extrinsic parameters. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubFanControl | ( | HubFanControlRequest * | req, |
| uint16_t | length, | ||
| HubFanControlCallback | cb, | ||
| void * | client_data | ||
| ) |
Turn on or off the fan of LiDAR unit connected to the Livox Hub.
| req | Fan control of LiDAR units. |
| length | length of req. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubGetExtrinsicParameter | ( | HubGetExtrinsicParameterCallback | cb, |
| void * | client_data | ||
| ) |
Get extrinsic parameters of LiDAR units connected to the Livox Hub.
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubGetFanState | ( | HubGetFanStateRequest * | req, |
| uint16_t | length, | ||
| HubGetFanStateCallback | cb, | ||
| void * | client_data | ||
| ) |
Get fan state of LiDAR unit connected to the Livox Hub.
| req | Get fan state of LiDAR units. |
| length | length of req. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubGetImuPushFrequency | ( | HubGetImuPushFrequencyRequest * | req, |
| uint16_t | length, | ||
| HubGetImuPushFrequencyCallback | cb, | ||
| void * | client_data | ||
| ) |
Get IMU push frequency of LiDAR units connected to the Livox Hub.
| req | get IMU push frequency of LiDAR units. |
| length | the request's length. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubGetLidarHandle | ( | uint8_t | slot, |
| uint8_t | id | ||
| ) |
Get the LiDAR unit handle used in the Livox Hub data callback function from slot and id.
| slot | Livox Hub's slot. |
| id | Livox Hub's id. |
| livox_status HubGetPointCloudReturnMode | ( | HubGetPointCloudReturnModeRequest * | req, |
| uint16_t | length, | ||
| HubGetPointCloudReturnModeCallback | cb, | ||
| void * | client_data | ||
| ) |
Get point cloud return mode of LiDAR unit connected to the Livox Hub.
| req | Get point cloud return mode of LiDAR units. |
| length | length of req. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubQueryLidarInformation | ( | HubQueryLidarInformationCallback | cb, |
| void * | client_data | ||
| ) |
Query the information of LiDARs connected to the hub.
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubQueryLidarStatus | ( | HubQueryLidarStatusCallback | cb, |
| void * | client_data | ||
| ) |
Get the state of LiDAR units connected to the Livox Hub.
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubQuerySlotPowerStatus | ( | HubQuerySlotPowerStatusCallback | cb, |
| void * | client_data | ||
| ) |
Get the power supply state of each hub slot.
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubRainFogSuppress | ( | HubRainFogSuppressRequest * | req, |
| uint16_t | length, | ||
| HubRainFogSuppressCallback | cb, | ||
| void * | client_data | ||
| ) |
Toggling the rain and fog mode for lidars connected to the hub.
| req | the request whether open or close the rain and fog mode. |
| length | the request's length. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubSetExtrinsicParameter | ( | HubSetExtrinsicParameterRequest * | req, |
| uint16_t | length, | ||
| HubSetExtrinsicParameterCallback | cb, | ||
| void * | client_data | ||
| ) |
Set extrinsic parameters of LiDAR units connected to the Livox Hub.
| req | the parameters to write. |
| length | the request's length. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubSetImuPushFrequency | ( | HubSetImuPushFrequencyRequest * | req, |
| uint16_t | length, | ||
| HubSetImuPushFrequencyCallback | cb, | ||
| void * | client_data | ||
| ) |
Set IMU push frequency of LiDAR units connected to the Livox Hub.
| req | set IMU push frequency of LiDAR units. |
| length | the request's length. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubSetMode | ( | HubSetModeRequest * | req, |
| uint16_t | length, | ||
| HubSetModeCallback | cb, | ||
| void * | client_data | ||
| ) |
Set the mode of LiDAR unit connected to the Livox Hub.
| req | mode configuration of LiDAR units. |
| length | length of req. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubSetPointCloudReturnMode | ( | HubSetPointCloudReturnModeRequest * | req, |
| uint16_t | length, | ||
| HubSetPointCloudReturnModeCallback | cb, | ||
| void * | client_data | ||
| ) |
Set point cloud return mode of LiDAR units connected to the Livox Hub.
| req | set point cloud return mode of LiDAR units. |
| length | the request's length. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubStartSampling | ( | CommonCommandCallback | cb, |
| void * | client_data | ||
| ) |
Start hub sampling.
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status HubStopSampling | ( | CommonCommandCallback | cb, |
| void * | client_data | ||
| ) |
Stop the Livox Hub's sampling.
| cb | callback for the command. |
| client_data | user data associated with the command. |
| bool Init | ( | ) |
Initialize the SDK.
| livox_status LidarDisableHighSensitivity | ( | uint8_t | handle, |
| SetDeviceParametersCallback | cb, | ||
| void * | client_data | ||
| ) |
LiDAR Disable HighSensitivity.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarEnableHighSensitivity | ( | uint8_t | handle, |
| SetDeviceParametersCallback | cb, | ||
| void * | client_data | ||
| ) |
LiDAR Enable HighSensitivity.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarGetExtrinsicParameter | ( | uint8_t | handle, |
| LidarGetExtrinsicParameterCallback | cb, | ||
| void * | client_data | ||
| ) |
Get LiDAR extrinsic parameters.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarGetFanState | ( | uint8_t | handle, |
| LidarGetFanStateCallback | cb, | ||
| void * | client_data | ||
| ) |
Get state of the fan.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarGetHighSensitivityState | ( | uint8_t | handle, |
| GetDeviceParametersCallback | cb, | ||
| void * | client_data | ||
| ) |
LiDAR Get HighSensitivity State.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarGetImuPushFrequency | ( | uint8_t | handle, |
| LidarGetImuPushFrequencyCallback | cb, | ||
| void * | client_data | ||
| ) |
Get IMU push frequency.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarGetPointCloudReturnMode | ( | uint8_t | handle, |
| LidarGetPointCloudReturnModeCallback | cb, | ||
| void * | client_data | ||
| ) |
Get point cloud return mode.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarGetScanPattern | ( | uint8_t | handle, |
| GetDeviceParametersCallback | cb, | ||
| void * | client_data | ||
| ) |
LiDAR Get Scan Pattern.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarGetSlotNum | ( | uint8_t | handle, |
| GetDeviceParametersCallback | cb, | ||
| void * | client_data | ||
| ) |
LiDAR Get Slot Number.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarRainFogSuppress | ( | uint8_t | handle, |
| bool | enable, | ||
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Enable and disable the rain/fog suppression.
| handle | device handle. |
| enable | enable and disable the rain/fog suppression. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarSetExtrinsicParameter | ( | uint8_t | handle, |
| LidarSetExtrinsicParameterRequest * | req, | ||
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Set LiDAR extrinsic parameters.
| handle | device handle. |
| req | the parameters to write. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarSetImuPushFrequency | ( | uint8_t | handle, |
| ImuFreq | freq, | ||
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Set IMU push frequency.
| handle | device handle. |
| freq | IMU push frequency. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarSetMode | ( | uint8_t | handle, |
| LidarMode | mode, | ||
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Set LiDAR mode.
| handle | device handle. |
| mode | the mode to change. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarSetPointCloudReturnMode | ( | uint8_t | handle, |
| PointCloudReturnMode | mode, | ||
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Set point cloud return mode.
| handle | device handle. |
| mode | point cloud return mode. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarSetRmcSyncTime | ( | uint8_t | handle, |
| const char * | rmc, | ||
| uint16_t | rmc_length, | ||
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Set GPRMC formate synchronization time.
| handle | device handle. |
| rmc | GPRMC/GNRMC format data. |
| rmc_length | lenth of gprmc. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarSetScanPattern | ( | uint8_t | handle, |
| LidarScanPattern | pattern, | ||
| SetDeviceParametersCallback | cb, | ||
| void * | client_data | ||
| ) |
LiDAR Set Scan Pattern.
| handle | device handle. |
| pattern | scan pattern of LiDAR, see LidarScanPattern for detail. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarSetSlotNum | ( | uint8_t | handle, |
| uint8_t | slot, | ||
| SetDeviceParametersCallback | cb, | ||
| void * | client_data | ||
| ) |
LiDAR Set Slot Number.
| handle | device handle. |
| slot | slot number of LiDAR, range from 1 to 9. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarSetUtcSyncTime | ( | uint8_t | handle, |
| LidarSetUtcSyncTimeRequest * | req, | ||
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Set UTC formate synchronization time.
| handle | device handle. |
| req | UTC format data. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarStartSampling | ( | uint8_t | handle, |
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Start LiDAR sampling.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarStopSampling | ( | uint8_t | handle, |
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Stop LiDAR sampling.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarTurnOffFan | ( | uint8_t | handle, |
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Turn off the fan.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status LidarTurnOnFan | ( | uint8_t | handle, |
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Turn on the fan.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status QueryDeviceInformation | ( | uint8_t | handle, |
| DeviceInformationCallback | cb, | ||
| void * | client_data | ||
| ) |
Command to query device's information.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status RebootDevice | ( | uint8_t | handle, |
| uint16_t | timeout, | ||
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Reboot device.
| handle | device handle. |
| timeout | reboot device after [timeout] ms. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| void SaveLoggerFile | ( | ) |
Save the log file.
| void SetBroadcastCallback | ( | DeviceBroadcastCallback | cb | ) |
Set the callback of listening device broadcast message. When broadcast message is received from Livox Hub/LiDAR, cb is called.
| cb | callback for device broadcast. |
| livox_status SetCartesianCoordinate | ( | uint8_t | handle, |
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Change point cloud coordinate system to cartesian coordinate.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| void SetDataCallback | ( | uint8_t | handle, |
| DataCallback | cb, | ||
| void * | client_data | ||
| ) |
Set the callback to receive point cloud data. Only one callback is supported for a specific device. Set the point cloud data callback before beginning sampling.
| handle | device handle. |
| cb | callback to receive point cloud data. |
| client_data | user data associated with the command. |
| void SetDeviceStateUpdateCallback | ( | DeviceStateUpdateCallback | cb | ) |
Add a callback for device connection or working state changing event.
| cb | callback for device connection/disconnection. |
| livox_status SetDynamicIp | ( | uint8_t | handle, |
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Set device's dynamic IP mode.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status SetErrorMessageCallback | ( | uint8_t | handle, |
| ErrorMessageCallback | cb | ||
| ) |
Add error status callback for the device. error code.
| handle | device handle. |
| cb | callback for the command. |
| livox_status SetSphericalCoordinate | ( | uint8_t | handle, |
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Change point cloud coordinate system to spherical coordinate.
| handle | device handle. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status SetStaticDynamicIP | ( | uint8_t | handle, |
| SetDeviceIPModeRequest * | req, | ||
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Set device's IP mode.
| handle | device handle. |
| req | request sent to device. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| livox_status SetStaticIp | ( | uint8_t | handle, |
| SetStaticDeviceIpModeRequest * | req, | ||
| CommonCommandCallback | cb, | ||
| void * | client_data | ||
| ) |
Set device's static IP mode.
| handle | device handle. |
| req | request sent to device. |
| cb | callback for the command. |
| client_data | user data associated with the command. |
| bool Start | ( | ) |
Start the device scanning routine which runs on a separate thread.
| void Uninit | ( | ) |
Uninitialize the SDK.


--- layout: home search_exclude: true image: images/logo.png --- Welcome! This is a repository where I host all my personal data science projects.


Hello! I’m Ella Kang, a grade 11 student in Canada. I’m passionate about everything related to STEM and I joined Magnify as a member of Art and Partnership teams. Through Magnify Wellness, I hope to bring impactful changes in society and contribute to promoting positive mental health for everyone!
.Hi, I'm Saavi, a freshman in high school in Texas. I joined Magnify Wellness because their mission is amazing and I love to help others!
.Hello, my name is Gretel Tassah and I’m a senior in high school from Minnesota. I write and create graphics for Magnify Wellness. In 2020, I was awarded the NCWIT Aspirations in Computing Award, Quest for Excellence New American Award, and named a QuestBridge National College Match Finalist. In my free time I enjoy spending time with friends/family and learning how to code :)
.Emily Vo is a high school senior from South Florida. She enjoys watching foreign films, reading sci-fi novels, and learning about computer science. Emily is also passionate about environmental issues and combating climate injustice through STEM. In her free time, she also enjoys hiking and taking naps!
.Mandy Lieng is currently a junior in high school and a member of Magnify’s Art Team. She is passionate about art and interested in pursuing a career in UI/UX design. In her free time, she loves to draw and create new playlists.
.Rebecca Hong is currently a junior in high school from Fullerton and is part of Magnify’s Art Team. She is passionate about mental health support and hopes to pursue a study in psychology. In her free time, she enjoys discovering new music and growing her art skills.
.Ferduse Rahman is a computer science student at Hunter College who has a strong interest in making an impact through tech and art. She is a member of the tech and art team at Magnify Wellness.
.