DOA GUI Bug - Page body not loading

1

Hello,

Intro - Context:
KrakenS DR arrived some weeks ago (yay) and I’m still setting up the DOA use-case in my free time.
Compiled DOA from source on a Raspberry Pi 4B that runs at 1.8Ghz, all cables and power supplies are OK, and all Firmware threads/processes are alive and apparently healthy. The only problem is GUI-related and will be described below. The purpose of this post is to kindly ask if someone has faced this in the past and remembers the solution, before investigating myself and proceeding to share the fix.

Description of the Problem
Visiting http://<RASPBERRY_IP>:8080/config presents a webpage with a properly rendered header but no body (See image below).
Technically, inspection shows a frequent update of the update_rx placeholder (i.e. the DIV Element with id=“placeholder_update_rx”), but no information received on the frontend for the DIV Element with ID “daq_cfg_files”, which I guess it’s the one that receives the information used to build the frontend body content / the graphics for the configuration.

Screenshot from 2024-02-24 17-00-08
Screenshot from 2024-02-24 17-00-082902×1550 434 KB

Two Errors Spotted

Error 1: JavaScript
The browser’s console does report the following error, only once after the site is refreshed:

ReferenceError: A nonexistent object was used in an Input of a Dash callback. The id of this object is daq_cfg_files and the property is value. The string ids in the current layout are: [url, header_config, header_spectrum, header_doa, settings-refresh-timer, placeholder_start, placeholder_stop, placeholder_save, placeholder_update_rx, placeholder_recofnig_daq, placeholder_update_daq_ini_params, placeholder_update_freq, placeholder_update_dsp, placeholder_config_page_upd, placeholder_spectrum_page_upd, placeholder_doa_page_upd, dummy_output, page-content, _none]
at di (dash_renderer.v1_9_1m1617985068.min.js:20:88389)
at pi (dash_renderer.v1_9_1m1617985068.min.js:20:88285)
at dash_renderer.v1_9_1m1617985068.min.js:20:86411
at Array.map ()
at dash_renderer.v1_9_1m1617985068.min.js:20:86243
at u (dash_bootstrap_components.v1_1_0m1708693958.min.js:2:7133)
at Generator._invoke (dash_bootstrap_components.v1_1_0m1708693958.min.js:2:6921)
at Generator.next (dash_bootstrap_components.v1_1_0m1708693958.min.js:2:7562)
at zo (dash_renderer.v1_9_1m1617985068.min.js:20:80940)
at a (dash_renderer.v1_9_1m1617985068.min.js:20:81144)

Error 2: Python Logs
There also are errors reported on /home/krakensdr_doa/krakensdr_doa/_share/logs/krakensdr_doa/ui.log, albeit they are not replicated each time we hit “refresh” – if there is some connection it is not inmediate.

