text:
# Is this ESD safe circuit?

I am trying to make a AC Mains detection circuit with ESD protection. The AC switch is located 30 meters away from the circuit board.

Of the two circuits, which is better for ESD protection & mains isolation? In Schematic One, is connecting the other end of TVS diode to AC Neutral correct?

Please suggest if there need to be any modification.

TVS Diode: TPD1E10B066 http://www.ti.com/lit/ds/sllseb1d/sllseb1d.pdf

Schematic: One

Schematic:Two

EDIT: Let me explain the scenario in detail. There are quite a lot of switches to be monitored. Inductive loads are also there. All the switches have very long wires & I am concerned about the excess energy that reach the optocoupler during switching, spikes in the line or by lightning. What is the best way to protect from such occurrences?

• Are you connecting the TVS and the Zener to the low-voltage ground on purpose? – marcelm Sep 1 '17 at 15:26
• The bottom circuit with TVS and ZD to ground is no good. You're making a conductive path between mains (neutral and live) to ground. Best case: your GFCI will trip. Worst case: all grounded equipment will have a live voltage. Top circuit should be OK. I do not like using a ground symbol for AC neutral though, often AC neutral is not neutral and can have some voltage. – Bimpelrekkie Sep 1 '17 at 15:30
• @Bimpelrekkie There's no indication at all that signal ground is connected to earth or chassis or anything. – marcelm Sep 1 '17 at 15:34
• Regarding ESD protection: you do not actually need it. The mains live side (the LED and everything to its left) are not ESD sensitive and you're not going to touch the connections anyway as they're not safe to touch (neutral not always being without a voltage). MCU side: The only real sensitive component is the MCU and it will have proper ESD protection. No additional protection is needed. – Bimpelrekkie Sep 1 '17 at 15:35
• I'd like you to explain what you mean by ESD. I don't think you mean the same thing as the rest of us, judging from this question. ESD is normally not a problem with line voltage circuits. – pipe Sep 1 '17 at 15:37

I would create a Zero Crossing Switch narrow pulse (ZCS) instead of sine to square. Set the output R high (not 2k) to obtain CTR of 1%. Add cap to input R for <1kHz LPF to adjust phase shift but attenuate spikes. This is a bidirectional opto with isolation rating >5kV.

http://www.vishay.com/docs/83675/sfh620a.pdf

A Cap Voltage transformer using X rated 0.047 uF to ceramic 1 uF results in 1% sine voltage at lower impedance then series RC to opto can use low power R.

Here shown with Rin only between line and neutral may give a wider positive output pulse at zero crossing.

Alternatively, a square wave to pulse conversion just uses both inputs of an XOR gate with 1us RC delay on one input.

Neither A or B. Remove the TVS, zener,...

simulate this circuit – Schematic created using CircuitLab

• I agreem the TVS and zener do not harm but are overkill and not needed. – Bimpelrekkie Sep 1 '17 at 15:30
• Vac threshold will vary with load , CTR and needs a LPF on input. R needs to be rated for 2kV transients minimum. – Tony Stewart Sunnyskyguy EE75 Sep 1 '17 at 15:43
• @TonyStewart.EEsince'75 I just purged out unnecessary components as an example. OP has to calculate the CTR and other things to suit the needs. He was concerning just about ESD. – Marko Buršič Sep 1 '17 at 15:47
• I think he meant PLT, not ESD – Tony Stewart Sunnyskyguy EE75 Sep 1 '17 at 15:55
• @TonyStewart.EEsince'75 I can read only ESD from his post, anyway what's a PLT? – Marko Buršič Sep 1 '17 at 16:05

The TVS, zener and 100R resistor do nothing of value. If you want to protect against transients, make sure that the 220K resistor is rated for very high breakdown voltage. For example the 1W VR68 series (leaded). You need a diode inverse parallel across the LED- a 1N4148 or LL4148 is plenty good enough- those are rated for 75V or so PIV (it will see less than 1.5V) and 200mA.

Even with 5kV on the resistor only 23mA will flow, which the LED and diode will have no problem with. If the resistor arcs over, even the TVS may not be enough to preserve functionality.

