Flydream V3 Captures

Ok I traced down the cc2500 on the receiver and can confirm Csn was not connected. Now all signals should be there, So,Si,Slsk,Csn, record is auto started t receipt of downgoing clock.
Files are all bind files from Rx.

These captures are good, thanks. Looks like the last byte of the rx_tx_addr is used as the frequency on which the channel numbers are transferred. Would you please make two more captures to confirm? Using deviation with a new fixed id first capture the bind sequence, then power off the receiver and wait for deviation to exit bind, then capture while powering on the receiver. Since the receiver doesn't automatically go into normal mode after binding the captures of binding don't include the receiving of the id packets.

Ok Hexfet some more info I found that some ID's bind erratically took time finally bind after some second or did not bind, but next time did bind, I have put tx in 1mw.
Same when reconnecting Rx, it took sometimes long, but finally connects and servo worked.

So I tried to fine tune the frequency I used ID) to do it and there is something wrong in this protocol, I could bind as lowest value -1 but the max value 127 it still bind and I can't find the upper value...... (Original Frsky Rx, values are close to zero <6, I believe normally I do not tune..)

attached the captures, but take care they are with fine freq 0, default tune.

Thanks Fernandez. If I understand correctly and you can't bind below -1 but can still bind at 127, then a good value to use would be 63. Can you try that and bind with fixed id 0 and then make a capture on the rx when powering up in normal mode.

Can't tell yet if the problem is just due to the many CRC errors, or if there is a change needed in the code.

yes but the max frequency shift is even higher as I do not loose binding at 127, anyway I'll enter 70. It will be definitively better than 0.
I assume that CRC may come from off center will capture and post it

Freq fine +70
id0 rx bound to devo.
Tx is in operation, switch on the receiver.

That looks much better. No CRC errors with freq-fine set to +70, and the LQI values are much better. Please try binding with the fixed ID values that were giving problems earlier. No need for captures unless there's a problem.

As expected now binded all fast and rx lock in fast.
Still it is strange it is so far off-tune never seen before, can we shift it a bit down, so can estimate the real center value?
Will try another Rx just to verify, not a bad X-tal in this particular one...

Anything more to test needed, as this week will be travelling abroad for work, will be back next weekend, so can't do more tests.
So only something to ensure frequency a start-up are selected good way.

Off topic;
Something annoying I noticed tune values are stored per model not per module, if you by accident etc move the protocol and get back he value will be deleted. (And it means 10 step trial and error to find center again.....)
It would be great if we can have a two stage, fixed shift to calibrate the Tx module in the transmitter.
(Fixed shift applicable to calibrate the tx module or hardware.ini)
In case we want to tune the to Rx, this part is on top (of the fixed shift set). Just depending on each receiver can be inside model as is now.
Maybe there are better solutions, but to get max range out of receiver, good centered freq is important, so it can be potentially dangerous, if accidentally delete freq tune.......

Different Receiver and I am surpriced, but excactely same as other receiver spot on...
-1 it still binds -2not anymore +127 (max value) it still binds.
So different Rx same behavior.

That's good news. I don't think a freq-fine value of 70 is excessive, though as you point out we don't really know if it could be better without knowing the max value. I verified the cc2500 initialization is the same as the stock tx so the need for the freq-fine value is some hardware difference, maybe slightly different crystal values. Don't think it would be a good idea to try to compensate with configuration changes.

If you are using the latest test build then Pascal's channel selection algorithm is already in use. The more fixed id values tried the higher the confidence will be that there aren't any invalid combinations. The code's functionally complete but there will be a new test build when you get back with changes to remove debug code.

While verifying the cc2500 initialization I noticed that the rx and tx configuration is different for four registers, though only one would have any effect on the radio link. In the Flydream tx captures the deviation (register 0x15) is set to the default of 0x47 while on the rx it is set to 0x50. That's a difference of about 3kHz (6%). Hard to say if this is a mistake or on purpose. Might be interesting to try a range test with the two different values if you're up for more testing. It is interesting that the Corona V2 protocol uses a deviation of 0x50, while V1 is 0x47.

