Volantex V761-1 Firestar Mini protocol

Hi Goebish, sry I didn't get round to this. ( which is not cool after your effort)
I started experiencing uncontrolled flight at any distance more than 10m (I suspect its due to my firmware upgrade and me not copying the code across properly again) and haven't flown subsequently due to our windy season.
I will make an effort this weekend to test and sort it out.
I will also implement pascal recommendations

Sure. I'm travelling as well during the next 2 weeks but I'll be online most of the time.

goebish wrote: Thanks !
According to Pascal, no wonder range is just around 10m with your implementation:
"NRF24L01_SetPower(); is not called in the transmit loop so it will stay on bind power"

What is strange is that I never had the problem initially, so I suspect I removed it by accident at some point.

Or you did not put at the begining BIND_IN_PROGRESS and therefore you were always in full power.

Pascal

To be honest most of the code is way above my head ...
so please excuse the questions

I call the BIND_IN_PROGRESS; only in the initV761, should it be elsewhere?

could you possible explain how the return function works in simple terms specifically with reference to my V761_callback( and thus within the remote call back function), I had initially tested using the value 15730 and it did not complete the bind when I changed to 50( based on example) it worked , but I don't fully understand the implication of it. I had assumed it was returning to the function much sooner? ( I prob need to go and read the multiprotocal.ico properly to understand the implementation)

the other fixes in code are done.

Kill_Switch wrote: To be honest most of the code is way above my head ...
so please excuse the questions

I call the BIND_IN_PROGRESS; only in the initV761, should it be elsewhere?

could you possible explain how the return function works in simple terms specifically with reference to my V761_callback( and thus within the remote call back function), I had initially tested using the value 15730 and it did not complete the bind when I changed to 50( based on example) it worked , but I don't fully understand the implication of it. I had assumed it was returning to the function much sooner? ( I prob need to go and read the multiprotocal.ico properly to understand the implementation)

the other fixes in code are done.

BIND_IN_PROGRESS is fine now in your code. You also have BIND_DONE when bind is competed so you are all set.

For the return of the call back, the value indicates the number of micro seconds the call back should be executed again. A number like 50µs is way too small, the NRF won't have the time to transmit and you are just bursting the packets out. Having a proper timing is important for protocols to work as they rely on the timing to hope between frequencies and meet there. During bind the frequency is most likely fixed so this problem is lesser but you still need to give the right information at the right time.
I haven't looked at the dumps but between 15730µs and 50µs there is a big gap. If 50µs was working I would try more 1000 or 2000µs which leaves time to the multi core to process data.
Hope that helps.
Pascal

Thx.( the limitations of setting it too fast make sense)
I am going to try again at 15730 as per Goebish spi analysis
Now the rain must just clear up long enough for a test flight.
I have committed it again but testing is needed.

Everything that has been asked does not need a fly test... Everything is on the bench.
You need to try to bind with your own ID currently hard coded in the function initialize_txid. If you see that you have correct and smooth controls then just try different IDs and frequencies. This is the important part and what's preventing us to move forward with the implementation.

Pascal

Ok results form bench tests( connect Rx first then switch on Tx)

Test TX id
memcpy(rx_tx_addr,(uint8_t *)"\x47\x93\x45\xD5",4); // random 4 bytes x47\x93\x45\xD5
memcpy(hopping_frequency,(uint8_t *)"\x14\x32\x46",3); // random 2 bytes for hopping_frequency[1] = 0x32 hopping_frequency[2] = 0x46;

Actual from SPI grab
memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2c\xb1\x93",4);
memcpy(hopping_frequency,(uint8_t *)"\x14\x1e\x4b",3);

With correct values - Full control

With both TX id and hopping changed - No control
Rx initialises (on Tx powerup) before this the gyro is disabled as soon as power on tx is on the gyro becomes active even if there is no control

Only with Tx id - No Control
Rx intialises

Only Hopping - Full controll
seemed to be a short delay( less than 5 sec) , but then had control. Subsequent power cycle worked 100%

Not sure what he next step would be

Try to not change fully the ID right away neither hoppin frequencies. Change one by one the first byte, then second, then third, then forth. See if you can keep control when changing only by a little.

Also you might want for example to just increment the last byte of the ID 0x93->0x94. From there see if you keep the connection if not try incrementing the first hopping frequency number 0x14->0x15 and try again.

This is the complicated part to figure out the match between ID and frequencies. You are the one with the receiver so the only that can do tests and figure out...

Pascal

Any news?

Got to some testing today
Unfortunately it seems the Rx board is now broken I cant even get the stock Tx to bind. ( Not sure how since all the changes are on the TX side so I'm really confused)

this is what I got Its only based onn incremental changes on TXID the last two I cannot confirm as this seems to be when the rx Board became unresponsive...

memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2c\xb1\x94",4); Yes
memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2c\xb1\x95",4); No
memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2c\xb1\x92",4); Yes
memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2c\xb1\x91",4); No

memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2c\xb2\x93",4); Yes
memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2c\xb3\x93",4) No
memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2c\xb0\x93",4) No

memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2d\xb1\x93",4); Yes
memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2e\xb1\x93",4); No
memcpy(rx_tx_addr,(uint8_t *)"\x6f\x2b\xb1\x93",4) No

Unconfirmed results
memcpy(rx_tx_addr,(uint8_t *)"\x70\x2c\xb1\x93",4); No
memcpy(rx_tx_addr,(uint8_t *)"\x6e\x2c\xb1\x93",4); No

Kill_Switch wrote: Got to some testing today
Unfortunately it seems the Rx board is now broken I cant even get the stock Tx to bind. ( Not sure how since all the changes are on the TX side so I'm really confused)

Heya Kill_Switch - found you over here from the multi module thread on rcgroups. Did you ever replace your RX board or do more work on this?

I too, have several Volantex planes I really like. The one I'd like to use with the MPM on my X-Lite, is the Volantex 761-2 Ranger 600. I believe the radio it comes with is identical to yours as it has exactly the same functions/channels/behaviors you name. In addition, the chip on the TX is the identical part number. I don't know what the RX chip is as it's glued inside the plane upside down, but I'd bet it, and all Volantex planes, use the same pair of chips.

Is there a way I can help with this, or test? Thanks either way.

We can try the same protocol with your plane since most of the details are known.
You've also asked on RCGroups where I've indicated how to dump your TX. If you could do so that would help to figure out the ID.
- Pascal

Hi, sorry to reply this so old post but I am curious if this V761 protocol has finally been included in any of the nighly builds already posted. Thank you!

I answer myself: Yes, latest builds already support it.