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)And the change to setup_pulses to still allow interrupts for the PPM case: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; }
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 setupPulses() { switch(g_model.protocol) { case PROTO_PPM: sei(); setupPulsesPPM(); cli(); break; case PROTO_PXX: setupPulsesPXX(); break; case PROTO_DSM2: setupPulsesDsm2(6); break; } }
Pat MacKenzieCode: 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; }
DSM2 work
DSM2 work
DSM fixes suggested by pmackenzie here:
Z
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
- MikeB
- 9x Developer
- Posts: 17995
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
DSM2 proposal
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.
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!
The difficult we do immediately,
The impossible takes a little longer!
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
Re: DSM2 work
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
http://www.rcgroups.com/forums/showthread.php?t=1482559
It might help? Unless you've already checked it out.
Cheers, Adrian
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: DSM2 work
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
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
Re: DSM2 work
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!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: DSM2 work
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
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
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
Re: DSM2 work
I grabbed the builds you posted 'on that other site'...
Nice work.
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.)=pmackenzie;20247667]A couple have asked, so here is a zipped copy of the r649 with the DSM2 "fix" for others to try.
...
Nice work.
- MikeB
- 9x Developer
- Posts: 17995
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: DSM2 work
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.
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!
The difficult we do immediately,
The impossible takes a little longer!
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
DSM2 work
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!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
Re: DSM2 work
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)
Again, excellent work. I fly in the winter, and right now, it's minus 16c , nice. (-35c just a hours North of me)
Re: DSM2 work
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!!
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: DSM2 work
Standard for me.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.
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
- MikeB
- 9x Developer
- Posts: 17995
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: DSM2 work
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.
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 612 times
-
- er9x-frsky.hex
- FrSky version DSM2 test
- (166.98 KiB) Downloaded 592 times
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: DSM2 work
Does it work at all? - Yes
Runs my AR6100 setup perfectly.
Does it glitch? - charging batteries for my MCPx, should know in a while
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
Runs my AR6100 setup perfectly.
Does it glitch? - charging batteries for my MCPx, should know in a while
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
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: DSM2 work
FWIW, I just did a quick check and PPM when selected is still working fine as well.
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: DSM2 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.cr8tive_leo wrote:I grabbed the builds you posted 'on that other site'...
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.)=pmackenzie;20247667]A couple have asked, so here is a zipped copy of the r649 with the DSM2 "fix" for others to try.
...
Nice work.
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
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
Re: DSM2 work
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 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
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: DSM2 work
3 flights so far - no glitches
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
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
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: DSM2 work
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
Pat MacKenzie
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
Pat MacKenzie
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
Re: DSM2 work
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...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.
-
- Posts: 1844
- Joined: Tue Dec 27, 2011 8:22 pm
- Country: -
- Location: Ottawa
Re: DSM2 work
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).
A bit chilly (and windy) for flying here too -- wind chill in the -20s (C).
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: DSM2 work
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?
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?
- MikeB
- 9x Developer
- Posts: 17995
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: DSM2 work
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.
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 2149 times
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: DSM2 work
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
with a AR6210 today. I confirmed it using a Spektrum Analyser.
Cheers,
Vinz
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
Re: DSM2 work
A) yesMikeB 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.
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
off to the monster in laws, will hook up the lp4 this weekend in another tx to see how it performs.
- Mechcondrid
- Posts: 222
- Joined: Fri Dec 30, 2011 3:53 am
- Country: -
- Location: ledyard, connecticut, United States
- Contact:
Re: DSM2 work
hey was looking at doing this where would i get a dsm2 transmitter module?
- MikeB
- 9x Developer
- Posts: 17995
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: DSM2 work
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.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)
Mike.
- Attachments
-
- er9x.hex
- (148.88 KiB) Downloaded 469 times
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
- wheelspinner20
- Posts: 175
- Joined: Tue Dec 27, 2011 6:22 pm
- Country: -
- Location: Michigan, U.S.
Re: DSM2 work
Mechcondrid.... ebay, heres a link with a few tx only sales. whack and hack it!hey was looking at doing this where would i get a dsm2 transmitter module?
http://www.ebay.com/sch/i.html?_nkw=msr ... m270.l1313
Pat
no more quippy little latin phrases.! Its old
- Mechcondrid
- Posts: 222
- Joined: Fri Dec 30, 2011 3:53 am
- Country: -
- Location: ledyard, connecticut, United States
- Contact:
Re: DSM2 work
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?
also what are the current chances of getting dsmx to work on er9x?
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
DSM2 work
I believe that is a hardware function of the module - so will work regardless if er9x!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?
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!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!