Pocket POCSAG Transmitter

1 reply [Last post]
EverestX
EverestX's picture
Offline
SX Crew
Joined: 2009/05/15

Fair warning, this is a lot of words for a very simple PCB and code that's not mine. I wanted to share a lot of thoughts on how I arrived at certain conclusions and try to answer questions up front rather than gate keeping or trying to do a dozen one off responses. The .PCB file is attached here as "SX_Pocket_Pager.zip"

Background:

Several years ago I began reminiscing over the simple life of a pager. Basking in the ability to avoid direct vocal contact, read receipts, and respond at my leisure it hit me. I needed a small, highly portable, battery powered POCSAG transmitter that could be programed and charge itself over USB. It needed to be as powerful as possible while supporting various antenna options. The design itself needs to work for all 3 bands easily for global consumption and as it is mobile it also needs to able to generate the outbound messages from my cell phone so I could send phallic ascii art to recipients on the go.

Finding Gold:

Solving the POCSAG transmissions itself was easy, there's an old release (circa 2014) that does exactly that. It leverages Radiohead which is incredibly well documented as an added bonus. There is also a HAM version for those of you who may be interested in potential use for DAPNET. To be clear - this isn't my code. Not so much as a fork. I simply devised a *very tiny*, lipo powered, and Bluetooth connected PCB to integrate with it.

	Shout out to ON1ARF for the code. 
	https://github.com/on1arf/pocsag 

Lets make a shitty PCB: (and not release it for literal years)

The earliest working portable POC was filled with a mix of SMD and THT components due to parts on hand. A raw 32u4 (which has some memory issues with the code - more on that later), voltage dividers (5v vs 3.3v logic which both the RF module and HC-05 modules need), a lipo charger IC that is borderline impossible to solder by hand, etc. A functional POC but a miserable and unattractive build. After sending my first successful message I elated in the fact it worked but immediately came to a realization. Sure, I could build this but how would my friends also be able to send me immature messages as if we were a ad-hoc pager network of giggling children? I guess I'll make a PCB.

PCB:

3D
Kicad

Example Builds:
Male
Female
Example

Where from here?:

The fact of the matter is that it has been a handful of years since I showed this to some pager nerds in dark corners of the globe. Unfortunately life and job often gets in the way for me so enough is enough. I'm happy to say I'm done sitting on this PCB (admittedly a shitty PCB compared to some additional improvements I have on the backburner). I found a couple hours to dedicate to release and want other people to start poking and prodding. There is a huge opportunity to greatly enhance the existing codebase and functionality of the current pcb which is why I'm dropping it to everyone. Enhancements to the code, supported message types, etc are all feasible with this relatively simple design.

Bill of Materials: [As tested working]

	1 x Teensy LC (or 3.1)
	1 x SoldierX Pocket Pager PCB. 
	1 x RFM23BP ISM Radio Transceiver (RFM22 and RFM23B may work with a few minor changes)
	1 x HC-O5 Bluetooth Module 
	1 x 2.54mm Pinheaders and additional female headers to be able to easily remove 
	1 x appropriately pinned JST battery for Featherwing

About the Hardware:

You like Tolerances?
It's hard to express just how jam packed this featherwing board is, perhaps even pushing the tolerances a bit. The RFM23bp *barely* fits in between the feather pins. You may even need to give your pin headers or the side of the RF module a quick file to fit correctly. The HC-05 is no different. With that in mind, it seemed entirely logical to stuff all that, an SMA connector, and a pile of jumpers all in ~2" X 1" to me.
Note: this is an older PCB design and a 32u4 shown but for a better idea on just how tight

size

