Remote Sensing Morse Code

MFB

Senior Member
Jitter on the 567 output could be an indication of sub-optimal component values. Its a long time since I used this chip but do remember that it was important to get the correct ratio between the different (osc and filters etc) RC components. It might be worth playing around with these a bit more to get the cleanest output from noisy signals. If I can find some of my notes using the 567 I'll let you know.
 

srnet

Senior Member
Yes, playing with the component values makes a difference, I will spend some time experimenting and post a circuit diagram.

The enclosed code will decode standard spacing machine generated code from 10 to about 18WPM. it detects the character and word gaps and formats the output to sertxd accordingly.

If the limits for the lengths of the various tones and gaps were made variables, the code could be made adaptive to the measured morse;

SYMBOL ditmax = 150 'approx maximum for a dit in mS
SYMBOL ditgapmax = 150 'if gap exceeds these mS then its a character gap
SYMBOL wordgap = 420 'if gap exceeds these mS then its a word gap
SYMBOL tonemax = 480 'if tome exceeds these mS then its too long
 

Attachments

mrburnette

Senior Member
I played around in the simulator at http://www.falstad.com/circuit/
and it appears that the 567 dit-dah output could substitute as the sq. wave gating source in this simulation and provide the 555 generated (change "c" to get 800Hz or so) to feed the PICAXE with a clean "BFO" signal and also to reduce/eliminate the jitter issue. It would need to be breadboarded, obviously.

Import this text into the simulator and then observe the output in the scope:


$ 1 5.0E-6 5.023272298708815 64 7.0 50
w 368 160 336 160 0
r 336 160 336 224 0 10000.0
w 336 224 368 224 0
w 336 224 336 256 0
w 336 256 368 256 0
c 336 256 336 320 0 1.0E-8 -4.999838086230453
g 336 320 336 336 0
w 336 96 432 96 0
R 336 96 272 96 0 0 40.0 5.0 0.0 0.0 0.5
O 496 192 560 192 0
165 368 128 384 128 2 5.0
w 432 96 496 96 0
w 496 96 496 160 0
r 336 160 192 160 0 10000.0
R 192 160 96 160 0 2 100.0 5.0 0.0 0.0 0.5
o 9 64 0 34 5.0 9.765625E-5 0 -1



- Ray
 
Last edited:

srnet

Senior Member
Here is the schematic, not perfect but it works. Accepts a sound input from a PC or from a UHF tranciever.

The jitter is eliminated by the transitor driver and capacitor for the 08M2 pulse input. I will experiment further and try the decoder with some weak signals.
 

Attachments

mrburnette

Senior Member
Fantastic.
Looks like a promising telemetry component on the receive end. While a nice side benefit of Morse is that it is human readable, it is still nice to have an inexpensive and flexible device that can 'read' Morse and optionally log data. Using the NPN in saturation mode worked pretty well with the 555 code oscillator and manual key, too. With the 567 front-end, pulling Morse out of the background noise should be quiet good. I'm looking forward to reading about some successes as this evolves. The Soviets and NASA and other countries used Morse Code telemetry for years as a back-up telemetry system for critical flight information - based on several Morse Code histories I have read.

Having an autoreader for Morse should open up telemetry use to non-Morse users. Great job srnet... quick also.

- Ray

Afterthought: I had previously said, "on the receive end", but there is really no reason that the circuit you propose could not be used on the model end.... the 08M2 may still have enough code space and EEPROM space to incorporate a few critical commands such as cutting down a payload from a balloon, etc. By creating a clever set of uplink command codes, the PICAXE could easily decode, select the proper subroutine, and encode again to Morse to provide a very flexible command module. Effectively, a poor-man's command multiplexer using only one channel.
 
Last edited:

MFB

Senior Member
Nice work srnet! You may have been able to save a transistor by feeding the low-pass filter, on the NE 567 output, directly into a PICAXE Schmitt input (INPUT 2).
 

srnet

Senior Member
Nice work srnet! You may have been able to save a transistor by feeding the low-pass filter, on the NE 567 output, directly into a PICAXE Schmitt input (INPUT 2).
I have eliminated the transistor, you can apply feedback from the NE567 output back to pin 1.

But whilst it works well enough, the NE567 does not produce clean pulses when there is a reasonable amount of noise present, although the signla is quite readable by ear.
 

srnet

Senior Member
Fantastic.
Looks like a promising telemetry component on the receive end. While a nice side benefit of Morse is that it is human readable, it is still nice to have an inexpensive and flexible device that can 'read' Morse and optionally log data
That the 'data' it human readable is the key reason for selecting morse. The amount of data I am transmitting is small, either distance and direction (9 digits) or the Lat and Long position (12 digits). A key factor is that the Lost Model Locator should be useable with just a UHF tranciever, often when you are out flying you dont have a lot of kit with you. The transmitter I am using (RFM42) does have direct telemetry capability to a matching receiver the RFM31.

Guess I will build me a PCB combining the 28X2, RFM31 receiver, NE567, a driver to an LCD display and do some field testing.

