Include file name + contrast adjustment + power optimization

[mryndzionek]

Without this it doesn't build on Linux.

[Gissio]

Hi there, thanks for the submission! I have added your changes to the 2.0 repository, which will be released in short.

I also noticed you added a pull request for setting the monochrome display contrast. Are you having problems with the default contrast value? What contrast value works best on your device?

[mryndzionek]

I also noticed you added a pull request for setting the monochrome display contrast.

Not a PR yet, just a commit on my fork (pushed it here by mistake).

Are you having problems with the default contrast value? What contrast value works best on your device?

Yes, on my device values in the range 30-34 work the best. 40 (0x28) looks bad. My device is FS2011 with GD32F150 and J305.

[mryndzionek]

If you're adding changes, you can also fix the temperature readout here by changing 0.0041F to 4.1F.

[Gissio]

Thanks a lot for your reports! The contrast settings will be added in the upcoming 2.0 release.

According to the datasheet (https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230314/GD32F150xxDatasheetRev3.5.pdf, page 61), the temperature formula in https://github.com/Gissio/radpro/blob/main/platform.io/src/stm32/stm32_adc.c#L236 is correct. Could something else be wrong?

[mryndzionek]

Thanks a lot for your reports! The contrast settings will be added in the upcoming 2.0 release.

According to the datasheet (https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230314/GD32F150xxDatasheetRev3.5.pdf, page 61), the temperature formula in https://github.com/Gissio/radpro/blob/main/platform.io/src/stm32/stm32_adc.c#L236 is correct. Could something else be wrong?

Oh, yes, sorry, you are right. I don't know what is happening then...

[mryndzionek]

I think I got, at least one, piece of the puzzle. It seems that on GD32 you need to use adc_tempsensor_vrefint_enable() instead of adc_enable_temperature_sensor().

[Gissio]

On the GD32F150, the code is doing

ADC_CTL1 |= ADC_CTL1_TSVREN;

which is equivalent to calling adc_tempsensor_vrefint_disable().

There was another bug related to a short conversion, which might have caused this problem. It is fixed in the current repository. Could you please try it?

[mryndzionek]

Doesn't even build:

src/keyboard.c:214:10: error: conflicting types for 'getKeyboardEvent'
 enum Key getKeyboardEvent(void)
          ^~~~~~~~~~~~~~~~
In file included from src/keyboard.c:14:0:
src/keyboard.h:59:12: note: previous declaration of 'getKeyboardEvent' was here
 enum Event getKeyboardEvent(void);

Even if I fix the error my counter doesn't work after flashing. So far only the tag 2.0beta11 works.

[mryndzionek]

I think I bricked my counter after last reflash... Any ideas how to recover GD32F150?

[Gissio]

Most important: don't panic!

Get https://github.com/stlink-org/stlink/releases and try this command:

st-link --probe

If your device responds, try the following:

st-link --erase

After this you should be ok again.

If your device does not respond, try grounding the NRST (reset) line (see https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230314/GD32F150xxDatasheetRev3.5.pdf, page 11) while attempting the previous commands. This should correspond to grounding the right side of resistor R5 (https://github.com/Gissio/radpro/blob/main/docs/devices/FS2011/FS2011%20GD32F150%20J305.jpg).

Let me know.

[mryndzionek]

Most important: don't panic!

Get https://github.com/stlink-org/stlink/releases and try this command:

st-link --probe

If your device responds, try the following:

st-link --erase

After this you should be ok again.

If your device does not respond, try grounding the NRST (reset) line (see https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230314/GD32F150xxDatasheetRev3.5.pdf, page 11) while attempting the previous commands. This should correspond to grounding the right side of resistor R5 (https://github.com/Gissio/radpro/blob/main/docs/devices/FS2011/FS2011%20GD32F150%20J305.jpg).

Let me know.

I tried grounding NRST yesterday, but it did not work. I think I had too old st-link. Now with 1.8 I managed to recover. Thanks!

[mryndzionek]

There seems to be something wrong with https://github.com/Gissio/radpro/blob/main/platform.io/src/stm32/stm32_adc.c#L158 on GD32F150. This power_on hangs indefinitely.

[Gissio]

I'm glad you were able to recover your counter.

It seems a silly #define mistake slipped into the code. It should work with the latest commit.

[mryndzionek]

I have a question regarding battery life. Now it seem that around half of alkaline battery goes like in ~10h (no display backlight and no clicks). Is it possible to improve the battery life?

[Gissio]

The settings format in Rad Pro 2.0 changed. Could it be that the firmware is using incorrect values? Try selecting the "energy saving" HV profile. Does it work?

[mryndzionek]

I made some measurement and in the default mode and without backlight the current draw is ~38mA. This is around 3 days for standard alkaline battery. With "energy saving" the current drops to ~12-15mA. This is around 10 days. This is a lot better, but still, I would think that a month should be achievable.

[Gissio]

It seems your results are consistent with what Dsl71 reports in the following discussion (use Google Translate if you don't read german): https://www.geigerzaehlerforum.de/index.php/topic,729.30.html

I tried everything in my power to keep power consumption low: for example, entering sleep mode with the WFI instruction whenever possible.

From a software point of view, I don't think it is possible to lower power consumption further. If you come up with some bright idea, let us know!

[mryndzionek]

Okay, fair enough. My expectation come from a simpler device I've built on attiny85. It only has 2 LEDs and with 3xAAA batteries it can work for ~7months. The HV power supply draws very little, most likely less that 1mA. The display, I suspect, without backlight maybe 300uA. This seems to indicate that there is headroom. The problem is most likely that the operations in firmware don't overlap. To change this however either using some RTOS with tickless idle would be needed, or changing the overall design to something more event-driven. In general, increasing the amount of concurrency in the system.

[mryndzionek]

I went through the forum and it seems the HV power supple doesn't have feedback. So this is the main problem. A much more energy efficient control can be implemented when there is a HV measurement feedback available, like here: https://www.hackster.io/news/pen-sized-geiger-counter-runs-for-up-to-a-year-on-battery-ccf386bcb88b

Anyway, thanks for sharing the firmware! It is much, much better than the original one. A lot of good work went into it. Can't wait to test it on FNIRSI GC-01.

[Gissio]

Yes, it seems the FS2011 was optimized for cost (or effort), not power consumption.

Nevertheless, your comments piqued my curiosity, so I did some experiments on my FS2011/STM32F051. With a 3.3 V power supply, the baseline power consumption (everything turned off, sleep mode) is 6.1 mA. Turning on the devices, except for HV, makes power consumption rise to 6.5 mA.

So optimizing more is not really worth the effort.

[mryndzionek]

One more question. I noticed that with loud pulse clicks the backlight dims slightly. Is to to be expected, or is there maybe some GPIO misconfiguration?

[Gissio]

I rather think that the power/speaker circuit is poorly designed.