Mjx Bugs 3

my apologies again. i have re-capture with the correct spi settings now,

btw, this test build has some strange behavior.

after arming, my throttle don't react exacting the way i want it, and some times it auto disarm or motor lock itself. not sure if that is flip behavior
for your reference

Unfortunately this capture does not have any packet markers, which usually indicates an issue with the Enable signal. Also please set the SPI format to Hex before exporting. If you'd like to just upload the logicdata file I can try to spot the issue.

I didn't expect this test code to bind so it will be interesting to see what's happening.

oh, i see. i uploaded both capture and global settings

This csv file is fine. Thanks.

The hopping frequencies changed with the change in the (presumed) txid values. The radio id did not change. That's good news in that it's still possible a single receiver might be used to determine the algorithm that determines the hopping frequencies. But it's not encouraging that davdrone1's quad is not controllable as some information in the packet from the receiver may be involved in the algorithm. The bytes returned by the quad in this capture didn't change so each receiver may have a unique id.

A few of the frequencies are the same as with the stock tx txid which is why you have some intermittent control.

We can try to determine what the values in the packets from the quad mean. The user manual says it reports battery low and edge-of-range. First test is to determine if the numbers in the rx data report some value, or if there are just single bits set for battery low and range alarms. We need captures with the battery at various levels, and at various ranges from the tx (but don't change both at the same time). At least one of the captures should be while the stock tx is reporting battery low and edge-of-range alerts. Also please make captures for the trim buttons. Use the af8868a test build for all these captures. This might take some time

Dunno which scenerio can i use the deviation tx for capture? since you mention using a specific test build but rssi lvc doesn't work with my jumper i think

Yep, my mistake...

It looks like there is an analog value for the RSSI. Maybe also for the LVC. It seems to be more than one bit but only two different values are in the captures. That leaves two unchanging bytes that could be a receiver id that's part of the algorithm for selecting hopping channels.

From the trim captures it's clear the trim values are sent in separate bytes so there is the possibility of using driven trims. The captures show the trim values moving in one direction then back to the starting value. Was the capture made while trimming all the way in one direction, then back to center?

Oh i probably didnt perform the trim properly, i press the trim button until the beeps get faster till it ends, than i press the other direction of the trim until the same beeps end. Probably it only re center instead of triming to the right. I will recapture tonight again

my apologies as i was busy the last 2 days and couldn't perform the capture.

Attached is the stock tx trim capture. after trimming, i restarted quad and tx so it should be reset back to non-trim positions

Not a problem. I've updated the test build (df75601) with code to drive the trim values. Not all quads respond well to this technique, so please make a flight comparison between this build and af8868a.

The receiver I ordered will arrive Tuesday so we'll be able to get some comparison captures. If things go well then I'll work on collecting data to see if we can puzzle out the relationship between txid, rxid, and the hopping frequencies.

I received my bugs 3 mini. If I got a logic analyzer would someone be able to help with captures?

Check out the SPI capture guide stickied post in this topic . Captures from more receivers would be helpful.

Blade81, would you please post information on your receiver connections showing which signal is on which pin. Thanks.

hexfet wrote: Check out the SPI capture guide stickied post in this topic . Captures from more receivers would be helpful.

Blade81, would you please post information on your receiver connections showing which signal is on which pin. Thanks.

Thanks, I don't currently own a logic analyzer and it would take some time to ship. Would a raspberry pi 3 be a valid alternative?

EDIT: Ok I found some projects online but unfortunately I don't think they would operate at the right frequency.

I havnt got time to test out the test build yet.

but below is my wiring and logic analyser settings

pardon my amateurish soldering

Thanks, that gave me a head start. The bugs3 receiver arrived early and I've made some captures. There's good news and bad news.

The good news is that the hopping frequencies seem to be completely determined by the txid. Using the txid from Blade81's capture to bind, the receiver listens on the same hopping frequencies as Blade81's. Don't necessarily need to decode the algorithm, we could just always use these frequencies with any receiver.

The bad news is that the radio id used by this receiver is different from Blade81's, which means it's identified by the "rxid" bytes in the rx bind packet. To bind to any receiver we have to decode the algorithm for rxid -> radio id, or capture every single possibility. I think I could build a test rig to do that but I'd need a transmitter and BG says they're restocking.

For anyone that makes a capture I can add your receiver to the protocol and you'll be able to fly. But without the rxid to radio id algorithm or a full dataset we won't have a protocol we can add to the nightly build.

Hexfet I have an extra tx,I will try to ship out this weekend but you will have to sign for it so we can avoid another unfortunate mishap.

Thanks, that would be best. Post office is nearby. Is it an A2 transmitter?

The plan is to write some deviation code to emulate the receiver. It will respond to the stock tx bind packets with all possible rxid values and an spi monitor will check what radio id is then set by the stock tx. The monitor will be automated but it'll take some time to put together.

It's an A1 transmitter but I think I saw something where there is only 1 bugs 3 tx for all versions...

The A1 captures you made only have 7 hopping frequencies where the A2 has 16. But it's possible it uses the same rxid to radio id algorithm as the A2 version. And maybe the A2 receiver is smart enough to use just the 7 frequencies from the A1 transmitter.

I have a Bugs 3 FC and transmitter that I am not using. If they could help move this development along let me know.