Nyzo version 530 (commit on GitHub) adds the Micropay server and client.
This version adds two new run modes: the Micropay server and the Micropay client. It also affects the command-line client.
This is a large commit, but the changes are all in systems that interact externally with the verifiers. The internal workings of the verifier and the sentinel are unaffected, so this version does not introduce any new concerns regarding the security or efficiency of blockchain processing.
A new configuration file was added for the Micropay server. This follows the same pattern as the files provided for the verifier and sentinel.
In Message.fetchFromRandomNode(), the new MicropayServer run mode has been added as a consumer of ClientNodeManager.randomNode(). As will be seen later in these notes, the MicropayServer run mode currently shares the client's blockchain-tracking functionality. They have similar relationships to the mesh: neither services incoming Nyzo messages and neither will ever produce a block.
In RunMode, MicropayServer and MicropayClient have been added. The Micropay server is a simple but fully functioning web server that collects Nyzo payments before allowing access to premium resources. The Micropay client is a lightweight local application that allows a user to interact with Micropay servers.
In ClientTransactionUtil, the createAndSendTransaction() methods have been refactored for readability and to expose intermediate calculations. The suggestedTransactionTimestamp() method provides a timestamp that will allow for a new transaction to be created that will be approved in a reasonable amount of time even if blockchain processing has fallen behind. This calculation was previously performed in the createAndSendTransaction() method, and it is now also used by the Micropay server to produce suggested timestamps for Micropay strings.
Refactoring of the createAndSendTransaction() method did not change its behavior. However, when an IP address and port are not provided, sendTransactionToCycle() has been replaced with sendTransactionToExpectedVerifier(). So, instead of sending the transaction to multiple verifiers, and continuing to send the transaction until the block that is supposed to contain the transaction is received, the transaction is only sent to the one verifier. This significantly reduces the network traffic required for each transaction while negligibly reducing the chance that the transaction will be incorporated into a block. This process should continue to be refined in the future to account for new verifiers and verifiers dropping from the cycle, but such refinements are small relative to the functionality already provided.
The sendTransactionToExpectedBlockVerifier() method is used by both the client and the Micropay server. The waitForBlock argument is used by the client to wait for the block that is supposed to contain the transaction. When this block is received, the user is informed whether the block contains the transaction, and the command completes. In the case of the Micropay server, such user feedback is an unnecessary overhead, so it is bypassed.
This method uses the frozen edge, along with the ordered list of verifiers in the current cycle, to determine which verifier should process the block for the transaction. Note that the calculation works properly even when the ordered list of verifiers was generated for a different block than the frozen edge that was retrieved. While this is a rare occurrence, it can happen due to the multithreaded nature of the system.
MicropayCreateCommand and MicropaySendCommand have been eliminated from the client. They were useful for exploring the mechanics of the Micropay system, but they are no longer appropriate due to changes in the Micropay string structure. To simplify design of the Micropay client and to reduce overall burden on the mesh, Micropay clients do not track the blockchain. This requires the Micropay server to provide a previous-block hash and suggested timestamp to Micropay clients. Those fields have such a limited lifetime that manual creation and use of Micropay strings is an unlikely use case.
The MicropayAuthorization class is a simple container for tracking which users are allowed to access which endpoints on the Micropay server. As the comment explains, the class will evolve to allow more authorization-control options. Also, loading of previous authorizations from the blockchain will be added so that authorizations are not lost on server restart.
The MicropayClient run mode has the simplest of all run mode initialization processes. The run mode is set, and the web listener is started. The Micropay client does not track the blockchain.
MicropayController provides endpoints for both the Micropay server and the Micropay client. The Micropay client has two endpoints: the page for authorizing payments and a ping endpoint that is used for automatic port detection.
The endpoints for the Micropay server are built dynamically based on the contents of the directory specified as micropay_data_root in the preferences file. The process() method recursively builds the server paths based on the directory structure.
The Micropay client's ping page provides a plain text, known response to allow easy identification of a Micropay client. The page also displays the IP address of the requester, though this information is unused by the port-detection process.
The Micropay client's authorization page is presented to ask whether the user wants to approve a Micropay transaction. If the Micropay information is valid, the client signs the transaction and sends it back to the Micropay server at the provided callback URL.
The client authorization page will only create a transaction if the Micropay client has been configured correctly and if the transaction amount is less than the user-specified maximum. This protects a user from accidentally sending large transactions with Micropay.
This is an example Micropay authorization page. While this is a web page, it is served by the locally running Micropay client, not a remote server.
The MicropayEndpoint class encapsulates all of the Micropay server's functionality for authorizing accesses and delivering content. The Micropay server automatically builds endpoints based on a directory structure, much like a typical web server. Content for an example Micropay site is available on Github.
By default, a page on a Micropay site does not require payment. To require payment for a page, add the following tag to the head element of the page. The following tag would require a payment of ∩0.1 to access the page.
<meta name="nyzo-micropay-amount" content="0.1">
The getMicropayAmount() method extracts the Micropay value from the page. The standard Java libraries do not offer an HTML parser, and Nyzo seeks to limit dependencies as much as possible, so this method uses a regular expression and basic string manipulation to find the value.
The renderByteArray() method provides the page content to the web listener. If a page is free, if the user is previously authorized, or if the request contains a valid transaction, the page content is delivered. Otherwise, an authorization page is delivered.
The server authorization page is displayed when a user has not yet paid to access a piece of content. This page creates the appropriate Micropay string that the user must approve to access the content.
A script scans the most common ports on which a user might run a Micropay client: 80 and 8080 for http, 443 and 8443 for https. The authorization link is pointed to the appropriate port.
The processTransactionParameter() method checks the transaction provided by the user. If the receiver, sender data, and amount are correct, and the transaction appears likely to be accepted into the blockchain, then the Micropay server forwards the transaction to the appropriate verifier and immediately provides access to the requested content.
This method demonstrates what the Micropay system is all about: because of the way the Nyzo blockchain is structured, anyone tracking the blockchain can easily determine whether a transaction is likely to be incorporated into the blockchain, and anyone in possession of a transaction can take the appropriate steps to try to get that transaction into the blockchain. While some transactions will be lost, the small values of these transactions make periodic losses acceptable, and the system can be improved over time to lower transaction loss rate.
The senderDataForIp() method provides sender data for the transaction. The IP address and path are signed by the verifier, and the first 32 bytes of the signature are used for the sender data. As the comment notes, this calculation has some nice properties, but many any calculation that suits the needs of the Micropay server operator can be used.
The MicropayServer class is the entry point for the MicropayServer run mode. The Micropay server shares the client's data manager for mesh and blockchain tracking, and a new class, TransactionTracker, watches incoming blocks to report transactions for which this verifier is the recipient.
The TransactionTracker class provides minimal reporting on transactions in incoming blocks. This class will provide more substantial reporting and help in the authorization process in future versions, potentially allowing exclusion of transactions from senders that are known to abuse the system.
The NyzoStringEncoder class now has the ability to decode transaction strings.
In Micropay strings, the receiver IP address and receiver port have been removed, and timestamp and previous-block information added, to support the updated use of these strings. The new Micropay format is not compatible with the old format, and the old format and use case will no longer be supported.
NyzoStringTransaction allows signed transactions to be represented as Nyzo strings. These are used in the Micropay process, and they will also be useful in many other situations.
In NyzoStringType, the prefix tx__ has been registered for transaction strings.
In NyzoStringTest, a test has been added for transaction strings.
The test for Micropay strings has been updated for the new Micropay string structure.
In PreferencesUtil, methods have been added for retrieving byte arrays and long values.
In CycleController, the signatures of the endpoint methods have changed to the new definition of EndpointMethod. Query parameters are now passed into the method, along with request headers, and the EndpointResponse return type contains the response headers in addition to the content.
The EndpointMethod interface, as noted above, is evolving to handle more of the necessary complexities of web requests and responses.
The EndpointResponse class contains response headers in addition to the response content.
SentinelController has also been changed for the revised EndpointMethod interface. Additionally, a small formatting issue has been corrected.
In WebListener, the constant for port has been replaced with a method for determining the port, which is now dependent on the run mode.
The endpoint map is no longer a constant (final) variable. This change was made so that the loading process could be written to allow the map to be reloaded, allowing update of endpoints in the Micropay server without restart of the server. Note that this is not yet fully implemented: the Micropay server will pick up page content changes while running, but Nyzo Micropay pricing metadata and the endpoint map are only currently read on server initialization, and the Micropay server must be restarted for these changes to be updated.
The new port method is used in place of the constant, and the port is logged so the operator of the server can ensure the correct port was used.
Endpoint methods are now provided with the query parameters and source IP address, and the headers returned in the EndpointResponse are passed to the HttpExchange.
The path() method has been updated to provide some path normalization. A method has been added to extract query parameters into a map.
The buildEndpointMap() now includes endpoints for the Micropay server and Micropay client. The process has been built to allow atomic swaps of the endpoint map. Dynamic endpoint map updates for the Micropay server will be implemented in a future version.
The getPort() method provides more options than the previous port constant. The web_port constant is treated exactly as before, but run-mode-specific settings are now also available. For instance, to run the Micropay client on port 8081 and all other run modes on port 8080, you would specify web_port_micropay=8081 and web_port=8080 in /var/lib/nyzo/production/preferences.
In WebUtil, convenience constants have been added for inline button styles.
Classes have been added to structure links, paragraphs, and titles in HTML.
To run a Micropay server, follow the same installation instructions as the Nyzo verifier, using the nyzoMicropayServer.conf file in place of the nyzoVerifier.conf file. Also, be sure to include some web content and specify the web root as micropay_data_root in /var/lib/nyzo/production/preferences. Content for an example Micropay site is available on Github.
The Micropay server uses the private key specified in /var/lib/nyzo/production/verifier_private_seed as the recipient of all Micropay transactions. Be sure that this is an existing account, as new accounts are unable to receive small transactions due to balance-list spam protections.
The Micropay client follows the same build process as all other run modes. It does not require the trusted_entry_points file. It does require specification of micropay_sender_key and micropay_max_amount_nyzos in /var/lib/nyzo/production/verifier_private_seed. The entry point for the client is co.nyzo.verifier.micropay.MicropayClient. Micropay clients for mobile systems are currently under consideration for development.


