ol-ext: DrawRegular interaction
ol.interaction.DrawRegular
is an interaction to draw regular polygon (circle/ellipse, triangle, square/rectangles, etc).


All functions
|
|
construct_mran_url()
|
Construct MRAN url if snapshot date provided |
|
copy_electricshine_package()
|
Copy electricShine package to an isolated folder.
This is necessary to avoid dependency-install issues |
|
copy_remotes_package()
|
Copy remotes package to an isolated folder.
This is necessary to avoid dependency-install issues |
|
copy_template()
|
Copy Electron boilerplate into app_root_path |
|
create_build_directory()
|
Create a directory for creating the new app and copy template of files |
|
create_folder()
|
Create an output folder |
|
create_package_json()
|
Create the package.json file for npm |
|
.check_arch()
|
Check if compatible architecture |
|
.check_build_path_exists()
|
Check whether build path exists |
|
.check_node_works()
|
Check if Node works |
|
.check_npm_works()
|
Check if npm works |
|
.check_package_provided()
|
Check package paths |
|
.check_repo_set()
|
Check that a repo for packages/R was set |
|
.download_r()
|
Download R installer given its url |
|
.find_win_exe_url()
|
Find Windows R installer URL from MRAN snapshot |
|
.install_mac_r()
|
Download and untar mac R into app folder |
|
.install_win_r()
|
Install R for Windows at given path |
|
.ping_url()
|
Check internet connection |
|
.prompt_install_nodejs()
|
Prompt whether nodejs can be installed or not |
|
.prompt_install_r()
|
Prompt whether R can be installed or not |
|
electrify()
|
Meta-function |
|
get_os()
|
Get operating system |
|
install_nodejs()
|
Install Node.js |
|
install_package()
|
Install from isolated lib |
|
install_r()
|
Install R from MRAN date into electricShine folder |
|
install_user_app()
|
Install shiny app package and dependencies |
|
modify_background_js()
|
Modify background.js to include the call to the shiny app |
|
modify_mac_r()
|
Change fixed paths to make R portable on Mac |
|
run_build_release()
|
Create an electron-builder release |
|
system_install_pkgs()
|
Run package installation using the newly-installed R |
|
trim_r()
|
Remove html and pdf files from R installation |
|
write_text()
|
Write to a file |


Meaty is a kid from the Steaky species who lives in Butcherland. The Steaky species can run very fast and jump up high. The Steaky species are small, but they are very brave.
Use your special parkour abilities to overcome all the obstacles, avoid sharp object, beat all the tenderizers and fight against great evil! Test your agility to run, jump, collect gold, defeat the deadly attacks of evil enemies.


Log in
You have been logged out successfully.
Your username and password is invalid.
username
password
Log In
Create an account
reset


