Hi everybody!
I'm building my own energy monitor using an Arduino Uno, a CT Sensor, a 9VAC Transformer (instead AC-AC power adapter) and some generic electronic pieces.
I have some questions about how to interface the components with the arduino, I already have the breardboard ready with the resistors and capacitors installed in place (I follow this tutorial http://openenergymonitor.org/emon/buildingblocks/how-to-build-an-arduino-energy-monitor).
For connecting the CT Sensor, I have a generic 3.5mm jack, with 3 outputs (tap, ring , sleeve) but I don't know which ones connect to the breardboard, and also, the 3.5mm jack that I bought has only one output for the ring and the CT Sensor has 2 rings :(
For connect the transformer; the transformer has 3 outputs, 2 current outputs and a gnd. If I connect the 2 current outputs, I get an output of 9VAC, if I connect one current output and the gnd I get an output of 4.5VAC; so, Which of these outputs I have to connect to the breardboard?
Thanks in advance.
Re: Interfacing CT Sensor and 9VAC Transformer
Hello Juan,
Taking the CT first. Do you have a multimeter? If so, you can check which connections are used. Only two are used with our standard CT, tip and sleeve. There is no connection to the ring.
The female connector you have is, in audio terms, mono? If you have no connection to the ring on the plug (male) connector, the socket (female) connector you have should be OK.
For the voltage monitor, use the full 9 V if you have the voltage divider components specified.
Re: Interfacing CT Sensor and 9VAC Transformer
The female connector is stereo, that is ok, I have just connect the CT Sensor (tip and sleeve [I used a multimeter]) but I don't know if I'm doing right because I get some dummy reads even without conect the CT to the female jack, this is a sample:
65.26 0.28
64.84 0.28
62.82 0.27
64.12 0.28
63.54 0.28
...
91.09 0.40
105.20 0.46
As you can see, sometimes I got values between 60.00 - 68.00 but also I got greater values, this is without connect the CT, but that doesn't matter because when I connect the CT I got the same values :(
I'm using the sketch of that page: http://openenergymonitor.org/emon/buildingblocks/arduino-sketch-current-only but I thinks I'm doing wrong because the sketch is for the european specifications and I'm from Mexico. Here the specification is 100 - 127 volts, 60 hertz electrical system.
In case of the transformer, when you use an AC-AC power supply, I think you have 2 outputs, live and gnd, right?
In the transformer, Do I have to connect both live terminals? Consider one as live and the other one as GND?
Re: Interfacing CT Sensor and 9VAC Transformer
The sketch you are using shows only current. Many people report seeing low readings when there is no current flowing, and we are investigating to try to find the cause. I think it might be digital noise from the Arduino itself interacting with the analogue to digital converter. The error will become much smaller as the current gets larger ( > 1% of maximum current). In any case, unless you have changed the sketch ( the line
must be changed to
or whatever your normal supply voltage is) you are reading twice as much power as there really is. 60 Hz compared to 50 Hz should make no difference - except that it will take fewer reading for each cycle of mains.
Now voltage:
The secondary winding of your transformer is "centre-tapped". That means it has a connection at the centre of the winding. It gives you 9 V measured from end to end, and 4.5 V across each half. You will not use the connection to the centre, and it does not matter (for this sketch) which end you call ground and which you call "9 V".
But to measure and use the voltage, you need to use a different sketch. Try http://openenergymonitor.org/emon/buildingblocks/arduino-sketch-voltage-...
You will need to change the calibration in this line:
to suit your mains voltage. The theory is here: http://openenergymonitor.org/emon/buildingblocks/ct-and-ac-power-adaptor... and I think you need to change 234.26 to about 117 (it might be less than 117, and it could be as big as 140). If you do not know the exact details of your transformer, you must measure the mains voltage (TAKE CARE!) and adjust the calibration constant in the software to give the correct answer.
If now this sketch gives a negative number for power, you must either reverse the connections to your voltage transformer, or reverse the CT on the cable.
Re: Interfacing CT Sensor and 9VAC Transformer
Hi Juan,
Power requirements for the Uno are nicely described at http://arduino.cc/en/Main/ArduinoBoardUno. The easiest way to power Arduino is via a USB cable. For standalone mode, you need to provide a 9V DC supply or similar (not AC). I've found an old 9V 200mA centre-positive AC-DC adapter which is working fine.
For measuring mains voltage, you need to provide a stepped-down version of the mains voltage to the Arduino's input. Your 9V transformer would do nicely, but do make sure that the voltage is sufficiently reduced. I'm also using a 9V AC supply which is further reduced by a factor of ten.
The secondary coil of your transformer must be completely isolated from ground. By tying it to the 2.5V reference at just one point, an AC signal centred at 2.5V is available at the input pin.
Good luck
Re: Interfacing CT Sensor and 9VAC Transformer
Hello again!
After a lot of attempts, finally I'm getting good readings from the CT Sensor, the problem was my wiring, I'm only need to solder the wires to the female 3.5 jack to fix it.
Now, the specification of the transformer are:
INPUT : 127V, 60Hz
OUTPUT: 9V, 300mA
But I'm measuring an output of 10V and 320mA, with this data and according the formula of AC Theory I calculate the voltage constant in 110.
Now, reading the calibration theory, I notice that this formula
counts = (input pin voltage / 3.3) x 1024
is considering that the arduino output is 3.3V, and I'm using the 5V output, Can this affect the measuring?
Re: Interfacing CT Sensor and 9VAC Transformer
No, if you continue reading: "However, the processor is able to measure its own reference voltage, this and the full scale count are already included in the program. This removes these steps and simplifies the calculation".
The 320 mA you measure is not relevant, because when the transformer is used as a voltage monitor, it delivers almost no current. In that case, it is quite normal for the output voltage to be higher than the label states (+25% is not unusual for a small transformer). The numbers you need to calculate the voltage constant are the supply voltage and the transformer output voltage (measured at the same time, because the supply voltage can and does vary). If you measured 10.0 V when the supply was 117 V, then I think your voltage constant is 128.7. Of course, this might still be wrong because the resistors might not be exactly the correct value. You might need to measure the supply and adjust the voltage constant so that your display reads the correct value.
Re: Interfacing CT Sensor and 9VAC Transformer
Hi Juan, It may not be worth going to a lot of effort to calculate VCAL and ICAL. The best calibration values for your circuit are those that make your readings agree most closely with measurements taken with accurate test equipment.
Taking great care, first measure the mains voltage with a suitable meter and change VCAL so that your circuit gives a similar value. Then check the current drawn by different loads which take known amounts of power and adjust ICAL so that your readings match these values.
Calibration is part of the Energy Monitor's design, you can't avoid it by calculation alone. Calibration is the process that allows different circuits to give the same (correct) results.
Re: Interfacing CT Sensor and 9VAC Transformer
It is worth calculating the calibration constants, and you should use the calculated values as a starting point. You will almost certainly need to adjust the values (using the procedure described in http://openenergymonitor.org/emon/modules/emontx/firmware/calibration and repeated by calypso_rae above) to take account of component tolerances. But if you find that you need to change the calibration constant by more than 10 - 15% for VCAL, or 5% for ICAL, then unless you can explain the difference it might indicate a faulty component or an assembly error (or, if you are not using a proven design, a design error), and you should carefully check your work.
Re: Interfacing CT Sensor and 9VAC Transformer
Hello,
I'm experiencing the same issue you were, with the CT sensor, I understand that the arduino is picking up a lot of noise and that's the reason why we are seing some values even when the sensor is disconnected.
My problem is that after putting all the components together I took a measurement of the circuit my notebook was connect ... and the measurements seemed legit enough, I was getting around 60 VA ... and a reading of the voltage of around 230V, but after connecting other devices to the line ... the current didn't change the way it should (it should of been of around 7A) , it stayed at the same value, the only visible change was in the voltage drop.
Do you have any hints about way this is happening?
BTW I'm using the YHDC SCT-012-000 and a 33ohm burden resistor.
Thanks ;)
Re: Interfacing CT Sensor and 9VAC Transformer
Have you read the installation and calibration notes? Where have you installed the c.t. ?
Re: Interfacing CT Sensor and 9VAC Transformer
To check the operation of any system that can measure current and voltage, I would start with the standard OEM V&I sketch.
While supplying a known load, such as an old-style 40W light bulb, record the power (which is available as emon1.realPower). Don't worry too much about the absolute value at this stage, just reverse the clamp and repeat the exercise. All being well, you should get two equal values with opposite signs.
Check for linearity; ten times the current should be recorded as ten times the power. Adjust VCAL and ICAL to give the voltage and current values that you expect, not forgetting to confirm your values by calculation so far as is possible :)
I posted a tool recently at http://openenergymonitor.org/emon/node/789 which allows indivual samples to be inspected. These values are in ADC-units in the range 0 - 1023. Make sure that you're using a reasonable amount of the range.
Until these basic aspects have been dealt with, I wouldn't take new hardware any closer to household wiring than the nearest 13A socket!
 I installed the ct sensor on the extension cord which was powering my laptop ... without separating the phase from the neutral ... Thanks again ;)
