Innovatie PDW | nieuwe PDW 2026

[flopper]

Probleem bleek hem te zitten in het stekkertje van de interface....  

Ales draait weer op 100%.

In de recentere versies zit een RX mail alert, die kan je inschakelen dan heb je er geen omkijken naar en krijg je mail als het stekkertje weer los ligt.

[flopper]

Met MySQL ondersteuning...

Persoonlijk zou ik het graag in een SQLite database hebben staan, die is file based en heeft dus geen verdere server functionaliteit nodig.
De sqlite3.dll bevat alles wat nodig is.

Zit in 3.5.7 met hetzelfde DB schema als voor MySQL, wil jij het testen en terug rapporteren?

https://www.dropbox.com/scl/fi/58h2t4c7naxv1ggu1l0f8/pdw3.5.7.exe?rlkey=es1hx22b8our06jm8z6xo18me&dl=0

Code: [Selecteer]

### SQLite output

Persists all decoded messages to a local SQLite database file. **Zero external DLL dependencies** — the SQLite amalgamation (`sqlite3.c`) is compiled directly into PDW. No server, no installer, no runtime required.

The schema mirrors the MySQL Optimized layout exactly, making it easy to switch between the two. `capcode` is `TEXT` to preserve leading zeros for POCSAG addresses (same rationale as MySQL CHAR(9)).

**Schema:**

```sql
CREATE TABLE IF NOT EXISTS "alarmeringen" (
    id          INTEGER PRIMARY KEY AUTOINCREMENT,
    ontvangen   TEXT    NOT NULL DEFAULT '',   -- 'YYYY-MM-DD HH:MM:SS'
    capcode     TEXT    NOT NULL DEFAULT '',   -- leading zeros preserved
    mode        TEXT    NOT NULL DEFAULT '',
    msg_type    TEXT    NOT NULL DEFAULT '',
    bitrate     INTEGER NOT NULL DEFAULT 0,
    message     TEXT    NOT NULL DEFAULT '',
    label       TEXT    NOT NULL DEFAULT '',
    subscribers TEXT    NOT NULL DEFAULT '',
    match_type  INTEGER NOT NULL DEFAULT 0,
    label_color TEXT    NOT NULL DEFAULT ''
);
CREATE INDEX IF NOT EXISTS idx_alarmeringen_capcode   ON alarmeringen(capcode);
CREATE INDEX IF NOT EXISTS idx_alarmeringen_ontvangen ON alarmeringen(ontvangen);
CREATE INDEX IF NOT EXISTS idx_alarmeringen_match     ON alarmeringen(match_type);
CREATE INDEX IF NOT EXISTS idx_alarmeringen_label     ON alarmeringen(label);
```

**Default file path:** `<PDW exe directory>\pdw.db` (configurable).

**Best-practice defaults applied automatically:**

| PRAGMA | Default | LowWrite mode |
|--------|---------|---------------|
| `journal_mode` | `WAL` | `WAL` |
| `synchronous` | `NORMAL` | `OFF` |
| `auto_vacuum` | `INCREMENTAL` | `INCREMENTAL` |
| `wal_autocheckpoint` | 1000 pages | 10000 pages |
| Commit cadence | every message | ~15 s batched |

**LowWrite mode** (`Options → SQLite → Reduce NVMe writes`): commits are batched every ~15 seconds instead of per message. Significantly reduces write amplification on SSDs. Trade-off: up to 15 seconds of messages may be lost on a hard crash or power failure.

**Automatic maintenance** (runs once per hour in the worker thread, off by default):

| Option | Description |
|--------|-------------|
| `PurgeDays` | Delete rows older than N days |
| `MaxSizeMB` | Delete oldest rows until the file is under this size |

Both options are disabled by default — PDW never deletes data without explicit configuration.

**Other features:**
- Writes via prepared statement with bound parameters — no SQL-injection risk
- Worker thread + 64-slot ring buffer (decoder never blocks)
- Connection test button in the settings dialog
- Optional activity log (`pdw_sqlite.log`)
- Field bitmask — write only the columns you need



[Faramir]

...wil jij het testen en terug rapporteren?

Niet alle velden worden consequent gevuld (label/subscriber), zie de afbeelding.
De kolom met FLEX-A en 1600 hoeven wat mij betreft er niet bij te zitten, die zijn voor zover ik weet altijd hetzelfde.
Misschien een optie om de ontvangen data op te splitsen in meerdere tabellen?
Denk bv aan capcode/opties/label in een tabel, messages/timestamps in een tabel, disciplines/kleursetting etc.
een en ander allemaal aan elkaar verbonden door bv een unieke CapCodeID die in elke tabel wordt gezet.
Veel data komt immers vaker terug en zo gesplitst is de hoeveelheid informatie die redundant in de database staat veel kleiner.
Moet ik eens goed over nadenken welke tabellen/relaties erbij komen kijken.

Een andere optie zou kunnen zijn om de filters.ini te vervangen door uit de database opgevraagde data.
Je zou dan in realtime de filters.ini entry voor die capcode kunnen samenstellen en toepassen. Dan is PDW compleet database gestuurd.

[flopper]

...wil jij het testen en terug rapporteren?

Niet alle velden worden consequent gevuld (label/subscriber), zie de afbeelding.
De kolom met FLEX-A en 1600 hoeven wat mij betreft er niet bij te zitten, die zijn voor zover ik weet altijd hetzelfde.
Misschien een optie om de ontvangen data op te splitsen in meerdere tabellen?
Denk bv aan capcode/opties/label in een tabel, messages/timestamps in een tabel, disciplines/kleursetting etc.
een en ander allemaal aan elkaar verbonden door bv een unieke CapCodeID die in elke tabel wordt gezet.
Veel data komt immers vaker terug en zo gesplitst is de hoeveelheid informatie die redundant in de database staat veel kleiner.
Moet ik eens goed over nadenken welke tabellen/relaties erbij komen kijken.