$R1 = \frac {V_{MAINS} - 90 }{I_{NEON}}$. (90 V is typical neon operating voltage.) The LDR's slow time constant should keep the reading stable during mains zero-cross.


text:
# while Statement

### Import the random module

import random

### Create a variable of the true number of deaths of an event

deaths = 6

## Create a variable that is denotes if the while loop should keep running

running = True

### while running is True

while running:
# Create a variable that randomly create a integer between 0 and 10.
guess = random.randint(0,10)

# if guess equals deaths,
if guess == deaths:
# then print this
print('Correct!')
# and then also change running to False to stop the script
running = False
# else if guess is lower than deaths
elif guess < deaths:
# then print this
print('No, it is higher.')
# if guess is none of the above
else:
# print this
print('No, it is lower')
No, it is higher.
No, it is higher.
Correct!

By the output, you can see that the while script keeping generating guesses and checking them until guess matches deaths, in which case the script stops.

format: plain


text:
# Stake Delegation and Rewards

Stakers are rewarded for helping to validate the ledger. They do this by delegating their stake to validator nodes. Those validators do the legwork of replaying the ledger and sending votes to a per-node vote account to which stakers can delegate their stakes. The rest of the cluster uses those stake-weighted votes to select a block when forks arise. Both the validator and staker need some economic incentive to play their part. The validator needs to be compensated for its hardware and the staker needs to be compensated for the risk of getting its stake slashed. The economics are covered in staking rewards. This section, on the other hand, describes the underlying mechanics of its implementation.

## Basic Design#

The general idea is that the validator owns a Vote account. The Vote account tracks validator votes, counts validator generated credits, and provides any additional validator specific state. The Vote account is not aware of any stakes delegated to it and has no staking weight.

A separate Stake account (created by a staker) names a Vote account to which the stake is delegated. Rewards generated are proportional to the amount of lamports staked. The Stake account is owned by the staker only. Some portion of the lamports stored in this account are the stake.

## Passive Delegation#

Any number of Stake accounts can delegate to a single Vote account without an interactive action from the identity controlling the Vote account or submitting votes to the account.

The total stake allocated to a Vote account can be calculated by the sum of all the Stake accounts that have the Vote account pubkey as the StakeState::Stake::voter_pubkey.

## Vote and Stake accounts#

The rewards process is split into two on-chain programs. The Vote program solves the problem of making stakes slashable. The Stake program acts as custodian of the rewards pool and provides for passive delegation. The Stake program is responsible for paying rewards to staker and voter when shown that a staker's delegate has participated in validating the ledger.

VoteState is the current state of all the votes the validator has submitted to the network. VoteState contains the following state information:

• votes - The submitted votes data structure.
• credits - The total number of rewards this Vote program has generated over its lifetime.
• root_slot - The last slot to reach the full lockout commitment necessary for rewards.
• commission - The commission taken by this VoteState for any rewards claimed by staker's Stake accounts. This is the percentage ceiling of the reward.
• Account::lamports - The accumulated lamports from the commission. These do not count as stakes.
• authorized_voter - Only this identity is authorized to submit votes. This field can only modified by this identity.
• node_pubkey - The Solana node that votes in this account.
• authorized_withdrawer - the identity of the entity in charge of the lamports of this account, separate from the account's address and the authorized vote signer.

### VoteInstruction::Initialize(VoteInit)#

• account[0] - RW - The VoteState.

VoteInit carries the new vote account's node_pubkey, authorized_voter, authorized_withdrawer, and commission.

### VoteInstruction::Authorize(Pubkey, VoteAuthorize)#

Updates the account with a new authorized voter or withdrawer, according to the VoteAuthorize parameter (Voter or Withdrawer). The transaction must be signed by the Vote account's current authorized_voter or authorized_withdrawer.

• account[0] - RW - The VoteState. VoteState::authorized_voter or authorized_withdrawer is set to Pubkey.

### VoteInstruction::Vote(Vote)#