Why a Featherwing?
The Feather series has a lot of major perks making it an easy choice - a small form factor, massive availability, 3.3v logic, great community support, numerous mcu options for long term support, USB programming, built in lipo charger, battery voltage monitoring, the list goes on. I'll acknowledge the featherwing standard does have some aspects I am not a fan of. For example I avoided the use of the so called "Free Pin" even though I needed to solder a wire (bodge) directly on the teensy adapter board as a result of face palms like this:
'Free' Pin - This is the pin to the right of TX. You can use it for an extra GPIO or if you have some onboard module that has a useful breakout. Sometimes we tie it to ground.
SRC: https://learn.adafruit.com/adafruit-feather/feather-specification

Why a Teensy?
The Teensy is purely overkill. I have hopes longer term to add much more support to the current code (such as receive support) and want to make sure hardware isn't the limiting factor. Yes it costs a couple bucks more and you may pull off functionality on a 32u4 but for future proofing this seemed like the best place to start. I also have a pile of them so consider this partially selfish interest.

Why the RFM32BP?
While the ON1ARF code should work with the standard RFM22 and the 23B (non-P version), the 23BP has a leg up with a built in amplifier (PA). If you wished to only use this with a dedicated external amp, the RFM22 is a better choice as you don't need the extra power.

	For the sake of comparison
	RFM22: Configurable +8 to +17 dBm 
	RF23BP: Configurable +10 and +30 dBm (The lower output is up for debate but output is up to 1 Watt) 
	Note: read on for some very interesting possible improvements to that 1W number

Why the HC-05 drop in module?
Cost and Accessibility. This thing is literally everywhere. I also have about 100 of them. The HC-05 can be found as a smaller capsulated board that would have saved some space on the PCB however they are a bit more difficult to buy in small quantities in this format without costing more than the "full size" breadboard compatible version or waiting on the sailboat from across the globe. There is a trade off however, there are some additional components that use some additional battery power that are largely unneeded.

Why do I have to solder 1 wire?
As mentioned above, the featherwing design that while I understand I don't always appreciate. The use case of CS pins. There are ways to work around this CS pin in the code but I didn't opt to fork the originating code.

SRC: https://learn.adafruit.com/adafruit-feather/feather-specification
SCK/MOSI/MISO - this should be your main SPI bus. 3.3V logic. If you share these with devices on the main featherwing, keep the CS pin from being exposed so that you don't have SPI bus contentions.

Why is the battery directly connected to the power on the RF module and the HC-05?
The RFM23BP alone can pull in excess of 550mA which exceeds the default 3.3v regulator output. Stacking the HC-05 on top, pushes it even further beyond built in limits. I have been able to send at configured 30dB output successfully on a charged lipo without issues but be aware at full power on a low battery you may experience odd behavior. To avoid issues with lower battery voltages sticking with 27dBm is the safest bet as 3.3v is capable of this without issues (allegedly).

Ref: https://www.airspayce.com/mikem/arduino/RadioHead/RH__RF22_8h_source.html

	/// CAUTION: the high power settings available on the RFM23BP require
	/// significant power supply current.  For example at +30dBm, the typical chip
	/// supply current is 550mA  [...] If you use this chip at high power make sure
	/// you have an adequate supply current providing full 5V to the RFM23BP (and
	/// the CPU if required), otherwise you can expect strange behavior like
	/// hanging, stopping, incorrect power levels, RF power amp overheating etc. [...]
	/// Note: with RFM23BP, the reported maximum possible power when operating on 3.3V is 27dBm.

Full disclosure there is an interesting note to be aware of following that about power output. I haven't tested extensively with lower output on the 23BP but want to make sure to call it out:

	/// The BP version is an RFM23 with a PA 
	/// external to the Silicon Labs radio chip.  
	/// The RFM23BP only supports the top three power settings because those three 
	/// output levels from the RFM23 provide enough drive to the PA to make it 
	/// saturate.  Less drive and the PA will dissipate more heat.  However, those 
	/// three levels don't change the output power from the PA.

