Generating Simultaneous Tones

[OldVolts]

I’m working on a project that needs to transmit 16 “bits” of information, all 16 “bits” simultaneously. 
Currently using AX.25 but nowhere quick enough; AX.25 overhead is a killer.
Please note: I’m NOT looking for other ways to do this – 16 tones at a time is where we’re going.
Caveats: No operating system(s) – that’s it!
Can use a (reasonable) number of processors (16 is NOT reasonable)
Thoughts?
Experiences?
Thanks!
Bill

[Ian.M]

One possibility for the transmit end would be 4x four channel DDS chips with pins for external modulation control, e.g. AD9959.  That specific DDS is capable of sinewave output on four independent channels from near DC to tens of MHz with reasonably low waveform distortion, modulated by four profile (control) pins.  You can set up simple two frequency FSK, two level ASK and a variety of other modulation modes directly controlled by parallel data on the profile pins. Once configured, no further CPU intervention would be required.

However I'm fairly sure you wont like the price!

If you want a better answer that doesn't involve selling your firstborn into slavery to fund it, you'll need to give us the frequency range of the tones, and their required purity, and any other constraints on their modulation, + the data rate required (per bit/channel).

[gnuarm]

Sorry, I'm not familiar with AX.25 and I wasn't able to get my questions about it answered using Google.  I'm guessing that this has something to do with coding digital bits as audio tones.  Do you use a different tone for each of your 16 bit streams?  What about AX.25 is not quick enough???  Maybe more details of your problem and why it is hard to do would be helpful?

It does sound like maybe DDS would do the job for the transmit side.  I've done a fair amount of work with DDS and it's not at all difficult.  If you have a processor that is not heavily loaded it should not require so many MIPS either.  A DDS has a frequency control input which is also called the step size or phase increment register.  This value determines the frequency output.  Then there needs to be a phase accumulator (a counter, but adds the step size rather than just adding one each time).  The phase value in the accumulator increases steadily until it rolls over creating a sawtooth pattern corresponding to the phase of a rotator, 0 to 2pi radian (or 0 to 360 degrees if you prefer).  The phase accumulator value is translated to a sine wave value typically involving a lookup table for the 0:pi/2 range which is used to generate sine values from 0:2pi by inverting the phase input and/or negating the sine value output through the four quadrants.  These values are multiplied by an amplitude coefficient.  The result is a sine wave of very precisely controlled frequency and amplitude. 

Audio sample rates do not typically require much processor time for this, so all 16 sine waves can be generated in the same code run sequentially with 16 different frequency control words.  The values can be added and output to a single DAC to be output to the transmitter. 

Does that make sense?  Am I understanding what you are trying to do, i.e. create 16 separate modems to transmit 16 bit streams in parallel? 

The receiving side is a bit tougher.  That will require filtering to separate the frequencies.  I don't know what frequencies you wish to use, but can be a lot of processing and I expect it will require a DSP... maybe.  The devil is in the details.

[ogden]

Keyword: OFDM.

[gnuarm]

Keyword: OFDM.

I've got one word for you Benjamin, Plastics! 

[emece67]

.

[fcb]

So generating 16 tones simulataneously of say less than 3.4KHz?

Essentially you need 16 sine generators with a sample rate of perhaps 8KHz.  Using a LUT (look-up table) based DDS generator with a bit of linear-interpolation.

I've done 192KHz sinewave generation at -130dB distortion on a dsPIC33FJ128GP306 in the past, which would give 24 (192/8) tones with some mods.  So you're well within what can be done on a low end DSP, so something beefier (like the dsPIC33EP series) you could also run an FFT on the same part for receiption/decoding.

[gnuarm]

The FFT can be a lot of math, but how often you need to do the FFT depends on the data rate on the 16 tones, so it might be feasible on simpler devices.  A lot is missing from this project description, but I suppose you can set an upper limit on the data rate based on the tone separation (channel spacing).  So if 3.4 kHz is indeed the working bandwidth, that gives 212.5 Hz channel spacing.  So maybe 100 bps per channel.  Then a means of synchronizing to the data bits would be needed, so a faster FFT rate may be needed which would require overlapped FFTs.  As long as the FFT length is not too long this may be practical on a simple MCU.

I have not worked with OFDM before, so I don't know the practical details. 

[fcb]

Goertzel filters were/are used in a DTMF decoders.

DTMF is 8 seperate tones, applied in 16 combinations.

[gnuarm]

Goertzel filters were/are used in a DTMF decoders.

DTMF is 8 seperate tones, applied in 16 combinations.

I once interviewed with a telecom company where one of the questions asked was how to detect such tones.  I said, "Goertzel" and the interviewer said that was an obsolete method, there are better.  What I thought was strange was that he put so much emphasis on my knowing this up front rather than establishing what I might be able to figure out on the job if given a problem to solve.  I've never been big on memorizing stuff as a definition of my job.  I pride myself on adapting and learning new things.  The board I have in production now uses synthetic impedance generation to make the output look like 50 ohms with a 12.5 ohm resistor giving additional head room.  It took me a while to find a circuit to do this but it made the board practical without dissipating a bunch more heat and not reaching the amplitudes required.  I didn't have a clue this could be done when I started the design. 

In DTMF the difference in amplitude between the two tones is called, "twist".  I've always thought that was a strange term and wondered why this came about.

[ogden]

Keyword: OFDM.

I've got one word for you Benjamin, Plastics!

I was not kidding. In short: using iFFT it is possible to generate multiple tones, depending how you set bins of FFT. Using FFT you "demodulate" it.

Further reading

[gnuarm]

Keyword: OFDM.

I've got one word for you Benjamin, Plastics!

I was not kidding. In short: using iFFT it is possible to generate multiple tones, depending how you set bins of FFT. Using FFT you "demodulate" it.

Further reading

I never thought you were kidding.  You have to say something to make a joke.

[ogden]

Keyword: OFDM.

I've got one word for you Benjamin, Plastics!

I was not kidding. In short: using iFFT it is possible to generate multiple tones, depending how you set bins of FFT. Using FFT you "demodulate" it.

Further reading

I never thought you were kidding.  You have to say something to make a joke.

Single abbreviation was much more relevant than whole sentence of (yours), so stop , stay on topic please.

[OldVolts]

Perhaps some clarification is in order:
1.  Only 1 needed - can be "moderately" expensive (~$200)
2. User end (decoder) is simple Arduino based FFT display.  32 "bins" seems possible.
3.  Tones from 300 - 3000 Hz (audio passband of 220 MHz amateur transceiver) - preferably not harmonically related.
I have an amateur 2M repeater with 7 remote receive sites in addition to the local receiver. 
At the control site I can observe the activity of each remote site - receive or not receive (the first 8 "bits")
I can also watch the voter selected receiver indication (1 "bit" for each receiver but only 1 selected at a time) - the second 8 "bits"
We already take this information and place it into an AX.25 packet and transmit it out at 1200 bps but it can run 1/2 to 3/4 second behind due to packetization and buffering.
This lag prevents the  observation of the system as a whole - in real time - sometimes required to troubleshoot.
It also requires the user to make an investment in obtuse hardware and arcane software - in some cases a full PC or several (3) SOCs. 
One Arduino and a 2 line LCD display is WAY simpler and cheaper.

So far so good - several interesting things to look at more closely.
Bill

[gnuarm]

Keyword: OFDM.

I've got one word for you Benjamin, Plastics!

I was not kidding. In short: using iFFT it is possible to generate multiple tones, depending how you set bins of FFT. Using FFT you "demodulate" it.

Further reading

I never thought you were kidding.  You have to say something to make a joke.

Single abbreviation was much more relevant than whole sentence of (yours), so stop , stay on topic please.

LoL!  Your initial post had nearly zero information content.  Your second post contained a single comment and griped that I didn't post anything useful which is false.  Why don't you try contributing something rather than arguing about it?  Try explaining how the frequencies would be assigned and how they should relate to the sample rate for optimum isolation of the channels and how fast data might be sent given the constraints of the FFT.  Do you have experience with any of this?

[gnuarm]

So maybe you can leave out the irrelevant information and explain what it is you require from the communications channel.  When you talk about voter circuits and arcane software this is information that I can't use for anything. 

Why don't you pick the frequencies and tell us what they should be?  What is the data rate you want to see on the channels? 

[langwadt]

Perhaps some clarification is in order:
1.  Only 1 needed - can be "moderately" expensive (~$200)
2. User end (decoder) is simple Arduino based FFT display.  32 "bins" seems possible.
3.  Tones from 300 - 3000 Hz (audio passband of 220 MHz amateur transceiver) - preferably not harmonically related.
I have an amateur 2M repeater with 7 remote receive sites in addition to the local receiver. 
At the control site I can observe the activity of each remote site - receive or not receive (the first 8 "bits")
I can also watch the voter selected receiver indication (1 "bit" for each receiver but only 1 selected at a time) - the second 8 "bits"
We already take this information and place it into an AX.25 packet and transmit it out at 1200 bps but it can run 1/2 to 3/4 second behind due to packetization and buffering.
This lag prevents the  observation of the system as a whole - in real time - sometimes required to troubleshoot.
It also requires the user to make an investment in obtuse hardware and arcane software - in some cases a full PC or several (3) SOCs. 
One Arduino and a 2 line LCD display is WAY simpler and cheaper.

So far so good - several interesting things to look at more closely.
Bill

16 bits at 1200bps is ~13ms, an arduino should have no problem doing 1200bps

[ogden]

Why don't you try contributing something rather than arguing about it?

I already contributed by telling that OFDM could be solution. Sorry if you were unable to process that.

Try explaining how the frequencies would be assigned and how they should relate to the sample rate for optimum isolation of the channels and how fast data might be sent given the constraints of the FFT.  Do you have experience with any of this?

OP/you can start with link I gave. Other useful resource about using OFDM multicarrier communication is https://en.wikipedia.org/wiki/PRIME_(PLC). PRIME-Spec_v1.3.6.pdf to be specific. Obviously basic knowledge of FFT/iFFT will help. Yes, I know enough about subject. No, I won't do any classes here.

[fourfathom]

It sounds to me that the OP is considering DMT (Discrete Multi Tone), with essentially on/off keying of the individual tones.

[OldVolts]

Exactly that.
Thanks!

[OldVolts]

16 bits at 1200bps is ~13ms, an arduino should have no problem doing 1200bps

Unfortunately it's not the "bits" that are the problem with AX.25.
Once the initial connection is established, data is transferred in frames - I (information) frames to be specific.
Fields in a frame:
Flag (8 bits), Address (112 to 560 bits), Control (8 bits), PID (8  bits), Information (our 16 bits), FCS (16 bits), Flag (8 bits) -
Therefore we have to transmit a WHOLE BUNCH more than our 16 bits of data to satisfy the AX.25 protocol requirements.
Oh - and the frame, once received, must be acknowledged back to the sender before the sender will send the next frame.
Sigh - AX.25 was not the best implementation.  Why I'm asking the group mind for ideas.

Thanks,
Bill

[David Hess]

Goertzel filters were/are used in a DTMF decoders.

That is probably the method I was thinking of.  As I recall, the Goertzel method is like a truncated FFT.  Long ago I used it on a PIC to decode DTMF.

In DTMF the difference in amplitude between the two tones is called, "twist".  I've always thought that was a strange term and wondered why this came about.

I thought it was because on an oscilloscope, the two tone combination looks like it "twists".

[fourfathom]

Then assuming the FM rigs have an audio bandwidth that covers 500Hz to 2500 Hz, you might choose tones starting at 550 Hz with a tone spacing of (say) 125 Hz.  This avoids harmonics of the lower tones (caused by distortion) falling on top of the upper tones -- at least I think it does.  FFT seems to be the way to decode these, and software generation of the tones seems pretty straightforward.  Of course the FFT buckets have to be narrow enough to not include the harmonics that *are* there.  I suppose you could use the same tone generation software to create quadrature tones and make individual tone detectors.  I have no idea if this is easier or harder than the FFT -- never done it myself.

[rfclown]

Keyword: OFDM.

I second the OFDM suggestion. I'd done RF hardware for many years and had done a fair amount of baseband work for Tx, but never Rx. With OFDM I was able to code a receiver. It's pretty slick. You use training symbols which allow you to do frequency correction and equalizattion. It seems exactly what you are asking for.

[gnuarm]

Then assuming the FM rigs have an audio bandwidth that covers 500Hz to 2500 Hz, you might choose tones starting at 550 Hz with a tone spacing of (say) 125 Hz.  This avoids harmonics of the lower tones (caused by distortion) falling on top of the upper tones -- at least I think it does.  FFT seems to be the way to decode these, and software generation of the tones seems pretty straightforward.  Of course the FFT buckets have to be narrow enough to not include the harmonics that *are* there.  I suppose you could use the same tone generation software to create quadrature tones and make individual tone detectors.  I have no idea if this is easier or harder than the FFT -- never done it myself.

The problem with the narrow spacing of tones is it requires a longer FFT to resolve them.  That implies a slower bit rate.  Why is it good to limit the low end of the frequency range so much?  If your tone spacing is 125 Hz, there's no reason in the processing to not use down to say, 200 Hz to allow a bit wider spacing.  Is there something about the RF gear that limits the low end range?  The OP is pretty stuck in seeing his original problem that he is having trouble explaining the requirements for the solution.  I don't think any references to AX.25 add anything to understanding the problem.  I'd love to see a simple statement of what is to be achieved with data rates and other requirements. 

The FFT is exactly the same as multiplying the input by a number of quadrature tones, i.e. a DFT.  Cooley and Tukey just found a clever way to take advantage of symmetries in the sine function to reduce the number of multiply operations.  Seems Gauss had actually discovered this 160 years earlier, but it had been forgotten by the people who could use it in the 1960s.  Hmmmm...

That actually made me realize this is one of those times when the FFT may be less efficient than the DFT.  The FFT is O(n log2(n)).  The DFT is O(n) for any bin and the max bins are O(n).  But in this case only 16 bins are needed.  So if the FFT size is large enough, it would be faster to calculate the specific bins needed in the DFT.  The cross over point would be at length 2^16 times some constant.  The constant would be approximately 0.5 since the FFT butterfly has two complex multiplies and two adds while the DFT unit is one of each.  Even so, the crossover would be about 32K data points which is far more than needed, so the FFT would still be faster.  Did I do that right?

[oPossum]

2. User end (decoder) is simple Arduino based FFT display.  32 "bins" seems possible.
3. Tones from 300 - 3000 Hz (audio passband of 220 MHz amateur transceiver) - preferably not harmonically related.

