bigandy
Apr 13, 2007, 05:45 AM
Hi folks.
First of all, let me explain what I was trying to acheive here. I have been looking into the Spectrum DX7 electronics and protocol for a short while. My intention was to see if it was feasible to design a convertor to take a standard PPM input (eg from a trainer port of an existing PPM transmitter, such as my Evo 9) and output a signal that would feed into the rf module section of the DX7 transmitter. The eventual aim would be to allow the use of spectrum receivers with a PPM transmitter.
Personally, I am reasonably happy with 35MHz at the moment, but I have two main issues. The first is the susceptibility to interference from things like brushless motors etc, and secondly, the lenght of the aerial (which is huge when you mainly fly sub 36" span models!). being able to use the Spectrum receivers with my Evo radio would be great, which is why I started out on this project. However, since I started, Spektrum have announced off the shelf PPM-Spektrum modules, which sort of eliminates the need for what I am doing here. This is why I have decided to post this work before it is completed. I may or may not carry on with it
Right, so what have I done? Well, the first thing was to have a good mooch around the DX7 internals. This reveals a board that has two connections to the host radio, and one 2.4GHz aerial connection. The two connections (J1 and J2 on the board, see picture) carry a total of 3 and 6 wires. The image attached shows the "module" board out of the radio, and the wires are ones that I have added to able me to probe them with an oscilloscope) The hardware on the board is pretty simple, a 3.3v linear voltage regulator, a Cypress PSoC, a few discrete components, and a X1TXN rf module. This board is also used in the DX6 radio, but with a slightly different layout, with less connections, and a different PSoC code, but that is another story. The X1TXN module is the bit that has the FCC ID applied to it, and there is a fair amount of information that can be read on the FCC site (eg test results, operation manual, and a functional block diagram) which makes for interesting reading.
See Image showing module mounted on my sophisticated test bed.... . (below)
Armed with an oscilloscope, I have had a bit off a mooch around the various lines going to the board from the host processor. I have had a good look to see what each of them does, and whether it is required for the DX7 to operate correctly. I have also taken a few oscilloscope readings (see images) to show what is going on, although because I am still waiting for my new scope to arrive from China, I have had to use one at work, which has limited me somewhat. I have made a little table explaining what each line does, along with a few observations about them.
See Table of notes on connectiosn to rf deck.. (below)
The effect on the operation of the DX7 of the disconnection of lines to the module was measured by connecting an AR7000 receiver up to a set of seven servos, and a battery pack, and testing to see what happened when the line was removed. This was done before power up, after power up, during binding, and during normal operation. The removal of any of the lines that did not affect the operation of the radio at short range on the bench does not seem to affect the operation during any operating situation that I have tried. The screenshots attached also show the oscilloscope readings for various signals. The clock signal is shown (all 128 cycles, and a close up of 3-4 cycles) and the data line is also shown.
See Image showing Clock line (J2 - 4). (below)
See image showing detail of pulses on clock line (J2 - 4). (below)
See sample of data line (J2 - 2) showing one frame of data, consisting of 128 bits of data. (below)
From my observations, I think that the main source of data from the transmitter is being received by the module from J2 -2 and J2 - 4. This 128 bit data packet seems to contain all the information that needs to be sent to the X1TXN transmitter module, and on to the receiver. from just playing around with the transmitter and watching the data change on the scope, it seems that each channel has a dedicated location in the data frame, and a certain number of data bits. There also seems to be a checksum or other data associated with each channel. To figure this out, I will need to collect further data (see below). The model match feature is also interesting as depending on the model selected in the DX7, the first few data bits in the 128 bit frame change.
That is about as far as I have got to date. Well, sort of. I obviously need to collect some data on the signal format used by the module, and based on the fact the data is a serial stream of sorts, I have writted a bit of code for a PIC microcontroller to read in the 128bits of data using an SPI port. I am still perfecting it, but this should allow the capture of data in an efficient manner, that can then be transmitter to a PC, and hopefully decoded. I expect to be able to find out where the channel data is located in the frame, and what it means, along with any checksum or other data that is included in the packet.
I think that is all for now. Any questions, fire away! As I mentioned, I am not sure that I will continue this work further, because of the availability of the Spektrum PPM modules in the near (hopefully!) future. I will more than likely see what format the 128 bit data packets are though, if only to satisfy my curiosity.
Cheers
Andy
First of all, let me explain what I was trying to acheive here. I have been looking into the Spectrum DX7 electronics and protocol for a short while. My intention was to see if it was feasible to design a convertor to take a standard PPM input (eg from a trainer port of an existing PPM transmitter, such as my Evo 9) and output a signal that would feed into the rf module section of the DX7 transmitter. The eventual aim would be to allow the use of spectrum receivers with a PPM transmitter.
Personally, I am reasonably happy with 35MHz at the moment, but I have two main issues. The first is the susceptibility to interference from things like brushless motors etc, and secondly, the lenght of the aerial (which is huge when you mainly fly sub 36" span models!). being able to use the Spectrum receivers with my Evo radio would be great, which is why I started out on this project. However, since I started, Spektrum have announced off the shelf PPM-Spektrum modules, which sort of eliminates the need for what I am doing here. This is why I have decided to post this work before it is completed. I may or may not carry on with it
Right, so what have I done? Well, the first thing was to have a good mooch around the DX7 internals. This reveals a board that has two connections to the host radio, and one 2.4GHz aerial connection. The two connections (J1 and J2 on the board, see picture) carry a total of 3 and 6 wires. The image attached shows the "module" board out of the radio, and the wires are ones that I have added to able me to probe them with an oscilloscope) The hardware on the board is pretty simple, a 3.3v linear voltage regulator, a Cypress PSoC, a few discrete components, and a X1TXN rf module. This board is also used in the DX6 radio, but with a slightly different layout, with less connections, and a different PSoC code, but that is another story. The X1TXN module is the bit that has the FCC ID applied to it, and there is a fair amount of information that can be read on the FCC site (eg test results, operation manual, and a functional block diagram) which makes for interesting reading.
See Image showing module mounted on my sophisticated test bed.... . (below)
Armed with an oscilloscope, I have had a bit off a mooch around the various lines going to the board from the host processor. I have had a good look to see what each of them does, and whether it is required for the DX7 to operate correctly. I have also taken a few oscilloscope readings (see images) to show what is going on, although because I am still waiting for my new scope to arrive from China, I have had to use one at work, which has limited me somewhat. I have made a little table explaining what each line does, along with a few observations about them.
See Table of notes on connectiosn to rf deck.. (below)
The effect on the operation of the DX7 of the disconnection of lines to the module was measured by connecting an AR7000 receiver up to a set of seven servos, and a battery pack, and testing to see what happened when the line was removed. This was done before power up, after power up, during binding, and during normal operation. The removal of any of the lines that did not affect the operation of the radio at short range on the bench does not seem to affect the operation during any operating situation that I have tried. The screenshots attached also show the oscilloscope readings for various signals. The clock signal is shown (all 128 cycles, and a close up of 3-4 cycles) and the data line is also shown.
See Image showing Clock line (J2 - 4). (below)
See image showing detail of pulses on clock line (J2 - 4). (below)
See sample of data line (J2 - 2) showing one frame of data, consisting of 128 bits of data. (below)
From my observations, I think that the main source of data from the transmitter is being received by the module from J2 -2 and J2 - 4. This 128 bit data packet seems to contain all the information that needs to be sent to the X1TXN transmitter module, and on to the receiver. from just playing around with the transmitter and watching the data change on the scope, it seems that each channel has a dedicated location in the data frame, and a certain number of data bits. There also seems to be a checksum or other data associated with each channel. To figure this out, I will need to collect further data (see below). The model match feature is also interesting as depending on the model selected in the DX7, the first few data bits in the 128 bit frame change.
That is about as far as I have got to date. Well, sort of. I obviously need to collect some data on the signal format used by the module, and based on the fact the data is a serial stream of sorts, I have writted a bit of code for a PIC microcontroller to read in the 128bits of data using an SPI port. I am still perfecting it, but this should allow the capture of data in an efficient manner, that can then be transmitter to a PC, and hopefully decoded. I expect to be able to find out where the channel data is located in the frame, and what it means, along with any checksum or other data that is included in the packet.
I think that is all for now. Any questions, fire away! As I mentioned, I am not sure that I will continue this work further, because of the availability of the Spektrum PPM modules in the near (hopefully!) future. I will more than likely see what format the 128 bit data packets are though, if only to satisfy my curiosity.
Cheers
Andy