Other pager protocols

[ellisgl]

The pager example only looks to generate POCSAG protocol output. There are several other protocols, but one of the other prominent protocols is the Motorola FLEX protocol. It would be nice to have support for that protocol.

Informational links:
https://en.m.wikipedia.org/wiki/FLEX_(protocol)
http://www.jelmerbruijn.nl/motorola-flex-p2000-decoding/flex-sync-and-header/
https://www.braddye.com/pager.php

Software Examples:
https://github.com/jjwbruijn/POCSAG_FLEX_Modem
https://github.com/dl1com/flex
https://github.com/unsynchronized/gr-mixalot

[jgromes]

Ah, the good ol' "wouldn't it be nice if ..." - the origin point of all feature creep ;)

I'm not totally opposed to the idea of adding FLEX (and of course, PRs will be welcome). However, I would need to see a specific use case as opposed to just "it would be nice".

[ellisgl]

I happen to have a couple Flex pages in the 900MHz I wanted to play with.

[jgromes]

Well I'm not stopping you - feel free to fork the library and build on top of the radio drivers and cryptography modules, so that you can focus on the protocol itself. Again, PRs will be welcome. But if it's just one person that says "it would be nice" then I can't realy justify working on this, at the very least not now.

[htotoo]

+1 would love to see it :)

[ellisgl]

After discussion, apparently it kind of a pita, since you have to keep a constant stream going. I decided to buy a GP2009N POCSAG pager and have it program to the 915 MHz range (916.175 MHz).

[rlaneth]

Hi everyone,

I've been successfully using RadioLib to transmit FLEX messages by encoding them externally and then transmitting via a TTGO LoRa32-OLED v2.1.6 board (with ttgo-fsk-tx).

Until recently, the encoder I had been using was gr-mixalot, but it is unmaintained, presents several bugs and lacks support for FLEX's long address format—capcodes that may have up to 9 digits, falling outside of the short address range.

Thus, a friend of mine (@Theldus) has taken it upon himself to develop and maintain a tiny C library for FLEX encoding, called tinyflex. I’ve been testing it myself with great results.

I'm interested in developing an open pager transmitter firmware for the TTGO. Instead of using RadioLib for only POCSAG and as an FSK transmitter for an external FLEX encoder, I would love to bring the FLEX encoding feature into RadioLib itself so that other users of the library can benefit from it.

There are, however, a few challenges with the FLEX protocol, which is likely the reason why there aren't many open source encoders and transmitters out there in the first place!

First off, the spec talks of 4FSK modulation at up to 9600 bps. The reason why it is possible to successfully transmit FLEX with the TTGO in the first place is because of a 2FSK 1600 bps mode that Motorola apparently designed for retrocompatibility with existing pager transmitter infrastructure back in the day.

Then, as @ellisgl has rightly pointed out, according to the spec, there's supposed to be a somewhat continuous transmission. The protocol is designed so that the pager synchronizes its internal timing to that of the transmitter and only wakes up at the specific time slots where the transmitter could be broadcasting a message intended to said pager. If there's no message, there is still supposed to be something—e.g an idle frame.

But the developers of gr-mixalot seem to have found a hack.

According to available FLEX spec documents, there's an emergency resynchronization (ERS) sequence that causes pagers to resynchronize with the transmitter (see “Emergency Re-synchronization Transmission” in the linked document). The pager is supposed to wake up during its regular time slot, notice the ERS and resynchronize from there. Depending on the pager's specific configuration (see the “Collapse” references in the FLEX spec), this could take up to four minutes.

In practice, however, an ERS sequence appears to cause most, if not all, FLEX pagers to wake up immediately. As such, the trick to sending a single message without a continuous transmission is doing a short burst of ERS and following it with the message frame.

This is not what the spec says should be done, but it works on all the pagers I could test against, which were Motorola models, including the Jazz and the Advisor Elite, and a more recent one from Sun Telecom, the Titan-III.

Considering this, my proposal for RadioLib would be to:

1. Limit the scope to 2FSK 1600 bps
2. Have the library produce valid FLEX frames, but not take care of timing—it would be up to the user of the library to either write a timing mechanism that fits the frames into their proper time slots, or to use the ERS hack

These details would have to be extensively documented. A usage example with the ERS hack must be included to avoid confusion, especially for those who don’t care about the theoretically proper implementation and just want a copy-paste solution.

@jgromes, thoughts? If this sounds good and fits RadioLib’s goals, I’d be happy to submit a PR.

Cheers.

[jgromes]

@rlaneth that's an interesting proposal - gotta admit I do like the hacky nature of this. The first point could in theory be implemented fully using hardware that does support 4FSK - currently it is only the CC1101, though in the future, the brand new LR2021 LoRa transceiver should be able to do that as well. So maybe that could be an option for extension, with 2FSK being the default.

Regarding the timing, I'm not sure what are the exact requirements in terms of the synchronization between the transmitter and receiver, as I did not really study the FLEX specification. Though I will point out that the LoRaWAN implementation also has to deal with sending data in defiend time slots between the transmitter and receiver by the nature of that protocol (downlinks from gateways to end devices are only allowed in certain time slots after uplinks from end devices). So if it something similar, it could be a source of inspiration.

[rlaneth]

@jgromes great to know that these radios are capable of doing 4FSK!

That said, FLEX requires quite a few changes in encoding (e.g. in block interleaving) for modes beyond 1600 bps/2FSK, so I won't be focusing on that immediately.

I'll follow on with the implementation, then. I'll open a PR once I get working, tested code.

Cheers.