Well, then the obvious answer for how to generate the tones would be with an IFFT. The bins of an FFT have rational relationship, so not a great choice if you really want non-harmonic related tones. Using only 32 bins makes them quite wide, so poor SNR.

We already take this information and place it into an AX.25 packet and transmit it out at 1200 bps but it can run 1/2 to 3/4 second behind due to packetization and buffering.

You could just use the underlying Bell 202 with some simple error checking.

[fourfathom]

Why is it good to limit the low end of the frequency range so much?  If your tone spacing is 125 Hz, there's no reason in the processing to not use down to say, 200 Hz to allow a bit wider spacing.  Is there something about the RF gear that limits the low end range?

if I'm not mistaken, the OP intends to send these tones via ham narrowband FM.  These radios usually have a lower-frequency audio cutoff somewhere above 300 Hz, and they often limit the high end to 3 KHz or even less.  It's sort of like the old telephony audio range of 300-3000 Hz, and often even narrower.

[langwadt]

16 bits at 1200bps is ~13ms, an arduino should have no problem doing 1200bps

Unfortunately it's not the "bits" that are the problem with AX.25.
Once the initial connection is established, data is transferred in frames - I (information) frames to be specific.
Fields in a frame:
Flag (8 bits), Address (112 to 560 bits), Control (8 bits), PID (8  bits), Information (our 16 bits), FCS (16 bits), Flag (8 bits) -
Therefore we have to transmit a WHOLE BUNCH more than our 16 bits of data to satisfy the AX.25 protocol requirements.
Oh - and the frame, once received, must be acknowledged back to the sender before the sender will send the next frame.
Sigh - AX.25 was not the best implementation.  Why I'm asking the group mind for ideas.

Thanks,
Bill

so don't use the AX.25 protocol, just use the 1200bps and your own protocol

[gnuarm]

Why is it good to limit the low end of the frequency range so much?  If your tone spacing is 125 Hz, there's no reason in the processing to not use down to say, 200 Hz to allow a bit wider spacing.  Is there something about the RF gear that limits the low end range?

if I'm not mistaken, the OP intends to send these tones via ham narrowband FM.  These radios usually have a lower-frequency audio cutoff somewhere above 300 Hz, and they often limit the high end to 3 KHz or even less.  It's sort of like the old telephony audio range of 300-3000 Hz, and often even narrower.

So you are saying this is how the equipment is designed.  Is there a reason for this low end cutoff of the equipment being so high?  Is it just to reduce the required size of the coupling caps in the signal path?

[fourfathom]

So you are saying this is how the equipment is designed.  Is there a reason for this low end cutoff of the equipment being so high?  Is it just to reduce the required size of the coupling caps in the signal path?

Not at all!  The audio channel is optimized for voice communications, so the frequency cutoffs are chosen to pass the voice frequencies needed for comprehension.  By design it's not Hi-Fi, but an optimization of radio channel utilization and voice communications effectiveness. 

True, shifting down the low-frequency cutoff wouldn't increase the FM occupied bandwidth, but excess low-frequency response can reduce comprehension as it allows low-frequency noise (vehicle rumble, etc) to interfere.

[oPossum]

So you are saying this is how the equipment is designed.  Is there a reason for this low end cutoff of the equipment being so high?  Is it just to reduce the required size of the coupling caps in the signal path?

Not at all!  The audio channel is optimized for voice communications, so the frequency cutoffs are chosen to pass the voice frequencies needed for comprehension.  By design it's not Hi-Fi, but an optimization of radio channel utilization and voice communications effectiveness. 

True, shifting down the low-frequency cutoff wouldn't increase the FM occupied bandwidth, but excess low-frequency response can reduce comprehension as it allows low-frequency noise (vehicle rumble, etc) to interfere.

Amateur radio on the VHF/UHF bands uses the lower frequencies for CTCSS so the audio frequency response begins above this range.

https://en.wikipedia.org/wiki/Continuous_Tone-Coded_Squelch_System

[ogden]

It's sort of like the old telephony audio range of 300-3000 Hz, and often even narrower.

So you are saying this is how the equipment is designed.  Is there a reason for this low end cutoff of the equipment being so high?  Is it just to reduce the required size of the coupling caps in the signal path?

Low end frequency of baseband will inevitably leave impact on frequency of symbol rate.

[gnuarm]

So you are saying this is how the equipment is designed.  Is there a reason for this low end cutoff of the equipment being so high?  Is it just to reduce the required size of the coupling caps in the signal path?

Not at all!  The audio channel is optimized for voice communications, so the frequency cutoffs are chosen to pass the voice frequencies needed for comprehension.  By design it's not Hi-Fi, but an optimization of radio channel utilization and voice communications effectiveness. 

True, shifting down the low-frequency cutoff wouldn't increase the FM occupied bandwidth, but excess low-frequency response can reduce comprehension as it allows low-frequency noise (vehicle rumble, etc) to interfere.

Ok, there!  Everything in the first paragraph is not actually relevant.  But the need to limit the low frequency response to exclude noise would be an actual reason to limit the bandwidth.

[gnuarm]

It's sort of like the old telephony audio range of 300-3000 Hz, and often even narrower.

So you are saying this is how the equipment is designed.  Is there a reason for this low end cutoff of the equipment being so high?  Is it just to reduce the required size of the coupling caps in the signal path?

Low end frequency of baseband will inevitably leave impact on frequency of symbol rate.

As does the tone spacing, so there is a tradeoff between the two with an optimum point.

[fourfathom]

The audio channel is optimized for voice communications, so the frequency cutoffs are chosen to pass the voice frequencies needed for comprehension.  By design it's not Hi-Fi, but an optimization of radio channel utilization and voice communications effectiveness.

Ok, there!  Everything in the first paragraph is not actually relevant.  But the need to limit the low frequency response to exclude noise would be an actual reason to limit the bandwidth.

Are you saying my first paragraph (quoted above] is irrelevant?  Why?  Commercial and ham narrowband FM works with narrow RF channel spacing, and widening the modulated FM signal by including the unnecessary high audio frequencies might lead to adjacent-channel interference.  By the way, we also have to allow for a small amount of transmitter frequency inaccuracy, so we need some buffer between channels -- again, to minimize adjacent channel interference.

[gnuarm]

The discussion is about the low frequency cut off.  While below 500 Hz may not be required for intelligibility, unless there is a specific reason to not transmit it there is no reason to block it.  Telephony passes frequencies between 300 Hz and 500 Hz, so it would seem there may be some minor loss of intelligibility or the phone companies and radio would likely use the same pass band.   Your second paragraph gives a reason to block it, low frequency noise which is present in mobile applications.  This would not have been a consideration in the initial design of telephony systems which set their standard. 

In this post you have shifted to talking about the high frequency cutoff, totally unrelated. 

Someone else talked about using frequencies below 500 Hz for CTCSS so clearly frequencies below 500 Hz are being transmitted on the RF, just not used for voice. 

[cdev]

use the sin() function. and summing of the separate generators and then a D to A converter (like a USB sound card?)

You can do the DDS thing in pure software. I've done it with only 2 simultaneous tones, but going to 16 only needs a faster processor. DDS is easy enough to even be feasible in assembly.

A small FPGA will also fit it, in case you need more speed.

Regards.

[cdev]

You may have to look pretty far back to find discussions on this but the search term "in band signalling" should bring up a fair amount of stuff.

The discussion is about the low frequency cut off.  While below 500 Hz may not be required for intelligibility, unless there is a specific reason to not transmit it there is no reason to block it.  Telephony passes frequencies between 300 Hz and 500 Hz, so it would seem there may be some minor loss of intelligibility or the phone companies and radio would likely use the same pass band.   Your second paragraph gives a reason to block it, low frequency noise which is present in mobile applications.  This would not have been a consideration in the initial design of telephony systems which set their standard. 

In this post you have shifted to talking about the high frequency cutoff, totally unrelated. 

Someone else talked about using frequencies below 500 Hz for CTCSS so clearly frequencies below 500 Hz are being transmitted on the RF, just not used for voice.

[MIS42N]

Are we being presented with a 'solution' to a not fully defined problem and then requested to flesh out the solution. I looked at it and thought 'I created a TOG for an ATmega328P, two of them would do it easily' [TOG - top octave generator, generates the 12 tones from D8 (4694.8Hz) to C9 (8368.2Hz) - used in old electronic organs]. But they are (a) not in the specified frequency range (b) continuous (c) come out of separate pins (d) square wave. So could that be modified to do the job? So then one asks, why use frequency division multiplexing (FDM) versus time division multiplexing. It is way more complex. A simple 1200 baud FSK signal would move 16 bits in 13ms, does it need to be quicker? If so, why? Although it requires parallel to serial conversion by the sender and serial to parallel conversion by the receiver, these are simple tasks offloaded to sub $1 parts.

I think we need a better definition of the problem. I know there was a partial explanation a few posts back, but it left out things like what data rate is required (more than 1200 bit/sec?), what delays are tolerable, how far the signal needs to propagate (is there a significant path delay), if there are errors, (a) that's OK (like in VoIP) (b) should be detected but don't require correction (c) need a forward correction like trellis encoding (d) could deal with as a simple ACK/NAK resend (if there's little latency, this could be achieved in less than 100ms). What is the significance of 16 bit? What SNR is this to work within. Is it a one off to fit a specific situation or should it allow for future mods and what might they be?

This is the bane of the system analyst. Brings to mind the story of the advertised job, financial manager pay $2 million p.a. Candidate asks what the job entails. "First figure out how you get paid".

[ogden]

Flag (8 bits), Address (112 to 560 bits), Control (8 bits), PID (8  bits), Information (our 16 bits), FCS (16 bits), Flag (8 bits) -
Therefore we have to transmit a WHOLE BUNCH more than our 16 bits of data to satisfy the AX.25 protocol requirements.
Oh - and the frame, once received, must be acknowledged back to the sender before the sender will send the next frame.
Sigh - AX.25 was not the best implementation.  Why I'm asking the group mind for ideas.

Overcomplicated. Especially considering that you are reinventing modem. For what? Single installation of 6 stations? I would use ISM band LoRa modules. It is <20$ whole radio including packet modem, thou w/o antenna

[cdev]

Is there any reason you cannot use a widely available DTMF encoder/decoder?

DTMF has 16 tones available in a 4x4 matrix

You can generate and decode DTMF with Audacity although I don't know how or if it would generate or decode multiple tones occupying the same time slot properly.

Does Gnuradio have the tools to do this? It seems to me that it might, and if so that would save you building your own. I would look at that first.

[David Hess]

Amateur radio on the VHF/UHF bands uses the lower frequencies for CTCSS so the audio frequency response begins above this range.

I have modified a few FM transceivers to gain direct access to the FM modulator and demodulator.  As you mention, the frequencies below the lower end of the voice band are used for sub-audible signalling.  Frequencies above the voice band are used to measure quieting which is what triggers the squelch on the receiver.  But of course you cannot access either of these through the audio output because it is filtered to limit it to roughly 300 to 3000 Hz to remove them.

Another thing to consider is that the audio filtering will usually have considerable phase distortion which can interfere with modulation that relies on phase.

[fourfathom]

About the original problem, I believe I was confused by the details of the multiple radio data source, and the desired data display.  So let me try to rephrase the problem (?):
* You have data from up to multiple radio/repeaters.  I think this is one or two bits per radio.
* A decision has been made to use AX.25  to transmit this data to a monitoring site.  This protocol has a lot of overhead, and generally uses 1200 bits/sec FSK on VHF links.
* You are looking for a more efficient (bits per second) way to send AX.25 over a narrowband FM channel, audio bandwidth perhaps 300 - 3000 Hz.

Is this correct?

If so, there are faster modulation methods being used for AX.25 over VHF.  I see that 9600-baud FSK is being used but that baud rate seems way too high for a 3KHz channel.  The documents I have seen are fuzzy on the whole bits/sec vs baud thing.

If you want to roll your own modem, then DMT modulation isn't a bad way to go (that's what telephone ADSL modems use, with rate-adaptive QAM and a variable number of carriers.)  But you might want to look at commercial radio-optimized modems like PACTOR or the almost-free VARA software modem.

[jmelson]

This should be trivial using an FPGA, implementing 16 DDS blocks and generating, say, 8-bit sine waves.
Each sine wave digital value would be added to the current sample when its corresponding bit was a '1'.
The sine table would be scaled so all of them hitting the max value at the same time would not overload the number of bits on the output.  Then, you feed that sum to a DAC. 

I'm guessing for modest audio frequencies that this could be done with a DSP chip or maybe even fast microcontroller.

Jon

[fourfathom]

I'm guessing for modest audio frequencies that this could be done with a DSP chip or maybe even fast microcontroller.

Easily.  Or on a PC.  If I understand the problem, the use of 16 on/off carriers was just a suggested way to carry 16 bits of data per "Baud" or symbol period.  If so, there are better ways to do this. 

As I mentioned, VARA is a software modem, optimized for radio comms,  that runs on a standard PC.  It uses 52 carriers. with the individual carrier modulation adapted according to the channel characteristics.  The symbol rate (Baud) is 37.5 Hz.  The individual carrier modulation ranges from BPSK through 4PSK / 8PSK / 16QAM and 32QAM.  The bytes per packet rate (or packet length) is also varied to optimize for the  channel conditions.  The actual modulation and demodulation are probably the easy part, it's the adaptive capabilities that are quite complicated.

I'm not suggesting that the OP needs to do anything this complicated, just that a simple software modem isn't that hard and perhaps more bits/second could be achieved by choice of a better modulation technique.

VARA: https://rosmodem.wordpress.com/2017/09/03/vara-hf-modem/

[rfclown]

Amateur radio on the VHF/UHF bands uses the lower frequencies for CTCSS so the audio frequency response begins above this range.

I have modified a few FM transceivers to gain direct access to the FM modulator and demodulator.  As you mention, the frequencies below the lower end of the voice band are used for sub-audible signalling.  Frequencies above the voice band are used to measure quieting which is what triggers the squelch on the receiver.  But of course you cannot access either of these through the audio output because it is filtered to limit it to roughly 300 to 3000 Hz to remove them.

Another thing to consider is that the audio filtering will usually have considerable phase distortion which can interfere with modulation that relies on phase.

