-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HV pulse every sec using a timer #192
Comments
Would a |
Don't know at the moment, will investigate. But I think, it should be possible. |
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. putty-ESF32-20200225-with_1s-pulse-gen.log Best Regards P.S.: meine Nebenrechnung zur Belastung der Hochspannung durch den 1 GOhm-Widerstand: Vorwiderstand am GMZ: 10 MOhm Max. Zahl der Entladungen/s: 1 / 0,0004 = 2500 ~= 150 uSv/h Tastkopf mit 1 GOhm Vorwiderstand entspricht einer ODL: 84 GOhm / 1 GOhm * 0,1 uSv/h = 8,4 uSv/h |
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. |
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. |
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
<#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
<#192 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AON6HA53BINPPHMBVUCQZW3RQMZQXANCNFSM4KTKOMGA>.
--
Joachim Wölk
Luisenstraße 19
74354 Besigheim
Tel. 07143 31097
|
Pulse repetition rate 2.7ms (expected: 1500us + 1000us = 2.5ms, 100us ISR timer) uncovered another off-by-one error, see #288. Thanks! |
My serial log (normal operation): The serial log with HV+ connected to a 2nd scope probe via 1 1GigOhm resistor: |
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:
Note: I think this is rather a hw issue than related to this PR, but still would be interesting why it is like that. |
OK, so when comparing this to algorithm:
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". |
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: |
Reopening this until discussion finished for better visibility. |
We'll have timer interrupt driven charging in V1.14.0 release, code is already merged. |
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. |
AFAICS, the interrupt-driven adaptive charging is working OK (at least at relatively low radiation levels), so I am closing this for now. |
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.
The text was updated successfully, but these errors were encountered: