DSM2 work

Like DSM2/DSMX? Want to mod your radio to support it? Post your messages here!
Post Reply
User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

DSM2 work

Post by erazz » Tue Dec 27, 2011 6:33 pm

DSM fixes suggested by pmackenzie here:
Finally figured out what was going on.
Between each byte pair the ISR was calling setup_pulses() to load up the next byte pair.
Presumably to keep overall system performance high it allowed other interrupts to be processed, but blocked further calls to itself.
This works fine in the much slower PPM sequence since the call is made when there is more than 5msec of free time before the next change in the PPM sequence.

However in this case the setup_pulses() sequence was occasionally (every couple of minutes!) getting interrupted by the 10 msec timer for long enough that it did not get done before the next bit change.
There was a bit of code to try to catch this, but what it did was end up putting a 32.7 msec pause in the middle of the data packet. (They warn in the data sheet about directly setting the timer values when using the compare mode, so it was missing the end and rolling around)

The solution was easy - just don't allow interrupts during the setup_pulses in the DSM case.
Then you can eliminate the checking code as well since you will never miss the interrupt while processing the last one.

After this change there were still occasional very short twitches I modified the code to output all 0x55 and 0xAA, the worst case, and looking at the output with the logic analyzer there were occasional single bit errors in the decoded data.
To attempt to reduce them I sped up the ISR by removing the lines of code that measured the dither.
That solved the problem of single bit errors in the logic analyzer, and I have not seen a glitch in the heli since.

Here are the changes to the code (in red)

Code: Select all

ISR(TIMER1_COMPA_vect) //2MHz pulse generation
{
    static uint8_t   pulsePol;
    static uint16_t *pulsePtr = pulses2MHz;

//    uint8_t i = 0;
//    while((TCNT1L < 10) && (++i < 50))  // Timer does not read too fast, so i
//        ;
//    uint16_t dt=TCNT1;//-OCR1A;


    if(pulsePol)
    {
        PORTB |=  (1<<OUT_B_PPM);
        pulsePol = 0;
    }else{
        PORTB &= ~(1<<OUT_B_PPM);
        pulsePol = 1;
    }

    //  if (g_model.protocol==PROTO_PPM)
    //  {
    //    if ( *(pulsePtr+1) != 0 )  // Not the sync pulse
    //    {
    //      if ( channel & 1 )  // Channel pulse, not gap pulse
    //      {
    //        *pulsePtr = max(min(g_chans512[channel>>1],PPM_range),-PPM_range) + PPM_CENTER - PPM_gap + 600;
    //      }
    //    }
    //    else // sync pulse
    //    {
    //      uint16_t rest ;
    //      rest = PPM_frame - PulseTotal ;
    //      *pulsePtr = rest ;
    //    }
    //    channel += 1 ;
    //  }
    //  PulseTotal += (OCR1A  = *pulsePtr++);
    OCR1A  = *pulsePtr++;
    
//		if ( dt > g_tmr1Latency_max) g_tmr1Latency_max = dt ;    // max has leap, therefore vary in length
//    if ( dt < g_tmr1Latency_min) g_tmr1Latency_min = dt ;    // max has leap, therefore vary in length

    if( *pulsePtr == 0) {
        //currpulse=0;
        pulsePtr = pulses2MHz;
        pulsePol = g_model.pulsePol;//0;
        //    channel = 0 ;
        //    PulseTotal = 0 ;

        TIMSK &= ~(1<<OCIE1A); //stop reentrance
 //       sei();
        setupPulses();
 

// No  missed interrupts allowed! This section no longer required
				// For DSM2 problem, missed interrupt
//		    if (g_model.protocol == PROTO_DSM2)
//				{
//					if ( TIFR & (1 << OCF1A ) )		// Interrupt pending
//					{			
//						TCNT1 = 0 ;					
//					}
//				}
 //       cli();
        TIMSK |= (1<<OCIE1A);
 //       sei();  why is this here? Should be done on automatically return from the interrupt
    }
    heartbeat |= HEART_TIMER2Mhz;
}
And the change to setup_pulses to still allow interrupts for the PPM case:

Code: Select all