And there is 6dB/octave pre-emphasis on Tx and de-emphasis on Rx. At least in the land mobile band it was required. You could cheat the requirement by using a "dummy microphone" as allowed by EIA. You could make the dummy mic response compensate for your desired response. I was once presented with the task of regulatory testing of a radio with a really weird Tx response. The original designer had gone beyond cheating and didn't even actually measure the response of the radio system, but the response of a audio module in "Ray's fixture". (That's what was in his log book). The R and C values I calculated to make a passive dummy mic to do the job were stupid, so I asked if it was ok to make an active dummy mic. I was told ok, so I cheated in the way that the regulation allowed.

[OldVolts]

Decoding is simple: Google for "Arduino audio analyzer" - plenty of examples.
Yes - Going to have to get rather picky about the tones to avoid intermod generated false tones. 
Pure sinewave would be best as most, if not all FM modulators have "deviation limiters" which clip the audio. 
Will have to keep the tones (combined waveform including peaks) well below the clipping level.
Currently looking at possible Arduino generation using PWM but finding that having only a single clock frequency to play with makes tone selection a big issue. 
More to learn unless the hive mind comes up with something simple.
Thanks,
Bill

[Marco]

2. User end (decoder) is simple Arduino based FFT display.  32 "bins" seems possible.

If you can use an Arduino can't you just use a Teensy 4 with their audio library to generate the sines, sum them and output them?

I don't care how inefficient Arduino programming is, a 600 MHz Cortex M-7 is not going to care for this.

[gf]

Currently looking at possible Arduino generation using PWM but finding that having only a single clock frequency to play with makes tone

A DDS generator is not difficult either. For each sample of each tone, add a pre-calculated offset to the tone's phase accumulator and then use the upper N bits of the phase accumulator as index into a pre-calulated sine waveform table (of size 2^N). Just a handful of instructions per sample and tone. Then add the sine values of all tones and send the sample to the DAC. In practice one would not send each sample directly to the DAC, but one would rather use DMA and double buffering (as explained here). 3kHz bandwith require a sampling rate of > 6kHz. I would oversample though (say 4x, or even more if possible) in order to reduce the transition band steepness requirements for the analog reconstruction filter after the DAC.

EDIT: How many 16-bit symbols do you need to transmit per second?

[gf]

As I mentioned, VARA is a software modem, optimized for radio comms,  that runs on a standard PC.  It uses 52 carriers. with the individual carrier modulation adapted according to the channel characteristics.  The symbol rate (Baud) is 37.5 Hz.  The individual carrier modulation ranges from BPSK through 4PSK / 8PSK / 16QAM and 32QAM.  The bytes per packet rate (or packet length) is also varied to optimize for the  channel conditions.  The actual modulation and demodulation are probably the easy part, it's the adaptive capabilities that are quite complicated.

I'm not suggesting that the OP needs to do anything this complicated, just that a simple software modem isn't that hard and perhaps more bits/second could be achieved by choice of a better modulation technique.

VARA: https://rosmodem.wordpress.com/2017/09/03/vara-hf-modem/

I did not find any source code. Is it open source?
Btw, yet another (open source) soft modem implementation (for Linux) is linmodem.

But I would only consider a sophisiticated modem implementation if a higher bit rate and/or better BER are really required.
Seems to me that OldVolts has not very high requirements, though, and rather wants a simple solution.

[OldVolts]

So you are saying this is how the equipment is designed.  Is there a reason for this low end cutoff of the equipment being so high?  Is it just to reduce the required size of the coupling caps in the signal path?

In commercial and most amateur VHF systems, frequencies below 300 hertz are filtered out and used for "sub-audible" signalling e.g. CTCSS / PL / Quiet Channel as examples.
Bill

[OldVolts]

So you are saying this is how the equipment is designed.  Is there a reason for this low end cutoff of the equipment being so high?  Is it just to reduce the required size of the coupling caps in the signal path?

In commercial and most amateur VHF systems, frequencies below 300 hertz are filtered out and used for "sub-audible" signalling e.g. CTCSS / PL / Quiet Channel as examples.
Bill

[OldVolts]

Currently looking at possible Arduino generation using PWM but finding that having only a single clock frequency to play with makes tone

EDIT: How many 16-bit symbols do you need to transmit per second?

All of them 

[gf]

I don't care how inefficient Arduino programming is, a 600 MHz Cortex M-7 is not going to care for this.

At a sampling rate of (say) 48kSa/s, there are 12500 clock cycles available per sample, or 781 clock cycles per sample and tone. Do you really think that 781 clock cycles don't suffice to calculate one DDS sample for one tone (-> 1x integer add, 1x integer shift, 3x memory fetch, 1x memory store)

[Marco]

Sorry, that's what I meant ... the Teensy 4 is always going to be fast enough, no matter how inefficient the programming. The Teensy also has a proper DAC, so no need for PWM.

PS. oops, only the older Teensy's have a DAC ... still the 72 MHz for a 3.2 should still be plenty using their libraries for synthesis.

[gf]

EDIT: How many 16-bit symbols do you need to transmit per second?

All of them 

What is "all of them"? How many times per second do the state bits change at maximum? The available bandwidth imposes an upper limit. Given a bandwidth of 3000-300=2700 Hz and 16 sub-channels, the maximum bandwith which can be allocated to a sub-channel is 2700/16=168.75 Hz. Unipolar NRZ with moderate pulse shaping has a baseband bandwidt equal to the bit rate, and the modulation to the carrier is eventually AM with double sideband, therefore the maximum bitrate for each of the 16 bit-streams cannot exceed 168.75/2=84.375 bits/s. I.e. you can send the state bits 84 times per second, at maximum. Eventually you win almost nothing compared to Bell 202 FSK @1200 bits/s. If you need more, then you need to consider a more sophisticated kind of modulation, not a simpler one.

[fourfathom]

VARA: https://rosmodem.wordpress.com/2017/09/03/vara-hf-modem/

I did not find any source code. Is it open source?
Btw, yet another (open source) soft modem implementation (for Linux) is linmodem.

But I would only consider a sophisiticated modem implementation if a higher bit rate and/or better BER are really required.
Seems to me that OldVolts has not very high requirements, though, and rather wants a simple solution.

VARA is not open source.  A less powerful, but still very impressive software modem for radio channels is (I believe) open source: WINMOR.  As with VARA, WINMOR is an auto-adaptive mode with ACK/NAK feedback from the receiving end used to adjust the modulation and speed choices.  I highly doubt that the OP wants or needs this type of behavior.

My understanding of the OP's goal is that he wants data rates faster than the 1200 bps modem traditionally used in VHF AX.25 packet operation.  How much faster? I don't know.  Clarification would be useful.

This is also assuming that the OP is stuck with the AX.25 protocol for sending his data.  If the goal is just to continually send sixteen bits at a fast rate then there are obviously much simpler ways than using AX.25.  But one advantage of AX.25 (as opposed to some unique simple protocol) is that AX.25 is compatible with the ham data infrastructure, so there's that.

[gnuarm]

This should be trivial using an FPGA, implementing 16 DDS blocks and generating, say, 8-bit sine waves.
Each sine wave digital value would be added to the current sample when its corresponding bit was a '1'.
The sine table would be scaled so all of them hitting the max value at the same time would not overload the number of bits on the output.  Then, you feed that sum to a DAC. 

I'm guessing for modest audio frequencies that this could be done with a DSP chip or maybe even fast microcontroller.

Jon

These signals are audio.  There is no reason to use 16 different DDS generators.  A single  generator with 16 sets of registers (easily implemented in LUT memory) will run many times faster than required.  As others have pointed out this can easily be done in nearly any MCU you can think of.  It is the decoding that is a bit more difficult.  Some are suggesting an FFT is the way to go, but the devil is in the details and so far I have not seen any details from the OP.  In fact, this "project" may just be a prank.   He seems to be responding to serious questions with sarcasm. 

Yeah, it seems like it's time to ignore this thread.  Am I wrong?

[ogden]

Some are suggesting an FFT is the way to go, but the devil is in the details and so far I have not seen any details from the OP.

No offense to OP intended, but usually reason of insufficient info is lack of knowledge to provide such. That comes into mind when I see requirement "NO other way than 16 simultaneous tones and selfmade modem".

Yeah, it seems like it's time to ignore this thread.  Am I wrong?

You are wrong indeed. Besides OP there are other forum members who can learn something new.

[MIS42N]

Yeah, it seems like it's time to ignore this thread.  Am I wrong?

Not wrong.

In the 90s there was a Telebit trailblazer modem that could punch 19.2kbit (16 * 1200kbit) through pretty bad analog telephone circuits. I implemented a dial up mail link between Australia and the UK using a pair. At the time they were $2000 each, but saved that amount in a few months by reducing the quite expensive telephone costs. Whatever scheme they used may suit OP. However he is explicit in requiring 16 tones, for unexplained reasons. With poorly defined requirements, strange constraints and lack of engagement it may just be a stir. I'm out.

[gnuarm]

Some are suggesting an FFT is the way to go, but the devil is in the details and so far I have not seen any details from the OP.

No offense to OP intended, but usually reason of insufficient info is lack of knowledge to provide such. That comes into mind when I see requirement "NO other way than 16 simultaneous tones and selfmade modem".

The OP has repeatedly ignored direct questions and even answered them flippantly. 

   

        How many 16-bit symbols do you need to transmit per second?

    All of them 

If a lack of knowledge is the problem then it would be a simple matter to for him to ask more questions.  The main reason I come to this group is to learn.  I'm happy to ask questions.  But some people seem to have less obvious reasons for being here.

Yeah, it seems like it's time to ignore this thread.  Am I wrong?

You are wrong indeed. Besides OP there are other forum members who can learn something new.

Without a clear statement of requirements it's a bit like asking how long is a piece of string?  Do you plan to continue to espouse effluently on a vague subject?  One of the posts consisted of nearly a single word with no explanation at all.  So I guess on the average the posts are a good length.

[ogden]

You are wrong indeed. Besides OP there are other forum members who can learn something new.

Without a clear statement of requirements it's a bit like asking how long is a piece of string? Do you plan to continue to espouse effluently on a vague subject? One of the posts consisted of nearly a single word with no explanation at all.  So I guess on the average the posts are a good length.

Threads like this can teach many lessons besides primary question. Like how to not piss off those who are trying to help you I still believe that OP is clueless dreamer who can't keep-up with ideas provided. Also I believe that contributors can continue discussion disregarding - OP is following or not, because many other forum members are reading and learning. Feels like I am repeating myself.

[langwadt]

https://xyproblem.info/

[gnuarm]

So how long is that piece of string?   

[fourfathom]

So how long is that piece of string?   

The answer doesn't much matter to me.  What I enjoy is the process we go through along the way, wherever we end up.  Perhaps we never end up anywhere, and that's OK too.

If it were critical that we solve "this particular problem", and as is the case here we were given little information and less useful feedback, then I would be immensely frustrated.  But hey, we're discussing radio modems, channel characteristics, modulation and demodulation techniques, etc.  I enjoy thinking about this stuff and occasionally learning something new.

[gnuarm]

The problem is there needs to be a context for the discussion.  One person says this, another says that and they are both right without any qualifications.  Meanwhile very little of substance is being discussed.  People are saying FFT/IFFT is the way to do "it".  Others talk of tone generators and detectors solving "it" and others say use standard modem techniques to ship the data of "it".  Yes, they are all right.  Meanwhile no one is pointing out the advantages or limitations of the techniques in a useful way. 

Discussing issues in general is fine, but without a context we might as well be discussing the weather.  Hmmm... I wonder what an FFT of the weather patterns would look like.  Better yet, do an IFFT and control the weather!   

[ogden]

Discussing issues in general is fine, but without a context we might as well be discussing the weather.  Hmmm... I wonder what an FFT of the weather patterns would look like.  Better yet, do an IFFT and control the weather!   

If you expect that someone suggesting FFT as an solution will teach you generic DSP as well, then you are mistaken to say it politely

[oPossum]

Hmmm... I wonder what an FFT of the weather patterns would look like.

https://joannenova.com.au/2013/05/fourier-analysis-reveals-six-natural-cycles-no-man-made-effect-predicts-cooling/

[gnuarm]

Hmmm... I wonder what an FFT of the weather patterns would look like.

https://joannenova.com.au/2013/05/fourier-analysis-reveals-six-natural-cycles-no-man-made-effect-predicts-cooling/

Interesting.  "However one has to caution for artefacts. An obvious one is the limited length of the records. The dominant 250 year period peak in the spectrum results from only one period in the data. This is clearly insufficient to prove periodic dynamics." 

It is not surprising there would be a very low frequency peak.  If the AGW influence is relegated to the last 100 or so years and the time span of the data is a bit over 200 years, that would fit very well with a ~240 year period.  Duh! 

Fourier spectral analysis starts with the math principle that all signals can be represented as a sum of sine waves.  So why is it surprising to see peaks in the spectrum? 

[oPossum]

I have seen a much more in-depth Fourier analysis that used a longer time period. Unfortunately I couldn't find a link.

[gf]

[...] It is the decoding that is a bit more difficult. Some are suggesting an FFT is the way to go, but the devil is in the details [...]

Indeed, the devil is in the details.
I tried a rudimentary simulation in Octave, using a sliding FFT as filter bank.
A few things turned out to be important:

• Since the carrier frequencies (16 equally spaced channels in the 300...3000Hz band) are not approriate for baseband FFT, I needed to shift them with a quadrature mixer in the first place. Alternatively a different frequency plan with less bandwidth per sub-channel and several unused sub-channels could be chosen.
  
• Proper pulse shaping on the sender side turned out very important in order to avoid ICI (inter-carrier interference, i.e. cross-talk betwen the channels) which made error-free demodulation impossible.
  
• I had to use twice the number of FFT bins in order to account for the main lobe width of the window function (i.e. only every 2nd bin is eventually evaluated).
  Alternatively I tried w/o window function (i.e. with rectangular window), but the spectral leakage did lead to too much border discontinuity effects and channel crosstalk, since the modulated channels are no longer CW but have a bandwidth >0. Thus using a window function turned out to be mandatory.
  EDIT: I tried Hamming, Hanning and Blackman, and Hamming gave the best result. Eventually the main lobe must not be too wide, and side lobes must still be reasonably suppressed.
  An even better solution would be likely a polyphase filterbank. This would allow well-defined filter shapes, but the realization is more complex (-> IFFT + FFT + several FIR filters) than a single FFT.
  

Attached is a simulated eye digram of the demodulated NRZ bitsream. Looks acceptable for a first rudimentary draft.
The transmission channel was assumed to be error-free, I just added gaussian noise in the amount of 3% of the full-scale voltage.

