Running OHB and Hamclock both on Raspberry Pi 4B timeout in hamclock for propmap

[kr8x]

Describe the bug

Running OHB and Hamclock both on Raspberry Pi 4B timeout in hamclock for propmap

Initially, this issue was a perceived lockup at the pi after a fresh installl. This was working previously for earlier versions of ohb running native without docker, but, PropMap wasn't implemented yet.

Looks like it didn't crash - just was unresponsive -- but running very slowly
propmap fail - looks like hamclock is timeing out before propmap is returned.

From voacap log

2026-03-21 14:47:44,003 INFO AreaMap(REL): 2026/03 UTC=14 TX=(33.1670,-96.9170) 14.100MHz CW SSN=26 2640x1320
2026-03-21 14:47:44,796 INFO VOAAREA OK: /tmp/voaarea_2ro49q7a/itshfbc/areadata/ohb_6597e2b8/pyArea.vg1 (234349 bytes)
2026-03-21 14:47:44,796 INFO TIMING voacapl: 0.79s
2026-03-21 14:47:44,846 INFO VG1 parsed: 1369 pts lat -86.8..86.9 lon -179.9..179.6
2026-03-21 14:47:44,846 INFO TIMING parse: 0.05s
2026-03-21 14:47:45,032 INFO TIMING interp: 0.18s
2026-03-21 14:47:46,351 INFO TIMING render_day: 1.32s
2026-03-21 14:47:47,461 INFO TIMING rendernight: 1.11s
127.0.0.1 - - [21/Mar/2026:14:47:54 +0000] "GET /health HTTP/1.1" 200 3 "-" "curl/8.14.1"
2026-03-21 14:48:05,596 INFO TIMING bmp565: 18.13s TOTAL: 21.59s
2026/03/21 14:48:06 [warn] 17#17: *470 an upstream response is buffered to a temporary file /var/lib/nginx/uwsgi/7/00/0000000007 while reading upstream, client: 172.21.0.2, server: , request: "GET /fetchVOACAPArea.pl?YEAR=2026&MONTH=3&UTC=14&TXLAT=33.167&TXLNG=-96.917&PATH=0&WATTS=50&WIDTH=2640&HEIGHT=1320&MHZ=14.10&TOA=3.0&MODE=19&TOA=3.0 HTTP/1.1", upstream: "uwsgi://unix:/run/uwsgi/voacap.sock:", host: "voacap-service:8080"
[pid: 87|app: 0|req: 4/10] 172.21.0.2 () {34 vars in 677 bytes} [Sat Mar 21 14:47:44 2026] GET /fetchVOACAPArea.pl?YEAR=2026&MONTH=3&UTC=14&TXLAT=33.167&TXLNG=-96.917&PATH=0&WATTS=50&WIDTH=2640&HEIGHT=1320&MHZ=14.10&TOA=3.0&MODE=19&TOA=3.0 => generated 581539 bytes in 22711 msecs (HTTP/1.1 200) 5 headers in 167 bytes (4 switches on core 0)
172.21.0.2 - - [21/Mar/2026:14:48:06 +0000] "GET /fetchVOACAPArea.pl?YEAR=2026&MONTH=3&UTC=14&TXLAT=33.167&TXLNG=-96.917&PATH=0&WATTS=50&WIDTH=2640&HEIGHT=1320&MHZ=14.10&TOA=3.0&MODE=19&TOA=3.0 HTTP/1.1" 200 581539 "-" "libwww-perl/6.78"
127.0.0.1 - - [21/Mar/2026:14:48:24 +0000] "GET /health HTTP/1.1" 200 3 "-" "curl/8.14.1"

From hamclock -o log

622.424 mapMsg: Calculating 20m/REL...
622.484 running /fetchVOACAPArea.pl?YEAR=2026&MONTH=3&UTC=14&TXLAT=33.167&TXLNG=-96.917&PATH=0&WATTS=50&WIDTH=2640&HEIGHT=1320&MHZ=14.10&TOA=3.0&MODE=19&TOA=3.0
632.485 getTCPChar timeout

hamclock timeout is 10s but generation takes 22+ seconds. Stopping mqtt container makes no difference

10s timeout is hardcoded in hamclock. There might just not be enough processing power in the Pi to to PropMap generation. If you want to patch hamclcok, setting this to 30000 would probably work...

