Exception when alarm goes off

[ninjas28]

It seems if the dose rate alarms are configured then the device sends additional data that the webserver example is not designed to handle?

I get a couple of different errors when I activate the alarm

Rates updated, sending to 0 connected clients
Task exception was never retrieved
future: <Task finished coro=<process() done, defined at /usr/local/lib/python3.7/dist-packages/radiacode-examples/webserver.py:42> exception=Exception('BytesBuffer: 7 bytes required for <BBBi, but have only 6')>
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/radiacode-examples/webserver.py", line 46, in process
    databuf = app.rc_conn.data_buf()
  File "/usr/local/lib/python3.7/dist-packages/radiacode/radiacode.py", line 123, in data_buf
    return decode_VS_DATA_BUF(r, self._base_time)
  File "/usr/local/lib/python3.7/dist-packages/radiacode/decoders/databuf.py", line 14, in decode_VS_DATA_BUF
    seq, eid, gid, ts_offset = br.unpack('<BBBi')
  File "/usr/local/lib/python3.7/dist-packages/radiacode/bytes_buffer.py", line 18, in unpack
    raise Exception(f'BytesBuffer: {sz} bytes required for {fmt}, but have only {len(self._data) - self._pos}')
Exception: BytesBuffer: 7 bytes required for <BBBi, but have only 6

or sometimes I get

Rates updated, sending to 0 connected clients
Task exception was never retrieved
future: <Task finished coro=<process() done, defined at /usr/local/lib/python3.7/dist-packages/radiacode-examples/webserver.py:42> exception=Exception('seq jump, expect:86, got:48')>
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/radiacode-examples/webserver.py", line 46, in process
    databuf = app.rc_conn.data_buf()
  File "/usr/local/lib/python3.7/dist-packages/radiacode/radiacode.py", line 123, in data_buf
    return decode_VS_DATA_BUF(r, self._base_time)
  File "/usr/local/lib/python3.7/dist-packages/radiacode/decoders/databuf.py", line 17, in decode_VS_DATA_BUF
    raise Exception(f'seq jump, expect:{next_seq}, got:{seq}')
Exception: seq jump, expect:86, got:48

[davidcarlsonSEE]

Yep I get the error too. It's in def decode_VS_DATA_BUF(

I grabbed a screen shot while debugging with Visual Studio Code on Windows 11 Linux subsystem with a shared USB.

def decode_VS_DATA_BUF(
    br: BytesBuffer,
    base_time: datetime.datetime,
) -> List[Union[RealTimeData, DoseRateDB, RareData, RawData, Event]]:
    ret: List[Union[RealTimeData, DoseRateDB, RareData, RawData, Event]] = []
    next_seq = None
    print(f"decode_VS_Data br={[br._data.hex()]}")
    while br.size() > 0:
        seq, eid, gid, ts_offset = br.unpack('<BBBi')
        dt = base_time + datetime.timedelta(milliseconds=ts_offset)
        if next_seq is not None and next_seq != seq:
            raise Exception(f'seq jump, expect:{next_seq}, got:{seq}')

Here are the readings as a hex string before alarming the Radiacode 103. Inside the [] brackets
[4700000026080092010000003b0000001d0000e5000000496dc540f50d27373c00c2004020001e0101002200000300320000000000c040c28627380000c040e02d103600000040e02d9035]

Here are the readings during alarm.
[7700000026080092010000006b0000002b00002d2700000080f243bb27c33a5900a0004222092c0101e82500000900320000000000fe43bec1cf3a0000e04368919d3a0000ec43c364b23a0000ee43a167eb3a0000f8437cf2c83a0000f24370cea03a00000144b7d1c83a0000e343bf7dbd3a0000e443ba49b43a]

[davidcarlsonSEE]

I "think" what is happening is the usb read is not handling multiple blocks of data when this happens. If you just print the message and return ret the next readings read works.

There's a couple of other times this happens, but only when you move the radiation source close and far from the device to trigger alarm values. I find when this happens with other radiation meters it's because the devices take and extra second to perform their internal calculations.

        if next_seq is not None and next_seq != seq:
            print(f'seq jump, expect:{next_seq}, got:{seq}')
            return ret
            #raise Exception(f'seq jump, expect:{next_seq}, got:{seq}')

[kanefron5]

The same issue. Any workaround?

[davidcarlsonSEE]

No I don't have a python workaround.
What I did was to print a message and return just skipping the problem. I know it's a lazy thing, but I was using the python to help me develop an android version in java.

[ckuethe]

my workaround is to wrap it in an exception handler and keep reading. I haven't tried to decode the alarms