Proposed changes to protocol labels (open9x)
- gruvin
- 9x Developer
- Posts: 131
- Joined: Tue Jul 24, 2012 10:02 pm
- Country: New Zealand
- Location: Auckland
- Contact:
Proposed changes to protocol labels (open9x)
I've been working with PPM, PPM16 and DSM code lately and it has occurred to me that the labels we currently use for these modes could use a working over.
For example, "PPM16" is not actually what that label suggests. It is more like "PPM+8", since there's no hint in the name "PPM16" that the upper 8 channels will be pumped out a different port, whereas I think "+8" bears some suggestion of that. Directly related to that is the fact that the base channel count can be set anywhere from "4CH" to "16CH". I am guessing that this in fact refers to the primary PPM output channel count, to which the upper 8 channels are added, on the secondary output (trainer) port. Perhaps then, we should either restrict base channel count to maximum "8CH" for this "PPM+8" protocol -- or increase the available mixer channels to 24 (16+8), if that is even feasible.
For the DSM protocol, we currently have a main protocol label of "DSM2", with sub-modes "LP4/LP", "DSM2onl" and "DSMX", which doesn't really make much sense. (How can DSM2 also be LP4 or DSMX?) So I would vote for protocol name of just "DSM", with sub-modes "DSM1", "DSM2" and "DSMX". However, there's also the near term potential of implementing the faster 11ms frame rate for DSM2 and DSMX modes, in which case I would suggest that the main protocol name could be split into three -- "DSM", "DSM2" and "DSMX" (two more items added to the current protocol list count) with the sub-mode then being simply either, "22ms" or "11ms". The latter would be disabled for the older "DSM" protocol, of course.
Happy to do the coding. Just need others to debate, agree or whatever.
Gruvin.
For example, "PPM16" is not actually what that label suggests. It is more like "PPM+8", since there's no hint in the name "PPM16" that the upper 8 channels will be pumped out a different port, whereas I think "+8" bears some suggestion of that. Directly related to that is the fact that the base channel count can be set anywhere from "4CH" to "16CH". I am guessing that this in fact refers to the primary PPM output channel count, to which the upper 8 channels are added, on the secondary output (trainer) port. Perhaps then, we should either restrict base channel count to maximum "8CH" for this "PPM+8" protocol -- or increase the available mixer channels to 24 (16+8), if that is even feasible.
For the DSM protocol, we currently have a main protocol label of "DSM2", with sub-modes "LP4/LP", "DSM2onl" and "DSMX", which doesn't really make much sense. (How can DSM2 also be LP4 or DSMX?) So I would vote for protocol name of just "DSM", with sub-modes "DSM1", "DSM2" and "DSMX". However, there's also the near term potential of implementing the faster 11ms frame rate for DSM2 and DSMX modes, in which case I would suggest that the main protocol name could be split into three -- "DSM", "DSM2" and "DSMX" (two more items added to the current protocol list count) with the sub-mode then being simply either, "22ms" or "11ms". The latter would be disabled for the older "DSM" protocol, of course.
Happy to do the coding. Just need others to debate, agree or whatever.
Gruvin.
Last edited by gruvin on Wed Dec 19, 2012 12:04 am, edited 1 time in total.
Re: Proposed changes to protocol labels
OKgruvin wrote:Perhaps then, we should either restrict base channel count to maximum "8CH" for this "PPM+8" protocol
I'd say DSM for protocol, and LP / DSM2 / DSMX for the variants (LP modules are also DSM2).gruvin wrote:So I would vote for protocol name of just "DSM", with sub-modes "DSM1", "DSM2" and "DSMX".
As far as I know, the modules that actually support that mode don't have the embedded processor like the low end modules, they just have the CYRF chip and its SPI interface, it's the radio's processor's job to handle the protocol, so no chance with the 9x.gruvin wrote:However, there's also the near term potential of implementing the faster 11ms frame rate for DSM2 and DSMX modes,
Re: Proposed changes to protocol labels
Not even the SKY9X's Arms processor can handle that?Kilrah wrote:As far as I know, the modules that actually support that mode don't have the embedded processor like the low end modules, they just have the CYRF chip and its SPI interface, it's the radio's processor's job to handle the protocol, so no chance with the 9x.gruvin wrote:However, there's also the near term potential of implementing the faster 11ms frame rate for DSM2 and DSMX modes,
- gruvin
- 9x Developer
- Posts: 131
- Joined: Tue Jul 24, 2012 10:02 pm
- Country: New Zealand
- Location: Auckland
- Contact:
Re: Proposed changes to protocol labels
At this point, I have to ask, "What is "LP" and "LP4" in the first place? I have never seen those labels used outside of open9x.Kilrah wrote:I'd say DSM for protocol, and LP / DSM2 / DSMX for the variants (LP modules are also DSM2).
I'd also like to point out that the labels on the transmitter should not refer to the mode of the transmitter module or what it is capable of -- but rather the mode of the RECEIVER to which this model set-up is targeting. From that point of view, as far as I know, the market has only ever known the terms, "DSM", "DSM2" and "DSMX" -- with receiver model designator such as AR6100 (DSM), AR6200 (DSM2) etc. I have never seen "LP" or "LP4" in any marketing literature. Have I missed something?
Interesting. Again, I have not seen personally noted any practical differences in "high end" versus "low end" modules, by which I presume you are in fact referring to high/low end radios they are installed in?As far as I know, the modules that actually support that mode don't have the embedded processor like the low end modules, they just have the CYRF chip and its SPI interface, it's the radio's processor's job to handle the protocol, so no chance with the 9x.
I have seen more wires than just serial data connected in most every case. For example, I used to assume that the DX7 (not 7s) needed more connections than just the PPM or serial input, since there are at least 5 more wires hooked up between the transmitter and the main PCBs. Moreover, that transmitter board is being sent PPM pulses -- not 125K serial -- though that same old module seems to work just fine with serial, none the less!
I was certain that all those extra wires must surely be needed to get DSMX mode working properly. If that is true though, no one told it to the DX4e. In the current "low end" DX4e radios, there is a DSMX module (so labelled) being sent only PPM pulses -- 90% sure -- just like my old DX7. But I have extracted that module from the DX4e and am using it happily with 125Kbps serial. It "just works".
Nowadays then, remarkably perhaps, I have come to believe that the extra connections -- like the SPI bus for example -- are mostly only there to facilitate firmware updates and probably some kind of factory/developer test modes.
In any case, when I look at the complete 1.11ms DSM2/X data frame at 125Kbps, relative to the present 22ms frame spacing, it seems to me there shouldn't be any problem simply pumping frames out at 11ms intervals instead. Here's what the data bursts look like at 22ms intervals. The fat white block in the bottom trace are each an entire 6-channel DSM2 frame ...
![Image](http://img687.imageshack.us/img687/5738/dsm2serial.png)
I admit that this is mostly academic, until I actually implement and test 11ms frames -- and I sure as heck have been wrong before. Fun discussion though.
![Razz :-P](./images/smilies/icon_razz.gif)
Gruvin.
Re: Proposed changes to protocol labels
It's for use with the modules scavenged from the LP "toy" transmitters that apparently had slightly different protocol / flags between the radio MCU and TX module than the high-power ones, even though the modules transmit DSM2. Spektrum doesn't exactly expect you to take their radios apart, so this "hidden" difference obviously doesn't appear anywhere in the literature. From what I understood this mode might not be needed for later LP modules, that among other things support model match while earlier ones didn't. Again a hidden change as it's irrelevant from the normal user's point of view.gruvin wrote:At this point, I have to ask, "What is "LP" and "LP4" in the first place? I have never seen those labels used outside of open9x. I'd also like to point out that the labels on the transmitter should not refer to the mode of the transmitter module or what it is capable of -- but rather the mode of the RECEIVER to which this model set-up is targeting. From that point of view, as far as I know, the market has only ever known the terms, "DSM", "DSM2" and "DSMX" -- with receiver model designator such as AR6100 (DSM), AR6200 (DSM2) etc. I have never seen "LP" or "LP4" in any marketing literature. Have I missed something?
DSM is obsolete, AFAIK DSM2 radios never even were backwards compatible with DSM RXs.
AFAIK modules > 6CH used SPI. Someone posted a photo of the innards of the modules, and there's only the RF chip, the processor that handles the communication in the lower end modules isn't there. On the DX8 for example there's definitely bidirectionnal communication, as the radio will tell you what mode the module decided to use to communicate to the receiver when binding.gruvin wrote:Interesting. Again, I have not seen personally noted any practical differences in "high end" versus "low end" modules, by which I presume you are in fact referring to high/low end radios they are installed in?
That certainly isn't a problem, however it doesn't guarantee the RF modukle actually transmits them and doesn't jsut wait for 22ms by itself.gruvin wrote:In any case, when I look at the complete 1.11ms DSM2/X data frame at 125Kbps, relative to the present 22ms frame spacing, it seems to me there shouldn't be any problem simply pumping frames out at 11ms intervals instead.
I must say the combinations of protocols and modes for Spektrum aren't that straightforward. For example things like setting DSMX does NOT guarantee DSMX operation, it only "allows" it if the receiver supports it. You can bind to a DSM2 RX in DSMX mode (the TX module will fall back to DSM2 if the receiver doesn't answer DSMX binding packets), and you can bind a DSMX RX in DSM2 mode as it too is backwards compatible.
- gruvin
- 9x Developer
- Posts: 131
- Joined: Tue Jul 24, 2012 10:02 pm
- Country: New Zealand
- Location: Auckland
- Contact:
Re: Proposed changes to protocol labels
I couldn't resist. I put of the work I'm supposed to be doing to test 11ms frame rate. It works.
DSM2/DSMonl mode at 11ms frame rate works perfectly -- and on an older, non-DSMX module, in fact. I didn't even have to rebind. As expected, it just works.
Amazing how much more responsive the servos seem. I didn't think it would be noticeable!
Bryan.
DSM2/DSMonl mode at 11ms frame rate works perfectly -- and on an older, non-DSMX module, in fact. I didn't even have to rebind. As expected, it just works.
Amazing how much more responsive the servos seem. I didn't think it would be noticeable!
Bryan.
Re: Proposed changes to protocol labels
Interesting!
- gruvin
- 9x Developer
- Posts: 131
- Joined: Tue Jul 24, 2012 10:02 pm
- Country: New Zealand
- Location: Auckland
- Contact:
Re: Proposed changes to protocol labels
I have proof read this over and over and keep finding mistakes and typos. But I've run out of time. So here it it. Apologies for errors / omissions / inaccuracies, in advance ...
Addendum: See the P.S; before you read the rest. My assertions below about DMS v1 based on binding with an old AR-6000 may be wrong -- or not. Can't find a way to know yet. *sigh* ...
As you know doubt know, the difference in the serial protocol between the so-called LP4/LP and DSMonl modes, is a single binary bit in the frame header. More importantly, what that bit does is tell the transmitter module to use the original DSM (v1) mode. I have an AR-6000 (park flyer, low range DSM v1) here and have just re-confirmed this fact. That is to say, as I said before, this "LP4/LP" thing is in fact "DSM" (v1) -- or at least 100% compatible with same.
To add to the prior confusion on this topic, it just so happens that up until recently (couple months or so, circa revision r1380ish) there was a bug in open9x's DSM2 code, such that ALL modes (LP4/LP, DSMonl and DSMX) chosen from the model SETUP menu were in fact sending the same protocol header. I forget which header was being sent. Perhaps it was DSM2, given you comments above -- about the DSM2 compatibility. Someone will recall.
Either way, right now I know with certainly that, "LP4/LP" mode works with my ancient AR-6000 receiver and, addressing your comment above to the contrary, does NOT bind with an AR-6200 DSM2 receiver. I have to be in "DSMonl" mode to get my AR-6100 and AR-6200 receivers to bind. Again, this may be a change since the aforementioned bug was resolved.
So in summary, I say that the three modes we currently have implemented are in fact, for all intents and purposes and certainly from a receiver-end or market-awareness perspective: DSM, DSM2 and DSMX.
I should ask though; are these RTF models from which the term LP4/LP came from actually labelled as such -- or is that an acronym we invented for our own use? (I live in a bubble and have never seen nor heard of such kits, just so you know. Sorry :-/)
I am not so sure that DSMX mode will fall back to DSM2 wither, in our specific case. Maybe some two-way communication is needed between the radio main board and the TX module to make that happen? Not in a position to test that just now either, sorry. But will later, some time.
Either way, the transmitter modules themselves definitely ARE backwards compatible with DSM v1 AR-6000 receivers, if you tell them to be (LP4/LP mode). That's why I want to change the name to something more people understand -- and which seems true -- simply, "DSM" -- unless there is actual wording on the product boxes reading, "LP4" or "LP", in which case that might make more sense. But there's no "LP" anything stamped on my AR-6000 receiver and lots of people probably still have those laying about.
Obviously, Spektrum didn't want to make different TX modules for different radios. Moreover. their most recent TX modules appear to be 100% backward compatible with all previous version, whether or not the radio they are installed in uses those mode or not. We get to benefit from that, hugely. Yay \o/
I can tell you that the low end DX4e radio I bought (and stupidly discarded afterwards) had a DSMX labelled module in it and that this same module works in all three modes, with only 125Kbps serial data. (I did keep the module of course!)
Cynically speaking, I suspect the only reason my DX7 does not use 125Kbps serial, was a marketing decision, where someone insisted that the data protocol be forced to go via regular old PPM, to ensure the radio could not perform like the high end models about to be released -- even though it could, if simply coded to do so. Or maybe they were just playing it safe and thought it too risky at the time, to use an unproven technology at the radio level, so they stuck with PPM, even though the module could already do the fancy new thing. Who knows. They'll never tell us, I'm sure.
What I do know is that a cheapie DX4e DSMX labelled TX module does all three modes (DSM/DSM2/DSMX) -- including 11ms frame rate, with nothing but power and 125Kbps serial data supplied to it. In fact, even my old DX6i (DSM2 only) module is doing 11ms frame rate just fine and as expected.
Far as I can see, everything else is just classic marketing or internet rumour, obfuscation.
Fair point. And I have not the equipment here right now to test packet transmission frequency at the RF level. All I can tell you is that servos responsiveness is subjectively, markedly better when I'm using 11ms. This was completely unexpected. I can only guess that the receiver literally updates the servo PWM signal more rapidly in this mode.
Someone clever please answer me this then; How might I test more "scientifically", to be sure I'm really getting 11ms updates out the end of the receiver, in 11ms transmit frame mode?
I have an analogue and a digital oscilloscope, and a logic analyser at my disposal. But I can't think of a way to track the PWM output-change/update frequency -- how often the duty cycle gets updated. In PPM mode, it's 22.5ms. In DSM2 mode, it ought to be 22ms. In 11ms DSM2/X, it ought to be 11ms. But is it, in this case, with this old DX6i module? I am guessing so. I see no reason why it wouldn't be. In fact, I believe it would be technically harder to make it not be so, than to just let it naturally be.
That said, there has certainly been a bunch of confusion in my mind, up until the past few days. Amazing what actual, physical testing will reveal -- and what rumours and even self-conjured B.S. can be dispensed with in the process.![Razz :-P](./images/smilies/icon_razz.gif)
HOWEVER! And this is the last biggie in my mind ... What I do not know for certain today, is whether or not DSMX mode in our case -- using only 125Kbps serial data -- is actually implementing the full, frequency agile features of DSMX. What I mean is, it could be that all the frequency agile extra stuff that DSMX does in a Spektrum radio is done by -- or at least configured during start-up by -- the main logic board. Maybe the main board has to do a bunch of stuff on that SPI link to scan frequencies and perform proper initialisation? Maybe without that, the DSMX module just sits on two channels, like DSM2? I highly doubt this. But we really need someone with a spectrum analyser to have a play about and confirm that our simple serial DSMX header, connected to a DSMX labelled module out of DX4e, does in fact implement the full frequency agile protocol.
There's also the existence of products like this from HorizonHobby, which I can only see as backing us up as good to go, just as things is.
EDIT: Oh dear ... see the P.S. below. It could change a lot of what I believed above ...
Gruvin.
P.S: My DX7 DSM2 radio *is* backward compatible with the AR-6000 DSM v1 receiver. Definitely. I only just remembered. Not sure how it does that, since DMSonl mode definitely does not bind with the AR-6000.
EDIT: No. I couldn't believe that to be true. So I just tried again, binding in "DSMonl" mode under open9x to the AR-6000 receiver. It took longer, but it did bind. So no extra communication is required for the backward compatibility to work with a DX6i TX module -- or a DX7 module, for that matter. It's clear now then that the module will bind in either LP$/LP --or-- DSMonl mode. I'm beginning to see confusion again. :-/
Does this mean that so called "LP" models will not bind with DSMonl mode? If so, it's another marketing thing, to be sure.
Addendum: See the P.S; before you read the rest. My assertions below about DMS v1 based on binding with an old AR-6000 may be wrong -- or not. Can't find a way to know yet. *sigh* ...
Err, umm ... that does not gel with my experience. I mean, I've not been down that specific path at all, but learned other things besides. Here's what I've learned ...Kilrah wrote:It's for use with the modules scavenged from the LP "toy" transmitters that apparently had slightly different protocol / flags between the radio MCU and TX module than the high-power ones, even though the modules transmit DSM2.
As you know doubt know, the difference in the serial protocol between the so-called LP4/LP and DSMonl modes, is a single binary bit in the frame header. More importantly, what that bit does is tell the transmitter module to use the original DSM (v1) mode. I have an AR-6000 (park flyer, low range DSM v1) here and have just re-confirmed this fact. That is to say, as I said before, this "LP4/LP" thing is in fact "DSM" (v1) -- or at least 100% compatible with same.
To add to the prior confusion on this topic, it just so happens that up until recently (couple months or so, circa revision r1380ish) there was a bug in open9x's DSM2 code, such that ALL modes (LP4/LP, DSMonl and DSMX) chosen from the model SETUP menu were in fact sending the same protocol header. I forget which header was being sent. Perhaps it was DSM2, given you comments above -- about the DSM2 compatibility. Someone will recall.
Either way, right now I know with certainly that, "LP4/LP" mode works with my ancient AR-6000 receiver and, addressing your comment above to the contrary, does NOT bind with an AR-6200 DSM2 receiver. I have to be in "DSMonl" mode to get my AR-6100 and AR-6200 receivers to bind. Again, this may be a change since the aforementioned bug was resolved.
So in summary, I say that the three modes we currently have implemented are in fact, for all intents and purposes and certainly from a receiver-end or market-awareness perspective: DSM, DSM2 and DSMX.
I should ask though; are these RTF models from which the term LP4/LP came from actually labelled as such -- or is that an acronym we invented for our own use? (I live in a bubble and have never seen nor heard of such kits, just so you know. Sorry :-/)
I am not so sure that DSMX mode will fall back to DSM2 wither, in our specific case. Maybe some two-way communication is needed between the radio main board and the TX module to make that happen? Not in a position to test that just now either, sorry. But will later, some time.
True, almost I think. Obviously we cannot buy discrete, branded DSM v1 receivers any more. But then how do we explain the above AR-6000 vs. LP4/LP insights, in terms of those cheapie RTF kits still available?DSM is obsolete, AFAIK DSM2 radios never even were backwards compatible with DSM RXs.
Either way, the transmitter modules themselves definitely ARE backwards compatible with DSM v1 AR-6000 receivers, if you tell them to be (LP4/LP mode). That's why I want to change the name to something more people understand -- and which seems true -- simply, "DSM" -- unless there is actual wording on the product boxes reading, "LP4" or "LP", in which case that might make more sense. But there's no "LP" anything stamped on my AR-6000 receiver and lots of people probably still have those laying about.
Obviously, Spektrum didn't want to make different TX modules for different radios. Moreover. their most recent TX modules appear to be 100% backward compatible with all previous version, whether or not the radio they are installed in uses those mode or not. We get to benefit from that, hugely. Yay \o/
Could be. I have only tested with 6 channels, to date. For the record though, my 7-channel AR-7200 works with only 6 channels being sent to the TX module. (It's in my Trex-500.) Since this is an aircraft application, I am sure the design engineers made the protocol as forgiving as they could. So I wouldn't mind betting that 7 or even 8 channels will work just fine. I figure we just need to adjust the header to tell the thing how many channels we're including. I see no need for SPI. That just doesn't make sense. There's no technical reason for it. 125Kbps is already silly fast, for this application. Sure though -- I don't know either, yet. Will soon.gruvin wrote:AFAIK modules > 6CH used SPI.
![Wink ;-)](./images/smilies/icon_e_wink.gif)
Never seen that. So cannot comment.Someone posted a photo of the innards of the modules, and there's only the RF chip, the processor that handles the communication in the lower end modules isn't there.
I can tell you that the low end DX4e radio I bought (and stupidly discarded afterwards) had a DSMX labelled module in it and that this same module works in all three modes, with only 125Kbps serial data. (I did keep the module of course!)
Even the original DX7 (no 'S') has bi-directional data going on, over a "mysterious extra ribbon cable" and it also has a separate, TX board chip, taking in the PPM signal and driving the TX module. HOWEVER, none of that is actually required for proper operation -- well, not with modules extracted from DX6i and DX4e radios anyway.On the DX8 for example there's definitely bidirectionnal communication, as the radio will tell you what mode the module decided to use to communicate to the receiver when binding.
Cynically speaking, I suspect the only reason my DX7 does not use 125Kbps serial, was a marketing decision, where someone insisted that the data protocol be forced to go via regular old PPM, to ensure the radio could not perform like the high end models about to be released -- even though it could, if simply coded to do so. Or maybe they were just playing it safe and thought it too risky at the time, to use an unproven technology at the radio level, so they stuck with PPM, even though the module could already do the fancy new thing. Who knows. They'll never tell us, I'm sure.
What I do know is that a cheapie DX4e DSMX labelled TX module does all three modes (DSM/DSM2/DSMX) -- including 11ms frame rate, with nothing but power and 125Kbps serial data supplied to it. In fact, even my old DX6i (DSM2 only) module is doing 11ms frame rate just fine and as expected.
Far as I can see, everything else is just classic marketing or internet rumour, obfuscation.
[/quote]That certainly isn't a problem, however it doesn't guarantee the RF module actually transmits them and doesn't just wait for 22ms by itself.gruvin wrote:In any case, when I look at the complete 1.11ms DSM2/X data frame at 125Kbps, relative to the present 22ms frame spacing...
Fair point. And I have not the equipment here right now to test packet transmission frequency at the RF level. All I can tell you is that servos responsiveness is subjectively, markedly better when I'm using 11ms. This was completely unexpected. I can only guess that the receiver literally updates the servo PWM signal more rapidly in this mode.
Someone clever please answer me this then; How might I test more "scientifically", to be sure I'm really getting 11ms updates out the end of the receiver, in 11ms transmit frame mode?
I have an analogue and a digital oscilloscope, and a logic analyser at my disposal. But I can't think of a way to track the PWM output-change/update frequency -- how often the duty cycle gets updated. In PPM mode, it's 22.5ms. In DSM2 mode, it ought to be 22ms. In 11ms DSM2/X, it ought to be 11ms. But is it, in this case, with this old DX6i module? I am guessing so. I see no reason why it wouldn't be. In fact, I believe it would be technically harder to make it not be so, than to just let it naturally be.
Hmmm. I'm not sure I see any lack of clarity, nowadays anyway. I mean, we obviously know what receiver we are using, right? Seems a simple nicety to have backward compatibility in both directions, for equally obvious reasons.I must say the combinations of protocols and modes for Spektrum aren't that straightforward. For example things like setting DSMX does NOT guarantee DSMX operation, it only "allows" it if the receiver supports it. You can bind to a DSM2 RX in DSMX mode (the TX module will fall back to DSM2 if the receiver doesn't answer DSMX binding packets), and you can bind a DSMX RX in DSM2 mode as it too is backwards compatible.
That said, there has certainly been a bunch of confusion in my mind, up until the past few days. Amazing what actual, physical testing will reveal -- and what rumours and even self-conjured B.S. can be dispensed with in the process.
![Razz :-P](./images/smilies/icon_razz.gif)
HOWEVER! And this is the last biggie in my mind ... What I do not know for certain today, is whether or not DSMX mode in our case -- using only 125Kbps serial data -- is actually implementing the full, frequency agile features of DSMX. What I mean is, it could be that all the frequency agile extra stuff that DSMX does in a Spektrum radio is done by -- or at least configured during start-up by -- the main logic board. Maybe the main board has to do a bunch of stuff on that SPI link to scan frequencies and perform proper initialisation? Maybe without that, the DSMX module just sits on two channels, like DSM2? I highly doubt this. But we really need someone with a spectrum analyser to have a play about and confirm that our simple serial DSMX header, connected to a DSMX labelled module out of DX4e, does in fact implement the full frequency agile protocol.
There's also the existence of products like this from HorizonHobby, which I can only see as backing us up as good to go, just as things is.
EDIT: Oh dear ... see the P.S. below. It could change a lot of what I believed above ...
Gruvin.
P.S: My DX7 DSM2 radio *is* backward compatible with the AR-6000 DSM v1 receiver. Definitely. I only just remembered. Not sure how it does that, since DMSonl mode definitely does not bind with the AR-6000.
EDIT: No. I couldn't believe that to be true. So I just tried again, binding in "DSMonl" mode under open9x to the AR-6000 receiver. It took longer, but it did bind. So no extra communication is required for the backward compatibility to work with a DX6i TX module -- or a DX7 module, for that matter. It's clear now then that the module will bind in either LP$/LP --or-- DSMonl mode. I'm beginning to see confusion again. :-/
Does this mean that so called "LP" models will not bind with DSMonl mode? If so, it's another marketing thing, to be sure.
- gruvin
- 9x Developer
- Posts: 131
- Joined: Tue Jul 24, 2012 10:02 pm
- Country: New Zealand
- Location: Auckland
- Contact:
Re: Proposed changes to protocol labels
Sorry about the added confusion from my previous long post. Here, I just want to list what I know for sure and what I'm now not sure of. It will be just that, a list.
Gruvin.
- My AR-6000 DSM (park-flier) receiver binds with a DX6i TX module in either (open9x) LP4/LP or DSMonl modes -- the latter taking a little longer.
- I no longer know if LP4/LP mode is another name for the old DMS v1 protocol or not -- that is, whether it places the TX module in a DSM v1 compatible mode. It appeared that way when LP4/LP mode successfully bound (quickly) with my AR-6000. But it might be just the TD module automatically falling back to DSM v1 on its own accord.
- LP4/LP mode (with a DX6i module) does not bind with AR-6100, AR-6200 or AR-7200 DSM2 receivers. DSMonl mode does.
- 11ms frame rate on the 125Kbps serial port at the transmitter end definitely works (DSMonl mode, DX6i module) and seems more responsive. But the latter is only a subjective observation. Thus ...
- I do not known if 11ms frame rates actually translate to the servos at the receiver end
- I do not know if DSMonl mode also happens to work with LP4/LP models. If so, it would seem we have no practical need for LP4/LP mode since DSMonl works with DSM v1 receivers -- UNLESS it is required to get LP4/LP kit sourced TX module to transmit in DSM2 mode?
- it is not known if our implementation of DSMX mode actually fulfils the complete, frequency agile protocol without extra communication over wires we do not have connected.
- I have been told but do not know from first hand experience that our implementation of DSMX mode, using only 125Kbps serial data does work (in some manner or another) with the new DSMX receivers.
- My claimed DX6i module might be a DX5i module or even neither. Its label does not help.
Gruvin.
Re: Proposed changes to protocol labels
The RTF models, at least the current ones, they say they can be bound to "DSM2/DSMX" radios. So those LP modules supposedly would still bind to DSM2 receivers even in LP mode, so it wouldn't match the "Force DSM" idea.gruvin wrote:I should ask though; are these RTF models from which the term LP4/LP came from actually labelled as such -- or is that an acronym we invented for our own use?
IMO the LP2/LP4 name in open9x comes from whoever has first looked at how to talk to those DSM modules, who found that the ones from the LP toy radios received a different flag from their radio, and labelled it as such having no idea what it actually was for.
No, because the DX4e doesn't even have the "other" pins to the module connected as fas as I remember when taking mine apart. It only has the serial wire we use, and sends the same signal we do. So the radio tells the module to use either DSMX with fallback to DSM2 (our DSMX mode) or DSM2 only, and then the module does everything by itself thanks to that extra processor in there.gruvin wrote:I am not so sure that DSMX mode will fall back to DSM2 wither, in our specific case. Maybe some two-way communication is needed between the radio main board and the TX module to make that happen?
Even the DX8 doesn't have a "forced DSMX" mode, it's labelled DSMX but you can bind a DSM2 receiver in that mode, the only difference is that thanks to the more advanced communication it will tell you what mode it has effectively bound in.
Here's a DX4e module, shows the serial pin we use going to a processor in there:Someone posted a photo of the innards of the modules, and there's only the RF chip, the processor that handles the communication in the lower end modules isn't there.
And this is my "higher end" module from a Spektrum DM9 I intended to use at first, but that didn't work: No processor. There is a processor on its carrier board though, and the communication is bidirectionnal for sure as the LED won't do the same things when the module is there or when it's disconnected.
Nah, they likely just did the same everybody else did at the time, they took an existing PPM radio and slapped their module in there as an interim solution to sell some and see how it worked before they could supply their own fully fledged radios.gruvin wrote:I suspect the only reason my DX7 does not use 125Kbps serial, was a marketing decision, where someone insisted that the data protocol be forced to go via regular old PPM, to ensure the radio could not perform like the high end models about to be released -- even though it could, if simply coded to do so. Or maybe they were just playing it safe and thought it too risky at the time, to use an unproven technology at the radio level, so they stuck with PPM, even though the module could already do the fancy new thing. Who knows. They'll never tell us, I'm sure.
Graupner for example did that again only 2 years ago, seeing 35MHz radios didn't sell anymore they quickly threw their 2.4GHz modules on a PPM-serial converter board, and integrated that in their old radios without changing anything else to clear the stocks and give them time to finish the successor. Then a year later they came up with the new generation of radios where the module was integrated "natively".
When I integrated my DX4e module in my 9x I noticed that packet transmission created short, but rather important voltage drops on the supply lines. I'd just scope the module's power supply and look if the spikes get closer when you reduce the frame period. That should tell if it's actually sending more RF packets or not.gruvin wrote:Fair point. And I have not the equipment here right now to test packet transmission frequency at the RF level. All I can tell you is that servos responsiveness is subjectively, markedly better when I'm using 11ms. This was completely unexpected. I can only guess that the receiver literally updates the servo PWM signal more rapidly in this mode.
Well firstly look with a scope whether the servo signals actually change between 11ms and 22ms periods when you change it on the radio. Then if yes and if you want to be sure those 11ms orders are really all different (not like frsky who just repeat the same order twice in HS mode) you could make a special 9x firmware that sends significantly different servo pulses on every cycle on one channel. Then record that channel output with the logic analyser and check that each servo pulse is indeed different and mathces the pattern you've programmed.gruvin wrote:Someone clever please answer me this then; How might I test more "scientifically", to be sure I'm really getting 11ms updates out the end of the receiver, in 11ms transmit frame mode?
I have an analogue and a digital oscilloscope, and a logic analyser at my disposal. But I can't think of a way to track the PWM output-change/update frequency -- how often the duty cycle gets updated. In PPM mode, it's 22.5ms. In DSM2 mode, it ought to be 22ms. In 11ms DSM2/X, it ought to be 11ms.
I have a spectrum analyzer so I could check, but the problem is I don't have a DSMX receiver. And as DSMX mode falls back to DSM2 if it doesn't get an answer from a DSMX receiver during binding - I don't have a way to make the module put out DSMX so I can look at it.gruvin wrote:HOWEVER! And this is the last biggie in my mind ... What I do not know for certain today, is whether or not DSMX mode in our case -- using only 125Kbps serial data -- is actually implementing the full, frequency agile features of DSMX
- gruvin
- 9x Developer
- Posts: 131
- Joined: Tue Jul 24, 2012 10:02 pm
- Country: New Zealand
- Location: Auckland
- Contact:
Re: Proposed changes to protocol labels
@Kilrah -- Great reply. Thanks!
I also noticed the voltage spikes you mentioned. Good idea! Right now, I don't even know if the transmitter mirrors the input data frame timing at the RF stage or not. That could well be entirely asynchronous. But monitoring the power draw on the scope will indeed answer that question, swiftly. Then the question about 22ms versus 11ms being reflected at the RF level may be valid and will be a piece of cake to have answered.
Thanks for the idea of writing some code to move a phantom servo at a rapid enough pace and then using the logic analyser to view adjacent PWM pulses from the receiver. These are the types of ideas that take me months to come up. I mean, I didn't even think of using the logic analyser with some debug code to get these recent timing measurements until just a week or so back -- despite endlessly wishing there was some way to see it all in real time.
Anyway, I'll endeavour to do this servo movement thing soon, so we can know for sure what's going on -- at least with the module I'm currently using and later the DX4e DSMX module. (The latter is tied up, waiting for a PCB, to do with another thing I'm doing.)
OK about not having a DSMX receiver. Same here. All that end of things can wait until some other rainy day, then.
Oh and, I'll have to take the lid off my old DX7 TX module some time. There's a separate CPU on its TX carrier board too, so having seen your pictures and what not, I'd not be surprised to see no "helper chip" in there either.
In the end, we just might have to reverse engineer the SPI bus communications (if it is an SPI bus.) I can't recall off the top of my head if there's a second SPI port available anywhere on our ever-more-taxed little ATmega2560 chip. For simple, "what binding mode did you end up in?" type queries, we could multiplex the SD-card SPI port easily enough. But we can't be using that port for high speed, mission critical functions -- well not if we want to be logging telemetry to SD storage at the same time, anyhow. If things come down to that question though, I think I just remind myself that I never had a problem with 22ms framing in the past and so I shouldn't care a rats now, either.![Razz :-P](./images/smilies/icon_razz.gif)
I did hear a rumour that there was an all powerful ARM Cortex based logic board out there somewhere. I bet it could manage the task.
Gruvin.
P.S: Real busy next few days. Might not get a chance to check in.
I also noticed the voltage spikes you mentioned. Good idea! Right now, I don't even know if the transmitter mirrors the input data frame timing at the RF stage or not. That could well be entirely asynchronous. But monitoring the power draw on the scope will indeed answer that question, swiftly. Then the question about 22ms versus 11ms being reflected at the RF level may be valid and will be a piece of cake to have answered.
Thanks for the idea of writing some code to move a phantom servo at a rapid enough pace and then using the logic analyser to view adjacent PWM pulses from the receiver. These are the types of ideas that take me months to come up. I mean, I didn't even think of using the logic analyser with some debug code to get these recent timing measurements until just a week or so back -- despite endlessly wishing there was some way to see it all in real time.
![Embarrassed :oops:](./images/smilies/icon_redface.gif)
OK about not having a DSMX receiver. Same here. All that end of things can wait until some other rainy day, then.
Oh and, I'll have to take the lid off my old DX7 TX module some time. There's a separate CPU on its TX carrier board too, so having seen your pictures and what not, I'd not be surprised to see no "helper chip" in there either.
In the end, we just might have to reverse engineer the SPI bus communications (if it is an SPI bus.) I can't recall off the top of my head if there's a second SPI port available anywhere on our ever-more-taxed little ATmega2560 chip. For simple, "what binding mode did you end up in?" type queries, we could multiplex the SD-card SPI port easily enough. But we can't be using that port for high speed, mission critical functions -- well not if we want to be logging telemetry to SD storage at the same time, anyhow. If things come down to that question though, I think I just remind myself that I never had a problem with 22ms framing in the past and so I shouldn't care a rats now, either.
![Razz :-P](./images/smilies/icon_razz.gif)
I did hear a rumour that there was an all powerful ARM Cortex based logic board out there somewhere. I bet it could manage the task.
![Wink ;)](./images/smilies/icon_e_wink.gif)
Gruvin.
P.S: Real busy next few days. Might not get a chance to check in.
Re: Proposed changes to protocol labels
This has already been done. Some guys already managed to fully emulate the entire Spektrum TX module using jsut a microcontroller talking via SPI to the CYRF6936 RF chip on a devboard. We wouldn't even need an original Spektrum module anymore. HK already marketed a "compatible" DSM2/DSMX module a couple of weeks ago (here).gruvin wrote:In the end, we just might have to reverse engineer the SPI bus communications (if it is an SPI bus.)
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: Proposed changes to protocol labels
Hi,
Sorry for jumping in late to this topic. Perhaps I can clarify a couple of points, since I wrote the menu items in question and did some of the work getting the DSM2 modes working properly.
(Once I figured out what we needed, Mike's awesome interrupt handler was the final piece of the puzzle )
"LP" refers to the low power modules from the Vapor/Ember class RTF stuff, and also the LP5DSM2 transmitter. They use a 0x00 as the first byte of the header.
It might be unnecessary however, because they seem to ignore that byte altogether.
I left it in for "completeness" since my goal was to have ER9X emulate the donor transmitters as closely as possible.
The rest of the descriptions come from the manual for the Dx4e that describe its operating modes.
11 msec works fine with receivers that support it, mainly the DSMx ones. It also works fine with the MCPx.
( I actually use a very old version of the firmware just for that because I put the 11msec mode in there.)
If you try it with a receiver that puts out its pulses sequentially then it gets confused. There is not always enough time to get them all out before the next set arrive and the servos will stutter.
Never got around to submitting it to be included in the released versions of the code.
My concern was that it caused unpredictable performance with most DSM2 receivers. Could seem to work, then cause a crash.
And finally calling the main mode DSM2 is inaccurate, but DSM alone would be worse (since that is completely different ) and DSM"x" means something else, so I went with DSM2![Smile :)](./images/smilies/icon_e_smile.gif)
Perhaps it could be changed it to "SPEK"![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Pat MacKenzie
Sorry for jumping in late to this topic. Perhaps I can clarify a couple of points, since I wrote the menu items in question and did some of the work getting the DSM2 modes working properly.
(Once I figured out what we needed, Mike's awesome interrupt handler was the final piece of the puzzle )
"LP" refers to the low power modules from the Vapor/Ember class RTF stuff, and also the LP5DSM2 transmitter. They use a 0x00 as the first byte of the header.
It might be unnecessary however, because they seem to ignore that byte altogether.
I left it in for "completeness" since my goal was to have ER9X emulate the donor transmitters as closely as possible.
The rest of the descriptions come from the manual for the Dx4e that describe its operating modes.
11 msec works fine with receivers that support it, mainly the DSMx ones. It also works fine with the MCPx.
( I actually use a very old version of the firmware just for that because I put the 11msec mode in there.)
If you try it with a receiver that puts out its pulses sequentially then it gets confused. There is not always enough time to get them all out before the next set arrive and the servos will stutter.
Never got around to submitting it to be included in the released versions of the code.
My concern was that it caused unpredictable performance with most DSM2 receivers. Could seem to work, then cause a crash.
And finally calling the main mode DSM2 is inaccurate, but DSM alone would be worse (since that is completely different ) and DSM"x" means something else, so I went with DSM2
![Smile :)](./images/smilies/icon_e_smile.gif)
Perhaps it could be changed it to "SPEK"
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Pat MacKenzie
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: Proposed changes to protocol labels
One more comment - some have suggested that the Orange module makes the DSM2 mod obsolete .
With respect i disagree. So far there is no sign that it works properly, or that it has FCC/CE approval.
The DX4e module is a known quantity, has FCC numbers, is inexpensive and works perfectly with ER9X.
Ditto for any sort of DIY Spek module. To me you are then treading on dangerous ground that could affect not only you but others.
Pat MacKenzie
With respect i disagree. So far there is no sign that it works properly, or that it has FCC/CE approval.
The DX4e module is a known quantity, has FCC numbers, is inexpensive and works perfectly with ER9X.
Ditto for any sort of DIY Spek module. To me you are then treading on dangerous ground that could affect not only you but others.
Pat MacKenzie
- gruvin
- 9x Developer
- Posts: 131
- Joined: Tue Jul 24, 2012 10:02 pm
- Country: New Zealand
- Location: Auckland
- Contact:
Re: Proposed changes to protocol labels
Very helpful.
I had confirmed that 11ms framing seemed to work here, on the bench, using both an older DSM2 and DX4e modules -- and also translated to faster updates at the receiver end. But I never got around to running lengthy reliability tests and thus didn't post anything about it yet. So that information is especially valuable for me. Thanks.
Re the label naming, open9x changed (I presume) DSM2 to DSMonl (DSM only), which IMHO makes no sense at all. "DSM only", as opposed to "DSM" and, "what else?"
Given that we also have DSMX as a separate selection (for reasons now better understood) I would prefer to see this changed back to DSM2 -- and leave LP/LP4 as it is.
(I am assuming the "LP5DSM2" reference was a typo, regarding the "5".)
Merry Christmas All.
I had confirmed that 11ms framing seemed to work here, on the bench, using both an older DSM2 and DX4e modules -- and also translated to faster updates at the receiver end. But I never got around to running lengthy reliability tests and thus didn't post anything about it yet. So that information is especially valuable for me. Thanks.
Re the label naming, open9x changed (I presume) DSM2 to DSMonl (DSM only), which IMHO makes no sense at all. "DSM only", as opposed to "DSM" and, "what else?"
Given that we also have DSMX as a separate selection (for reasons now better understood) I would prefer to see this changed back to DSM2 -- and leave LP/LP4 as it is.
(I am assuming the "LP5DSM2" reference was a typo, regarding the "5".)
Merry Christmas All.
Re: Proposed changes to protocol labels
AFAIK it's "DSM2onl" for "DSM2 only". The reason is that the "DSMX" mode is actually "Auto DSMX/DSM2". I.e. when choosing DSMX you can't guarantee nor know which mode it will actually bind in. "DSM2onl" is however DSM2 for certain.gruvin wrote:Re the label naming, open9x changed (I presume) DSM2 to DSMonl (DSM only), which IMHO makes no sense at all. "DSM only", as opposed to "DSM" and, "what else?"
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: Proposed changes to protocol labels
No typo, LP5DSM2 was one of the early donor transmitters, Low Power, 5 channels DSM2 operation. Sold with the CX2 I think.
(Sometimes called LP5DSM, but it is of course a DSM2 transmitter, not a DSM one)
Correct, it is DSM2 only, and DSM2/DSMX auto select. The modes come from the DX4e manual, page 8
http://www.spektrumrc.com/ProdInfo/File ... Manual.pdf
They give only one reason in the manual for using "DSM2 on" (which I called "DSM2 Only" because it better describes it),
but for our purposes a better reason is that it forces all receiver types to bind in DSM2 mode.
If you have a mix of DSM2 and DSMX receivers it will save rebinding when you switch between types. Unlike a real Spektrum transmitter the module becomes set to the last type used.
DSM2 is fine if you are flying alone or in small groups. You really only need DSMX if you are flying in huge events, and you could easily switch to that mode and rebind.
Pat MacKenzie
(Sometimes called LP5DSM, but it is of course a DSM2 transmitter, not a DSM one)
Correct, it is DSM2 only, and DSM2/DSMX auto select. The modes come from the DX4e manual, page 8
http://www.spektrumrc.com/ProdInfo/File ... Manual.pdf
They give only one reason in the manual for using "DSM2 on" (which I called "DSM2 Only" because it better describes it),
but for our purposes a better reason is that it forces all receiver types to bind in DSM2 mode.
If you have a mix of DSM2 and DSMX receivers it will save rebinding when you switch between types. Unlike a real Spektrum transmitter the module becomes set to the last type used.
DSM2 is fine if you are flying alone or in small groups. You really only need DSMX if you are flying in huge events, and you could easily switch to that mode and rebind.
Pat MacKenzie