HV pulse every sec using a timer

[rexfue]

It seems, that if Wifi connection has problems, the HV will not be charged for many seconds. So we should use a hardware timer and timer interrupt to charge HV every second.

[ThomasWaldmann]

Would a GM pulse interrupt be able to interrupt the HV load ISR code?

[rexfue]

Don't know at the moment, will investigate. But I think, it should be possible.

[jwoelk]

I made an experiment this evening, replacing the GM tube by a 1s pulse generator at GMZ_COUNT (3.3V amplitude, 99% duty cycle). Please find the serial protocol attached. The equidistant pulses cause the SW to run very smoothly. 10 s are always accurate for +- 1 ms. As you can see, sending measurement values of two sensors (SI-22G + BME280) sometimes takes up to 12 s in normal cases. If a transmission times out, this adds about 6 s. The extreme case seen was 42 s, where both transmissions to madavi crashed with a "socket error" message. 2 weeks ago I had connected my scope via a 1 GOhm resistor for some time, as advised by Juergen. During WiFi transmissions the HV plateau region was then left after about 10 s (rough estimation), suppressing further tube pulses. This resistance corresponds to an additional ambient dose rate of 8.4 uSv/h according to my calculation. I think the Multigeiger should be able to measure such a dose rate. So I would appreciate when the HV would be charged regularily each second.

putty-ESF32-20200225-with_1s-pulse-gen.log

Best Regards Joachim

P.S.: meine Nebenrechnung zur Belastung der Hochspannung durch den 1 GOhm-Widerstand:

Vorwiderstand am GMZ: 10 MOhm Spannungseinbruchtiefe während der GMZ-Entladung: 60 V Restspannung am GMZ während der GMZ-Entladung: 340 V Dauer der GMZ-Entladung (nach Umformung in ein äquivalentes Rechteck mit gleicher Höhe): 0,4 ms GMZ-Widerstand während der Entladung: 340/60 10 MOhm = 57 MOhm Zahl der Entladungen/s bei 100 nSv/h: ca. 1,7 resultierender mittl. GMZ-Widerstand bei 100 nSv/h: 57 MOhm / (1,7/s 0,0004s) = 84 GOhm

Max. Zahl der Entladungen/s: 1 / 0,0004 = 2500 ~= 150 uSv/h Praktikabel: 100 uSv/h = 1700 cnt/s resultierender mittl. Widerstand: 57 MOhm / (1700 * 0,0004) = 84 MOhm

Tastkopf mit 1 GOhm Vorwiderstand entspricht einer ODL: 84 GOhm / 1 GOhm * 0,1 uSv/h = 8,4 uSv/h

[ThomasWaldmann]

See my comments there: #184