Bedankt voor de feedback. Wat je beschrijft is al aanwezig in de huidige implementatie?

-Lege label/subscribers bij ALPHA-rijen is correct gedrag labels verschijnen alleen als er een filter-match is met een toegewezen label, en subscribers wordt alleen gevuld bij GROUP-capcodes. Alpha-berichten zonder filter-match hebben geen van beide.
-Opsplitsen in meerdere tabellen is met het huidige schema al mogelijk zonder PDW aan te passen: de id-kolom is een unieke sleutel per bericht, capcode is de natuurlijke sleutel voor een capcode-tabel, en de subscribers-kolom bevat al een JSON-array met alle gekoppelde capcodes en labels van een groepsbericht. Een externe query of view kan op basis daarvan precies de genormaliseerde structuur opbouwen die je beschrijft.
-Disciplines en kleurinstellingen zitten al per rij in label en label_color ook die zijn direct bruikbaar als basis voor een aparte referentietabel buiten PDW.

Als je iets ziet dat hier niet mee overeenkomt, helpt een concreet voorbeeld met capcode en tijdstip om het te reproduceren.

-Kolomselectie (mode, msg_type, bitrate, message, label) is volledig geďmplementeerd via checkboxen in het SQLite-instellingendialoog. Vink een kolom uit om hem uit alle inserts te houden.

Een andere optie zou kunnen zijn om de filters.ini te vervangen door uit de database opgevraagde data.
Je zou dan in realtime de filters.ini entry voor die capcode kunnen samenstellen en toepassen. Dan is PDW compleet database gestuurd.

Lastig, want dan moet je over conversiepaden van filters.ini na gaan denken en alle logica om de GUI elementen op aan te laten haken. Ik heb 13.000 filters die moeten dan in de DB komen, kan allemaal wel. Maar ik zie geen functioneel voordeel anders dan nice-to-have? Ik heb in alle coding sprints rekening gehouden met het behouden van filter.ini.

[Faramir]

Helder, verdere opsplitsing kan inderdaad ook achteraf. Ik heb inmiddels 7600 codes in een nieuwe tabel staan, was een klusje van nog geen 5 minuten en vanuit daar kan ik verder specificeren.
Dank je wel voor je supersnelle implementatie van SQLite!! Ik heb nu alle mogelijkheden en ga op m'n gemak verder tabelletjes bouwen en kijken hoever ik kan komen.

[flopper]

Helder, verdere opsplitsing kan inderdaad ook achteraf. Ik heb inmiddels 7600 codes in een nieuwe tabel staan, was een klusje van nog geen 5 minuten en vanuit daar kan ik verder specificeren.
Dank je wel voor je supersnelle implementatie van SQLite!! Ik heb nu alle mogelijkheden en ga op m'n gemak verder tabelletjes bouwen en kijken hoever ik kan komen.

Top! Ik heb de DB layout gedeeld met je, als je vastloop kan je dat stukje code in AI plakken en je krijgt gratis tips terug hoe je verder moet.


Hier alvast een knipsel van de final readme.md op GitHub later deze maand.

Code: [Selecteer]

```sql
-- Latest 100, newest first
SELECT * FROM alarmeringen ORDER BY id DESC LIMIT 100;

-- Live polling (only newer than the last seen id)
SELECT * FROM alarmeringen WHERE id > :since ORDER BY id DESC LIMIT 50;

-- One capcode (capcode is CHAR(9) -- pass as string, e.g. '1234567' or '012345678')
SELECT * FROM alarmeringen WHERE capcode = :cc ORDER BY id DESC;
-- Also as a group member (indexless LIKE):
--   WHERE capcode = :cc OR subscribers LIKE CONCAT('%"capcode":"', :cc, '"%')

-- Only matched/filtered messages
SELECT * FROM alarmeringen WHERE match_type >= 1;

-- Full-text search across message and label
SELECT * FROM alarmeringen
WHERE MATCH(message, label) AGAINST (:q IN BOOLEAN MODE)
ORDER BY id DESC LIMIT 50;
```

[SeaSparks]

Misschien stomme vraag, maar is het filterscherm ook zo te maken dat de grootte instelbaar is?

[flopper]

Misschien stomme vraag, maar is het filterscherm ook zo te maken dat de grootte instelbaar is?

Tja dat is allemaal hardcoded, ik kan er eens een blik op werpen.

Ben vandaag vooral bezig geweest met het finalizen van de code, nog wat bugs eruit gehaald naar externe systemen met grote groepsoproepen en te weinig gereserveerde ruimte. En ik heb runs gemaakt op Nederlandse woorden en daar kwam ook nog wel e.a. uit.

Het optimized DB schema heeft ook Nederlandse woorden, dat heb ik over het hoofd gezien omdat ze afgeleid zijn van de classic en extended van dit forum. In middels gefixed maar dat betekent dat je wel je DB moet omzetten als je de nieuwe versie draait.

Wijzigingen in het optimized schema (MySQL and SQLite):

Old	New
table alarmeringen	table messages
column ontvangen	column received
column capcode	column address
JSON key "capcode" in subscribers	"address"

Classic en Extended schemas zijn niet gewijzigd.

MySQL migration

Code: (sql) [Selecteer]

ALTER TABLE `alarmeringen`
  CHANGE COLUMN `ontvangen` `received` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;

ALTER TABLE `alarmeringen`
  CHANGE COLUMN `capcode` `address` CHAR(9) NOT NULL DEFAULT '';

RENAME TABLE `alarmeringen` TO `messages`;


PDW.ini -- update voor [MySQL] en [SQLite]:

Code: [Selecteer]

Table=messages