Can you simulate RTTY transmission with a PICAXE ?

[srnet]

Can you simulate RTTY using the sound functions of a PICAXE ?

I have read the recent long thread on RTTY but am a bit vague on the details.

I am assuming that you transmit a low tone, of say 1000hz as a mark, and a high tone of 1170hz as a space.
Using the MMTTY software to decode the generated audio.

To send a R (baudot code 01010);

Start with a continuous mark tone ........
Transmit a space (high tone) for 1 bit (22ms) - the start bit
Transmit a space (high tone) for 1 bit (22ms) - 0
Transmit a mark (low tone) for 1 bit (22ms) - 1
Transmit a space (high tone) for 1 bit (22ms) - 0
Transmit a mark (low tone) for 1 bit (22ms) - 1
Transmit a space (high tone) for 1 bit (22ms) - 0
Transmit two spaces (high tone) for 2 bit (44ms) - the stop bits
Return to a continuous mark tone ........

Is that about right ?

 

[hippy]

Sounds right in principle though I'm not overly familiar with RTTY.

 

[geoff07]

You can certainly send rtty (murray code) with a Picaxe. You can either generate the tones directly or pulse a couple of oscillators with a ttl signal. How exactly to do it depends on what your input is (ascii text?); whether you need the full alphabet or just certain codes e.g. for telemetry; and how you want to generate the tones. Probably the trickiest bit is to translate the input ascii into the murray code you want to send, perhaps with a lookup table and a routine to pulse out the character.

 

[srnet]

For the moment I just want to transmit a couple of the murray ASCII characters, R and Y for instance, so I can get a feel for how good the PC software is at reading the RTTY in noisy signal conditions. As a comparison to the auto Morse decode I have tried.

As for the tones, direct from the Sound command for the moment, its only a test, I dont mind that the PICAXE is fully occupied sendind the RTTY, not concerned at the moment about the translation from numbers\text to RTTY, just a test transmission.

Do I have the mark space frequncies and timing correct ? Does the mark frequency have to be continuous even when not sending RTTY, or is there a minimum period for the Mark frequncy to be present befor sending the space start bits ?

 

[MFB]

The information on this link may provide some help...http://ukhas.org.uk/guides:linkingarduinotontx2

 

[geoff07]

The point about start and stop bits is that that is all you need (or get) with async comms in the wild. The alternative is synchronous comms, which requires a constant signal from which the clock can be extracted, with async, the timing is taken from the start bit.

The frequencies depend on how you want to do it, you can use narrow or wide shifts as you please. The issue is matching the modulation to the demodulation and depends on your channel, i.e. audio by wire or modulation on radio.

I haven't played with rtty for years and am not familiar with mmtty, but the issue will be matching the baud rate and frequency shift to what the rx expects/is set up for. You might not be able to tune the Picaxe frequencies precisely to what you want. Software decode is all very well but there are some advantages to using analogue filters to extract the received signal, noise immunity and resilience to small tuning errors for example.

RTTY should be better than morse at the same baud rate (unlikely of course) given the lack of any synchronisation with morse. In practice , RTTY is much faster than even machine morse. There were once telegraphists that could read rtty off the air, probably at 45 or 50 baud. One of the gotchas with rtty is the shift character, which switches to the different halves of the character set, as long as it isn't missed, in which case you get garbage.

 

[hippy]

Do I have the mark space frequncies and timing correct ?

For 45 baud the bit time should be 22.222ms but 22ms should be good enough. Probably best to look at the bit stream with a scope then adjust the PICAXE code so it's close to the 22ms.

Does the mark frequency have to be continuous even when not sending RTTY, or is there a minimum period for the Mark frequncy to be present befor sending the space start bits ?

Continuous marking is probably recommended so the receiver can synchronise, or you may have to have some marking for a time before the first start bit so it does synchronise correctly.

You can get continuous marking by using PWMOUT so it shouldn't be a problem to do that, then just set the frequency every 22ms.

