Proto X SLT bind issues

I just installed my nRF24L01 this weekend and was able to bind my Syma X11 to test that it is working, but I haven't had any luck with my Proto X SLT. Is there anything special I need in the model.ini to test it? I think I just took an old Proto X ini and added "PROTOCOL=SLT", is this correct?

Also I note that when I turn on my Devo 7e with a Hubsan X4 model.ini loaded it immediately says "Binding Hubsan X4, press ENT to stop" or something like that. With the Syma X11 model.ini it also does this when I turn on the Devo 7e. But with the Proto X SLT model.ini it does not automatically try to bind. Is this related to my problems?

Has anyone been able to bind the Proto X SLT? Got an ini file?

Tonight I learned that if you turn the quad on, and shake it a few times, it goes into bind mode (the leds start flashing). Then if I turn on my Devo 7e with my SLT ini, it seems to bind (the leds immediately stop flashing). So there is some kind of communication going on, but then it doesn't respond to any stick inputs.

Any ideas where the problem is?

What does your Tx do while you're doing this? My Proto X (the non-SLT version) will do this as well if I do what you're doing. But the Tx never leaves the bind box, and it clearly isn't transmitting.

I get around this by turning on the Tx first, letting it say it's binding, then turning on the quad. If your Tx is behaving like mine, you might try this order and see what happens.

Today I got it to bind fully!

(1) Bind it to stock transmitter
(2) Shake quad for 2-3 seconds until LEDs blink
(3) Turn on Devo w/ SLT ini file preloaded

Success! Now I think I just need a proper INI file with the channels mapped properly (anyone got one already?), and some thoughts from you guys on why it won't bind normally and why this is strange procedure would be necessary (no other method seems to work for me, it must be rebound to the stock transmitter every time before you can bind it to the Devo). Is it the quad, or is it Deviation?

Here's a video of me showing the bind procedure and some other strangeness:

I got it to bind to my Devo 6S as well.

I think it's an issue with the model.ini file not having the right channel assignments. It won't bind to the stock Tx if the throttle isn't -100, which is a pretty common behavior. You found a way around that, but if you then turn things off and back on, it won't pay attention to the throttle.

I'll poke at this more later tonight.

mwm wrote: It won't bind to the stock Tx if the throttle isn't -100, which is a pretty common behavior. You found a way around that

You're right! That's all it was! I reversed a few channels and now I can bind normally and it's flying beautifully! Best flight with a nano sized quad that I've ever had!!!

I'm a complete noob with ini files, but here's mine so far. Let me know if you improve anything.

Well, I got it to work better with my 6S. I copied the model file for my non-SLT Proto X, changed the protocol to SLT, and then reversed all the channels as indicated in your model.ini file.

Seems like there's a delay between moving a stick and the quad responding. For instance, I give it full right rudder, and it'll start spinning late, and then I center it, and it keeps spinning for a beat or And it takes a LOT of throttle before it spins up the motor. I get the same behavior using your model file. Hobbico believes my Proto X SLT is defective, so this may be a symptom of that. Especially if yours doesn't do that!

I've only flown it a few times since getting it to bind, but I think I may have noticed a little bit of the 'delay' that you are describing. But for me it is very intermittent and only affects me for maybe 3-4 seconds in total of a 4 minute flight, mostly the quad seems to fly really well.

But... once and a while, I think I feel it stop responding for a second or less, like there is a delay, or the signal has cutout, or I'm out of range. I was wondering if it's my antenna or the solder job on my nRF24L01 since this is the first time I've really tested it but I guess not if you're seeing similar behavior. Are your 'delays' just for a second or so every once and a while?

I'll fly it some more tomorrow and try to figure out how often it's happening.

Mine is consistently that way. And I'd be surprised if the delay was less than a second - it certainly seems to be somewhere between one and two.

I've been promised a replacement in about a month, when they have them in stock again.

I flew some more today and got more familiar with the problem. It doesn't sound like the same one you are having. For example, on my last flight, I experienced loss of control exactly 4 times, each time for less than a second. Often it is recoverable or happens so fast that you don't really notice. To me it seems like the signal is cutting out, or that the protocol is slightly delayed once and a while and trying to play catch-up.

I know the quad flies perfectly with the stock tx (how about yours?) so I'm pretty sure the problem is with Deviation or my nRF24L01. I have a couple more quads coming that use the nRF24L01 then I'll be able to narrow it down more.

It would be helpful if someone else on these forums could confirm they use the SLT protocol without issue.

On the RTF Tx, mine flies like you describe yours as flying. Mostly seems fine, but every once and a while it'll fail to respond for just long enough to notice.

New one arrived. It behaves exactly the same as the old one. Almost all stick movement is followed by a noticeable delay before the quad reacts. Anywhere from .5 to 1.5 seconds. Every once and a while, it'll react immediately, but that's the exception, not the rule.