Why 3.3v logic? (or 3v3 if you prefer)
Out of abundance of caution. Many off shelf RFM23BP's handle 5v just fine but not all. Once again the Radiohead docs has some useful insight for application on the RF module itself.

	
	/// Caution: some people have had problems with some batches of
	/// RFM23BP chips burning out their nIRQ outputs for unknown
	/// reasons when run at 5V. Some users assert that running RFM23BP with voltage
	/// dividers at 3.3V is to be preferred. We have not tested or verified
	/// either the cause or the supposed cure.

FAQ:

Can I purchase these assembled?
At least from me, or SoldierX.com atm no.

Can it RECIEVE POCSAG messages?
No.

Does it work with FLEX?
No (at least with the aforementioned code).

Can you adjust the power?
Yes, the radiohead library and RFM23BP both "support" adjustment of output between +10 and +30dBm. See notes on power output above.

Examples are available in the Radiohead docs:
https://www.airspayce.com/mikem/arduino/RadioHead/RH__RF22_8h_source.html

	
	// RFM23B only:
	#define RH_RF22_RF23B_TXPOW_M8DBM                  0x00 // -8dBm
	#define RH_RF22_RF23B_TXPOW_M5DBM                  0x01 // -5dBm
	#define RH_RF22_RF23B_TXPOW_M2DBM                  0x02 // -2dBm
	#define RH_RF22_RF23B_TXPOW_1DBM                   0x03 // 1dBm
	#define RH_RF22_RF23B_TXPOW_4DBM                   0x04 // 4dBm
	#define RH_RF22_RF23B_TXPOW_7DBM                   0x05 // 7dBm
	#define RH_RF22_RF23B_TXPOW_10DBM                  0x06 // 10dBm
	#define RH_RF22_RF23B_TXPOW_13DBM                  0x07 // 13dBm
	// RFM23BP only:
	#define RH_RF22_RF23BP_TXPOW_28DBM                 0x05 // 28dBm
	#define RH_RF22_RF23BP_TXPOW_29DBM                 0x06 // 29dBm
	#define RH_RF22_RF23BP_TXPOW_30DBM                 0x07 // 30dBm

Will a wire antenna work?
Ehhh, Kinda. The short answer is yes I have successfully sent messages at lower output power however impedance is a concern. Do not try to rock 30dBm on a small wire. SMA or a directly soldered antenna *highly recommended*.

	
	Radiohead Docs https://www.airspayce.com/mikem/arduino/RadioHead/RH__RF22_8h_source.html
	///	Connecting a simple 1/4 wavelength (ie a 17.3cm single wire)
	/// directly to the antenna output will not work at full 30dBm power,
	/// and will result in the transmitter hanging and/or the power amp
	/// overheating.

Is it Legal?
I can't speak for your local laws - It may or may not be depending on locale. I strongly recommend that you verify this prior to transmitting and accept no responsibility or liability for any issues that may arise from use of this device/pcb/module/code. There is a HAM version of the software if you'd like to include your call sign in messages.

Will and HC-06 work rather than an HC-05?
The HC-06 is intended as a slave only device, while the 05 can be master or slave. It may, but it is untested.

Bluetooth Control
You should be able to use any BT Serial application with this from your phone or PC. For mobile use I've leveraged "Serial Bluetooth Terminal" for Android extensively with no problems.

Jumpers on PCB:

Why are there all these jumpers?
In brief these are all to ensure this tiny little PCB is flexible as possible for the current use case, other feathers, and any other libraries you may wish to use. Keep in mind for some, once fully soldered depending on how you build it some may be inaccessible.

There are Jumpers for:

    The RFM Module:
	NIRQ (Interrupt Pin)
	NSEL (Slave Select/Chip Select Pin)
	SCK
	SDI (MOSI)
	SDO (MISO)
	JP1 & JP2

JP1 and JP2 are for the RFM23BP Antenna control and poorly labeled on purpose as it depends on the RF module used. Effectively these "should" be GPIO1 -> RX ON and GPIO2 -> TX ON for the RFM32BP. For the Radiohead libraries used these would always be bridged, if you want to use some other library and the board for another project, slice and dice accordingly. Same with the various other pins.