• account[0] - RW - The VoteState. VoteState::lockouts and VoteState::credits are updated according to voting lockout rules see Tower BFT.
• account[1] - RO - sysvar::slot_hashes A list of some N most recent slots and their hashes for the vote to be verified against.
• account[2] - RO - sysvar::clock The current network time, expressed in slots, epochs.

### StakeState#

A StakeState takes one of four forms, StakeState::Uninitialized, StakeState::Initialized, StakeState::Stake, and StakeState::RewardsPool. Only the first three forms are used in staking, but only StakeState::Stake is interesting. All RewardsPools are created at genesis.

### StakeState::Stake#

StakeState::Stake is the current delegation preference of the staker and contains the following state information:

• Account::lamports - The lamports available for staking.
• stake - the staked amount (subject to warmup and cooldown) for generating rewards, always less than or equal to Account::lamports.
• voter_pubkey - The pubkey of the VoteState instance the lamports are delegated to.
• credits_observed - The total credits claimed over the lifetime of the program.
• activated - the epoch at which this stake was activated/delegated. The full stake will be counted after warmup.
• deactivated - the epoch at which this stake was de-activated, some cooldown epochs are required before the account is fully deactivated, and the stake available for withdrawal.
• authorized_staker - the pubkey of the entity that must sign delegation, activation, and deactivation transactions.
• authorized_withdrawer - the identity of the entity in charge of the lamports of this account, separate from the account's address, and the authorized staker.

### StakeState::RewardsPool#

To avoid a single network-wide lock or contention in redemption, 256 RewardsPools are part of genesis under pre-determined keys, each with std::u64::MAX credits to be able to satisfy redemptions according to point value.

The Stakes and the RewardsPool are accounts that are owned by the same Stake program.

### StakeInstruction::DelegateStake#

The Stake account is moved from Initialized to StakeState::Stake form, or from a deactivated (i.e. fully cooled-down) StakeState::Stake to activated StakeState::Stake. This is how stakers choose the vote account and validator node to which their stake account lamports are delegated. The transaction must be signed by the stake's authorized_staker.

• account[0] - RW - The StakeState::Stake instance. StakeState::Stake::credits_observed is initialized to VoteState::credits, StakeState::Stake::voter_pubkey is initialized to account[1]. If this is the initial delegation of stake, StakeState::Stake::stake is initialized to the account's balance in lamports, StakeState::Stake::activated is initialized to the current Bank epoch, and StakeState::Stake::deactivated is initialized to std::u64::MAX
• account[1] - R - The VoteState instance.
• account[2] - R - sysvar::clock account, carries information about current Bank epoch.
• account[3] - R - sysvar::stakehistory account, carries information about stake history.
• account[4] - R - stake::Config account, carries warmup, cooldown, and slashing configuration.

### StakeInstruction::Authorize(Pubkey, StakeAuthorize)#

Updates the account with a new authorized staker or withdrawer, according to the StakeAuthorize parameter (Staker or Withdrawer). The transaction must be by signed by the Stakee account's current authorized_staker or authorized_withdrawer. Any stake lock-up must have expired, or the lock-up custodian must also sign the transaction.

• account[0] - RW - The StakeState.

StakeState::authorized_staker or authorized_withdrawer is set to to Pubkey.

### StakeInstruction::Deactivate#

A staker may wish to withdraw from the network. To do so he must first deactivate his stake, and wait for cooldown. The transaction must be signed by the stake's authorized_staker.

• account[0] - RW - The StakeState::Stake instance that is deactivating.
• account[1] - R - sysvar::clock account from the Bank that carries current epoch.

StakeState::Stake::deactivated is set to the current epoch + cooldown. The account's stake will ramp down to zero by that epoch, and Account::lamports will be available for withdrawal.

### StakeInstruction::Withdraw(u64)#

Lamports build up over time in a Stake account and any excess over activated stake can be withdrawn. The transaction must be signed by the stake's authorized_withdrawer.

• account[0] - RW - The StakeState::Stake from which to withdraw.
• account[1] - RW - Account that should be credited with the withdrawn lamports.
• account[2] - R - sysvar::clock account from the Bank that carries current epoch, to calculate stake.
• account[3] - R - sysvar::stake_history account from the Bank that carries stake warmup/cooldown history.