Please go from room-to-room and select the issues you need fixed - we'll ask for details later. You can come back to this checklist anytime.


--- layout: page category : emsim tagline: "necpp MoM simulation of a quadrifilar helical antenna" tags : [mom, necpp, emtheory] ---
{% include JB/setup %}
From balanis1982antenna we define the following parameters:
from here we define some derived parameters:
We seek to operate the antenna in the axial mode, where the radiation pattern has one major lobe oriented along the helix axis. In order to excite this mode, \(D\) and \(S\) must be large fractions of the wavelength. We will initially consider an antenna designed for NOAA APT reception at a nominal frequency \(f=137.0\) MHz .
In order to achieve circular polarization, also according to balanis1982antenna, we must have \(\frac{3}{4} < \frac{C}{\lambda _0} < \frac{4}{3}\) with \(\frac{C}{\lambda _0} = 1\) optimum and a spacing \(S \approx \frac{\lambda _0}{4}\) resulting in values of \(12 \degree < \alpha < 18 \degree\) . Later we will use these values as initial values for optimising properties of the antenna. Empirically derived expressions for various antenna properties have been derived kraus1950antennas and we will later compare simulated values to values calculated using these empirical results.
Given our basic geometry, the terminal impedance as found empirically is given approximately by
\begin{equation} R \approx 140 \frac{C}{\lambda_0} \end{equation}which when combined with the conditions for circularly polarized operation, yields an impedance of \(Z = R \approx 140 \Omega\) which is clearly not equal to a typical co-axial transmission line characteristic impedance of \(Z_0 = 50 \Omega\). Balanis balanis1982antenna claims that a match closer to \(50 \Omega\) may be achieved by increasing the wire diameter close to the feed-point. We shall seek to find the geometry of something that is simple to fabricate, such as a metal strip bonded to the helix wire, that brings the terminal impedance close to the transmission line characteristic impedance.
return "Free-space wavelength for initial consideration $\lambda_0 = {0:0.3f}$ (m)".format(3e8 / 137e6)
Free-space wavelength for initial consideration \(\lambda_0 = 2.190\)
The following python codes generate the antenna geometry. The Moment Method implementation, necpp molteno2014necpp is used since the antenna is electrically large and the invisaged construction method maps well to the geometric primitives by the method.
from argparse import ArgumentParser from PyNEC import * import logging import matplotlib.pyplot as plt import mpl_toolkits.mplot3d.axes3d as axes3d import numpy as np import os import scipy.optimize import solid as sp import solid.utils import sys
The following are simulation parameters, fundamental constants and derived parameters used by the simulation.
C = 299792458 """float: c (ms^{-1}), universal physical constant for speed of light in a vacuum. """ FREQ = 137.0 """float: f (MHz) (\mu s ^{-1}), the excitation frequency applied to the test situation. Current value is chosen for the NOAA APT frequency of 137.0 MHz """ LAMBDA_0 = C / (FREQ * 1e6) """float: \lambda _0 (m) , the nominal free-space wavelength for the design """ BANDWIDTH = 1.0 """float: f (MHz) (\mu s ^{-1}), the bandwidth over which the matching network should operate. Current value covers the range of exact transmitter frequencies, doppler corrected plus the effect of modulation of the carrier. """ GROUND_CONDUCTIVITY = 0.002 """float: sigma (S), electrical conductivity of ground. Current value is something like that experienced around the upper Eastern seaboard of the United States. Real valued conductivity is a function of angular frequency (omega) so this value should be altered to something realistic based on our excitation frequency above. """ GROUND_DIELECTRIC = 10 """float: epsilon_r (dimensionless), electrical dielectric 'constant' of ground. Strictly, this is the real part of the ground relative permittivity. """ BASE = 0.1 """float: offset (m) from the ground in the z direction. """ N_FILAMENTS = 4 """int: n_filaments (dimensionless), initial number of filaments (quadrifilar initially) """ N_SEGMENTS = 30 """int: n_segments (dimensionless), initial number of wire segments per turn """ N_TURNS = 1 """float: n_turns (dimensionless), initial number of (fractional) turns of the helix """ C_HELIX = LAMBDA_0 """float: c_helix (m), initial circumference of a single turn of the helix, fixed by the circular polarization condition(s) """ D_HELIX = C_HELIX / np.pi """float: d_helix (m), initial diameter of the helix """ S_HELIX = LAMBDA_0 / 4 """float: s_helix (m), spacing between turns of the helix, fixed by the circular polarization condition(s) """ L = N_TURNS * S_HELIX """float: l (m), total length of antenna along helix axis """ L_0 = np.sqrt(S_HELIX ** 2 + C_HELIX ** 2) """float: l_0 (m), length of wire used to form a single turn of the helix """ L_F = N_TURNS * L_0 """float: total length (m) of wire used to form a single filament """ ALPHA = np.arctan(S_HELIX / (np.pi * D_HELIX)) """float: pitch angle (radians) """ N_CONNECTOR_HOLE_PITCH = 0.01824 """float: hole pitch (m) of panel mount N connector mount holes """ CONDUCTIVITY_SS = 1.45e6 """float: sigma (S), electrical conductivity of stainless steel. Real part of admittivity is conductivity and is a function of angular frequency (omega) so this value should be altered to something realistic based on our excitation frequency above. """ CONDUCTIVITY_CU = 5.96e7 """float: sigma (S), electrical conductivity of copper. """ CONDUCTIVITY_AL = 3.5e7 """float: sigma (S), electrical conductivity of stainless steel. """ R_W = 0.0005 """float: r_w, (m), initial wire radius.""" N_WIRE_SEGMENTS = 30 """int: n_wire_segments, (), number of segments per NEC wire.""" Z0 = 50 """float: Z_0 (Ohms), feedline characteristic impedance.""" OPENSCAD_SV_FA = 5.0 """float: OPENSCAD_SV_FA , special variable $fa used in openscad rendering. Minimum fragment angle.""" OPENSCAD_SV_FS = 0.5 """float: OPENSCAD_SV_FS , special variable $fs used in openscad rendering. Minimum fragment length. """ OPENSCAD_SV_FN = 48 """float: OPENSCAD_SV_FN , special variable $fn used in openscad rendering. Number of fragments (override).""" SIGMA_L = 0.01 """float: SIGMA_L , construction uncertainty for wire lengths.""" DEBUG_LOG = True """bool: DEBUG_LOG , switch on verbose logging."""
Some global variables used to track the optimisation path
z_path = np.ndarray(shape=(1,0), dtype=complex) gamma_path = np.ndarray(shape=(1,0), dtype=float)
This function simply computes \(\Gamma\), the reflection coefficient for a particular antenna scenario given characteristic impedance of the transmission line.
def reflection_coefficient(z, z0): return np.abs((z - z0) / (z + z0)) def vswr(z, z0): Gamma = reflection_coefficient(z, z0) return float((1 + Gamma) / (1 - Gamma)) def mismatch(z, z0): Gamma = reflection_coefficient(z, z0) return 1 - Gamma**2
The following is a utility function that tests whether or not a QFA geometry meets the main electrical consideration that a wire segment length, \(\Delta\), is short in comparison with the excitation wavelength(s), formally,
\begin{equation} \Delta < \frac{\lambda _0}{10} \end{equation}def delta_criterion_met(d_helix, s_helix, n_segments, n_wire_segments, frequency): l_segment = np.sqrt(s_helix ** 2 + (np.pi * d_helix) ** 2) \ / (n_segments * n_wire_segments) return l_segment < (C / frequency) / 10.0
The following function generates the antenna and feed geometry for a generalised QFA:
def qfh_geometry(base, r_w, n_helix, d_helix, s_helix, n_filaments, n_segments, # number of segments per turn n_wire_segments, construct_nec_context=True, construct_solid_geom=False): # derived quantities c_helix = np.pi * d_helix l = n_helix * s_helix l_0 = np.sqrt(s_helix ** 2 + c_helix ** 2) l_n = n_helix * l_0 l_seg = l_0 / n_segments alpha = np.arctan(s_helix / (np.pi * d_helix)) theta_seg = 2 * np.pi / n_segments if DEBUG_LOG: print("qfh_geometry() called with \n" \ "base = [ {} ]\n" \ "r_w = [ {} ]\n" \ "n_helix = [ {} ]\n" \ "d_helix = [ {} ]\n" \ "s_helix = [ {} ]\n" \ "n_filaments = [ {} ]\n" \ "n_segmemts = [ {} ]\n" \ "n_wire_segmemts = [ {} ]\n" \ "c_helix = [ {} ]\n" \ "l = [ {} ]\n" \ "l_0 = [ {} ]\n" \ "l_n = [ {} ]\n" \ "l_seg = [ {} ]\n" \ "alpha = [ {} ]\n" \ "theta_seg = [ {} ]\n" \ .format(base, r_w, n_helix, d_helix, s_helix, n_filaments, n_segments, n_wire_segments, c_helix, l, l_0, l_n, l_seg, alpha, theta_seg)) # in case we are constructing neither context = None solid_geom = None curr_tag = 1 feed_tags = n_filaments * [None] if construct_nec_context: #creation of a nec context context = nec_context() context.set_extended_thin_wire_kernel(True) #get the associated geometry geo = context.get_geometry() # ensure that we meet validity criterion for # thin wire aproximation (non-extended thin wire kernel) assert (l_0 / n_segments / r_w) > 8 # TODO: add a feed of some sort... if DEBUG_LOG: print("Add wire {} {} {} ".format(base, base + 0.1, r_w)) if construct_nec_context: geo.wire(curr_tag, n_wire_segments, 0.0, 0.0, base, 0.0, 0.0, base + 0.1, r_w, 1.0, 1.0) curr_tag += 1 if construct_solid_geom: solid_geom = sp.translate([0, 0, (0.1/2 + base) * 1e3])( sp.cylinder(r=0.05 * 1e3, h=0.1 * 1e3, center=True)) theta_filament_deg = 360.0 / n_filaments theta_filament_rad = np.deg2rad(theta_filament_deg) if DEBUG_LOG: print("theta_filament_deg = {} theta_filament_rad = {} " .format(theta_filament_deg, theta_filament_rad)) if DEBUG_LOG: print("len(range(n_segments)) = {} " .format(len(range(n_segments)))) for n in range(n_filaments): # don't use the pre-canned helix as eventually we # would like to perturb individual wire segments # as part of a monte-carlo simulation to investigate # sensitivities to construction defects # also, could have exploited cylindrical symmetry # but we won't, again to have something approaching # realistic construction defects - if hand wound, # unlikely to be symmetric defects theta_filament_offset = theta_filament_rad * n x_0 = d_helix / 2.0 * np.cos(theta_filament_offset) y_0 = d_helix / 2.0 * np.sin(theta_filament_offset) z_0 = base feed_tags[n] = curr_tag for i in range(n_helix): for j in range(n_segments): x_1 = d_helix / 2.0 * np.cos(theta_seg * (j + 1) + theta_filament_offset) y_1 = d_helix / 2.0 * np.sin(theta_seg * (j + 1) + theta_filament_offset) z_1 = i * s_helix + s_helix / n_segments * (j + 1) + base if DEBUG_LOG: print("Add wire {} {} {} -> {} {} {} " .format(x_0, y_0, z_0, x_1, y_1, z_1)) if construct_nec_context: geo.wire(curr_tag, n_wire_segments, x_0, y_0, z_0, x_1, y_1, z_1, r_w, 1.0, 1.0) curr_tag += 1 if construct_solid_geom: solid_geom += sp.translate([x_0 * 1e3, y_0 * 1e3, z_0 * 1e3])( sp.rotate([0, np.rad2deg(np.pi / 2.0 - alpha), np.rad2deg(np.pi / 2.0 + theta_seg * (j + 0.5) + theta_filament_offset)])( sp.cylinder(r=r_w * 1e3, h=l_seg * 1e3, center=False))) x_0 = x_1 y_0 = y_1 z_0 = z_1 if construct_nec_context: # Group I cards context.ld_card(5, 0, 0, 0, CONDUCTIVITY_AL, 0.0, 0.0) # Don't specify a ground for this one context.gn_card(0, 0, GROUND_DIELECTRIC, GROUND_CONDUCTIVITY, 0, 0, 0, 0) context.geometry_complete(0) return context, solid_geom, feed_tags
def set_frequencies_linear(context, start_frequency, stop_frequency, count=None, step_size=None): """ If start_frequency does not equal stop_frequency, either count or step should be specified. The other parameter will be automatically deduced """ if start_frequency == stop_frequency: step_size = 0 count = 1 else: # TODO: add some asserts if count is not None: step_size = (stop_frequency - start_frequency) / count else: count = (stop_frequency - start_frequency) / step_size # TODO, what if we don't have nice divisibility here count = int(count) ifrq_linear_step = 0 context.fr_card(ifrq_linear_step, count, start_frequency, step_size) if DEBUG_LOG: print("Added fr_card({}, {}, {}, {}) " .format(ifrq_linear_step, count, start_frequency, step_size)) def set_frequency(context, frequency): set_frequencies_linear(context, frequency, frequency) def set_excitation(context, feed_tags): for i in range(len(feed_tags)): # Group II cards #add a "ex" card to specify an excitation context.ex_card(0, feed_tags[i], 1, 0, 0, np.cos(2.0 * np.pi / len(feed_tags) * i), -np.sin(2.0 * np.pi / len(feed_tags) * i), 0.0, 0.0, 0.0, 0.0) if DEBUG_LOG: print("Added excitation tag = {} ".format(feed_tags[i]))
def compute_impedance(context, frequency, feed_tags): set_frequency(context, frequency) set_excitation(context, feed_tags) # Group III cards context.xq_card(0) #get the input_parameters ip = context.get_input_parameters(0) z = ip.get_impedance()[0] return z
To be determined. A suitable cost function for optimising our QFA.
def cost_function(x): radial_len = x[2] radial_offset = 0.0 n_radials = 4 theta_radial = x[3] if theta_radial > 80.0 or theta_radial < 0.0: return float('inf') length = x[0] # length >= 0 base = x[1] # base >= 0 if base < 0 or length <= 0.1 or radial_len <= 0.1: return float('inf') context, solid_geom, feed_tags = qfh_geometry(base, R_W, N, D, S, N_FILAMENTS, N_SEGMENTS, construct_nec_context=True, construct_solid_geom=False) z = compute_impedance(context, FREQ, feed_tags) gamma = reflection_coefficient(z, Z0) global z_path, gamma_path z_path = np.append(z_path, z) gamma_path = np.append(gamma_path, gamma) return vswr(z, Z0)
def optimise_antenna(): # Starting value freq = FREQ bounds = [(np.log(0.4), np.log(0.7)), (np.log(0.01), np.log(0.02)), (np.log(0.4), np.log(0.7)), (np.log(15.0), np.log(85.0))] initial_radial_len = 0.6 initial_theta_radial = 22.0 initial_length = 0.6 initial_base = 0.01 initial_geom = np.array([initial_length, initial_base, \ initial_radial_len, initial_theta_radial]) # Carry out the minimization result = scipy.optimize.minimize(cost_function, initial_geom, \ method='Nelder-Mead') print('z_path min={} max={}'.format(np.amin(z_path), np.amax(z_path))) print('gamma_path min={} max={}'.format(np.amin(gamma_path), np.amax(gamma_path))) length = result.x[0] base = result.x[1] radial_len = result.x[2] radial_offset = 0.0 n_radials = 4 theta_radial = result.x[3] return base, length, R_W, radial_len, \ radial_offset, n_radials, theta_radial
The geometry yielding these simulated parameters is shown in figure qfh_geom . It has a driven element length of \(l_d = 0.701\)m and radials of length \(l_r = 0.348 \)m that make angle \(\theta _r = 46.86^{\circ} \) with the xy-plane.
def export_openscad_geometry(): context, solid_geom, feed_tags = qfh_geometry(BASE, R_W, N_TURNS, D_HELIX, S_HELIX, N_FILAMENTS, N_SEGMENTS, N_WIRE_SEGMENTS, construct_nec_context=False, construct_solid_geom=True) out_dir = sys.argv[1] if len(sys.argv) > 1 else os.curdir file_out = os.path.join(out_dir, 'qfh_antenna.scad') sp.scad_render_to_file(solid_geom, filepath=file_out, file_header='$fa = {}; $fs = {};' .format(OPENSCAD_SV_FA, OPENSCAD_SV_FS), include_orig_code=False) print("{}: SCAD file written to: {}\n".format(__file__, file_out))
Figure 1: Optimised antenna geometry
def compute_radiation_pattern(context): # Group III cards #add a "rp" card to specify radiation pattern sampling parameters context.rp_card(calc_mode=0, n_theta=180, n_phi=720, output_format=0, normalization=0, D=0, A=0, theta0=0.0, delta_theta=0.5, phi0=0.0, delta_phi=0.5, radial_distance=0.0, gain_norm=0.0)
def plot_radiation_pattern(rp, label): # Gains are in decibels gains_db = rp.get_gain() print('gains_db.shape = {0}'.format(gains_db.shape)) gains = 10.0**(gains_db / 10.0) thetas = np.deg2rad(rp.get_theta_angles()) phis = np.deg2rad(rp.get_phi_angles()) print('thetas.shape = {0} [{1},{2}]' .format(thetas.shape, thetas[0], thetas[len(thetas)-1])) print('phis.shape = {0} [{1},{2}]' .format(phis.shape, phis[0], phis[len(phis)-1])) print('gains \in [{0},{1}]'.format(np.amin(gains), np.amax(gains))) fig = plt.figure() max_gain_22deg5 = np.amax(gains_db[(180 * 3)//4 - 1,:]) max_gain_45deg0 = np.amax(gains_db[180//2 - 1,:]) max_plotted_xy_plane_gain = np.max([max_gain_22deg5, max_gain_45deg0]) min_gain_22deg5 = np.amin(gains_db[(180 * 3)//4 - 1,:]) min_gain_45deg0 = np.amin(gains_db[180//2 - 1,:]) min_plotted_xy_plane_gain = np.min([min_gain_22deg5, min_gain_45deg0]) print("amax(gains|\\theta=22.5) = {} amax(gains|\\theta=45.0) = {}" \ "max() = {}".format(max_gain_22deg5, max_gain_45deg0, max_plotted_xy_plane_gain)) print("amin(gains|\\theta=22.5) = {} amin(gains|\\theta=45.0) = {}" \ "min() = {}".format(min_gain_22deg5, min_gain_45deg0, min_plotted_xy_plane_gain)) max_plotted_xz_plane_gain = np.max([max_gain_22deg5, max_gain_45deg0]) max_plotted_yz_plane_gain = np.max([max_gain_22deg5, max_gain_45deg0]) # Plot 2d polar plots ax = fig.add_subplot(2, 2, 1, projection='polar') ax.plot(phis, gains_db[(180 * 3)//4 - 1,:], color='r', linewidth=3) ax.grid(True) # ax.set_rmax(max_plotted_xy_plane_gain) ax.set_rlim(rmin=min_plotted_xy_plane_gain, rmax=max_plotted_xy_plane_gain) ax.set_theta_zero_location("S") # ax.set_rscale('log') # ax.set_rmax(10) ax.set_title("Gain at an elevation of 22.5 degrees", va='bottom') ax = fig.add_subplot(2, 2, 2, projection='polar') ax.plot(np.concatenate((np.flip(thetas), -thetas)), np.concatenate((np.flip(gains[:,360]), gains[:,0])), color='r', linewidth=3) ax.grid(True) ax.set_rlim(rmin=np.amin([gains[:,360], gains[:,0]]), rmax=np.amax([gains[:,360], gains[:,0]])) ax.set_thetalim(thetamin=-90.0, thetamax=90.0) ax.set_thetagrids([-90.0, -60.0, -30.0, 0.0, 30.0, 60.0, 90.0]) ax.set_theta_zero_location("N") ax.set_title("Gain sliced through xz-plane", va='bottom') ax = fig.add_subplot(2, 2, 3, projection='polar') ax.plot(phis, gains_db[180//2 - 1,:], color='r', linewidth=3) ax.grid(True) # ax.set_rmax(max_plotted_xy_plane_gain) ax.set_rlim(rmin=min_plotted_xy_plane_gain, rmax=max_plotted_xy_plane_gain) ax.set_theta_zero_location("S") ax.set_title("Gain at an elevation of 45 degrees", va='bottom') ax = fig.add_subplot(2, 2, 4, projection='polar') ax.plot(np.concatenate((np.flip(thetas), -thetas)), np.concatenate((np.flip(gains[:,540]), gains[:,180])), color='r', linewidth=3) ax.grid(True) # ax.set_rmax(np.amax([gains[:,180], gains[:,540]])) ax.set_rlim(rmin=np.amin([gains[:,180], gains[:,540]]), rmax=np.amax([gains[:,180], gains[:,540]])) ax.set_thetalim(thetamin=-90.0, thetamax=90.0) ax.set_thetagrids([-90.0, -60.0, -30.0, 0.0, 30.0, 60.0, 90.0]) ax.set_theta_zero_location("N") ax.set_title("Gain sliced through yz-plane", va='bottom') plt.savefig('../images/qfh_polar_plots_{}.png'.format(label)) plt.gcf().clear() # Plot 3d radiation pattern. R = gains.T THETA, PHI = np.meshgrid(thetas, phis) print('THETA.shape = {0}'.format(THETA.shape)) print('PHI.shape = {0}'.format(PHI.shape)) X = R * np.sin(THETA) * np.cos(PHI) Y = R * np.sin(THETA) * np.sin(PHI) Z = R * np.cos(THETA) ax = fig.add_subplot(1, 1, 1, projection='3d') # Plot the surface. ax.plot_surface(X, Y, Z, rstride=1, cstride=1, cmap=plt.get_cmap('jet'), linewidth=0, antialiased=False, alpha=0.5) ax.grid(True) ax.set_title("3d gain plot", va='bottom') plt.savefig('../images/qfh_3d_gain_plot_{}.png'.format(label)) # plt.show() plt.gcf().clear() plt.close(fig)
def compare_excitation_modes(): base = BASE #modes = [ 'higher-order' ] modes = [ 'normal', 'axial', 'higher-order' ] #freqs = [ 1370.0 ] freqs = [ 0.1, 137.0, 1370.0 ] # begin with the degenerate case of a single filament n_filaments = 1 context, solid_geom, feed_tags = qfh_geometry(BASE, R_W, N_TURNS, D_HELIX, S_HELIX, n_filaments, N_SEGMENTS, N_WIRE_SEGMENTS, construct_nec_context=True, construct_solid_geom=True) set_excitation(context, feed_tags) for i in range(len(modes)): # ensure that we meet validity criterion for # segment length delta < 0.1 lambda assert delta_criterion_met(D_HELIX, S_HELIX, N_SEGMENTS, N_WIRE_SEGMENTS, freqs[i]) set_frequency(context, freqs[i]) compute_radiation_pattern(context) #get the radiation_pattern rp = context.get_radiation_pattern(i) plot_radiation_pattern(rp, modes[i]) return 0
Figure 2: 3d gain plot pattern - radiated normal mode excitation
And polar plots of gain at various elevation angles
Figure 3: Polar plots of gain pattern for normal mode excitation at various elevation angles
Figure 4: 3d gain plot pattern - radiated axial mode excitation
And polar plots of gain at various elevation angles
Figure 5: Polar plots of gain pattern for axial mode excitation at various elevation angles
Figure 6: 3d gain plot pattern - radiated higher-order mode excitation
And polar plots of gain at various elevation angles
Figure 7: Polar plots of gain pattern for higher-order mode excitation at various elevation angles
For our optimised antenna, how does the effective match to a \(50 \Omega \) load vary with frequency?
def compute_vswr(context, feed_tags): count = 50 set_frequencies_linear(context, FREQ - BANDWIDTH/2.0, FREQ + BANDWIDTH/2.0, count=count) set_excitation(context, feed_tags) context.xq_card(0) # Execute simulation freqs = [] vswrs = [] for idx in range(0, count): ipt = context.get_input_parameters(idx) z = ipt.get_impedance() freqs.append(ipt.get_frequency() / 1000000) vswrs.append(vswr(z, Z0)) return freqs, vswrs
def plot_vswr(freqs, vswrs): fig = plt.figure() # Plot cartesian, linear scale ax = fig.add_subplot(1, 1, 1, projection='rectilinear') ax.plot(freqs, vswrs, color='r', linewidth=3) ax.grid(True) ax.set_xlabel("Frequency (MHz)") ax.set_ylabel("VSWR") ax.set_title("VSWR vs. frequency (MHz) for 50 ohm system", va='bottom') plt.savefig('../images/qfh_vswr.png') plt.gcf().clear()
The plot in figure qfh_vswr shows the response of the optimised antenna across the Airband.
Figure 8: VSWR for 50 ohm system
For a real-world antenna with construction defects, what is the effect on antenna impedance of the driven element and radials having lengths that deviate from the ideal computed value? We attempt to compute the partial derivative of \(Z\) with respect to \(l_d\) by taking finite differences around the optimised value of \(l_d\) and estimate our construction tolerance \(\sigma l = 0.01\). For some small \(h\) we have
\begin{equation} \frac{\partial Z}{\partial l_d} \approx \frac{Z(l_d + h) - Z(l_d - h)}{2h} \end{equation}def compute_dz_dl_e(base, length, r_w, radial_len, radial_offset, n_radials, theta_radial, h): z_n = [] for k in range(2): context, solid_geom = qfh_geometry(base, R_W, N, D, S + ((-1) ** (k + 1) * h), N_FILAMENTS, N_SEGMENTS, construct_nec_context=True, construct_solid_geom=False) set_frequency(context, FREQ) set_excitation(context) context.xq_card(0) # Execute simulation ip = context.get_input_parameters(0) z = ip.get_impedance() z_n.append(z) print(z) partial_z_l_e = (z_n[0] - z_n[1]) / (2 * h) return partial_z_l_e
def compute_bp_matching_network(z0, zl): return 0.0
def main(): parser = ArgumentParser(description="Optimise QFH antenna and compute matching network.") args = parser.parse_args() # base, length, r_w, radial_len, \ # radial_offset, n_radials, theta_radial = optimise_antenna() base = BASE # length = 0.63 # radial_len = 0.6 # radial_offset = 0.0 # n_radials = 4 # theta_radial = 45.0 # r_w = R_W # print("\nOptimisation result\n") # print("final geometry {} {} {} {} {} {} {}" # .format(base, length, r_w, radial_len, # radial_offset, n_radials, theta_radial)) context, solid_geom, feed_tags = qfh_geometry(BASE, R_W, N, D, S, N_FILAMENTS, N_SEGMENTS, construct_nec_context=True, construct_solid_geom=True) out_dir = sys.argv[1] if len(sys.argv) > 1 else os.curdir file_out = os.path.join(out_dir, 'qfh_antenna.scad') sp.scad_render_to_file(solid_geom, file_header='$fa = {}; $fs = {};' .format(OPENSCAD_SV_FA, OPENSCAD_SV_FS), include_orig_code=False) print("{}: SCAD file written to: {}\n".format(__file__, file_out)) z = compute_impedance(context, FREQ, feed_tags) print("z: {0}".format(z)) print("Impedance at base={0:.2f} " " : ({1:6.1f},{2:+6.1f}i) Ohms" .format(base, z.real, z.imag)) print("Reflection coefficient Gamma={0:0.2f}" .format(reflection_coefficient(z, Z0))) print("VSWR @50 ohm ={0:0.2f}" .format(vswr(z, Z0))) set_frequency(context, FREQ) set_excitation(context, feed_tags) plot_radiation_pattern(context) #compute_bp_matching_network(Z0, zl) # context, solid_geom, feed_tags = qfh_geometry(base, R_W, N, D, S, # N_FILAMENTS, N_SEGMENTS, # construct_nec_context=True, # construct_solid_geom=False) # freqs, vswrs = compute_vswr(context, feed_tags) # plot_vswr(freqs, vswrs) # sensitivity to driven element length #h = 0.005 #dz_dl_e = compute_dz_dl_e(base, length, r_w, radial_len, # radial_offset, n_radials, theta_radial, # h) #print("dl10: {0}".format(dz_dl_e * SIGMA_L)) return 0
python qfh_antenna.py 2>&1 true


the lmfitdata class¶
This is a child class of nddata used for fitting.
For old fitdata documentation (obsolete, for development reference) see fitdata_old
creating new types of lmfitdata modules¶
There is a base class called “lmfitdata” that defines the basic routines necessary for fitting. Currently, the lmfitdata class only supports fitting along one dimension, so before constructing a new class, one must first choose what dimension they will be fitting along.
Todo
Of course, for multidimensional data, the fit will be repeated along the dimensions that are not the fit dimension. see how easy it would be to allow more than one dimension
To fit a new type of function, one simply creates a new type of class that inherits from the lmfitdata class. We override all the methods that have to do with the definition of the functional format. These are defined in the first section, where we build up an example for fitting a general \(T_1\) recovery curve. This example should be used as a starting point for making new fit classes. Then, we can make instances of the new class, and use their methods (described in the subsequent section) next.
Todo
the option block :no-inherited-members: doesn’t work – not sure how to modify class.rst I put a template from stackexchange inside _templates – see https://stackoverflow.com/questions/28147432/how-to-customize-sphinx-ext-autosummary-rst-template on how to use it
then, I need to link to or include generated/pyspecdata.lmfitdata.rst
- class pyspecdata.lmfitdata.lmfitdata(*args, **kwargs)¶
Inherits from an nddata and enables curve fitting through use of a sympy expression.
The user creates a lmfitdata class object from an existing nddata class object, and on this lmfitdata object can define the
functional_form()
of the curve it would like to fit to the data of the original nddata. This functional form must be provided as a sympy expression, with one of its variables matching the name of the dimension that the user would like to fit to.- copy()¶
Return a full copy of this instance.
Because methods typically change the data in place, you might want to use this frequently.
- Parameters:
data (boolean) –
Default to True. False doesn’t copy the data – this is for internal use, e.g. when you want to copy all the metadata and perform a calculation on the data.
The code for this also provides the definitive list of the nddata metadata.
- eval(taxis=None)¶
Calculate the fit function along the axis taxis.
- Parameters:
taxis (ndarray, int) –
- if ndarray:
the new axis coordinates along which we want to calculate the fit.
- if int:
number of evenly spaced points along the t-axis along the fit
- Returns:
self – the fit function evaluated along the axis coordinates that were passed
- Return type:
- fit()¶
actually run the fit
- property function_string¶
A property of the myfitclass class which stores a string output of the functional form of the desired fit expression provided in func:functional_form in LaTeX format
- property functional_form¶
A property of the myfitclass class which is set by the user, takes as input a sympy expression of the desired fit expression
- gen_indices(this_set, set_to)¶
pass this this_set and this_set_to parameters, and it will return: indices,values,mask indices –> gives the indices that are forced values –> the values they are forced to mask –> p[mask] are actually active in the fit
- guess()¶
Old code that we are preserving here – provide the guess for our parameters; by default, based on pseudoinverse
- latex()¶
show the latex string for the function, with all the symbols substituted by their values
- output(*name)¶
give the fit value of a particular symbol, or a dictionary of all values.
- Parameters:
name (str (optional)) – name of the symbol. If no name is passed, then output returns a dictionary of the resulting values.
- Returns:
retval – Either a dictionary of all the values, or the value itself
- Return type:
dict or float
- residual(pars, x, y, sigma=None)¶
calculate the residual OR if data is None, return fake data
- set_guess(*args, **kwargs)¶
set both the guess and the bounds
- Parameters:
guesses (dict of dicts) –
each dict has a keyword giving the parameter and a value that comprises a dict with guesses (value) and/or constraints (min/max)
Can be passed either as the only argument, or a kwarg called guesses, or as the kwargs themselves.
- settoguess()¶
a debugging function, to easily plot the initial guess


3CS is Sri Lanka’s premier web design and digital marketing agency. With over two decades of industry experience, multiple web design awards every year and a blue-chip clientele, we offer an unparalleled service. We offer highly personalized, bespoke solutions to an exclusive client list. Our solutions include responsive web design, digital marketing and professional photography.
Our sites are technically superior, optimized for achieving higher search engine rankings and function without failure or errors, even with millions of hits per month.
We have a highly creative in-house team of graphic designers and content writers to develop fresh and engaging marketing content. Work with us to take your marketing campaigns to the next level.
We can make your website one of the most profitable channels in your company. We offer unique insights into competing online, generating superior targeted visitor traffic, and converting a higher percentage of visitors into sales.
3CS has also designed and maintains several other websites for the LOLC group, including the main corporate website, LOLC Life, LOLC General, LOLC Motors and CLC. We are proud to continue being a web design partner for the LOLC Group.
For the first in the award’s history, a news website was selected as the best website in Sri Lanka.
3CS won a Best Web Developer award at Bestweb for a record 7th consecutive time.3CS continued to dominate the Travel & Tourism category, winning 2/3 awards handed out, including the highest award in the category.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Sunt ut voluptatum eius sapiente, totam reiciendis temporibus qui quibusdam, recusandae sit vero unde, sed, incidunt et ea quo dolore laudantium consectetur!
The website was designed in a modern user friendly style and layout.The site is fully responsive and compatible with all mobile devices and platforms.
Chairman
CEO
Associate Web Designer


Greta Parks holds a Master's of Music in Cello Performance and Certificate in College teaching from CU Boulder, as well as a Bachelor’s of Music in Cello Performance and a Performance Certificate from the Eastman School of Music. He primary teachers were Alan Harris, Judith Glyde, and Thomas Heinrich.
Ms Parks loves performing and teaching equally and maintains an active career in both areas. She is a tenure track member of the Boulder Philharmonic and maintains a small but vibrant private lesson studio.
A native of Poughkeepsie, New York, Ms. Parks currently resides in Colorado. She loves the outdoors and is happy to be living so close to the Rocky Mountains; she also loves a good cup of coffee.


Comparison of cost between different calling methods. Using the CodeCompare testing harness I compared the following calling methods using 12, 24 and 36 different commands to see if there was a noticeable difference in cost:
I don't think there's a whole lot that can be assumed from these findings. I found that slight changes to the code could drastically affect the performance costs. there were times when virtual methods were faster than function pointers and where switch cases fell over. This is just the latest version of the results.
|
|
|
|
|
|


Ticket ID: 409788
Name:
Parker Seidel
Email:
<EMAIL_ADDRESS>Response Time:
72hours, 60hours left
Last Action:
Never been locked.
Link to public post
Status:
Not answered


Kannada Article Summarizer: Natural Language Processing Project which contains the implementation of the art of intrinsic
extraction using a statistical stemmer, POS Tagger, TF-IDF& GSS co-efficient in Python for Kannada Language.
View Project on GitHub
May 2017


Expense Details: (Click To Edit)
On Report:
{{expenseReport.reportName}}
Expense Images
Name: {{expenseName}}
Cost: ${{expenseCost}}
Category: {{expenseCategory}}
Created By:
{{expenseCreatedBy.firstName}} {{expenseCreatedBy.lastName}}
Created: {{expenseCreated}}
Delete Expense


Quick parametric fuel consumption simulation app. Read more about this app here. View source.
| Parameter | Value | Parameter | Value |
|---|---|---|---|
| Preferred ship sailing speed, knots: | Vertical acceleration threshold, m/s²: | ||
| Auxiliary power load, W: | Relative position to LOA, %: |
A scatter diagram for the North Sea is preloaded by default. You can change it by uploading another file.
Weights of hull, decks and bulkheads are scaled with their areas. Lightweights of tanks and compartments are assumed to remain constant. As capacities of tanks and compartments scale with volume, they also remain constant. Read more about ship objects here.
Simulation will be performed for the design space visualized above. The algorithm will fix the beam at base value, loop through the length, step over beam, loop through length and so on. A step of 0.01 in the scaling ratio is used by default, totaling a number of up to 441 simulated ship specifications.
Every combination of scaled ship, propeller and power plant specifications will be simulated. It may take some minutes to perform all the simulations.


If you want to make robust, actionable data-driven decisions from data, you need to understand statistics. In this intensive bootcamp, you will learn the fundamental principles of statistical analysis and inference using the R statistical language in order to help you translate data into actionable analytics. Whether you are an experienced data analyst or completely new to the field of statistical inference, this course has something for you. You will start from the beginning, learning how to calculate summary statistics to gain immediate insights from data. You will then learn how to create, dissect, and implement regression models, including t-tests, correlation tests, and ANOVAs) to understand hidden relationships in your data. Advanced topics such as hierarchical regression, Bayesian methods, and non-parametric analyses will also be covered.
Each day will contain a series of short lectures and examples to introduce you to new topics. The bulk of each day will be dedicated to hands-on exercises to help you ‘learn by doing’. Dedicated time will be given for 1:1 feedback. All course materials, tutorials, examples, exercises, and solutions will be available online for you to view at any time during, and after the course.
Participants are requested to bring their own laptop with software installation rights. There are no strict knowledge prerequisites for this course. Prior experience with a programming language (e.g.; SAS, R, STATA), as well as an introductory course in statistics, is helpful but not necessary.
The course includes with a brief introduction to the R language to prepare participants for the content of the course. Prior experience with R, or any other programming language, as well as an introductory course in statistics, is helpful but not necessary.
|
|
|
Day 1 |
Day 2 |
| 15:30 |
Regression applications
+Practical
Implementing ANOVAs, t-tests, correlation tests as regression models.
Practical considerations in using regression?
| New statistics
Statistics beyond p-values.
A primer on Bayesian statistics.
|