[OldVolts]

Thanks all who contributed!
The winner: KISS

Arduino based generator(s) - multiple methods - most poorly documented tho.
Followed by a simple LPF to perform sine reconstruction and clean up grungies.
CMOS logic for input interface from radio equipment.

User end: Implementation of simple Arduino and 2x16 LCD display.
Nearly anyone can assemble and program on the kitchen table on the cheap
Again - KISS

Once again - Thanks All
Bill

[fourfathom]

So what happened to AX.25?

[gf]

I found a time slot to refine my simulation. Octave script is attached. Also attached are some plots generated by the script. Compared to the initial attempt I have reduced the sampling rate by from 43.2kHz to 10.8kHz (=2700*4), in order that the FFT size at the receiver can be reduced to 128 (to lower the computational complexity). Clearly this also reduced the noise immunity, which can be seen in the eye diagram. For comparison, an eye diagram for a noise-free channel is attached as well. Hard to estimate so far, how other channel deficiencies degrade the demodulation. Phase does not matter per se, since the demodulator output is the magnitude of the complex frequency bin, but group delay differences certainly do matter. 1ms might still be tolerable, but not significantly more.

[OldVolts]

AX.25 issues:
1 - not real time - "abuse" of protocol
2 - user end (receive) too complex; expensive.
Bill

[gnuarm]

So can you tell us what you decided to implement other than just saying "KISS" and "Arduino"?  What means of generating the tones, what frequencies, what means of detecting the tones? 

You never even told us what bit rate or symbol rate you are looking for?  Are the 16 channels all just continuous tones with async data on each one, rather like 16 separate Morse code keyers?  Is there some minimum response time to a change in the source of the data? 

I worked at a company once that designed push to talk military radios (never call them walkie talkies).  The old timers had very little sophistication and any time they wanted to say MCU they just said PIC.  I kept thinking they had a serious hard-on for Microchip for some reason.

[ogden]

I found a time slot to refine my simulation. Octave script is attached.

Could you show some more info about your solution for those who don't have Octave installed (yet)? I wonder you still use initial upconverter with FFT16 instead of let's say 16 (middle'ish) bins of FFT64 or even FFT32 w/o upconverter?

So can you tell us what you decided to implement other than just saying "KISS" and "Arduino"?

Right. BTW he said "LPF" and "CMOS" as well

[rfclown]

... I worked at a company once that designed push to talk military radios (never call them walkie talkies).  The old timers had very little sophistication and any time they wanted to say MCU they just said PIC.  I kept thinking they had a serious hard-on for Microchip for some reason.

walkie talkies were push to talk miliary radios, but they weren't hand held; those are handie talkies. HT is still the term used today for hand held PTT radios. We used to use the term "walkie talkies" when we were kids for the AM toy PTT radios, but that wasn't what the term originally meant. I worked for Moto on HTs.

I put an AVR in a product at work last year. Everyone refers to it as "the PIC". I've stopped correcting them; it's no use.

[gnuarm]

... I worked at a company once that designed push to talk military radios (never call them walkie talkies).  The old timers had very little sophistication and any time they wanted to say MCU they just said PIC.  I kept thinking they had a serious hard-on for Microchip for some reason.

walkie talkies were push to talk miliary radios, but they weren't hand held; those are handie talkies. HT is still the term used today for hand held PTT radios. We used to use the term "walkie talkies" when we were kids for the AM toy PTT radios, but that wasn't what the term originally meant. I worked for Moto on HTs.

I put an AVR in a product at work last year. Everyone refers to it as "the PIC". I've stopped correcting them; it's no use.

They still make back pack versions they call man pack which is more powerful with longer range as well as a vehicle mounted version with even more power, I forget the term for that, I think it was just a vehicle adapter with an amplifier.

[rfclown]

..
...Could you show some more info about your solution for those who don't have Octave installed (yet)? ...

I just installed Octave on my Windows 10 machine, and it was painless. Googeled "octave download", clicked link, installed, copied tone16.m.txt file, removed .txt from filename, typed "tone16" and gf's plots all popped up. I've never been a Matlab user, but this was just too easy to try. When I saw the "pkg load signal" at the begining of the file, I was afraid I'd have to learn about finding and loading packages, but it just worked.

[rfclown]

They still make back pack versions they call man pack which is more powerful with longer range as well as a vehicle mounted version with even more power, I forget the term for that, I think it was just a vehicle adapter with an amplifier.

I'm working on some man pack's now. You don't want to be the one who has to carry these things.

[gf]

Could you show some more info about your solution for those who don't have Octave installed (yet)?

It is not the solution, but a simulation of the potential outcome. The simulation assumes that the carriers are generated via (software) DDS and AM-modulated (regular double side-band modulation) with the 16 digital signals (after band-limiting them with a pulse shaping filter). Data streams are supposed to be async, with a (maximum) bit rate of 84.375 bits/s each. Carriers are 384.375, 553.125, 721.875, 890.625, 1059.375, 1228.125, 1396.875, 1565.625, 1734.375, 1903.125, 2071.875, 2240.625, 2409.375, 2578.125, 2746.875, 2915.625 Hz. Hopefully "KISS enough" The most computationaly expensive thing at the sender side is likely the pulse shaping filter.

Receiver side assumes sampling the audio signal at 10.8kSa/s sampling rate, a 384.375Hz quadrature LO (realized as software DDS as well), mixer (one complex multiplication per sample), and overlapping 128-point FFT (112 points overlap -> 8 FFT evaluations per symbol).

EDIT: Prior decimation could reduce the FFT size, but OTOH requires an additional decimation filter. I'm not sure if that were computationally cheaper, after all. And decimation were still limited to 2x, since the transition band of the decimation filter needs to be > 0, and the 2700Hz channel bandwidth is fully occupied by the 16 sub-bands.

Even w/o Octave installed you can still look at the code, of course

I wonder you still use initial upconverter with FFT16 instead of let's say 16 (middle'ish) bins of FFT64 or even FFT32 w/o upconverter?

I did not assume FFT on the sender side. OFDM requires the insertion of a guard interval between the symbols (mostly a cyclic prefix -> CP-OFDM), so I guess symbol timing recovery cannot be renounced at the receiver, and the receiver cannot work async? Or can it? The guard interval also reduces symbol rate (which can be compensated OTOH by modulating multiple bits onto one carrier). But likely no longer "KISS enough" for the OP then...

Also did take a brief look at gnuradio docs. Seems that a huge nuber of building blocks are readily avalable, which are suitable to compose various kinds of modems. So Raspberry PI + USB sound card + gnuradio might be an option, too?

[ogden]

Receiver side assumes sampling the audio signal at 10.8kSa/s sampling rate, a 384.375Hz quadrature LO (realized as software DDS as well), mixer (one complex multiplication per sample), and overlapping 128-point FFT (112 points overlap -> 8 FFT evaluations per symbol).

EDIT: Prior decimation could reduce the FFT size, but OTOH requires an additional decimation filter. I'm not sure if that were computationally cheaper, after all. And decimation were still limited to 2x, since the transition band of the decimation filter needs to be > 0, and the 2700Hz channel bandwidth is fully occupied by the 16 sub-bands.

Try 8KHz sample rate, iFFT64 and bins 4 till 20. Unused bins are set to 0, some may be used to transmit FCS btw. Decode accordingly - using 8KHz sample rate and FFT64.

OFDM requires the insertion of a guard interval between the symbols (mostly a cyclic prefix -> CP-OFDM), so I guess symbol timing recovery cannot be renounced at the receiver, and the receiver cannot work async? Or can it?

Cyclic prefix will not hurt - because then prolonged symbol do not need windowing for FFT at the receive end. Sync is needed as well - to avoid inter-symbol interference, thou for particular (OOK of subcarriers) application it can be as simple as brick: transmit some silence (>=1/4 of symbol time) between symbols. On receive end "listen" with AM envelope detector, save received baseband samples in the buffer. As soon as envelope detector finds signal which lasts as long as symbol - try FFT on buffer and consider it done. Well, maybe check FCS.

[gnuarm]

Could you show some more info about your solution for those who don't have Octave installed (yet)?

It is not the solution, but a simulation of the potential outcome. The simulation assumes that the carriers are generated via (software) DDS and AM-modulated (regular double side-band modulation) with the 16 digital signals (after band-limiting them with a pulse shaping filter). Data streams are supposed to be async, with a (maximum) bit rate of 84.375 bits/s each. Carriers are 384.375, 553.125, 721.875, 890.625, 1059.375, 1228.125, 1396.875, 1565.625, 1734.375, 1903.125, 2071.875, 2240.625, 2409.375, 2578.125, 2746.875, 2915.625 Hz. Hopefully "KISS enough" The most computationaly expensive thing at the sender side is likely the pulse shaping filter.

Where did you get the max bit rate?  I'm assuming it was from the frequencies you picked?

Receiver side assumes sampling the audio signal at 10.8kSa/s sampling rate, a 384.375Hz quadrature LO (realized as software DDS as well), mixer (one complex multiplication per sample), and overlapping 128-point FFT (112 points overlap -> 8 FFT evaluations per symbol).

I don't understand the need for the down conversion.  Your spectral results don't seem to be any different, just different frequencies.  Were your graphs not from the 128 point FFT, but rather higher resolution processing?

EDIT: Prior decimation could reduce the FFT size, but OTOH requires an additional decimation filter. I'm not sure if that were computationally cheaper, after all. And decimation were still limited to 2x, since the transition band of the decimation filter needs to be > 0, and the 2700Hz channel bandwidth is fully occupied by the 16 sub-bands.

[gf]

Where did you get the max bit rate?  I'm assuming it was from the frequencies you picked?

I have divided the 300-3000Hz voice channel evenly into 16 sub-channels, and the carriers are in the center of each sub-channel. Each sub-channel therefore has a total bandwidth of 168.75Hz and the upper and lower sideband of each sub-channel have a width of 84.375Hz. Since the 16 digital signals are AM-modulated onto their carriers, the bandwidth of each digital signal must not exceed 84.375Hz in order to avoid channel crosstalk. The spetrum of a digital NRZ signal has a main lobe with a width of 1HZ per bits/s. If only the main lobe is retained and the side lobes are eliminated by pulse shaping (low-pass filtering), then the 16 digital signals can have a bitrate of max. 84.375 bits/s each, w/o cross-talking into the neighbor channels. In the previously attached spectrum plot you can see the upper/lower sideband of each sub-channel.

I don't understand the need for the down conversion. Your spectral results don't seem to be any different, just different frequencies.  Were your graphs not from the 128 point FFT, but rather higher resolution processing?

Mixing with a sinusodial quadrature LO does exactly that -> shifting the frequency spectrum.
Reason for the down-coversion is that the carriers are not aligned with frequency bins of the 128 point FFT.
After down-conversion the carriers are exactly aligned with FFT bins (N*168.75Hz, where N is an integer).

The spectrum plots are high-resolution (16k points FFT) of ~1.5s data stream. They are not limited to a single symbol. They are supposed to show how the overall spectrum is utilized by the modulated signal. Limiting it to one symbol would only show a subset.

Note this is eventuall just AM+FDM, it is not OFDM.
Neither are the carriers orthogonal, nor does any symbol synchronization occur at the receiver.
EDIT: Not exactly true. While the actual carriers are not orthogonal, the down-converted carriers happen to be. Since the timedomain signal of the symbol was not generated by IFFT (circular convolution), and since there is also no symbol synchronization, the benefit of orthogonality alone is limited, and there is still a window function required for the FFT.
The FFT on the receiver side (in conjunction with the window function) is just "abused" as filter bank.

[gf]

Receiver side assumes sampling the audio signal at 10.8kSa/s sampling rate, a 384.375Hz quadrature LO (realized as software DDS as well), mixer (one complex multiplication per sample), and overlapping 128-point FFT (112 points overlap -> 8 FFT evaluations per symbol).

EDIT: Prior decimation could reduce the FFT size, but OTOH requires an additional decimation filter. I'm not sure if that were computationally cheaper, after all. And decimation were still limited to 2x, since the transition band of the decimation filter needs to be > 0, and the 2700Hz channel bandwidth is fully occupied by the 16 sub-bands.

Try 8KHz sample rate, iFFT64 and bins 4 till 20. Unused bins are set to 0, some may be used to transmit FCS btw. Decode accordingly - using 8KHz sample rate and FFT64.

OFDM requires the insertion of a guard interval between the symbols (mostly a cyclic prefix -> CP-OFDM), so I guess symbol timing recovery cannot be renounced at the receiver, and the receiver cannot work async? Or can it?

Cyclic prefix will not hurt - because prolonged symbol do not need windowing for FFT at the receive end. Sync is needed as well - to avoid inter-symbol interference, thou for particular (OOK of subcarriers) application it can be as simple as brick: transmit some silence (>=1/4 of symbol time) between symbols. On receive end "listen" with AM envelope detector, save received baseband samples in the buffer. As soon as envelope detector finds signal which lasts as long as symbol - try FFT on buffer and consider it done. Well, maybe check FCS.

I'm indeed tempted to try (simulate) that OFDM stuff, too. It seems to have a couple of nice properties

[ogden]

Note this is eventuall just AM+FDM, it is not OFDM.
Neither are the carriers orthogonal, nor does any symbol synchronization occur at the receiver.
EDIT: Not exactly true. While the actual carriers are not orthogonal, the down-converted carriers happen to be. W/o symbol synchronization, the benefit of orthogonality is limited, though.
The FFT on the receiver side (in conjunction with the window function) is just "abused" as filter bank.

It is OFDM indeed, just obfuscated with up/down-conversions I wonder about as well. OFDM does not actually define range of FFT bins to be used, nor modulation of subcarriers which can be any, even OOK/AM. iFFT64 @8KSPS can generate frequencies in range of 125 to 4000Hz for bins 1 to 32. We pick only those bins which fall into our band of interest, set others to 0 for iFFT and ignore in FFT receive end. In case of my example bin 4..20 will give 500Hz..2500Hz subchannels. Decoding is as simple as generation of symbol waveform - do FFT instead of iFFT making sure you point your FFT at symbol waveform (more or less).

I'm indeed tempted to try (simulate) that OFDM stuff, too. It seems to have a couple of nice properties

Would be nice to see what you make out of it.

[gf]

It is OFDM indeed, just obfuscated [...]

Isn't the "circular" property missing for the symbol's time domain samples, when they were not generated via IFFT, but as 16 independent AM streams, and without considering dedicated symbol borders?

Would be nice to see what you make out of it.