It's worth noting the RFM22 and 23BP have swapped GPIO to TX/RX mappings, so this is another reason these jumpers are here. Allegedly some RF22 devices have these swapped as to what GPIO ties to TX vs RX which is another reason these may be handy incase you need to remap. Before you start cutting related to radiohead you might check if the "setGpioReversed" feature works.

	
	/// For connecting an Arduino to an RFM23BP module. Note that the antenna control pins are reversed 
	/// compared to the RF22.

RX and TX (HC-05)
These *are not* for the RFM Module. They exist as a result of a great design concept combined with poor implementation when working with the HC-05 and 32u4 initially.

While space with the current code is about ~50% of the 32u4 flash space, memory used for creating POCSAG messaging is rather high. In order to avoid going with a full software serial library (no other hardware UART) I've opted to use the built in RX/TX from the 328p/32u4. This decision was not without its issues - in particular this breaks the factory USB interface. For a full mobile install with a good flash and test transmit of the RFM this isn't a problem, however for those of us that like to tinker, change code and break shit this is a major pain. As space is at a severe minimum using hardware toggle switches wasn't a great option, so jumpers it is!

The good news is other chips do have much more memory available for software serial so you can easily wire to whatever other pins you'd like. If you use a teensy for example, there's 3x hardware UART available! Out of the box, these aren't connected to UART2 or 3, but it's simple to solder 2 wires to a new UART then swap change in the code. For example: On a teensy you could replace "Serial." with "Serial3." in the code for using HC-05 Bluetooth Module on hardware UART on pins 7 and 8 of Teensy.

Notes on the ON1ARF code:
If you do not make this change Transmission will fail.

		Note that, as the RadioHead library by default does not allow
		packets larger then 50 bytes, one line need to be changed in the
		Readhead class before compiling the "pocsag" demo applications:

		In the file libraries/RadioHead/RH_RF22.h:
		#define RH_RF22_MAX_MESSAGE_LEN 50

		Should be changed to:
		#define RH_RF22_MAX_MESSAGE_LEN 255

If you need to wire up specific Slave Select and/or interrupt pins you can use "RH_RF22 driver" to do so prior to void setup

	/// (NSEL) Slave Select is pin 10, (NIRQ) interrupt is Pin 3
	     RH_RF22 driver(10, 3);

In void setup() make sure you have the settings you need to initialize.

Set the Frequency (based on RFM23BP module used):
While this can be set after the fact via the "F" command, starting at the right frequency is a good idea. I didn't need to leverage crystal correction mentioned for my pager to receive messages but it's worth doing some verification with an SDR to verify if you may need to.

	// Set frequency. AfcPullinRange set to 50 Khz (unused, we are not receiving)
	//  rf22.setFrequency(433.9000, 0.00);
	rf22.setFrequency(433.5000, 0.000); 
	// subtract 30 Khz for crystal correction
	// this correction-value will differ per device.
	// to be determined experimental

Verify you are set to POCSAG 512 and the correct deviation for your region/pager

	// set to 512 bps FSK, 4.5 Khz deviation (POCSAG 512)
	rf22.setModemConfig(RH_RF22::FSK_Rb_512Fd4_5 ); 

Set Power Output for the RFM23BP

	
	//Set Full Power
	rf22.setTxPower(RH_RF22_RF23BP_TXPOW_30DBM);
    
	//Set Medium Power
	rf22.setTxPower(RH_RF22_RF23BP_TXPOW_29DBM);
	
	//Set Low Power
	rf22.setTxPower(RH_RF22_RF23BP_TXPOW_28DBM);

Changing RX/TX Pins on HC-05
If you want to wire up RX/TX for the HC-05 to a hardware UART (requires cutting/soldering to the jumper) you could for example change thee "Serial." entries to Serial3:

	Serial.begin(9600);

to

	Serial3.begin(9600);

How do I use it?