:e filename
# edit a file in a new buffer
:bnext (or :bn)
# go to next buffer
:bprev (of :bp)
# go to previous buffer
:bd
# delete a buffer (close a file)
:sp filename
# open a file in a new buffer and split window
ctrl+ws
# split windows
ctrl+ww
# switch between windows
ctrl+wq
# quit a window
ctrl+wv
# split windows vertically


{% extends "layout.html" %}
{% set ptitle = "Is the representative an individual, company or other type of organisation?" %}
{% block page_title %}
{{ ptitle }} - Tax Tribunals Prototype
{% endblock %}
{% block content %}
{% include "includes/phase_banner_beta.html" %}


How-to write english documentation for Yanel
The purpose of this tutorial is to get started on Yanel by demonstrating a way to to create, edit and contribute documentation. Please keep in mind that Yanel is functional but not polished.
This tutorial assumes that you've installed the source distibution of Yanel with support for SSL in /usr/local/wyona and are able to view content in your Browser. (If you are using IE9 you might not be able to edit with one of the provided editors.)
Create the new page/resource
- Start Yanel.
- Visit http://<IP_ADDRESS>:8080/yanel/ or http://localhost:8080/yanel/.
- Click on the 'Yanel Website' link in the Registered Realms section.
- Click on 'Learn more about Yanel'.
- Click on 'Documentation'.
- Click on the link 'Toolbar' at the bottom of the page. You will be redirected a login page for the Yanel Website realm.
- Enter 'alice' as your Username and 'levi' as your password.
- After successfully logging in you will be redirected to the Documentation site with the additional Yanel 'Toolbar' on the top.
- Take a moment to consider how your contribution fits into the existing documentation structure.
You need to decide what page/resource type you want to create, where it will be placed and how to link to it.
For this tutorial, we will create a new tutorial called 'Adding Some Content' which will be placed at
http://<IP_ADDRESS>:8080/yanel/yanel-website/en/documentation/tutorials/add-some-content/index.html
- Select in the Yanel 'menu': file - new - Standard Page (XHTML)
- You are redirected to the first step of creating a new page.
In the 'title:' property text box enter the title that you would like to have for the page Adding some content.
In 'Save as:' use the directory tree to navigate to where the new content is to be placed. For this tutorial this means, /en/documentation/
Be very careful as there are currently no warnings about overwriting. If you do overwrite something, you may want to make
use of git's revert commands to restore what was overwritten.
In the 'New name:' text box enter tutorials/add-some-content/index.html
Review your work and the click on the 'Save new resource' button. This will create the resource and move you to a confirmation and summary page.
- Now that you've created the new page/resource, you may view it by clicking on the link on the confirmation/summary page.
Edit the content
There are two possibilities two edit your page. Either you alter the page in your browser or you alter the source file directly. First we will have a look at how to use the editors.
1. Using the editors
- Choose one of the editors provided in the Yanel 'menu'.
- Select in the Yanel 'menu': edit - open with - WYSIWYG editor - edit page with XXX
- Now you need to decide if you prefer to edit your page with Xinha or tinyMCE.
- According to your previous decision your document will be loaded into the editor interface.
- Edit the document by exploring the facilities provided by the editor.
2. Altering the source file
- Open the "conf" folder in your YANEL_HOME directory. (cd .../YANEL_HOME/conf)
- There you should have a look at the "realms.xml" file. This file helps you to locate the repository you are looking for. Follow the path enclosed by the <config ... />-tag.
(Of course consider the <config>-tag embedded by the realm-tag having the right "id".)
- In this directory you will find another "realm.xml" file. It tells you (embedded by the <data>-tag) where the data is saved.
- To find the source file, follow the directories, which are equal to the tree structure of the navigation.
- Open the source file. It contains html. Create/Edit the content as you see fit.
Congratulations! You've created and edited some new content in Yanel.
Contribute to the Yanel documentation
If you are really working on documentation for Yanel and you have commit privileges for the project you will need to use git to add the content you just created. One way of doing this is to open a shell and use the following sequence of commands:
cd /usr/local/wyona/yanel-trunk/src/realms/yanel-website
egrep -rio 'Adding some content' *
As you don't really want to commit the results of this tutorial to the Yanel repository at Wyona, you should remove your local modifications
asdfafdasfasfasf
If you are not a commiter but have created some documentation, please create a patch.
If you are really adding documentation to Yanel, you will need to either commit a change that links to your work or submit a patch that offers a change that will link to your work.


