There is a lot of stuff up on a few threads on how much time it takes to process all 6-7 channels from a receiver. But basically most of these receivers appear to process them serially. So first it will output the proper pulse width for a channel and as soon as it finishes that channel it will start the pulse for the second channel… Until it finishes the last channels pulse, at which time it waits for the next cycle time to come arround and it starts this over again. For this example assume that all seven channels come in order; 1,2,3,4,5,6,7. Depending on how you code this it can take a long time:
If you do a pulsin 1 followed by a pulsin 2, very often by the time the basic code gets into the pulsin 2 command the pulse already started and so it will hang around until the next whole cycle, which is not good. That is why if you know that this is the proper order then doing the pulsins by skipping 1 works a lot better: 1, 3, 5, 7, 2, 4, 6. This will still take two (to possibly 3) whole passes through the RC cycle. Side note: my assembly version function (mpulsein) can do it in one RC cycle…
So yes it would be great to offload all of this to a secondary processor, that caches up the information communicates with the BAP in a quick way. Which form of communication is best for this? I2c? SPI? serial? emulate PS2?
I know that Jim or others are looking into building a simple board to do this. I don’t know the current status of this.
I was initially thinking of just mimicking a PS2, so that it would be a drop-in replacement, but I suppose a little editing on the 'bot program could cut out the need to mimic a PS2’s initialization. What more should be changed? The “polling” of the current PS2 or serial coms is a bit of a bottleneck.
There is still the need to respond to a query request, although that could be simplified as well. It would be so much better to abandon the PS2 imitation, and run a synchronous SPI. Too bad Atom Basic doesn’t support SPI as an interrupt driven task. Although it could be added as interrupt driven ASM code. The hardware is there in the PICs, and probably in the Renisys (sp) chip as well.
I see the satellite processor (which could be running C or ASM instead) reading an R/C channel, updating a set of received values, and then answering requests as a PS2 implementation in a continuous loop to minimize latencies.
Or continuously sending out SPI words to it’s master as an SPI slave. All in the background.
How about a serial string of some sort… something that outputted something similar to
“1500;1500;1500;1500;1500;1500;1500” and then some null value #### and repeated every… whenever to signify a new sample being polled from the receiver?
Km6vv – Id say if your bored try programming a pic and see what you get.
You could send an ASCII string. Or, as in the case of the SP2, a “packet” of several (binary) words, which has the advantage of not needing decoding or translation. A checksum could also be appended.
You might not need to even worry about the new sample being received by the receiver. Although having a “data good” or “receiver active” status bit would be desirable.
I’ve always got several projects going! No boredom here! I may try some experiments with my old Futaba T4VWD (27 Mhz AM), and see if I can get any data. Really need a T7C to properly experiment. later…
… heh well I don’t have any idea’s how “best” of a way to do this idea.
I think buffered data as Kurte said above is the way to go.
Pick up a T7c and fiddle with it, its a great remote, maybe shoot some ideas when you get one on how to use the mixing controls for extra programming features. maybe Zenta has some ideas.
I don’t really think you would need to worry about a checksum.
Let me know if you need me to buy anything to test I wouldn’t mind building an Atmel programmer on a protoboard and test a chip. I think thoes things are pretty cheep … I think…