Sorry, not today

[ogden]

It is OFDM indeed, just obfuscated [...]

Isn't the "circular" property missing for the symbol's time domain samples, when they were not generated via IFFT, but as 16 independent AM streams, and without considering dedicated symbol borders?

Exact frequency of each subcarrier, not phase defines - "symbol" has circular property or not. OFDM symbol (output from iFFT) contains integer periods of each subcarrier sine. So if you generate correct subcarrrier waveforms using other than iFFT math, result shall be still valid. You did kinda prove it yourself Other argument - OFDM mostly uses nPSK modulations for subcarriers meaning their phase can vary, yet it does not impact circular properties of symbol, allows cyclic prefix.

[rfclown]

I assume though that for the OP's application he's sending "whatever" through an FM system. So if we want to use OFDM, it's not really OFDM on the RF carrier. Put regular OFDM through preemphasis and a fully compressed PA on the Tx, then a limiter and deemphasis on the Rx, and you have a mess. When I was thinking OFMD, I was just pondering the use of an IFFT to generate the tones and FFT to extract tones. OP didn't seem interested in the discussion anyway. What I got out of it was just having some thoughts... and downloading Octave.

[gf]

Exact frequency of each subcarrier, not phase defines - "symbol" has circular property or not. OFDM symbol (output from iFFT) contains integer periods of each subcarrier sine. So if you generate correct subcarrrier waveforms using other than iFFT math, result shall be still valid. You did kinda prove it yourself Other argument - OFDM mostly uses nPSK modulations for subcarriers meaning their phase can vary, yet it does not impact circular properties of symbol, allows cyclic prefix.

Generating the subcarrrier waveform for a symbol via IFFT implies that sub-carrier amplitude and phase is constant for the symbol duration. OTOH, the sine wave, AM-modulated with the low-pass-filtered NRZ signal, does not have a constant amplitude for the symbol duration. Still equivalent?

[ogden]

Generating the subcarrrier waveform for a symbol via IFFT implies that sub-carrier amplitude and phase is constant for the symbol duration. OTOH, the sine wave, AM-modulated with the low-pass-filtered NRZ signal, does not have a constant amplitude for the symbol duration. Still equivalent?

No. Unless precisely timed, amplitude change of subcarrier *during* OFDM symbol may break cyclic properties of it indeed.

[gf]

Would be nice to see what you make out of it.

Found a time slot to try, see attachent. Sorry, too late (in the night) now to describe details and findings. There are some comments in the code, though. There is still some debuging stuff left and commented-out. Pleas ignore.

EDIT:

I used the proposed baseband frequency plan (renouncing a mixer). This also gives some extra channels in the 500...3000 Hz range (which I used for e.g. sync and pilot tone). As subchannel modulation I used 2-PSK, i.e. using only real +1 and -1 constellations. My aim was to send plain bit streams, w/o dedicated frames, so I can't used use preamble for sync. Instead I used channel 16 (=> fs/4) to send a continuous sync pattern (alternating +1 and -1 constellation).

Since OFDM symbols are well-isolated in time domain, but the sub-channels have significant out of band leakage in the frequency domain, there is significant cross talk from the data channels to the sync channel. This (in conjunction with renouncing frames and preamble and the short symbol size) complicates detection of the symbol position in the time domain signal. Nevertheless correlating a long enough sequence of the sync pattern (20+ symbols) with the received data stream still did enable symbol position detection with a standard deviation of ~1.5 samples. That's close enough to do further phase synchronization via channel estimation.

For a poor man's channel estimation I used a 500 Hz pilot tone (so that a phase shift of +/-pi corresponds to an adjustment range of +/-8 samples, leaving some room to correct the  imperfectly detected initial symbol position). At the assumed noise level, the phase estimate from the pilot tone was still not robust enough, so I'm smoothing it over time. Consequence is that the first few symbols after initial synchronization still have a higher BER, which decays, however, when the smoothed time offset stabilizes. A simple single-pilot-tone EQ needs to rely on linear phase in the 500...3000 Hz band, which is certainly not granted in practice. So rather a larger number of pilot tones would be needed eventually, leading to even more complex EQ processing, doing some interpolation.

While it seems certainly feasible to implement all this stuff, I'd no longer consider it "KISS". So I think, for a low-effort and robust implementation I'd rather tend to go the gnuradio route, which already includes ready-to-use modules for all this stuff, and much more. Requires of course a processor/system where gnuradio is runnable (a Raspberry PI and an USB sound stick are not so expesive either, though). Nevertheless, evaluating various of aspects was an interesting experience.

[OldVolts]

These signals are audio.  There is no reason to use 16 different DDS generators.  A single  generator with 16 sets of registers (easily implemented in LUT memory) will run many times faster than required.  As others have pointed out this can easily be done in nearly any MCU you can think of.  It is the decoding that is a bit more difficult.  Some are suggesting an FFT is the way to go, but the devil is in the details and so far I have not seen any details from the OP.  In fact, this "project" may just be a prank.   He seems to be responding to serious questions with sarcasm. 

Yeah, it seems like it's time to ignore this thread.  Am I wrong?

Sorry but not a prank.  Really looking to generate 16 different audio tones simultaneously with the ability to control each individual tone.
My biggest issue was the number of I/O pins on any conventional MCU but I now believe any of the Propeller chips will solve that problem; 2 chips - 8 cores each - 16 tones.
If / When I get something making reasonable output I'll post.
Thanks All

[OldVolts]

Warning - LONG
To address the noise about need for more information:
I am responsible for the maintenance and improvement of a local amateur radio group's repeater systems.  One of those systems has 7 remote receivers distributed about the county and tied back to the "control" site by UHF radio links.  There is also "local" receiver bringing the total to 8 receivers.
The COR and audio output of each receiver is fed to a voter (LDG-RVS-8) then to a controller (SCOM 7k) and then to the transmitter (CDM750) and finally to the amplifier (Henry 500 BA).
The control site is a 30 minute drive and in a location having TIGHTLY controlled access.  Pure PITA!  By the time I get there the problem has usually gone "poof".
So . . .  To ease my troubleshooting pain I decided to undertake a means to remotely observe various diagnostic indicators, which initially lead to an attempt to use a packet-based protocol (AX.25) to transmit the diagnostic stuff.
Issue 1 - Data occurs in real time - packet is NOT.  A mobile can vote between 3 or 4 receivers in ONE second -NO packet system is that fast.
2 - Besides being data "shy" it is delayed so what I'm seeing is historical - not what I'm currently hearing.
3 - Uneconomical - requires a second radio dedicated to a TNC and some sort of display - $$
I want to watch 8 radio activity (COR) indications simultaneously - 8 "bits" and the voter's voted selection (one of 0 to .  I can encode the voted as 8 into 4 - requiring only 4 tones leaving tones 13, 14, 15 and 16 for environmental and other alarm indications.
The decoder is a slight modification to https://create.arduino.cc/projecthub/shajeeb/32-band-audio-spectrum-visualizer-analyzer-902f51
The tones I have chosen are non harmonically related through 5th order and are based on prime numbers so the FFT decoder should have an easy time keeping the tone display "clean".
So - to sum:  Looking at using 2 Propeller chips.  8 Cores each, 80 MHz clock, simple programming and SCADS of I/O pins.
As before - If I get it to work to my satisfaction I'll share what I can.
Thanks for those of you who were actually willing to help,
Bill

[gnuarm]

I thought you said it was going to be an Arduino???  KISS, no?

If you need to use two propeller chips,  you must need a data rate of around a Mbps.  That makes no sense because the tones are just AUDIO rates.  If you need much lower data rates you can generate the audio tones with pretty much any MCU, even a simple 8 bit Arduino processor. 

There may be 16 tones, but each tone generator only takes a few instructions.  So the tones can all be generated by the same code running sequentially on the same processor.  A DDS requires one word in memory for the phase increment which corresponds to the frequency and one word in memory for the phase accumulator.  In each case pick your data width to suit your frequency resolution and sample rate.  So that would be 32 words for 16 DDS. 

Assume a sample rate of 8 ksps that gives 128 k DDS updates per second or 156 clock cycles per DDS update with a 20 MHz processor.  That should be a piece of cake.  Use 16 bit data samples and you can achieve approximately 90 dB of SNR and similar harmonic distortion with any of many available 16+ bit stereo CODECs for $3.  All 16 DDS outputs can be summed into a single output for the CODEC. 

I literally can't think how it will be easier in any way to spread the tasks across 16 threads having then to coordinate them with a 17th process.  I suppose you could create each thread to sum data input from say the "LEFT" and pass data out to the "RIGHT" with the right of the last processor being the CODEC perhaps.  Otherwise the threads will have to be different.  Yeah, it's kinda goofy to try to take a single process and turn it into 16 threads.

[oPossum]

The tones I have chosen are non harmonically related through 5th order and are based on prime numbers so the FFT decoder should have an easy time keeping the tone display "clean".

You've got that backwards. An FFT can only give a 'clean' output for tones that are periodic within the sample set. Everything else will spill in to other bins.

[hamster_nz]

Depending on how crufty you want to go...

If I was doing this with parts on hand, it would be an ESP32 with an I2S DAC for encoding, and an ESP32 with an I2S ADC on the decoding.

I would also think of adding a pilot tone, so the receiver can 'anchor' onto something.

[MIS42N]

Talk about a steamroller to crack a nut. The OP distinctly stated in post #1 "Can use a (reasonable) number of processors (16 is NOT reasonable)" then proposes to use two propeller chips containing (....dada....) 16 processors.
If the 'explanation' of the problem by the OP is described as LONG, but answers few of the questions, I'd like to see the REALLY LONG description. I cannot see why this can't be dealt with as a parallel to serial conversion, simple transmission, serial to parallel at the other end. These are decades old techniques with simple, cheap and well proven technology.
It will be interesting to see the final solution.

[voltsandjolts]

I would also think of adding a pilot tone, so the receiver can 'anchor' onto something.

Pilots are definetly required for calculation (compensation) of symbol phase and amplitudes.
The more the transmission medium properties vary over the frequency range of interest, the more pilots that are required.

Symbol alignment is crucial but a neat trick is to copy, say, last 2% of time domain signal (for a symbol) to the beginning of the symbol. Similarly, 2% of the beginning copied to the end.
Thanks to the circular nature of FFT, symbol alignment can then be out by 2% and still get the same result.

[fourfathom]

The tones I have chosen are non harmonically related through 5th order and are based on prime numbers so the FFT decoder should have an easy time keeping the tone display "clean".

You've got that backwards. An FFT can only give a 'clean' output for tones that are periodic within the sample set. Everything else will spill in to other bins.

I think he's got that much right.  Say you have a FFT with a bin width of 50 Hz.  Use prime-related tones of 50 x {2, 3, 5 ... 53} (first 16 primes).  This gives you tones of 100Hz, 150Hz, 250Hz ... 265 Hz.  You can scale the bins and multipliers to better fit the VHF audio channel characteristics, but this will avoid false detection of distortion products.  I haven't looked at any windowing requirements, so perhaps the spectral leakage will be an issue.

[rfclown]

... I cannot see why this can't be dealt with as a parallel to serial conversion, simple transmission, serial to parallel at the other end. These are decades old techniques with simple, cheap and well proven technology....

I completely agree. I was baffled as I read the LONG description. What would make someone devise the proposed multitone solution to the problem?

> A mobile can vote between 3 or 4 receivers in ONE second -NO packet system is that fast.

So the data needs to be sent at least at a 1 Hz rate. 16 bits every 1 second.

[gnuarm]

... I cannot see why this can't be dealt with as a parallel to serial conversion, simple transmission, serial to parallel at the other end. These are decades old techniques with simple, cheap and well proven technology....

I completely agree. I was baffled as I read the LONG description. What would make someone devise the proposed multitone solution to the problem?

> A mobile can vote between 3 or 4 receivers in ONE second -NO packet system is that fast.

So the data needs to be sent at least at a 1 Hz rate. 16 bits every 1 second.

The OP is not thinking about the problem from a perspective of understanding the actual comms technology.  He is thinking in very simplistic terms that don't properly analyze the problem.  He hasn't really explained his thinking much at all, focusing on the higher level problem instead.  The mapping of requirements to the lower level problem of the actual transmission format was therefore faulty. 

One crucial requirement I don't think I've seen is the time between an event and the time it is recognized at the other end.  That is what seems to dominate his thinking as if it needs to be as close to zero as possible rather than defining a number then working with that. 

Meanwhile people are proposing many solutions which result in different values for this delay so that potentially NONE of them may actually meet this requirement.  Is this my mistake and he does have a delay time in mind? 

I don't know the bit rate that can be sent over the channel, but a packet system doesn't limit the data rate.  I assume he is referring to preexisting packet systems.  If he is going to roll his own tone based system there is no reason why he can't roll his own "packet" system which is another name for aggregating bits and sending them serially with a simple modulation scheme. 

I think we put together something like that in a sophomore level lab class in school.  It is hard to find a more simple idea.  Yeah, a "packet' of three bytes.  One is a counter, (0, 1, ... 255, 0...) for sync and the other two are the data.  A really simple MCU can handle that at both ends with a very short end to end delay (shorter than an FFT most likely) and so much more simple to implement. 

Another nice feature of the "packet" approach is the size of the "packet" is very easy to change for different applications.  Add another byte and the delay time goes up by 33%.  In the tone approach the resolution of the FFT pushes up the length of the FFT according to N but the processing time by N*log(N)

[fourfathom]

Using the simplest 300-baud 2FSK modulation (300 bits/second, 12 bits gives you RS232-UART-style "start/8-data/parity/stop/stop") you could have a simple message format: [Sync, Data1, Data2, Checksum].  That's 48 bits, 6.25 times per second, carrying sixteen user-databits.  Extremely simple and dirt-cheap.  No reason not to add a few more user-data bytes per message.  300 baud 2FSK is easily carried over any reasonable VHF channel.

[oPossum]

All of the bins will be harmonics (integer multiples) of the bin spacing. That is the harmonic relationship I am referring to. I am assuming the frequencies have been chosen without regard to this harmonic relationship and are thus non-periodic within the FFT sample set. They will spill over into other bins, the FFT will not be 'clean'.

The tones I have chosen are non harmonically related through 5th order and are based on prime numbers so the FFT decoder should have an easy time keeping the tone display "clean".

You've got that backwards. An FFT can only give a 'clean' output for tones that are periodic within the sample set. Everything else will spill in to other bins.

