Mjx Bugs 3

Yes I agree flybuy,much Kudos to hexfet we truly appreciate your hard work and your humble approach.

Hi hexfet, I downloaded the latest test version (deviation-t8sg-v4.0.1-43c6c86), and flashed the dfu file. Before my USB Port failed, I'd been testing earlier builds. I think the most recent previous version was deviation-t8sg-v5.0.0-372d1cf. Do I need to copy any files across in USB mode after flashing the dfu file, or are you only making changes within the dfu file? Another question based on my limited understanding of the development process is mild curiosity as to why you are working from version 4.0.1 rather than 5.0.0

And as for all of us hoping for a positive outcome, I salute your effort and willingness to work on the Bugs 3 protocol. I'll start putting up video of my binding attempts soon.

Just the dfu needs to be installed on the t8sg. The test builds are up-to-date with the master branch, which means they're based on 5.0.0. The zips were marked 4.0.1 due to a technical glitch (had to fetch the tag) and will be marked 5.0.0 in the future.

Appreciate the kind words and everyone's patience. Probably tomorrow or Friday before the next test build.

Thank hexfet for all the hard work, effort and time you put in for this. A million thanks!

The test builds are updated. Found a couple of things to change in the bind sequence. Also changed channel 5 to control arming (motors off/on). If it does bind set channel 5 to greater than 0 to start the motors. LED control is moved to channel 6 and picture to channel 7.

The way the bind sequence works implies more captures are going to be needed before we can be successful. Is anyone else able to make SPI captures ( how-to here )?

When binding the tx transmits with txid and channels set to one set of values. All bugs3 listen to the same txid/channels to get the bind data. The aircraft then sends a id packet to the tx that contains an identifier. When the tx receives that packet it starts transmitting data packets with a new txid and new set of channels. What we have to figure out is how the new txid and channels are determined.

If it's based on something transmitted in the bind packets then all aircraft should respond the same and the bind should work at least with the values of txid/channels from the spi captures. That's the best scenario. Alternatively the new txid/channels could be based on the data sent in the id packet from the rx to tx. In that case we'll have to figure out the algorithm for determining the txid/channels from the data received from the rx which is generally difficult.

The data from the current spi captures is bind txid:channels 0xac59a453: {0x1d, 0x3b, 0x4d, 0x29, 0x11, 0x2d, 0x63}
The rx responds with id packet with first four bytes 0x1d, 0x5b, 0x2c, 0x7f.
Then the tx switches to txid:channels 0x56926d94: {0x27, 0x4b, 0x1c, 0x63, 0x25, 0x0a, 0x57}

Hi Hexfet, had a play with the latest build, but no luck so far. I put a video up of the steps I took. The first minute just shows the normal power up sequence for both my older and newer Bugs 3, which seems the same - about 33 secs to get to solid white LEDs. Next, I show a normal bind and engine start with the standard MJX TX. Then I try two different attempts to bind to the Jumper. Finally, I load another model and power up an Eachine E011, just to show the Jumper works, and that I have a rough idea of how to use it.

I can try to perform a capture but first i need to buy a logic analyser thats gonna take sometime though

Below is my test using the new dfu. Oddly everything is reverse

Thanks for the testing. I'll see what I can come up with for the next test build.

Blade, what version string is displayed when you first turn on the t8sg? I just installed the test build on mine and the display orientation is correct.

hexfet wrote: Thanks for the testing. I'll see what I can come up with for the next test build.

Blade, what version string is displayed when you first turn on the t8sg? I just installed the test build on mine and the display orientation is correct.

Thank you. Btw i ordered a logical analyser but it probably take 2 weeks or so to arrive. Gotta borrow a multimeter from my colleagues in the electrical workshop by than.
As for the reverse screen issue i think i know whats wrong and it is entirely my fault as i flash the wrong firmware meant for devo build by mistake. Luckily the tx didnt brick. I retried the test with the correct firmware but it is still the same results though.

I turned on my Jumper with my Bugs 3 model loaded, and then hit "Bind". I then powered up the Bugs 3. After the usual 33 secs I had solid white LEDs on the Bugs, but the Jumper was still waiting to Bind. I then turned my Bugs TX on, but nothing happened. I then turned the Jumper off. I then had to power down the Bugs 3, turn the Bugs TX off and on, then power up the Bugs 3 again to bind, and use the red button to spin up the props. I repeated this process with my newer Bugs 3, using the other Bugs TX that came with it, and got the same result.

Based on these tests, I don't see any evidence that the current test model is getting any response from the Bugs 3. Sorry if this might sound a bit negative - I'm just trying to provide as clear a picture of the results of my testing as I can. Happy to keep testing for as long as everyone is trying to get this working.

My alternative would be to replace the FCB with an F3 or F4 FCB and try to set it up with Betaflight. I'm not looking forward to trying that, as there are so many unknowns in the process.

Test builds are updated (ce4241b). Found one change to make in the command sequence. Also updated the packet timings slightly.

Being explicit is a good thing. It helps in keeping all the puzzle pieces straight.

Searching for more info it seems replacement receiver boards come in two versions . Didn't see any information if either will work with any stock transmitter Does anyone know if all bugs3 transmitters can control all bugs3 quads?

Not quite there yet. One change noticed - when I have the "Bind" option hi lighted and press the ENT button, nothing appears to change - I don't see the next screen saying "Binding ... etc.
However, sometimes I get a tone a few secs after pressing ENT. The Bugs 3 still does not react.

Both of my BUgs 3 have the later A2 boards.

That might be the problem,I had the original bugs 3 I think it was the a1 board,I brought it from Tomtop.

They might still use the same protocol, but no way to tell unless someone knows if the transmitters are compatible.

Test builds are updated (c4ef83d). Learned a little more about the a7105 and made some adjustments. Now trying to check the data received from the quad, but not entirely sure what to be looking for. Can any of y'all make a serial capture from the trainer port? You'd need an FTDI adapter and a special build I'd make.

No reaction from my Bugs 3 to the deviation-t8sg-v5.0.0-c4ef83d build, either while waiting to bind, or after I turned the Jumper off. I watched the LEDs when turning off, as I get flashing when I turn off the MJX Bugs 3 TX. However, the TX now displays the "Binding B3 ... " message after I press the ENT button with the "Bind" option hi lighted again.

Did a test with the new build. Still the same resulta

Can't find any more changes to try right now. Did not find anything definitive online about whether the A1 and A2 versions of the receiver board use the same protocol. Need some more spi captures from other transmitters. I ordered an A2 version receiver board which will help but won't arrive for 6-8 weeks.

Thanks for the update, hexfet. I'll be patiently waiting for the next development.
How will you use the A2 FCB? Do you have one or more escs and motors to wire up to it?

Mainly interested in spi captures from the receiver, but I have old parts around to use if necessary. If the receiver does base the frequencies used on the txid then it's possible to use the receiver board to get responses to many different txids so we can find the pattern.

what up Mods... I so wish the Bugs3 will bind.. let me know if i cna do anyting...