dave@victus:~/ESPHamClock-4.22/src$ grep -i read_pending_ms ArduinoLib/*h
ArduinoLib/WiFiClient.h: const int READ_PENDING_MS = 10000; // max read wait time, ms

workaround works to patch and rebuild hamclock

$ mkdir hamclock
$ cd hamclock
$ wget https://www.clearskyinstitute.com/ham/HamClock/ESPHamClock.zip
$ unzip ESPHamClock.zip
$ mv ESPHamClock ESPHamClock30s
$ cd ESPHamClock30s
$ cd ArduinoLib/
$ chmod +x WiFiClient.h
$ nano WiFiClient.h
change 10000 to 30000
$ cd ..

if running current hamclock, get build paramter with hamclock -v
$ hamclock -v
Result will look like
Version 4.22
built as: make hamclock-web-3200x1920

$make hamclock-web-3200x1920
$sudo make install

some extra processor capacity can be gained if you don't need PSKReporter

from running
$ vmstat -Sm 2

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
5 1 182 27 67 3216 0 0 0 5152 5971 7764 77 5 15 3 0
5 1 182 27 67 3216 0 0 0 1190 3984 4649 70 1 8 21 0
4 2 182 27 67 3216 0 0 0 5122 6430 11245 70 3 7 19 0
4 0 182 27 67 3216 0 0 0 2876 3931 6629 74 3 4 19 0
4 1 182 27 67 3216 0 0 0 14226 2564 2869 75 2 23 0 0
4 1 182 27 67 3216 0 0 0 4820 5793 6205 70 2 25 3 0
4 1 182 27 67 3216 0 0 0 4622 5227 9270 70 3 8 19 0
5 0 182 27 67 3216 0 0 0 5078 5692 10823 65 3 12 19 0
3 0 182 27 67 3216 0 0 352 14454 4578 6557 77 7 14 1 0

About here I did a
$docker stop pskr-mqtt-cache

idle load is third column from the left

4 0 182 27 67 3216 0 0 0 470 2804 3833 70 2 28 0 0
4 0 182 27 67 3216 0 0 0 4 2994 4699 69 5 27 0 0
3 0 182 27 67 3216 0 0 0 70 2325 2808 68 3 29 0 0
3 0 182 27 67 3216 0 0 0 13614 2389 2956 58 6 36 0 0
4 0 182 27 67 3216 0 0 0 0 2267 2709 68 3 29 0 0
4 0 182 27 67 3216 0 0 0 480 2378 2919 67 4 29 0 0
4 0 182 27 67 3216 0 0 96 6 2419 2918 68 3 29 0 0
4 0 182 27 67 3216 0 0 0 50 2231 2572 65 6 29 0 0
4 0 182 27 67 3216 0 0 0 0 2313 2705 69 3 29 0 0
4 0 182 27 67 3216 0 0 0 0 2325 2739 70 1 29 0 0
3 0 182 27 67 3216 0 0 0 112 2434 2955 70 1 29 0 0
3 0 182 27 67 3216 0 0 0 0 2233 2648 66 5 29 0 0
3 0 182 27 67 3216 0 0 0 34 2390 2870 68 3 29 0 0
6 0 182 27 67 3216 0 0 0 0 2320 2773 74 1 25 0 0
5 0 182 27 67 3216 0 0 0 4 2640 3076 79 2 20 0 0
4 0 182 27 67 3216 0 0 2 2 2868 4017 70 1 29 0 0
3 0 182 27 67 3216 0 0 0 60 2876 3977 71 1 28 0 0
3 0 182 27 67 3216 0 0 0 6 2347 2818 70 0 29 0 0

To Reproduce

Install hamclock and OHB onto a Raspberry Pi 4B

Expected behavior

Screenshots
If applicable, add screenshots to help explain your problem.

HamClock deployment (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Backend:

• ohb.hamclock.app:80
• your own deployment [e.g., OS, hardware]

Additional context
Add any other context about the problem here.

[komacke]

Would it make sense to report this here: https://github.com/komacke/hamclock

It doesn't seem like anything OHB can address. My only suggestion would be to tweak OHB only to generate the size maps you want with the map_sizes.sh file. You can comment out the sizes you don't use.

If you use less than the maximum history of PSKR, you can poke the file /etc/pskr-mqtt-cache/config.yaml in the docker container to set the max_age_hours value to a smaller number.

[kr8x]

Would it make sense to report this here: https://github.com/komacke/hamclock

no, this is an issue for OHB if it is desired to a) reduce the CPU footprint b) speed up propmap generation. It isn't a hamclock issue - I only mentioned the workaround so testing on Pi can continue.
Regardless, it should at least be captured as a caveat in documentation concerning platforms supported to have both OHB an hamclock running.

It doesn't seem like anything OHB can address. My only suggestion would be to tweak OHB only to generate the size maps you want with the map_sizes.sh file. You can comment out the sizes you don't use.

If you use less than the maximum history of PSKR, you can poke the file /etc/pskr-mqtt-cache/config.yaml in the docker container to set the max_age_hours value to a smaller number.

When OHB was built on native, there was an option to specify the sizes desired to be generated; however, when I stopped mqtt, no significant time improvement was seen. Even when no maps are being built in OHB container, it still takes awhile. It seems unlikely that moving from docker to bare metal will have an over 50 percent improvement in speed, but, any improvements may help a singleton deployment scale if load balancing isn't used.

[komacke]

No, there won't be any speed improvements moving out of docker. These calculations take a lot of horsepower for image manipulation. We can keep this open but I don't currently know what can be done in software other than, as you say, document it.