## Benefits of the design#

• Single vote for all the stakers.
• Clearing of the credit variable is not necessary for claiming rewards.
• Each delegated stake can claim its rewards independently.
• Commission for the work is deposited when a reward is claimed by the delegated stake.

## Staking Rewards#

The specific mechanics and rules of the validator rewards regime is outlined here. Rewards are earned by delegating stake to a validator that is voting correctly. Voting incorrectly exposes that validator's stakes to slashing.

### Basics#

The network pays rewards from a portion of network inflation. The number of lamports available to pay rewards for an epoch is fixed and must be evenly divided among all staked nodes according to their relative stake weight and participation. The weighting unit is called a point.

Rewards for an epoch are not available until the end of that epoch.

At the end of each epoch, the total number of points earned during the epoch is summed and used to divide the rewards portion of epoch inflation to arrive at a point value. This value is recorded in the bank in a sysvar that maps epochs to point values.

During redemption, the stake program counts the points earned by the stake for each epoch, multiplies that by the epoch's point value, and transfers lamports in that amount from a rewards account into the stake and vote accounts according to the vote account's commission setting.

### Economics#

Point value for an epoch depends on aggregate network participation. If participation in an epoch drops off, point values are higher for those that do participate.

### Earning credits#

Validators earn one vote credit for every correct vote that exceeds maximum lockout, i.e. every time the validator's vote account retires a slot from its lockout list, making that vote a root for the node.

Stakers who have delegated to that validator earn points in proportion to their stake. Points earned is the product of vote credits and stake.

### Stake warmup, cooldown, withdrawal#

Stakes, once delegated, do not become effective immediately. They must first pass through a warmup period. During this period some portion of the stake is considered "effective", the rest is considered "activating". Changes occur on epoch boundaries.

The stake program limits the rate of change to total network stake, reflected in the stake program's config::warmup_rate (set to 25% per epoch in the current implementation).

The amount of stake that can be warmed up each epoch is a function of the previous epoch's total effective stake, total activating stake, and the stake program's configured warmup rate.

Cooldown works the same way. Once a stake is deactivated, some part of it is considered "effective", and also "deactivating". As the stake cools down, it continues to earn rewards and be exposed to slashing, but it also becomes available for withdrawal.

Bootstrap stakes are not subject to warmup.

Rewards are paid against the "effective" portion of the stake for that epoch.

#### Warmup example#

Consider the situation of a single stake of 1,000 activated at epoch N, with network warmup rate of 20%, and a quiescent total network stake at epoch N of 2,000.

At epoch N+1, the amount available to be activated for the network is 400 (20% of 2000), and at epoch N, this example stake is the only stake activating, and so is entitled to all of the warmup room available.

epocheffectiveactivatingtotal effectivetotal activating
N-12,0000
N01,0002,0001,000
N+14006002,400600
N+28801202,880120
N+3100003,0000

Were 2 stakes (X and Y) to activate at epoch N, they would be awarded a portion of the 20% in proportion to their stakes. At each epoch effective and activating for each stake is a function of the previous epoch's state.

epochX effX actY effY acttotal effectivetotal activating
N-12,0000
N01,00002002,0001,200
N+1333667671332,400800
N+2733267146542,880321
N+31000020003,2000

### Withdrawal#

Only lamports in excess of effective+activating stake may be withdrawn at any time. This means that during warmup, effectively no stake can be withdrawn. During cooldown, any tokens in excess of effective stake may be withdrawn (activating == 0). Because earned rewards are automatically added to stake, withdrawal is generally only possible after deactivation.

### Lock-up#

Stake accounts support the notion of lock-up, wherein the stake account balance is unavailable for withdrawal until a specified time. Lock-up is specified as an epoch height, i.e. the minimum epoch height that must be reached by the network before the stake account balance is available for withdrawal, unless the transaction is also signed by a specified custodian. This information is gathered when the stake account is created, and stored in the Lockup field of the stake account's state. Changing the authorized staker or withdrawer is also subject to lock-up, as such an operation is effectively a transfer.