Content-type: text/html
Manpage of HPING2
HPING2
Section: Maintenance Commands (8)
Updated: 2001 Aug 14
Index
Return to Main Contents
NAME
hping2 - send (almost) arbitrary TCP/IP packets to network hosts
SYNOPSIS
hping2
[
-hvnqVDzZ012WrfxykQbFSRPAUXYjJBuTG
] [
-c
count
] [
-i
wait
] [
--fast
] [
-I
interface
] [
-9
signature
] [
-a
host
] [
-t
ttl
] [
-N
ip id
] [
-H
ip protocol
] [
-g
fragoff
] [
-m
mtu
] [
-o
tos
] [
-C
icmp type
] [
-K
icmp code
] [
-s
source port
] [
-p[+][+]
dest port
] [
-w
tcp window
] [
-O
tcp offset
] [
-M
tcp sequence number
] [
-L
tcp ack
] [
-d
data size
] [
-E
filename
] [
-e
signature
] [
--icmp-ipver
version
] [
--icmp-iphlen
length
] [
--icmp-iplen
length
] [
--icmp-ipid
id
] [
--icmp-ipproto
protocol
] [
--icmp-cksum
checksum
] [
--icmp-ts
] [
--icmp-addr
] [
--tcpexitcode
] [
--tcp-timestamp
] [
--tr-stop
] [
--tr-keep-ttl
] [
--tr-no-rtt
] [
--rand-dest
] [
--rand-source
]
hostname
DESCRIPTION
hping2 is a network tool able to send custom TCP/IP packets and to
display target replies like ping program does with ICMP replies. hping2
handle fragmentation, arbitrary packets body and size and can be used in
order to transfer files encapsulated under supported protocols. Using
hping2 you are able to perform at least the following stuff:
- Test firewall rules
- Advanced port scanning
- Test net performance using different protocols,
packet size, TOS (type of service) and fragmentation.
- Path MTU discovery
- Transferring files between even really fascist firewall
rules.
- Traceroute-like under different protocols.
- Firewalk-like usage.
- Remote OS fingerprinting.
- TCP/IP stack auditing.
- A lot of others.
It's also a good didactic tool to learn TCP/IP.
hping2 is developed and maintained by<EMAIL_ADDRESS>and is
licensed under GPL version 2. Development is open so you can send
me patches, suggestion and affronts without inhibitions.
HPING SITE
primary site at
http://www.hping.org.
You can found both the stable release and the instruction
to download the latest source code at http://www.hping.org/download.html
BASE OPTIONS
- -h --help
-
Show an help screen on standard output, so you can pipe to less.
- -v --version
-
Show version information and API used to access to data link layer,
linux sock packet
or
libpcap.
- -c --count count
-
Stop after sending (and receiving)
count
response packets. After last packet was send hping2 wait COUNTREACHED_TIMEOUT
seconds target host replies. You are able to tune COUNTREACHED_TIMEOUT editing
hping2.h
- -i --interval
-
Wait
the specified number of seconds or micro seconds between sending each packet.
--interval X set
wait
to X seconds, --interval uX set
wait
to X micro seconds.
The default is to wait
one second between each packet. Using hping2 to transfer files tune this
option is really important in order to increase transfer rate. Even using
hping2 to perform idle/spoofing scanning you should tune this option, see
HPING2-HOWTO
for more information.
- --fast
-
Alias for -i u10000. Hping will send 10 packets for second.
- --faster
-
Alias for -i u1. Faster then --fast ;) (but not as fast as your computer can send packets due to the signal-driven design).
- -n --numeric
-
Numeric output only, No attempt will be made to lookup symbolic names for host addresses.
- -q --quiet
-
Quiet output. Nothing is displayed except the summary lines at
startup time and when finished.
- -I --interface interface name
-
By default on linux and BSD systems hping2 uses default routing interface.
In other systems or when there is no default route
hping2 uses the first non-loopback interface.
However you are able to force hping2 to use the interface you need using
this option. Note: you don't need to specify the whole name, for
example -I et will match eth0 ethernet0 myet1 et cetera. If no interfaces
match hping2 will try to use lo.
- -V --verbose
-
Enable verbose output. TCP replies will be shown as follows:
len=46 ip=<IP_ADDRESS> flags=RA DF seq=0 ttl=255 id=0 win=0 rtt=0.4 ms
tos=0 iplen=40 seq=0 ack=1380893504 sum=2010 urp=0
- -D --debug
-
Enable debug mode, it's useful when you experience some problem with
hping2. When debug mode is enabled you will get more information about
interface detection, data link layer access, interface settings, options
parsing, fragmentation, HCMP protocol
and other stuff.
- -z --bind
-
Bind CTRL+Z to
time to live (TTL)
so you will able to increment/decrement ttl of outgoing packets pressing
CTRL+Z once or twice.
- -Z --unbind
-
Unbind CTRL+Z so you will able to stop hping2.
PROTOCOL SELECTION
Default protocol is TCP, by default hping2 will send tcp headers to target
host's port 0 with a winsize of 64 without any tcp flag on. Often this
is the best way to do an 'hide ping', useful when target is behind
a firewall that drop ICMP. Moreover a tcp null-flag to port 0 has a good
probability of not being logged.
- -0 --rawip
-
RAW IP mode, in this mode hping2 will send IP header with data
appended with --signature and/or --file, see also --ipproto that
allows you to set the ip protocol field.
- -1 --icmp
-
ICMP mode, by default hping2 will send ICMP echo-request, you can set
other ICMP type/code using
--icmptype --icmpcode
options.
- -2 --udp
-
UDP mode, by default hping2 will send udp to target host's port 0.
UDP header tunable options are the following:
--baseport, --destport, --keep.
- -8 --scan
-
Scan mode, the option expects an argument that describes groups of
ports to scan. port groups are comma separated: a number describes
just a single port, so 1,2,3 means port 1, 2 and 3. ranges are specified
using a start-end notation, like 1-1000, that tell hping to scan ports between 1 and 1000 (included). the special word
all
is an alias for 0-65535, while the special word
known
includes all the ports listed in /etc/services.
Groups can be combined, so the following command line will
scan ports between 1 and 1000 AND port 8888 AND ports listed in /etc/services:
hping --scan 1-1000,8888,known -S target.host.com
Groups can be negated (subtracted) using a ! character as prefix,
so the following command line will scan all the ports NOT listed
in /etc/services in the range 1-1024:
hping --scan '1-1024,!known' -S target.host.com
Keep in mind that while hping seems much more like a port scanner in
this mode, most of the hping switches are still honored, so for example to
perform a SYN scan you need to specify the
-S
option, you can change the TCP windows size, TTL, control the
IP fragmentation as usually, and so on. The only real difference is that
the standard hping behaviors are encapsulated into a scanning
algorithm.
Tech note:
The scan mode uses a two-processes design, with shared memory for synchronization. The scanning algorithm is still not optimal, but already quite fast.
Hint:
unlike most scanners, hping shows some interesting info about received
packets, the IP ID, TCP win, TTL, and so on, don't forget to look
at this additional information when you perform a scan! Sometimes they
shows interesting details.
- -9 --listen signature
-
HPING2 listen mode, using this option hping2 waits for packet that contain
signature
and dump from
signature
end to packet's end. For example if hping2 --listen TEST reads a packet
that contain
234-09sdflkjs45-TESThello_world
it will display
hello_world.
IP RELATED OPTIONS
- -a --spoof hostname
-
Use this option in order to set a fake IP source address, this option
ensures that target will not gain your real address. However replies
will be sent to spoofed address, so you will can't see them. In order
to see how it's possible to perform spoofed/idle scanning see the
HPING2-HOWTO.
- --rand-source
-
This option enables the
random source mode.
hping will send packets with random source address. It is interesting
to use this option to stress firewall state tables, and other
per-ip basis dynamic tables inside the TCP/IP stacks and firewall
software.
- --rand-dest
-
This option enables the
random destination mode.
hping will send the packets to random addresses obtained following
the rule you specify as the target host. You need to specify
a numerical IP address as target host like
10.0.0.x.
All the occurrences of
x
will be replaced with a random number in the range 0-255. So to obtain
Internet IP addresses in the whole IPv4 space use something like
hping x.x.x.x --rand-dest.
If you are not sure about what kind of addresses your rule is generating
try to use the
--debug
switch to display every new destination address generated.
When this option is turned on, matching packets will be accept from all
the destinations.
Warning:
when this option is enabled hping can't detect the right outgoing
interface for the packets, so you should use the
--interface
option to select the desired outgoing interface.
- -t --ttl time to live
-
Using this option you can set
TTL (time to live)
of outgoing packets, it's likely that you will use this with
--traceroute
or
--bind
options. If in doubt try
`hping2 some.host.com -t 1 --traceroute'.
- -N --id
-
Set ip->id field. Default id is random but if fragmentation is turned on
and id isn't specified it will be
getpid() & 0xFF,
to implement a better solution is in TODO list.
- -H --ipproto
-
Set the ip protocol in RAW IP mode.
- -W --winid
-
id from Windows* systems before Win2k has different byte ordering, if this
option is enable
hping2 will properly display id replies from those Windows.
- -r --rel
-
Display id increments instead of id. See the
HPING2-HOWTO
for more information. Increments aren't computed as id[N]-id[N-1] but
using packet loss compensation. See relid.c for more information.
- -f --frag
-
Split packets in more fragments, this may be useful in order to test
IP stacks fragmentation performance and to test if some
packet filter is so weak that can be passed using tiny fragments
(anachronistic). Default 'virtual mtu' is 16 bytes. see also
--mtu
option.
- -x --morefrag
-
Set more fragments IP flag, use this option if you want that target
host send an
ICMP time-exceeded during reassembly.
- -y --dontfrag
-
Set don't fragment IP flag, this can be used to perform
MTU path discovery.
- -g --fragoff fragment offset value
-
Set the fragment offset.
- -m --mtu mtu value
-
Set different 'virtual mtu' than 16 when fragmentation is enabled. If
packets size is greater that 'virtual mtu' fragmentation is automatically
turned on.
- -o --tos hex_tos
-
Set
Type Of Service (TOS),
for more information try
--tos help.
- -G --rroute
-
Record route. Includes the RECORD_ROUTE option in each packet sent and
displays the route buffer of returned packets. Note that the IP header
is only large enough for nine such routes. Many hosts ignore or discard
this option. Also note that using hping you are able to use record route
even if target host filter ICMP. Record route is an IP option, not
an ICMP option, so you can use record route option even in TCP and UDP
mode.
ICMP RELATED OPTIONS
- -C --icmptype type
-
Set icmp type, default is
ICMP echo request
(implies --icmp).
- -K --icmpcode code
-
Set icmp code, default is 0 (implies --icmp).
- --icmp-ipver
-
Set IP version of IP header contained into ICMP data, default is 4.
- --icmp-iphlen
-
Set IP header length of IP header contained into ICMP data, default is 5 (5 words of 32 bits).
- --icmp-iplen
-
Set IP packet length of IP header contained into ICMP data, default is the real
length.
- --icmp-ipid
-
Set IP id of IP header contained into ICMP data, default is random.
- --icmp-ipproto
-
Set IP protocol of IP header contained into ICMP data, default is TCP.
- --icmp-cksum
-
Set ICMP checksum, for default is the valid checksum.
- --icmp-ts
-
Alias for --icmptype 13 (to send ICMP timestamp requests).
- --icmp-addr
-
Alias for --icmptype 17 (to send ICMP address mask requests).
TCP/UDP RELATED OPTIONS
- -s --baseport source port
-
hping2 uses source port in order to guess replies sequence number. It
starts with a base source port number, and increase this number for each
packet sent. When packet is received sequence number can be computed as
replies.dest.port - base.source.port.
Default base source port is random, using this option you are able to
set different number. If you need that source port not be increased for
each sent packet use the
-k --keep
option.
- -p --destport [+][+]dest port
-
Set destination port, default is 0. If '+' character precedes dest port
number (i.e. +1024) destination port will be increased for each reply
received. If double '+' precedes dest port number (i.e. ++1024), destination
port will be increased for each packet sent.
By default destination port can be modified interactively using
CTRL+z.
- --keep
-
keep still source port, see
--baseport
for more information.
- -w --win
-
Set TCP window size. Default is 64.
- -O --tcpoff
-
Set fake tcp data offset. Normal data offset is tcphdrlen / 4.
- -M --tcpseq
-
Set the TCP sequence number.
- -L --tcpack
-
Set the TCP ack.
- -Q --seqnum
-
This option can be used in order to collect sequence numbers generated
by target host. This can be useful when you need to analyze whether
TCP sequence number is predictable. Output example:
#hping2 win98 --seqnum -p 139 -S -i u1 -I eth0
HPING uaz (eth0 <IP_ADDRESS>): S set, 40 headers + 0 data bytes
2361294848 +2361294848
2411626496 +50331648
2545844224 +134217728
2713616384 +167772160
2881388544 +167772160
3049160704 +167772160
3216932864 +167772160
3384705024 +167772160
3552477184 +167772160
3720249344 +167772160
3888021504 +167772160
4055793664 +167772160
4223565824 +167772160
The first column reports the sequence number, the second difference
between current and last sequence number. As you can see target host's sequence
numbers are predictable.
- -b --badcksum
-
Send packets with a bad UDP/TCP checksum.
- --tcp-timestamp
-
Enable the TCP timestamp option, and try to guess the timestamp update
frequency and the remote system uptime.
- -F --fin
-
Set FIN tcp flag.
- -S --syn
-
Set SYN tcp flag.
- -R --rst
-
Set RST tcp flag.
- -P --push
-
Set PUSH tcp flag.
- -A --ack
-
Set ACK tcp flag.
- -U --urg
-
Set URG tcp flag.
- -X --xmas
-
Set Xmas tcp flag.
- -Y --ymas
-
Set Ymas tcp flag.
COMMON OPTIONS
- -d --data data size
-
Set packet body size. Warning, using --data 40 hping2 will not generate
0 byte packets but protocol_header+40 bytes. hping2 will display
packet size information as first line output, like this:
HPING www.yahoo.com (ppp0 <IP_ADDRESS>): NO FLAGS are set, 40 headers + 40 data bytes
- -E --file filename
-
Use
filename
contents to fill packet's data.
- -e --sign signature
-
Fill first
signature length
bytes of data with
signature.
If the
signature length
is bigger than data size an error message will be displayed.
If you don't specify the data size hping will use the signature
size as data size.
This option can be used safely with
--file filename
option, remainder data space will be filled using
filename.
- -j --dump
-
Dump received packets in hex.
- -J --print
-
Dump received packets' printable characters.
- -B --safe
-
Enable safe protocol, using this option lost packets in file transfers
will be resent. For example in order to send file /etc/passwd from host
A to host B you may use the following:
[host_a]
# hping2 host_b --udp -p 53 -d 100 --sign signature --safe --file /etc/passwd
[host_b]
# hping2 host_a --listen signature --safe --icmp
- -u --end
-
If you are using
--file filename
option, tell you when EOF has been reached. Moreover prevent that other end
accept more packets. Please, for more information see the
HPING2-HOWTO.
- -T --traceroute
-
Traceroute mode. Using this option hping2 will increase ttl for each
ICMP time to live 0 during transit
received. Try
hping2 host --traceroute.
This option implies --bind and --ttl 1. You can override the ttl of 1
using the --ttl option. Since 2.0.0 stable it prints RTT information.
- --tr-keep-ttl
-
Keep the TTL fixed in traceroute mode, so you can monitor just one hop
in the route. For example, to monitor how the 5th hop changes or
how its RTT changes you can try
hping2 host --traceroute --ttl 5 --tr-keep-ttl.
- --tr-stop
-
If this option is specified hping will exit once the first packet
that isn't an ICMP time exceeded is received. This better emulates
the traceroute behavior.
- --tr-no-rtt
-
Don't show RTT information in traceroute mode. The ICMP time exceeded RTT
information aren't even calculated if this option is set.
- --tcpexitcode
-
Exit with last received packet tcp->th_flag as exit code. Useful for scripts
that need, for example, to known if the port 999 of some host reply with
SYN/ACK or with RST in response to SYN, i.e. the service is up or down.
TCP OUTPUT FORMAT
The standard TCP output format is the following:
len=46 ip=<IP_ADDRESS> flags=RA DF seq=0 ttl=255 id=0 win=0 rtt=0.4 ms
len
is the size, in bytes, of the data captured from the data link layer
excluding the data link header size. This may not match the IP datagram
size due to low level transport layer padding.
ip
is the source ip address.
flags
are the TCP flags, R for RESET, S for SYN, A for ACK, F for FIN,
P for PUSH, U for URGENT, X for not standard 0x40, Y for not standard
0x80.
If the reply contains
DF
the IP header has the don't fragment bit set.
seq
is the sequence number of the packet, obtained using the source
port for TCP/UDP packets, the sequence field for ICMP packets.
id
is the IP ID field.
win
is the TCP window size.
rtt
is the round trip time in milliseconds.
If you run hping using the
-V
command line switch it will display additional information about the
packet, example:
len=46 ip=<IP_ADDRESS> flags=RA DF seq=0 ttl=255 id=0 win=0 rtt=0.4 ms
tos=0 iplen=40 seq=0 ack=1223672061 sum=e61d urp=0
tos
is the type of service field of the IP header.
iplen
is the IP total len field.
seq and ack
are the sequence and acknowledge 32bit numbers in the TCP header.
sum
is the TCP header checksum value.
urp
is the TCP urgent pointer value.
UDP OUTPUT FORMAT
The standard output format is:
len=46 ip=<IP_ADDRESS> seq=0 ttl=64 id=0 rtt=6.0 ms
The field meaning is just the same as the TCP output meaning of the
same fields.
ICMP OUTPUT FORMAT
An example of ICMP output is:
ICMP Port Unreachable from ip=<IP_ADDRESS> name=nano.marmoc.net
It is very simple to understand. It starts with the string "ICMP"
followed by the description of the ICMP error, Port Unreachable
in the example. The ip field is the IP source address of the IP
datagram containing the ICMP error, the name field is just the
numerical address resolved to a name (a dns PTR request) or UNKNOWN if the
resolution failed.
The ICMP Time exceeded during transit or reassembly format is a bit
different:
TTL 0 during transit from ip=<IP_ADDRESS> name=nano.marmoc.net
TTL 0 during reassembly from ip=<IP_ADDRESS> name=UNKNOWN
The only difference is the description of the error, it starts with
TTL 0.
AUTHOR
Salvatore Sanfilippo<EMAIL_ADDRESS>with the help of the people mentioned in AUTHORS file and at http://www.hping.org/authors.html
BUGS
Even using the --end and --safe options to transfer files the final packet
will be padded with 0x00 bytes.
Data is read without care about alignment, but alignment is enforced
in the data structures.
This will not be a problem under i386 but, while usually the TCP/IP
headers are naturally aligned, may create problems with different
processors and bogus packets if there is some unaligned access around
the code (hopefully none).
On solaris hping does not work on the loopback interface. This seems
a solaris problem, as stated in the tcpdump-workers mailing list,
so the libpcap can't do nothing to handle it properly.

Time: 18:58:26 GMT, August 22, 2012


TheStig other than being a fantastic driver, is a fantastic IRC bot. Check it out on GitHub!
Recently TheStig was renamed to Mana and is no longer a Lexteam project. See the website here.
--- layout: default title: TheStig permalink: /software/thestig/ redirect_from: /projects/thestig/ section: software ---