DIY UHF RF text messaging transceiver
Standalone (not dependent of any provider) two way text messaging with a small LCD and a keybad or a 5-way joystick for user input. It has to work on UHF for RF safety reasons, sonce power could be as high as 0.5W or more.
Are there any such communicators in the market?
What if I want to design my own?
These SA818 or SA828 modules could be a good start to simplify RF design?
I think that you have to zero in on some proper texting protocol, so coders/decoders can be built or purchased cheaply. There are commercial pagers about and many different text based systems (like this one!).
It could be more effective to buy commercial pagers and retune them to an amateur band.
Frank
If you really want to home brew one, I suggest ASCII text sent as FSK is easiest. For best results pre-process the data and send it bi-phase (Manchester) encoded. It's simple to do but you will have to use a microcontroler.
Brian.
I did not know that these pagers can communicate by themselves! I thought they required a base station to handle the data and reroute it!
Pagers are generally 'all over' with the same message going out through several transmitters to give wide coverage or zoned so only a particular region is covered. The most common protocols are POCSAG and FLEX, both use FSK at various data rates. Even in the remote area where I live I can see pager messages for recipients hundreds of Km away. There was even a system that 'piggy backed' the teletext data stream on terrestrial TV but I think that shut down when the UK TV went all digital a few years ago. As far as I know, all transmitters in a pager network, either nationally or within a zone, carry the same data simultaneously, there is no 'routing' as such. In the UK, frequencies around 153.5MHz and 466MHz are used, it may be different in other countries.
If you are looking for a point to point messaging system using ham frequencies or 'licence free' frequencies I would strongly advise you to use the bi-phase encoded FSK I mentioned earlier. It is very simple to implement and quite reliable. I use it here (433.92MHz) 24/7 for data linking between a floating sensor in my swimming pool and the filtration and pumping control units. It worked with no detected errors for the past 3 years, sending 32 character data packets once every minute until a few days ago then without warning it started sending 32 consecutive zeroes. The encoder and RF were still working fine but the temperature sensor had sprung a leak and filled with water!
I've got the replacement beside me right now, waiting for the potting compound to fully harden before reinstalling it.
Brian.
Pagers are not used in my country, and that is a pitty.
So If I buy a pair of UK-compatible UHF pagers (let's ignore licenses for a bit), will they able to chat one another independently of any third party service?
I am looking for the simplest solution as my time is quite limited nowadays, else I would try to build something from scratch like you said.
yes that's correct they need a base, just like the mobile phone service
The way pagers work is like this:
1. someone uses a telephone or on-line service to send the message. (some are from automated systems or alarm units)
2. control center handles the call and formats the message by adding a serial number, time stamp and destination address to it.
3. control center sends mesage by landline to all or a selected zone of transmitters.
4. pager hears all calls on the frequency and displays any that match it's own address.
Often the same message will be repeated several times but with different time stamps, the pager will normally ignore subsequent ones until the message/serial number are different.
So, they can't talk one to another, they need a central control system. Pagers normally don't have any transmit capability at all, they are simple superregerative receivers with an MCU to decode the tones and compare the in-built address with the one in the message headers it receives.
Brian.
That was very helpful, thank you.
Obviously this is different of what I am looking for.
Isn't it weird no one have produced a point to point text messaging system (like PMR for voice) yet?
Well, a PMR could be used in combination to an AFSK encoder/decoder (with LCD).
A simple solution I am thinking, would be to pull out the case of a small PMR and take out the PCB, then put it inside the same case as the AFSK LCD encoder/decoder.
There are a few "LCD terminals" in the web, I may find an AFSK one as well.
This will allow also for voice comms on PMR, without any additional hardware complexity, since we are using a PMR.
Text messaging is good because you don't have to be in range to receive the message. A "received ok flag" could be used to notify the sender that the recipient has received the message. Of course each user will have it's own ID. I do not think this scheme would be that difficult to implement?
Isn't it called SMS?
I think you have to be careful in planning a 'private' text service. The concept of holding a message until the recipient is in range can be quite dangerous, witness the plethora of ham BBS systems a few years ago that jammed the channels by repeatedly asking if stations were within range, sometimes sending the same requests all day and night for several days. In a mobile phone scenario, the status and location of the phone is known almost all the time by the cell network so messages can be routed to the apppropriate base station and it can confirm it was received. It knows the location because periodically, the phone sends it's ID (IMEI number) and one or more cell receivers picking it up will negotiate which is best placed for communcation. Without that knowledge of location, there is no way to be sure the recipient can pick your message up without continuously resending until it gets a reply.
So the problem is: what do you do if you don't get a "received ok flag"? Do you just keep trying for ever?
Brian.
No it is not SMS, this is a private and point-to-point text messaging system I am talking about.
You are right about the "keep trying for ever" issue, but as said this will be used privately, throughout family or a few friends, so even if keep trying for ever, it won't hurt.
A preset delay has to be set between two message repeats to avoid draining the battery.
A more clever scheme just asks for the receiver to send his ID before sending anything. If he replies then he sends the message.
Another scheme could be "try two or three times with 5 minutes delay between the first two retries and 10 minutes delay for the third" or something like this. If no response, discard the message.
Like always, the problem is programming the micro/LCD, because I have nor good experience, so I have to rely on ready-made projects or use one of these picaxe
That's the whole problem. The mobile phone system gets around it by each area (cell) knowing which phones are within it's reach and routing the message anywhere in the World with coverage. If you don't know if the recipient is within range your only option is to keep polling them until you get a reply. Abandoning the message after a few tries isn't a reliable strategy as you would never know if it arrived or not.
If you want to try it, I would advise you to learn simple microcontroller programming, it has a steep learning curve but after a few weeks you will master it and never look back. My preference is the PIC family but to be honest, all manufacturers aim to be as versatile as possible so you could use almost any you want. My suggestion would be to start from scratch rather than using a development board or pre-loaded PIC like the Picaxe. Almost any small PIC can work as a keypad/LCD interface, encode the data and control the transmission, you can even get ones with built in VHF/UHF transmitters although you would probably find it cheaper to build the RF circuits yourself and leave the PIC to do the number crunching.
Brian.
yes exactly ... they are receive only
I am designing the VHF/UHF transceiver. For your aimed application, by adding an MCU that is responsible for the keypad input and the point to point wireless transpond is by the VHF/UHF transceiver. I think this structure could satisfy your requirements.
This is a whole lot of work!
I would live to see your ideas
over what transmission range ?
you are not going to achieve much range at VHF/UHF from a small pocket device a few 100 metres to a km at most
and what range were you expecting ... I suspect you are seriously underestimating how well you will do
commercial paging transmitters are placed on high hills, towers, high buildings and typically run a 1000W or more so as to get the required coverage
When I lived in New Zealand us amateurs that did 2m and 70cm DX used to listen for the Australian 153MHz pager transmitters to indicate when the 2m band was opening up between NZ and Oz
Dave
I have used PMR446 0.5W and LPD433 0.01W, so I know about the range limitations. I expect only local coverage.
Maybe two RF gateways could connect two places through internet.
I have done that successfully for voice http://qrp.gr/eqsoen.htm so anyone can voice chat to me throughout the world. Two such RF gateways could cover a very wide area. Anyway as said I am only interested in local comms.
and again ... what is your definition of local coverage ?
with your power levels indicated ... you cannot expect more than a few 100 metres, at best, of reliable comms from a pocket device
Yes this is sort of the range I am talking about.