RFM22/Si4432 Receiver

[ManoDaSilva]

Hi Kristoff,

Have you thought about implementing an RX feature? I'm considering doing this for DapNET, as an alternative to commercial pagers...

Regards,
Manoel - ON6RF

[sp2ong]

Hi,
It would be interesting to build low-cost an RX pager for DAPNET based on:

Arduino Pro MINI
Si4432 radio board
OLED or other low power DISPLAY TFT 1.8''
DC-DC adapter 1.5 -> 3.3 V
Power with 1.5 V

We can find example RX base on Si4432
https://www.rcgroups.com/forums/showthread.php?2114859-Cheap-Easy-DIY-openLRS-openLRSng-RX-TX-modules

73 Waldek SP2ONG

[on1arf]

Hi Waldek, Manoel, It has been a long time I have looked into this, but -as far as I see it- it is not possible to directly use a si4432 to receive native POCSAG-messages. Sending and receiving data with a si4332 uses a fixed packet-handler that is configured into the chip (see chapter 6 of the "si4330/31/32" datasheet). Using the packet-handler hardware in the si4332, it is not possible to get it to detect and recover a POCSAG-message. The format o the datapackets used by the si4332 "packet-mode" is very different from the format of a POCSAG-message. (*) (*) note. The reason it is possible to use a si4332 to *transmit* a POCSAG-message (in contrast to receive it), is because the complete POCSAG-message (including the 576 bits  sync-pattern) is encapsulated inside a si4332 + ReadHead datapacket. The data of the si4332 and RH datapacket that come before and after the POCSAG-message message are simply ignored by the commercial pocsag-pagers (or at least, the one I used to test this). These pagers just trigger on the sync-pattern of the POCSAG-message, and that's it. So, in fact, the POCSAG-pageing packets generated by a si4332 are strickly speaking not pocsag-packets. They are si4332/ReadHead packets that happen to contain a complete POCSAG-message. It's a bit of a dirty hack, .. but the pagers react to it .. so it works :-) Now, there is a "packet mode disabled" mode in the chip (see 6.4.1 of the datasheet)., but I have never used that. This would make the code completely incompatible with the ReadHead-library, so you would need to rewrite the great work of Mike for the low-level code of the RH library.. I have not said it is not possible; and -looking at 6.4.1., it might be possible to get this working, but would require quite some work and quite some testing. Do you have any experience with this so we can work on this together? 73 kristoff - ON1ARF

…

On 10-08-18 07:32, Waldek wrote: Hi, It would be interesting to build low-cost an RX pager for DAPNET based on: Arduino Pro MINI Si4432 radio board OLED or other low power DISPLAY TFT 1.8'' DC-DC adapter 1.5 -> 3.3 V Power with 1.5 V 73 Waldek SP2ONG — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1Aq7e9peZBd1N5H1oaCZEpBKeaYF3bks5uPRr7gaJpZM4V1T8E>.

[ManoDaSilva]

Hi Kristoff,

Thanks for coming back to us! That's what I thought; POCSAG receivers probably ignore the headers and just read what they need.

There's a direct mode indeed: but it seems it's TX only... Or I didn't find a mention of it in the Datasheet.
Other single-chip transceivers we could explore are:
-nRF905
-CC1101

Maybe there's something in those two that could allow us to receive those POCSAG frames directly and process them in a separate µController (example here)

73
Manoel

[ManoDaSilva]

Okay, apparently the CC1101 implements a "Packet Handling Disable" feature, that would allow us to handle the data directly on the µC: http://www.ti.com/lit/an/swra359a/swra359a.pdf

(BTW Kristoff, I think I met you in Brussels, during FOSDEM a while ago... I had a TETRA Repeater running, and showed you some homebuilt pagers :) )

[sp2ong]

Hi Kristoff and Manoel,

Kristoff, thank you for such a comprehensive explanation of the topic.
I do not have as much experience as you, but I was looking for a solution for building low-cost pagers to the DAPNET network. After explaining, si4432 is not suitable for this purpose.

But Manoel showed the CC1101 radio module which also has the support of 2-FSK and from the description, it can be used to build a pager to DAPNET. Description of using it with Arduino:
https: //www.electrodragon.com/w/CC1101

https://e2e.ti.com/support/wireless_connectivity/low_power_rf_tools/f/155/t/231753#
https://e2e.ti.com/support/wireless_connectivity/low_power_rf_tools/f/155/t/314400

73 Waldek SP2ONG

[ManoDaSilva]

