Flydream V3 Captures

Hi Hexfet will try you're testbuild this evening. (To confirm No the previous build the Rx led wont flash or flicker when in bind mode, basically indicating it is still awaiting to receive bind from transmitter) With ID0, bind is established immediately.

Yes I can capture more data also from RX (some soldering needed but doable), but I forgot how I did setup capturing device. I downloaded latest Salae software but it seem different. Could you possibly point me to a valid link or instruction for capturing? Or towards the old Salae software?

Take a look at this link for spi capture info. The Salae site may have old versions available - not sure where else to look.

Hi Hexfet, I tried your latest testbuild, it works nicely but again only on bind id0. Several other 6digits tried without a succes not any reaction from rx led.

So it is time for me to come up with some additional captures, keep you posted.

Btw I see you’re test build are 4.01 and not 5.0

I managed to create some new Capture i hope they are readable.
For the Rx I have connected 6 lines as not sure what is what and wanted to ensure I got all lines captured.

these are the last files, if any tests needed, it took some time, but I have it now working, and lines are still hooked.

Not having much luck making sense of the captures. The ones larger than 3 MB seem to have valid clock, miso, and mosi signals but no enable. The smaller files have 4 active signals but none seem to be a valid enable. Can you take a picture of how the leads are attached to the radio?

Hi hexfet, for the Tx captures, i did not resolder any trace wires as was still connected to Tx module as before. So no idea why it is different to original captures.....(Could it be due to setup of Salae, maybe pluged into wrong pin at Salae side ?)

For the Rx, the cc2500 pa/lna is piggybacked as a module ontop of the Atmega, so i took moreless all lines which looked of interest, see attached the images.

I also have one old burned Rx, which I dismantelled, so you could see the traces.

In the original captures the fourth input signal is the enable signal (named csn). It's good in those captures, but in the latest it is always high. Maybe it's not making a good connection.

The receiver captures should have a signal that looks like enable as well. I did find some data in the receiver captures so the clock, miso, and mosi signals are there. It did seem like there were some bit errors though so please also check the wires and make sure there's a good ground. It's difficult to see what's going on without the enable signal to mark packet boundaries but I'll see what I can find.

I'll check I used some crappy dupont wires and I found allready that they were sloppy and thin wire easy to brake, I'll will double check all connenctions and make some new records. Gnd is defenitively ok, otherwise it is a noisy/spiky as hell..... For Tx original recofdings I start capturing at arrive of clock. (setting) for new records i just start capture than power on, it records all...

As you see for the RX, I hooked up most of the lines.
The bind procedure for RX is very strange, as press button for two seconds, when led is on (you have two seconds) loosen the button in that time and RX is in bind mode (led off). When binded with tx, rx led flashes fast. You prefer I start capture, when RX is allready awaiting in its in bind mode? or just from power on putting Rx into into bind stage?

If you can locate the Enable signal on the receiver then it will be helpful to have a capture of everything from power-on. If not then it's okay just to start capturing after putting the rx in bind mode. Without the Enable signal I can't decode the chip initialization that happens at power-on.

One thing I can tell from the receiver captures is that there are errors in the data received from the t8sg, but not from the stock tx. I verified the chip initialization and bind packets are correct. There may be some freq-fine adjustment needed. Do you have any Frsky receivers that you've used the freq-fine adjustment with? If so try setting it to the same value for Corona FDV3.

I also updated the test builds but don't expect it to make any difference. The stock tx does a manual frequency calibration at the end of chip initialization. I left that out originally since the cc2500 is configured to auto-calibrate at the start of every transmission anyway. Just put it in to match exactly the stock tx initialization.

The second thing learned from the receiver captures is that the receiver does not accept any random txid. The capture with deviation fixed id 123456 fails to bind not because the receiver starts listening on an unknown channel, but because the receiver never accepts the random txid. Is there any way on the stock tx to change the fixed id? If so please capture a couple bind sequences on the receiver with different fixed id on the stock tx. If not then we're probably stuck with the single working txid, but that's no worse than the stock tx with a single fixed id.

Hmm interesting find, I have only one original tx module, but several Rx.

The module used is one of the very old cc2500 modules, with original d4r etc its is very close to mid I beleive -6 or so. (As this is probably within tolerances, Normally I do not tune it for original
Frsky rx)

Will do my best for re checking wiring and some more captures, probably not before weekend.
Do we have a cc2500 image with lines marked we need to tap, I may try to follow the traces on pcb etc.

Hi Hexfet,
I haven't looked at the dumps of this thread but since I've reversed Corona v1 and V2 I might be able to give hints.

You've written:

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.

What you are explaining here looks like Corona V2.
For Corona V2 the bind is in 2 folds. The first part of the bind is only based on the TX sending it's txid and that's all the information sent to the RX. Then you power off both the RX and TX. Start the RX in normal mode, at this stage since the RX does not receive a signal from the TX, it goes by itself on a "second bind mode" to retrieve the TX frequencies. When you then power on the TX in normal mode, it starts by sending for a really small amount of time a packet containing his ID (learnt by the RX during bind) and the frequencies to use on a specific channel. Then it starts sending the data packets.

Let me know if this is of any help and if I should look at the dumps.

Pascal

Thanks Pascal. The Flydream V3 binding is similar to Corona V2. The difference is that when the TX is turned on in normal mode it doesn't send the ID/freqs for a short amount of time. Instead it continuously sends the ID/freqs every 4th packet, with the 3 other packets being normal data packets on three different frequencies.