I think he's got that much right.  Say you have a FFT with a bin width of 50 Hz.  Use prime-related tones of 50 x {2, 3, 5 ... 53} (first 16 primes).  This gives you tones of 100Hz, 150Hz, 250Hz ... 265 Hz.  You can scale the bins and multipliers to better fit the VHF audio channel characteristics, but this will avoid false detection of distortion products.  I haven't looked at any windowing requirements, so perhaps the spectral leakage will be an issue.

[OldVolts]

I thought you said it was going to be an Arduino???  KISS, no?

Not enough I/O pins on simple Arduinos.
Turns out Propeller is cheap and, with 8 cores and 32 I/O pins I'll be spoiled for choices.
Write simple code - once.  Load from Hub to each core.  Hit "Go".
Very KISS.

Bill

[MIS42N]

One crucial requirement I don't think I've seen is the time between an event and the time it is recognized at the other end.  That is what seems to dominate his thinking as if it needs to be as close to zero as possible rather than defining a number then working with that. 

I did ask about that, but no reply. The implication is a person could see events in real time. A person takes quite a few milliseconds to notice an event and many more to react. A good 'below human perception' delay is 20ms, the frame rate of some television. And if it is a person reacting, a certain level of error tolerance is built in - 1 bit in a 100 would be noticed by a person but quickly ignored. Using straight async characters with start bit, stop bit = 8 data bits and 2 overhead. 16 bits of data takes 20 bits, which at 1200 baud takes less than 20ms. 1200 baud is slow by amateur radio standards.

My preferred solution (given the meager specification) would be to capture and time stamp events, and have some way of recording everything. That way, events can be analyzed at leisure. Also, it doesn't need someone sitting looking at it. At one time I was responsible for 75 computers around the world. Each one generated a couple of hundred events a day. These were compressed (zip) and sent daily to a computer on our site. Then a scheduled job filtered and summarised, so I had a report at 8:00 a.m. when I arrived at work, which may have a dozen items for action. Usually a simple fix, but sometimes a trawl through the raw data to get a picture (The events were recorded in local time, but before zipping they were adjusted to UTC. Why certain operating systems don't run on UTC is an annoyance. One mainframe was turned off for an hour at start of daylight savings, couldn't handle records time stamped in the future. Some of our problems were on networks crossing time zones so UTC made correlation easier).

my 2¢.

[OldVolts]

I completely agree. I was baffled as I read the LONG description. What would make someone devise the proposed multitone solution to the problem?
> A mobile can vote between 3 or 4 receivers in ONE second -NO packet system is that fast.
So the data needs to be sent at least at a 1 Hz rate. 16 bits every 1 second.

Try 10 "updates" per second - 10 Baud per "carrier".
Bill

[OldVolts]

One crucial requirement I don't think I've seen is the time between an event and the time it is recognized at the other end.  That is what seems to dominate his thinking as if it needs to be as close to zero as possible rather than defining a number then working with that. 

I did ask about that, but no reply. The implication is a person could see events in real time. A person takes quite a few milliseconds to notice an event and many more to react. A good 'below human perception' delay is 20ms, the frame rate of some television. And if it is a person reacting, a certain level of error tolerance is built in - 1 bit in a 100 would be noticed by a person but quickly ignored. Using straight async characters with start bit, stop bit = 8 data bits and 2 overhead. 16 bits of data takes 20 bits, which at 1200 baud takes less than 20ms. 1200 baud is slow by amateur radio standards.

My preferred solution (given the meager specification) would be to capture and time stamp events, and have some way of recording everything. That way, events can be analyzed at leisure. Also, it doesn't need someone sitting looking at it. At one time I was responsible for 75 computers around the world. Each one generated a couple of hundred events a day. These were compressed (zip) and sent daily to a computer on our site. Then a scheduled job filtered and summarised, so I had a report at 8:00 a.m. when I arrived at work, which may have a dozen items for action. Usually a simple fix, but sometimes a trawl through the raw data to get a picture (The events were recorded in local time, but before zipping they were adjusted to UTC. Why certain operating systems don't run on UTC is an annoyance. One mainframe was turned off for an hour at start of daylight savings, couldn't handle records time stamped in the future. Some of our problems were on networks crossing time zones so UTC made correlation easier).

my 2¢.

Worth several times that amount.
Scenario:
I am listening to a mobile (in motion) and as the signal switches between remote receivers (due to the transmitting station being in-motion) I notice that the system is voting a receiver with (lets say) 60 Hz hum - a failing power supply.  Which remote is it?
The remote monitor enables me to correlate, in real time, the activities of the system (what I hear) with the current actions of the voting system (which receivers receiving and receiver voted and repeated).  Historical - even by seconds - simply doesn't cut it.
Closest analogy: out of sync lips / voice in "What's Up Tiger Lilly".
Bill

 mobile

[fourfathom]

Historical - even by seconds - simply doesn't cut it.

As has been mentioned, human response being what it is you would prefer that the delay between event and display to be no greater than 30 ms.  My suggestion to use 300 bps 2FSK gave you a response time of perhaps 200 ms (which I suspect would be perfectly usable for your needs.)  On a good ham VHF link you can pretty easily bump that datarate from 300 up to 1200, giving you a 50ms transmission time.  You can speed this further by simplifying my four word "packet", perhaps by eliminating the final checksum byte and instead relying on the parity bits for error checking.

I claim that this will be perfectly usable and vastly simpler than your DMT implementation.  There are many other simple methods that would work.

