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)
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.
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.
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.
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?
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.
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.
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.
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.
So how long is that piece of string?
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.
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!
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
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?
I have seen a much more in-depth Fourier analysis that used a longer time period. Unfortunately I couldn't find a link.
[...] 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.
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
So what happened to AX.25?
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.
AX.25 issues:
1 - not real time - "abuse" of protocol
2 - user end (receive) too complex; expensive.
Bill