New SYMA protocol

Failed to open for me in Saleae software. Mine is Logic 1.1.15.

victzh wrote: Failed to open for me in Saleae software. Mine is Logic 1.1.15.

I am using the last beta 1.1.18 ....

There's a note on the beta software page:

A Note on Saved Files
The logic software can save captures (*.logicdata) and setups (*.logicsettings). These saved files are forward compatible, but not backwards.
Files saved using the Logic 1.1.18 beta software will not be openable in older versions of the software, but they will be openable in future releases. Please keep this in mind when you save your work.

hexfet wrote: There's a note on the beta software page:

A Note on Saved Files
The logic software can save captures (*.logicdata) and setups (*.logicsettings). These saved files are forward compatible, but not backwards.
Files saved using the Logic 1.1.18 beta software will not be openable in older versions of the software, but they will be openable in future releases. Please keep this in mind when you save your work.

Everyone is using the 1.1.15 ?

Ok ...

here a capture with v 1.1.15


www.wetransfer.com/downloads/889d3bf1b4c...0140201235319/9f17cc

Here's the capture processed with a script of mine. Happy to share the source if anyone wants it.

Haven't looked closely yet. Looks like init, bind, and data.

Something strange that doesn't show up in the CSV file is a bunch of transitions on MOSI after the init sequence but with enable high. Don't know what that means.

Ok I am uploading a video of my experiment ..... maybe I am doing something wrong. I will also upload the associated logicdata file

The new data :

www.wetransfer.com/downloads/3135a965a17...0140202002642/de8fa9


and associated video:

I will go to sleep now ....

Can continue tmr ....

Edit: Try binding this quad with the YD717 protocol. There may be a slight difference in the data packets, but it looks like it should bind at least.

Spoke too soon. I see two differences from YD717.
- A different bind address is used. I think this is pre-configured in the rx so it's unlikely to bind.
- The data packets are 9 bytes instead of 8. Looks like the extra byte is a checksum.

Is there a good way to accommodate these differences without duplicating the rest of the yd717 code?

I decode it from SPI output - it's a bit easier, but does not allow extra signals like CE. The results of decoding for the first data are attached.

hexfet wrote: Something strange that doesn't show up in the CSV file is a bunch of transitions on MOSI after the init sequence but with enable high. Don't know what that means.

I'd suspect that the SPI bus is also being used for something else, like an LCD, with it's own enable. Possibly the lines could even be being used for something that is not SPI - while the enable is invalid, it doesn't really matter to the radio chip what the processor does with them.

Incidentally, for mapping sticks to fields in a packet, I found the ability of sigrok (instead of saleae) client software to provide raw streaming output to a custom decoder quite useful. At 1 or 2 MSPS my decoder would fall behind, so I ended up running short bursts of capture/decode in a loop repeating a few times a second. That let me move sticks and push buttons, and immediately see how the packet data changed.

Is the YD717 protocol have been updated since NB from 10 juanuary ?. Coz I tried with my actual version.... it doesn't work but the TX is emitting strange noise ... Maybe I don't have the last version.

EDIT : the video with 16 juanuary Happyharry build



With the 26 juanuary build, the same problem



@victzh: with your decoded packet can you now be sure that this new SYMA protocol would be compatible with the nRF24L01 ?


Anyways, thanks guy for trying this new challenge . I am impressed by your tecknic level skill in this area ... I am completly rooky but I would like to learn

Ok, thanks to hexfet, I did an error in saleae logic analyser in the SPI mapping configuration.

Now I got some extra informations appearing on timeplot. I exported both the session as well as the SPI output in the following zip



www.wetransfer.com/downloads/172a95a18f8...0140202101753/1f56af

cstratton wrote:

hexfet wrote: Something strange that doesn't show up in the CSV file is a bunch of transitions on MOSI after the init sequence but with enable high. Don't know what that means.

I'd suspect that the SPI bus is also being used for something else, like an LCD, with it's own enable. Possibly the lines could even be being used for something that is not SPI - while the enable is invalid, it doesn't really matter to the radio chip what the processor does with them.

That's probably the explanation. Clock and MISO are also inactive during the MOSI activity. In any case it won't affect the radio chip.

SeByDocKy wrote: Is the YD717 protocol have been updated since NB from 10 juanuary ?.
With the 26 juanuary build, the same problem

The 26 Jan version has the latest YD717, but as mentioned I don't think it will bind.

For testing I'll make a YD717 version that has a protocol option to support the Syma X4. If you're not building from source I can make a dfu file for you. Is that a Devo 7e radio?

Still learning myself, but I think a new yd717.mod file is all that's needed to try this on a 7e. Please copy this file to the protocol directory on your radio (after saving the yd717.mod that's already in there!).

Select YD717 protocol and click ENT to bring up the options. Change Model to Syma X4. Then click re-init and power up the Syma. Hopefully it will bind. There are still two minor differences in the bind process but they shouldn't matter.

One thing in your video is concerning. The YD717 protocol should stay in bind mode until successful, but it looks like the bind notice on your screen disappears as soon as it starts. Are you flying any nRF24L01 protocols successfully? I killed my nRF module with static and now the bind mode ends as soon as it starts, resulting in the same behavior as in your video.

I've included an annotated SPI capture. It was almost a complete copy/paste from the YD717 version.

Looks like at least the throttle channel should be in the correct spot. Not sure about the others.

hexfet wrote: Still learning myself, but I think a new yd717.mod file is all that's needed to try this on a 7e. Please copy this file to the protocol directory on your radio (after saving the yd717.mod that's already in there!).

Select YD717 protocol and click ENT to bring up the options. Change Model to Syma X4. Then click re-init and power up the Syma. Hopefully it will bind. There are still two minor differences in the bind process but they shouldn't matter.

One thing in your video is concerning. The YD717 protocol should stay in bind mode until successful, but it looks like the bind notice on your screen disappears as soon as it starts. Are you flying any nRF24L01 protocols successfully? I killed my nRF module with static and now the bind mode ends as soon as it starts, resulting in the same behavior as in your video.

I've included an annotated SPI capture. It was almost a complete copy/paste from the YD717 version.

Looks like at least the throttle channel should be in the correct spot. Not sure about the others.

File Attachment:

File Name: SymaX4module.zip
File Size:55 KB

Yes my nRF24L01+ is working perfectly with my V2x2 quad for example.

Ok I will test your mod now .... feedback in few minutes

Strange ... I can't bind or re-init at all ... no action at all ...


Very strange ...

Did you installed the last Nightly build before ?


EDIT . Your YD717 seems to not be compatible with my current .dfu and or for devo7E