Owners of an MMDVM hotspot running Pi-Star can configure this hotspot as low power DAPNET transmitter too. During idle time when no QSO in digital mode is running, the hotspot will switch to the DAPNET frequency at set times to transmit pager messages.

In Pi-Star this can be configured via the special POCSAG section in the configuration screen. Call sign and authentication code have to be entered here. Be aware these credentials have to be requested separately! The credentials for the DAPNET website can’t be used to login a transmitter. 

But in this same section a line called ‘POCSAG Whitelist’ is included. It’s not clear for everyone how this works and how it can be used. Summarized this line includes the RIC the hotspot should transmit messages for. So this is a ‘include filter’ for DAPNET messages: only messages with a RIC listed in the whitelist are actually transmitted. But if no RIC is entered in this field, the hotspot transmits all messages offered via the network. The question is if and how this function makes sense? Why not just transmit every pager message?

First of all most MMDVM based hotspots are low power transmitters having between 10mW and 100mW output. Enough to serve their purpose: providing coverage around the house, office or mobile home. For more than that the small hotspots can’t be used. As this is the area where its owner moves around with the DStar or DMR radio, this will also be the area where the same owner moves around with a pager. As the coverage area of the hotspot is that small, there won’t be a lot of other pager owners who have to be served by the hotspot. In that context it doesn’t make sense at all to have the hotspot transmitting a lot of messages for users who won’t (ever) be in its coverage area. So it makes sense to have the hotspot only transmit information for its owner.

For the time the hotspot is transmitting DV traffic, no DAPNET messages will be transmitted. During a QSO the hotspot can’t switch quickly to the POCSAG frequency to transmit a batch of messages. In those cases a DV QSO takes some more time the amount of queued pagermessages will increase rapidly if there’s no filtering. As soon as the DV QSO has ended and the hotspot is available again it will start handling the backlog of DAPNET messages by transmitting them during the designated time slots. During this process oldes messages are transmitted first, but at the back side new messages are still queue via the network. This causes a huge delay in message delivery. Because DAPNET isn’t a ‘mission critical’ infrastructure, this is annoying but not dangerous. It can be rather pesky with the time synchronization: also those messages are queued, which causes a delay in time sync. So the pager start synchronizing its internal clock with old messages, so the clock will be out of sync.

The whitelist can help here. Most of the messages coming through the network are not addressed to the owner of the hotspot. Using the white list correctly ensures the hotspot will only transmit messages for its operator. During a DV QSO probably some DAPNET messages addressed to the hotspot owner will be queued. These backlog messages will be transmitted as soon as the DV QSO has ended, but in this scenario it will be only a hand full of messages. They can be transmitted within a few time slots. The size of the backlog and the time to get rid of it will be far less as in the scenario without white list.

It will be handy to include the RIC for the time synchronization in the whitelist too. So also when using the whitelist delayed time syncs will be transmitted. But because the queue is rather small the ‘outdated’ messages for the time sync will be transmitted much faster as well. As within 1-2 minutes an up to date time sync will be sent, the clock will be running out of sync much shorter.

Then the part of the regulations. Depending on the country a special permit can be needed to transmit messages ‘for others’. As the majority of the DAPNET messages is meant for others, there can be an issue with the regulations an amateur has to adhere to. In the Pi-Star configuration a hotspot can be set in ‘private mode’, so only its owner can use it (based on CCS7 ID). For DAPNET this can be done with the whitelist function: by including only the own RIC no messages for others will be transmitted.

The screenshot in the article shows a sample configuration. The RIC for time synchronization of the NEC 21/a (Skyper) is included as well as some fake RIC. Multiple RIC can be included comma separated.