I dug the first one out, and verified it does the same.

I don't have an SLT Proto X (I wonder how my wife still allows me to live with all my quads and helis, so I don't plan to buy one soon ), so can't verify it myself. When I reversed SLT I noticed that there is room for it's extension - it seems to negotiate (one way - TX to RX) the packed length. So the receiver should theoretically support all possible TXs, but in this case it can be limited and support some specific packet length. I implemented only what I had as a transmitter - Anylink, and it generated only one type of packets. If you have Anylink, can you try it with Proto X SLT and check for this delayed behavior.

mwm wrote: New one arrived. It behaves exactly the same as the old one. Almost all stick movement is followed by a noticeable delay before the quad reacts. Anywhere from .5 to 1.5 seconds. Every once and a while, it'll react immediately, but that's the exception, not the rule.

I dug the first one out, and verified it does the same.

Bummer... sorry to hear that man..... this is so close to being the king of nanos, I wish we didn't have these problems.....

I do need to stress that my Proto X SLT with stock TX performs perfectly, way better then my two Cheerson CX-10s. I'd rather fly my SLT over the CX-10 any day. The TX is just so much better.... but when I pull out my Devo 7e our symptoms are just too similar to be coincidence... something is going on with this nano quad...

For me, with the Devo 7e it performs even better then stock tx, but there are these weird (rare) 0.5 - 1.0 second delays that cannot be explained.

I have to blame the TX - I have no other explanation.

Maybe I got lucky, but from where I stand, there is nothing wrong with the quad. The issue is with the TX.

side note: I went the opposite direction, I ordered a Proto X (old version, no SLT) to test my Devo 7e... I tried to go backwards... and although deviation flies it perfectly, the results were not impressive; it doesn't fly as well and the battery is noticeably less (2 min with prop guards). The SLT is better, and I want it to work dammit!

It would be extremely valuable if someone else here could confirm the SLT protocol works okay on Deviation...

....is ANYONE using SLT without issue?



 

Tryptych wrote: I have to blame the TX - I have no other explanation. 

Well, I blame the nature of reverse engineering. Given that victzh only had one SLT Tx to work with, and that included parameters that it didn't vary, it should be no surprise that this kind of thing is happening. It's not all that different from what's going on with DMS working with more than 8 or more channels and with other reverse-engineered protocols. Maybe we need a deviationTx interop?

Anyway, I've put disassembling the Proto X SLT Tx and hooking up a logic analyzer to it on my list of things to do. Hopefully, that will help, but there's other things I need to get done before that.


Victzh, if there' s anything specific you'd like to see, let me know.

I had two but they were the same Anylinks - I needed to see the difference for different TXs even of the same kind to be able to write a test code.

What I would like to have from people with Proto X SLT and having connectivity issues is to set a couple experiments. First - write down your fixed id, and then change it to any other value and test again. If it's better or worse, we probably have a lead.

There is always a weak spot in radio link - your calculated TX address serves as a radio address for many protocols, SLT including. It can be unfortunate - too few 0/1 transitions and thus not very well decodable. So RX starts losing packets and recovering takes time larger than just missed packet. It can require a whole frequency hopping cycle - 15 packets in case of SLT, or 0.3 sec, which can be noticeable.

Mine had no fixed ID. I changed it to 524288 and then to something random (I can check if you really need to know).

They all three had the same behavior - a delay of a little over a second between stick movements and the motors changing behavior. A couple of times the cyclic would react almost instantly, but I don't believe it did that consistently on any of them. I could go back and do more experiments if it helped.

Also of note, it would not bind with a fixed ID of 524287. I only tried three or four times, and it's always been a little finicky about binding.

However, I plan on having the logic analyzer out and set up for captures on my JoySway. If you'd like a something from the Proto X SLT Tx, let me know.

tryptych wrote: the protocol is slightly delayed once and a while and trying to play catch-up.

victzh wrote: It can require a whole frequency hopping cycle - 15 packets in case of SLT, or 0.3 sec, which can be noticeable.

I think you're on to something. My knowledge is very limited, but let me know if I can help with any testing. I flew some more today using no fixedID, fixedID=123456, and fixedID=633333. I didn't notice any difference, they all have the delay. I encounter it on average once every minute or so, and the delay could very well be exactly 0.3 seconds (it's definitely less than one second for me, but it can take 1+ seconds to recover from it).

Unfortunately the TX id as visible from the user is not so meaningful - it's being mixed with MCU id to make sure the 2 TXs with the same id set would not interfere.

But the case with ID with which you can't bind at all is very interesting. If you could build a developer build using TYPE=dev in the make command and record the serial output it will contain both the address and frequency hopping sequence that would help me analyze the situation.