AF Vehicle blog — January 31, 2010
| Home | << Historical | << First | < Prev | Next > | Last >> |
Yikes, it's been a long time!
I have been concentrating lately on getting the receiver decoder designed. In the entry on September 7th, I described what I thought was the algorithm used to time the pulses coming from the XPS receiver, or at least describe them. Further testing has shown that I was close, but not exactly right.
In an attempt to actually characterize the pulses and design the PIC firmware to decode them, I discovered something a bit unsettling. That is, the start time for the pulses can start very close together, as little as 17 µS apart. This means that I would not be able to resolve this with the shortest interrupt routine I could write, which requires about 50 or so µS to complete. This was bad news, and, I thought, meant that I would need a separate PIC for each channel once again.
However, during further investigation I found I could not get two subsequent intervals between channels to both be 17 µS. Reducing the interval between one set of channels seemed to push the prior and subsequent intervals out to considerably more than that. I eventually figured out what I now believe to be the correct interpretation of the timings.
XPS timing diagram
The above diagram will hopefully describe what I now believe to be the timing mechanism used in the XPS receiver. Note all timings are approximate. The four thick blue lines represent four channels being output from the receiver. We'll call them 1 through 4, from top to bottom. These lines are just examples of what might happen with particular locations of the sticks on the transmitter controlling these channels and are just for illustration.
Let's start to the right, when the pulses end. As I described before, the end times are quantized. All pulses ends on particular 60 µS boundary, represented by the dashed vertical lines. You can also see from this example that it's possible for the channels to end out of order, for instance, channel 3 ends before any of the other channels. You can also see that it is possible that more than one channel can end at exactly the same time (channels 2 and 4 in the example).
Now let's go back to the beginning of the pulses. (Note that the diagram is not to scale here!) This is where I was a little bit off in my analysis before. It seems like each channel has a 60 µS "window" in which it can start. The end time is quantized on a 60 µS boundary and the start time is adjusted so it starts some time within this 60 µS window, so that the entire pulse width is of the required length.
What is interesting is that each subsequent channels seems to have its own 60 µS window and these do not overlap. There is a 17 µS gap between the end of the window on one channel and the start of the window on the next channel. In the worst-case scenario (from the point of view of decoding it), if one channel starts at the very end of its window and the next channel starts at the very start of its window, there is only a 17 µS gap between the starts of the two pulses. Channels 2 and 3 in the above example illustrate this.
That's the bad news. It means that I can't use one controller to resolve two adjascent channels. However, as it should be clear, if two channels do start within 17 µS of each other, then obviously the second pulse started at the very beginning of its window, and the pulse in the next channel cannot start for at least another 60 µS. That bit of news tells me that I do not need one controller per channel; I can get away with two controllers, one to handle odd-numbered channels and one to handle even channels. That way, there must be at least 60+17+17=94 µS between the starts of any two pulses on a given controller. That is plenty of time!
I originally thought I would be decoding 4 channels with one controller. Since it is apparant now that I need two controllers, it becomes possible to decode 8 channels. Coincidentally, the XPS receiver is 8 channels. I don't believe I will need all those channels, but I don't see any point in limiting myself if it is easy to process all eight. You never know when you might want more in the future.
Receiver decoder design
With that, I think I have enough information to proceed with the receiver decoder module's design. I think the module will actually, conceptually, be two modules, the receiver decoder and the bus controller. The receiver module will be two PICs (processing odd and even channels) and the bus controller will be one PIC for a total of three. They will all be on the same board, as the bus controller will have to wait for the receiver decoder to finish before starting the frame. There will be a wire between each of the receiver decoder controllers and the bus controller.
From there, perhaps the next step might be to implement a servo module, which will pick up one of the channels from the bus and convert the value back into a servo pulse of the appropriate length. I can program up several of these and hook up servos or even an ESC, and I should see the entire thing work as if the servos were plugged into the receiver directly. Look ma, only one wire!
AF Vehicle blog — January 31, 2010
| Home | << Historical | << First | < Prev | Next > | Last >> |