TypeError: ‘NoneType’ object is not iterable
INFO:quart.serving:192.168.0.222:34878 GET /_dash-component-suites/dash_core_components/dash_core_components-shared.js.map 1.1 500 - 26836
[2024-02-24 15:34:50,485] 192.168.0.222:34878 GET /_dash-component-suites/dash_core_components/dash_core_components-shared.js.map 1.1 500 - 26836
INFO:quart.serving:192.168.0.222:34878 GET /_dash-component-suites/dash_core_components/dash_core_components-shared.js.map 1.1 - - 29282
[2024-02-24 15:34:50,488] 192.168.0.222:34878 GET /_dash-component-suites/dash_core_components/dash_core_components-shared.js.map 1.1 - - 29282
ERROR:quart.serving:Error in ASGI Framework
Traceback (most recent call last):
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/hypercorn/asyncio/task_group.py”, line 27, in _handle
await app(scope, receive, send, sync_spawn, call_soon)
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/hypercorn/app_wrappers.py”, line 34, in call
await self.app(scope, receive, send)
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/app.py”, line 1741, in call
await self.asgi_app(scope, receive, send)
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/app.py”, line 1767, in asgi_app
await asgi_handler(receive, send)
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/asgi.py”, line 51, in call
_raise_exceptions(done)
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/asgi.py”, line 353, in _raise_exceptions
raise task.exception()
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/asgi.py”, line 102, in handle_request
await asyncio.wait_for(self._send_response(send, response), timeout=timeout)
File “/home/miniforge3/envs/kraken/lib/python3.9/asyncio/tasks.py”, line 481, in wait_for
return fut.result()
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/asgi.py”, line 131, in _send_response
async for data in response_body:
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/wrappers/response.py”, line 103, in _aiter
for data in iterable: # type: ignore
TypeError: ‘NoneType’ object is not iterable
[2024-02-24 15:34:50,491] Error in ASGI Framework
Traceback (most recent call last):
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/hypercorn/asyncio/task_group.py”, line 27, in _handle
await app(scope, receive, send, sync_spawn, call_soon)
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/hypercorn/app_wrappers.py”, line 34, in call
await self.app(scope, receive, send)
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/app.py”, line 1741, in call
await self.asgi_app(scope, receive, send)
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/app.py”, line 1767, in asgi_app
await asgi_handler(receive, send)
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/asgi.py”, line 51, in call
_raise_exceptions(done)
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/asgi.py”, line 353, in _raise_exceptions
raise task.exception()
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/asgi.py”, line 102, in handle_request
await asyncio.wait_for(self._send_response(send, response), timeout=timeout)
File “/home/miniforge3/envs/kraken/lib/python3.9/asyncio/tasks.py”, line 481, in wait_for
return fut.result()
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/asgi.py”, line 131, in _send_response
async for data in response_body:
File “/home/miniforge3/envs/kraken/lib/python3.9/site-packages/quart/wrappers/response.py”, line 103, in _aiter
for data in iterable: # type: ignore
TypeError: ‘NoneType’ object is not iterable
INFO:quart.serving:192.168.0.222:34606 GET /_dash-component-suites/dash_html_components/dash_html_components.min.js.map 1.1 500 - 30379
[2024-02-24 15:34:50,499] 192.168.0.222:34606 GET /_dash-component-suites/dash_html_components/dash_html_components.min.js.map 1.1 500 - 30379
INFO:quart.serving:192.168.0.222:34606 GET /_dash-component-suites/dash_html_components/dash_html_components.min.js.map 1.1 - - 32942
[2024-02-24 15:34:50,502] 192.168.0.222:34606 GET /_dash-component-suites/dash_html_components/dash_html_components.min.js.map 1.1 - - 32942
INFO:quart.serving:192.168.0.222:34616 GET /_push 1.1 101 - 18250
[2024-02-24 15:34:50,541] 192.168.0.222:34616 GET /_push 1.1 101 - 18250
INFO:quart.serving:192.168.0.222:55760 GET /config 1.1 200 662 7786
[2024-02-24 15:36:11,333] 192.168.0.222:55760 GET /config 1.1 200 662 7786
INFO:quart.serving:192.168.0.222:55760 GET /config 1.1 - - 8860
[2024-02-24 15:36:11,334] 192.168.0.222:55760 GET /config 1.1 - - 8860

Closing remarks
Equivalent no-body issues could be described for the /doa and /spectrum endpoints if required, but I have chosen to first focus on what I guess is the “simplest” endpoint, and see later how to proceed.

2

Can you try running the ready to use image file instead?

Someone else did report seeing this after the latest updates to the code, but for whatever reason I haven’t been able to replicate it yet.

The images keep the stable version of the code, whereas direct compile is for getting the latest possibly buggy version.

3

Update: I just pushed an update which should fix this.

But I’m unsure why you would be getting this problem on the config screen in the first place. In my tests it was only possible to glitch it on the Spectrum and DOA Estimation screens, and only very rarely.

4

Perfect, thanks Carl. Now the GUI is loading the configuration menu and no errors are reported on the JavaScript Browser Console (Chrome Version 121.0.6167.85 (Official Build) (64-bit)) - screenshot below.