void setupPulses()
{
    switch(g_model.protocol)
    {
    case PROTO_PPM:
        sei();
        setupPulsesPPM();
        cli();
        break;
    case PROTO_PXX:
        setupPulsesPXX();
        break;
    case PROTO_DSM2:
        setupPulsesDsm2(6);
        break;
    }
}
I also made a change to the bind portion to allow the stick positions to be sent during bind as well as 8 channels to be sent. My LP4 module goes into bind mode on every power up so I couldn't fully test the first item, and 8 channel mode did not work at all. But perhaps it will with the DX5e module?

Code: Select all

void setupPulsesDsm2(uint8_t chns)
{
   static uint8_t dsmDat[2+8*2]={0x80,0,  0x00,0xAA,  0x05,0xFF,  0x09,0xFF,  0x0D,0xFF,  0x13,0x54,  0x14,0xAA, 0x1B, 0xFF, 0x1e,0xff};  //changed from 2+6*2, and added last 4 bytes of init data
    static uint8_t state = 0;
//    SPY_ON;

    pulses2MHzptr = pulses2MHz;
    
    if(state==0){

        if((dsmDat[0] == 0) || ! keyState(SW_Trainer))//pim{ //init - bind!
            dsmDat[0]=0; dsmDat[1]=0x00;  //DSM2_Header = 0,0;
            for(uint8_t i=0; i<chns; i++){
                uint16_t pulse = limit(0, (g_chans512[i]>>1)+512,1023);
                dsmDat[2+2*i] = (i<<2) | ((pulse>>8)&0x03);
                dsmDat[3+2*i] = pulse & 0xff;
            }
        //pim}
    }
    sendByteDsm2(dsmDat[state++]);
    sendByteDsm2(dsmDat[state++]);
//    sendByteDsm2(0xAA);
//    sendByteDsm2(0x55);
//    state++;state++;
    if(state >= 2+chns*2){
        pulses2MHzptr-=1; //remove last stopbits and
        _send_1(20000u*2 -1); //prolong them
        state=0;
    }
    _send_1(0);           //end of pulse stream
 //   SPY_OFF;
}
Pat MacKenzie
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!


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

DSM2 proposal

Post by MikeB » Tue Dec 27, 2011 6:57 pm

The interrupt routine is struggling to complete in 8uS. There are so many register pushes and pops they take up 4uS alone. Then there is the entry and exit and the actual processing. The 32.7 mS glitch is caused by the interrupt routine falling behind. The timer is set up to reset to zero on compare match. So as soon as the compare happens, and the interrupt is flagged up, the counter is already counting for the next interrupt. What happens is the OCR1A match register iis set to 8uS, but the interrupt routine is so far behind the counter has already gone past, so it has to wrap right round which takes the 32.7 mS of course.

Removing the dither code will shorten the interrupt routine, and must have made it short enough that the counter will not now get to the 8uS before the OCR1A register is set.

Maybe we could use the Input capture compare (has a CTC mode like OC1A) and its interrupt to create a really short routine to do the pulses, and the OCR1B compare interrupt to detect when the next set of pulses needs to be set up. To create the complete pulse train for DSM2 needs a maximum of 140 entries, but the pulses are quite short. I think we could use bytes to store the pulse widths, create a union of 70 words and 140 bytes.

So fior DSM2 disable the OCR1A interrupt, change the timer to mode 12 (ICP is top and clear time on match), enable the capture interrupt an set OCRB to match at 100 uS (value of 200). Create a pulse train of 8uS bits. The minimum is 8uS and the maximum is 72uS (ICP values of 16 and 144). Make the last pulse 255 (125.5uS). Send the pulses using the Capture interrupt, the counter will never get to 200 (100 uS) until all pulses sent. So when you get the OCRB match interrupt, set the ICP value to 40000 (20mS), and create the next set of pulses. When the Capture interrupt next occurs, it is time for the next pulse train to be sent, so will happen automatically.

If you switch back to PPM, then just disable the Capture interrupt and OCRB match interrupt, change the timer back to mode 4 (OCRA is top and clear on match) and re-enable the OCRA interrupt.

The DSM2 serial data will then be sent with no delays at all. Does this sound workable ot have I missed something?

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

User avatar
cre8tiveleo
Posts: 1434
Joined: Tue Dec 27, 2011 6:13 pm
Country: -
Location: Ontario,(GTA North)
Contact:

Re: DSM2 work