Non-Ham version of the code:
To Generate Page: P [Destination capcode(7 digit "phone number")] [Sender Capcode] [Repeat Count] [Message]
P 1234567 1234567 0 Ah Durka Durka

To Set Frequency (433.500 for example):
F 433 500

POCSAG 1200 and 2400
While it has been quite some time since I tested outside of POCSAG 512 (read: literal years), it is possible to get 1200/2400 working. This requires some modifications to both the RH_RF22.h and RH_RF22.cpp files in Radiohead.

Effectively, you are hacking in the selectable modes (FSK_Rb_1200Fd4_5, and FSK_Rb_2400Fd4_5) for use.

 
    FSK_Rb_1200Fd4_5,     ///< FSK, No Manchester, Rb = 1200bs,  Fd = 4.5kHz, for POCSAG compatibility
    FSK_Rb_2400Fd4_5,     ///< FSK, No Manchester, Rb = 2400bs,  Fd = 4.5kHz, for POCSAG compatibility

More details on those mods are available here: http://ratcotel.net/?p=376

Some additional notes on the HC-05

AT Mode

I mention the AT mode in particular as the opportunity to "tune" your HC-05 exists and is generally overlooked with projects involving them. For example, the HC-05 defaults to a pairing passkey/pin of "1234" in AT mode. This can easily be changed with "AT+PSWD=6789". For a device that can be easily connected to and transmit from this may be desirable. Another example is the energy saving mode. I haven't noticed any major issues with it configued on mine for portable use but may have some caveats I am unaware of.

As to not blatantly steal work from others check out the document here for a good run down on AT mode:
https://www.gme.cz/data/attachments/dsh.772-148.2.pdf

A typical lack of standards

Using AT mode is pretty simple however it's once again a gotcha. The "EN" or Enable pin is unfortunately not always connected to pin 34 as it should be. Some do, and others will leave you wonder why this isn't working!? The fix is to manually place a wire directly to pin 34 (see link above). With that in place you'll have access to AT Mode with the appropriate code.

Every module I've used had some type of clear heat shrink covering the castellated board so you'll need to trim to gain that access. The good news is while the teensy is arguably "overkill" for the current code, it's 3.3v logic lends itself to no extra components to do so.

A few AT highlights:
Default Baud for AT mode is 38400 and (at least as of writing) can't be changed.
There is more than one "AT Mode" a mini and full so if commands are missing you may be in the wrong mode.

	General:
	AT Confirm you are in AT mode
	AT+UART Baud for Communication mode can be changed (Mode used in non AT Mode)
	AT+ORGL Reset to default. If you mess up a setting this will help you recover.

	Host Details:
	AT+ADDR Get HC-05 MAC Address
	AT+NAME Set broadcasted device name. Use this to advertise a readable name.

	Power Saving:
	AT+ENSNIFF Enable Enegry Saving Mode 
	AT+EXSNIFF Disable Energy Saving
	AT+SNIFF Change Powersaving options

	Security:
	AT+SENM Security and Encryption options
	AT+MRAD Show most recent authed device

	Scanning:
	AT+INQ Look for nearby discoverable devices. 
	AT+ANQC to cancel discovery.

ON1ARF RF22 Code
https://github.com/on1arf/rf22_pocsag

Radiohead documentation for the Radio
http://www.w5obm.us/Arduino2/Remote%20Telemetry/RadioHead/RH_RF22.h

Maybe more than 1 Watt with some extra bits?
The RFM23BP has some interesting enhancements one could potentially make to output power pushing it well past 1W.
http://www.itluxembourg.lu/site/modding-the-orangerx-1w-modules-for-full...
http://www.itluxembourg.lu/site/2-5w-narpat-mod/

AttachmentSize
SX_Pocket_Pager.zip29.78 KB
PCB_3D.png106.15 KB
PCB_Kicad.png295.28 KB
Build_Female.jpg651.14 KB
Build_Male.jpg655.77 KB
Size.jpg678.25 KB
Example.jpg664.63 KB