Thanks!

PS: the “Spectrum” and “DOA” sections are now loading O.K. their windows, albeit no info is displayed. It is clearly connected to the “DAQ Status: Disconnected” message shown in the screenshot below - I will debug this myself.
My Heimdall Daq directory was cloned from 910fecbee0a3ce317e780c2a1835519bce0b458d
i.e. “Fix Makefile” Tue Feb 13 12:09:09 2024

I will check again cables and stuff, and if required reinstall firmware. I may also try with the latest release of firmware, i.e. Release v3.1.0-a.1 from May 2022.

Thanks!

Screenshot from 2024-02-27 12-27-47
Screenshot from 2024-02-27 12-27-473592×1328 388 KB

5

Please check the log files in the krakensdr_doa/_share folder and in the heimdall logs folder too.

The GUI has started up, but it’s missing the connection to heimdall for some reason. If there is no connection the spectrum and DOA pages won’t work because there is no data to display.

1 Like
7

UPDATE:

Now I see that apparently
krakensdr_doa/_share/logs/heimdall_daq_fw
contains more info than
heimdall_daq_fw/Firmware/_logs/

Analyzing the correct path shows

status.json shows:

…“daq_status”: {}, “daq_ok”: false, “daq_num_dropped_frames”: 2…

logs/krakensdr_doa/ui.log shows:

CRITICAL:kraken_sdr_receiver:Shared memory initialization failed

logs/heimdall_daq_fw/hwc.log shows:

Traceback (most recent call last):
File “/home/m4zz31/krakensdr_doa/heimdall_daq_fw/Firmware/_daq_core/hw_controller.py”, line 702, in
HWC_inst0.start()
File “/home/m4zz31/krakensdr_doa/heimdall_daq_fw/Firmware/_daq_core/hw_controller.py”, line 415, in start
active_buff_index = self.in_shmem_iface.wait_buff_free()
File “/home/m4zz31/krakensdr_doa/heimdall_daq_fw/Firmware/_daq_core/shmemIface.py”, line 188, in wait_buff_free
signal = unpack(‘B’, os.read(self.fw_ctr_fifo, 1))[0]
struct.error: unpack requires a buffer of 1 bytes
/home/m4zz31/miniforge3/envs/kraken/lib/python3.9/multiprocessing/resource_tracker.py:216: UserWarning: resource_tracker: There appear to be 2 leaked shared_memory objects to clean up at shutdown
warnings.warn('resource_tracker: There appear to be %d ’
/home/m4zz31/miniforge3/envs/kraken/lib/python3.9/multiprocessing/resource_tracker.py:229: UserWarning: resource_tracker: ‘/delay_sync_hwc_A’: [Errno 2] No such file or directory: ‘/delay_sync_hwc_A’
warnings.warn(‘resource_tracker: %r: %s’ % (name, e))
/home/m4zz31/miniforge3/envs/kraken/lib/python3.9/multiprocessing/resource_tracker.py:229: UserWarning: resource_tracker: ‘/delay_sync_hwc_B’: [Errno 2] No such file or directory: ‘/delay_sync_hwc_B’
warnings.warn(‘resource_tracker: %r: %s’ % (name, e))

logs/heimdall_daq_fw/rebuffer.log shows:

12:03:32 FATAL rtl_daq.h:62: IQ header read error

and logs/heimdall_daq_fw/delay_sync.log shows:

CRITICAL:main:Failed to acquire new data frame, exiting…

8

I confirm that after switching to latest stable versions (see below) all is working as expected.

Looks like some commits from Firmware project introduced some problems, as the DOA version being used was released less than one week ago, but who knows, maybe it’s something else.

I am unblocked but if there is some more info about the previous situation which can help the project please feel free to ask it out.

Versions used with behaviour as expected:
DAQ v3.1.0-a.1
DOA V1.8.0

Thanks! I consider this topic CLOSED. thanks.

1 Like