Originally Posted by printk

Eventually I find out the secret. The MCPX receiver using a modify
sequence when it is seeking the alignment with the TX jumping
sequence. In this seeking mode, it is alternative channel in the
sequence is 11th apart. In other word, if I skip every other channel
in the seeking mode, I will get the jumping sequence in the receiving
mode. In the seeking mode, the receiver run 2 threads at half the
speed of the normal sequence.

Sorry, I thought I'd mentioned this before. You need to capture every other channel value (which you have discovered)

No problem. I think even if you mention it, I would have forgot it and
rediscover it any way. Until I actually looking at the trace, I haven't
no idea what every other channel you are talking about

I add a few feed back and resume capability to the system. The RPi
can detect the receiver receive the bind packet then move to the next
stage faster. It can also detect the receive get stuck and retry the binding
process. It have very rare but it does happen and pause the system
if I don't handle it.

I also add the range script and ability to resume from the previous
working progress if I stop and program and start it again. It is necessary
to stop the probing if I need to test bind on my own heli in the house.

I update a zip file contain almost 4 thousand entries. More data point.
I think I might actually able to hit the erase cycle limit on that poor
receiver chip if I running it none stop. I am pretty happy with my current
setup now. RPi takes very few power to run.

Originally Posted by printk

More data point.
I think I might actually able to hit the erase cycle limit on that poor
receiver chip if I running it none stop. I am pretty happy with my current
setup now. RPi takes very few power to run.

Have you checked whether it actually saves the binding data if it never sees any channel data? I can't confirm at the moment, but I seem to recall that it would not start scanning from the last bind unless it had previously completed the sequence by seeing channel data. Or it may be because I am probing a Satellite and the main Rx is broken and will not actually complete binding.

You might be right about the receiver chip only write eeprom if it see realy
channel data. I have to go back to see the LA trace to verify it tonight.

That is right. If the RX did not receive channel data. The next time it does not follow
the previous not successful bind. It make sense to me now, if the RX has a bad
binding process. It should not abandon the last known good one otherwise the
RX might not bind to any thing.

Get to 4K entries now.

I collect a little more than 10K of guid samples.
I just want to find out how random is there sequence.

Now just a distribution of channel shows.

It is clear that between 29 - 51, channel are less often used.
The green line is the random selection. The blue line are DSMX
channel distribution. It is pretty close to even, the dip is likely
cause by the algorithm. That give us hint that DSMX channel
is not selected as paranoid as it can be. It is likely using some
simpler but not perfect random way to make the sequence.

interesting

I think I am on to some thing.

Notice that the channel range is 3 - 75. There are 37 odd channel
and 36 even channel. So I redraw the distribution graph separate
out the even and odd channel. That make the graph much smoother.

Here is what I get, the blue line is even channel. The green on is odd
channel.



The questions is, what kind of method was used to result in that
kind of the distribution?

Notice that the distribution graph have 3 separate bar. It is pretty
flat within the bar. So my guess is that, the channel selection is
using segmented selection.
The channel is split into 3 zone: low, mid and high.
odd channel: 3-27, 29-51 , 53-75
even channel: 4-26, 28-50, 52-74

So out of the 23 channel, 23 can't divided by 3. So that will
explain the middle dip. My guess was that, 8 was coming from
low, 7 was coming from mid, 8 was coming from high.

I just run a program to verify that. YES! All the channel selection
match the [8,7,8] distribution in the 3 zone. There is no
exceptions in my 28K guid samples! I think Spectrum want
to spread the 23 channel selection, not clump into same zone.

More interesting stuff.

So it seems that DSMX channel selection have some rules to split it into
3 zones. It select [8,7,8] channels from [low, mid, high]. I think it is likely
DSMX first select channel then decide how to shuffle the channel from
the selected group.

Following this idea. I want to find out what is the 2D distribution of the
channel. In other words, if I give a channel X, what is the distribution of the
next jumping channel that following X.
Now we are only concern of the 23 channel, how it is arranged.
I make a transform to map each channel to it's order number.

e.g.