Hi Hexfet Thanks certainly will test that range test builds.

It is good time to verify range test anyway on cc2500, as reported before for Frsky (at least in the past) RF output deviation in 100uW, was way to high, I test field strength using 100uA meter and diode and compared to original Frsky, were in range check my wireless field strength meter not show anymore power.

The schematic for Tx module is public, it is XTAL SMD 4025 26M, surrounded by 15pf each side. I assume Rx uses same setup.

No idea what is used on a stock CC2500, or FRSKY, could be f.i. 10pf, than freq will move up higher, offset tune will goo down?

Hexfet, where are the nightly sources used for your builds? I've tried to look around but it's not obvious...

The source is on branch protocol_corona in my repo . Generally I make the test build directory name the same as the branch name to help me remember.

Test build is updated (1f907e3). When the fixed id is an even number the DEVIATN setting from the tx captures is used. If it's odd the rx deviation will be used. Fernandez, please see if you can detect some range difference (or any other change) between the two settings.

On the topic of power I made a change a few test builds back that automatically sets tx power to minimum during binding. In normal mode the power setting in the model is used. No need to reduce the model power setting when binding. This test build also reduces the bind phase duration to 10 seconds.

Yes I've found your repo/branch holding your source in progress on gihub previously but I was wondering if you were doing a source build with all the latest protocols combined or you are developping each protocols idenpendently and then merge them to the deviation master repo when proved working.

I am travelling till the weekend then be able to test it.

On power settings, I will also verify in the past with frsky d protocol, when set to rangechecknor 100uW the power out put was still way too high. (Measurable with Rf pick up).
Original dht in rangechecknI could not detect output rf with my detector.

With devo in rangecheck d series, you have too walk huge distances.

But will verify this power output during the weekend..........

planger wrote: Yes I've found your repo/branch holding your source in progress on gihub previously but I was wondering if you were doing a source build with all the latest protocols combined or you are developping each protocols idenpendently and then merge them to the deviation master repo when proved working.

Okay I misunderstood. The test builds are built from the branch, so they only contain the changes in the branch. I try to keep the branch up-to-date with master to make the eventual PR and merge easier so the test builds will usually include other changes that have made it into the nightly builds.

Ok I did some testing, the power output setting for cc2500, seem to work fine now, t when in 100uw I cannnot pick up any more with my field strength meter, which was not the case in the past, so probably this bug has been fixed back ago.

When comparing bind with id2 or bind with id3, difficult to say but I have the feeling that ID3 might be a tad better. ( tx 100uW, fine freq +70)

When put Tx at edge of operation, at loss of signal servo move to failsave position.
I reboot power Rx and try it to connect, while moving bit the Rx antennas to get reception, I get sometimes a short lock and it looks like servo moves into wrong direction sometimes (but not failsave), as short spike, then locks, decode correct on to signal.

What I also find this receiver only get's into failsave position at loosing Rf lock, but at switch on (without Tx on) servos won't move to failsave. (I think it is Rx firmware, just behaviour of this system)

Anyway is there a better way to validate which would be best can I make a capture, any better test?

Not really a better way to check. I'll set the tx to the value the rx uses because that's the best kind of correct.

If you could check a half-dozen random fixed id values to make sure they all bind it'll give more confidence that any values work in the protocol for txid and hopping frequencies. I have cleaned up the code for a pull request and posted a final test build (840448c).

Since I used the +70 fine tune, all codes I tried did bind, checked possibly 20.

The Flydream X-tal is 26Mhz, both side 15pf to gnd, all FD receivers loose excactely bind at -2 fine, so it is not the tolerances between receivers, maybe stock cc2500 module (and Frsky) uses different capacitances.... Normally my Tx, tune is quite spot at center, so maybe this significant offset, some user may get out of tune.

When we get the nightly build, I'll do a test flight.

Thanks Fernandez. It will be in the next nightly build.