Hello everyone, in my emontx configuration I am counting the pulses through the optical sensor on the rj45 and reading the temperature through the probe connected to pins 3, 5 and 6 of the terminal board.
Unfortunately I have verified that the optical reading interferes with the temperature reading, I imagine both signals travel on the same channel, at this point.
Did I do something wrong with the connection? How can I fix it?
Thank you
That should not be the case, exactly how do they interfere?
I don’t think you’ve done anything wrong. You don’t have a whisker of wire going to pin 4, which is the alternative pulse input pin? On your photo, I can’t see anything wrong there.
I can believe an optical pulse might upset the timing on the One-wire bus, but in that case the temperature reading should be invalid and it should be ignored.
Thanks for your answer!
The anomaly consists of an increase in temperature at an increase in pulse frequency. If there are no pulses the temperature is apparently correct, around 23°C, if pulses are very frequent it reaches 80°C or more.
In the attached photos there is a detail of the connection:
black on 3 (GND), red on 5 (PWR) and white on 6 (date).
Everything looks good in those photos.
I have checked the “default” sketch for the emonTx, and there is actually no error checking present in the sketch. Why, I do not know.
A temperature of 85 °C is a known error condition. It is the value to which the memory inside the temperature sensor is initialised at power-on (which happens each time the emonTx asks for a reading), and it will return that number if the emonTx asks for the temperature reading but has not asked the sensor to read the temperature (so it has not put the actual temperature into that memory).
I cannot do any tests for a few days, because my emonTx is being used for another test. I will try to replicate the problem, and I’ll post what I find here. It will be possibly a week or more before I can do that.
Thank you, for any help.
The 85°C is just one of the unreasonably high values i get (58, 73, …).
Each time there is an high frequency of pulses the “apparent” temperature rises.
I found a workaround for this by taking the minimum value of the measured temperature in a 5min interval, so that at least a reasonable value is “hopefully” found in any given interval.
I will test this during the week as well and post the results.
Thanks again for your help, please let me know about your tests,
If you have set email notifications in your profile, you should receive an email if anyone posts on this thread.
Which sketch are you using in the emonTx? Alternatively, if it is the one supplied with the emonTx, when did you buy the emonTx?
It’s the Emontx v3.4.3, bought last september
That means it’s the Discrete Sample sketch using emonLib.
I’m working on the theory that the pulse interrupts are corrupting the One-wire decoding of the temperatures. If the pulse rate is high, as @lmssdd has noted, the chance that it will get corrupted is so much greater.
What I am thinking is: trigger the emonTx’s on-board LED and point the pulse sensor at it, that way the optical pulse timing is under software control. We know the timing of the temperature sensor, so by requesting a reading and then pulsing the LED, I think I can generate an interrupt mid-way through the One-wire data stream. If it gives a wrong value, it’s proven. But there’s no solution to that - the sketch cannot anticipate an optical pulse and avoid asking for a temperature when one is expected.
There might be a work-around - there’s a CRC on the data, so why it’s apparently never been used is beyond my comprehension. If it’s corrupt, then the reading should be tried again (up to a limit).
[I’ve stepped through a month’s data from my emonTx running emonLibCM and can’t see a single wrong temperature, though my optical pulse rate is normally very slow.]
I have confirmed your problem. Here is a plot of temperature as recorded by the default emonTx (discrete sample) sketch. LED pulses were provided by another emonTx. At this stage I have not attempted to synchronise the pulse with reading the temperature.
The times of the changes to the “lit” and “dark” periods are listed below. “lit” and “dark” times are in ms.
20:52:11.177 → EmonTx V2 LED flasher
20:52:11.210 → Loaded EEPROM config
20:52:11.210 → Settings:
20:52:11.210 → Lit 30, Dark 106
20:52:11.210 → POST…wait 10s
20:52:11.210 → ‘+++’ then [Enter] for config mode
20:52:36.026 → Dark: 5000
20:53:36.386 → Dark: 4000
20:53:56.537 → Dark: 1000
20:54:29.500 → Lit: 100
20:55:25.592 → Dark: 800
20:59:25.877 → Settings:
20:59:25.877 → Lit 100, Dark 800
20:59:33.974 → Dark: 500
21:04:06.966 → Dark: 250
21:06:59.136 → Settings:
21:06:59.136 → Lit 100, Dark 250
21:07:06.138 → Dark: 150
21:07:13.638 → Lit: 50
21:09:09.636 → Dark: 200
21:09:13.385 → Settings:
21:09:13.385 → Lit 50, Dark 200
21:10:42.140 → Dark: 250
21:10:43.633 → Settings:
21:10:43.633 → Lit 50, Dark 250
21:17:56.834 → Dark: 750
21:17:59.256 → Settings:
21:17:59.256 → Lit 50, Dark 750
It seems that the problem starts when the time between pulses is less than about 800 ms. The time to transfer the data from the temperature sensor is 375 ms, so that accounts for nearly half the time between pulses. It would appear that there’s nothing here to conflict with my initial suspicion, which was that the One-wire interface that retrieves the temperature reading from the sensor, and which is critically time-dependent, is being interrupted by the pulse counting process, thus corrupting the temperature reading.
Reducing the temperature reading precision to 9 bits ( 0.5°C ) gives a reading time of under 100 ms. That appears to have alleviated the problem - it can now accept a pulse rate of 370 ms between pulses (20 ms on, 350 ms off).
This is not a cure - I would need to revisit the temperature reading routines before I could say whether I think anything more can be done.
My next move will be to apply the same test to the temperature routines in emonLibCM, because that handles the process in a slightly different way.
@TrystanLea & @glyn.hudson
Any further comments?
[Later]
And here’s what I get with the test sketch and emonLibCM. It is happily recording the temperature - albeit with some missing data (quite possibly due to an ill-behaved emonTx V3.2 on the same radio channel). The pulse rate is gradually increasing, after 1:04:45 running at 12.5 per second (on for 15 ms, off for 65 ms). The reduction in the pulse rate at minute 45 was when the 100 ms pulse minimum period limited the rate - I had to edit the sketch to set it to zero and recompile to continue. The spikes in the temperature curve are where I held the sensor to convince myself it was still working. Unfortunately, the list of pulse on and off times was lost when I recompiled the sketch.
1 Like
In theory at least, all that 1wire bit-banging code protects itself from interrupts disturbing the timing. For example…
uint8_t OneWire::read_bit(void)
{
IO_REG_TYPE mask IO_REG_MASK_ATTR = bitmask;
volatile IO_REG_TYPE *reg IO_REG_BASE_ATTR = baseReg;
uint8_t r;
noInterrupts();
DIRECT_MODE_OUTPUT(reg, mask);
DIRECT_WRITE_LOW(reg, mask);
delayMicroseconds(3);
DIRECT_MODE_INPUT(reg, mask); // let pin float, pull up will raise
delayMicroseconds(10);
r = DIRECT_READ(reg, mask);
interrupts();
delayMicroseconds(53);
return r;
}
If you’ve got a scope it might be worth probing the 1wire bus to see if the pulses are causing any physical disturbances on the bus.
You posted while I was typing…
It looks like the high level routines are suspect, and the theory is correct. EmonLibCM goes in at a fairly low level and commands a read of all the sensors, carries on for a while while they do the necessary, and then comes back to them and requests the data. It seems the data is getting through just fine, doing that. It’s run at 12.5 pulses per second (as I edited above) and I’m quitting for today. I never actually tested at those pulse rates, so I’m pleasantly surprised. I’ll try to break it tomorrow, and see just where it fails.
1 Like
Continuing from where I left off in post no.12, I started with 12.5 Hz pulse rate (15 ms on, 65 ms off) and gradually increased the rate. I have failed to break it. I gave up with a pulse rate of 66.67 Hz (5 ms on, 10 ms off), which is faster than any mains frequency. I can’t imagine any meter flashing at that speed.
Again there are very many missing data points, but the temperature sensor is being read correctly (corroborated by a mercury thermometer alongside it).
19:19:20.927 → Settings:
19:19:20.927 → Lit 15, Dark 65
19:19:33.631 → Lit: 10
19:19:40.238 → Dark: 60
19:19:42.398 → Settings:
19:19:42.398 → Lit 10, Dark 60
19:23:33.671 → Dark: 50
19:23:34.567 → Settings:
19:23:34.567 → Lit 10, Dark 50
19:28:00.999 → Dark: 40
19:28:02.293 → Settings:
19:28:02.293 → Lit 10, Dark 40
19:31:59.013 → Lit: 5
19:32:01.802 → Dark: 35
19:32:02.698 → Settings:
19:32:02.698 → Lit 5, Dark 35
19:35:01.723 → Dark: 25
19:35:02.354 → Settings:
19:35:02.354 → Lit 5, Dark 25
19:38:01.441 → Dark: 20
19:38:03.532 → Settings:
19:38:03.532 → Lit 5, Dark 20
19:41:09.960 → Dark: 15
19:41:10.757 → Settings:
19:41:10.757 → Lit 5, Dark 15
19:45:01.800 → Dark: 10
19:45:09.898 → Dark: 10
19:45:10.727 → Settings:
19:45:10.727 → Lit 5, Dark 10
1 Like