[75, 63, 69, 35, 51, 17, 41, 15, 49, 11, 27, 25, 39, 61, 71, 5, 43, 29, 7, 3, 73, 65, 57]

Will map into:

[22, 17, 19, 9, 14, 5, 11, 4, 13, 3, 7, 6, 10, 16, 20, 1, 12, 8, 2, 0, 21, 18, 15]

Notice the order of first channel "75" is 22, because 75 is the biggest channel.
Channel "3" will map into 0, it is the smallest channel.

This will get rid of the uneven distribution on channel selection.
We only concern about how channel are re-arranged.

So the 2D distributions, after the remapping, it looks like this:

I am using color to represent the distribution value. Hotter the color
means higher the distribution. The diagonal line is blue means,
no channel will repeat itself (stay in the same channel without jumping).

This distribution has very straight lines! Again, it match the [8,7,8]
zone division. That tells us, there is a higher level decision to be
make to let channel stay into the same zone vs jump to a different
zone. Other than this decision, the distribution seems pretty flat.

By the time we are done we will have applied more of the scientific method to this problem than they wever did. Id they wanted to achieve optimal usage they should have produced a flat distribution graph.

Hasn't hammer22 got a working DSMX transmitter module? If so, then it's probably unlikely that he's decapped a Spektrum microcontroller and hacked it to dump its firmware...

I've only just started reading through this thread and the Cypress chip is new to me. Also I don't have any Spektrum kit to play around with myself.

Keep up the good work guys though!

Si.

My guess is that, hammer22 got a working DSMX by using a present
DSMX sequence. The hard part of this problem is how to map a GUID
to a jumping sequence. However, if you are only building one TX and use
one GUID at a time. You can using the SPI bus sniffer one the receiver to
discover the jumping sequence for that GUID. Then you just hard code the
jumping sequence in TX. That way you can walk around the harder problem
of how to map ANY GUID to a jumping sequence.

If we preset the GUID in firmware, that comes to a problem that the preset
GUID is limited, you might run into another TX in the field with same GUID.
Then that is really bad. My guess is that, Hammer22 can avoid it by assign
a different GUID for each TX module he sell.

The receiver are relative cheap. You can also use the MCPX/MQX 3 in 1
board to play with the receiver. That is what I did any way because I have
a few busted MCPX board in hand.

Originally Posted by SimonChambers

Hasn't hammer22 got a working DSMX transmitter module? If so, then it's probably unlikely that he's decapped a Spektrum microcontroller and hacked it to dump its firmware...

I've only just started reading through this thread and the Cypress chip is new to me. Also I don't have any Spektrum kit to play around with myself.

Keep up the good work guys though!

Si.

Originally Posted by printk

My guess is that, hammer22 got a working DSMX by using a present DSMX sequence.

Yes, this is my understanding. We already have all the info needed to build a DSMx transmitter, but If you want to build a DSMX receiver, you need to actually figure out the GUID->sequence mapping though. To my knowledge no one has done this as yet.

Well, printk has nailed exactly what I do. I started doing some of what he has done to analyze the frequency hopping pattern and quickly came to the conclusion that it was far beyond my skills and available time to try and reverse engineer the Spektrum DSMX frequency hopping algorithm. So, I just sniff on the receivers hopping pattern to come up with the correct pattern to use for a given GUID. The chances of two transmitters using the same hopping pattern, whether they're an actual spektrum product or one of my modules is astronomical, IMHO.

I lose a walkera TX module due to the experiment.
I think I left it on for too long or some thing. It was collecting
the sequence fine, running for a few days. After it complete the
64K sample and program exit. I find out it is not working any
more the other day.

Long story short. I guess it is the FET that switch the antenna
circuit or the amplify circuit was bad. So I open up the TX
module metal casing. Break the circuit right before entering
the FET. Instead I solder a short wire as antenna.

It actually works. I don't have power amplify any more, but
it can bind to DSM2 receiver. For this test, I don't need to
amplify the TX signal any way because the receiver is very
close. I actually prefer no amplifier because I don't want to
interference with my other heli binding.

So I salvage a $10 part. Here is the picture where I solder
the antenna