The PCB for the GPS capable Lost Model Locator arived this morning (see picture) , this is using a 18F26K22 SSOP28 and Mikrobasic. There have been suggestions that the trig necessary calculations can be done in PICAXE basic, but not straight forward.
 

Attachments

MFB

Senior Member
Did you also remember to remove the transistor pull-up resistor? Also, unless your series resistor to the PICAXE is (say) ten times greater than the NE567 pull-up resistor low-pass filter will be unbalanced (e.g. when the NE567 output resister is off the filter capacitor sees the total value of both the pull-up and series resistor but when the transistor is on the capacitor is only the series resistor) and this will not make best use of the Schmitt input characteristics.
 

srnet

Senior Member
The transitor buffer does a better job compared to using the feedback filter option on the NE567. I did find a commercial design for a Morse decoder that appears to have come to the same conclusion, the NE567 feedback components had been removed and the jitter elimination removal was then (apparently) then being done in software.

I wonder if there are any off the shelf designs for a DSP type approach to filtering the audio before the NE567 ?

I have LTC1068 somewhere (2 x 4th order switched capacitor filter) but that requires fair few close tolerancwe components, and hardly a low cost approach.

It would be good to find a good method of enhancing performance, the audio frequncy of the morse can be fixed, even crystal controlled if need be, which ought to make filter design easier.
 

Armp

Senior Member
I wonder if there are any off the shelf designs for a DSP type approach to filtering the audio before the NE567 ?
....
It would be good to find a good method of enhancing performance, the audio frequncy of the morse can be fixed, even crystal controlled if need be, which ought to make filter design easier.
A lot of work was done back when the 567 was the only cheap solution. A full blown DSP approach is superior - but not really relevant to a PICAXE hosted forum. PM me if you want to discuss other solutions.

Chris

If it works it's obsolete!
 

srnet

Senior Member
A lot of work was done back when the 567 was the only cheap solution. A full blown DSP approach is superior - but not really relevant to a PICAXE hosted forum. PM me if you want to discuss other solutions.

Chris

If it works it's obsolete!
It was not a 'full blown DSP' approach I was suggesting, just dont have the time to develop such a DSP application.

If however someone had produced a (audio) DSP filter engine, programable for instance via say SPI or I2C for frequency and filter type, that would be of general interest here, it would be an easy to use solution to a common problem.
 

MFB

Senior Member
Not sure why an rc low-pass filter between the output of the NE567 and the Schmitt input of the 08M should not greatly reduce jitter. Provided that the filter resistor is significantly greater than the pull-up resistor this should work.

As mentioned before, it may also be worth adding a simple single op-amp band-pass filter on input of the NE567 with some back-to-back diodes to provide some 'soft' amplitude limiting. The final tone decoder circuit will still be a pretty low component count and power solution.
 

srnet

Senior Member
As mentioned before, it may also be worth adding a simple single op-amp band-pass filter on input of the NE567 with some back-to-back diodes to provide some 'soft' amplitude limiting. The final tone decoder circuit will still be a pretty low component count and power solution.
This was the approach I was going to take next. A single LM324 should give enough scope for some fairly effective filtering without adding much to the component count.

I recall many years ago building an 'audio processor' to be used for Shortwave DX listening, that had an audio limiter which was a couple of back to back Si diodes.
 

MFB

Senior Member
Sounds likes it would be worth digging out that old audio limiter circuit. Diodes can give rounded limiting that does not introduce too many harmonics.
 

MFB

Senior Member
Looks really clean! However, as the duration of the NE567 output spikes is significantly shorter than the Morse signal, it should be possible to reject noise with a single stage rc filter feeding a Schmitt input (discrete gate or PICAXE type). I use this simple low-pass filtering technique on inputs from switches and sensors for automotive systems. It normally consists of a 10K full-up resistor followed by a 100K series resistor and then a capacitor from the Schmitt input to ground. The capacitor value will determine the minimum pulse width/maximum pulse rate that will pass-through the filter.
 

srnet

Senior Member
Yes, agreed. Need to find schmitt CMOS logic gate to try, despite several square feet of component drawers with electronic bits in my workshop I cant find a logic schmitt, might even have to buy one !!!!

The filtering of the NE567 output did lead to a substantial improvement and was a low component count option.

Processing the incoming audio is not looking promising, and seems to be a great effort for only a minimal chnage in effectiveness. The NE567 seems to already be failry capable here without extra filtering.

My PC Storage scope has a spectrum analyser output, and attempts to add a diode limiter (passive or Op-Amp) introduces significant 2nd harmonics with little discernable change in detection.
 

MFB

Senior Member
I could also see little improvement when adding input filtering. Narrow-band radio receivers do a pretty good job anyway.

You could use the Schmitt input provided on input 2 (leg 5) of the 08M but there is of course no direct way of monitoring it's output.
 

srnet