I think the best approach is to set the PICAXE up so it sends a character every second, see what MMTTY produces and based on that adjust the PICAXE code as appropriate; most likely problems will be wrong bit order transmission, swapped over frequencies.

 

[Paix]

Green Key Wizard enters the room:
First let's bust a myth: There were once telegraphists that could read rtty off the air, probably at 45 or 50 baud..
Like cockroaches in beehive hairdoos, everyone knows someone who knows someone that can do it. As a telegraphist I never heard that claim, only many years later from radio amateurs. Provide a name. As I explained elsewhere recently, it is easy to recognise an RYRYRY sequence of reversals on a calling tape, but to read just two groups of five letters at 50 baud from a tape transmitter (machine speed) would be a convincing start. 66.6wpm. To put it into perspective take the characters A B C D E F in Morse, transmit them at 50wpm and see how accurate your result is. I used to check TAFORS that I had typed up and with the copy in front of me used to run the perforated Morse tape at 50wpm to check it. I could pick up an error, but had to turn the Wheatstone transmitter down to 30wpm to be able to reliably catch the character.
I have to add that my sweet spot was (not is) in the 16wpm to 20wpm range. Why did I check the tape at 50wpm, simple, so that I could get back to reading my book. Checking at the 18wpm speed for Allied broadcasts would have taken up all the time between broadcasts.
= = =
Back on thread.
Known as a 5 unit code, the format was invariably 1 start bit, 5 data and 1.5 stop bits. 45.45 baud was popular amongst radio amateurs, but Military and GPO teleprinters ran at 50 baud, giving a rate of 66.6wpm or 10 characters per second. 75 baud gave 100wpm.

In Amateur use the standard shift for many years was 850Hz using tones 2125Hz and 2975Hz. This later became known as Wide Shift and the Narrow Shift at 170Hz became popular using tones 2125Hz and 2295Hz. This quickly became a standard, but was only possible as the frequency stability and tuning accuracy of transmitters and receivers improved over the years, even before frequency synthesisers became popular or common. For many years the ubiquitous 88mH telephone loading torroids were the prized heart of many a tuning unit. As supplies eventually dried up the semiconductor industry was beginning to produce some very interesting devices which came to the rescue and brought about some radical new designs initially using 741 op amps before the clever stuff arrived. A lot was done to remove phase discontinuity errors in AFSK tone generators.

Military transmitters invariably used USB and did not observe the 10MHz convention with regard to SSB transmissions. Changing from USB to LSB would of course invert the two tones. On ship shore RATT (Radio Automatic TeleType) circuits, it was common to hammer away rythmically on the letter shift whilst thinking between typing to keep up the signal to noise margin. Random bursts of typing would otherwise become lost as the receiver AGC attacked and took time to settle at the onset of a transmission.

You became very good at reading a bit of terxt received in the wrong case in such cases. The Baudot code (Emile Baudot) was improved upon by Murray and the Murray Code was later adopted at the ITA2 international alphabet. The term Baudot code tends to be used by Americans and in Amateur Radio circles. GPO telegraph engineers were easily recognised by their pronunciation of the phrase "baud speed" Baud as in Loud, whereas mere mortals invariably said Baud as in Lord.

Standard convention was Mark high, both logic and frequency/tone being high for the marking/idle line condition. On line communications used to begin VZCZC. The V being a wake up character to allow mechanical systems to get up to speed and the ZCZC was a reversal code which was probably used by automatic systems to verify the start of a transmission and synchronise.

Ir should be very possible to produce an acceptable AFSK oscillator using the PICAXE sound command. And conversion from ASCII to ITA2 coding should be relatively easy, given that a relatively limited character set is involved and case control characters (figs and letters) generated as needed.