Post by cre8tiveleo » Tue Dec 27, 2011 10:32 pm

Have you looked into what this user did with dsm?

http://www.rcgroups.com/forums/showthread.php?t=1482559

It might help? Unless you've already checked it out.

Cheers, Adrian :ugeek:

pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: DSM2 work

Post by pmackenzie » Tue Dec 27, 2011 11:26 pm

It is working well now with the interrupts disabled in the ISR, but if another timer mode would work that would
allow us to eliminate the breaks between bytes it might help with latency. Measuring that is on my "to do " list.
A lot of unknowns here since we don't know how the module is dealing with the incoming data.

I thought of trying to use 4 bits instead of 8 to store the bit intervals, but could not come up with a fast enough way to do it using the existing ISR.


Pat MacKenzie

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: DSM2 work

Post by erazz » Tue Dec 27, 2011 11:57 pm

I like what you did. I also like the idea of using non-blocking interrupts. I just want to be sure this doesn't break something else.
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!


pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: DSM2 work

Post by pmackenzie » Wed Dec 28, 2011 12:53 am

Check carefully. There is not much more critical in the radio than the PPM generation. :!:
I tried to make sure that the normal PPM routine was unaffected, other than eliminating the data collection of the jitter.
The jitter still shows up on the diagnostic screen, but with the initial values set when the program boots.
Not sure they serve much purpose anymore anyway.

tmain is still useful to see, since the users mixes can affect the value.

Pat MacKenzie

User avatar
cre8tiveleo
Posts: 1434
Joined: Tue Dec 27, 2011 6:13 pm
Country: -
Location: Ontario,(GTA North)
Contact:

Re: DSM2 work

Post by cre8tiveleo » Wed Dec 28, 2011 1:46 pm

I grabbed the builds you posted 'on that other site'... :geek:
=pmackenzie;20247667]A couple have asked, so here is a zipped copy of the r649 with the DSM2 "fix" for others to try.
...
My ar9000s still go flakey, but, I did notice the signal lights don't flicker every so often any more, they are rock solid all the time. (before they would flicker every few seconds.)

Nice work.

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

Re: DSM2 work

Post by MikeB » Wed Dec 28, 2011 3:23 pm

I've implemented my proposed changes, to add the two extra interrupt routines, on my test setup. The output signal on the 'scope looks really good, 14 bytes packed end to end every 20 mS. I don't have s DSM2 setup, so I will post a version for others to test. Which version does anyone need? Standard er9x, or FrSky etc.?

Pat's done an excellent job of locating the problem, and fixing the existing code. I'm merely trying to engineer a better implementation than we started with. We just copied the code from TH9X (thanks Thus). This new implementation might also be useful for the proposed PXX protocol which also needs high speed bit bashing.

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

User avatar
Rob Thomson
Site Admin
Posts: 4543
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

DSM2 work

Post by Rob Thomson » Wed Dec 28, 2011 4:10 pm

MikeB wrote:I've implemented my proposed changes, to add the two extra interrupt routines, on my test setup. The output signal on the 'scope looks really good, 14 bytes packed end to end every 20 mS. I don't have s DSM2 setup, so I will post a version for others to test. Which version does anyone need? Standard er9x, or FrSky etc.?

Pat's done an excellent job of locating the problem, and fixing the existing code. I'm merely trying to engineer a better implementation than we started with. We just copied the code from TH9X (thanks Thus). This new implementation might also be useful for the proposed PXX protocol which also needs high speed bit bashing.

Mike.

Frsky for me please :)


Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

User avatar
cre8tiveleo
Posts: 1434
Joined: Tue Dec 27, 2011 6:13 pm
Country: -
Location: Ontario,(GTA North)
Contact:

Re: DSM2 work

Post by cre8tiveleo » Wed Dec 28, 2011 6:30 pm

