MarkF
Senior Heliman
Location: Palo Alto, CA
| Hi, Gang!
Angelos: Thank you very much for the generous offer!!! Unfortunately, all my work so far has been structured around the 16-channel data format, so I'd have to rewrite the code for the Futaba standard to be able to take advantage of your chip. Since my real interest is working on a next-generation solution, I am certainly very tempted to take you up on your offer, but it probably makes more sense for me not to waste your time, and to continue along the path I'm on. Again, though, I really appreciate the extremely kind offer! Thanks again - that was a totally cool thing to do!
In addition to the data channel format, I'm at a major decision point as to how to proceed with the next stage of development. As I'd mentioned earlier, the code as written needs about 1.2 mS of "dead time" between transmit frames (thanks to that critical section while its driving the servo pulses), which was just a simplifying assumption for initial development. To fix this, I'll need to decide what actual communications sampling format we'll be using. While the data structure's been described above, I want to eliminate the need for dead air, in order to achieve maximum data rate transmission, hence the lowest system latencies.
There's no question how the work would be done for QPSK: as mentioned earlier, we'd continuously DMA incoming analog data. The QPSK data would be transmitted at 16K bps, which is 8K symbols/second thanks to having 2 bits/symbol. In order to recover the data most efficiently, the receiver would oversample the incoming analog stream at four times the symbol rate, meaning that we'd have 32K samples/second, where each sample is comprised of an I-component and a Q-component. While we'd only need ~6-8 bits/sample to recover the incoming data, the Crystal A/D would be sending out 24 bits each for the I & Q components, leading to a total incoming data rate of 32K * 2 * 3 * 8 = 1.5M bits/second. Quite a lot of work to be done there!
Anyway, back to the point, for FSK, we'd ideally like to do something similar, that is, have a continuous oversampling of the incoming data stream that would be dumped into memory. This would allow "voting"-based reception, where instead of having to make a single decision whether a bit is high or low, we could decide that, say, if 5 samples out of 8 were high, then the result is a '1', or if 5 samples out of 8 were low the result would be a '0'. If we wound up with 4 samples out of 8 being high, we'd call this a bit error. This kind of approach would significantly increase the usable Signal/Noise Ratio. Just as important, it would be a much closer match to the architecture of the QPSK version.
Unfortunately, the chip that I'm using doesn't support these kinds of capabilities, so it'll be necessary to go to the Atmel chip to fix it. In the mean time, the question is whether to just publish the code as-is, with the requirement for the dead air, or whether to move on to the Atmel, develop a longer-term solution on that part, and then publish the code. Or maybe do both?
I guess the question is this: is anyone interested enough in what's been done so far to merit the effort of publishing the code in the next week or two, or would you rather wait until I move on to the next-generation chip, completely eliminate the deadtime, and publish it then? Any and all opinions would be greatly appreciated!
Thanks again, Angelos!!!
Cheers!
MarkF |