That gives me motivation to get my mini-pagers out of the attic and start working on the software from scratch :)
https://hackaday.io/project/11056

73

[sp2ong]

Hi Manoel,

It looks promise. Maybe you need to add a buzzer to play a sound when a new message arrives.

[sp2ong]

Hi Manoel,

This is a very nice project and if it will work with the POCSAG protocol, we will have an alternative for commercial PAGERS. It would be good to have the Arduino Pro Mini.

[on1arf]

Manoel, (inline comments)

On 13-08-18 15:51, ManoDaSilva wrote: Hi Kristoff, Thanks for coming back to us! That's what I thought; POCSAG receivers probably ignore the headers and just read what they need.

Well, if you think of it, this does offer some nice options. Like, why not combine POCSAG with APRS? - build a single-frequency mesh-network - like APRS, have paging (in pocsag-format) repeated ("flooded") some 3 or 4 nodes further down the network - but, use standard FSK (instead of AFSK) so that standard POCSAG pagers can pick them up and react to them I had the idea to do this when experimenting with the 100 mW si4332 modules combining the "mesh-network" mode of the readhead-library with incapsulated POCSAG-messages. That way, you can build a large-scale paging-network based on many low-power mesh-network nodes (instead of one single high-power node, as is done now in most POCSAG-paging networks).

There's a direct mode indeed: but it seems it's TX only... Or I didn't find a mention of it in the Datasheet.

Do you mean for the si4332? If I read the datasheets correctly, there DOES is a RX-mode: 6.4. Packet Handler RX Mode 6.4.1. Packet Handler Disabled When the packet handler is disabled certain fields in the received packet are still required. Proper modem operation requires preamble and sync when the FIFO is being used, as shown in Figure 20. Bits after sync will be treated as raw data with no qualification. This mode allows for the creation of a custom packet handler when the automatic qualification parameters are not sufficient. Manchester encoding is supported but data whitening, CRC, and header checks are not.

Other single-chip transceivers we could explore are: -nRF905

The nRF905 uses GFSK instead of standard FSK and the bitrate is fixed to 100 Kbps: Modulation The modulation of nRF905 is Gaussian Frequency Shift Keying (GFSK) with a data- rate of 100kbps. Deviation is ±50kHz. GFSK modulation results in a more bandwidth effective transmission-link compared with ordinary FSK modulation. (page 24 of the nRF905 datasheet)

-CC1101

The CC1101 seams to be OK.

Maybe there's something in those two that could allow us to receive those POCSAG frames directly and process them in a separate µController (it's already being done with a Motorola RX board)

Other options are the RFM95/96/96/98 and sx1276/77/78/79. These chips are mainly used as lora-radios, but they can also do OOK and (G)FSK (and (G)MSK for the RFM-chips). Anycase, I have a number of these radio-chips to play around with, but I do not have a "real" POCSAG-transmitter to use as test-signal. But I I do have a hackRF so it should not be to difficult to create such a signal. I would really need to look into this.

73 Manoel

73 kristoff - ON1ARF

[on1arf]

Hi Waldek, Manoel,

On 13-08-18 17:40, Waldek wrote: Hi Manoel, This is a very nice project and if it will work with the POCSAG protocol, we will have an alternative for commercial PAGERS. It would be good to have the Arduino Pro Mini.

Question. (just to get an idea how you two see this development). What do you see as  the main reason to develop an open-source pager? Is it because the commercial pagers are to expensive, to difficult to get, .. or is it to develop new features (for ham-radio paging) If the goal is to develop something completely new, I wonder if it makes sence to go the further than then just copying the existing POCSAG-networks. I think interesting options would be to use a more modern modulation-sceme (like lora), two-directional paging-network (rx and tx) or incorperate it somehow into the APRS network. How many commercial pagers would there currently be in use by hams for the ham-radio pocsag paging networks? Manoel, Yes; your name did surely ring a bell, but for some reason I did not find your name in my email-archive concerning FOSDEM so I wasn't sure it was indeed you. BTW. I will probably start the procedure to request an infobooth on amateur-radio at FOSDEM 2019. So, If we get permission from the people of FOSDEM for the infostand, and you are interested to join our booth, feel free to drop me a message in a couple of months. 73 kristoff - ON1ARF

[ManoDaSilva]

Hi Kristoff,

My idea is to develop a multi-mode transceiver, capable of handling basically whatever FSK/GFSK/ASK data we throw at it. POCSAG and APRS would be the two main standards I'd like to implement. You are also right, I'd also like to offer an alternative to commercial POCSAG receivers...

