I thought about counting pulses over a certain period and sending that result to the computer, but... If a pulse happens right when the information is sent and the count is restarted, I will lose that pulse. I know it may not seem like much, but say 10 pulses per day lost, that is ~300 pulses per month which is 3000 watt hours lost.
You can design around this, though. The classic method would be to use locks, and two processes. One process (cog) reads an IR flash, checks out a lock, increments the hub value, and returns the lock. The other process waits until it's time to transmit, checks out a lock, reads and clears the hub value, returns the lock, and transmits the value. No pulses lost.
Unless the pulse rate is very high (100's to 1000's/sec) there is very little chance of missing a pulse. In fact depending on how long it is, you may have to be careful that you don't count it twice. If you have 2 processes the count process checks for a pulse, adds one to the count if there was a pulse, transfers the count to the send process and zeros the count if the time is up, and repeats the loop.
A 200 Amp service provides 200A at 240V. That would be a maximum of 48,000 watt hours per hour, 800 watt hours per minute, or 13.33 watt hours per second. If it is 1 watt hour per pulse that would be 13.33 pulses per second. If it is 10 or 100 watt hours per pulse it would be 10 or 100 times slower. A simple counting process running on it's own cog could easily do that and never miss a pulse.
Sounds reasonable I am trying to learn about timing right now. I would like to set the serial output to once per 5 seconds for testing purposes. Probably would be best for a new cog, but I have been out of prop programming for too long and have forgotten how to start cogs and process variables between them
I need to make sure I understand the watt per hour thing....
If each pulse is 100 watt hours this means that if there were 1000 pulses per hour, I would be using 100,000 watts used in 1 hour. Is this correct? If this is the case, I am getting on average around 45 pulses per 30 seconds with the AC running. This would be 90 pulses per minute which is 5400 pulses per hour. That would be 540,000 watts used in that hour which comes out to 540 kw which is what really confuses me.
For some reason Watts and Watt hours is confusing me. Could someone help me out with this?
540kw sounds a bit much. Maybe out by 1000 - if say you had just the fridge running it is more like using 540W. Maybe go round the house and turn everything off and see what it is then?
If this is the case, I am getting on average around 45 pulses per 30 seconds with the AC running.
Is that what you are calculating or what you are measuring?
Addit: I just went out and checked my meter. It probably is different to yours but it has a led flashing about once every 2 seconds, and next to that are the words "1000 imp/kilowatt hour". So that is about 30 pulses a minute, and so roughly 30 mins to do 1000 pulses which means I am using about 2 kilowatts which would be about right with the reverse cycle going.
I am measuring the IR pulse from the "Smart" power meter outside my house. I have read that each pulse is 100 watt hours. I am trying to convert that to watts used at the current time along with getting peak wattage, low wattage, and an average over an hours time.
olddata is the last number of pulses counted send by the prop.
receiveInterval is the time the prop counts the pulses between. Currently set at 10 seconds
I am currently getting 4 pulses per 10 seconds which comes out to 2400 watts or 2.4kW. I am seeing 2400 as the output in my VB program.
The only things running are 1 light, 2 computers (one running the DVR system), small window AC in my shed, the electric water heater, the fridge, and 2 ceiling fans.
I guess to double check you could turn everything off, then turn one thing on with a known consumption (eg a fan heater) and check the pulses.
Hmm - only problem there is you need your computer on to measure it. Ok, measure the computer first by itself. Might be 200W or something. It probably won't be changing much.
Well, I have decided to go another route that I think will be much more accurate for shorter read times like I am trying to do. Currently, I am just counting pulses over a 10 second span. For my reading, I am getting basic numbers like 1200, 1800, 2200 which will not show changes based on a few lights that I may add motion sensing to turn them off when no motion is detected. I am hoping to get it much more accurate than what I have right now by using the waitpeq function and timing the distance between pulses. Problem is I don't understand how to get a result back in millisecond results. Could someone help me with this?
Here is my code to time the distance between each pulse :
PUB PulseCounter
ctra[30..26] := %01000 ' Set mode to "POS detector"
ctra[5..0] := 1 ' Set APIN to 17 (P17)
frqa := 1 ' Increment phsa by 1 for each clock tick
dira[Sensor]~ ' Pin to input
repeat
waitpeq(%000000, |< 1, 0) ' Wait for pin to go low
phsa~ ' Clear the phsa register
waitpeq(|< 1, |< 1, 0) ' Wait for pin to go high
pulsewidth := phsa
'waitpeq(%000000, |< 1, 0) ' Wait for pin to go low
Ok, I am lost I cannot get a steady result from any code, nor can I get the milliseconds between each pulse. I don't want to skip a pulse by waiting for a high, then a low, then a high again since that would throw off the true data and my results would for sure differ from the electric company's information.
The difficulty is that what you are trying to do is next to impossible. Going back to my previous post (#37) what you are trying to do is to measure a change of 60W (or 60Whours) in a system that has a maximum of 48,000W (or 48,000Whours), and in a noisy environment to boot. That's 60/48000, 1/800, or a 0.125% change. Even lower if you are using CFC's.
If you really want to see things at that low a level you will need to put a current transformer on the individual circuits to measure the current and calculate the watt hours. If all you want is to see when a circuit is drawing current you could use a toroidal inductor instead.
Simpler to stick with an average over a period of time.
So counting the time between pulses is not possible with any kind of accuracy? I have an LED that blinks each time the IR sensor blinks outside and it seems pretty steady. What if I took the output of the LED pin and jumped it to another which gave me the HIGH and LOW reading instead of trying to read it directly from the IR signal? An accuracy of +/- 400 watts makes this project useless so I need to get the accuracy as close as I can to what my bill should show. I am sure counting the pulses over a longer period of time will show better results, but can the Prop "wait" that long accurately using this : waitcnt(clkfreq / 1000 * CountDelayInMS + cnt)?
I thought of something last night in a dream (I am cracking up starting to dream in assembly!). The propeller is perfect for this. Set one cog to measure the pulses and set another cog to handle the data transfer. The cog measuring the pulses will never miss one because that is its only job. You have a super accurate timer so all that cog does is wait for a low to high transition on a pin, then record the exact time on the counter into a circular buffer that you set up in hub. The transfer cog will be reading this same buffer but its timing is not so critical, and it could probably be all spin if you wanted. There will be a list of longs there corresponding to the times. If head=tail, no new data. If it goes off to transmit a block of times via a serial port, and maybe head gets ahead of tail by a few longs, it does not matter. You will never miss a pulse, and with the timing being so accurate, you can time those pulses down to microseconds and I think get the accuracy you want too.
As for writing the code, hmm, maybe break it down to bits and ask on the forum. eg pasm code to read the time when a pin changes and place that in a buffer in hub. Hopefully someone will chime in.
I have a bit of code I have written and it counts successfully, but I can't seem to figure out how to convert the result to a millisecond result. Here is the code I am using currently :
The pulsewidth variable is the result. The accuracy seems pretty good viewing the past 100+ results sent via serial. Would the result be divided by 80(mhz) to get milliseconds?
Use the propellers clock in spin. It will be different code, instead of having a counter, you are waiting for the pin change then reading the internal counter. Just watch when it cycles from 2^15 to zero about every 30 seconds - you need a difference between the current value and the previous value.
psuedocode
repeat
wait for low to high
counter2 := counter1 ' store the previous value
counter1 := cnt ' get the new value
difference := counter1 - counter2
store difference
increment head
I tried doing that but I kept getting several glitches over a period of time where the time would jump from say 123456 to 7, then to 189, then to 40000. The time was extremely inconsistent. The way it is now, it appears to be staying pretty steady which is the first time I have been able to keep a steady result. I have been watching the output for over 10 minutes without a single glitch.
I assume you are referring to using the phsa and ctra as I was using before. This was a pain to work with since I don't understand what clock cycles are nor do I understand what Us unit of time is. Like I have said before, I know enough to be dangerous!
* EDIT *
I have also tried the CNT - old CNT method which was really confusing and not accurate IMO. I think it could have been due to my coding though since I have changed the way the sensor is read many times. I still don't understand how to convert the prop clock to milliseconds.
Am I doing something wrong in the above code? I have a hard time learning by reading instructional documents since I have always learned from reading working code and dissecting it to learn the steps and how the process works.
PUB PulseCounter
'ctra[30..26] := %01010 ' Set mode to "POSEDGE detector"
'ctra[5..0] := LED ' Set APIN
'frqa := 1 ' Increment phsa by 1 for each clock tick
count1 := 0
repeat
dira[LED]~~
outa[LED] := 0
waitpeq(%000000, |< 1, 0) ' Wait for pin to go low
waitpeq(|< 1, |< 1, 0) ' Wait for pin to go high
count2 := count1 ' store the previous value
count1 := cnt ' get the new value
pulsewidth := count1 - count2
outa[LED] := 1
A bit of googling reveals that the physical standard for the infrared port, in the USA at least, is ANSI C12.18, and there are higher level data protocols coming in ANSI C12.22.
You noticed at first that there seemed to be multiple flashes rather than one single flash at each interval. Maybe that was when you were looking at it right at the meter. If you have the photodetector way out on the end of a cable running through your basement, all the fine structure may be washed out. It may also be subject to all sorts of noise pickup that your program might detect. This is the sort of thing that an oscilloscope is useful for, to visualize the signal you are trying to count. There may be a lot more going on than the simple regular pulse you are expecting.
If your clkfreq is 80MHz, each tick of cnt represents 12.5ns. So if you get a count of 6016, that represents 6016 * 12.5 = 75200 nanosecond = 0.0752 millisecond. Clearly too fast for you to see as an individual pulse! And
935392 * 12.5 = 11692400 = 11.7 millisecond. So, something is going on and you are either detecting details of the comms protocol, or noise. The code you have is very sensitive to transitions. It seems the pulses on the order of 1 second are not showing up.
I went back to adding a counter to the code and it still seems to be reading pretty accurately. I am not sure if I have my math correct to read the wattage, but it is staying pretty steady based on usage.....when the AC kicks on, the light blinks faster and the wattage goes to around 6000 watts according to my formulas. Here is my current code :
Private Sub Timer1_Timer()
Do
incomingdata = incomingdata + "" + MSComm1.Input
DoEvents
If MSComm1.InBufferCount = 1 Then Exit Do
Loop
End Sub
Private Sub Timer2_Timer()
Dim olddata As String
olddata = incomingdata
If (Val(olddata) <> 0) Then
pulsecount.Caption = olddata
incomingdata = ""
currentWattage = ((60 / (Val(olddata) / 1000)) * 100) * 60 ' Formula : (60 seconds / (milliseconds / 1000) * 100 watt hours) * 60 minutes = watt hours / watts being used?
currentwatts.Caption = Format((currentWattage / 100), "#0.00")
End If
End Sub
Yes, what Tracy Allen said. It is the same problem as debouncing a switch - as the signal transitions from low to high it may bounce around a bit. Two options come to mind. You can build a schmitt trigger in hardware to give a clean signal. Or, you can do it in software. I presume low is no led, and high is led on? If so, wait till the low to high transition, do the readings, then go off and do a delay for a few milliseconds.
PUB pause1ms(period) | clkcycles
'' Pause execution for period (in units of 1 ms).
clkcycles := ((clkfreq / _1ms * period) - 4296) #> 381 ' Calculate 1 ms time unit
waitcnt(clkcycles + cnt) ' Wait for designated time
Opps, I missed a value, in my code in post #56 the value of _1ms is 1000. Which I think means your code is around 5ms delay. (the extra numbers in my code reflects the delay in spin needed to read cnt). If you want to be certain of the delay maybe
PUB pause1ms(period) | clkcycles
clkcycles := ((clkfreq / 1000 * period) - 4296) #> 381 ' Calculate 1 ms time unit
waitcnt(clkcycles + cnt) ' Wait for designated time
And 5ms should be fine (very unlikely pulses are every 5ms otherwise you are using a lot of power!).
The values are very consistent so far. I think I have it returning the milliseconds between pulses but I don't have a way to see how accurate it is besides a watch. From what I can tell, it is pretty accurate. If the LED stays off for 4 seconds, I will get a value back of 4000.
I need to figure out how to convert this to current watts used and watt hours used. The whole watt hours thing has me confused.
My meter tells me it flashes 1000 pulses per kilowatt hour. One kilowatt hour is 1000 watts over 1 hour or 1000 watts in 3600 seconds. 1 watt is one joule per second. So 1 kilowatt hour is 3600000 joules. I calculated that but you can look it up on the internet anyway.
So that tells me that on my meter one pulse is 3600 joules. If it happened to be pulsing once a second, I'd be using 3.6 kilowatts. Once per four seconds is 1/4 of that, so 900 watts. That is a semi-plausible number, probably more plausible than 90 watts or 9000 watts. I wonder if your meter is calibrated the same way?
Addit: just checked my meter and it is flashing about once every 4 seconds too.
Comments
You can design around this, though. The classic method would be to use locks, and two processes. One process (cog) reads an IR flash, checks out a lock, increments the hub value, and returns the lock. The other process waits until it's time to transmit, checks out a lock, reads and clears the hub value, returns the lock, and transmits the value. No pulses lost.
A 200 Amp service provides 200A at 240V. That would be a maximum of 48,000 watt hours per hour, 800 watt hours per minute, or 13.33 watt hours per second. If it is 1 watt hour per pulse that would be 13.33 pulses per second. If it is 10 or 100 watt hours per pulse it would be 10 or 100 times slower. A simple counting process running on it's own cog could easily do that and never miss a pulse.
CON _CLKMODE = XTAL1 + pll16x _XINFREQ = 5_000_000 LED = 0 Sensor = 1 CountDelay = 10 SendInterval = 5000 VAR BYTE countpointer LONG counter LONG counterStack[200] OBJ Ser : "FullDuplexSerial" PUB Main(gear) countpointer := 0 Ser.start(17, 16, 0, 9600) cognew(sendData, @counterstack) repeat dira[LED]~~ outa[LED] := 0 if ina[Sensor] == 1 outa[LED] := 1 counter[countpointer]++ repeat while ina[Sensor] == 1 waitcnt(clkfreq / 1000 * CountDelay + cnt) waitcnt(clkfreq / 1000 * CountDelay + cnt) PUB sendData | oldpointer repeat oldpointer := countpointer waitcnt(clkfreq / 1000 * SendInterval + cnt) if countpointer == 0 countpointer := 1 else countpointer := 0 Ser.dec(counter[oldpointer]) counter[oldpointer] := 0It actually seems to be working
If each pulse is 100 watt hours this means that if there were 1000 pulses per hour, I would be using 100,000 watts used in 1 hour. Is this correct? If this is the case, I am getting on average around 45 pulses per 30 seconds with the AC running. This would be 90 pulses per minute which is 5400 pulses per hour. That would be 540,000 watts used in that hour which comes out to 540 kw which is what really confuses me.
For some reason Watts and Watt hours is confusing me. Could someone help me out with this?
540kw sounds a bit much. Maybe out by 1000 - if say you had just the fridge running it is more like using 540W. Maybe go round the house and turn everything off and see what it is then?
Is that what you are calculating or what you are measuring?
Addit: I just went out and checked my meter. It probably is different to yours but it has a led flashing about once every 2 seconds, and next to that are the words "1000 imp/kilowatt hour". So that is about 30 pulses a minute, and so roughly 30 mins to do 1000 pulses which means I am using about 2 kilowatts which would be about right with the reverse cycle going.
1 KWhr = 1000 watts being used for 1 hour
A 60W bulb kept on for 1 hour would use 60W x 1hr = 60Watt hours
1 watt hour per pulse sounds like a pretty reasonable way to measure consumption so I suspect what you are using is 540Watts.
currentWattage = (100 * Val(olddata) * (60 / receiveInterval))
olddata is the last number of pulses counted send by the prop.
receiveInterval is the time the prop counts the pulses between. Currently set at 10 seconds
I am currently getting 4 pulses per 10 seconds which comes out to 2400 watts or 2.4kW. I am seeing 2400 as the output in my VB program.
The only things running are 1 light, 2 computers (one running the DVR system), small window AC in my shed, the electric water heater, the fridge, and 2 ceiling fans.
Hmm - only problem there is you need your computer on to measure it. Ok, measure the computer first by itself. Might be 200W or something. It probably won't be changing much.
Here is my code to time the distance between each pulse :
PUB PulseCounter ctra[30..26] := %01000 ' Set mode to "POS detector" ctra[5..0] := 1 ' Set APIN to 17 (P17) frqa := 1 ' Increment phsa by 1 for each clock tick dira[Sensor]~ ' Pin to input repeat waitpeq(%000000, |< 1, 0) ' Wait for pin to go low phsa~ ' Clear the phsa register waitpeq(|< 1, |< 1, 0) ' Wait for pin to go high pulsewidth := phsa 'waitpeq(%000000, |< 1, 0) ' Wait for pin to go lowIf you really want to see things at that low a level you will need to put a current transformer on the individual circuits to measure the current and calculate the watt hours. If all you want is to see when a circuit is drawing current you could use a toroidal inductor instead.
Simpler to stick with an average over a period of time.
Tweet-A-Watt-Power-Monitor
In your code above in post #42,
ctra[5..0] := 1 ' Set APIN to 17 (P17)
That specifies pin p1. And
waitpeq(0000, |< 1, 0)
the |< 1 masks pin p1 also.
As for writing the code, hmm, maybe break it down to bits and ask on the forum. eg pasm code to read the time when a pin changes and place that in a buffer in hub. Hopefully someone will chime in.
PUB PulseCounter count1 := 0 repeat dira[LED]~~ if ina[Sensor] == 1 outa[LED] := 1 pulsewidth := count1 repeat while ina[Sensor] == 1 count1 := 0 count1++ outa[LED] := 0The pulsewidth variable is the result. The accuracy seems pretty good viewing the past 100+ results sent via serial. Would the result be divided by 80(mhz) to get milliseconds?
psuedocode
Look up CNT in the propeller manual
I assume you are referring to using the phsa and ctra as I was using before. This was a pain to work with since I don't understand what clock cycles are nor do I understand what Us unit of time is. Like I have said before, I know enough to be dangerous!
* EDIT *
I have also tried the CNT - old CNT method which was really confusing and not accurate IMO. I think it could have been due to my coding though since I have changed the way the sensor is read many times. I still don't understand how to convert the prop clock to milliseconds.
Here is the code :
PUB PulseCounter count1 := cnt repeat dira[LED]~~ if ina[Sensor] == 1 outa[LED] := 1 pulsewidth := cnt - count1 repeat while ina[Sensor] == 1 count1 := cnt 'count1++ outa[LED] := 0PUB PulseCounter 'ctra[30..26] := %01010 ' Set mode to "POSEDGE detector" 'ctra[5..0] := LED ' Set APIN 'frqa := 1 ' Increment phsa by 1 for each clock tick count1 := 0 repeat dira[LED]~~ outa[LED] := 0 waitpeq(%000000, |< 1, 0) ' Wait for pin to go low waitpeq(|< 1, |< 1, 0) ' Wait for pin to go high count2 := count1 ' store the previous value count1 := cnt ' get the new value pulsewidth := count1 - count2 outa[LED] := 1With the code above, this is the result I got :
definitely not accurate
You noticed at first that there seemed to be multiple flashes rather than one single flash at each interval. Maybe that was when you were looking at it right at the meter. If you have the photodetector way out on the end of a cable running through your basement, all the fine structure may be washed out. It may also be subject to all sorts of noise pickup that your program might detect. This is the sort of thing that an oscilloscope is useful for, to visualize the signal you are trying to count. There may be a lot more going on than the simple regular pulse you are expecting.
If your clkfreq is 80MHz, each tick of cnt represents 12.5ns. So if you get a count of 6016, that represents 6016 * 12.5 = 75200 nanosecond = 0.0752 millisecond. Clearly too fast for you to see as an individual pulse! And
935392 * 12.5 = 11692400 = 11.7 millisecond. So, something is going on and you are either detecting details of the comms protocol, or noise. The code you have is very sensitive to transitions. It seems the pulses on the order of 1 second are not showing up.
PUB PulseCounter ' 65825 counts per 1 second count1 := 0 repeat dira[LED]~~ repeat while ina[Sensor] == 1 waitcnt(clkfreq / 1000 * 5 + cnt) outa[LED] := 1 if count1 > 0 pulsewidth := ((count1 * 1000) / 65825) * 2 count1 := 0 count1++ outa[LED] := 0And for the VB output / math code...
Private Sub Timer1_Timer() Do incomingdata = incomingdata + "" + MSComm1.Input DoEvents If MSComm1.InBufferCount = 1 Then Exit Do Loop End Sub Private Sub Timer2_Timer() Dim olddata As String olddata = incomingdata If (Val(olddata) <> 0) Then pulsecount.Caption = olddata incomingdata = "" currentWattage = ((60 / (Val(olddata) / 1000)) * 100) * 60 ' Formula : (60 seconds / (milliseconds / 1000) * 100 watt hours) * 60 minutes = watt hours / watts being used? currentwatts.Caption = Format((currentWattage / 100), "#0.00") End If End Subrepeat dira[LED]~~ repeat while ina[Sensor] == 1 waitcnt(clkfreq / 1000 * 5 + cnt)So far, it seems to be working correctly, but I am still not sure if my math is correct.
And 5ms should be fine (very unlikely pulses are every 5ms otherwise you are using a lot of power!).
Are you getting consistent values back now?
I need to figure out how to convert this to current watts used and watt hours used. The whole watt hours thing has me confused.
My meter tells me it flashes 1000 pulses per kilowatt hour. One kilowatt hour is 1000 watts over 1 hour or 1000 watts in 3600 seconds. 1 watt is one joule per second. So 1 kilowatt hour is 3600000 joules. I calculated that but you can look it up on the internet anyway.
So that tells me that on my meter one pulse is 3600 joules. If it happened to be pulsing once a second, I'd be using 3.6 kilowatts. Once per four seconds is 1/4 of that, so 900 watts. That is a semi-plausible number, probably more plausible than 90 watts or 9000 watts. I wonder if your meter is calibrated the same way?
Addit: just checked my meter and it is flashing about once every 4 seconds too.
So an easier way to calculate the wattage is this formula :
3600 joules per pulse / (4000 milliseconds / 1000 milliseconds in a second) = 900 watts