What about Assan?

Bisky wrote: Thanks for the info and offer. I think i will switch all receivers to dsm2, sems to be a cheaper option to do.

Regards, Bojan

i think assan use NRF24L01 chip RF cheap . In protocols development on Devo , nrff24l01 very protocol

Bisky wrote: Thanks for the info and offer. I think i will switch all receivers to dsm2, sems to be a cheaper option to do.

Regards, Bojan

Bisky, if you would like to have the Assan protocol developed, you can help by taking photos of the transmitter internals and/or spi trace (see the post by victzh above). Most developers here can help to do it for free, but they don't have the Assan transmitter/receiver to work with. That's why they asked for photos and SPI logs. mwm's offer is an optional paid service provided by him. It doesn't mean that paying is the only way to get the protocol you want. Don't switch all your receivers to dsm2 just yet. Try and see if you can provide the photos that victzh had requested.

PS. I don't mind mwm to provide a paid service and announcing it in a dedicated thread. But advertising the service when some newbie asking for help may have an adverse effect. Just like the case here.

it's been well over a year since this thread was started and still not even something as simple as a couple of photo's from those who want the protocol done have been posted :/

petsmith wrote:

Bisky wrote: Thanks for the info and offer. I think i will switch all receivers to dsm2, sems to be a cheaper option to do.

Regards, Bojan

PS. I don't mind mwm to provide a paid service and announcing it in a dedicated thread. But advertising the service when some newbie asking for help may have an adverse effect. Just like the case here.

Well, I did point out that we needed dumps from a logic analyzer or at least photos of the board to get started before I plugged the service if he didn't want to do those things.

And while I've gotten lots of positive feedback about the service (your comment here is the closest thing to a negative comment I've seen), there are effectively no subscribers, so it's probably going to die once I get healthy enough to be serious about finding a paycheck.

I can make photos of receiver and ppm module, if it's any use. I do not own a logic analyser, How can I help?

I fitted the ppm hack module in a JR style module housing.

Making usefull images is not easy. The RF-Module has two boards soldered together. Imprtant chips got sealed or damaged surfaces to avoid copies;)

Here is some information from a guy who investigated into the ASSAN stuff, in order to give the receivers a CPPM output, Maybe its helpfull:
tomsik.eu/assan_x8_hack
tomsik.eu/assan_firmware

Yes it is difficult to make good pictures. I found a site which has a few good pictures of modules made. I could also help with making better ones of mine module. I also heave a STK500v2 maybe I could read something out? Any suggestions?

radio-commande.com/modifications/comment...24ghz-sur-une-mx16s/

DonKracho wrote: Making usefull images is not easy. The RF-Module has two boards soldered together. Imprtant chips got sealed or damaged surfaces to avoid copies;)

Here is some information from a guy who investigated into the ASSAN stuff, in order to give the receivers a CPPM output, Maybe its helpfull:
tomsik.eu/assan_x8_hack
tomsik.eu/assan_firmware

That RX no bind , and have not any code for Bind .So it useless

So any ideas or suggestions how do we start?

A friend of mine sent me an Assan TX module and an Assan RX. I'll start to work on reversing this protocol soon.
It's using a NRF2401 (without L) so let's see how they use it... The bind is bidirectionnal which hads some complexity in the mix.

Ok, my bench is setup. I have a first extract of the Assan TX module starting up.
For people interrested:
- freq hopping on 2 channels, channel is changing every 12ms. In my TX case 36 (0x24) and ( 67 or 68 or 69 or 70 or 71 or 73 or 74 or 75 or 78). I've haven't seen the first channel moving at all but second channel is changing at each power up. I've captured several power up but the table above 67...78 might not be complete. The second channel seems to move around freq1 * 2 +- 6...
- 2 packets are sent after each channel change spaced by 5ms
- preamble 8 bits
- address on 4 bytes, 2 addresses are used, addresses are linked to the freq change, address2 is equal to address1 +1 on each byte. In my TX case addr1=0x2237FA53 and addr2=0x2338FB54.
- payload on 20 bytes: 2 bytes per channel => 10 channels transmitted with min=0x1EE0,mid=0x2EE0,max=3EE0
- CRC16
- Shockburst enabled