The issue right now is that the RX doesn't seem to respond to any txid except for the one from the captures - it just stays in bind mode. The current code does bind correctly with the txid from the captures, but would like to find some other working txid values to prevent interference if multiple transmitters used together. Though the likelihood of this protocol being used by multiple users at a single site would be small

Fernandez, the captures from the receiver shows LQI at the max value which is usually a good indicator that a freq-fine adjustment is needed. The binding still works because occasionally a packet is received correctly (with a good CRC flag). Please try freq-fine steps up and down until it won't bind and then pick a value in the middle.

I also changed the code to set tx power to minimum when binding. Setting the tx power to minimum before binding with the version you already have will do the same. Test builds are updated (9321701).

Pinout for the cc2500 is attached. The signals we're interested in are pins 1 (Clock), 2 (MISO), 7 (Enable), and 20 (MOSI). Set up the SPI analyzer with these assignments and you should see data in the decode window. The circle in the corner indicates pin 1.

Without captures from other Flydream tx modules it will be difficult to determine what makes a valid txid. Have to try changing the fixed id one step at a time to find values where the rx responds.

Is there any way on the stock tx to change the fixed id?

May be useful, on a Corona you have to press the bind button on the TX for a couple of seconds (5-10) at power up to change the ID.

Looking at your code I'm thinking you might want to try something (again I haven't looked at the dumps). On Corona V1 and V2 rx_tx_addr[1] is a constant equal to 0xFE. If I look at the V3 ID, I can see that this 0xFE has been switched to 0xFA. So basically I would try to force rx_tx_addr[1] to 0xFA (like I'm forcing it to 0xFE).

Pascal

planger wrote: May be useful, on a Corona you have to press the bind button on the TX for a couple of seconds (5-10) at power up to change the ID.

This will be very helpful if it works for Flydream! It's not in the Flydream manual but I only found it mentioned in one of two Corona manuals I found: "(Attention: Not keep hold the button down over 3 seconds,or its ID will change randomly) ". Is there any indication on the module that the button has been down long enough to generate a new ID?

planger wrote: Looking at your code I'm thinking you might want to try something (again I haven't looked at the dumps). On Corona V1 and V2 rx_tx_addr[1] is a constant equal to 0xFE. If I look at the V3 ID, I can see that this 0xFE has been switched to 0xFA. So basically I would try to force rx_tx_addr[1] to 0xFA (like I'm forcing it to 0xFE).

Pascal

Good suggestion. I have updated the test build (9ac611b) with this change.

Fernandez, please use the latest test build for testing. Summarizing the last few posts I think the following is your homework
1) Check logic analyzer connections. The Enable signal is missing from both tx and rx captures.
2) Make several receiver captures of binding stock tx, each time holding down the bind button on tx long enough to change the txid (10 seconds).
3) Adjust freq-fine on devo tx using fixed id 0. Try adjusting up/down in steps of 10 until it won't bind, then set to middle value.
4) Make a receiver capture of binding deviation with fixed id not 0. Probably will not be successful but will be able to see if the freq-fine setting makes a difference.

Hopefully the flydream module will also change txid by holding the bind button down a long time. With a few captures we have a better chance of figuring out the algorithm, but even if that's not successful we can at least have several different working txid values in the protocol.

Good input; Would not surprise me if it also works for Flydream, very often code has been "unofficially copied" or sold under an licence and ends up, with small mods in other systems.....

What I do first, bind RX to original TX, than play with long press the button (10sec) , during powering on etc. If it changes Quid, rx loose its bind and need for rebind than YES! I can capture several different bind with original Tx.

will be during weekend, I expect.

Jut small sidenote; I own Flydream V2 transmitter module, however the Rx are all Flydream V3 . (I think difference V2 and V3 is only some switched regulators etc)

Ok at first I was abit of disappointed. I binded my rx to the stock flydream tx module, I tried pushing button on tx 10sec during power on etc several times and sequenses , but what ever i tried, the binded RX stay bind to the original TX indicating the the Tx ID cannot be changed and seem to be fixed in flydream....

So next test i tried new testbuild, 123456 binded immediately, bingo! Tried few other ID randomly al of them binded worked fine.
To confirm whith devo ID0, my original flydream can control the RX which was bind to the DEVO. But bind ID 123456, my original TX can't control and or interfere the Rx.

Only thing left than is the LBT scan search for free channels at start, then select those? But so far I am very impressed by your skillls!
How do you choose channels right now? I would imagine you want them, spread far out of each other...not 3 neighbouring channels, even if they are empty at time of switch on.

Progress! that's good news. I would guess that it's working because the fixed FA value suggested by Pascal. In the latest test build the channel numbers come directly from the fixed id.

Would you please make two spi captures on the receiver while binding with two different fixed ids? Would like to confirm we're not just hitting the id packet channel number by luck. Also did you adjust the freq-fine setting? Curious to see if it makes a difference in the captures, so if you haven't changed freq-fine yet please make one capture, find the optimum freq-fine, then make another capture. It's okay to make the captures without looking for the enable signal on the rx as that part of the capture can still be decoded. Thanks!

I wouldn't describe the initial check for receiving packets as LBT as far as the ETSI requirements. The tx is just checking for received packets, not checking power levels. I plan to use the channel selection algorithm Pascal already put in for Corona which ensures the channels are spread apart and within band. Test build (004235a) is updated with this change, but if you can make the captures please do that before upgrading (just in case it doesn't work .

Great news! I'll wait for the tests to be completed before porting the code back to Multi.

One point about this LBT thing, I know that Corona V1 does something similar where the TX listens if a RX is around before launching the bind sequence but it's at bind time only.

Pascal