Standard 9x would be great. (I've two dsm2 and two standard turnigy radios)

Again, excellent work. I fly in the winter, and right now, it's minus 16c , nice. (-35c just a hours North of me)

Clivew
Posts: 338
Joined: Tue Dec 27, 2011 8:08 pm
Country: -
Location: Stroud, Glos, England

Re: DSM2 work

Post by Clivew » Wed Dec 28, 2011 11:11 pm

MikeB wrote:I've implemented my proposed changes, to add the two extra interrupt routines, on my test setup. The output signal on the 'scope looks really good, 14 bytes packed end to end every 20 mS. I don't have s DSM2 setup, so I will post a version for others to test. Which version does anyone need? Standard er9x, or FrSky etc.?

Pat's done an excellent job of locating the problem, and fixing the existing code. I'm merely trying to engineer a better implementation than we started with. We just copied the code from TH9X (thanks Thus). This new implementation might also be useful for the proposed PXX protocol which also needs high speed bit bashing.

Mike.

Frsky when you have time Mike!
I've just had 3 glitch-free flights with my mcpX and it seems a lot smoother with Pat's modified file.
Brilliant work!!

pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: DSM2 work

Post by pmackenzie » Wed Dec 28, 2011 11:20 pm

MikeB wrote:I've implemented my proposed changes, to add the two extra interrupt routines, on my test setup. The output signal on the 'scope looks really good, 14 bytes packed end to end every 20 mS. I don't have s DSM2 setup, so I will post a version for others to test. Which version does anyone need? Standard er9x, or FrSky etc.?

Pat's done an excellent job of locating the problem, and fixing the existing code. I'm merely trying to engineer a better implementation than we started with. We just copied the code from TH9X (thanks Thus). This new implementation might also be useful for the proposed PXX protocol which also needs high speed bit bashing.

Mike.
Standard for me.
Did you get the stop bit length down? That might possibly help Leo's issue with the AR9000.

The parallel port logic analyzer I used is way better than a scope to check out the waveforms.
http://www.codeproject.com/KB/system/17 ... lyzer.aspx

My DX4e got back from Horizon today so I can start to experiment a bit with it. One thing I tried with the LP4 module was to change the value of the second byte.
It is always zero, and changing it did absolutely nothing. (I though it might possibly have something to do with model match)
I will try the same test with the DX4e module, and also look into range check and DSMx modes.

One thing I still have to get is an actual DSMX receiver. The only things I have now are AR6100,AR6110, various micro "bricks", the MCPx and an AR7000, all DSM2.

Pat MacKenzie

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

Re: DSM2 work

Post by MikeB » Wed Dec 28, 2011 11:33 pm

The stop bit is now a single bit time, the bytes are packed together and take 1120 uS to send according to my digital storage 'scope. I also ignore the pulse polarity option, data is always serial.

I don't have any DSM receivers or transmitters so I will need feedback to know if this works.
(a) Does it work at all?
(b) Is it glitch free?
(c) Does the bind operation still work?

Standard and Frsky hex files attached (useful test of the new forum handling hes files?).

The main pulse handling interrupt is much shorter that the original because it is dedicated to DSM. SetupPulses() checks to see if the protocol has been changed. If it has, it switches the timer operation and which interrupt routines handle the pulse output.

Mike.
Attachments
er9x.hex
Standard version DSM2 test
(148.93 KiB) Downloaded 315 times
er9x-frsky.hex
FrSky version DSM2 test
(166.98 KiB) Downloaded 326 times
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: DSM2 work

Post by pmackenzie » Thu Dec 29, 2011 12:11 am

Does it work at all? - Yes :)
Runs my AR6100 setup perfectly.

Does it glitch? - charging batteries for my MCPx, should know in a while :D

Can't test the bind mode, my module is auto-bind. But I can check with my logic anaylzer easily enough.

Anxious to see your code.


Pat MacKenzie

pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: DSM2 work

Post by pmackenzie » Thu Dec 29, 2011 12:15 am

FWIW, I just did a quick check and PPM when selected is still working fine as well.

pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: DSM2 work

Post by pmackenzie » Thu Dec 29, 2011 12:23 am

cr8tive_leo wrote:I grabbed the builds you posted 'on that other site'... :geek:
=pmackenzie;20247667]A couple have asked, so here is a zipped copy of the r649 with the DSM2 "fix" for others to try.
...
My ar9000s still go flakey, but, I did notice the signal lights don't flicker every so often any more, they are rock solid all the time. (before they would flicker every few seconds.)

Nice work.
Leo - try doing a fresh bind with the AR9000. Since it is 2048 mode, binding to it could put the module in a different operating mode than the normal DSM2.
If it then works you might then find that the MCPx does not work, since it expects 1024 data.

