More Channels for DSM2/DSMX?

er9x is the best known firmware. It has a superb range of features and is well supported by the community. Well worth trying out.
Post Reply
MGeo
Posts: 21
Joined: Fri Feb 03, 2012 4:43 pm
Country: -

More Channels for DSM2/DSMX?

Post by MGeo »

Hi all,

I've been developing an RFM22B based Tx/Rx pair with 2 -way telemetry for use with my TGY 9X. I'd like the Tx to receive er9x command data using the serial based DSM2/DSMX. I've started work on the decoder, should be fairly straight forward.

Would it be straight forward to extend the DSM2/DSMX protocol to more than 6 channels of Tx data (to say 9?). A quick look at pulses.cpp seems to indicated it is presently hard coded at 6 channels. There is a warning in the code at line 424:

" // If more channels needed make sure the pulses union/array is large enough"

I assume this is the pulses2MHz array.

Code: Select all

#define PULSES_WORD_SIZE	72
#define PULSES_BYTE_SIZE	(PULSES_WORD_SIZE * 2)

union p2mhz_t 
{
    uint16_t pword[PULSES_WORD_SIZE] ;   //72
    uint8_t pbyte[PULSES_BYTE_SIZE] ;   //144
} pulses2MHz ;
I see that pulses2MHz array is a union of 72 words / 144 bytes. Does anyone know how to calc the needed array size based on number of DSM2 channels?

Line 390 gives me a clue that there are at most 10 transitions per byte transmitted:

Code: Select all

#define BITLEN_DSM2 (8*2) //125000 Baud
static void sendByteDsm2(uint8_t b) //max 10changes 0 10 10 10 10 1
With a two byte header plus 6 channels (12 bytes), each transmit string is 14 bytes. 14 bytes times 10 changes per byte max gives 140 changes. It looks to be that pulses2MHz holds the number of 2MHz ticks to the next pin transition. Are these ticks encoded in the array as byte or word values? The array storage numbers make me think bytes, but they look to be loaded into 16 bit OCR1A at line 87 in the ISR(TIMER1_COMPA_vect).

Code: Select all

  OCR1A  = *pulsePtr ;
		pulsePtr += 1 ;


So still trying to figure out how the DSM data is packed into pulses2MHz and how to allocate storage for additional channels. Any pointers or pitfalls would be much appreciated.

Thanks in advance,
George

User avatar
MikeB
9x Developer
Posts: 17993
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: More Channels for DSM2/DSMX?

Post by MikeB »

The DSM data is initially created in the (static) array dsmDat[] declared at the start of setupPulsesDsm2()

Code: Select all

void setupPulsesDsm2(uint8_t chns)
{
    static uint8_t dsmDat[2+6*2]={0xFF,0x00,  0x00,0xAA,  0x05,0xFF,  0x09,0xFF,  0x0D,0xFF,  0x13,0x54,  0x14,0xAA};
This is one array that needs extending for more channels.
You will need to also extend the pulses2MHz array/union.

When driving out DSM (or PXX) pulses, then OCR1B is used and the timings are stored in bytes as the time between edges is short enough. OCR1A uses 16 bit values for PPM.

Originally DSM2 sent up to 7 channels once every 22 mS, with each channel encoded as a 10 bit value. To support more than 7 channels, 7 channels are sent every 11mS, first channels 1-7, then 11 mS later channels 8-14. This is worth doing as it limits the extra RAM needed to store the channel and pulse data.
You could keep all the arrays the size they are and send channels 1-6 in one frame and 7-12 in the next.

Channel data is sent as two bytes, most significant byte first:
Bit 15: Pass - 0 for frame with channels 1-7, 1 for frame 8-14
Bit 14: 0
Bits 13-10: Channel number, 0 for channel 1, 1 for channel 2 etc.
Bits 9-0: Channel data, 512 for centre, each count of 1 away from this is about 1.25uS change in the pulse width.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
MGeo
Posts: 21
Joined: Fri Feb 03, 2012 4:43 pm
Country: -

Re: More Channels for DSM2/DSMX?

Post by MGeo »

Thanks again Mike. In an attempt to minimize latency I would like to try 9 channels per single stream per frame. With your info and some head scratching I went through what I think are the pulses.cpp patches to stream 9 channels of data. It appears to be working, but I need to do more testing. Source file and diff are attached below.

I would like to better understand where the source data is coming from. I think that better understanding the conversions and storage better may allow me to reduce the RAM usage.

I spent several hours trying to trace g_chans512[] back to the ADC but can not seem to connect the two. Would you be able to point me toward the conversion and storage path and how it gets called through the periodic frame interrupt?

Code: Select all

uint16_t pulse = limit(0, ((g_chans512[i]*13)>>5)+512,1023);
Since I am using my own module I don't need to stay 100% pure DSM. If channel resolution is encoded with 10 bit resolution, perhaps could I pack all 9 channels worth of data into the existing 96 bit array (6*2 data bytes * 8 bits/byte = 96 bit) with 6 bits to spare for some frame encoding info? Maybe that is going to far and I would be better off packing 12 bits / channel similar to PXX over USART. I'm sure if I can understand the conversion steps I could come up with a workable approach.

Thanks again for the help
George
Attachments
DSM2_9B.png
DSM2_9A.png
pulses.cpp.patch
(1.63 KiB) Downloaded 262 times
pulses.cpp
(23.23 KiB) Downloaded 280 times
User avatar
MikeB
9x Developer
Posts: 17993
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: More Channels for DSM2/DSMX?

Post by MikeB »

The analog inputs are read by:
void getADC_osmp()
with the results placed in the array s_anaFilt[].
These results are read by calls to:
uint16_t anaIn(uint8_t chan)
perMain() calls perOutPhase(g_chans512, 0)
passing the address of g_chans512.
perOutPhase() calls perOut, passing on the g_chans512 address.
perOut() is the main mixer function and fills in g_chans512:
cli();
chanOut = result ; //copy consistent word to int-level
sei();

perMain actually calls perOutPhase() as fast as possible to keep g_chans512 updated as fast as possible. perOut() calls anaIn() to get the analog values.
void getADC_osmp() is also called as often as possible.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Post Reply

Return to “er9x”