text:
# zbMATH — the first resource for mathematics

Optimal investment and consumption with labor income in incomplete markets. (English) Zbl 1447.91162
Summary: We consider the problem of optimal consumption from labor income and investment in a general incomplete semimartingale market. The economic agent cannot borrow against future income, so the total wealth is required to be positive at (all or some) previous times. Under very general conditions, we show that an optimal consumption and investment plan exists and is unique, and provide a dual characterization in terms of an optional strong supermartingale deflator and a decreasing part, which charges only the times when the no-borrowing constraint is binding. The analysis relies on the infinite-dimensional parametrization of the income/liability streams and, therefore, provides the first-order dependence of the optimal investment and consumption plans on future income/liabilities (as well as a pricing rule).
##### MSC:
 91G10 Portfolio theory 93E20 Optimal stochastic control 91B16 Utility theory
Full Text:
##### References:
 [1] Bank, P. and Kauppila, H. (2017). Convex duality for stochastic singular control problems. Ann. Appl. Probab. 27 485-516. · Zbl 1360.93765 [2] Barbu, V. and Precupanu, T. (2012). Convexity and Optimization in Banach Spaces, 4th ed. Springer Monographs in Mathematics. Springer, Dordrecht. · Zbl 1244.49001 [3] Brannath, W. and Schachermayer, W. (1999). A bipolar theorem for $$L^0_+(\Omega,\mathcal{F},\mathbb{P})$$. In Séminaire de Probabilités, XXXIII. Lecture Notes in Math. 1709 349-354. Springer, Berlin. · Zbl 0957.46020 [4] Campi, L. and Schachermayer, W. (2006). A super-replication theorem in Kabanov’s model of transaction costs. Finance Stoch. 10 579-596. · Zbl 1126.91024 [5] Cuchiero, C. and Teichmann, J. (2015). A convergence result for the Emery topology and a variant of the proof of the fundamental theorem of asset pricing. Finance Stoch. 19 743-761. · Zbl 1341.60018 [6] Cuoco, D. (1997). Optimal consumption and equilibrium prices with portfolio constraints and stochastic income. J. Econom. Theory 72 33-73. · Zbl 0883.90050 [7] Cvitanic, J., Schachermayer, W. and Wang, H. (2001). Utility maximization in incomplete markets with random endowment. Finance Stoch. 5 259-272. · Zbl 0993.91018 [8] Czichowsky, C. and Schachermayer, W. (2016). Strong supermartingales and limits of nonnegative martingales. Ann. Probab. 44 171-205. · Zbl 1339.60045 [9] Delbaen, F. and Schachermayer, W. (1994). A general version of the fundamental theorem of asset pricing. Math. Ann. 300 463-520. · Zbl 0865.90014 [10] Delbaen, F. and Schachermayer, W. (1997). The Banach space of workable contingent claims in arbitrage theory. Ann. Inst. Henri Poincaré Probab. Stat. 33 113-144. · Zbl 0872.90008 [11] Delbaen, F. and Schachermayer, W. (1998). The fundamental theorem of asset pricing for unbounded stochastic processes. Math. Ann. 312 215-250. · Zbl 0917.60048 [12] Dellacherie, C. and Meyer, P.-A. (1982). Probabilities and Potential. B: Theory of Martingales. North-Holland Mathematics Studies 72. North-Holland, Amsterdam. · Zbl 0494.60002 [13] Duffie, D., Fleming, W., Soner, H. M. and Zariphopoulou, T. (1997). Hedging in incomplete markets with HARA utility. J. Econom. Dynam. Control 21 753-782. · Zbl 0899.90026 [14] Duffie, D. and Zariphopoulou, T. (1993). Optimal investment with undiversifiable income risk. Math. Finance 3 135-148. · Zbl 0884.90062 [15] Ekeland, I. and Temam, R. (1976). Convex Analysis and Variational Problems. North-Holland, Amsterdam. · Zbl 0322.90046 [16] El Karoui, N. and Jeanblanc-Picque, M. (1998). Optimization of consumption with labor income. Finance Stoch. 2 409-440. · Zbl 0930.60050 [17] Föllmer, H. and Kramkov, D. (1997). Optional decompositions under constraints. Probab. Theory Related Fields 109 1-25. · Zbl 0882.60063 [18] He, H. and Pagès, H. F. (1993). Labor income, borrowing constraints, and equilibrium asset prices. Econom. Theory 3 663-696. · Zbl 0820.90028 [19] Hugonnier, J. and Kramkov, D. (2004). Optimal investment with random endowments in incomplete markets. Ann. Appl. Probab. 14 845-864. · Zbl 1086.91030 [20] Hugonnier, J., Kramkov, D. and Schachermayer, W. (2005). On utility-based pricing of contingent claims in incomplete markets. Math. Finance 15 203-212. · Zbl 1124.91338 [21] Jacod, J. and Shiryaev, A. N. (2003). Limit Theorems for Stochastic Processes, 2nd ed. Grundlehren der Mathematischen Wissenschaften [Fundamental Principles of Mathematical Sciences] 288. Springer, Berlin. · Zbl 1018.60002 [22] Karatzas, I. (1989). Optimization problems in the theory of continuous trading. SIAM J. Control Optim. 27 1221-1259. · Zbl 0701.90008 [23] Karatzas, I. and Kardaras, C. (2007). The numéraire portfolio in semimartingale financial models. Finance Stoch. 11 447-493. · Zbl 1144.91019 [24] Karatzas, I. and Žitkovic, G. (2003). Optimal consumption from investment and random endowment in incomplete semimartingale markets. Ann. Probab. 31 1821-1858. · Zbl 1076.91017 [25] Kardaras, C. (2013). On the closure in the Emery topology of semimartingale wealth-process sets. Ann. Appl. Probab. 23 1355-1376. · Zbl 1408.91196 [26] Klein, I., Lépinette, E. and Perez-Ostafe, L. (2014). Asymptotic arbitrage with small transaction costs. Finance Stoch. 18 917-939. · Zbl 1309.60042 [27] Kramkov, D. O. (1996). Optional decomposition of supermartingales and hedging contingent claims in incomplete security markets. Probab. Theory Related Fields 105 459-479. · Zbl 0853.60041 [28] Malamud, S. and Trubowitz, E. (2007). The structure of optimal consumption streams in general incomplete markets. Math. Financ. Econ. 1 129-161. · Zbl 1204.91064 [29] Matoussi, A. and Xing, H. (2018). Convex duality for Epstein-Zin stochastic differential utility. Math. Finance 28 991-1019. · Zbl 1417.91470 [30] Mnif, M. and Pham, H. (2001). Stochastic optimization under constraints. Stochastic Process. Appl. 93 149-180. · Zbl 1070.93050 [31] Mostovyi, O. (2015). Necessary and sufficient conditions in the problem of optimal investment with intermediate consumption. Finance Stoch. 19 135-159. · Zbl 1309.91134 [32] Mostovyi, O. (2017). Optimal investment with intermediate consumption and random endowment. Math. Finance 27 96-114. · Zbl 1391.91149 [33] Protter, P. E. (2004). Stochastic Integration and Differential Equations: Stochastic Modelling and Applied Probability, 2nd ed. Applications of Mathematics (New York) 21. Springer, Berlin. · Zbl 1041.60005 [34] Rásonyi, M. (2018). On utility maximization without passing by the dual problem. Stochastics 90 955-971. [35] Rokhlin, D. B. (2010). On the existence of an equivalent supermartingale density for a fork-convex family of random processes. Mat. Zametki 87 594-603. · Zbl 1203.60046 [36] Yu, X. (2015). Utility maximization with addictive consumption habit formation in incomplete semimartingale markets. Ann. Appl. Probab. 25 1383-1419. · Zbl 1312.91084 [37] Žitkovic, G. · Zbl 1108.91032
This reference list is based on information provided by the publisher or from digital mathematics libraries. Its items are heuristically matched to zbMATH identifiers and may contain data conversion errors. It attempts to reflect the references listed in the original paper as accurately as possible without claiming the completeness or perfect precision of the matching.