I started this project without much ambition in 2016 (or was it 2015?): a simple arduino µC, an OLED display and a CC1101. I was mainly focusing on hardware, and didn't give much thought on the actual infrastructure. Got bored and shelved the project.
In the meantime, I worked on small AFSK1200 modems (with a modified AX.25 layer) which were heavily based on Mark Qvist's work. The main use was on Red Cross preventive actions, where we needed to transfer simple text lines with victims data between remote locations, and avoid using Internet (4G can be a problem in crowded areas, such as a concert in the Heysel stadium). We now use it more and more.

A year ago, Xavier ON7RX had an idea of using existing UHF repeaters to transmit/receive APRS data (why APRS? because it's easy to interface with basic radios, you just need to "patch" into the audio path, no need for direct mod/discriminator access). The pagers would have a list of repeaters in a given area and select the best one based on RSSI. That's what gave us the idea to merge an AFSK1200 micromodem with my original pager idea. We switched the CC1101 for a DRA818 (1W output power is a huge plus), and implemented the micromodem in the audio path. Xavier also wrote a web API, implemented a "mailbox" system, along with some other bells and whistles. As we're having troubles with the STE feature enabled by default on those modules (along with the low-pass filters on the Mic input), we didn't work on it that much in those last months.

Seeing your project made me think about implementing this solution on a single-chip radio again, with an additional PA if needed.... It could be interesting to have one radio that could be switched between POCSAG pager mode, APRS pager mode, [insert custom datamode here], etc. DRA818 modules basically limits you to AFSK, not the SI4432. I saw somewhere an APRS-SI4432 library for Arduino, I'll try to find it again...

Back to the SI4432:
You're absolutely right! I completely missed that part! If I got the datasheet right, we can use two different modes for our purpose:
-Direct mode (section 4.2.2): through the GPIO, we can toggle a pin in TX mode and directly command the FSK modem, and receive unbuffered data from the modem in RX mode. It requires some fiddling with registers 33h, 35h and 71h, and setting the GPIO2 pin (register 0Dh) to an RX (or TX) IO. I think it can be done by slightly modifying the Radiohead library.
-Packet handling disabled, FIFO mode: the sync bytes are ignored, and the packet is stored as is in the buffer. It probably would need to be regularly emptied, when we see how big POCSAG messages can get. Don't know much about that one; I'm not really used to manipulating buffers TBH.

73,
Manoel

[sp2ong]

Hi,

I have found example used SX1278 (RFM96/98 radio module)
https://teknokoodiradio.vuodatus.net/lue/2017/06/semtech-sx1278-fsk-packet-mode-decoding-with-arduino

At current when POCSAG transmission is available in MMDVM project ( https://hampager.de/dokuwiki/doku.php?id=mmdvm ), we can be observed growing up numbers of transmitters POCSAG on map https://hampager.de/#/.
We are looking to build ham radio receiver pager where we can adjust receiver frequency to local POCSAG the transmitter. The commercial pagers, not all allow setup receiver frequency on ham radio band plan.
We can use DAPNET to send messages to Emcom members or other solutions.

73 Waldek

[on1arf]

Waldek, Manoel, Interesting. Now. I do not know if this is the best place to discuss this further. I propose to contact you both offlist and contintue the discussion further that way. I will then close this ticket. BTW. I am currently working on a gnuradio python embedded block for pocsag, so I can generate a good test-signal and use that to test the different radio-modules I have lying around. 73 kristoff - ON1ARF

…

On 14-08-18 11:08, Waldek wrote: Hi, I have found example used SX1278 (RFM96/98 radio module) https://teknokoodiradio.vuodatus.net/lue/2017/06/semtech-sx1278-fsk-packet-mode-decoding-with-arduino At current when POCSAG transmission is available in MMDVM project ( https://hampager.de/dokuwiki/doku.php?id=mmdvm ), we can be observed growing up numbers of transmitters POCSAG on map https://hampager.de/#/. We are looking to build ham radio receiver pager where we can adjust receiver frequency to local POCSAG the transmitter. The commercial pagers, not all allow setup receiver frequency on ham radio band plan. We can use DAPNET to send messages to Emcom members or other solutions. 73 Waldek — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1AqwifeRtxLvRvkjABTUb_-yiifyqEks5uQpORgaJpZM4V1T8E>.

[Rashen2001]

Is it possible to implement the Tetra network on Arduino? Parsing SDS messages from the TETRA network ? what iron to choose for this?