Senior Member
You could use the Schmitt input provided on input 2 (leg 5) of the 08M but there is of course no direct way of monitoring it's output.
No direct way which would be nice, but a simple loop reading the input and setting an output would have a 'propagation delay' that gives a fairly good simulation.

But I would prefer to see the output for real.
 

MFB

Senior Member
How are things progressing? Hope you can find the time to post it under the Project Section when its finished.
 

srnet

Senior Member
So so. It definetly works.

The decoding copes with standard spacing morse at 15WPM, which as a novice reader I find difficult by ear, I need larger spaces between characters.

I have added (to the 08M2 code) some debug options that measure the period (thus frequency) of the incoming audio and the NE567 oscillator to make it easier to setup. There is an option that prints the measured mark and space on the incoming morse which allows you to see if the limits for mark and space are correct for the morse WPM.

I have added an output for a 16x2 character AXE133Y OLED and modified the OLED code so it runs at 38400 baud. Thus you can read the morse out and about without having to lug a PC around. I added a scroll mode to the OLED so the burden of displaying the last 32 characters is independant of the mark and space timing on the decoder. The decoder also outputs decoded morse (and debug stuff) to the serial terminal. You can press a button and the decoder stops and freezes the display of the last 32 characters.

I have recoded some received morse samples and various strengths so that I have a consistant signal to work with and am currently tweaking the various components and filters for best performance.

Once thats done, I will do a PCB so I can make a portable unit. I intend to make the PCB dual use with either a 20X2 or a 28X2 so that I can drive a single digit 7 segment display which would be enough (just) to allow the unit to fulfill a role of displaying the numbers for the GPS Lat and Long, without needing to have the OLED.

I will post it when done, the decoder can be built in a very basic version, without the various filters since the Ne567 works with reasonable signals direct to the input. Adding a HEX CMOS buffer allows the various filtering and debuging to be added. WIP circuit diagram of basic version and improved attached.
 

Attachments

Last edited:

srnet

Senior Member
Here is a sample of the amount of noise the current setup can cope with (so far). Its an on air recording of the numbers 0-9, its an MP3 (32kbs) of the original WAV which decodes every time so far.

Rename the flie to .mp3
 

Attachments

Last edited:

MFB

Senior Member
Thanks for the up date. Its very useful information.

Regarding your comments on the other thread about the potential hassle of using an FSK modem chip like the MX614, I'm sure it would offer good a performance with fewer bits (than the 'less simple' decoder ) and if you wanted to decode by ear you could simply filter out the 'space' frequency.

One of the main advantages of FSK modulation is that there is always a signal transmitted to overcome noise. In addition, the receiver does not have to deal with rapid changes in amplitude.
 

Paix

Senior Member
It's not unheard of to use two-tone Morse, to get the benefit of the noise margin. Transmitting a second tone instead of the space information.

Then it's a matter of selecting the mark or space tone and inverting the signal if necessary so that the keying is the right way up in your ears. for automatic decoding that's not quite so important.

The possible problem is that a transmitter will of course be 100% key down which might be significant if it is part of a telemetry scheme and battery power/endurance is at the transmitter is at a premium.

Not something you hear very much on the amateur bands though, other than for Packet CW_id.
 

mrburnette

Senior Member
It's not unheard of to use two-tone Morse, to get the benefit of the noise margin. Transmitting a second tone instead of the space information.
<...>
Multitone definitely has its place, but Morse was originally concocted as a on-off carrier (first DC, later RF) communication scheme. With keyed-carrier, CW, the tone is generated after reception by BFO circuitry. CW with a very narrow-band receiver has the benefit of lower transmitter average power which is nice for battery operated devices. The more tones we throw at the carrier, the wider the sidebands and the lower the average power in each frequency spectrum and the more complex the receiver and decoder.

I worked with wideband, multifrequency tone-pacs (600+) for many years in the military and my comments above are not meant to be opposed to multifrequency, but I think that for the model work that is being suggested, a locator beacon sending GPS coordinates, that the desire for a long battery life would bias the approach to the more simple implementations.

- Ray
 

MFB

Senior Member
Interesting comments about power consumption. Most the High Altitude Balloon teams seem to use FSK with Dlfigi software to track their payloads. Maybe they have found that the inherent noise advantages of multi-tone modulation allows operation at lower 'average' transmitter power.
 

srnet

Senior Member
Power consumption and a long battery life for the lost Model Locator was obviously an issue.

It was set up from the start to run from either the main flight battery OR a small circa 400mahr single cell Lipo as a backup. The backup battery is essential, its not uncommon for the heavier flight battery to become detached from a model in a crash. The main flight battery is used if its present and that will run down before the backup battery takes over.

The transmitter module (RFM42) is capable of data telemetry, and I have just sent off the morse decoder PCB to be made and that will have an option for a telemetry receiver (RFM31) driven by a 28X2.

The data telemetry ought to be very much more power efficient than transmitting morse, because its so much quicker to send tha data, but I just can't get the RFM42 & RFM31 to talk to each other digitally.
 
Top