The link http://www.kloth.net/services/ttypunch.php gives most of the practical information required.. Note the picture of the tape runs in with letter shifts (standard) uses ZCZC as I have mentioned (notice the complimentary data pattern), includes RYRY sequence (note the complimentary data pattern).
At the end of the tape the sequence is CR CR LF LF LF LF NNNN. The Alignment Function is CR CR LF (infers a military trained operator (?))
The reason for 2 CR LF was that it took a while for the platen to move back to the begining of the line. If only CR LF was used then one character was likely to be printed during the return journey of the platen. LF CR would of course print the first character of the new line rather late in the line and the second character could also become a casualty.

@Hippy, so now you know why I'm so anal about serial comms.
@Manuka, standard fare I guess! I bet you had the t-shirt back in the day.

 

[srnet]

Thanks for all the info guys.

Limited sucess so far, with series of PWM commands;

hpwm pwmdiv16, 0,0,%1000, 106,214 'pwm output of 1170hz SPACE - 0
pause 21
hpwm pwmdiv16, 0,0,%1000, 124,250 'pwm output of 1000hz MARK - 1
pause 21

Connected to the direct mod input of my 20X2\RFM42 transmitter, I am sending RY, but decoding TY with the MMTY software which uses the PC soundcard to process the audio feed from my UHF tranciever.

Need to check the timing me thinks.

 

[geoff07]

First let's bust a myth

It may indeed be a myth, after all, it would be difficult to do. But I learned it in my youth while at a Post Office Telecommunications training centre in the late '60s when there were still teleprinters in daily use and I had no reason to doubt the claim. I have never heard it from another radio amateur.

 

[lbenson]

It's a far cry from doing it by ear, but back in the day, along about 1968, when I had a job as proofreader for an early "computerized" typesetting outfit, I could read 5-punch paper tape (probably at something less than 50 wpm)--when I knew the context and had some familiarity with the text. That was after working at the job for just a couple of months.

Corrections were made by copying from one punch tape to a new one, stopping at an error, and typing the correction onto the copy, and then continuing the copying. In a few cases, where the bits were right, one could make corrections by overpunching the erroneous character on the original.

 

[geoff07]

Ah, paper tape. I used to have (sadly lost now) some reels of tape that printed nice pics of Winston Churchill, film stars, etc. by massively overprinting the lines. Very good they were too, if viewed at a distance. Those were the days when operators had time on their hands.

 

[Paix]

@Snet, I forgot that SOUND was a blocking instruction and so would not provide a clean tone transition. Might I suggest that you start with six or seven stop bits in the first instance. My reasoning being that essentially after 6.5 units, it's game over and the receiver should be ready for a new character however badly the first was framed.

If you were regularly getting TYTYTYTY instead of RYRYRYRY, then I would be more inclined to check your character coding.

a series of AINO AINOAINOAINO or ONIA is two bits descending or ascending. Once you have a winner, then shorten the stop bits radically until you get back to 1.5. It should work with only one stop bit, but any garble and the room for resynchronisation becomes ever so problematic . . .



@Geoff07, I don't doubt that you heard the claim and accept that you had no reason to doubt it, but you never had anyone claim to be able to do it themselves, and even less likely to be willing to demonstrate the ability. I did and do challenge any such claim to be able to read rtty at 50 baud, even just five character letter groups over a distance of two complete groups under test conditions.

A calling tape sounds different to a brief over or a long message. Even groups may be identified by the rhythm of the characters. Every good Teleprinter Operator or Telegraphist used to be able to read the 11/16" punched tape, if only to find the correct message on a reel of tape to satisfy rerun requests.

 

[geoff07]

Paix wanted a name:
Chris Burger ZS6EZhttp://www.mail-archive.com/digitalradio@yahoogroups.com/msg08535.html

Second hand, but witnessed and documented. Probably only at 45 baud but still remarkable.

73s
G8ZNW

 

[Paix]

OK so callsigns, limited length, but I accept that. I have emailed Chris for any other details he might wish to advise me.

Sounds like 45.45 baud and hand speed(?) and not in the UK, circa 2006. From collateral comment the ability would be restricted and not extend to reading message text of any length more than a few words. The wonders of Internet search eh?