Goesbish have experience with Nrf24l01 . I think he will support if free time

Bind has multiple phases:
- First TX listens on channel 3 with address 0xB8808080 @1Mbps. (SchockBurst, 4 bytes address, 20 bytes of data, CRC16)
- It receives 20 frames from RX with a kind of a counter inside:
frame 0 : 0x08 ... 0x08 0x08 0x0F 0x00
frame 1 : 0x08 ... 0x08 0x08 0x0F 0x01
...
frame 14 : 0x08 ... 0x08 0x08 0x0F 0x0E
frame 15 : 0x08 ... 0x08 0x07 0x0F 0x0F
frame 16 : 0x07 ... 0x07 0x07 0x07 0x10
frame 17 : 0x07 ... 0x07 0x07 0x07 0x11
frame 18 : 0x07 ... 0x07 0x07 0x07 0x12
frame 19 : 0x07 ... 0x07 0x07 0x07 0x13
- After 270ms it switches to TX with address 0xB8808080 and sends 19 identical frames every 22.52ms
0x05...0x05 0x99 TXID
- It sends 1 last frame
0x05...0x05 0x13 TXID
- It does nothing for 520ms...
- It switches to RX on channel 36 using it's own TXID address @250kbps
- It waits for the RX reply which is coming 371ms later with 0x00 0x01 0x02 ... 0x0F and TXID
- It switches to TX
- It waits 2.186 seconds
- It starts the normal frames transmission with channels data

I'm wondering if we could simplify the bind by not listening to the RX but just sending the 0xB8808080 frames during a couple of seconds and then switch to normal TX mode...

I have now enough information from the protocol on what to expect.
I don't know how the channel 36 has been choosen surely based on the TX ID. But I'm afraid I would need multiple dumps to figure that out...

Now I need to spy on air to see how the NRF2401 transmits data and how the CRC is calculated. It would be too good if NRF2401 and NRF24L01+ are using the exact same bits/bytes order and CRC calculation. So let's see.

From the datasheet:
"The nRF24L01 can have the Enhanced ShockBurst™ feature disabled in order to be backward compatible with the nRF2401A, nRF24E1, nRF2402 and nRF24E2.
Disabling the Enhanced ShockBurst™ features is done by setting register EN_AA=0x00 and the ARC = 0."
Which is a good news, it might be really easy then after all

Nice to see some progress planger, but I gave up on Assan. I sold may module along with all receivers.

HI planger,

I'm very happy to hear, that there is progress with Assan, I'm still using Assan, because I've got a lot of receivers, which all work absolutely flawless. So there is no need to replace them and it would be nice to be able to use them directly with the Devo8.

First step done, I can control the Assan RX outputs. Servos are moving smoothly
RX was already binded to the original TX and I've used the same TXID/FREQ of the original transmitter.

Now let's code the bind sequence This will enable me to try different TX IDs.
More to come soon...

- Pascal

I can now bind successfully the Assan RX.

Now I need to find the relation between TXID and RF chan...
Here are 2 real working IDs:
- 0x2237FA53 freq=36
- 0x223FAE0F freq=15 but from tests 18 also works

These tests ones work:
- 0x2237FA52 freq=35
- 0x223FAE10 freq=16
- 0x223FAF0F freq=16
- 0x2240AE0F freq=16
- 0x233FAE0F freq=16
- 0x223FAE0E freq=14
- 0x223FAE0D freq=13
- 0x223EAE0F freq=14
But these tests ones don't:
- 0x2237FA54 freq=37
- 0x223FAE11 freq=17 but from tests freq=19 and 21 works
- 0x223FAE0C freq=12 but from tests freq=8 and 10 works

- Pascal