If it does behave like this it would simply be a limitation of the module based systems. The integrated ones store the "flavour" of DSM2 with the model settings and switch the RF set accordingly.

Pat MacKenzie

User avatar
cre8tiveleo
Posts: 1434
Joined: Tue Dec 27, 2011 6:13 pm
Country: -
Location: Ontario,(GTA North)
Contact:

Re: DSM2 work

Post by cre8tiveleo » Thu Dec 29, 2011 12:52 am

pmackenzie wrote:
Leo - try doing a fresh bind with the AR9000. Since it is 2048 mode, binding to it could put the module in a different operating mode than the normal DSM2.
If it then works you might then find that the MCPx does not work, since it expects 1024 data.

If it does behave like this it would simply be a limitation of the module based systems. The integrated ones store the "flavour" of DSM2 with the model settings and switch the RF set accordingly.

Pat MacKenzie
Makes sense. I try to rebind with every new update. They all bind, all the rx's do , I can control the ar6100's 6110 6100e orage ar8000 ar 7000 and ar9000s, it's only with the 9000 that I have the flutter. I will try to make a video of what I am talking about. (maybe it's just 1024 and the 9000 just deals with it in that manner, but it only flutters when I do Rudder right, the throttle channel then goes flakey.)
:)

pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: DSM2 work

Post by pmackenzie » Thu Dec 29, 2011 1:04 am

3 flights so far - no glitches :D

I took a look at the binding data. Header looks fine but I would suggest sending the actual channel data instead of the "canned" data thus did.
Stick positions on bind are used to set power on - no RF signal positions and failsafes.

If you kept the basic logic structure of SetupPulsesDSM2 then it is just a matter of removing one set of curly brackets to get the channel data with the bind codes.

Pat MacKenzie

pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: DSM2 work

Post by pmackenzie » Thu Dec 29, 2011 1:55 am

Noticed a problem with my AR6100 setup. With the sticks "in the corners" so that all the pulses go long it starts to stutter and move in steps.
Doesn't do it with my earlier fix.


One thing I would suggest is increase the frame length. you have 18.8 msec of dead time for a 20 msec frame. Try a 22 msec total frame to match the LP5 and LP4.

If you could email a copy of pulses.cpp then I could do some testing :geek:

Pat MacKenzie

User avatar
cre8tiveleo
Posts: 1434
Joined: Tue Dec 27, 2011 6:13 pm
Country: -
Location: Ontario,(GTA North)
Contact:

Re: DSM2 work

Post by cre8tiveleo » Thu Dec 29, 2011 2:08 am

pmackenzie wrote:Noticed a problem with my AR6100 setup. With the sticks "in the corners" so that all the pulses go long it starts to stutter and move in steps.
Doesn't do it with my earlier fix.
That's what happens with my ar9000, only with rudder to the right though (and flickers, or jumps...) I haven't installed the lasted test fix posted here...

Daedalus66
Posts: 1844
Joined: Tue Dec 27, 2011 8:22 pm
Country: -
Location: Ottawa

Re: DSM2 work

Post by Daedalus66 » Thu Dec 29, 2011 4:11 am

He said "Standard ER9x", not "Standard 9x", so I think you're out of luck with the regular firmware if that's what you meant.
A bit chilly (and windy) for flying here too -- wind chill in the -20s (C).

pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: DSM2 work

Post by pmackenzie » Thu Dec 29, 2011 4:56 am

I was able to replicate the stuttering with the sticks in the corners with my version by reducing the frame width to 20 msec total.
if it is increased to 22 msec the MCPx starts to stutter. Pretty narrow window!

I think the stop bit length might have to be increased as well, based on the LP5DSM data stream.
I will try to scan the DX4e tomorrow to see how it falls into this.
If it is significantly different perhaps we will need to add options to the DSM menu item to select the actual module type?
lp5.gif
new isr.gif

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

Re: DSM2 work

Post by MikeB » Thu Dec 29, 2011 12:01 pm

Pat, here are the sources of pulses.cpp and er9x.h. These are the only two files needed for the DSM2 changes. The hex files I posted have a couple of fixes and changes for FrSky operation, but these don't matter for DSM2.