Point conceded Geoff. I suspect that in the late 1960's that far fewer people were using RTTY as the hardware was for the most part noisy and ungainly. Most telegraphists didn't listen to the signal as it was received over a line from a distant receiver station.

I'll let you know what Chris has to say about it all if and when he replies.

Ian - G0PAI

 

[srnet]

Cant get this to work.

By using a spare pin on my 20X2 I can see the mark and space periods on a scope, they appear to be correct, within 2ms for an entirte packet of startbit, 5 baudot bits, 2 stop bits.

Tones appear to be correct on the waterfall displays with the correct offset, using hpwm outputs.

But the decoding does not apear to be related to the bit pattern being sent, I can only conclude that the decoding software just does not like square waves.

Got an XR2206 somewhere, maybe the PC software is happier with pseudo sinewaves.

 

[Paix]

The XR2206 looks to be a nice chip to have on a little board as a FSK modulator to be able to swap between development projects.
http://www.jaycar.com.au/images_uploaded/XR2206V1.PDF


FSK modulator from the datasheet.

Removing the need to produce the tones with the PICAXE should make it a breeze. The XR2206 appears to make a very good job with sinusoidal output too.
= = =

From the horses mouth, "I'm afraid I have to disappoint you, as I never could read RTTY by ear."

Chris ZS6EZ has advised me that he could recognise common frequent patterns of characters and use the audio signal to augment the identification of RTTY callsigns in noise
at 45.45 and 50 Baud.

I'll PM Geoff the full result, if anyone else is interested, pm me for a copy. It's a MYTH

 

[srnet]

The XR2206 does not look difficult to use, but retro fitting the device for my application is a non-starter, the direct mod input to the RFM42 allows audio tones as squarewaves to be generated only.

 

[Paix]

@Srnet, Oh, I don't think that I fully understand
The RFM42 is an FSK transmitter, so if there is no Audio input for tones from the XR2206, then the FSK input takes raw TTY keying data? Even if the shift is not right, you should be able to tune the signal to straddle the tone centre frequency. Presumably your data is input by only one line, so if the signal is inverted, then you probably need to un-invert it. The standard is Mark/idle high, so your start bit will be going low.

If you only have an FM only UHF rig you may not get a lot of milage out of it, although the PS/2 data port on your radio might give you some change. If your receiver is multi-mode then USB should produce the tones for you and just tune off to center them.

I'm just guessing however . . . so ignore me if I appear to be misleading. I am assuming that you are a radio amateur. I'm not at all sure how familiar you are with things RTTY. You certainly appear to know about the RFM42, but I can't seem to find a diagram giving me a pinout.

 

[mrburnette]

The XR2206 does not look difficult to use, but retro fitting the device for my application is a non-starter, the direct mod input to the RFM42 allows audio tones as squarewaves to be generated only.

A 556 used as a dual audio osc. could be used for the two sine waves. The PICAXE can be used to key the tones. Maybe a simpler/cheaper solution.

- Ray

 

[srnet]

@Srnet, Oh, I don't think that I fully understand

I feel the same most of the time.

The RFM42 can do FSK, OOK or GFSK. You can set deviation and the 'data' modulation comes either from the internal FIFO\Packet handler or you can apply the 'data' direct to one of the RFM42s GPIO pins. Thats how I setup the device for Morse transmission, configure for FSK and direct mod, deviation around 8khz, apply a tone (actually a sound output command from the Picaxe) and by magic the morse tone is heard on a small handheld UHF tranciever set to NBFM. That all works dandy, and the Morse can be heard several kM away, so its purpose as a lost model locator is fulfilled.

The RFM42 can send data directly in the form of packets from a pre-loaded 64 byte FIFO, and after a lot of playing I got it to work;

http://www.picaxeforum.co.uk/showthread.php?20024-Wireless-Link-using-Hope-RF-modules

What would be cool is to collect, whilst in flight, data from the RFM42 Lost Model Locator I referred to, circuit here;