Now that I can see it's working I would like to try and get rid of some of the noise my circuit is picking up...
And since for the moment it's on a breadboard I'm thinking to print a pcb and have all the components installed on it.
And I was also thinking of trying to calibrate the circuit by making an average of n samples ... for a given load (like calypso_rae sugessted) and going from there ... but I haven't thought this thru yet ... any suggestions are more then welcome :D
Re: Interfacing CT Sensor and 9VAC Transformer
I wasn't suggesting that you should take the average of multiple samples. Rather, that your circuit should give readings that look right for various different loads. If your circuit is linear, then that should not be a problem.
My Mk2 input circuitry is on a breadboard and is giving good results. There's nowt wrong with breadboards, for short-term use, IMHO :)
Re: Interfacing CT Sensor and 9VAC Transformer
There's nowt wrong with breadboards, for short-term use, IMHO :)
But there's anecdotal evidence that breadboards are more likely to give spurious readings when no current is actually flowing. A PCB with a good layout for the analogue department is more likely to give satisfactory results. Breadboards are excellent for what they're intended. It's horses for courses.
Re: Interfacing CT Sensor and 9VAC Transformer
Unless you're using all-soldered connections, your voltage and current inputs will be arriving at the Arduino via its push-in connector strips. The sockets on my breadboard inspire far more confidence than those on either of my Arduinos!
My current and power readings seem just fine with the breadboard. Once the design has been fixed, I then rebuild everything onto stripboard. I've never constructed a PCB. My first attempt to do so would probably not be a pretty sight!
Re: Interfacing CT Sensor and 9VAC Transformer
I have another question :D
If anybody tried it, or knows how this works...or how it's supposed to work
I also have a chipkit max32 prototyping board with a pic32 on it, and I initially tried to have the monitor working on it ... but I kind of failed.
to program the max32 I'm using MPIDE which doesn't really get along so well with the OEM library and I don't really know what I should change in it the make it work ...
Re: Interfacing CT Sensor and 9VAC Transformer
What are you referring to here: "If anybody tried it, or knows how this works...or how it's supposed to work"? The chipKIT board?
I have not noticed anyone in the forums mention the chipKIT board - I think everyone here uses either the Arduino or our shop's emonTx, emonBase and emonGLCD.
Unless anyone else knows better, I think you have to take our code, understand how it works and then adapt it to use the libraries etc. that I presume are available for the chipKIT, and at the same time adjust the code to suit what I presume are different port allocations etc. I see the Digilent website claims that it is "Compatible with many existing Arduino™ code examples" but clearly not all.
You might find someone who can give more help on the chipKIT forum.
Re: Interfacing CT Sensor and 9VAC Transformer
Yes, that's what I was referring to, the chipkit board.
Re: Interfacing CT Sensor and 9VAC Transformer
Hi,
New member here with problem which I think most closely relates to this thread.
Some details;
The output in the monitor window is;
41.62 44.00 54.56 0.81 0.95
That 54.56V is the problem I have, to get it close to the expected 230V I have to increase the voltage calibration factor to over 1000, I can’t see why?
Re: Interfacing CT Sensor and 9VAC Transformer
Hello & welcome,
Are you using the emonTx PCB or an Arduino? I assume when you say "The two reference voltages (potential dividers) are 2.4V" that it's an Arduino. If it's an emonTx, there's your problem - they should be 1.65 V. Otherwise, those voltages seem to make sense, though the final divided down voltage (0.997) is OK for an emonTx but low for an Arduino (the Arduino input range with a 5 V supply is 0 - 5 V, so 5 V p-p less a bit for component tolerances = 1.4 - 1.5 V rms or so. But that doesn't explain a factor of about 4.
Which sketch? I also assume you have got all the required libraries downloaded and installed in the correct places.
The library function reads the reference voltage and it should cancel in the maths, have you tried putting some Serial.print(....) debugging statements in to see exactly what the values are. First suspicions are vcc = readVcc(); What are you getting there for vcc? (It should be the supply in mV, I read 3342 on an emonTx).
Re: Interfacing CT Sensor and 9VAC Transformer
I’m really sorry, I just knew that I would leave out some important info. Here are some more details;
I’m guessing it’s that board reference value that may be a large part of my problem?
I tried making the change detailed here in post #2, but that had the effect of dropping the value to zero for readVcc;
http://openenergymonitor.org/emon/node/668
Thanks very much for the help.
Edit: Your points about the reference voltage got me thinking, and I just found this (perhaps I should have looked here first, seems obvious now?), it seems I have a couple of choices for the internal reference, and I guess that it is currently defaulting to 1.1V;
http://arduino.cc/en/Reference/AnalogReference
I guess that to obtain full range of the A-D inputs I need to set the Arduino to a default reference of 5V?
Re: Interfacing CT Sensor and 9VAC Transformer
With the standard Voltage and Current sketch, there should be two ac signals at the Arduino, one for voltage and one for current. A 1V ac signal, centred at 2.4V, sounds perfect for the voltage input; that's around 3V peak-to-peak.
Re: Interfacing CT Sensor and 9VAC Transformer
Thanks for the reply, I think you are correct, but I now believe that the reference voltage being used by the Mega is too low at 1.1V, I was probably editing my post while you were replying?
Re: Interfacing CT Sensor and 9VAC Transformer
With the Arduino Uno Rev 3, the default value of Vref appears to be 5V. That ties in nicely with the standard front-end circuits which create signals that are centred around 2.5V.
Using a lower value of Vref (e.g. 1.1V) might well be a good idea because this would be better suited to the output of the CT which does not like being forced to generate high voltage values. The components of the resistive divider that creates Vref would just need to be altered accordingly.
Reducing Vref may be a more practical alternative than adding an amplifier stage. I'm so pleased that my circuit is still on breadboard ...
Re: Interfacing CT Sensor and 9VAC Transformer
I'm at work at the moment, but will play around with the AnalogReference setting this evening, if the default value of 5V works, then I will probably stick with that.
Re: Interfacing CT Sensor and 9VAC Transformer
I detect some confusion about to creep in here. If the reference is set to 1.1 V, then the signal must swing between 0 V and 1.1 V. If it was centred on 2.5 V, the input was permanently above the 1.1 V reference (= 1023 counts, the maximum) except for a brief period on the negative-going peaks, and that explains your very low reading for the mains voltage.(I won't confuse the issue with explaining what the software high-pass filter did - but I can if you want me to!).
Your choices:
As Calypso_rae points out, the current transformer will behave better with a lower burden resistor and lower voltage output (i.e. you might need to use an external burden in parallel with the internal one to give the 1.1 V peak-peak output at the maximum current you want to measure).
There should be no problem with using the 1.1 V reference. It does make the analogue inputs a little more susceptible to noise pickup, but the software should perform better because the 1.1 V reference is stable so you have no need to switch references in the software to measure the 5 V supply - which the library does automatically - to ensure the input is calibrated correctly.
Re: Interfacing CT Sensor and 9VAC Transformer
I think the idea of using a smaller value of Vref is an excellent one. This aligns nicely with the size of signal that a correctly set up CT will generate. The burden should be set to give an output signal of around 1V p-t-p when the current is at the maximum rating of the dump load (usually 3kW, or 12.5A).
(hope I'm not addiung to any confusion!)
Re: Interfacing CT Sensor and 9VAC Transformer
Robert / Calypso, thanks for the replies.
So I’m back from work and I edited the setup() section of the sketch to add ‘analogReference(DEFAULT)’, but the results didn’t change. I had added some debug print to the Emonlib.cpp, printing out the ‘result’ from readVcc(), and it did not change from the 1100 value I saw earlier. I suspect that this line may be incorrect;
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
But the suggested change here http://openenergymonitor.org/emon/node/668 did not work for me as it caused the readVcc() result to drop to -1.
I set the readVcc result to a fixed value of 5000, i.e. meaning full digital range equates to 5V (not quite the true value) and I started getting sensible values for both voltage and current, my 3Kw electric kettle adding about 12A to the current reading when turned on.
So, I think the analogue reference is actually defaulting to the 5V supply, and A-D conversions are good with no clipping, but the Emonlib.cpp readVcc() function is always returning the internal 1.1V reference value.
I could change resistor values as suggested, but would like to try to track down the correct code for determining the analogue reference voltage in use by the Mega 2560.
Re: Interfacing CT Sensor and 9VAC Transformer
I’ve been looking at the datasheet, and it looks to me like I should be able to set the ADMUX to read the AVCC voltage, but I’m not familiar with the code to set the appropriate bits. I should be able to work it out, just bit too late in the day for me to think straight right now.
http://www.atmel.com/dyn/resources/prod_documents/doc2549.PDF
Re: Interfacing CT Sensor and 9VAC Transformer
From what you say, I think you're right and it is only the reading of the reference that's gone wrong. If your 5 V is very stable, then in theory at least you shouldn't need to read it and you could plug in the fixed value and forget it. If not, the reading of it is probably necessary.
I suspect the code you tried was for the 328P, which is the one used in the emonTx. That could explain why it's all not working, because stuff like _BV(REFS0) are macros and could well be device-specific. I've never had to delve into these areas, I think there are three approaches you could try:
You might find the explanations here useful: http://urbanhonking.com/ideasfordozens/2009/05/18/an_tour_of_the_arduino... and Trystan Lea recently blogged about a linked topic here: http://openenergymonitor.blogspot.co.uk/2012/08/low-level-adc-control-ad...
Re: Interfacing CT Sensor and 9VAC Transformer
Thanks,
It was getting late last night, and while the datasheet isn’t so difficult to understand it was too late for me to investigate any further.
I measured the AVCC at the pin, and it was very stable (4.765), so I entered that adjusted value (4765) into Emonlib.cpp, and I seem to be getting sensible values e.g. switching on the kitchen lights (8*50W halogen) caused the power reading to increase by 400W. I still need to make some calibration changes, but I don’t mind that now that I am in the ballpark and not out by a factor of nearly five. I’m testing with the board powered from my laptop USB port, so will need to make another adjustment when I move to a different supply or computer.
I will consider using a lower reference voltage (maybe the 2.56V ref), but I plan to use the other 14 analogue inputs for measuring things like room temperatures/light/humidity around the house, and the sensors I plan to use are very simple to interface to a 5V range D-A. Also with a number of sensor cables (screened) distributed round the house I think the affects of noise could become more significant if using a lower reference voltage.
Knowing what I know now I am surprised it worked at all, most of the input waveforms must have been clipped by the A-D. That does seem to explain the occasional zero readings and the occasional 20Kw readings, it's all pretty stable now.
Re: Interfacing CT Sensor and 9VAC Transformer
So you're a moderately happy bunny then? Long-term I think it would be a good idea to track down where the error is and read the reference, because then you shouldn't be bothered if the 5 V drifts a little.
Re: Interfacing CT Sensor and 9VAC Transformer
What version of the ATMEGA 2560 chip are you using?
Looks like the "A" version has some ADC bugs in it!
http://www.scribd.com/doc/49801593/133/ATmega2560-rev-A
Re: Interfacing CT Sensor and 9VAC Transformer
Robert,
Yes I’m happy. If I do find anything relevant / useful I will post here, but at the moment I’m good to go.
Stuart,
Not sure which version it is, but I was able to select the different reference voltages (internal 1.1 / internal 2.56 / AVCC) and measure the change at the pin, and the results for the current / voltage measurement also changed at the same time. So I think the internal reference voltages are good, it just seems like the code at the end of Emonlib.cpp (readVcc) is not working with the Mega2560.
Re: Interfacing CT Sensor and 9VAC Transformer
Andy,
the ATmega2560s ADC and especially its multiplexer is quite a bit different from the ATmega328. It has more input channels and an option for differential inputs.
You have to change at least one line in readVcc()::
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
to
ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
This should select the 1.1V reference as ADC input on the ATmega2560 same as the previous line did for the ATmega328.
I can't try this because I do not have an ATmega2560.
BR, Jörg.
Re: Interfacing CT Sensor and 9VAC Transformer
Jörg.
I have tried making changes such as you suggest, and in fact with the current Emonlib.cpp unchanged I have verified that the 1.1V reference is being selected / read. However following the original energy monitor instructions here; http://openenergymonitor.org/emon/buildingblocks/how-to-build-an-arduino-energy-monitor I have everything set to operate from a 5V supply, so if I were to set the ADC with a top end reference of 1.1V without modifying the circuit, everything would be clipped quite heavily.
I currently have the Mega2560 set to use the AVCC reference which is pretty stable at 4.675V, but this will most likely change when I change supply. The remaining problem is that the readVcc function in Emonlib seems to assume that the reference voltage in use is the 1.1V ref, and accordingly all my signals were being factored down roughly five time e.g. mains voltage was reading about 55V. The reference voltage in use is AVCC, nothing is being clipped, but the Emonlib readVcc function is in my case making an incorrect assumption.
If it is possible, and I think it is, I plan to change the Emonlib readVcc function so that it reads the AVCC voltage, then I should be able to change supplies e.g. move to a different computer without having to use a preset value in the readVcc function as I am currently doing (always returns 4675).
Re: Interfacing CT Sensor and 9VAC Transformer
The remaining problem is that the readVcc function in Emonlib seems to assume that the reference voltage in use is the 1.1V ref,
No, the readVcc() function 'compares' the reading of the 1.1V reference to VCC in order to get a 'calibrated' value for the (until then unknown!) VCC voltage (if VCC is taken as reference for the ADC, then FullScale of the ADC = VCC = 1023).
Example:
if VCC = 4.4V (=1023=FullScale of the ADC!) then the reading for the reference voltage of 1.1V will be ~1023/4=~256. So, if you do not know the value of VCC, you take the result of the ADC conversion of the 'well-known' 1.1V and use this value to calculate VCC. In my example:-
- you get a reading of 256 for 1.1V
- calculate Vcc as 1023/256*1.1V = ~4.4V
The 1.1V reference voltage does not have a very good absolute accuracy, but it is quite stable regarding temperature and VCC changes. So, using this method makes the voltage readings independant from supply voltage fluctuations and temperature changes.
Re: Interfacing CT Sensor and 9VAC Transformer
if VCC = 4.4V (=1023=FullScale of the ADC!) then the reading for the reference voltage of 1.1V will be ~1023/4=~256.
It may be that I have misunderstood what readVcc is trying to do. I’m working from memory since I’m at work at the moment, but I have only seen readVcc return either 1100 or -1, regardless of what I set analogReference() to in the sketch (DEFAULT, INTERNAL1V1, or INTERNAL2V56).
I know that currently I have set readVcc to return a constant value of 4657, with the analogReference set to (DEFAULT), and AVCC measuring around 4.657V at the appropriate pin on the Mega2560. This results in sensible values for power / current / voltage being printer out to the monitor window.
If however I let readVcc report as normally without making any other changes, it returns a value of approximately 1100, which I understand means Vcc is 1.1V, and all values printed out to the monitor window are wrong e.g. Vrms is about 55V.
So my understanding of what you have said, is that for a normally working system the readVcc function should only return a value of around 1100 if the ADC reference voltage is set to 1.1V, and if the reference voltage for the ADC is set to 5V then readVcc should return a value of 5000. Does that seem correct, if so it's not what is happening for me?
Re: Interfacing CT Sensor and 9VAC Transformer
If you use readVcc() as it is, it does not matter to which other value you set the reference with analogReference, as this is overwritten in readVcc(). ADMUX = _BV(REFS0) sets the reference to 'AVCC with external capacitor on AREF pin'.
And yes, this function:
should give a reading of ~5000 from readVcc() if your VCC is ~5.0V.
Re: Interfacing CT Sensor and 9VAC Transformer
Thanks Jörg,
I will have another look tonight if I get chance and add a few more print statements to see where it goes wrong. I have tried adding _BV(MUX4) already and it didn’t work (result was -1), but I will happily try again since I could have made a silly error in my typing.
Re: Interfacing CT Sensor and 9VAC Transformer
Well I tried the code change again, even copied/pasted from web pages where I had seen the same code, the result was -1 as before. With the original code the result is 1100, and so it seems to me that the measurement is being made while the reference voltage for the ADC is also 1.1V, a bit odd since all other measurements seem to be correctly scaled for a 5V range, simply forcing readVcc () to return 4675 results in reasonable values for voltage / current. So is it possible that the readVcc() function is not only measuring the 1.1V reference, but is also setting the ADC to use that reference at the same time? I don’t see how myself.
Re: Interfacing CT Sensor and 9VAC Transformer
As I understand it, the way it should work is this:
Re: Interfacing CT Sensor and 9VAC Transformer
Robert, that makes sense, and I think agrees with Jörg’s explanation above. I believe the Mega2560 is using the 1.1V as both the reference for the ADC and the MUX is measuring that same voltage (a bit incestuous). The raw ADC output is 1023 (ish) giving a readVcc() return of 1100 mV.
Actually, thinking about it, I can’t really tell what reference it is using for both; they could both be the AVCC voltage since if both the reference and the measured voltage are the same the result will be 1023.
It seems to me that I need to change the code so that readVcc() uses the AVCC (5V) reference to measure the 1.1V reference, which should result in the area of the figures Jörg suggested (225 for as 5V reference). I need to think about this more in the morning when my brain is awake, it's a little late for me to be looking at datasheet registers.
EDIT:
I think the answer may be on page 291 of the Mega2560 datasheet, Table 26.4 MUX5:0 row 011110 1.1V (VBG), I need to set the MUX bits to 011110 to select the 1.1V reference to be measured (with AVCC selected by ADMUX = _BV(REFS0) as Jörg said.
Re: Interfacing CT Sensor and 9VAC Transformer
I need to set the MUX bits to 011110 to select the 1.1V reference to be measured (with AVCC selected by ADMUX = _BV(REFS0) as Jörg said.
This is exactly what the line
does! MUX5 is per default set to 0, but you could do this manually if you do not trust it. Did you really try this code line (or better still the complete code for readVcc() that I posted above)?
Re: Interfacing CT Sensor and 9VAC Transformer
Does ADCSRB (in the 2560) need to be set up as well as ADMUX ? It doesn't exist in the 328.
Re: Interfacing CT Sensor and 9VAC Transformer
Jörg, yes, I really have tried that line, several times now, manually entered and cut/pasted from web pages, the returned value is -1, I have even tried setting MUX5 explicitly (a different register - ADCSRB) but admit I may have got that bit of code wrong.
Robert, if the ADC is set to use the AVCC reference, with the MUX incorrectly set such that it’s reading a floating input, or worse the ADC set to the 1.1V reference with the MUX incorrectly set to a floating input, then I think that could be a possible cause for the full scale reading?
Re: Interfacing CT Sensor and 9VAC Transformer
Jörg, yes, I really have tried that line, several times now, manually entered and cut/pasted from web pages, the returned value is -1, I have even tried setting MUX5 explicitly (a different register - ADCSRB) but admit I may have got that bit of code wrong.
Hmmm. I give up, no chance to test it myself :-(
-1 is a strange result. How can this be reached? If you divide 1126400L by a positive integer in the range from 0-1023, you should never get -1.
STOP, divide by 0 could be a reason! So it seems that the ADC conversion gives 0 as result!?!
ADCSRB &= ~(1<<MUX5) clears the MUX5 bit. If this is set, strange things might possibly happen.
Re: Interfacing CT Sensor and 9VAC Transformer
I think it's anybody's guess what a floating input will return. There's absolutely no reason for it to float anywhere in particular, the input impedance is huge (100M Ohms) and flux residue or dampness on the PCB is going to have as much effect as anything. The chances are though it will float to one rail or the other.
So yes, a floating input could give you full scale. Or maybe not!
A snippet of code here: http://bennthomsen.wordpress.com/embedded-design/peripherals/analogue-in... suggests that ADMUX and ADCSRB both need to be set:
Re: Interfacing CT Sensor and 9VAC Transformer
Thanks Jörg / Robert, I will take another look at it this evening, but not too late in the day this time.
If MUX5 is the only bit in question, then since it can only be one of two values, the incorrect code that might result would be 111110 which in table 26-4 of the datasheet is listed as ‘reserved’.
Re: Interfacing CT Sensor and 9VAC Transformer
Andy,
can you paste this:
and give us the result? If this does not work, than we simply miss something that might have nothing to do with the mux or reference settings.
Re: Interfacing CT Sensor and 9VAC Transformer
A snippet of code here: http://bennthomsen.wordpress.com/embedded-design/peripherals/analogue-in... suggests that ADMUX and ADCSRB both need to be set:
Sorry, Robert, that link doesn't work for me :(
Where are the bit-setting values that appear in the EmonLib function readVcc() actually defined?
Re: Interfacing CT Sensor and 9VAC Transformer
Robin,
if you talk about MUX1, REFS0, these are defined in the header files for the individual controllers. In my arduino installation I find these at
arduino-1.0.1/hardware/tools/avr/avr/include/avr/iom328p.h
in this case for the ATmega328.
Re: Interfacing CT Sensor and 9VAC Transformer
Jörg, I’ll gladly try that, will be about 10 hours from now though, and will let you know how it goes.
Re: Interfacing CT Sensor and 9VAC Transformer
Thanks Jörg. As posted, my code doesn't #include any other files, and doesn't use readVcc(). Because V & I measurements need to run continuously, there is no proper time for this. Rightly or wrongly, my sketch seems to work fine without it!
Yesterday, I changed the analogReference to INTERNAL. My V and I signals are now much smaller in order to stay within the 1.1V range of the Uno's ADC. I've not recalibrated anything, and still don't use readVcc().
Today, the triac appears to be behaving just as before, and our water is clearly getting warm.
Re: Interfacing CT Sensor and 9VAC Transformer
Robin,
readVcc() does only make sense if you think that your VCC is not stable (enough). As it is only measured every now and then it can also not correct very short term VCC variations.
With a stable VCC provided by a voltage regulator it is simply not necessary. (I think they may have introduced it because the arduino hardware may be powered by USB where the voltage can vary quite substantially.)
Re: Interfacing CT Sensor and 9VAC Transformer
Hello, yes the reason readVcc was introduced was primarily to make it possible for the emontx to "self-calibrate" as the supply voltage decreased from 3.3V to 2.7V when powered directly off batteries. If your confident that the voltage is constant then I guess it is not needed. All the best, Trystan
Re: Interfacing CT Sensor and 9VAC Transformer
Jörg, that worked perfectly, seems my error was with MUX5, thanks to everyone for the help, very much appreciated.
Re: Interfacing CT Sensor and 9VAC Transformer
Good to hear that it works now .


Example:
// © 2021 char c = '©'; String s = "Áî";
After the quick-fix is applied:
// © 2021 char c = '\u00a9'; String s = "\u00c1\u00ee";


Toggle navigation
ldmlEdit
{{vm.fileName}}
Load & Save
identity
characters
collations
dates
delimiters
display names
miscellaneous
numbers
resources
segmentations
Copyright 2014 SIL International. All rights reserved. Beta version 0.1


Authentic Italian recipes
This guide covers the basics of classic Italian cooking
The Bare Essentials
The Bare Essentials
The Bare Essentials


Logging into the account
There are two ways you can access your account in the Dashboard:
-
Use the private key that you registered with Ambrosus. Initially, this will be the only way you can log into the system.
-
Once you are in, you can go to your personal account settings, set a password and “Save”. Next time, you can use your e-mail and password to access the account.


Implementation of Normalized Spectral clustering with Lrw Laplacian (Shi and Malik 2000). More...
Public Member Functions | |
| def | __init__ |
| Constructor. | |
| def | perform_clustering |
| Does the actual clustering by doing a k-medoids clustering of the first k eigenvector rows. | |
| def | handle_params |
Public Attributes | |
| verbose | |
| sigma_sq | |
| W | |
| spectral_type | |
| eigenvectors | |
| max_clusters | |
| sigma_estimation | |
| store_W | |
| force_sparse | |
| use_k_medoids | |
Static Public Attributes | |
| list | spectral_types_enum = ["UNNORMALIZED","NORMALIZED"] |
Implementation of Normalized Spectral clustering with Lrw Laplacian (Shi and Malik 2000).
It tries to be both fast and memory efficient in order to be able to work with very big datasets.
Definition at line 33 of file spectralClusteringAlgorithm.py.
| def pyproct.algorithms.spectral.spectralClusteringAlgorithm.SpectralClusteringAlgorithm.__init__ | ( | self, | |
| condensed_matrix, | |||
| kwargs | |||
| ) |
Constructor.
Calculates the eigenvectors given a dataset distance matrix. The eigenvector distances would be the common part for clusterings with different k.
| condensed_matrix,: | The distance matrix of the dataset. |
| sigma_sq,: | The squared value of sigma for the adjacency matrix calculation. If None, the value will be automatically calculated. |
| max_clusters,: | Maximum number of clusters we will try with this algorithm (for instance with max_clusters = 10 we can try with ks in range [1..10] |
| laplacian_calculation_type,: | The type of calculation. |
| store_W,: | If True the object stores the adjacency matrix. Useful for testing. |
| verbose,: | If True some messages will be printed. |
Definition at line 52 of file spectralClusteringAlgorithm.py.
| def pyproct.algorithms.spectral.spectralClusteringAlgorithm.SpectralClusteringAlgorithm.handle_params | ( | self, | |
| params, | |||
| max_clusters_default | |||
| ) |
Definition at line 130 of file spectralClusteringAlgorithm.py.
| def pyproct.algorithms.spectral.spectralClusteringAlgorithm.SpectralClusteringAlgorithm.perform_clustering | ( | self, | |
| kwargs | |||
| ) |
Does the actual clustering by doing a k-medoids clustering of the first k eigenvector rows.
| kwargs,: | Dictionary with this mandatory keys:
|
Definition at line 99 of file spectralClusteringAlgorithm.py.
| pyproct::algorithms::spectral::spectralClusteringAlgorithm.SpectralClusteringAlgorithm::eigenvectors |
Definition at line 52 of file spectralClusteringAlgorithm.py.
| pyproct::algorithms::spectral::spectralClusteringAlgorithm.SpectralClusteringAlgorithm::force_sparse |
Definition at line 130 of file spectralClusteringAlgorithm.py.
| pyproct::algorithms::spectral::spectralClusteringAlgorithm.SpectralClusteringAlgorithm::max_clusters |
Definition at line 130 of file spectralClusteringAlgorithm.py.
Definition at line 130 of file spectralClusteringAlgorithm.py.
Definition at line 52 of file spectralClusteringAlgorithm.py.
Definition at line 52 of file spectralClusteringAlgorithm.py.
list pyproct::algorithms::spectral::spectralClusteringAlgorithm.SpectralClusteringAlgorithm::spectral_types_enum = ["UNNORMALIZED","NORMALIZED"] [static] |
Definition at line 34 of file spectralClusteringAlgorithm.py.
Definition at line 130 of file spectralClusteringAlgorithm.py.
Definition at line 130 of file spectralClusteringAlgorithm.py.
Definition at line 52 of file spectralClusteringAlgorithm.py.
Definition at line 52 of file spectralClusteringAlgorithm.py.


The following is what your recipient members will receive via email. If it looks good, press "Send RFI".
Edit RFI


Career talk and university selection talk Alliance Francaise Entry 500
Book club The Alchemist Entry: A book and a drink
Baking lessons with PewdiePie Entry 500
IAES Kenya Edition Fri, September 15, 2017, 7:00 AM – 10:00 PM EAT Entry :free
Chaka Ranch Fun , March 25, 2017 6 a.m. - 6 p.m
SCHOLARSHIP PROGRAMMES
You’ve worked hard in school to maintain your good grades, and there are people out there who noticed. Luckily, these people are willing to reward you with scholarship money. Check out our full list of merit-based scholarships
below and get started on paying off all that hard work.
COLLEGES AND UNIVERSITIES
Universities are generally divided into a number of academic departments, schools or faculties. Public university systems are ruled over by government-run higher education boards.
EXCHANGE PROGRAMMES
A student exchange program is a program in which students from a secondary school or university study abroad at one of their institution's partner institutions. the National Student Exchange program (NSE) offers placements throughout
the United States and Canada.


The following mods were gleaned from Dave Magnuson's "Resonant Frequencies" page, which has since been swallowed by the ever-shifting internet. Lucky for you, I hate it when stuff like that goes away, and now that it's gone from it's original site, I've copied the important bits and have placed them here. I'll make it pretty later, for now, here's the raw info.
Remove R114 from the DR-110 voice board. Attach two wires to the holes in the circuit board. Wire a 50K linear pot to the two wires as shown. Please note that one end of the pot is left unconnected.
Remove R113 from the DR-110 voice board. Attach two wires to the holes in the circuit board. Connect a 100K log taper pot to the two wires as shown in the diagram below.
You need to remove R16 from the voicing board in your DR-110. Solder two wires into the old location, and fly them to a new circuit board. On this new board, construct the circuit shown in the box on the right. Use a 1K linear pot for the manual filter control, and a 100K log pot for the CV level.
The Cymbal Decay control adds some really strange effects to the DR-110. This will allow
extremely short or extremely long cymbal sustain (15 to 20 seconds!!). Especially strange
noises can be created when used in conjunction with the filter mod above. I chose to simplify
things and skip the voltage control on this mod. You can add it if you'd like with the same
circuit I've been showing in the other mods.
Remove R44 from the voice board and attach 2 wires to the holes in the circuit board. You'll
need to wire a 1K series resistor and 1M linear potentiometer as shown in the diagram below.
On the right I've shown a small portion of the hihat circuit to clarify what I've done. First, I remove R12 from the voicing board, and solder two 4" to 6" wires into the holes. I then construct the simple circuit on an external circuit board, and use the two wires to tie it to the voicing board. I found that a 1K linear taper pot works well for the manual filter control, and a 100K log pot is a good choice for the CV level.
Remove R20 from the voicing board, and solder two 4" to 6" wires into the holes. These two wires are then connected to a resistor and pot. I found that a 1M linear taper pot works well for the decay control, with a 1K resistor in series between the existing circuit and the new pot.
To complete this modification, remove R70 from the voicing board. Install 2 wires to the holes you removed the resistor from, and connect them to a 1K linear pot. I connect the wire in contact with Q10 to terminals A and B on the potentiometer, and the second (ground) wire connects to terminal C. Note that this is a view from the back of the pot.
First, you need to remove R81 from the voicing board of the DR-110. Install two wires between 4" and 6" long into the holes you took the resistor from. I connected these wires to a new circuit board that I built to hold the additional circuits. I found that a 50K linear potentiometer works well for the manual control of the level, and a 100K log pot seems to work well for the CV level. The new transistor can be a 2N3904, or an equivalent. A portion of the snare circuit is shown on the right to help illustrate the new additions. On the manual control pot (50K), connect the new wire from Q13 to terminal C on the pot, and the ground wire connects to both terminals A and B.
Remove R76 from the voicing board. Again, fly two new wires from the voicing board to the new board, and construct the circuit as shown. Again, a 50K linear and 100K log pot are used, along with a 1K resistor and 2N3906 transistor. In this case, connect the wire that is in contact with C35 / C29 / C31 to terminal A on the 50K pot. Connect the other (ground) wire to terminals B and C.
The stock DR-110 already has an "Accent Trigger Output" circuit on board. It converts the negative-going CPU pulses to 6V, 10mS positive-going pulses. You can see this portion of the circuit on the section of the CPU board shown. (I have full DR-110 schematics available for download). As the CPU accent pulse goes negative, it allows capacitor C4 to discharge through D9. This in turn causes Q1 to conduct, pulling the accent output (through R5) to the positive rail (which is 6V in the DR-110)
I felt the stock accent trigger circuit was simple and effective, so I decided to replicate it for each of the drum voices. I simply copied the circuit components listed here
Looking at the ribbon cable connections at the edge of the CPU board schematic, you'll see the following CPU pulses:
There's a total of 8 CPU triggers that go to the voice board. One line is dedicated to Accent (which already has a trigger converter). Each other drum voice has it's own independent trigger, except the handclap which has 2 (one for a single clap, and a triple trigger for the slightly delayed hits around it).  I connected the trigger output board to the DR-110 CPU board with an 8 pin ribbon cable, and carefuly soldered each wire to the appropriate ribbon cable connections. Remember that the accent circuit is already on board. The positive accent pulse is available on the ribbon cable at wire 18. I also added a 2 conductor wire to supply power and ground.
I chose to strap an LED across the trigger outs, so I have a visual indication of which drum voices are firing at any given time. I duplicated R5, so that the collector of Q1 was tied to 2 1K resistors. One feeds the trigger output, the other feeds the LED. I connected all of the trigger outputs to a 9 pin D-sub connector which provides the 8 trigger outputs and a ground connection. For a unique look, I used a numeric display LED instead of 8 individual T-1 (3mm) LEDs. It's pretty wild to watch the numeric display, because it creates a bunch of weird alien characters on Playback.
Of course with this new circuit board, LEDs and D-Sub connector, you'll run out of space inside the DR-110 case. You'll need to come up with a crafty method to attach a new box. I simply added a small box off the rear of the case (above the grid display). I used super glue and a few #4-40 screws, nuts and washers to make a strong, permanent connection. I hope to add pictures soon.


About Me
Bacon ipsum dolor amet drumstick landjaeger tail corned beef ball tip brisket flank boudin capicola filet mignon spare ribs fatback prosciutto pork. Turkey shank kevin short loin tail spare ribs tongue t-bone pork loin sirloin pancetta. Sausage shankle prosciutto cow, frankfurter jerky kielbasa. Brisket bresaola cupim jerky venison sausage corned beef tenderloin chicken strip steak.


NPR Horse.
Loosely based on a "
Loose and Sketchy
" rendering
approach
.
Built with
crayon.js
and
three.js
by
@blurspline
Credits:
Paper Texture
, Horse from
Ro.me
, Art color grading
Wagner


Input a number and click that shiny button to talk to Mr. Roboger! He's a nice fella!
Meet Mr. Roboger!
Mr. Roboger says...
You should not be seeing this dialogue... If you do, it's a bug, please report it! Thanks!!
You should not be seeing this dialogue... If you do, it's a bug, please report it! Thanks!!


Please enable JavaScript in order to view this webpage.
WORK IN PROGRESS
Back to Projects List
Project Name/Title
Description...


The Journal Begins
Two days late, and a lot of html short...
I found the perfect class! But I found it two classes in. Currently playing catch up, but very excited to learn. I finally feel like I'm getting somewhere and doing something concrete toward better career options. I'm on the right track and white-knuckling my way through catching up and learning to "speak to robots"!
First Official Class!
a.k.a. try not to panic and take lots of notes.
First class was fun, I really like the atmosphere of the Portland Code School. I feel a little like she-who-knows-the-least but I will just have to keep pushing. Only I can fix that! I think this is definitely a better way for me to learn than just watching videos at home with no one to ask for help. The energy of the class really keeps me going when I get stuck or frustrated.
The Light is Dawning
a.k.a. things start to connect and make sense.
Things are picking up speed but also starting to fall into place. I watched more of the videos, and that helped way more than I anticipated. Connections are being made! The proverbial clouds are parting!
Which Learning Style Helped
a.k.a. sometimes experts are experts for a reason.
I chose "Skilled learners are process-oriented." from the list of 25 Things Skilled Learners Do Differently. I am always a future planner. This both helps and hurts me. I love the planning stages of things and then often loathe the process. I am trying to keep focused on the process and stay present. Yoga has been trying to teach me this for a long time, so the concept is not foreign. In this particular learning experience, I find I have little choice. It is moving fast and all I can do is stay present. It's like the hot yoga of learning!
Moving into Pro
a.k.a. the part where it gets life changing
So it has definitely been a busy several weeks. But as the class ramps up, and deadlines loom, it becomes clear that decision time is afoot. I thought I had already made these decisions, but no, THIS is when I make those decisions. Things like what is the next step? How am I really feeling about all of this? What does the next step mean for my life? Where can I carve out some more room in my life for this?
This is when sh*t gets real. The good news is, despite all of these big life-altering questions, I still want to do this. I still want to learn this. And I still think this is a good plan. So now it's just a matter of information gathering, advice seeking, list making, and then at last, decision making.
Remember to breathe.


{% extends 'commercialoperator/emails/base_email.html' %} {% block content %}
Your application for a commercial filming authority {{proposal.lodgement_number}} for the {{ district_proposal.district_name }} district/region has been declined.
For further information please login to your account.
If you have any queries regarding this decision please contact a licensing officer on {{settings.DEP_PHONE_FILMING}}, or email {{settings.SUPPORT_EMAIL_FILMING}}
{% endblock %}


| Ingredients | ||
|---|---|---|
| Ingredient | 10 inch pan | 8 inch pan |
| Bob's 1-1 Gluten Free or Paleo Baking Flour | 1 cup (148 g) | 5/8 cup (92 g) |
| Bob's Corn Flour | 1 cup (116 g) | 5/8 cup (72 g) |
| Bob's Medium Cornmeal | 1/2 cup (76 g) | 5/16 cup (48 g) |
| baking powder | 1 Tbsp | 2-3 tsp |
| sugar (coconut, white) | 5 tsp | 3 tsp |
| salt | 1/4 tsp (optional) | 1/8 tsp (optional) |
| Buttermilk | 1.4 cup (340 ml) | 7/8 cup (210 ml) |
| Apple Cider Vinegar | 1 Tbsp | 2 tsp |
| eggs | 2 | 1 |
| butter | 1 Tbsp | 2 tsp |


The best way to manage and understand the logs is to have each member log to its own files.
Log File Naming Recommendation
For members running on the same machine, you can have them log to their own files by starting them in different working directories and using the same, relative log-file
specification. For example, you could set this in <commonDirectoryPath>/gemfire.properties
:
log-file=./log/member.log
then start each member in a different directory with this command, which points to the common properties file:
java -DgemfirePropertyFile=<commonDirectoryPath>/gemfire.properties
This way, each member has its own log files under its own working directory.
Searching the Log Files
For the clearest picture, merge the log files, with the gfsh export logs
command:
gfsh> export logs --dir=myDir --dir=myDir --merge-log=true
Search for lines that begin with these strings:
- [warning
- [error
- [severe
Creating Your Own Log Messages
In addition to the system logs, you can add your own application logs from your Java code. For information on adding custom logging to your applications, see the online Java documentation for the org.apache.geode.LogWriter
interface. Both system and application logging is output and stored according to your logging configuration settings.


Paired With
Pot pie
Guilt-free gluten-
free spaghetti pasta
is sautéed in a
garlic, kale pesto.
It’s an easy and
healthy dinner.
INGREDIENTS
DIRECTIONS
Fat
12g
Calories
465g
Protein
27g
Gluten–free
Egg Free
Creamy Pesto
Pasta
Basil
Gluten-free Spaghetti
Garlic
Ricotta
Kale
Red Pepper Flakes
Extra Virgin Olive Oil
Salt
Pine Nuts
INGREDIENTS
DIRECTIONS
Pot Pie


This page demonstrates the easybytes widget.
Simplest form of easybytes.
Easybytes set to abbreviate units of measure.
Easybytes set to abbreviate units of measure and change default unit to MB.
Easybytes prepopulated with 1 GB.
Easybytes prepopulated with 1 GB and set to multiple of 1000.
Easybytes with a placeholder.


Client Search
Report
Logout
Encounter Form
Date of Encounter
Role of HIVA Representative
Staff
Volunteer/Intern
Initials of HIVA Representative
HIVA Center Location
Select one
Blair
HIV A
Glenwood
Cottage Grove
Outreach
Have they shared a used needle since their last exchange?
Yes
No
Did you provide harm reduction information?
How long ago (in months) was their last HIV test?
Was HIV test referral offered?
How long ago (in months) was their last Hep C test?
Was Hep C test referral offered?
Do they have any medical conditions for which they need to see a doctor?
Yes
No
Was wound/primary care referral offered?
Would they like safer injection info?
Yes
No
Was safer injection info given?
Would they like information about detox, treatment, or NA meetings?
Yes
No
Was detox/treatment referral offered?
Number of Syringes IN
Number of Syringes OUT
Number of Alcohol Swabs Taken
Number of Condoms Taken
Number of Sharps Taken
Number of Cottons Taken
Are they homeless?
Yes
No
What health insurance do they have (if any)?
Select one
Veterans Benefits
Medicare
OHP
Private Insurance
Other
None
Have they exhanged needles with us before?
Yes
No
Have they witnessed a drug overdose in the last 12 months?
Yes
No
Are they exhanging needles for others?
Yes
No
If so, with how many people?
Have they received food from us since July 1st, 2017? (snacks at exchange or Hep C case management food bag)
Yes
No
{% if client_id %}
{% endif %} {% if encounter_string %}
{% endif %}
Submit
{% if encounter_string %} {% else %} {% endif %}


This week we are going to discuss Inheritance and Composition!
As we all have began to notice, writing Ruby code for different real world situations usually entails creating new classes. These classes vary in function, but all include definitions which delineate what the class will do. While each class that we create will differ from another, often times these classes have methods in common. Instead of having to re-write each of the methods, it would be great if we could start out defining a class, and then let other classes use all of those defined methods, as well as any other methods that we want to create for them.
Well wouldn't you know it, Ruby has given us that functionality. With inheritance we can use one class as the “Parent” class, and let all of the child classes, that we create secondarily, inherit the methods defined in the parent class. We can still define additional methods for each of the child classes to use alongside those they have inherited.
Ok, enough talk, let's see this inheritance stuff in action.
class Parent
def to_inherit
puts "I'm the PARENT"
end
end
class Child < Parent
end
mom = Parent.new
daughter = Child.new
mom.to_inherit => "I'm the PARENT"
daughter.to_inherit => "I'm the PARENT"
Did you see that, with the (<) symbol we were able transfer the methods we defined in the Parent class to the Child class. Now when we call the to_inherit method (that we defined in the Parent class) on our instance of the Child class, the method works and we get an output of "I'm the PARENT”.
You can also override methods in the Child class that were previously created in the Parent class. Check this out:
class Parent
def override
puts "PARENT is here"
end
end
class Child < Parent
def override
puts "Move over Parent, CHILD is here now!"
end
end
mom = Parent.new
daughter = Child.new
mom.override => "PARENT is here"
daughter.override => "Move over Parent, CHILD is here now!"
You see, we changed the override method for the Child class, which altered the result that we got when calling it on our instance of the Child class, but not on the Parent class.
Now as we know, there is never only one way to do something in Ruby. Thus, another way to let classes inherit from each other is with something called Composition.
The inheritance entails an is_a? relationship. Basically the Child class is_a Parent class. This can be useful, but when our programs start to get more complex, this is going to relate in a lot of similar coupled classes. Instead, we might try using Composition. Composition functions on a has_a? relationship. Child will have some of the functionality of Parent, but also be its on entity. Composition re-uses some shared logic from another class by creating an object of the other class and calling its methods. Let's see composition in action
class Other
def to_inherit
puts "I'm from the OTHER class"
end
def override
puts "OTHER is here"
end
end
class Composed
def initialize()
@other = Other.new
end
def to_inherit
@other.to_inherit
end
def override
puts "Move over Other, CHILD is here now!"
end
end
new = Composed.new
new.to_inherit => "I'm from the OTHER class"
new.override => "Move over Other, CHILD is here now!"
Initializing the Composed class by creating a new instance of the Other class, allows us to use the methods created in the Other class within the Compose class.
There you have it, you are now equipped with two ways to create classes by re-using methods from previously defined classes. Now go off and practice using both!
melissawimberly signing off...


Complexity
“Easy to use is easy to say, but
hard to do”
Jim Allchin – 9/4/97
While I think everyone acknowledges that our software and PCs in general are hard to use, I don’t think the magnitude of the problem is understood at all. No other consumer product in history has been so hard to use and so fragile. Yet computers and software have continued selling despite this. It is an amazing testament to all the benefits that personal computers bring that consumers are willing to put up with the vast array of associated problems.
All of us have our horror stories about spouses, neighbors, family members, ourselves where we wasted a weekend (or longer!) trying to get something to work. We are supposed to be experts, but even we can’t get things to work properly. (Any one who gets ISDN working without getting help from someone else deserves an award.) It is a total embarrassment. Craig Mundie said to me recently that he never touches his machines in his home except at the beginning of a weekend because it knows it might take the entire weekend to recover from whatever goes wrong.
What is fascinating is that when you talk to average users, they assume that they aren’t smart enough or that they are doing something wrong when the computer doesn’t work properly. However, if those same people were dealing with other consumer appliances, they would more than likely say that the appliance was designed wrong. There is even a culture growing dealing with “idiots” and “dummies” that have to work with computers. This is an amazing social phenomenon. Eventually consumers will wake up with the equivalent of Ralph Nader taking the lead.
So, is it just that software has gotten so complicated that we can’t make the system resilient and easy to use any more? Is it that the demands for features mean that we can’t focus on naïve users? Is performance or memory size more important than consistent operation? What are we going to do about the hardware companies that continue building unreliable PC products?
Our software is approaching massive size (and internal complexity). NT Workstation 5.0 will have around 27 million lines of code at Beta 1 – and more will be added before it finally ships some time next year. For perspective, the first version of NT only had around 6 million lines of code. In my view however, the size of the system has nothing to do with whether the system can be made resilient or easy to use. In fact, more software is required to make systems consistent and more reliable; it just has to be the right software.
Our products are becoming more and more feature rich. We have ways to “tweak” virtually everything. The amount of information known publicly about flags/fields stored in the registry and how to tailor aspects of the software is amazing. We present user interface dialog box tabs covering technical features that only a miniscule fraction of all users will ever need (or understand). You could argue that this is great --- it’s a Turing machine, you know – you can customize it to do anything. Unfortunately, we seem to look at these things as a computer geek does and forget about “the rest of us”. On the other hand, we have done some good work in areas where we have added features (e.g., spelling correction in Word) which do not add additional complexity. I believe you can simplify the experience for naïve users and still maintain the flexibility for power users.
What about performance? Is it ok to trade off consistency or reliability for performance? How about trading off consistency or reliability for smaller memory size? Is it ok to make the system super fast most of the time, if it doesn’t operate correctly (or crashes) in some rare cases? Microsoft has a disease dealing with these questions. I have been in many meetings where tradeoffs like this are actively discussed from billg on down. “We could win the benchmark.” “It saves 80K of memory.” This is a travesty. It would be better to not have a feature than have one that doesn’t work consistently 100% of the time.
So the question is: Is it possible to have a set of rules that guide the development of software that is more resilient, consistent, and easier to use? Unfortunately, software is still art and I do not know of any perfect rules, but I do believe there is a philosophy that can be adopted to start addressing our complexity morass. The rest of this paper covers this philosophy.
The thoughts below may seem very obvious. You may disagree with some of them. Nevertheless, I claim that following these rules would result in software order of magnitude less complex and friendlier to humans. The question is why don’t we follow them.
From rec.humor.funny:
|
Multitasking You can crash several programs all at once. No waiting! Built-in Networking You can crash several PC’s all at once. No need to buy Novell Personal Netware or LANtastic to crash. Microsoft Network Connect with other Windows 95 users and talk about your crash experiences. |
PnP Plug and Pray (that it works) Multimedia Experience the immense sign and sound of crashing. Compatible with existing software It will also crash your existing software |
From KISS Software, Rescue Me!  Who wants to boot your TV every few hours?” I could go on and on. Our products have a poor quality reputation.
Quality is about ensuring the system works consistently: every time, all the time. A key metric I think about is crashing. Our software should never crash – period. We ship software today that we know has bugs in it that can crash the system or that has architectural holes that would allow an errant application to crash the system. We are under “market pressure” and somehow are able to convince ourselves that the likelihood of the condition (usually very complicated) occurring is very small and so it is ok to ship the product and fix it in the next release.
The first building block for making a system easy to use is quality. Quality doesn’t make a system easy to use; on the other hand, you can’t have a good system without it. You can have a very hard to use system that has high quality. MVS or VM/CP represent such systems. Once you get one of these systems running they are amazing resilient to hardware and software problems. I spent time with IBM engineers adding code for some of the error recovery paths for VM/CP. Tons of code exists to handle faults in these types of systems. It’s not that these systems were designed correctly. If you changed a line of code you were required to add your initials to the comment field on that line. I would look at pages and pages of BAL assembler code where the comment field of every line had been updated. And not by a single person. In more cases than not, there would be 5 or more initials on the same BAL line. Code (and quality?) by brute force.
So everyone says they support quality (Mom and apple pie, right?). What should we change?
· We should tradeoff compatibility for quality if necessary. At a minimum if we know that being compatible with some feature (from the past) could cause the system to crash or get in some inconsistent state, then we should have an option that a user can select that prevents the compatibility, in favor of stability. Users then have a choice in how the system operates.
· No algorithms should be used which we know a priori could cause the system to fail or enter an inconsistent state. No benchmark, size, or schedule crunch should be allowed to come between quality and us.
· We must ensure that PC hardware doesn’t impede our quality efforts. The classic example here is ISA slots allowing non-PnP cards to be supported. But, it goes beyond this. We need to drive the industry to address areas that are likely causes of consumer issues and faults in the system. An example here would be the fact that PC-Card (or PCMCIA) devices can be removed without warning from the system. That’s like being able to rip a CD out of your audio system while it is still moving and playing. If we want to improve the experience for end-users, we must focus on improving the fragile hardware we have today in PCs.
Ok, suppose the system doesn’t crash. But, does it recover gracefully from problems? Resiliency is about having the system recover automatically from environmental issues (e.g., server going away, DHCP server not found, etc.) or common user mistakes.
This takes a very specific designer mindset. You have to assume that if something could go wrong, it will and then program defensively for these problems. Too often I find designers programming for the case when everything works perfectly. When an error occurs, they simply give up, spew an error message to the screen, and return an error message to their caller (who of course does nothing with the error except return it to their caller, etc.).
Networking is perhaps the area where this is most visible. Our networking code is extremely fragile today. Virtually any problem (lost packet, server not responding after we have a connection to it, configuration error, etc.) either makes the system totally unresponsive (with no indication to the end-user what is going on) or worse yet it actually stops working correctly. This lack of resiliency is a problem for the operating system (e.g., networking errors during authentication, etc.), but it’s also a problem for applications such as mail, calendar, chat, browsing, etc. No other peripheral is more error prone today than the network. It takes special designs to deal with this.
 There is no disk activity; no screen activity; nothing. But, you can’t do anything since the application or the operating system is “locked up”. This is because the software isn’t handling the network (flakiness) correctly. The network will continue to be very error prone (e.g., different delays, outages, errors, node failures, etc.) for quite some time in the future. Moreover, the fact that we want to be mobile moving between wireless cells or connecting between very different speed networks means that handling networking resiliency must be a top priority for us. Architecturally, we need to learn about network errors in a standard way and then avoid multiple timeouts, nested retries, etc.
We do have parts of the operating system that are more resilient today than other parts. One example is scandisk that automatically “repairs” the system if there are disk inconsistencies detected. The issue today is that scandisk may not correct the problem totally. In fact, it could delete a critical file. Still it is better than not doing anything. Assuming that we must have a utility like scandisk (because of the file system design) we need to ensure that upper levels of the software can recover from perhaps poor deletion choices that scandisk might make. (Furthermore, as noted later, if we have to have scandisk utilities, they should run silently without introducing the user to any bizarre terminology or operational choices.)
Resiliency is about keeping the system running at all costs. An example of this is that if the NT 4 shell (or IE 4 shell on NT 5) dies, the desktop disappears for a second. But, the operating system restarts the shell quietly in the background. The system is resilient to shell faults. This is not the case with win95 or win98.
Ways to improve resiliency:
· Auto-configure. Do not let the user configure things. Networking is one of the most complicated areas of our system. Asking a novice (or even an “expert”) to configure a protocol stack is like asking a layperson to do surgery – it takes training and even then they sometimes make a mistake. If you can't auto-configure, then the system should probably be redesigned so that it can be auto-configured.
· Assume a machine is transiently connected to the network. Never allow the user interface to be stopped by a network outage. Switch gracefully (but visibly) from network mode to offline mode.
· Once an error is detected (e.g., network timeout), it should be sensed only once. That is, at most one timeout should happen until there is good communications established again.
· Design for error cases even if it means the regular operation of the system is impacted slightly. A good example here is out of disk space. Assume you run out of disk space at the worse possible time. Will the system still function correctly? Can the user still remove some space? If it takes allocating some free disk space as a buffer during normal operation (to ensure that the system is still totally functional) then do it.
For some strange reason we insist on trying to teach people a foreign language: geektalk. My Mom doesn’t want to learn another language right now. She just wants to track her church work, write letters, exchange email, track her budget, look for things on the Internet, etc.
Geektalk is actually one of our worse sins in interacting with a user. Our systems tend to produce more internal information than a user needs to know and in doing so we use terms that only a computer literate person (and in some cases programmer) would understand.
Turn on (note a naïve user thinks a “boot” is a shoe) any PC and just watch the words/characters fly by.
24576 KB OK
SystemSoft BIOS for Opt Viper 557/508N 1.00 (2450-35) (Version 01.11)
SystemSoft Plug-n-Play BIOS
<F10> to enter Computer Setup
Oh, I see…
Now of all of the above, what do you think a first time user has to know? What terms would they know? Why do we insist on telling a user all these things? I believe it is because the system is basically in debug mode all the time. We never know when a user might have to know the internals of the system to deal with a problem.
When our software starts running we are even worse. I can’t even begin to represent the insane number of terms we use. We use terms such as “FAT32”, “clusters”, “defragging”, “DHCP”, “DNS”, “WBEM”, “WAN Mini-port”, “ODBC”, “enable IP forwarding”, “bindings”, “NDIS Proxy TAPI Service Provider”, “Video Compression Codecs”, “Device Tree”, “devmgmt”, IRQ, DMA, “Launch Internet Explorer Browser” (launch?), “Insert ActiveX Monitor Control”, etc.
And our error messages are nothing short of amazing. Consider these error messages from NT 5:
· No IPSEC Policy DN.
· {A79C9582-19D1-11D1-91C7-C4252BDEA3A4} : Could not find an adapter.
· The Net Logon service terminated with service-specific error 3095.
· No Windows NT Domain Controller is available for domain NTWKSTA. (This event is expected and can be ignored when booting with the 'No Net' Hardware Profile.) The following error occurred: The RPC server is unavailable.
· Illegal instruction
· And on and on.
When a TV is sold the manufacturer doesn’t have to explain how to read the color bands (detailing resistance) on some resistor that is used. Why do we insist on trying to make computer people out of everyone? We are still making software for the hobbyist. We need to make software for the consumer. Do we want the user to debug the system? Is our software so unreliable that we have to be in pseudo debugging mode all the time?
Of all the issues raised in this paper, reducing information dumping and simplifying/removing terminology is the easiest to change. Every product should have a glossary of terms that is used throughout the product. We can introduce new (computer) concepts to end-users, but they should be done with great care. Developers and user education (e.g., help, documentation) should only communicate using layperson’s language and the approved glossary.
One other key point is that some areas of a product might require more advanced knowledge and therefore a richer set of terms. In this case there should be an advanced button (or tool) that permits access to these terms (otherwise they are hidden). In general though these advanced dialogs should be avoided. Why? Because having the concepts exposed at all makes it hard to avoid having some error/information message pop out at a naïve user (e.g., “can’t renew IP address because DHCP server is not responding”). It would be far better in my view to have a command line utility that adjusts certain parameters (as in debugging mode), then have this information exposed in a general UI. Then we would never have to even explain what something like a DHCP server was to an end-user.
Lack of consistency is a key problem in our user interface and our underlying conceptual model. Humans are amazingly adept at dealing with ambiguity and inconsistency – but only up to a point. Much of learning is about understanding rules. If A, then B. Anyone who programs knows that deep nesting of if/else statements is very difficult to debug. In every day life it is no different. If you have to memorize one exception after exception, it is very difficult to not make mistakes unless you are living and breathing the environment constantly. Teaching someone about the system deals with teaching him or her about the rules. You want the rules to be very simple: if you do this, then that happens.
Our systems have tons of footnotes on how it works. Let’s look at some examples.
Inconsistent drag-drop. When you drag a file from one place to another, it would seem reasonable that the file will be moved, not copied. That rule is not correct however. If you drag a file on the same disk, then the file is moved. However, if you drag between disks, the files are copied – not moved. If you drag an EXE, then a shortcut is created, and the file is neither copied nor moved – that is, unless the destination is a removable drive.
Tray. This area on the screen doesn’t seem to follow any rules. It holds mostly icons except for the clock that is. Some icons get double-clicks, some get single-clicks, some get right-clicked, and some don’t get clicked at all. Some icons have tool-tips, others don’t (it depends on whether the application window is selected or not). With IE 4, there is yet another area on the tray that operates totally differently than the other tray components. It is magic.
Shortcuts. Shortcuts are very inconsistent since they are not supported through win32 APIs. Shortcuts are kludges done on top of the file system. The result? Terrible inconsistency. Whether a shortcut is linked to a file or a folder, it is always treated as a file. Specifically, you can’t specify a shortcut to a folder in a path. So, shortcuts are “sort of” transparent, but not always.
We should not be rigid about consistency. There is a higher level principle of familiarity (with real –world objects/tasks) that I think is even more important than consistency across all aspects of the system. Nevertheless, we are not consistent enough today in our systems. We use different terms for the same task, object, etc. in different parts of our system (e.g., Emergency Recovery Disk). We need fewer concepts defined and few ways to do things. Concepts that we introduce should be consistent unless there is a overwhelming reason not to be.
A key to allowing people to learn something quickly is to build on prior knowledge. We need to maximize the concepts and techniques in our products that users are familiar with from their real world experiences. The first time someone uses an automated washbowl, they look curiously around the sink for handles. Once someone explains how it works or they discover how it works independently, then from then on they will intuitively try putting their hands under the nozzle if they don’t see handles. Of course, in some countries the water flow is controlled through foot petals. And someone who is used to automatic washbowls will be surprised when the water doesn’t come on. (I know because this happened to me.) The point is that once someone learns something they become familiar with it and expect it to be the same in a variety of situations.
Our user interface and our conceptual model should attempt to model within reason tasks or objects that people already know. If there is an analogy that exists outside the computer realm that a culture understands we should use it in our systems. A good example of this is highlighting in Word. This is something that virtually all people are familiar with. Using yellow as the default and calling the feature highlighting is easy to understand for most everyone.
Designers should not force fit metaphors if the computer operation isn’t a close match to the real world. Strong metaphors (e.g., phone) need to behave as much like a phone as possible – because users really know how a phone works and they will map their knowledge appropriately onto the computer interaction.
When I am writing a letter, I am writing a letter. I usually don’t want to deal with anything else. A new mail indication might interrupt me and I might switch to reading mail, but that is no different than being interrupted by a phone call. In both cases, though I am doing a single task. This argues for more full screen activities focused on single/related tasks and less window management.
I strongly believe in virtualized User Interfaces that map to particular tasks that a user is currently doing. However, more investigation is required to really understand the right level of virtualization. It could be at a macro level: entertainment, office work, programming, etc. Or it might be more granular: home financials, music composing, correspondence (e.g., letters, faxes, email, voice, etc.), watching TV, etc. The reason I think this makes so much sense is that it allows us to create a more familiar environment for a user and still let the user switch from task to task. Further, I think this task-based view is much closer to the way average users work (e.g., I need to write some checks and see where the portfolio is today).
Without a doubt, the best computer concept is the concept that you don’t have to invent (because it already exists in the real world).
We seem to clutter everything. We clutter the desktop. When was the last time you opened the “network neighborhood”? Yet it is on the desktop of probably 100 millions machines. We clutter menus. Look at the cascading menu after menu off the Start/Programs area. We clutter toolbars. And on and on.
We have so many tab dialogs for some functions that we created multi-row-tabbed dialogs. Some of these tab dialogs are amazingly complex. (By the way, the fact that the tabs all change positions when a back-row tab is clicked is extremely confusing and difficult to use.) We should only include a function in the system if a large number of users need the function. Basic functions should be immediately apparent – not masked by reams of options that most customers will never use.
The Administrative Tools folder (off the Programs Start menu) in NT 5 Workstation Beta 1 is a classic example of not designing for the bulk of users. It is more complicated than NTW 4 – which was already much too complicated for the average user. Most users just never need to know about most of these functions. In addition, the current user interface is designed for a computer expert. We have to change our mindset totally here.
We can make systems much smarter than they are today. I think some of the intelligence in the office applications is quite good. There is no equivalent of this in the operating system however. Simple heuristics go a long way. For example, if we can’t sense a network adapter, then we shouldn’t have timeouts and we shouldn’t ask the user anything about a network. We should automatically reconfigure the system. Suppose we do find a network that is operating, but if we can’t find a DHCP server, then we should be able to automatically assign an IP address. If a DHCP server comes back online, then we should automatically switch to the right IP address. If someone is looking at a help topic, then we should be able to step him or her through the tasks to address their question. We should be using as much automatic and dynamic self-configuration as possible. The system should be viewed as a true organism that is constantly adapting to its surroundings (usage, environmental changes, etc.).
Still, simplicity is about more than just being smarter. I expect that most early users believe that Office is quite complicated. Why? Because Office doesn’t ease a user into using the product --- starting with the basics and gradually expanding to richer and richer power. My Mom was overwhelmed when I first introduced her to Office. She now has a limited set of functions that she knows and she tries to avoid deviating from them.
I believe that user interfaces need to be scaled. The scaling can be done in many ways. The most naïve way to do this is to only show the basics and then create an advance area(s) where the “pros” go. Another technique is to have toolbars not show up by default. Another more high-tech approach is to track which features/functions a user does frequently and slowly evolve the interface to favor/highlight these functions. We must really improve in this area in the future.
 They simply cover up the complexity that exists in the system. If a wizard fails for some unplanned reason, the user is dumped right back in the underlying complex system. If the underlying system weren’t complicated, then probably a wizard wouldn’t have been needed in the first place. A wizard might be useful in certain multi-step interactions with the system, but in general they could be avoided if the system was simpler and smarter.
In short, I think we need ways to scale the UI from simple/basic operation to more advanced operation. We need the system to be more automated about configuration and learning what a user uses and might want to use. And we should hide (or totally remove) clutter that is in everyone’s face unless the bulk of naïve users will use the function.
If you delete an icon on the desktop, what do you think happens? Does the object really go away? You would think so – it’s the obvious thing – after all you deleted it, right? Well, it depends on the object. In some cases the entire object goes away (e.g., spreadsheet – assuming no links!), but in other cases only portions of the total object goes away (e.g., program executables). Some programs today have icons on the desktop, menu items in the Start menu, tons of files somewhere on the disk, and a series of registry entries (sometimes dispersed in several areas of the registry). The obvious thing just doesn’t happen when you delete objects. In fact, our inconsistency concerning deletion is one reason why most user’s disks are full of unnecessary files; the user thinks they were already deleted!
The system should never pretend to do something transparently if it can’t do it perfectly 100% of the time. The cancel button in the browser is a great idea, for example. It is horribly confusing when the system tries to hide something that ends up showing up in certain failure cases. Better to let the user participate in the environment in this case. It is much more obvious this way. The conceptual model then is the same for the user and the computer. Another example deals with Intellimirroring. We should NOT hide the fact that there is a difference between a user who is connected vs. standalone. Trying to pretend like there is no difference will clearly not work and the user will be surprised at random times as the transparency fails.
Tasks that users perform frequently or would likely have to do at some point should be very discoverable. It is critical to understand a prioritized list of tasks and optimize the obviousness of these. The operating system is a mixed bag today. An example of a big improvement is the Small Business Server. But, in general, our usability is very poor across our products. I don’t think we ever generated such a prioritized list for the operating system. If we had, then things like configuring and accessing Mail (or fax) would have been much simpler than it is today. Designers must be very hardcore to ensure that the ease of use for the key tasks is not undermined.
As an example, consider Backup. Where should the program item and/or icon be placed? Should the dialogs give the user lots of power through many choices (incremental, scheduled times, particular files, job definitions, etc.)? The obvious task the user wants to do is to simply backup the system (or restore a file). Any design that doesn’t make this task extremely obvious and easy is failing at this design principle.
Users should be protected from making errors. This seems obvious enough. We do some of the easy things today (e.g., have a recycle bin, reconfirm a deletion or format, etc.). But, we do virtually nothing to provide any safety for the system as a whole. Users can make a machine non-bootable in less than 10 seconds. They can stop networking from working in 10 seconds. They can break an application in about 10 seconds.
We should never allow a system to be put in an unusable state unless the hardware has failed. Today, we have several problems. First, we let people metaphorically play with the integrated circuits of the software by being able to play with system files loaded on the disk. By system files I mean any component of the system that is used in the standard operation of the system. There is no reason for this. There is no reason anyone except a programmer needs to know anything about these files in the system. They should not be able to be seen, deleted, moved, renamed, or tampered with in any way. Drivers (or other system components) should be signed and a user should explicitly agree to use a driver (or other system component) before they can be installed. There should not be any way to partially remove or install an application.
Second, we need to ensure that manual configuration operations (hopefully over time there should be fewer and fewer of these) cannot put the system in an unusable or non-recoverable state. If a manual configuration could make some part of the system (e.g., hardware device, network connection) stop working, then the user should be strongly warned about the danger of the proposed change. We should attempt to make significant changes a single step UI operation so that we can detect the danger easily. In contrast today, configuring a dial-in line requires multiple steps in different areas of the UI with reboots in between. Obviously mistakes are easy and restoring the system to the way it was before the configuration started in very difficult. A global undo is a good idea. In addition, issues arise when something is reconfigured (e.g., deleting an ISDN board) where we leave partial bits of information around that confuse the system. When something is deleted, every trace should be removed from the system. There shouldn’t be any information in the registry, file system, or user interface associated with the deleted entity. In general, reversibility would build confidence for users to try new things since they would know that they could reverse any bad decision they made.
Having an overall default mode for everything in the system is also a good idea. This is a mode that lets the system operate no matter what, albeit perhaps not as customized as the user might want.
Personal computers are about being “personal”. That means it is critical that users be able to customize the interface they use to the computer – just like people customize/decorate their cars, homes, and desks at work. Personalization can help make the system feel comfortable and familiar.
This is an area where we need to do a lot of work – especially when a computer is shared. Today, we confuse per machine and per user state frequently. We need to be able to customize very clearly for each user --- as well as make it easy to reset the environment to an overall default state for a new user (e.g., family member). Further, it is important that this personalization be moveable easily from one computer to another.
1. Data integrity or crashes must be ship stoppers.
2. Gracefully support all known failure conditions. Program defensively being prepared for these failure cases. Given the complexity of the system, don’t expect administrators or the end-user to figure out what the problem is. You (the designer) have more knowledge of what to do than anyone else does. The probability of having a human make the situation worse is very high.
3. Test all limit cases – e.g., disk full.
4. Do not permit a user to change anything that could cause the system to crash (e.g., registry). Do not give a user access to internal parts of the system that should be hidden.
5. Do not use computer terms (e.g., DNS, DHCP, FAT32, scandisk, DLL, etc.) when communicating with a user. THINK like someone who has never seen a computer before. Create and use a glossary of terms for the product. Error messages should only use terms from the glossary. (The “repair” person should have some means to get more diagnostic information.)
6. Make concepts shown to the user work consistently in all cases (e.g., shortcuts).
7. Avoid configuration if at all possible (e.g., make systems auto configuring by sensing the environment: memory size, network condition, etc.)
8. Do not show error messages to users unless they can specifically do something about the problem. The system should recover from the problem automatically or simply stop working so that a “repair” person can diagnose the problem.
9. Make the 90% case the design center. Ensure that the basic top 10 tasks are obvious.
10. Integrate resolution of a user issue with the Help system.
11. Assume that the network is error prone and transient.
12. Create scaleable User Interfaces where a user can be slowed exposed to more power, but can start their experience in a simple, non-threatening mode.
13. Avoid wizards that simply cover up the complexity of the underlying system.
14.  And match the semantics of the real world as closely as possible. If a new concept is required, then ensure that it is defined and use consistency throughout the product and documentation.
15. Design per user capabilities in the product from the start so that easy personalization is possible.