Mjx Bugs 3H

This topic started on the 25th page of the MJX Bugs 3 topic, but since they are very different, here is the new topic for this bird.

Here is the first capture, the bind should be in there somewhere. I made it with DSView 0.9.8 on a mac.

Unfortunately I couldn't use any proper triggering because the thing just keeps talking to the rf module. If someone can tell me what to look for I can try to set up the trigger so it starts capturing after a certain data string or value. The channels are CH0:CSN|CH1:SCK|CH2:MOSI|CH3:IRQ|CH4:TXen|CH5:RXen

You need to record from the TX power on so we can see the init.
Also you need to do multiple dumps in separate files:
- bind
- aileron center/left/center/right center
- same for elevator, rudder, throttle
- any feature button

aszasza wrote: Here is the first capture, the bind should be in there somewhere. I made it with DSView 0.9.8 on a mac.

Strangely DSView "SPI protocol" exports only the decoded bytes with an ID incrementing every byte instead of every instructions (every starts of CSN).
I'll need to rewrite my decoder so it just decode the stream instead of looking at the instructions.

Don't bother I've just ordered one of those 10 dollar analyzers, that should work with the saleae sw, 24 mhz is plenty here. Until that arrives I'll give sigrok a go, maybe that has better decoders.

Can you at least give a go at recoding from TX power on with your current setup?

I messed up big time. As I was taking the remote apart one the solder tabs of the battery holder touched some random trace on the pcb and the radio don't seem to bind ever since. My suspect is the XN297L Chip itself, because the radio turns on, beeps and behaves like normal, but there is no activity on the IRQ line of the radio module. I think that the mcu is okay in the radio because it is trying to communicate with the module but never gets any reply. Is there any place to buy this chip? or a cheap toy drone that is known to be using the XN297L?

This little accident really bugs me(pun intended), so I decided to get a cx-10 from amazon, its around 15 bucks and should arrive on friday. I just hope that it has the right chip. If not, its just gonna be for my girlfriend lol.

The bugs 3 mini shares that chip also according to Goebish,the receiver is on ebay for around 12-15 USD.

Thanks! I've ordered one of those as well. The CX-10 uses an all in one chip, they must have optimised the manufacturing costs with that. I've also ordered a CX-10D and an x-lite radio with the mpm module so I should be able to test if the protocol works once its implemented. Now I just need to wait for the stuff to arrive.

Can you still do the TX from power on?
There is a big chance that the radio is not checking three response of the xn297l.

I can, yes. I'm working til late every day but I'll try to do it as soon as possible. In the meantime, the CX-10D came and it has an XL297 but not the L version. (both the quad and the tx)Do you think if it will still work? I couldn't find the proper datasheets for them, so I can not compare the registers. Should I try to replace it?

The "L" version has additional/different config registers...

so basically its not gonna work for me.

Most likely. But I still haven't seen the boot and config...

Here are 2 captures, one with the faulty radio module still in place and the other one is without the radio module. I know that dsview is annoying, I'm gonna try to do a capture with saleae as well soon.

Okay, I've done a capture with logic as well, here it is. This is with the radio module fitted back.

Aaaaand here it is with the XL297 just wired in crudely for testing.

Good news, I've managed to fix my TX, and also made some captures. here they are.

I've started to look at the packet structure for the normal mode. It's different compared to the BUGS3 protocol while having similarities.
AILERON, THROTTLE, ELEVATOR, RUDDER values are 0..500.
packet[0]=checksum=packet[1]^..^packet[23]^0x6D <-same as BUGS3
packet[1..3]=TX ID=0x20,0x28,0xBA
packet[4]=THROTTLE>>1=0x00..0xFA
packet[5]=RUDDER>>1=0x00..0x7D..0xFA
packet[6]=ELEVATOR>>1=0x00..0x7D..0xFA
packet[7]=AILERON>>1=0x00..0x7D..0xFA
packet[8]=0x20|AILERON<<7 <- hard to determine exactly since the stick is moving too fast but most likely
packet[9]=0x20|ELEVATOR<<7 <- hard to determine exactly since the stick is moving too fast but most likely
packet[10]=0x20|RUDDER<<7 <- hard to determine exactly since the stick is moving too fast but most likely
packet[11]=0x4E|THROTTLE<<7 <- hard to determine exactly since the stick is moving too fast but most likely
packet[12]=alternates on each packet between:0x00=first packet on RF channel and 0x40=second packet <-looks like change_channel variable of BUGS3, default value 0x86, 0x04 low/high mode, 0x01 picture
packet[13]=flags 0x80=lights, 0x40=arm/0x20=disarm needs to be looked at again, 0x02 and 0x04 pro to altitude 0x00->0x02->0x06 needs to be looked at again
packet[14]=0x00
packet[15]=0x53 <- unknown
packet[16..23]=0x00

Packets are sent every 6840µs.

Bind: NRF_ADDR=0x6D,0x6A,0x78,0x52,0x43 Hopping=0x11,0x1A,0x23,0x2C,0x35,0x17,0x20,0x29,0x32,0x3B,0x14,0x1D,0x26,0x2F,0x38
Normal: NRF_ADDR=0x25,0xB3,0x25,0x3E,0x73 Hopping=0x13,0x25,0x37,0x1F,0x31,0x17,0x28,0x3A,0x1C,0x2E,0x22,0x33,0x19,0x2B,0x3D

Every 13 packets a packet of 16 bytes is received from the model.
rx_packet[0]=CRC somewhat of a sum of something + RSSI
rx_packet[1]=NRF_ADDR[0]
rx_packet[2]=NRF_ADDR[2]
rx_packet[3]=RSSI?

Pascal