http://www.picaxeforum.co.uk/showthread.php?19549-RFM42-Lost-Model-Locator

Whilst I have built a portable telemetry reciever based on the RFM31 the reception range is fairly poor when compared to the Morse, by a factor of 20 - 50.

So it got me thinking about RTTY. I realise you normally recieve RTTY via SSB, which I dont have, hence the attempt at direct audio tones.

I did used to be a ham once, GW7HPW, VHF\UHF only. I did the cert around the time I was in College doing Radio\TV\Electronics.

 

[mrburnette]

<...>
Whilst I have built a portable telemetry reciever based on the RFM31 the reception range is fairly poor when compared to the Morse, by a factor of 20 - 50.

So it got me thinking about RTTY. I realise you normally recieve RTTY via SSB, which I dont have, hence the attempt at direct audio tones.

I did used to be a ham once, GW7HPW, VHF\UHF only. I did the cert around the time I was in College doing Radio\TV\Electronics.

Ummm... Is there an issue with using Morse directly for telemetry data? Standard/Modified Morse was utilized for many years as back-up telemetry data for satellites, etc. While Magic Morse full alphabet is EEPROM-happy, just using numbers can be done easily on the transmission side:
http://www.picaxeforum.co.uk/entry.php?30-Notes-behind-Magic-Morse

- Ray

 

[srnet]

Is there an issue with using Morse directly for telemetry data?

Not in particular, I have built a portable automatic Magic morse decoder;

http://www.picaxeforum.co.uk/showthread.php?20059-Portable-Magic-Morse-Decoder

And that gives around 15-20 times the range of the data telemetry, albiet at a massivly reduced effective data rate. The Morse transmission routines are my own, originally written in Mikrobasic. The portable decoder and the lost model locator Morse operates at 15WPM, I tried it at 30WPM, and it seemed to work. I have a copy of the MRP40 morse decoding software (which I paid for !) and that works on my small netbook. It says its supports up to 60WPM, but I have not tried that.

The RTTY decoding software is of course free.

 

[Paix]

Nothing wrong with AFSK rather than FSK. In fact when you pop a nice clean set of tones into a sideband TX then it's difficult know that it isn't a pure FSK signal.

It seems that the transmitter is just too clever, what with it's packet frame etc. A lesser beast would give you a data input and an audio input and in this case you would have been home and dry.

I read just about all the posts on here these days, but rarely open .BAS or .ZIP files. .TXT and .PDF open just fine, but everything else is a struggle as I have to download them first and then open them. Usually too much effort to he honest. Sorry. I currently have stuff on three desktops and about a dozen documents open that I am (ostensibly) working on, then a couple of pdf's (manuals) as well as the browser. So you can see where I'm coming from.

Sorry that I couldn't solve your problem, I feel like a little boy talking to the scientist now . . . ha ha.
= = =
On the licence front; are you aware of the current licensing arrangements. The Morse test has gone, as has the A and B licence designations, so you would now qualify for a full licence, which would cost you £20 to get your callsign back, validate it (let them know that you still exist) once every 10 years and nothing more to pay. Handy to have, even if you don't actually use it. If you are up to speed on the regs, then again I apologise, there is no intention of trying to teach you to suck eggs. Just want to be sure that you are aware of the situation.

 

[srnet]

