Spektrum users - Which mode should I run? READ!

[rchaas]

Noted. I always reboot both together, so I guess that's why it was "fixing" it.

thx

[wrobijns]

Now it's still not clear to me.
Is it an issue with VBAR internal receivers like the mini VBAR and new Blue full sized?
Or a spektrum problem alltogether?

There is nothing on the Spektrum Forums on this, only on te VBAR forums.
I have a Spektrum DX8 and the AR8000 receiver (that comes with it).
The receiver has one satelite and then connects to the black fullsized VBAR.

So all the reception parts are within Spektrum stuff.
Do I have an issue?

[MrMel]

Its an transmission issue, i will test AR8000 this coming week.

Its the protocol of 2048 resolution that is the problem, not the framerate. So 11ms 1024 would be fine.

[KDE Direct]

Can someone please explain how the protocol for Spektrum 2048 resolution works? From what I understand, it operates in 1024-native and then sends the extra bit in a separate package with each signal to complete the 11-bit resolution (2048). Is this correct? If the 1024-native signal is not being corrupted, why is the additional package having issues? Have the Spektrum and JR receivers been secretly chopping off the 11th-bit if it arrives corrupted, which seems the VBAR system is not doing, so most of us have been truly flying 1024 resolution the majority of the time without knowing it?

I'm just curious as to the theory of the issue, although I'm confident I can't tell the difference between 1024 and 2048-resolution, it's definitely overkill based on the application in my opinion.

[MrMel]

1024 is sent in one package.
2048 is sent in two packages after each other to cover the extra bit. (a few channels in one, a few in the other)

If you have a bad connection, where you might have 50% packet loss, the 1024 you get a good package every few anyway, at 2048 you need to wait for a complete set.
This is what causing issues.

I truly do not know why this is happening, it might be linked to proximity, it must have something to do with background interference and how DSM2 works.
Just know it does happen as I have seen it and recorded it with my equipment (Logic analyzer to on the satellites)

drop me a PM and I can tell you more.

[OnTheSnap]

I'm really not sold on your root cause analysis. Some big piece is missing.

We know:
1) SK720 runs 11/2048, no issues (I don't even have an option to bind in LowrRes!)
2) Total G runs 11/2048 no issues
3) 4 or 5 different JR/Spek receivers all work with 11/2048

---> vBar does not work

So really at this point, the only device that does not work correctly with a DSM "bug" is vBar. Odds are your measurement was incorrect or the understanding of how the protocol works is wrong.

Bottom line is only one device is not working correctly here. vBar.

[MrMel]

Just reboot radio enough times not RX.
But since there is at least one other factor, be prepared to do it for a while, I had streak where it took 100+ times, sometimes it happened within 3, other 50, without anything changing around me.

I replicated it on total G with 3 satellites, less servo jerky effect with 3 but, No, its not a vbar issue
Same thing with satellites connected to a R921, but then servo moves ok due to internal 2 x RX

You can even reboot enough times until it happen, then MOVE the satellites from vbar, totalg, whatever, and the effect stay, unless background interference change, did this several times.

Placement/Angle of Satellites does not seem to affect, tried that too, position of TX does to some extend, but that's where I hit the limit of my testing equipment as I could not see live, had to Move->record-Move-Record etc.

[MrMel]

Regards to AR8000 using a new type of satellite and internal RX, new type of binding it seems, none of my old could be bound with the 8000, only the new one. So where as if its better or not need more testing.

[OnTheSnap]

Is it possible to build a fail safe where vbar will not initialize if it boots and see's corrupt data during init?

On the sk720 I do occasionally boot and see it go to a red fail status after the sat's initialize. I wonder if it's detecting the issue and then entering a failure mode. I must have over a 1000 power cycles on my 720's and have never observed the behavior.

[MrMel]

Perhaps, but since we do not know WHY it happens really, just that it can, what say it cannot happen inflight all of the sudden?

Better to run 1024, there is ZERO gain from running 2048 really.

That's as far as I will pursue it really, I fly in "lowres" mode and will be happy, that or I will switch to Futaba gear.

Perhaps the solution is already in the AR8000 satellites as they are different, I do not know.

MrMel, What did you do last week?: I cycled the power on the radio a few thousand times...
(spent probably 50+ hours testing)

[flymustangs]

Originally Posted by MrMel

MrMel, What did you do last week?: I cycled the power on the radio a few thousand times...
(spent probably 50+ hours testing)

It's not much, but THANKS!

[ping]

Their may be a new version of firmware on those satellites.

[MrMel]

Originally Posted by ping

Their may be a new version of firmware on those satellites.

It is, there is different pulses coming out of the AR8000 for binding, the old ones will not even know to start the bind process.

[futurase]

So is this just a matter of needing sats with the newest firmware?

[MrMel]

No, its not confirmed that it helps at all.
Just a theory, will test if i feel like spending the hours it takes.
Waiting for another test equipment so i can test another theory at same time

[TheBum]

Originally Posted by MrMel

No, its not confirmed that it helps at all.
Just a theory, will test if i feel like spending the hours it takes.
Waiting for another test equipment so i can test another theory at same time

All your efforts are greatly appreciated, Fredrik!

[futurase]

Exactly what Alan said. The Vbar would not be what it is without you Fredrick. Your help has sold more vbars than Mikado will EVER realize. Many peoples deciding factor on buying one was due to you. I know that for a fact.

Thanks,

Norman Ross Jr.

[MrMel]

Thanks for those words.

Well, 500+ more restarts of the radio I think I have a clear picture.

The new satellites that comes from AR8000 does not suffer same fate as the older ones.

DSM2 sending in 2 channels, so with a R921 (2 internal receivers and 2 satellites max) same signal is sent to two of the satellites, if this was a pure TX issue the same effect should be identical on two satellites, its not.

if I restart enough time, to get a bad signal it seems that the decoder inside the satellites get screwed up.

But, with the new Satellite from the AR8000 now connected to a R921 and rebound, has zero packet loss.

See picture;
(last line is a good connection and how it should look like, the other suffer severe packet loss)

To why this is happening, I do not know, Proximity, Interference, bad luck I do not know, I do know that it has happened in the field for people, it happens regardless of what system you are running (VBar, TotalG etc).

But it must be the decoder/transformer in the satellites, as when it's really bad, its always ONE out of two packages that's missing, problem is, when its ALL second packages, its total loss of control, due to how 2048 is transmitted.

i do not know if Spektrum can upgrade older satellites.

I also did above test with both R921 and AR8000 bound at same time running in parallel, while I managed to get total loss of connection on the R921 the AR8000 never missed a beat.

[futurase]

Ok, then here is the big question. Is there something special about the sat with a AR8000 or do all new sats come updated? It would not make sense to make two different makes of the same product.

Paul Beard is who needs asking about this.

[MrMel]

The AR8000 satellites can be bound with older RX, but a older Satellite cannot be bound with a AR8000 meaning it's backward compatible, so to be honest, they probably knew and this is how it's fixed.