I've changed the serial data to have 2 stop bits, the total frame period to 21mS, and put the stick data in the frame during binding.
With 11 bits per byte it takes 1232 uS to send the 14 bytes, so there is a 'make up' value in the OCRB compare interrupt.
I've also removed the DSM2 check in the standard OCRA interrupt routine since it will never happen.

Had to zip the files (.cpp and .h extensions not allowed).

Mike.
Attachments
DSMpulses.zip
(10.3 KiB) Downloaded 1892 times
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

lilvinz
Posts: 1
Joined: Thu Dec 29, 2011 6:35 pm
Country: -

Re: DSM2 work

Post by lilvinz » Thu Dec 29, 2011 6:37 pm

Hi together, just wanted to let you know that i was able to bind in DSMX mode
with a AR6210 today. I confirmed it using a Spektrum Analyser.

Cheers,

Vinz

User avatar
cre8tiveleo
Posts: 1434
Joined: Tue Dec 27, 2011 6:13 pm
Country: -
Location: Ontario,(GTA North)
Contact:

Re: DSM2 work

Post by cre8tiveleo » Fri Dec 30, 2011 4:00 pm

MikeB wrote:...
I don't have any DSM receivers or transmitters so I will need feedback to know if this works.
(a) Does it work at all?
(b) Is it glitch free?
(c) Does the bind operation still work?...
Mike.
A) yes
B) No
C) yes

B) - With a ar9000 the bind light above throttle flashes constantly, the other two (one on satellite and the other one on the module are solid for most of the time, they randomly flicker, but the frequency is greater than 1 min)

Pat's incarnation had solid bind lights all around. Both still have the twitch on the throttle when hitting right rudder, in both mode 1 and mode 2. (this happens with th9x too btw) all my other rx worked flawlessly. (as far as I could tell)

I am using
Image

off to the monster in laws, will hook up the lp4 this weekend in another tx to see how it performs.

User avatar
Mechcondrid
Posts: 222
Joined: Fri Dec 30, 2011 3:53 am
Country: -
Location: ledyard, connecticut, United States
Contact:

Re: DSM2 work

Post by Mechcondrid » Fri Dec 30, 2011 5:09 pm

hey was looking at doing this where would i get a dsm2 transmitter module?

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

Re: DSM2 work

Post by MikeB » Fri Dec 30, 2011 5:10 pm

cr8tive_leo wrote: B) - With a ar9000 the bind light above throttle flashes constantly, the other two (one on satellite and the other one on the module are solid for most of the time, they randomly flicker, but the frequency is greater than 1 min)

Pat's incarnation had solid bind lights all around. Both still have the twitch on the throttle when hitting right rudder, in both mode 1 and mode 2. (this happens with th9x too btw) all my other rx worked flawlessly. (as far as I could tell)
Here is a standard version of er9x with the changes I described above where I posted the source. Pat pointed out there should be 2 stop bits between bytes, this might make things better.

Mike.
Attachments
er9x.hex
(148.88 KiB) Downloaded 266 times
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
wheelspinner20
Posts: 175
Joined: Tue Dec 27, 2011 6:22 pm
Country: -
Location: Michigan, U.S.

Re: DSM2 work

Post by wheelspinner20 » Fri Dec 30, 2011 6:54 pm

hey was looking at doing this where would i get a dsm2 transmitter module?
Mechcondrid.... ebay, heres a link with a few tx only sales. whack and hack it!


http://www.ebay.com/sch/i.html?_nkw=msr ... m270.l1313

Pat
no more quippy little latin phrases.! Its old

User avatar
Mechcondrid
Posts: 222
Joined: Fri Dec 30, 2011 3:53 am
Country: -
Location: ledyard, connecticut, United States
Contact:

Re: DSM2 work

Post by Mechcondrid » Fri Dec 30, 2011 11:49 pm

whack and hack? lol i prefer disasembly in a much more controlled manner heh
also what are the current chances of getting dsmx to work on er9x?

User avatar
Rob Thomson
Site Admin
Posts: 4543
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

DSM2 work

Post by Rob Thomson » Sat Dec 31, 2011 12:00 am

Mechcondrid wrote:whack and hack? lol i prefer disasembly in a much more controlled manner heh
also what are the current chances of getting dsmx to work on er9x?
I believe that is a hardware function of the module - so will work regardless if er9x!

Rob


Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!


Post Reply

Return to “DSM2/DSMX Mods”