Here the circuit of the transmitter, although it wont tell you a lot, black boxes etc. The smaller version of the transmitter is also shown, so you see not a lot of space for tone generators and the like (for size the header is a 5pin 0.1" one).

The transmitter does have a 'data' input, but no access to a 'audio' input. Exactly how it turmns the data input logic level into FSK I dont know.

I knew the Morse had gone, but was not aware the licence was now a once off fee, thanks for highlighting that. The annual fee was one of the reasons I stopped being licensed. Might re-register, the technical exam is not exactly hard. Ironically one of the things I have always fancied trying is ultra simple long distance comms with Morse, you know the sort of transmitter that can be put in a Altoids tin (do they still do tobacco tins ?).

 

[mrburnette]

"... albeit at a massively reduced effective data rate"

Understood. As Morse Code can be constructed using FSK, I would think this would be an option and would push the data rate up to that of RTTY... or close, since there are some protocol differences between the 5-bit BAUDOT code and the 6-bit variable Morse. Of course, my opinion is that it is easier to stay in the same technology class, but I am not implying that there is any inherent reason not to use RTTY for data. Mostly, just curious.

- Ray

 

[Paix]

Manua/Stan wrote a Morse routine for the 08 chip I think, which was a bit of a squeeze. More room on the 08M and much more on the 08M2

Essentially each character was coded as five bits for the dots and dashes and three bits for the character length.

I took the coding idea and worked out my own destiny, The code diverged, but not overly much. I considered that every dot, dash and space had a dot's worth of space on the end of it. I found that it made my coding easier.

Previously I would use a word value and code 10 = dot, 11 = dash, 01 = that trailing dot space and 00 indicating end of character coding. Obviously it would allow me all the barred characters, but is not as compact as Stan's code. I just shifted left and read the leftmost pair of bits, but that was on a PC many moons ago. I never did get around to producing a clean interface . . .

The message strings were written into the program as numbers representing the binary coding of both character and length.
It wouldn't be difficult, given an ASCII string of characters, to code them up into morse-charlength form of string and then at the point of transmitting call the dot, dash, charspace or wordspace routines or inter-element spaces, making them use an appropriate combination of tones and timing to meet your needs for dual tone, triple tone or tripple tone equal dot/dash length.

I was going to use a slight modification of that scenario to produce Murray Code, but I forgot about glitches between mark and space tones, but the XR2206 would have overcome that as instead of producing tones I would have manipulated an output port.

I have lots of good ideas, but I suspect that your R/C aircraft would have have to be something like a Dakota and the PICAXE would get swamped. Hmmmmm.

= = =
No re-examination required. The RSGB will sort out your entry in a previous year's callbook, proof of having held the call and Ofcom will take your £beer/£food coupon and give you your ticket back. Almost painless.

 

[mrburnette]

Manua/Stan wrote a Morse routine for the 08 chip I think, which was a bit of a squeeze. More room on the 08M and much more on the 08M2 ... Essentially each character was coded as five bits for the dots and dashes and three bits for the character length.
<...>

Essentially what I did with Magic Morse... see the PDF mapping at the end of the blog:
http://www.picaxeforum.co.uk/entry.php?30-Notes-behind-Magic-Morse
Magic Morse, however, has the ability to be quickly decoded by an 08M2 (and higher) due to the nature of how the decoded (EEPROM) address is built dynamically from the received stream. The transmit algorithm is also extremely easy.

... and I do remember reading your article last year when I was doing my initial research.

- Ray

 

[srnet]

I also encoded morse as a byte, 3 bits for how many bits to send, and the other 5 bits set with 1 for a dah and a 0 for a dit. Only sending 5 bit morse then the basic routine is;

symbol ditlen = 7 'this controls the morse rate, length of dit in units of ms
symbol dahlen = ditlen * 3
symbol wordgap = ditlen * 7

'send a morse character
sendmorse:

	morsebits = morsecharacter AND %00000111 'isolates bottom 3 bits
	morsecharacter = morsecharacter / 8 'this has the same effect as shifting right 3 bits
	morseposition = 1
	
	for numchars = 1 to morsebits
		test = morsecharacter AND morseposition
		if  test > 0 then 'if 1 should default to true
			hpwm pwmdiv16, 0,0,%1000, 124,250  'pwm output for 1khz Dit
			pause dahlen
			hpwm off
		else 
			hpwm pwmdiv16, 0,0,%1000, 124,250  'pwm output for 1khz Dah
			pause ditlen
			hpwm off
		endif
		pause ditlen
		morseposition = morseposition * 2	    
	next numchars
	pause dahlen 
return

Call it with the encoded character in variable morsecharacter. It should send proper spacing 1/3/7 morse, in relation to the single variable ditlen. To adjust the speed, just change ditlen.

The MRP40 morse decoder (for PC) does not decode much above 56WPM, but with the above routines I had FLDGI (also for PC) decoding Morse at 130WPM. I had not realised FLDGI (which is free) had a CW mode, but it does, and an adjustable narrow band filter so no noticeable issues with harmonics. The weak signal performance surprised me, it seemed able to cope with a reasonably noisey signal even at 130WPM.

With a cheap and very sensitive handheld UHF tranciever costing around £25 on eBay, you could use a PICAXE and just about any UHF data module for long range, not too fast, telemetry.

 

[manuka]

With a cheap and very sensitive handheld UHF transceiver costing around £25 on eBay, you could use a PICAXE and just about any UHF data module for long range, not too fast, telemetry.

Such sets,many now Chinese sourced, are indeed appealing and sensitive,with amazing versatility. Check the likes of this Baofeng UV-3R review.

Data decoding however may require a discriminator hack to access unfiltered audio. I've done this with Uniden receive only scanners (for ~166MHz marine AIS decoding), but not transceivers. As your need seems for data that's very reliable (rather than fast),perhaps focus on S L O W Morse based QRSS/DFCW(i) approaches? Stan. (ZL2APS)

 

[srnet]

Such sets,many now Chinese sourced, are indeed appealing and sensitive,with amazing versatility. Check the likes of this Baofeng UV-3R review.

I have a UV-100, which is the same set. Small and not solidly built like an Icom or Yaesu set might be, but sensitive and it works just fine for the Morse.

I have a Yaesu VR120D Scanner, which is not as sensitive, but it does have a fully adjustable squelch, rather than a digital stepped one. The fine adjustment of the squelch allows for reasonably accurate 'body fade' direction finding when the locator is transmiting its RDF beacon tones. There is a decent handheld around which has a continuous squelch, cant recall the model number.

 

[manuka]

Those nifty Baofeng's are apparently software defined radios (SDR),& they're credited with THE most sensitive 433MHz receiver going. One e-detective reports-"The heart of the radio is a RDA Microelectronics RDA1846 single chip transceiver for walkie talkies. This single CMOS chip provides frequency synthesizer, VCO/VFO, AFC, AGC, pre/de-emphasis (selectable and can be disabled), RSSI indicator, CTCSS/DCS encode/decode, DTMF, 8dBm PA (about 6mw), and more. Basically everything a radio needs is provided by a single chip."

Predictably hacks & frequency expansions already abound,with a keen Yahoo group driving most tweaks. Check here for software.

No - I don't have one, and am wary of their (minor) bugs & potential for out of band abuse & usage... At their astoundingly low price (~US$50) it's however perhaps worth popping one in your UHF toolbox just for general 433 MHz ISM band monitoring. Any Kiwis fancy joining in a bulk order? Stan. (ZL2APS)

 

[srnet]

Not sure I would want to use one as a main ham handdie, but for this use they are fine. batteries are cheap too, around £5.

One mod I might make is to disable the PTT function on the earphone\mic socket, plug a standard 3.5mm jack audio lead in and it turns the TX on.

One other thing I will try is to see how well the portable magic morse decoder I made copes with the faster Morse.

 

[srnet]

Intial tests with the portable magic morse decoder had it decoding morse OK at 60WPM (on a 28X2 at 64Mhz), with only a change to the program timing limits on a dit and dah. Looks promising.

 

[srnet]

And the FLDIGI software does a good enough job of decoding the 60WPM morse generated by my 20X2 using my 99p from China USB 'sound card'. Need that dongle as the netbook does not have an external MIC socket. Although FLDIGI will work when the radio speaker is held next to the Netbooks Mic.

To test this all in the field, I need the previously mentioned long beach and to combine the magic morse decoder and telemetry decoder programs, and to do that I need to work out why my 28X2 seems so keen to run at 64Mhz only when the external resonator is enabled.