As has also been mentioned, there is no free lunch when it comes to bits per second throughput over a noisy, band-limited channel.  Overcomplicating the modulation method doesn't buy you anything.  The reason for many of the fancier schemes is to allow graceful optimization of the datarate in the presence of variations in channel capacity caused by noise and interference.  I don't see this capability being useful in your situation (and you certainly haven't implemented such.)

[hamster_nz]

I'm sure I posted this last night, but it has disappeared... sorry if this is a double-up

Anyhow... here's some code to generate upto 16 concurrent tones (can be easily implemented in all integer) - 580Hz -> 1940Hz at 8000 S/s, along with some (pretty average) code to decode it. As written it send random 16-bit values, The value transmitted could change 20 times per second, but for easy decoding you don't want to change it that much unless you put some effort in detect and align to the transition.

Decoding could also be implemented in fixed point if effort is put in to analyze it, or implement in fixed point servicing the ADC data, and floating point for display results.

Signal is generated in +/- 32768, but still works fine with samples reduced to +/-7, so ADC bit depth will not be a big deal. I guess if you used it over a SSB channel you need to be tuned within +/-10 Hz for it to work.

With no noise added

Code: [Select]

$ ./encode | ./decode | more
Hard limited     % of max
1110011010100010 100 100 100   0   0 100 100   0 100   0 100   0   0   0 100   0
1110011010100010 100 100 100   0   0 100 100   0 100   0 100   0   0   0 100   0
1110011010100010 100 100 100   0   0 100 100   0 100   0 100   0   0   0 100   0
1110011010100010 100 100 100   0   0 100 100   0 100   0 100   0   0   0 100   0
1110011010100010 100 100 100   0   0 100 100   0 100   0 100   0   0   0 100   0
0110001111000100   0 100 100   0   0   0 100 100 100 100   0   0   0 100   0   0
0110001111000100   0 100 100   0   0   0 100 100 100 100   0   0   0 100   0   0
0110001111000100   0 100 100   0   0   0 100 100 100 100   0   0   0 100   0   0
0110001111000100   0 100 100   0   0   0 100 100 100 100   0   0   0 100   0   0
0110001111000100   0 100 100   0   0   0 100 100 100 100   0   0   0 100   0   0
...
With 50% random noise added

Code: [Select]

$ ./encode | ./decode | more
Hard limited     % of max
1110011010100010  91  90  95   6  11  95  92   6 100  11  90  11  11  16  88  11
1110011010100010 100 100  94   5   9  96  75  14  89   4  98   6  19  17  99  16
1110011010100010  88 100  82   8   6  95  69   2  90   5  87   9   2  18  91  11
1110011010100010  90  83  89  13  15 100  78   3  87  18  80   4   7  11  66   4
1110011010100010 100  77  81   7   3  92  85   5  60  11  85  12   6  11  73  10
1111000111101110  98  86  87  89   9  18  26  77  83  99  85   7  97 100  91   4
1111000111101110  93  87  86  84  18  18  12  86  76  89  77   9 100  74  88  14
1111000111101110  95  95  88  90   3  13  20  87  93  97  94  22 100  76  89  10
1111000111101110  80  78  83  75   4  10  10  75  56 100  84   9  86  87  87   7
1111000111101110  96  83  73  98   4  12  11  88 100  90  96  11  90  84  79  12
0000001101101100   4  15   7   3   9   1 100  92   9  90  96   5  96  93  11   7
0000001101101100   5   9   9   4   6   7  98 100  11  99  88  10  93  99  10   6
0000001101101100   5   6   5   7   6   5  86 100   5  75  80   3  83  97  13   9
0000001101101100   9   9   2  15   5   9  99  95   6  88 100  11  95  95   2   2
0000001101101100  12   2   7   9  14   3  89 100   8  95  97   9  98  93   8   8
1010010001001110  83   3  87   9   9  75  11   7   4  85   4   6  91  78 100  11
1010010001001110  89   6  94   4  10 100  14  10   4  87  10   6  85  89  97   5
1010010001001110  93   4 100  19   9  89   8  14   5  89   5   8 100  91  94   4
1010010001001110  87   6 100  15  13  98   2   8  13  93   4  10  94  93  99   7
1010010001001110  85  12  87   5   4 100  14   5   3  91   3  13  92  93  88   3
1000011100111100  90  10   6  11  23  84 100  96   4   8  89  87  98  95  11   5
1000011100111100  88   8  10   8  16  91  89  89   6   8  95  93  94 100  12   7
1000011100111100  82  12   7   4   5 100  79  86  13   7  91  91  97  78  16   4
1000011100111100  86   6  13   7   6  81  87  81  10   4  90  83 100  96   9  13
1000011100111100  75   5  14  10  14  81  81 100   9  21  72  86  90  89  17   4
0110011100110111   9  78 100  16  22  81  81  89  18   7  84  94  10  78  85  91
0110011100110111   3 100  92  16   9  90  99  94  12   9  92  84  24  83  61  87
0110011100110111  12  89  99  15  13 100  84  86  19  13  91  87  11 100  99  95
0110011100110111  15  87  97  15  18  88  79  91   2  15  67 100  24  97  82  86
0110011100110111   5  88  76   7   6 100  85  78   9   9  82  90  15  78  89  77
1111000110011101  97  80 100  86   5  16  20  82  78  18  13  92  99  82   5  90
1111000110011101  87 100  71  98  15   5  11  98  87   6   7  89  88  93   4 100
1111000110011101  74  65  90  84   9  13  16  86  81  10   9 100  90  77  19  67
...


[gf]

Seems there was a forum outage, and some messages were lost.

[rfclown]

I completely agree. I was baffled as I read the LONG description. What would make someone devise the proposed multitone solution to the problem?
> A mobile can vote between 3 or 4 receivers in ONE second -NO packet system is that fast.
So the data needs to be sent at least at a 1 Hz rate. 16 bits every 1 second.

Try 10 "updates" per second - 10 Baud per "carrier".
Bill

ok, so 10x that. How would I transmit 160 bits/sec? Simplest things I can think of are OOK and FSK. As mentioned before, all that is needed here is a parallel to serial converter. What I have lying around are Arduino Pro Minis, just the ticket.  17 completely undedicated digital I/Os (PORTB 0-4, PORTC 0-5, PORTD 2-7). If you need more you can use the RESET line, XTAL (PORTB 6-7 and use internal 8MHZ RC) PORTB 5 (LED) and TX/RX (PORTD 0-1), but I'm going to use the Tx/Rx. I won't even have to touch the Arduinos. All I need is one resistor.

Coded u_tx.c just to generate numbers and throw them out the UART at 600 baud. Yes, for 16 bit packets I'd have some frame byte and two data bytes, but I'm just showing the concept. Hooked the ATmega Tx UART output through a resitor to the FM modulation port of my signal generator set for 500 MHz, 5 kHz peak deviation.

For the receiver, I hauled out my modulation analyzer. Set for FM demod, 75usec de-emphasis, 3kHz lowpass. Fed the modulation output directly into the Rx UART pin of another Arduino Pro Mini running u_rx.c. All the code does is take the UART Rx input, and send it out the UART Tx so I can see it on my PC.

Picture shows setup. Both ATmegas are on a single small solderless breadboad sitting on my laptop keyboard. Square wave FSK input of sig gen is shown on scope as well as Modulation Analyzer demod output. PC is running a terminal program that shows sequential numbers being received.

For the simple code, I use Arduino hardware and the gcc and avrdude that gets installed with the Arduino install, but I ditch the Arduino UI and use the avr libraries. I call gcc and avrdude from the command line.

[MIS42N]

ok, so 10x that. How would I transmit 160 bits/sec? Simplest things I can think of are OOK and FSK. As mentioned before, all that is needed here is a parallel to serial converter. What I have lying around are Arduino Pro Minis, just the ticket.  17 completely undedicated digital I/Os (PORTB 0-4, PORTC 0-5, PORTD 2-7). If you need more you can use the RESET line, XTAL (PORTB 6-7 and use internal 8MHZ RC) PORTB 5 (LED) and TX/RX (PORTD 0-1), but I'm going to use the Tx/Rx. I won't even have to touch the Arduinos. All I need is one resistor.

Coded u_tx.c just to generate numbers and throw them out the UART at 600 baud. Yes, for 16 bit packets I'd have some frame byte and two data bytes, but I'm just showing the concept. Hooked the ATmega Tx UART output through a resitor to the FM modulation port of my signal generator set for 500 MHz, 5 kHz peak deviation.

For the receiver, I hauled out my modulation analyzer. Set for FM demod, 75usec de-emphasis, 3kHz lowpass. Fed the modulation output directly into the Rx UART pin of another Arduino Pro Mini running u_rx.c. All the code does is take the UART Rx input, and send it out the UART Tx so I can see it on my PC.

Picture shows setup. Both ATmegas are on a single small solderless breadboad sitting on my laptop keyboard. Square wave FSK input of sig gen is shown on scope as well as Modulation Analyzer demod output. PC is running a terminal program that shows sequential numbers being received.

For the simple code, I use Arduino hardware and the gcc and avrdude that gets installed with the Arduino install, but I ditch the Arduino UI and use the avr libraries. I call gcc and avrdude from the command line.

I had a closer look at what OP is on about. I gather all the information needed is going into or coming out of the RVS-8. There are 16 signals to deal with, 8 incoming signals and 8 output signals. The voted repeater output is one bit on one of 8 outputs and as OP pointed out, this could be coded as 4 bits, 1 to say if any line is selected and 3 for which of the 8.

I was thinking along the Pro Mini line myself. I don't write C, just assembler. As the output was to be audio tones rather than FM I was going to generate PWM output applied to a low pass filter to generate one of two tones. See similar idea here https://chapmanworld.com/2015/04/07/arduino-uno-and-fast-pwm-for-afsk1200/. I hadn't looked too hard at the receiver end but I think the Pro is fast enough to decode the audio applied to an analog input pin.

We don't know the link over which the data is moved. Maybe the FM scheme will work if the transmitter/receiver handle it. If the restriction is audio in/audio out I'm pretty sure the Pro Mini could do it, but it may take more than 1 resistor.

[rfclown]

ok, so 10x that. How would I transmit 160 bits/sec? Simplest things I can think of are OOK and FSK. As mentioned before, all that is needed here is a parallel to serial converter. What I have lying around are Arduino Pro Minis, just the ticket.  17 completely undedicated digital I/Os (PORTB 0-4, PORTC 0-5, PORTD 2-7). If you need more you can use the RESET line, XTAL (PORTB 6-7 and use internal 8MHZ RC) PORTB 5 (LED) and TX/RX (PORTD 0-1), but I'm going to use the Tx/Rx. I won't even have to touch the Arduinos. All I need is one resistor.

Coded u_tx.c just to generate numbers and throw them out the UART at 600 baud. Yes, for 16 bit packets I'd have some frame byte and two data bytes, but I'm just showing the concept. Hooked the ATmega Tx UART output through a resitor to the FM modulation port of my signal generator set for 500 MHz, 5 kHz peak deviation.

For the receiver, I hauled out my modulation analyzer. Set for FM demod, 75usec de-emphasis, 3kHz lowpass. Fed the modulation output directly into the Rx UART pin of another Arduino Pro Mini running u_rx.c. All the code does is take the UART Rx input, and send it out the UART Tx so I can see it on my PC.

Picture shows setup. Both ATmegas are on a single small solderless breadboad sitting on my laptop keyboard. Square wave FSK input of sig gen is shown on scope as well as Modulation Analyzer demod output. PC is running a terminal program that shows sequential numbers being received.

For the simple code, I use Arduino hardware and the gcc and avrdude that gets installed with the Arduino install, but I ditch the Arduino UI and use the avr libraries. I call gcc and avrdude from the command line.

I had a closer look at what OP is on about. I gather all the information needed is going into or coming out of the RVS-8. There are 16 signals to deal with, 8 incoming signals and 8 output signals. The voted repeater output is one bit on one of 8 outputs and as OP pointed out, this could be coded as 4 bits, 1 to say if any line is selected and 3 for which of the 8.

I was thinking along the Pro Mini line myself. I don't write C, just assembler. As the output was to be audio tones rather than FM I was going to generate PWM output applied to a low pass filter to generate one of two tones. See similar idea here https://chapmanworld.com/2015/04/07/arduino-uno-and-fast-pwm-for-afsk1200/. I hadn't looked too hard at the receiver end but I think the Pro is fast enough to decode the audio applied to an analog input pin.

We don't know the link over which the data is moved. Maybe the FM scheme will work if the transmitter/receiver handle it. If the restriction is audio in/audio out I'm pretty sure the Pro Mini could do it, but it may take more than 1 resistor.

For number of IOs and bits actually needed for the problem, I'm afraid the OP will discard suggestions on something other than what he has already determined. He said, "Not enough I/O pins on simple Arduinos.", but I count enough on an ATmega32 (Uno, Nano, ProMini, all simple Arduinos) which I enumerated.

My first thought when I decided to throw something together was also to PWM two different tones. But before I started doing that I looked at my RF signal generator which has a DC coupled FM port and realized all I needed was two DC levels. No reason to do anything else.

 >We don't know the link over which the data is moved.
This is a major factor in the question that we don't know. The original question should have been stated as "I want to transfer data at X bits/sec over a Y radio link." I assume it is an FM link, so I showed how 160bps could be sent with simple FM.

I just realized my mistake with the OP

...Please note: I’m NOT looking for other ways to do this – 16 tones at a time is where we’re going....

He clearly stated that he isn't open for suggestions against his 16 tone solution.

[fourfathom]

We don't know the link over which the data is moved. Maybe the FM scheme will work if the transmitter/receiver handle it. If the restriction is audio in/audio out I'm pretty sure the Pro Mini could do it, but it may take more than 1 resistor.

I've been assuming (perhaps incorrectly) that the modulation would be audio tones.  This audio signal will be connected to the transmitter audio input (microphone or AUX port), and these audio tones modulate the FM carrier.  For demodulation, the demodulated audio output of the receiver will be these audio tones which will be sent to an audio demodulator (FSK, DMT, or whatever is used).  This has been how most ham radio digital transmission is done, at least when using external modems.

With this method, any pre-emphasis or de-emphasis is done inside the transceiver, although there may be some response-shaping done in the modem.

[fourfathom]

I just realized my mistake with the OP

...Please note: I’m NOT looking for other ways to do this – 16 tones at a time is where we’re going....

He clearly stated that he isn't open for suggestions against his 16 tone solution.

Apparently the only acceptable response was supposed to be "Wow!  What an amazingly great scheme!"

[gnuarm]

I just realized my mistake with the OP

...Please note: I’m NOT looking for other ways to do this – 16 tones at a time is where we’re going....

He clearly stated that he isn't open for suggestions against his 16 tone solution.

Apparently the only acceptable response was supposed to be "Wow!  What an amazingly great scheme!"

I'm sure he will get something to work.  It will either meet some requirement he has not actually shared with us in a clear manner, or it will be a lot more work than a simpler solution. 

I don't recall how he said he was going to demodulate the tones.  Would each propeller CPU be used as a tone detector? 

Actually, he might not need a demodulator on the receiving end.  Aren't spectral displays common on receiver outputs?  Or maybe they are only on the RF rather than the audio output.

[oPossum]

I don't recall how he said he was going to demodulate the tones.  Would each propeller CPU be used as a tone detector? 

Decoding is simple: Google for "Arduino audio analyzer" - plenty of examples.

Propeller was for tone generation. Two of them.

It can be done with an ATMega328. Here is some code that uses DDS for 16 tones. IFFT could also be used.

Code: [Select]


#include <xc.h>

static int8_t const st[1 << 8] = {
    0,    3,    6,    9,   12,   15,   18,   21,   24,   27,   30,   33,   36,   39,   42,   45,
   48,   51,   54,   57,   59,   62,   65,   67,   70,   73,   75,   78,   80,   82,   85,   87,
   89,   91,   94,   96,   98,  100,  102,  103,  105,  107,  108,  110,  112,  113,  114,  116,
  117,  118,  119,  120,  121,  122,  123,  123,  124,  125,  125,  126,  126,  126,  126,  126,
  127,  126,  126,  126,  126,  126,  125,  125,  124,  123,  123,  122,  121,  120,  119,  118,
  117,  116,  114,  113,  112,  110,  108,  107,  105,  103,  102,  100,   98,   96,   94,   91,
   89,   87,   85,   82,   80,   78,   75,   73,   70,   67,   65,   62,   59,   57,   54,   51,
   48,   45,   42,   39,   36,   33,   30,   27,   24,   21,   18,   15,   12,    9,    6,    3,
    0,   -3,   -6,   -9,  -12,  -15,  -18,  -21,  -24,  -27,  -30,  -33,  -36,  -39,  -42,  -45,
  -48,  -51,  -54,  -57,  -59,  -62,  -65,  -67,  -70,  -73,  -75,  -78,  -80,  -82,  -85,  -87,
  -89,  -91,  -94,  -96,  -98, -100, -102, -103, -105, -107, -108, -110, -112, -113, -114, -116,
 -117, -118, -119, -120, -121, -122, -123, -123, -124, -125, -125, -126, -126, -126, -126, -126,
 -127, -126, -126, -126, -126, -126, -125, -125, -124, -123, -123, -122, -121, -120, -119, -118,
 -117, -116, -114, -113, -112, -110, -108, -107, -105, -103, -102, -100,  -98,  -96,  -94,  -91,
  -89,  -87,  -85,  -82,  -80,  -78,  -75,  -73,  -70,  -67,  -65,  -62,  -59,  -57,  -54,  -51,
  -48,  -45,  -42,  -39,  -36,  -33,  -30,  -27,  -24,  -21,  -18,  -15,  -12,   -9,   -6,   -3   
};

static uint8_t const pi[16] = { 2, 3, 5, 7, 8, 11, 12, 13, 17, 19, 20, 23, 25, 27, 28, 29 };

static volatile uint8_t samples[1 << 8];
static volatile uint8_t update;
static volatile uint8_t timer;

static void generate(uint16_t const tones)
{
    uint8_t n = 0;
    uint8_t pa[16] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };

    while(update);
   
    do {
        int16_t i = 0;
        for(uint8_t t = 0; t < 16; ++t) {
            if(tones & (1 << t)) i += st[pa[t]];
            pa[t] += pi[t];
        }
        samples[n] = (2048 + i) >> 4;
   } while(++n);
 
    update = 1;
}

void __attribute__ ((signal, used, externally_visible)) TIMER1_CAPT_vect(void)
{
    static uint8_t n;
    static uint8_t new;
    static uint8_t out[1 << 8];

    if(new) out[n] = samples[n];
    OCR1A = 100 + out[n];
   
    if(!n++) {
        --timer;
        if(new) {
            new = 0;
            update = 0;
        } else {
            new = update;
        }
    }
}

int main(void)
{
    PORTB = PORTC = PORTD = 0;
    DDRB = DDRC = DDRD = 0xFF;
    TCCR1A = 0xA2;
    TCCR1B = 0x19;
    TCCR1C = 0x00;
    ICR1 = 13 * 32 - 1;
    OCR1A = OCR1B = 100 + 128;
    TIFR1 = 0;
    TIMSK1 = 0x20;
    __asm__ __volatile__ ("sei" ::: "memory");
   
    generate(~0);
    timer = 255; while(timer);
   
    uint16_t lfsr = 1;
    for(;;) {
        timer = 7; while(timer);
        lfsr ^= lfsr >> 7; lfsr ^= lfsr << 9; lfsr ^= lfsr >> 13;
        generate(lfsr);
    }
   
    return 0;
}


[hamster_nz]

I don't recall how he said he was going to demodulate the tones.  Would each propeller CPU be used as a tone detector? 

Decoding is simple: Google for "Arduino audio analyzer" - plenty of examples.

Propeller was for tone generation. Two of them.

It can be done with an ATMega328. Here is some code that uses DDS for 16 tones. IFFT could also be used.

Code: [Select]


#include <xc.h>

static int8_t const st[1 << 8] = {
    0,    3,    6,    9,   12,   15,   18,   21,   24,   27,   30,   33,   36,   39,   42,   45,
   48,   51,   54,   57,   59,   62,   65,   67,   70,   73,   75,   78,   80,   82,   85,   87,
   89,   91,   94,   96,   98,  100,  102,  103,  105,  107,  108,  110,  112,  113,  114,  116,
  117,  118,  119,  120,  121,  122,  123,  123,  124,  125,  125,  126,  126,  126,  126,  126,
  127,  126,  126,  126,  126,  126,  125,  125,  124,  123,  123,  122,  121,  120,  119,  118,
  117,  116,  114,  113,  112,  110,  108,  107,  105,  103,  102,  100,   98,   96,   94,   91,
   89,   87,   85,   82,   80,   78,   75,   73,   70,   67,   65,   62,   59,   57,   54,   51,
   48,   45,   42,   39,   36,   33,   30,   27,   24,   21,   18,   15,   12,    9,    6,    3,
    0,   -3,   -6,   -9,  -12,  -15,  -18,  -21,  -24,  -27,  -30,  -33,  -36,  -39,  -42,  -45,
  -48,  -51,  -54,  -57,  -59,  -62,  -65,  -67,  -70,  -73,  -75,  -78,  -80,  -82,  -85,  -87,
  -89,  -91,  -94,  -96,  -98, -100, -102, -103, -105, -107, -108, -110, -112, -113, -114, -116,
 -117, -118, -119, -120, -121, -122, -123, -123, -124, -125, -125, -126, -126, -126, -126, -126,
 -127, -126, -126, -126, -126, -126, -125, -125, -124, -123, -123, -122, -121, -120, -119, -118,
 -117, -116, -114, -113, -112, -110, -108, -107, -105, -103, -102, -100,  -98,  -96,  -94,  -91,
  -89,  -87,  -85,  -82,  -80,  -78,  -75,  -73,  -70,  -67,  -65,  -62,  -59,  -57,  -54,  -51,
  -48,  -45,  -42,  -39,  -36,  -33,  -30,  -27,  -24,  -21,  -18,  -15,  -12,   -9,   -6,   -3   
};

static uint8_t const pi[16] = { 2, 3, 5, 7, 8, 11, 12, 13, 17, 19, 20, 23, 25, 27, 28, 29 };

static volatile uint8_t samples[1 << 8];
static volatile uint8_t update;
static volatile uint8_t timer;

static void generate(uint16_t const tones)
{
    uint8_t n = 0;
    uint8_t pa[16] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };

    while(update);
   
    do {
        int16_t i = 0;
        for(uint8_t t = 0; t < 16; ++t) {
            if(tones & (1 << t)) i += st[pa[t]];
            pa[t] += pi[t];
        }
        samples[n] = (2048 + i) >> 4;
   } while(++n);
 
    update = 1;
}

void __attribute__ ((signal, used, externally_visible)) TIMER1_CAPT_vect(void)
{
    static uint8_t n;
    static uint8_t new;
    static uint8_t out[1 << 8];

    if(new) out[n] = samples[n];
    OCR1A = 100 + out[n];
   
    if(!n++) {
        --timer;
        if(new) {
            new = 0;
            update = 0;
        } else {
            new = update;
        }
    }
}