Well I got a couple CT's last night so I was finally able to get something running. Only have sct-013's so I can not monitor main panel current yet. For now it is setup on my heatpump. I have protoboards, headers, and headphone jacks on the way so soon I can put together a cleaner setup and be able to return my daughters Lego bin lid. System is North American 120/60hz. Goal is an as small as possible single collector/transmitter connected to web.
Code is here: https://github.com/officeboy/EmonCore
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Hey, nice work!
I'm definitely interested in this. I especially like the super small size and built-in wifi. I know they're not available till next month, but have you thought about using the Photon?
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
The photon is what got me thinking about going this route, I already had some jeenodes, but one has a bad radio and I wasn't sure if the range was going to work out. The Photon for $19 and that small form factor is ++good.
I ordered the Photon Prototype kit. Comes with a Core now, and a Photon when available.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Quick update; shipping on parts is slow, but I did get my little 1.3" OLED screen. Turns out to be something there isn't really a library for, so I am modifying an arduino one to work on the spark, it gave some output last night, but was putting my unit into panic/reboot mode.
In the meantime I need to start putting together a schematic, I think I am going to go with (what I assume to be) Robert Walls, Buffered Voltage Bias circuit. Hopeful it will scale up well.
I got good data for a few days and it matched up very nicely with what I was seeing in power usage (I get daily usage reports from my power company).
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Nope, it was originally Robin's. What do you mean by "scale up"? - as the input current is barely more than that needed to charge the Sample & Hold capacitor, you ought to be able to hang any (sensible) number of input devices off the op. amp. output.
If you have a lot of inputs, note that when using that, you need only one software low pass filter to extract the dc, because that dc 'sit' is common to all the inputs. It speeds up the input processing but you'll need to customise emonLib to get any benefit.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Scale up means I expect to have 16 inputs,and I hope to avoid having 16 voltage dividers with the use of a single buffered virtual ground. I have 8 inputs on my arm chip and will add 8 more with a stackable "shield" using probably a MAX11615EEE, but I haven't decided on that yet. I'll get all 8 inputs working first.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Whether you get any interaction will depend on the input characteristics of your ADC, but if the input impedance is high, and the capacitance (S&H + stray) is low, then I don't see a problem with 16 inputs using the same buffer op. amp. The demands are not all that onerous: all that's needed for the Atmel 328 is for the output impedance with the feedback in place to be such that the input stays within one ADC step when the multiplexer switches. If you also have a multiplexer in front of a single ADC, it's an identical situation; if you have separate ADCs for each channel, then it's slightly different but the requirement is identical even though the perturbation comes from the combined effect of all the other channels 'pulling' the bias source, rather than just the one channel switching.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Anyone have comments on my first stab at making a PCB (that isn't a point to point proto).
https://github.com/officeboy/EmonCore/tree/master/hardware
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Don't leave the unused inputs of the spare op.amp floating. You might as well make it a unity gain follower and tie the + input to VGround. (Now there's a confusing name! Vmid(point) or Vbias? I realise it was called that in the link you referenced earlier, but that isn't its function here, here it is an offset bias, biasing the quiescent input to the midpoint of the ADC input range.)
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Thanks, Robert. I had planed on using a single channel opamp, but the software I started using didn't have one in it's library. I switched to eagle so that I could use the actual footprint of the 3.5mm jacks I have.
Anyway quick story. I used to do a lot of audio stuff back about 10-12 years ago. I was semi active in the DIYaudio forum and made a few chipamps, an aleph-x etc. So opamps are no big deal... right? I have dip-8 sockets. Well I got my digikey order yesterday with my max11516 16-tsop and the lvm321 tc-70. Holy cow. What am I supposed to do with these things? I think I did a decent job considering, but I may need to get some breakout boards for prototyping.
That 16 pin ADC is going to be impossible, without a proper pad.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
"So opamps are no big deal... right?"
I had no idea what your previous experience was, surely it's better to point out what might have been an oversight before you had pcb's made, rather than explaining what an unconnected oscillating op. amp was doing to its other half?
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I only meant no big deal in terms of soldering to a proto board. Selection and implementation are a whole different issue. And I do/did appreciate the feedback, in audio work generally the extra amps would be used as an input preamp/follower, or differentials from crossover circuits or phase adjusters. I changed that fritzing schematic, but then scrapped the whole thing and went to eagle.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Had a chance to put some things together while I was sick today.
http://imgur.com/a/7ZgRc
(with flash)
Main leg CTs are working, but something isn't right with the two sub circuits. I'll need to review if it is a code issue or a wiring thing. They worked ok testing on a 60W light, but I should have spent more time on them.
I have 50 ohm burdens on the sct-013,and 32ohm on the sct-019's.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Turns out that the 3.5mm jacks are not making good contact with the stereo plugs that come on the sct-013's. Does anyone know of a specific jack that works OK and is less than a buck a piece?
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Dustin,
Here's a 3.5mm Nickel panel mount stereo jack for $0.43
www.bgmicro.com/AUDCA017.aspx
Regards,
Bill
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Sorry if this question is not adequate im new here trying to get into the project, but how are you using the graphing in real time? where did you get the code or how did you made it, to post it in the forum, are you using the emon cms? i would really love to have a graph like that in real time for my home
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
It is just the vis part of emoncms.org.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
thanks i will check it out,
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Nice project! Photon looks like a cool board. How easy was it to develop for? Have you heard any more info on RFM12B / RFM69CW support on the Photon?
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
It has been pretty easy to build, and the IDE is pretty close to arduino so there isn't much of a learning curve. I have been pulled away to a few other projects, and haven't touched this in a bit. The only issue I have is dropping signal. The photon's external antenna will be a nice feature for cases like mine where the AP is 50+ feet away.
I know there is a RFM69 library, but that is all I know about it.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I have a photon on order and will be attempting this when I get it. I had originally ordered it to build a garage door opener, but this seems like a better use of it.
The biggest attraction is the fact that you can remotely load sketches to it and its already connected to the internet.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
If your power panel is in your garage I don't know why you can't do both. In fact I should do that. I am not really using any digital outputs, tie one to a relay and wire that in with the button. Nice idea! Could open by timer, ITTT, or webaddress (homepage link from phone).
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I am already doing temperature, voltage and 3 CTs monitoring and solar diverting. Does the photon have enough of power to do more?
How does the ADC on the photon / core compare to the Arduino Uno?
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
The photon is a 120Mhz 32-bit ARM cpu (the core is 72Mhz). I have no idea how that translates over to amount of work possible, but I am open to finding out, if anyone could help with that... I suppose I could see how many samples are possible in a second? Wish I could just run TOP, or open Taskmanager...
On the ADC, the core and photon both have 12-bit ADC, with 8 inputs on the core and 9 on the photon. significantly better than the Uno. The measurement range is reduced from 5V to 3.3, but there is still 6x the resolution, and some extra inputs.
The datasheet for the micro used in the Spark Core (https://github.com/spark/core/blob/master/Datasheets/ST_STM32F103CB.pdf (page 75) ) says the total conversion time of the A/D converter is min of 1 µs and max of 18 µs. And sample rate is from 0.05-1Mhz
The one for the photon (https://github.com/spark/photon/blob/master/datasheets/STM32F205RGY6.pdf (page 121) ) says up to 6MSPS. (conversion time 0.5min to 16.4max µs /sample rate is 0.6-30Mhz)
From what I can tell the uno is 125khz, so faster but possibly slower?
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
From what I can tell the uno is 125khz, so faster but possibly slower?
That's a typical clock rate going into the ADC, but each conversion takes 13 clocks, so the actual conversion rate is 125/13 kHZ or 9.6 kHZ, or 104 usecs per conversion. So the ARM based chips do conversions way way faster. Many of them have 2 or 3 ADCs (Vs that AVR's single ADC), so simultaneous conversions are truly possible, subject to whether or not your board gives you access to the multiple ADCs.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Am still waiting for my photon to arrive.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Looks like they had a bad batch of power regulators, hopefully shipping near end of the month. I ordered a core and photon in march and still don't have a photon either.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
It's looking like end Aug before I receive the photon. That's when I get back into this project.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
It works a treat with the Photon. I had things working on a Spark (Particle Core) and was able to do a straight swap for a Photon except for connecting D0 to D3 and 3v3* to Vbatt.
If you are using interrupts to monitor meter flashes or gas meter reed switches then you need to avoid using Photon pin D0 which does not support interrupts.
The phase compensation will not work (at least for the amount of phase shift I have) even at the slowest standard Photon sampling speed so you need to put in a 500 microsecond or so delay in the ADC sampling loop to slow things down a bit.
Finally, both the Spark(Core) and Photon have enough performance spare that you can log the current and voltage waveforms along with the power information. That is quite an eye opener.
The Core and Photon are both capable of uploading data direct to emoncms without other hardware (OK you need a wireless router).
https://community.particle.io/t/open-energy-monitor-port/3166
Gives the history of this project.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
The phase compensation will not work (at least for the amount of phase shift I have)
Somebody here: http://openenergymonitor.org/emon/node/11021 reckons they got it to work on a fast sampling ARM by using a much bigger PHASECAL number (7.5 Vs 1.7). I'm not sure how their sampling speeds compare with yours, and I'm not familiar enough with PHASECAL to compare their approach with your delay() approach, but hopefully others here might have a view.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Thanks dBC It is a relief to know that I'm not alone.
The phase correction code is:
so it is interpolatng between the most recent two voltage measurements. Ideally the two voltage measurements should be sampled on either side of the current (I) measurement in which case PHASECAL should be between 0 and 1. A modest extrapolation is safe but a large one changes the amplitude of the waveform.
Putting a delay between samples avoids the need for a large extrapolation. Without the delay the Photon can make a few hundred measurements per cycle and would need a large extrapolation similar to the one you mention. This would increase the measured V amplitude by about 10%. Not huge and it can be fixed with the calibration but I prefer to add the delay.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Might be worth modifying the title of this thread to include the term Particle as well as Spark Core.
This looks to be a really great solution and if I understand correctly it would allow up to 7 CT clips plus a voltage measurement for what should be much less than emonTX for 4 CT clips or the emonPi for only 2 CT clips.
The one thing that does really concern me with using the Particle as the basis for a replacement for the existing two solutions is stability or lack of history of the company producing the Particle boards.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Might be worth modifying the title of this thread to include the term Particle as well as Spark Core.
Done.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
"a large [extrapolation] changes the amplitude of the waveform"
Not only that, if you have 'flat-topping' (where both positive and negative crests of the sine wave are flattened, as is common where I live), extrapolation significantly changes the shape of the waveform too.
So a much better way (possibly even better than the delay) would be to save voltage samples and pick out the best two to interpolate between.
If you can, it would be worth dropping 1 cycle's worth of values into a spreadsheet, doing the extrapolation and plotting the resulting wave shape. As you don't have a true sinusoid there, you might not like the result!
Be aware that PHASECAL corrects for three things, phase errors in both the vt and ct, and the time error between readings. Changing the order of readings could help (I before V) but also bear in mind that all 3 variables change - the first two with voltage and current respectively, the third with supply frequency (in electrical degrees, not in time!).
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Yes Robert Wall, you are quite right and most perceptive. It would be better to pick the most appropriate pair of V measurements to use for the interpolation and you are also right that the lag between measurements changes due to several variables, mostly unwanted ones and also due to the change in inductive loads that we want to detect so a fixed PHASECAL will never correct perfectly.
I looked at the waveform error with large extrapolation. I'm near enough sinusoidal that it wouldn't significantly change the calculated power factor - I guess because near zero V vs T is close to linear. I still don't like the large extrapolation idea though.
I thought about adapting to variation in the unwanted effects on the fly (since the ARM based processors would have no problem with processing power) but I don't know how much of my load is inductive at any particular time and much of the time my current has such an awful waveform I wouldn't have a clue where to put my origin.
Consequently I have to make do with a fixed adjustment for lag. If I sample at several hundred measurements per cycle I could use
where ph is the whole number part of the phase correction and PHASECAL is the fractional part. It would just need a small buffer to store a few measurements. But is this overkill? At that high a sample rate the fractional part is not very important so phaseShiftedV = filteredV[t-ph]; would be good enough.
The alternative is to space the measurements out. It may be a bit less accurate - i.e. only as good as an Arduino ; ) but I don't think the error is significant compared with the demonstrable variation in V and I lag with power. That is why I settled for the minimal re-coding version with quite a large delay added. You still benefit from I and V being measured close to each other (especially if as you suggest you do it in the right order for your system).
I guess the really sophisticated solution would adjust the sample time to have a constant number of samples per cycle but life is too short and mains frequency stable enough.
Incidentally, the measurement that is most important to me is the exported power as that determines when I can turn on the immersion heater. The current clamp system gives me the import/export sign and I get a completely accurate power figure by meter flash counting. My calibrated current clamp is accurate to a few percent at large loads (imported or exported) but unimpressive at low powers though I use it when the meter flashes are too few and far between. Before I got a curent clamp I used to just use meter flashes and infer import/export by correlating the power changes from the generation and general meters and it was surprisingly reliable, but the current clamp responds more quickly.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Maybe we should design a shield for this chip. It certainly seems like quite a nice device.
There is a company that produces an Arduino like shield for the Particle Photon,
https://www.sparkfun.com/products/13321
So maybe that with the emontx shield is a good starting point. But I notice that the hardware on the shield itself has not be updated with the latest emontx changes. So maybe that is step 1.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I had a spark shield I was working on, but have been sidelined with a major home reno project.
https://github.com/officeboy/EmonCore/tree/master/hardware
Someone could take that and make the few changes for a photon, and get em made up. (don't use the 3.5mm jacks I did, they are terrible!)
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Trying to create a design based on all the improvement suggestions I have spotted.
How is this as a concept for the Photon?
I've used the following bits.
1. Allow the photon to be powered by the same 9V ac adaptor. May have to put this into VBat rather than Vin. Design taken from V3.4
2. Buffer the input voltage bias and use the same for the CTs as well, Design taken from Robin.
3. Protect the inputs. Design taken from dBC.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
"I spotted an error in it"
So have I - in the 9 V transformer dept! But you must do a careful simulation of that half-wave supply, because the component values are critical to ensure correct operation at the current your require at the lowest supply voltage you are likely to encounter, and to verify that the voltage monitor input is not adversely affected by the voltage dip caused by the transformer regulation.
And it will be a lot harder if you want a 5 V d.c. supply - you might have to go to a 12 V transformer to have enough voltage to play with.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Might be best to ditch trying to use the 9V AC for both purposes and switch to using a dual 9V AC transformer and use one part for the AC wave detection and the other part for the 5V regulator via a Bridge rectifier.
Or use the face that the Photon already has the mini USB with a 3.3V regulator. And stick with using the single 9V AC for the volt detection only.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
It says the Photon needs 80 mA - that's well outside the capacity of the half-wave rectifier with the component values you have. I suggest you use a transformer with two 9 V windings, using one with a full-wave rectifier for power, and the second for voltage monitoring. You will still get some interaction in the form of a dip in the voltage wave before and around the peak as the current pulse charges the smoothing capacitor, but in the full wave rectifier it is half the size of the half-wave pulse - but it happens twice as often.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Might as well use the Photons usb connection and regulator. It will keep the component count down of the additional stuff required.
It does however mean that two power sockets get used to get this running. I.e. one for the usb power adapter and one for the 9v ac adapter.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Anyone know why the voltage divider was changed on the AC sense circuit from 10K+100K in the emontx v2 to the 10K+120K in the emontx v3?
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Presumably to give a little more headroom given worst-case tolerances for all the relevant components.
Not that it makes a great deal of difference - the place where you need all the resolution you can get is in the current department. The usual range of the voltage input is the nominal voltage ± 10%. People expect the current to be measured accurately over at least 2 orders of magnitude, and often a lot more (but they are usually disappointed!).
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Trying to put together a circuit which has the best suggestions/improvements. So maybe a 10K+120K is the way to go.
Any other suggestions to get the hardware side as flexible and sorted as possible. The plan was to tie the analogue inputs down to CTs and voltage reading. And expose all the Digital IOs into a terminal block. That way it's the most flexible.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
How is the attached as a starting point?
There is one bit I don't quite understand.
In Buffered Voltage Bias circuit the middle of the 10K+100K junction is fed to the chip as the voltage sense. And the 'mid-point' on the op amp is used for the CT sensors which is also connected to the 10K.
But in his own MK2 router he uses the the middle of the 10K+100K junction and the 'mid-point' on the op amp for the CT sensors. And the 10K is used into the chip for the voltage sense.
Why the difference? and which way is better?
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
"How is the attached as a starting point?"
Something's gone wrong with the current input - you've got the ADC input connected to the bias source and the burden voltage does nothing.
You're missing a few dots where crossing/meeting lines ought to join.
"Why the difference? and which way is better?"
Both present a divided-down voltage to the analogue input. The difference is probably down to either personal preference, the way the ac adapter plug is connected (because the difference is when changing from one to the other, the voltage signal is inverted), or the ease of laying out the pcb.
If you're concerned with the phase of the voltage signal (which could come from compatibility issues), one is right and one is wrong. Otherwise, neither is intrinsically 'better'.
Does the Photon have separate analogue and digital VCC? If it does, you should pay careful attention to that and include some filtering because of potential noise problems. And you must be careful with earthing/grounding too (i.e. keep the analogue grounds separate from the digital as far as possible, and joint them at one place only).
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
How's this revision? I'm trying to keep the hardware design as close to the V3.4 as possible, so will stick to using the middle of the 10K+120K as the input into the ADC.
The Photon doesn't appear to have separate Vcc. Just a single 3.3V output. There are two Grounds but again they are connected on the same Ground plane within the chip. For ease, I will utilise the Left hand for the analogue inputs and the Right hand ground can be reserved for the Digital ones.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
The STM32 processor itself has a separate Vdda pin and the datasheet specifies how to decouple it from Vdd, but that all has to be done right at the pin, so hopefully the Photon designers followed those instructions. It wouldn't make sense to expose that pin all the way out to Photon pins and expect you to do it. Unfortunately, the schematic here: https://docs.particle.io/datasheets/photon-datasheet/#schematic doesn't show you how things are wired inside the P0 module, but either of pins 46 or 47 look like a possible candidate with decoupling on each.
It seems that processor has 3 ADCs each of which can access any of 16 input pins (although only 8 are exposed by your module). If you're prepared to put the coding effort in, you could potentially get some great results with simultaneous conversions on 3 pins at a time. Given that, I wonder if it would be worth devoting one of the 8 ADC input pins to measuring the mid-rail (at the cost of being able to measure one less CT). I'm not sure if anyone has experimented with measuring the DC offset Vs the current method of filtering it away in software. On the AVR based designs that would be very expensive in terms of precious ADC conversions, but you appear to have the horsepower to at least consider it.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
We can always have one analogue input devoted to measuring the mid-rail. My thoughts were 3 full range CTs and 3 high sensitivity CTs, 1 used for the AC measurement, so we still have one spare.
How will I need to wire up the input to don the measurement you are talking about.
Once we get the hardware nailed down we can decide how best to use the available design features within the software.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I think it would be as simple as taking the output of the op-amp and wiring it to A1 (say), and change your CT input section to say "A2-7" instead of "A1-7". You shouldn't need any protection on that input because there are no external forces to take it beyond the rails.
But I'm having trouble reconciling your footprint with the LMV321 datasheet I found here: http://www.ti.com/lit/ds/symlink/lmv321-n.pdf. Is yours 6-pin as shown in your schematic?
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I have taken the LMV321 pinout from the page in the Building blocks section. Haven't checked it with the datasheet, just assumed that it was correct.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I see the issue. I used a 6 pin package in my diagram whereas the LVM321 is a 5 pin part. Will change that.
But my pin numbers are correct, just the package representation is wrong.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I haven't found the part needed that gives me a 5 pin op amp symbol yet, so ignore that.
But I've made the changes to feed the output of the op amp into the ADC A1. Are we sure we don't want to protect this input like we are doing the others.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
"Are we sure we don't want to protect this input like we are doing the others."
Q. What are you protecting against?
A. The input voltage going beyond the power rails, i.e. less than 0 V or greater than 3.3 V.
Q. (To you) How can it do that when it is the midpoint of those two rails?
dBC: In Robin's Mk2 diverter, he uses the op.amp buffer and the low pass filter on one input only to extract the offset, then subtracts the same offset from that and the remaining 2 inputs, the objective being to economise on processor cycles. If Bruce wants, he can do the same (and keep all 8 ADC inputs available) or he can take your suggestion and simply subtract that channel from each of the others to remove the offset. But a caveat: if different ADCs are used for different channels, a small offset may remain due to errors within the ADCs. The Atmel processor has only one ADC, so any differences between channels is down to the multiplexer only.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I officeboy, i invite you to take a look at this lib : http://openenergymonitor.org/emon/node/2406
In particular read this app note for general energy metering information: http://www.atmel.com/Images/Atmel-2566-Single-Phase-Power-Energy-Meter-w...
A reliable solution is lacking for 3 phase metering. With this hardware capabilities i thing you should focus on it.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I'm trying to nail down the hardware side as much as possible using all the best suggestions. Once that is done and I have a sample batch of boards ready, I can distribute those, at cost, to anyone who wants one. Then collectively we can work on using the capability of a web connected microprocessor.
So if there is anything in the hardware design that is lacking for 3 phase metering then shout and I'll add it in.
My thoughts behind the 3 high range inputs and 3 high sensitivity inputs was to cater for a 3 phase implementation too. But always open to suggestions.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
If you want to do accurate 3-phase metering, then 3 voltage inputs are essential. One voltage input can only be accurate for that phase, everything else is an assumption based on the phases being balanced.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
So maybe 3 phase accuracy is a dream. Because no one is going to have 3 ac adapters plugged into this. Having a 5v usb and a 9v ac block is seen as excessive enough.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
So any other suggestions? To improve on the hardware and utilise what we have on offer within the Photon.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
How many milliamps will that 9V input/regulator be able to provide before the AC wave is too distorted?
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
If you want to do accurate 3-phase metering, then 3 voltage inputs are essential.
I'll second that. In some spot checks I've done in Aus and NZ, it's common to see more than 10V difference between the phases, and which phase is hottest varies throughout the day so you can't calibrate it away.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
"How many milliamps will that 9V input/regulator be able to provide before the AC wave is too distorted? "
I have no idea. It depends on what you mean by "too distorted" and of course on the parameters of the adapter/transformer that you're using. If I remember correctly, I decided that about ½% reduction in the rms voltage due to the dip was the limit of acceptability. You might think that's excessively cautious, but I based it on claims by some users that with care, they had calibrated their emonTx to read within 1% of their supplier's tariff meter. Probably the only realistic way to determine what you can get away with is to measure the transformer, then build an accurate Spice model of the transformer, rectifier, smoothing and regulator, and then apply varying loads and keep checking the distortion.
There's a picture of what happens in this thread: http://openenergymonitor.org/emon/node/10715#comment-30427
I actually designed the circuit from the other direction: The required current was defined, so I chose the components (for the emonTx V3.2) to give the minimum dip whilst still able to just operate at minimum supply voltage.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
Are we still trying to get this powered and voltage measured using the 9V supply. I thought we felt the power required by the Photon and all the other associated components was pushing that too far. Hence sticking with using the 5V usb and a 9v ac separate.
Re: EmonCore - All in one project based on the Particle (fomerly Spark) Core
I think I'll start a new thread to let people comment on the design, not least because it's using the Photon instead of the Core.


In 2007 Ken Levine and his creative team at Irrational Games (known at the time as 2K Boston) launched BioShock, a first-person shooter that challenged the perception of what the genre was capable of. BioShock set a new standard for interactive story-telling, moving away from conventional cut-scenes so heavily relied upon by its contemporaries, and offered a dynamic approach to combat with a heady mix of gun-play and extraordinary powers.
Set in 1960, BioShock told the story of Rapture, an underwater city built upon the vision of Andrew Ryan. Rapture was intended as a place of opportunity and moral objectivism; predicated on the notion that a brilliant mind should not be fettered by morality or public conscience and that the talent of the individual should not be taxed for the benefit of the feckless.
Unshackled from conventional restrictions, Rapture’s scientists unlocked the secrets of DNA-splicing tonics, which the population soon became dangerously obsessed with. The decline of Rapture was charted by the very environments of BioShock’s world and the vivid ruins of its Art Deco architecture. Former citizens turned half-mad Splicers stalked Rapture’s halls, while the disquieting relationship between the Big Daddies and Little Sisters characterised the city’s former perverse glory.
BioShock’s commentary on Objectivist philosophy, moral choice and video game design was brilliantly realised by one of the medium’s most memorable reveals and three little words: “Would you kindly?”. As the player grappled with the shattered assumptions of their position in the game and the protagonist’s role in the Rapture experiment, the pieces fell into place to culminate in a chilling scene played out in Andrew Ryan’s office.
BioShock’s early critical acclaim was later solidified by numerous awards for its visual and audio design, along with its writing and story direction. It won numerous Game of the Year awards, both from fan sites and the specialist press, as well as the 2007 BAFTA for Best Game.
In 2010 2K Marin launched BioShock 2. The developer had previously worked on the PlayStation 3 port of the original BioShock and picked up the story of Rapture some eight years after the death of Andrew Ryan. The narrative was one of conflict and conscience as Subject Delta, a deactivated Big Daddy, struggled to understand his place in the devastated Rapture. BioShock 2 continued the original title’s exploration of moral choices but this time the player’s decisions directly affected the emotional development of one Eleanor Lamb: Delta’s former ward, matured Little Sister and daughter of despot antagonist, Sofia Lamb. A commercial success in its own right, the worldwide combined sales of BioShock and BioShock 2 have exceeded 7m units.
Now, Levine and Irrational Games are set to return to the BioShock universe with the launch of BioShock Infinite. Bringing with it Levine’s award-winning writing talent and the team’s proven track-record for engaging design, BioShock Infinite exceeds the scope and ambition of Rapture’s underwater dystopia with the introduction of the sky-bound, floating city of Columbia.
As former-Pinkerton agent Booker DeWitt, players will travel to Columbia to retrieve the mysterious Elizabeth, an AI companion capable of creating tears in the very fabric of space and time. Together, DeWitt and Elizabeth will become embroiled in the machinations of one of Columbia’s founding fathers: the religious zealot, Zachery Comstock. BioShock Infinite further refines the original game’s imaginative mechanics, offering the ability to dual-wield firearms and diverse, adaptable powers known as Vigors, while Columbia’s Sky-Lines introduce high-speed traversal and intense aerial combat. BioShock Infinite aims to exceed the impact made by its 2007 forebear and is expected to be quite unlike anything that has gone before it.


| A woman who studies butterflies and moths tests the limits of her relationship with her lover. | |
| Genres: | Drama, Mystery, Romance |
| Director: | Peter Strickland |
| Writer: | Peter Strickland |
Cast: | Evelyn - Chiara D'Anna Dr. Lurida - Kata Bartsch Cynthia - Sidse Babett Knudsen Lorna - Monica Swinn Dr. Schuller - Zita Kraszkó Dr. in Audience - Gretchen Meddaugh Dr. Viridana - Eszter Tompa The Carpenter - Fatma Mohamed Dr. Fraxini / The Scream - Eugenia Caruso |


Dear Erlen,
My
name
is
and
my
email address
is
I have a
message
for you,
send
Vist
erlen.co.uk
to see my work


This 3rd party module provides support for the FastCGI protocol. FastCGI is a language independent, scalable, open extension to CGI that provides high performance and persistence without the limitations of server specific APIs.
FastCGI applications are not limited to a particular development language (the protocol is open). FastCGI application libraries currently exist for Perl, C/C++, Java, Python, TCL, SmallEiffel, and Smalltalk.
FastCGI applications use TCP or Unix sockets to communicate with the web server. This scalable architecture allows applications to run on the same platform as the web server or on many machines scattered across an enterprise network.
FastCGI applications are portable to other web server platforms. FastCGI is supported either directly or through commercial extensions by most popular web servers.
FastCGI applications are fast because they're persistent. There is no per-request startup and initialization overhead. This makes possible the development of applications which would otherwise be impractical within the CGI paradigm (e.g. a huge Perl script, or an application which requires a connection to one or more databases).
See the FastCGI website for more information. To receive FastCGI
related announcements and notifications of software updates, subscribe to fastcgi-announce. To participate in the discussion of
mod_fastcgi
and FastCGI application development, subscribe to fastcgi-developers.
For information about building and installing the module, see the INSTALL document that came with the distribution.
FastCGI applications under mod_fastcgi
are defined as one of three types: static, dynamic, or
external. They're configured using the FastCgiServer, FastCgiConfig, and FastCgiExternalServer directives respectively. Any URI that Apache identifies as a FastCGI application and
which hasn't been explicitly configured using a FastCgiServer or FastCgiExternalServer directive is handled as a dynamic application (see the
FastCgiConfig directive for more information).
FastCGI static and dynamic applications are spawned and managed by the FastCGI Process Manager, fcgi-pm. The process manager is spawned by Apache at server initialization. External applications are presumed to be started and managed independently.
Apache must be configured to identify requests for FastCGI URIs. mod_fastcgi
registers (with
Apache) a handler type of fastcgi-script
for this purpose.
To configure Apache to handle all files (within the scope of the directive) as FastCGI applications (e.g. for a fcgi-bin directory):
SetHandler fastcgi-script
To configure Apache to handle files (within the scope of the directive) with the specified extension(s) as FastCGI applications:
AddHandler fastcgi-script fcg fcgi fpl
Consult the Apache documentation for more information regarding these and other directives which affect
request handling (such as Action).
Dynamic FastCGI applications require the ExecCGI
option be enabled (see the Options
directive) in the
application's directory.
mod_fastcgi
logs FastCGI application error (stderr) output to the server log associated with
the request. Errors reported by the FastCGI process manager, fcgi-pm, are reported to the main server log
(typically, logs/error_log). Data written to stdout or stderr before entering the FastCGI accept
loop or via a mechanism that is not FastCGI protocol aware will also be directed to the main server log. If
Apache's LogLevel
is set
to info
additional informational messages are printed to the logs, these messages may be
especially helpful while debugging a configuration.
Under Unix, expect your FastCGI application to see SIGPIPE, SIGUSR1, and SIGTERM. The latest FastCGI C, C++ and Perl application library installs default handlers if none are installed by the application. If an http client aborts a request before it completes, mod_fastcgi does too - this results in a SIGPIPE to the FastCGI application. At a minimum, SIGPIPE should be ignored (applications spawned by mod_fastcgi have this setup automatically). Ideally, it should result in an early abort of the request handling within your application and a return to the top of the FastCGI accept() loop. Apache uses SIGUSR1 to request a "graceful" process restart/shutdown. It is sent to Apache's process group (which includes applications spawned by mod_fastcgi). Ideally, it should result in a FastCGI application finishing the current request, if any, and then an exit. The mod_fastcgi process manager isn't particularly patient though (there's room for improvement here) and since it has to shutdown too, sends a SIGTERM to all of the FastCGI applications it is responsible for. Apache will restart the process manager and it will restart its managed applications (as if the server was just started). SIGTERM is, well, SIGTERM - your application should exit quickly.
Under Windows, there are no signals. A shutdown event is used instead. This is setup by mod_fastcgi and honored by the latest version of the C, C++, and Perl application library. If your using a library which doesn't support this, your application will not get shutdown during an Apache restart/shutdown (there's room for improvement here).
To pass per-request environment variables to FastCGI applications, have a look at: mod_env
(SetEnv
,
PassEnv
, UnSetEnv
), mod_setenvif
(BrowserMatch
, BrowserMatchNoCase
, SetEnvIf
,
SetEnvIfNoCase
), and mod_rewrite
(if you're feeling
adventurous).
FastCGI application output is buffered by default. This is not the case for CGI scripts (under Apache 1.3).
To override the default behavior, use the -flush
option (not available for dynamic
applications).
Redirects are handled similarly to CGI. Location headers with values that begin with "/" are treated as internal-redirects; otherwise, they are treated as external redirects (302).
Session affinity (as well as distribution) should be achievable outside of mod_fastcgi
using
mod_rewrite
. If you get this
working, please post the details to<EMAIL_ADDRESS>so they can be included here.
The FastCGI specification is not implemented in its entirety and I've deviated a bit as well resulting in some Apache specific features.
The file descriptors for stdout and stderr are left open. This is prohibited by the specification. I can't see any reason to require that they be closed, and leaving them open prevents FastCGI applications which were not completely ported to FastCGI from failing miserably. This does not mean the applications shouldn't be fixed such that this doesn't occur, but is invaluable when using a 3rd party library (without source code) which expects to be able to write to stderr. Anything written to stdout or stderr in this manner will be directed to the main server log.
The Filter and Log Roles are not supported. The Filter Role has little value in Apache until the output of one handler can be piped into another (Apache 2.0 is expected to support this). The Log Role has some value, but Apache's "piped logs" feature is similar (and is even more CPU friendly).
The FastCGI protocol supports a feature, described in the specificiation as "multiplexing", that allows a single client-server connection to be simultaneously shared by multiple requests. This is not supported. This does *not* prevent FastCGI applications from supporting multiple simultaneous requests over independent connections. Of course, the application has to be specifically designed to do so by using a threaded or select/poll based server model.
The Authorizer Role has three variations corresponding to three specific Apache request handling
phases: Authentication, Authorization, and Access Control. mod_fastcgi
sets up the
(Apache specific) environment variable "FCGI_APACHE_ROLE" to indicate which Apache authorizer
phase is being performed.
Authorizers under mod_fastcgi
are sent nearly all of the standard environment variables
typically available to CGI/FastCGI request handlers including some explicitly precluded by the FastCGI
specification (for authorizers); I didn't see the point in leaving them out. All headers returned by a
FastCGI Authorizer in a successful response (Status: 200) are passed to sub-processes (CGI/FastCGI
invocations) as environment variables rather than just those prefixed by Variable-
as the
FastCGI specification calls for; I didn't see the point in leaving them out either. FastCGI
specification compliant authorizer behavior can be obtained by using the -compat
option to the
Auth server directives.
Custom failure responses from FastCGI authorizer applications are not supported (speak up if you need this). See the ErrorDocument directive for a workaround (a CGI/FastCGI application can serve the error document).
FastCgiServer
FastCgiConfig
FastCgiExternalServer
FastCgiIpcDir
FastCgiWrapper
FastCgiAuthenticator
FastCgiAuthenticatorAuthoritative
FastCgiAuthorizer
FastCgiAuthorizerAuthoritative
FastCgiAccessChecker
FastCgiAccessCheckerAuthoritative
| Syntax: |
FastCgiServer filename [option ...]
|
| Context: | server config, virtual host |
The FastCgiServer
directive defines filename as a static FastCGI application. If the
filename does not begin with a slash (/) then it is assumed to be relative to the ServerRoot.
By default, the Process Manager will start one instance of the application with the default configuration
specified (in parentheses) below. Should a static application instance die for any reason
mod_fastcgi
will spawn another to replace it and log the event (at the warn
LogLevel
).
Note: Using FastCgiServer
within a
VirtualHost
does not necessarily limited access to that host. If filename is
accessible via other virtual hosts, they too can leverage the same definition.
Option can be one of (case insensitive):
-appConnTimeout n (0 seconds)
connect()
should be used. Blocking
connect()
s have an OS dependent internal timeout.
If the timeout expires, a
SERVER_ERROR results. For non-zero values, this is the amount of time used in a select()
to write to the file descriptor returned by a non-blocking connect().
Non-blocking
connect()
s are troublesome on many platforms. See also -idle-timeout
, it
produces similar results but in a more portable manner.-port
option and dynamic applications) use
this value successfully to limit the amount of time to wait for a connection (i.e. it's not
"troublesome"). By default, this is 90 seconds (FCGI_NAMED_PIPE_CONNECT_TIMEOUT in
mod_fastcgi.h).
-group groupname|#gid (none)
-group
option must be used together with
-user
.
-idle-timeout n (30 seconds)
error
LogLevel
). The inactivity timer
applies only as long as a connection is pending with the FastCGI application. If a request is queued to
an application, but the application doesn't respond (by writing and flushing) within this period,
the request will be aborted. If communication is complete with the application but incomplete with the
client (the response is buffered), the timeout does not apply.
-initial-env name[=[value]] (none)
-init-start-delay n (1 second)
-flush (none)
mod_fastcgi
buffers data in order to free the application as quickly as possible.
-listen-queue-depth n (100)
listen()
queue (also known as the backlog) shared by all of the instances of
this application. A deeper listen queue allows the server to cope with transient load fluctuations
without rejecting requests; it does not increase throughput. Adding additional application instances
may increase throughput/performance, depending upon the application and the host.
-min-server-life n (30)
-nph
-pass-header header (none)
-port n (none)
-socket
and -port
options are mutually exclusive.
-priority n (0)
setpriority()
).
-processes n (1)
-restart-delay n (5 seconds)
-socket filename (generated)
FastCgiIpcDir
. This option makes the application accessible
to other applications (e.g. cgi-fcgi
) on the same machine or via an external FastCGI
application definition (FastCgiExternalServer
). If
neither the -socket
nor the -port
options are given, the module generates a
Unix domain socket filename. The -socket
and -port
options are mutually
exclusive.
FastCgiIpcDir
. This option makes the application
accessible to other applications (e.g. cgi-fcgi
) on the same machine or via an external
FastCGI application definition (FastCgiExternalServer
). If neither the -socket
nor the
-port
options are given, the module generates a name for the named pipe. The
-socket
and -port
options are mutually exclusive.
-user username|#uid (none)
-user
option must be used together with
-group
.
| Syntax: |
FastCgiConfig option [option ...]
|
| Context: | server config |
The FastCgiConfig
directive defines the default parameters for all dynamic FastCGI
applications. This directive does not affect static or external applications in any way.
Dynamic applications are not started at server initialization, but upon demand. If the demand is heavy, additional application instances are started.  Many of the options govern this process.
Option can be one of (case insensitive):
-appConnTimeout n (0 seconds)
connect()
should be used. Blocking
connect()
s have an OS dependent internal timeout. If the timeout expires, a SERVER_ERROR
results. For non-zero values, this is the amount of time used in a select()
to write to
the file descriptor returned by a non-blocking connect()
. Non-blocking
connect()
s are troublesome on many platforms. See also -idle-timeout
, it
produces similar results but in a more portable manner.-port
option and dynamic applications) use
this value successfully to limit the amount of time to wait for a connection (i.e. it's not
"troublesome"). By default, this is 90 seconds (FCGI_NAMED_PIPE_CONNECT_TIMEOUT in
mod_fastcgi.h).
-autoUpdate (none)
-restart
.
-flush (none)
mod_fastcgi
buffers data in order to free the application as quickly as possible.
-gainValue n (0.5)
1 - gainValue
), so making it smaller weights old values more than
the current value (which is scaled by gainValue
).
-idle-timeout n (30 seconds)
error
LogLevel
). The inactivity timer
applies only as long as a connection is pending with the FastCGI application. If a request is queued to
an application, but the application doesn't respond (by writing and flushing) within this period,
the request will be aborted. If communication is complete with the application but incomplete with the
client (the response is buffered), the timeout does not apply.
-initial-env name[=[value]] (none)
-init-start-delay n (1 second)
-killInterval n (300 seconds)
-listen-queue-depth n (100)
listen()
queue (also known as the backlog) shared by all instances of
applications. A deeper listen queue allows the server to cope with transient load fluctuations without
rejecting requests; it does not increase throughput. Adding additional application instances may
increase throughput/performance, depending upon the application and the host.
-maxClassProcesses n (10)
-maxProcesses n (50)
-min-server-life n (30)
-minProcesses n (5)
-multiThreshold n (50)
singleThreshold
is used instead.multiThreshhold
is also accepted.
-pass-header header (none)
-priority n (0)
setpriority()
).
-processSlack n (5)
processSlack
exceeds maxProcesses
, the process manager invokes the killing
policy. This is to improve performance at higher loads by killing some of the most inactive application
instances before reaching maxProcesses
.
-restart (none)
-restart-delay n (5 seconds)
-singleThreshold n (0)
-appConnTimeout
is set).singleThreshhold
is also accepted.
-startDelay n (3 seconds)
startDelay
must be less than appConnTimeout
to be effective.
-updateInterval n (300 seconds)
| Syntax: |
FastCgiExternalServer filename -host hostname:port [option ...]
|
FastCgiExternalServer filename -socket filename [option ...]
|
|
| Context: | server config, virtual host |
The FastCgiExternalServer
directive defines filename as an external FastCGI
application. If filename does not begin with a slash (/) then it is assumed to be relative to the
ServerRoot. The filename does
not have to exist in the local filesystem. URIs that Apache resolves to this filename will be
handled by this external FastCGI application.
External FastCGI applications are not started by the process manager, they are presumed to be started and
managed "external" to Apache and mod_fastcgi. The FastCGI devkit provides a simple tool,
cgi-fcgi
, for starting FastCGI applications independent of the server (applications can also
be self-starting, see the devkit).
Note: Using FastCgiServer
within a
VirtualHost
does not necessarily limited access to that host. If filename is
accessible via other virtual hosts, they too can leverage the same definition.
Option can be one of (case insensitive):
-appConnTimeout n (0 seconds)
connect()
should be used. Blocking
connect()
s have an OS dependent internal timeout. If the timeout expires, a SERVER_ERROR
results. For non-zero values, this is the amount of time used in a select()
to write to
the file descriptor returned by a non-blocking connect()
. Non-blocking
connect()
s are troublesome on many platforms. See also -idle-timeout
, it
produces similar results but in a more portable manner.-port
option and dynamic applications) use
this value successfully to limit the amount of time to wait for a connection (i.e. it's not
"troublesome"). By default, this is 90 seconds (FCGI_NAMED_PIPE_CONNECT_TIMEOUT in
mod_fastcgi.h).
-group groupname|#gid (none)
-group
option must be used together with
-user
.
-idle-timeout n (30 seconds)
error
LogLevel
). The inactivity timer
applies only as long as a connection is pending with the FastCGI application. If a request is queued to
an application, but the application doesn't respond (by writing and flushing) within this period,
the request will be aborted. If communication is complete with the application but incomplete with the
client (the response is buffered), the timeout does not apply.
-flush (none)
mod_fastcgi
buffers data in order to free the application as quickly as possible.
-host hostname:port (none)
-socket
and -host
options are mutually exclusive.
-nph
-pass-header header (none)
-socket filename (none)
FastCgiIpcDir
. The -socket
and -port
options are
mutually exclusive.
FastCgiIpcDir
. The -socket
and -port
options are
mutually exclusive.
-user username|#uid (none)
-user
option must be used together with
-group
.
| Syntax: |
Unix: FastCgiIpcDir directory
|
Windows NT: FastCgiIpcDir name
|
|
| Default: |
Unix/Apache: FastCgiIpcDir logs/fastcgi
|
Unix/Apache2: FastCgiIpcDir RUNTIMEDIR/fastcgi
|
|
Windows NT: FastCgiIpcDir \\\\.\\pipe\\ModFastCgi\\
|
|
| Context: | server config |
Unix: The FastCgiIpcDir
directive specifies directory as the
place to store (and in the case of external FastCGI applications, find) the Unix socket files used for
communication between the applications and the web server. If the directory does not begin with a slash (/)
then it is assumed to be relative to the ServerRoot. If the directory doesn't exist,
an attempt is made to create it with appropriate permissions. Do not specify a directory that is not on a
local filesystem! If you use the default directory (or another directory within /tmp
),
mod_fastcgi
will break if your system periodically deletes files from /tmp
.
Windows NT: The FastCgiIpcDir
directive specifies name as the
root for the named pipes used for communication between the application and the web server. The
name must be in the form of \\\\.\\pipe\\pipename (notice that the
backslashes are escaped). The pipename can contain any character other than a backslash.
The FastCgiIpcDir
directive must precede any FastCgiServer
or FastCgiExternalServer
directives (which make use of Unix
sockets). The directory must be readable, writeable, and executable (searchable) by the web server, but
otherwise should not be accessible to anyone.
FastCgiIpcDir
is typically used move the directory someplace more suitable (than the default)
for the platform or to prevent multiple Apache instances from sharing FastCGI application instances.
| Syntax: |
FastCgiWrapper On | Off | filename
|
| Default: |
FastCgiWrapper Off
|
| Context: | server config |
Unix (only): The FastCgiWrapper
directive is used to enable support for a
wrapper such as suexec (included with Apache in the
support directory) or cgiwrap. To use the same wrapper used
by Apache, set FastCgiWrapper
to On (NOTE - mod_fastcgi cannot reliably determine the
wrapper used by Apache when built as a DSO). The On argument requires suexec be enabled in Apache
(for CGI). To use a specific wrapper, specify a filename. If the filename does not begin with a
slash (/) then it is assumed to be relative to the ServerRoot. The wrapper is used to invoke all
FastCGI applications (in the future this directive will have directory context).
When FastCgiWrapper
is enabled, no assumptions are made about the target application and thus
presence and permissions checks cannot be made. This is the responsibility of the wrapper.
The wrapper is invoked with the following arguments: username, group, application. The username and group are determined as described below. The application is the "filename" Apache resolves the requested URI to (dynamic) or the filename provided as an argument to another FastCGI (server or authorizer) directive. These arguments may or may not be used by the wrapper (e.g. suexec uses them, cgiwrap parses the URI and ignores them). The environment passed to the wrapper is identical to the environment passed when a wrapper is not in use.
When FastCgiWrapper
is enabled, the location of static or external FastCGI application
directives can be important. Under Apache 1.3, they inherit their user and group from the user and
group
of the virtual server in which they are defined. User
and Group
directives must precede
FastCGI application definitions. Under Apache 2.0, the -user
and -group
options
to FastCgiServer and FastCgiExternalServer directives must be used (dynamic applications still use
the virtual server's user and group).
Note that access to (use of) FastCGI applications is not limited to the virtual server in which they were defined. The application is used to service requests from any virtual server with the same user and group.
If a request is received for a FastCGI application without an existing matching definition already running with the correct user and group, a dynamic instance of the application is started with the correct user and group. This can lead to multiple copies of the same application running with different user/group. If this is a problem, preclude navigation to the application from other virtual servers or configure the virtual servers with the same User and Group.
See the Apache documentation for more information about suexec (make sure you fully understand the security implications).
| Syntax: |
FastCgiAuthenticator filename [-compat]
|
| Context: | directory |
The FastCgiAuthenticator
directive is used to define a FastCGI application as a per-directory
authenticator. Authenticators verify the requestor is who he says he is by matching the provided username
and password against a list or database of known users and passwords. FastCGI based authenticators are
useful primarily when the user database is maintained within an existing independent program or resides on
a machine other than the web server.
If the FastCGI application filename does not have a corresponding static or external server definition, it is started as a dynamic FastCGI application. If the filename does not begin with a slash (/) then it is assumed to be relative to the ServerRoot.
FastCgiAuthenticator
is used within Directory
or Location
containers and must include
an AuthType
and AuthName
directive. Only the
Basic
user authentication type is supported. It must be accompanied by a require
or FastCgiAuthorizer
directive in order to work correctly.
<Directory htdocs/protected> AuthType Basic AuthName ProtectedRealm FastCgiAuthenticator fcgi-bin/authenticator require valid-user </Directory>
mod_fastcgi
sends nearly all of the standard environment variables typically available to
CGI/FastCGI request handlers. All headers returned by a FastCGI authentication application in a successful
response (Status: 200) are passed to sub-processes (CGI/FastCGI invocations) as environment variables. All
headers returned in an unsuccessful response are passed on to the client. FastCGI specification compliant
behavior can be obtained by using the -compat
option.
mod_fastcgi
sets the environment variable "FCGI_APACHE_ROLE" to
"AUTHENTICATOR" to indicate which (Apache specific) authorizer phase is being performed.
Custom failure responses from FastCGI authorizer applications are not (yet?) supported. See the ErrorDocument directive for a workaround (a FastCGI application can serve the document).
| Syntax: |
FastCgiAuthenticatorAuthoritative On | Off
|
| Default: |
FastCgiAuthenticatorAuthoritative On
|
| Context: | directory |
Setting the FastCgiAuthenticatorAuthoritative
directive explicitly to Off allows
authentication to be passed on to lower level modules (as defined in the Configuration
and
modules.c
files) if the FastCGI application fails to authenticate the user.
A common use for this is in conjunction with a well protected AuthUserFile
containing a
few (administration related) users.
By default, control is not passed on and an unknown user will result in an Authorization Required reply. Disabling the default should be carefully considered.
| Syntax: |
FastCgiAuthorizer filename [-compat]
|
| Context: | directory |
The FastCgiAuthorizer
directive is used to define a FastCGI application as a per-directory
authorizer. Authorizers validate whether an authenticated requestor is allowed access to the requested
resource. FastCGI based authorizers are useful primarily when there is a dynamic component to the
authorization decision such as a time of day or whether or not the user has paid his bills.
If the FastCGI application filename does not have a corresponding static or external server definition, it is started as a dynamic FastCGI application. If the filename does not begin with a slash (/) then it is assumed to be relative to the ServerRoot.
FastCgiAuthorizer
is used within Directory
or Location
containers and must include
an AuthType
and AuthName
directive. It must be
accompanied by an authentication directive such as FastCgiAuthenticator
, AuthUserFile
, AuthDBUserFile
or AuthDBMUserFile
in order to work correctly.
<Directory htdocs/protected> AuthType Basic AuthName ProtectedRealm AuthDBMUserFile conf/authentication-database FastCgiAuthorizer fcgi-bin/authorizer </Directory>
mod_fastcgi
sends nearly all of the standard environment variables typically available to
CGI/FastCGI request handlers. All headers returned by a FastCGI authorizer application in a successful
response (Status: 200) are passed to sub-processes (CGI/FastCGI invocations) as environment variables. All
headers returned in an unsuccessful response are passed on to the client. FastCGI specification compliant
behavior can be obtained by using the -compat
option.
mod_fastcgi
sets the environment variable "FCGI_APACHE_ROLE" to
"AUTHORIZER" to indicate which (Apache specific) authorizer phase is being performed.
Custom failure responses from FastCGI authorizer applications are not (yet?) supported. See the ErrorDocument directive for a workaround (a FastCGI application can serve the document).
| Syntax: |
FastCgiAuthorizerAuthoritative On | Off
|
| Default: |
FastCgiAuthorizerAuthoritative On
|
| Context: | directory |
Setting the FastCgiAuthorizerAuthoritative
directive explicitly to Off allows
authorization to be passed on to lower level modules (as defined in the Configuration
and
modules.c
files) if the FastCGI application fails to authorize the user.
By default, control is not passed on and an unauthorized user will result in an Authorization Required reply. Disabling the default should be carefully considered.
| Syntax: |
FastCgiAccessChecker filename [-compat]
|
| Context: | directory |
The FastCgiAccessChecker
(suggestions for a better name are welcome) directive is used to
define a FastCGI application as a per-directory access validator. The Apache Access phase precede user
authentication and thus the decision to (dis)allow access to the requested resource is based on the HTTP
headers submitted with the request. FastCGI based authorizers are useful primarily when there is a dynamic
component to the access validation decision such as a time of day or whether or not a domain has paid his
bills.
If the FastCGI application filename does not have a corresponding static or external server definition, it is started as a dynamic FastCGI application. If the filename does not begin with a slash (/) then it is assumed to be relative to the ServerRoot.
FastCgiAccessChecker
is used within Directory
or Location
containers.
<Directory htdocs/protected> FastCgiAccessChecker fcgi-bin/access-checker </Directory>
mod_fastcgi
sends nearly all of the standard environment variables typically available to
CGI/FastCGI request handlers. All headers returned by a FastCGI access-checker application in a successful
response (Status: 200) are passed to sub-processes (CGI/FastCGI invocations) as environment variables. All
headers returned in an unsuccessful response are passed on to the client. FastCGI specification compliant
behavior can be obtained by using the -compat
option.
mod_fastcgi
sets the environment variable "FCGI_APACHE_ROLE" to
"ACCESS_CHECKER" to indicate which (Apache specific) authorizer phase is being performed.
Custom failure responses from FastCGI authorizer applications are not (yet?) supported. See the ErrorDocument directive for a workaround (a FastCGI application can serve the document).
| Syntax: |
FastCgiAccessCheckerAuthoritative On | Off
|
| Default: |
FastCgiAccessCheckerAuthoritative On
|
| Context: | directory |
Setting the FastCgiAccessCheckerAuthoritative
directive explicitly to Off allows
access checking to be passed on to lower level modules (as defined in the Configuration
and
modules.c
files) if the FastCGI application fails to allow access.
By default, control is not passed on and a failed access check will result in a Forbidden reply. Disabling the default should be carefully considered.


new Connection
The Cassandra Connection
Parameters:
| Name | Type | Description |
|---|---|---|
options |
Object | The options for the connection defaults to: { port: 9160, host: 'localhost' user: null, password: null, keyspace: null, timeout: 1000 } |
- Source:
- connection.js, line 147
Members
-
_client
-
Thrift Client
- Source:
- connection.js, line 235
-
_connection
-
Thrift Connection
- Source:
- connection.js, line 218
-
cqlVersion
-
The CQL version. - Cassandra 1.0 supports CQL 2.0.0 - Cassandra 1.1 supports CQL 2.0.0 and 3.0.0 (with 2.0.0 the default) - Cassandra 1.2 will have CQL 3.0.0 as the default Cassandra will support choosing the CQL version for a while,
- Source:
- connection.js, line 197
- See:
-
- https://issues.apache.org/jira/browse/CASSANDRA-3990
-
host
-
The host to connect to
- Default Value:
- localhost
- Source:
- connection.js, line 164
-
keyspace
-
The keyspace to authenticate to
- Source:
- connection.js, line 185
-
password
-
The password to connect with
- Source:
- connection.js, line 180
-
port
-
The port to connect to
- Default Value:
- 9160
- Source:
- connection.js, line 158
-
ready
-
Ready state of the client
- Source:
- connection.js, line 202
-
timeout
-
The timeout for the connection
- Default Value:
- 3000
- Source:
- connection.js, line 170
-
user
-
The username to authenticate with
- Source:
- connection.js, line 175
-
<private, static, constant> DEFAULT_HOST
-
Default host
- Source:
- connection.js, line 32
-
<private, static, constant> DEFAULT_PORT
-
Default port for cassandra
- Source:
- connection.js, line 24
-
<private, static, constant> DEFAULT_TIMEOUT
-
Default Timeout
- Source:
- connection.js, line 40
-
<private, static, constant> NOOP
-
A No-Operation function for default callbacks
- Source:
- connection.js, line 16
Methods
-
authenticate
-
Authenticates the user
- Source:
- connection.js, line 337
-
close
-
Closes the connection to the server
- Source:
- connection.js, line 536
-
connect
-
Connects to the cassandra cluster
- Source:
- connection.js, line 209
-
cql
-
Executes a CQL Query Against the DB.
Parameters:
Name Type Description cmd
String A string representation of the query: 'select %s, %s from MyCf where key=%s' args0...argsN
Array An Array of arguments for the string ['arg0', 'arg1', 'arg2'] options
Object An object with options for the query, { gzip:true } callback
Function The callback function for the results - Source:
- connection.js, line 396
-
createKeyspace
-
Creates a keyspace
Parameters:
Name Type Description keyspace
String The name of the keyspace to create options
Object Keyspace options callback
Function The callback to invoke once complete - Source:
- connection.js, line 469
-
dropKeyspace
-
Drops a keyspace
Parameters:
Name Type Description name
String The keyspace name - Source:
- connection.js, line 515
-
execute
-
Executes a command via the thrift connection
Parameters:
Name Type Description command
String The command to execute additional params are supplied to the command to be executed - Source:
- connection.js, line 362
-
use
-
Sets the current keyspace
Parameters:
Name Type Description keyspace
String The keyspace to use - Source:
- connection.js, line 312
-
<private, static> createError
-
Creates a JS Error from a Cassndra Error
Parameters:
Name Type Description err
Object The cassandra error eg: { name:'Exception', why:'Some Reason' } - Source:
- connection.js, line 48
-
<private, static> escapeCQL
-
Escapes CQL, adapted from node-mysql
Parameters:
Name Type Description val
String The value to be escaped - Source:
- connection.js, line 95
Returns:
The sanitized string- Type
- String
-
<private, static> formatCQL
-
Formats CQL properly, paradigm borrowed from node-mysql: https://github.com/felixge/node-mysql/blob/master/lib/client.js#L145-199
Parameters:
Name Type Description str
String - Source:
- connection.js, line 65
Returns:
The formatted CQL statement- Type
- String


This app let's you scrap content from www.zalando.de. Please enter a category path/name.
{{ form_error }}


--- layout: cards page_title: All Posts description: 404? You might find what you were looking for below. --- See all posts below or try Experience, Projects, Blog, About, or Contact pages {% include social.html %}


--- layout: post title: '30 Days in April: Day 22' date: 2009-04-22 23:22:31.000000000 -07:00 type: post published: true status: publish categories: - 30 Days in April tags: - 30 days - conceptual art - units of measurement meta: _publicize_pending: '1' _edit_last: '6192' aktt_tweeted: '1' original_post_id: '254' _wp_old_slug: '254' author: login: falsefridays email<EMAIL_ADDRESS>display_name: Jim Withington first_name: '' last_name: '' ---
Foot (2009)
Ask five friends to measure their feet.
Pick the person who has a foot closest to twelve inches in length.
Take a photo of that person's foot.
Print the photo to actual size.
Hang it on a wall where you live, with the caption "Standard of Measurement" below it.


If it's working, your browser will hang for a long time.
Sending data from Flash->JS without full escaping looks like a total disaster.
We can't send characters 8232-8233 for because they are line breaks in some crazy language.
And when trying to send character 55296, it becomes 65532 on the JS side.
The same for the next thousand or so characters.
build log


{% extends '_base.html' %} {% block content %}
According our friends at FiveThirtyEight, these games are among the worst (but somewhat widely played) games of all time.


Welome remarks was done bu Senior Pastor Rev. Chang Kyu Shin and implied to us that the camp will only consist of three things: EAT,PLAY and PRAY.
Our amazing preacher who shared gospel for two consecutive nights
Oh my donsaengs are happy and enjoying without me ^_^. (Kenji and Jericson)
Canteen, but we prefer eating outside for a cooler feel.
They were so serious taking videos of the performance.
An hour before we leave the camp, clothes were given to everyone.
Made it. Enjoyed it in two hours.
Aubrey and her son Yhuan
Special Performances from different families which we envy, so next year me and my dongsaengs will prepare something too.
Thanks Doc for the cough medicine.
With Taepyong Team Leader Sister Stephanie
Our last night at the camp and we made friends with the other families from Baguio Group.
With Sister Lovely
Baguio Group and Pastor Shin
An hour filled with fun and play. Feels like playing at Running man with limited time LOL! Now we need to run back at the camp. Luckily, its just five minutes tricycle away


Ryan Elliot Drew
About Ryan
Based out of Prince Edward Island, Canada, Ryan Elliot Drew is an active performer, writer, and educator. He is the music specialist at the Montessori School of Charlottetown, a teaching artist with the National Art Centre's Music Alive Program, and he is a classicaly trained percussionist who performs regularly throughout North America.


Physician Review
A physician is reviewing your order to determine if this is appropriate for you.
Kit Registered
You have successfully registered your sample collection kit.
Sample Uploaded
Your sample has been received by the lab.
DNA Extraction Complete
Your sample is currently being processed by the lab.
Data Delivery Complete
Helix genomics has provided your sample data for reviewing and interpretation.
Results ready for view
Follow the instructions below to view your results.


randRange(0,1)
quesType===0 ? "genotype" : "phenotype"
randRange(0,2)
randRange(0,2)
["homozygous dominant","heterozygous","homozygous recessive"]
["A couple is planning to have a baby and wants more information about the probabily that their baby will have brown or blue eyes. The dominant allele (B) is brown eyes and recessive allele (b) is blue eyes.", "Two pea plants are crossed and the color of the offsprings' seeds is studied. The dominant trait (Y) is yellow seeds and the recessive trait (y) is green seeds.","Two corn plants are crossed and their offsprings' height is studied. The dominant trait (T) is tall and the recessive trait (t) is short.","Two guinea pigs are crossed and the length of their offsprings' fur is studied. The dominant trait (R) is long hair and the recessive trait (r) is short hair."]
randRange(0,scenarios.length-1)
scenarios[scenarioNum]
["BB","Bb","bb","YY","Yy","yy","TT","Tt","tt","RR","Rr","rr"]
allelesText[scenarioNum*3]
allelesText[(scenarioNum*3)+1]
allelesText[(scenarioNum*3)+2]
The mother is traitTypes[momtype] and the father is traitTypes[dadtype]. What is the probability of the offspring having each possible genotype?
[100,0,0,50,50,0,0,100,0,50,50,0,25,50,25,0,50,50,0,100,0,0,50,50,0,0,100]
(momtype * 3 + dadtype)*3
combos[answerStart]
combos[answerStart + 1]
combos[answerStart + 2]
The mother is traitTypes[momtype] and the father is traitTypes[dadtype]. What is the probability of the offspring having each possible phenotype?
["Brown eyes", "Blue eyes", "Yellow seeds", "Green seeds", "Tall", "Short", "Long hair", "Short hair"]
phenosText[scenarioNum*2]
phenosText[scenarioNum*2 + 1]
[100,0,100,0,100,0,100,0,75,25,50,50,100,0,50,50,0,100]
(momtype * 3 + dadtype)*2
phenoCombos[phenoAnswerStart]
phenoCombos[phenoAnswerStart+1]
["are","is","are","are","are"]
["s","","s","s","s"]
probText
quesTextGeno
init({
range: [ [ -5, 5 ], [ -5, 5 ] ]
});
line([-4,-4],[-4,4]);
line([0,-4],[0,4]);
line([4,-4],[4,4]);
line([-4,4],[4,4]);
line([-4,0],[4,0]);
line([-4,-4],[4,-4]);
var label1 = allelesText[scenarioNum*3+momtype][0];
var label2 = allelesText[scenarioNum*3+momtype][1];
var label3 = allelesText[scenarioNum*3+dadtype][0];
var label4 = allelesText[scenarioNum*3+dadtype][1];
label( [-2,5], label1, "center");
label( [2,5], label2, "center");
label( [-5,2], label3,"center");
label( [-5,-2], label4, "center");
console.log(momtype);
console.log(dadtype);
console.log(combos);
console.log(answerStart);
console.log(answerHomoDom);
console.log(answerHetero);
console.log(answerHomoRec);
homoDomAlleles = answerHomoDom%
heteroAlleles = answerHetero%
homoRecAlleles = answerHomoRec%
Copy the mother's first allele (allelesText[scenarioNum*3+momtype][0]) into the two left boxes directly below and the mother's second allele (allelesText[scenarioNum*3+momtype][1]) into the two right boxes directly below.
Copy the father's first allele (allelesText[scenarioNum*3+dadtype][0]) into the two top boxes directly to the right and the father's second allele (allelesText[scenarioNum*3+dadtype][1]) into the two bottom boxes directly to the right.
Count the number of homozygous dominant allele combinations (homoDomAlleles) and enter the percent (that number/4) in the corresponding answer box.
There genoHintText1[answerHomoDom/25] answerHomoDom/25 homoDomAlleles combinationgenoHintText2[answerHomoDom/25]. That represents answerHomoDom%
Count the number of heterozygous allele combinations (heteroAlleles) and enter the percent (that number/4) in the corresponding answer box.
There genoHintText1[answerHetero/25] answerHetero/25 heteroAlleles combinationgenoHintText2[answerHetero/25]. That represents answerHetero%
Count the number of homozygous recessive allele combinations (homoRecAlleles) and enter the percent (that number/4) in the corresponding answer box.
There genoHintText1[answerHomoRec/25] answerHomoRec/25 homoRecAlleles combinationgenoHintText2[answerHomoRec/25]. That represents answerHomoRec%
probText
quesTextPheno
init({
range: [ [ -5, 5 ], [ -5, 5 ] ]
});
line([-4,-4],[-4,4]);
line([0,-4],[0,4]);
line([4,-4],[4,4]);
line([-4,4],[4,4]);
line([-4,0],[4,0]);
line([-4,-4],[4,-4]);
var label1 = allelesText[scenarioNum*3+momtype][0];
var label2 = allelesText[scenarioNum*3+momtype][1];
var label3 = allelesText[scenarioNum*3+dadtype][0];
var label4 = allelesText[scenarioNum*3+dadtype][1];
label( [-2,5], label1, "center");
label( [2,5], label2, "center");
label( [-5,2], label3,"center");
label( [-5,-2], label4, "center");
console.log(momtype);
console.log(dadtype);
console.log(phenoAnswerStart);
console.log(answerDomPheno);
console.log(answerRecPheno);
domPhenosText = answerDomPheno%
recPhenosText = answerRecPheno%
Copy the mother's first allele (allelesText[scenarioNum*3+momtype][0]) into the two left boxes directly below and the mother's second allele (allelesText[scenarioNum*3+momtype][1]) into the two right boxes directly below.
Copy the father's first allele (allelesText[scenarioNum*3+dadtype][0]) into the two top boxes directly to the right and the father's second allele (allelesText[scenarioNum*3+dadtype][1]) into the two bottom boxes directly to the right.
Remember that phenotype means the actual trait that shows up. For the dominant trait to show up, only one dominant allele is necessary. Count the number of combinations that contain the dominant allele (allelesText[(scenarioNum*3)+1][0]) and enter the percent (that number/4) in the corresponding answer box.
There genoHintText1[answerDomPheno/25] answerDomPheno/25 combinationgenoHintText2[answerHomoDom/25] that contain the dominant (domPhenosText) allele. That represents answerDomPheno%
For the recessive trait to show up, both alleles must be recessive. Count the number of combinations that contain only the recessive allele (allelesText[(scenarioNum*3)+1][1]) and enter the percent (that number/4) in the corresponding answer box.
There genoHintText1[answerRecPheno/25] answerRecPheno/25 combinationgenoHintText2[answerHetero/25] that contain both recessive (recPhenosText) alleles. That represents answerRecPheno%