Mjx Bugs 3

Done. Let me know if you need more captures

Progress! The quad is receiving the bind packets from deviation, but is not responding. CRC is good so maybe something wrong with the data. The only differences from stock tx are in the control channels. New test build (a5a0a6a) now forces the "correct" values during bind. Please make a capture with this version.

This looks extremely promising. Upon bind. the quad lights goes steady immediately!

Capture attached!

Another step forward. The quad is now responding to the bind packet, and deviation receives the response. They both enter the data phase and the quad receives the data packets, but is not responding. Next step is to figure out why. First guess is the non-zero channel values.

Can you confirm that deviation exits the bind dialog with version a5a0a6a?

Test build is updated (c8c0bf8). The code now continues forcing the idle values on the data channels until armed. The algorithm to calculate the channel values is also changed to ensure it covers the full possible range.

Please make a capture of binding to this version. If deviation does exit the bind dialog, then send a positive value on channel 5 (props removed) and see if anything happens. Please capture this whole sequence.

yes i confirm that deviation exits binds mode, once i power up the quad.

quad light stays steady instead of flashing.
The back lights (blue led) even flashed once but motors did not armed. (Bugs blue led comes on when armed, and off when disarmed)

But unfortunately i tried but unable to arm the quad with the switches.

Several things in play here so need to do some experiments. Have two tests in the new test build (0a6fb8d).

First set the fixed id to an odd number and try to bind. Just need to know if deviation exits bind mode or not. This is to determine if the A7105 will automatically exit receive mode if the packet has fewer bytes than configured FIFO size.

Next set the fixed id to an even number and make a capture of binding and trying to arm. The packet timing is changed to try to better match the receiver.

Have tested deviation-t8sg-v5.0.0-0a6fb8d.dfu First with fixed id 123457, then again with 123456.
I had the Tx ready to bind, then turned on the Bugs 3. I then pressed ENT on the Tx to initiate the bind.
In both cases the front flashing LEDs on the Bugs 3 went to solid on with a few seconds, indicating that the Bugs had received from the Tx.
However, in both cases, Deviation did not complete the bind by exiting from the bind screen.
The Tx continued to display "Bing B3.. Press ENT to stop."

Thats Bind not Bing, as you've probably guessed ...

Try putting deviation in bind mode, then apply power to the quad. Or the new timing may not be working - the capture will show.

ok, when i set Fixed id to 111111 and bind. The TX bind screen did not go away.
The quad lights does go steady.
Activating channel switches has no effect.

Fixed ID to 123456 and bind. TX bind screen goes away.
The quad light goes steady.

Activating Ch6 and Ch7 makes the quad light goes back flashing.


video for your reference.

Thanks. Please make the same odd/even fixed id tests on the new test build (f5aaf53). Added code to change the fifo end pointer so the rx will auto-complete when a packet is received. The control and telemetry packets are not the same length.

Also changed the timing some more. The rx is missing every other packet due to some problem in the send timing. The stock hardware uses external signals to help control the chip and those are not available to deviation.

The extra channels are (probably):
5 - arm
6 - LEDs
7 - Picture

Now with both FIXED ID 111111 and 123456
bind mode exit immediately upon bind.
activating channel 6 and channel 7 causes led lights to flash.


Just thinking out loud here.
stock tx has the ability to calibrate the gyro/acel (not sure which) by having the both sticks down to bottom right.
However with my jumper, i couldn't get the calibration to work.
and the reason is probably the sticks values is not close enough for the calibration mode to activate.

Stock tx when Arming the quad. it cannot arm when the throttle is not all the way to the bottom. so its probably the same throttle settings is not in n that "Arming allowed" condition yet.
i think if we can't figure out the minimum stick values, we probably wouldn't be able to arm the quad.

Until channel 5 is set to a value greater than zero the channel values are all forced to zero. Perhaps we'll need to check if changing that to just forcing the throttle value still works for binding and would allow calibration without arming.

Would you please try setting channel 5 greater than zero and see if it arms?

It looks like maybe the packets are being missed because one of the "alternating" bits in the protocol packet is telling the rx when to change frequencies. Need to look at the captures some more to decide what to change but will need some more tests to be sure.

I tried, intermittently i can get it to arm. probably 1 in 100 attempts.

sometimes my throttle has to be at 50% sometimes at 0%. its not like something i can always do. most of the time just switching the channel 5 don't work.
there is some sort of combination for the quad to arm.
there was once i had channel 5 up while in bind mode and power on the quad, quad bound and armed at the same time. which i was not able to replicate the scenario again..

Also after arming i can't do anything. all stick has no controls. throttle, pitch, yaw, roll nothing.

and if it arms for 10 seconds. it automatically disarms itself. probably due to quads safety feature or something

i was trying to capture the data but its not easy to trigger it

Please make a capture binding with the new test build (21bc73b). Made a change to try to fix the problem of missing every other packet.

Not sure yet about the issue with arming. Will try to find something in the existing captures.

Went back to look at the capture for throttle/yaw/pitch/roll and noticed more than one byte in the data packet changing for each channel. It's not obvious how to combine them. It seems like an extra 6 or 8 bits (in two different bytes) for throttle, and either 2 or 4 bits for other channels. That seems needlessly complicated which means it may not be right. Would you please make 4 captures with the stock tx, one for each of AETR (capture the data on the rx). Move each stick slowly (around 4 seconds) through full travel. Try to move the stick only along one axis as it looks like some of the extra bits may be shared (could be flags of some sort).

Great work fellas,wish I can help.I just ordered the bugs 3 mini and will take captures and submit them for any future interest.These flysky protocols are coded very difficult according to these posts.

Okay, uploaded. Thanks Hexfet, for putting so much effort in helping decipher the codes. wish i can buy u a beer or something hehe

Have tested deviation-t8sg-v5.0.0-21bc73b.dfu with fixed id 123456 and then 123457.

I had the Jumper Tx waiting in bind mode displaying "Bind B3.. Press ENT to stop."
When I turned on the Bugs 3, Deviation left the waiting to bind screen,
and the front flashing LEDs on the Bugs 3 went to steady on immediately.

As with the MJX Tx, the front left and the right rear props quivered very briefly.
However resetting channel 5 and then channel 6 from -100 to +100 had no visible effect on the Bugs 3.

Thanks for the testing. This is more fun than sudoku puzzles

The packet timing now looks good - the receiver is getting every packet. I think we're done with the bind phase and packet timing.

The new stock tx captures are helpful. They show the channel values are 10 bits instead of the 8 that was previous coded. The lowest two bits of each channel are packed into data packet byte 14. The protocol code is updated to support this.

Those captures also showed the lower 6 bits of packet byte 0 changing every time the other bytes in the packet changed, so it's likely a parity or checksum value. Running the data through reveng gave a suggestion of "CRC-8/DARC". But since there's only 6 bits for CRC that may not be correct. Need to code up some more tests on this data, so don't need any more captures right now.

This might explain why arming sometimes works. It could be when the check value happens to be correct. Currently it's always set to a fixed value which is correct for the forced idle data values. But most of the time doesn't work because the check value is not correct.

Good to know that you're having fun, hexfet - you have a growing group of fans who appreciate your work.

I'm currently down to one flying Bugs 3 at the moment, having snapped an arm off my one year old Bugs when I lost connection after foolishly flying behind a big tree.

However, I've ordered another one, plus a bottom frame to attempt a repair, confident that you're about to empower the dream of flying all my models using one Tx. I hope MJX haven't made any changes to Tx or Rx since I bought my last one. Should soon know.