Flydream V3 Captures

I still have about 8 of those flydream receivers laying around and honestly I never had really issues with them.
It is based on the cc2500 and I expect that there are big similarities with corona. (likely 3 frequencies used) also it uses similar hardware and almost similar pcb.

www.fd-rc.com/cpzs.asp?classid=37&Boardid=189
www.fd-rc.com/cpzs.asp?classid=37&Boardid=208

In order to bind, I have to push button Tx, power Tx on during push , then push button RX power it on loosen the button when Rx led is solid, than Rx flashes rapid and is bound.

These are my first recordings I hope the are ok

Anyone who could check if the recordings seem to be correctly done?
Was my first time hooking up digital analyser.

Except that your recordings have the some channels mapped wrong they look good to me. Channel 02 is clock and channels 03 is enable. I will leave protocol analyzing to the CC2500 gurus

Any gurus around who did have a look?

The ;cc2500 initialization and packet length are the same as Corona. Have you tried the Corona test build? I don't have any Corona captures to compare and it will take time to compare these captures to the Corona code.

I will try it, but i'll expect it won't work. (As I beleive at the time others have tried to bind flydream to corona).
Probably some small differences...

I tested Flydream V3 to bind at Corona testbuild, but no succes. It seems there is some activity of the Rx bind led.
Basically the receiver indicates that it binds, however it has not.

So put Tx in Bind > push button RX, power RX> loose button RX when led is light > rx flashes fast Rx bound
Then after reboot led should be solid, but it is off, so no bind established.
Surprisingly this behaviour of fast flikkering led at Rx (normally indicating finished binding), is same when tx is just in corana transmission mode,

I tried some different bind id's 000000 and 111111 and a random nr, no luck.

Anyway it seems it is lsightly different. I ahve no corona here so I can only try to make flydream work.
For further testing I'd like that the Tx stays in bind mode when hit bind button, as for flydream procedure you have to put tx in binding mode than bring receiver in binding mode, but after few seconds tx beeps and binding mode exits.

Thanks for testing. The flydream captures show it to be a mashup of corona v1 and v2. Just haven't had time to put some code together but it's on my list.

Thanks in advance Hexfet !

The Corona test builds are updated. I added the FDV3 format to the protocol options for Flydream V3. It's hard-coded with the address and frequencies from the captures so it may work without binding if the receiver is already bound to the tx used to make the captures. Good chance binding will work too I think. If so we can move on to test the more general algorithm.

The channel max/min range may also need to be adjusted, so be careful if it works and you test with servos in an aircraft.

Wow Hexfet you're getting close now!
The good news is it can bind Flydream and all channel 1-8 are all working smoothly and seem correct!

After switch on TX, RX moreless immediately locked and a solid led at RX, but in 1 out of 10 cases when switch on Tx, within1-3 seconds the Rx led goes off (lost connection), then goes on again shortly after.

It seems there is a "kind of missed lock" to the Rx. During the missed lock period after switch on (Rx led on), the servos do resond with "shocks", sometimes it seems to receive the right data, but miss a lot of data too, but during this faulty lock RX won't go into Failsave.

It is no't swamping as I am on 3mw and Also have the affect at 1meter away and it is not always.

hope it is clear let me know if you need more tests.

The test builds are updated with a small timing change. Not sure if it will be better or worse. From what I can tell the data is all correct so it was the only thing I could think to change.

Are these receivers compliant with EU regulations? At startup the captures show the tx spends some time checking for receive data on the channels it is going to transmit on. In the existing captures it never receives anything, so it would be interesting to see what happens when it does. To do that would you please make a capture where you turn on the deviation tx first (with protocol corona fdv3), then turn on the stock tx and capture its spi data. Thanks.

Thanks will test and report, not sure about if it listens to free frequecy, but it could indeed be the case. This is one of the first 2.4g systems, at that time "DSM issues", were hot, it could indeed be that V3 listens to channels first.....

This link may be of interest as full test reports FCC are available:

apps.fcc.gov/oetcf/eas/reports/ViewExhib...%3D&fcc_id=X6N-IS-8F

Ok new testbuild I cannot reproduce the problem, it seem to lock any time immediately with full control, it is linked very fast, switch on deviation almost instantly solid Rx led and link established.

When using original module, it take about 2 seconds after aplly power to Flydream module, before Rx links to Tx.

when transmitting both it seems that the Tx switched on first keep control to the Rx.

Think I am going to make those "listen before Talk" Captures, hope I still figure out how to do it
The wires and capturing are still soldered to the Tx module.

That's good news. Seems like the timing change worked. I've updated the test builds to use random address and channels if the model fixed ID is not zero. Please test a few different fixed id's and check if you can still bind and everything works as expected. If it doesn't work you can set fixed ID to 0 and the address/channels from the captures will be used.

According to the captures the stock tx spends about 1 second listening after power-on so that may be some of the delay you mention. I think the tx is probably just trying to avoid interference with other Flydream radios rather than comply with the ETSI requirement. It's not trying to estimate the power in each channel but rather checking for received data packets in the channels it's picked to use.

No luck this time, I tried a few codes, but it only binds at 0.

Is it possible to leave the tx longer in bind mode, or leave in bind until press bind button again? It is a bit too short especially for flydream, as Tx must be put in bind and then Rx must be put in bind, by pressing button for some time during power on then loosing the button...

Test builds are updated. The bind time is increased to 15 seconds. Keep in mind if you dismiss the bind dialog early it only clears the screen - bind packets are still sent for 15s.

Please try the non-zero model IDs again. I made a slight change just for testing - don't really expect a difference in behavior. Is there any possibility of getting a bind spi capture from another tx module? If not we may just have to live with always using the captured address/channel values.

I tried the new testbuild and yes Tx stays longer in bind state, when pressing bind, usefull for testing.
But no good news, I can still only bind it with ID: 0
I tried a nr of codes randomly, no succes, not even a blink, just nothing happens to RX.

After trying some binds, I have to rebind Rx to ID: 0 and it starts to work again.
I have no other tx modules, I could capture the Rx, but not sure if that make any sence.

I have no idea how it works but why there need to be a 6 digit ID and not some other ID, Hex?

Thanks for testing. We're trying to figure out how the receiver picks a radio channel to listen on based on the txid. During bind the Flydream protocol only sends the txid to the receiver. When not binding the protocol sends three data packets on three different channels, then an id packet with both txid and the three channels the rx should use to listen for data. The channel the rx listens on for the id packet must be derived somehow from the txid.

Fixed id 0 works because of test code that uses the known good values for txid and channels when fixed id is 0. When it is working have you checked the receiver outputs? With a simple mix at 100% do you get the expected PWM width and/or servo deflection?

Test builds are updated. Just a small change when fixed id is not 0 to perhaps get another clue on the channel selection. Going to start putting the commit hash here to help keep track of changes vs results (d5e0a6f). Please try a couple different fixed id values.

It would be helpful to get captures on the RX if possible. Try with a couple different fixed id values so we can see what channel the rx picks to listen. Please put the fixed ids used in the filename of the captures. If we can't figure this out it means all your receivers have to bind with the same fixed id.