Keeping the connections might speed up transmission significantly (IF the server doesn't close before we transmit next measurement), especially in case of a TLS connection. I'll do the tls changes / connection keeping changes after next release.

[rexfue]

Maybe HTTP/TLS connection can be speeded up, but LoRa needs about 4sec (at the moment). So we should use timer interrupt to charge every sec.

[ThomasWaldmann]

@jwoelk I don't have an oscilloscope here - can you test the PR #254 code and see how the HV recharging / HV voltage looks like (maybe at different radiation levels)?

[jwoelk]

Hi Thomas,

I will do that, but need some days because of other duties. Maybe two weeks. I also never downloaded SW to the ESP32, but remember to have seen instructions somewhere. I think I should be able to get on, otherwise I will ask someone.

I can only simulate two different radiation levels: 1. the natural level at home, 2. the same with an additional 1 GOhm resistor in parallel with the GM tube that emulates an effective level of about 8.4 uSv/h. I need the resistor to attach the scope probe to the HV.

Cheers

Joachim

Am 08.05.2020 um 00:34 schrieb TW:

@jwoelk https://github.com/jwoelk I don't have an oscilloscope here

• can you test the PR #254 https://github.com/ecocurious2/MultiGeiger/pull/254 code and see how the HV recharging / HV voltage looks like (maybe at different radiation levels)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ecocurious2/MultiGeiger/issues/192#issuecomment-625530934, or unsubscribe https://github.com/notifications/unsubscribe-auth/AON6HA53BINPPHMBVUCQZW3RQMZQXANCNFSM4KTKOMGA.

-- Joachim Wölk Luisenstraße 19 74354 Besigheim Tel. 07143 31097

[jwoelk]

@ThomasWaldmann

Tested 2020-05-12 on Windows 10 Pro 1909 with HW Node esp32-7936340 (Sensor IDs 40369 / Si22g + 40370 / BME280), SW 1.13.1-dev on branch pr/254 and the following libs:

• Adafruit BME280 2.0.2
• Adafruit Unified Sensor 1.1.2
• Adafruit ADXL343 1.2.0
• IoTWebConf 2.3.1
• MCCI LoRaWAN LMIC library 3.1.0
• U8g2 2.27.6

Measurements Part 1: Normal operation, steady state. About 0,11 uSv/h.

HV_FET_OUT (1 V/div): about 3.3 V amplitude and 1.6 ms duration per single pulse. Occurs in terms of pulse trains each 3.8 seconds (measured manually with a stop watch). A pulse train comprizes two pulses in most cases, but sometimes one pulse or three pulses, with a pulse repetition rate of 2.7 ms.

HV_CAP_FULL (1 V/div): about 1.6 V amplitude or more and 10 us pulse duration. Pulse trains with two pulses in most cases, as above. The screenshot shows a train of three pulses with staggered amplitudes (1.3 V, 1.6 V, 2.0 V). Amplitude of 1st pulse varies between 1.3 and 2.0 V. If it is > 1.8 V, no more pulses follow. Amplitude of 2nd pulse is 1.6 ... 2.0 V. Amplitude of 3rd pulse 1.9 ... 2.1 V.

Here a single HV_CAP_FUL pulse:

Measurements Part 2: added a 1 GigOhm resistor between HV (tube + pole) and a second 10 MOhm probe.

HV_FET_OUT: pulse train repetition rate is now about 0.3 s. Pulse trains still have two, sometimes one or three pulses. In one single case a 4-pulse train was seen.

HV_CAP_FULL: pulse train repetition rate is again the same as HV_FET_OUT. Other characteristics remain.

HV (100 V/div, yellow trace in the following screenshot): is stable, also during the HTTP transmission phase. Unfortunately there is a 50 Vpp 50 Hz hum overlaid, of which I cannot tell the source. Nevertheless one can see that the first HV_FET_OUT pulse within a pulse train augments HV by maybe 10 V.

If I may add a jadgement: I think the FW update is working rather satisfying.

[ThomasWaldmann]

Pulse repetition rate 2.7ms (expected: 1500us + 1000us = 2.5ms, 100us ISR timer) uncovered another off-by-one error, see #288. Thanks!

[jwoelk]

My serial log (normal operation): putty-ESF32_20200512_1.13.1-dev.log

The serial log with HV+ connected to a 2nd scope probe via 1 1GigOhm resistor: putty-ESF32_20200512(+HV)_1.13.1-dev.log

[ThomasWaldmann]

The HV_CAP_FULL pulse trains are a bit unexpected.

Instead of slightly increasing amplitudes from first to third pulse in such a train, I had rather expected no 1st and 2nd pulse (or very very low amplitude) and only a final (and definitely high enough) pulse when the cap is full.

Can you say something about the time distance between:

• first HV_FET rising edge and first HV_CAP_FULL rising edge?
• first HV_FET falling edge and first HV_CAP_FULL rising edge?

Note: I think this is rather a hw issue than related to this PR, but still would be interesting why it is like that.

[jwoelk]

Hi Thomas, here are two new screenshots: HV_FET_OUT is green, HV_CAP_FUL is yellow. Both 1 V /div.

The 2nd screenshot shows in detail a falling HV_FET_OUT edge and the corresponding HV_CAP_FUL pulse.

[ThomasWaldmann]

OK, so when comparing this to algorithm:

• rise HV_FET_OUT
• pause 1500us (via timer)
• lower HV_FET_OUT
• ~10us later HV_CAP_FULL pulse while pausing 1000us (via timer)
• check whether there was a HV_CAP_FULL event

So it looks like there are ~990us time (within the "low phase" of the charge pulse) for the ISR to set the hv_cap_full variable, which is way more than enough.

So, it seems we are doing analogue stuff here: "is the HV_CAP_FUL rising high enough to actually trigger an interrupt" rather than (what I expected) digital stuff like "is the HV_CAP_FUL pulse happening or not".

[ThomasWaldmann]

Idea (please check): how much is the measurement equipment influencing the HV_CAP_FUL signal height? I mean e.g. the oscilloscope probe's capacitance and cable inductivity.

Besides doing calcuations one could maybe experimentally see this: under same radiation conditions, are you seeing more charge pulses with the probe attached than without?

[ThomasWaldmann]

Reopening this until discussion finished for better visibility.

[ThomasWaldmann]

We'll have timer interrupt driven charging in V1.14.0 release, code is already merged.

[jwoelk]

An oscilloscope probe has an impedance of about 1 or 10 Mohm in parallel with 10 pF. Connected to node HV_CAP_FUL, the probe is in parallel with R1 (10k +- 5%) and C2 (10n, 10%), hence the additional load is small, even below the parts' tolerances. I would not expect any influence from probing this signal.

As an experiment, I connected two probes, one of 1 MOhm and one of 10 MOhm, in parallel. Then I removed one probe or the other. I cannot tell any difference, because the pulses vary slightly anyway from one occurence to the next.

On the other hand, the tolerances of the ZY200 diodes are quite large, from 188 to 212 V, at 5 mA current. When the HV_CAP_FUL signal reaches 2 V, only 0.2 mA flow through R1. According to the old General Semiconductor datasheet

https://cdn-reichelt.de/documents/datenblatt/A400/ZY1-THRU-ZY200_ENG_DATASHEET.pdf

the dynamic resistance is about 850 ohms at 0.2 mA, going down to about 150 ohms at 5 mA. At 2.5 mA it is 200 ohms. This means the smaller current reduces the zener voltage further by roughly estimated 2.5 mA * 200 ohms = 0.5 V.

This means the HV of two diodes in series can be as low as 375 V or as high as 423 V. Fortunately the plateau region of the Si22G tube goes from 350 V to 450 V. Ditto SBM-19 and SBM-20.

---

When I remove the tube, then I see one HV_FET_OUT pulse every 10 s. It is always one, never two or three in a train. With the Si22G tube, in steady-state a two-pulse train comes every 4 s.

[ThomasWaldmann]

AFAICS, the interrupt-driven adaptive charging is working OK (at least at relatively low radiation levels), so I am closing this for now.