int main(void)
{
    PORTB = PORTC = PORTD = 0;
    DDRB = DDRC = DDRD = 0xFF;
    TCCR1A = 0xA2;
    TCCR1B = 0x19;
    TCCR1C = 0x00;
    ICR1 = 13 * 32 - 1;
    OCR1A = OCR1B = 100 + 128;
    TIFR1 = 0;
    TIMSK1 = 0x20;
    __asm__ __volatile__ ("sei" ::: "memory");
   
    generate(~0);
    timer = 255; while(timer);
   
    uint16_t lfsr = 1;
    for(;;) {
        timer = 7; while(timer);
        lfsr ^= lfsr >> 7; lfsr ^= lfsr << 9; lfsr ^= lfsr >> 13;
        generate(lfsr);
    }
   
    return 0;
}


Nice, very nice.

A little outside of the voice 300 -> 3k bandwidth requirement, but that's just selecting the right range of primes and sample rate...

[gnuarm]

I don't recall how he said he was going to demodulate the tones.  Would each propeller CPU be used as a tone detector? 

Decoding is simple: Google for "Arduino audio analyzer" - plenty of examples.

Propeller was for tone generation. Two of them.

Yes, that's my point.  Anyone who would use a pair of propeller multiprocessors for generating tones that any MCU could generate would clearly not be happy with anything simple for tone detection.  In fact, I expect he would want to program distinct FIR filters for each tone, one per propeller CPU. 

[ogden]

In lost post of mine I was saying that multichannel transmission does not increase information transmission speed, nor improve latency.

Example: OOK/BPSK spectral efficiency is 1bit/Hz, 1600bps transmission requires 1600Hz frequency band of single channel. Transmission of 16 bits will take 1/100 sec. When we split 1600Hz channel into smaller 16 non-interfering 100Hz subchannels and transmit using OOK/BPSK, then those who can do the math will see that latency of 16 bit transmission will be 1/100 sec. In short: 16-tone requirement only adds unnecessary complexity, does improve nothing in terms of speed or latency.

[gf]

It can be done with an ATMega328. Here is some code that uses DDS for 16 tones.

Thanks for the practical proof of concept, showing that the core functionality of a software DDS is indeed not more than a handful lines of code.
I'm not sure whether this was understood by the OP, when a DDS was proped pretty early in this thread (w/o giving a practical code example showing the final implementation on a µC).

A little outside of the voice 300 -> 3k bandwidth requirement, but that's just selecting the right range of primes and sample rate...

Given that a 300...3000Hz channel is available (as specified by the OP), larger primes need to be selected so that fmax/fmin does does exceed 10:1. For instance the 16 primes in the 7...67 range, in conjunction with a base frequency of 44.6Hz would fit (orthogonality of tones were granted then for window sizes which are integral multiples of 22.422ms). For DDS, the sampling rate does not need to be an integral multiple of the generated frequency. By using a larger phase accumulator (e.g. 32bits), and doing phase truncation, one can basically generate arbitrary frequencies at much finer granularity (at the cost of a bit of phase noise, but the amount can be controlled via the the waveform table size). Of course it is certainly helpful if a sampling rate can be selected which does not require phase truncation, but if it can't, then it is not a disaster either.

[gnuarm]

In lost post of mine I was saying that multichannel transmission does not increase information transmission speed, nor improve latency.

Example: OOK/BPSK spectral efficiency is 1bit/Hz, 1600bps transmission requires 1600Hz frequency band of single channel. Transmission of 16 bits will take 1/100 sec. When we split 1600Hz channel into smaller 16 non-interfering 100Hz subchannels and transmit using OOK/BPSK, then those who can do the math will see that latency of 16 bit transmission will be 1/100 sec. In short: 16-tone requirement only adds unnecessary complexity, does improve nothing in terms of speed or latency.

Bingo!  1+   

[gnuarm]

It can be done with an ATMega328. Here is some code that uses DDS for 16 tones.

Thanks for the practical proof of concept, showing that the core functionality of a software DDS is indeed not more than a handful lines of code.
I'm not sure whether this was understood by the OP, when a DDS was proped pretty early in this thread (w/o giving a practical code example showing the final implementation on a µC).

A little outside of the voice 300 -> 3k bandwidth requirement, but that's just selecting the right range of primes and sample rate...

Given that a 300...3000Hz channel is available (as specified by the OP), larger primes need to be selected so that fmax/fmin does does exceed 10:1. For instance the 16 primes in the 7...67 range, in conjunction with a base frequency of 44.6Hz would fit (orthogonality of tones were granted then for window sizes which are integral multiples of 22.422ms). For DDS, the sampling rate does not need to be an integral multiple of the generated frequency. By using a larger phase accumulator (e.g. 32bits), and doing phase truncation, one can basically generate arbitrary frequencies at much finer granularity (at the cost of a bit of phase noise, but the amount can be controlled via the the waveform table size). Of course it is certainly helpful if a sampling rate can be selected which does not require phase truncation, but if it can't, then it is not a disaster either.

In an application like this phase noise is not likely to be significant at all.  If it is, it is not hard to mitigate with a linear approximation after the sine lookup using the remaining low order bits of the phase word.  It is not uncommon to use a linear approximation to reduce the size of the sine table.  I recall a method using a trig equivalence sin(a+b) = sin(a)cos(b) + cos(a)sin(b) ~= sin(a) + cos(a)sin(b) or two table lookups (functionally equivalent to the linear approximation).  The noise levels attainable are actually quite remarkable and show why digital techniques can be superior to analog.  In this case the limitation will be in the noise generated in the DAC process. 

Using an FFT for the tone decoding has some problems.  Because the frequencies being detected are so low, it is easy to detect them with simple band pass filters.  This eliminates the need for the frequencies to be multiples of any fundamental rate and eliminates the need for windowing.  With a bank of tone detectors each detector works asynchronously with no framing, only exhibiting a delay corresponding to the width of the band detected.  Unlike the FFT, there is no windowing so no "bin splatter".

The interplay between FFT bins and prime numbers result in some bins being very closely spaced so larger data sets are needed increasing the computational loads and delaying the response.  The FFT can be run on overlapping input data, but that results in much higher computational loads.  I have not looked at the ability of simple MCUs to perform FFTs in a while.  If a processor like the ARM CM4F is used, I suspect this won't be a problem.  Certainly they are not any more expensive or power consuming than the propeller devices and are much easier to program, not to mention only requiring a single device rather than two.

[MIS42N]

In lost post of mine I was saying that multichannel transmission does not increase information transmission speed, nor improve latency.

Example: OOK/BPSK spectral efficiency is 1bit/Hz, 1600bps transmission requires 1600Hz frequency band of single channel. Transmission of 16 bits will take 1/100 sec. When we split 1600Hz channel into smaller 16 non-interfering 100Hz subchannels and transmit using OOK/BPSK, then those who can do the math will see that latency of 16 bit transmission will be 1/100 sec. In short: 16-tone requirement only adds unnecessary complexity, does improve nothing in terms of speed or latency.

I was wondering about that. To achieve higher bit rates needs each subchannel to have some form of multibit encoding. Old modems (and maybe still do) negotiated by sending tones and working out noise and distortion, encoded as many bits as each subchannel could reliably handle. However, this does nothing to reduce latency, just send more bits in the same time slice. OP seems interested in latency more than bit rate.

Depending on the actual timing of events, maybe event notification would be a better solution. Send a byte with an event and new value. Since the value is only 1 bit (led on or off) could have up to 128 events. An extensible scheme. This has lower latency and given the sort of data involved could be encoded in a narrow bandwidth. Use a carrier under 300Hz and still get 100ms response. Could go along with the audio.

[hamster_nz]

The requirements are not well enough thought out and expressed if it was monitoring the state of 16 subsystems on a deep space probe.

However, the OPs requirements are well enough thought out and expressed for a hobby project, to be made out of stuff on hand, and perform 'well enough' for their needs, which appear to be monitoring 16 things in a semi-remote radio site.

This sounds like an environment where a Raspberry Pi + cell phone +  web cam pointed at battery meters could be a workable solution to monitoring UPS charge. Let's not over-engineer it. 

[MIS42N]

The requirements are not well enough thought out and expressed if it was monitoring the state of 16 subsystems on a deep space probe.

However, the OPs requirements are well enough thought out and expressed for a hobby project, to be made out of stuff on hand, and perform 'well enough' for their needs, which appear to be monitoring 16 things in a semi-remote radio site.

This sounds like an environment where a Raspberry Pi + cell phone +  web cam pointed at battery meters could be a workable solution to monitoring UPS charge. Let's not over-engineer it. 

I understand what you saying. I don't think two $3 boards and a few passives is over engineering. The beauty of microprocessors is how much can be done with very little. Reading 16 inputs, encoding, decoding and create 16 outputs is a simple task. I recently decided I needed a second 9600 baud input to a processor with one UART, implemented one in software, no problem and for good measure would handle 3.3V input without a level translator. On an 8 bit processor worth maybe $1. Is that over engineering or just making best use of what is there?

And maybe the OP had thought out the requirements, but I would contest that they were expressed in any useful format. About all we were told was a certain packet protocol had too much delay, and were given a 'solution' that we were left to flesh out. I think the majority opinion is the solution is not appropriate for the problem. It is interesting that the only demonstration that appears to solve the problem did not use the proposed solution.

It is interesting to see if any of the multitone proposals gets a real world demonstration. And if it works, is it in any way superior to a time slot system. I think it is like clean coal. Feasible but uneconomic.

[gf]

[...] And if it works, is it in any way superior to a time slot system. I think it is like clean coal. Feasible but uneconomic.

One significant disadvantage of the OOK/DMT approach is the huge peak to avarage power ratio. In order not to clip at worst case¹⁾, when the peak values of all tones happen to add-up, each tone needs to be transmitted with a level of only -24dB_FS²⁾. In my simulation, the maximum tolerated noise level turned out to be only about -27dB_FS (where I still got sufficiently clean eye diagrams). That's not much. To me it is still unclear what effect a squelch or dynamic compressor in the transmission path would have on the bit error rate. Data rate in my simulation was 84.375 16-bit-words per second, dividing the 300...3000Hz range into 16 equally spaced bands. Delay is dominated by by pulse shaping on the sender side (necessary to prevent cross-talk into neighbor channels) and the FFT window I used at the receiver side. Makes a delay of about 3-4 symbols in total (about 35-45ms).

For comparison, the good old Bell 202 FSK signal @1200bits/s has constant amplitude and thus a very good peak to average power ratio. It is pretty robust/tolerant to amplitude change and even some clipping. Due to constant amplitude I would not expect problems with squelch or dynamic compressor. I have simulated FSK as well, and even after adding -6dB_FS of noise I've still seen bit error rates as low as 10^-4...10^-3. So the noise tolerance is ~20dB better (factor 10 in terms of voltage) than the OOK/DMT approach. Both, modulator and demodulator are computationally cheaper than for OOK/DMT. If I assume 20-bit frames (start, 16x data, parity, 2x stop) then the net data rate is 60 16-bit-words per second. Delay (excluding the radio) is about 18ms (16.667ms for the frame transmission, and ~1ms for a digital low-pass filter at the reciver). If any DAC/ADC buffering and/or analog audio signal filters are required, they add on top of that (but this applies to both approaches).

Who of them is my winner?

¹⁾ Since the worst case happens rarely, it may be possible to overcommit amplitude, say by a factor of ~2. Still gains only 3dB 6dB SNR, while intruducing additional bit errors OTOH.
²⁾ With dB_FS I mean dB relative to a full scale sine wave

[fourfathom]

Delay is dominated by by pulse shaping on the sender side (necessary to prevent cross-talk into neighbor channels) and the FFT window I used at the receiver side. Makes a delay of about 3-4 symbols in total (about 35-45ms).

I think from your numbers that you are modulating the individual tones at twice the channel spacing (in Hz)?  If you cut the modulation rate in half (baud rate = tone spacing) then the modulation spectral nulls will have the same spacing as the channel-spacing, reducing neighbor crosstalk and your filter requirements.  Of course that halves your data rate...

[gf]

I think from your numbers that you are modulating the individual tones at twice the channel spacing (in Hz)?  If you cut the modulation rate in half (baud rate = tone spacing) then the modulation spectral nulls will have the same spacing as the channel-spacing, reducing neighbor crosstalk and your filter requirements.  Of course that halves your data rate...

I tried to avoid channel overlap completely at the transmitter side.
It is only 0.5 baud per Hz channel spacing, i.e. the main lobes of adjacent channels don't overlap (first zero in the middle between adjacent carriers).
And the side lobes are significantly reduced by doing pulse shaping prior to the AM modulation onto the carriers.
See attached figure2.png here https://www.eevblog.com/forum/projects/generating-simultaneous-tones/msg3552741/#msg3552741

[oPossum]

Nice, very nice.

A little outside of the voice 300 -> 3k bandwidth requirement, but that's just selecting the right range of primes and sample rate...

Thanks.

The OP mentioned using "Arduino audio analyzer" as a basis for decoding. That may be a reference to this: https://create.arduino.cc/projecthub/shajeeb/32-band-audio-spectrum-visualizer-analyzer-902f51
The code for that project has 32 bands from 601 Hz to 19.23 kHz. With a few simple changes described in the writeup it can cover 150 Hz to 4.8 kHz. So I wrote code that has a DDS phase increment value that matches the bin number of the FFT. The frequencies where chosen to have no 2nd or 3rd harmonics of each other. The result is 16 tones from 301 Hz to 4.357 kHz that match the FFT bins of the audio analyzer.

[gf]

The OP mentioned using "Arduino audio analyzer" as a basis for decoding. That may be a reference to this: https://create.arduino.cc/projecthub/shajeeb/32-band-audio-spectrum-visualizer-analyzer-902f51

One issue with this gadget is obviously leakage from the left and right neighbor channel, which can be also seen in the screenshots. Looking at the code at Github basically clarifies why this happens. Hamming window has a suppression of 40+ dB for the side lobes, but that comes at the cost that the main lobe has a width of +/-2 bins, i.e. the two immediately adjacent neighbor channels still fall into the main lobe. I see two potential solutions:

• Keep the Hamming window, but double the FFT size and discard every 2nd frequency bin (leads to higher computational cost for the longer FFT)
• Replace the Hamming window with a rectangular one, accepting some leakage when tones are turned on or off in a fast sequence
  (carriers which are continuously on, are still not supposed to leak, since the fall onto the zeros of the window's frequency response, but the modulation sidebands can leak)

Another potential issue is that the code caputures 64 samples, and then it does the whole processing for these samples before capturing the next samples. So the audio stream is obviously not sampled continuously, without gaps. For the intended use case this may be still OK. I have no idea, though, how long the processing takes and how log the gaps are.

BTW, just wondering, are the supported sampling rates really limited to "odd" values of 16MHz/13/2^n?