Mjx Bugs 3

Hi HexFet,

sorry i have been rather busy
below is the video of using af8868a test build


summary, Arming, LED lights,NONE, Flip button is present and works.

unable to change speed rate
quads takes off center, no trim required


is DF75601 test build

Arming, Led lights, Flip, Speed mode
Quad takes of, yawing left, rolling left, pitching front.
i had trim all the extremes but still off centered.

Been away for a bit. My "new" Bugs 3 arrived, and I get the same response as the older two with build deviation-t8sg-v5.0.0-af8868a.dfu.
The new Bugs would not at first bind using the Tx from my oldest Bugs 3, but bound OK with the newer Tx, and would then bind with the older Tx.
I have not used the Tx that came with the new Bugs 3. (Pity postage from Australia to USA is so expensive.) Looks the same as the Tx from the second Bugs 3.
The "new" Bugs has V04 M2504-RX 2017/03/02 stamped on the fcb, but looks almost the same as the older fcb, apart from forward facing front
sockets. Pics attached.

Thanks for the updates. Blade81, based on that testing I'll leave the trims alone. There won't be a channel for speed rate in deviation. The bugs3 should be in "expert" mode all the time and then mixers can be used to reduce rates if desired.

davdrone1, the board I have is the V04. When you say the old tx would bind after binding to the new tx, do you mean going through the bind procedure in both cases (holding down the button while powering on the tx)? Or is it that the old tx will connect with the new bugs3 after binding it to the new tx?

Should I stilll send the older tx hexfet?I thought there was 1 tx for every version davdrone1.

Forgot to address the comment from kaseym. It would probably be best to use a tx that we know is a recent version. The A1 version tx may not use the same algorithm for radio id. I'll send a pm to kaseym to see if we can set something up.

Ok,thanks for the heads up..My bugs 3 mini came in about a day ago also,I'm going to order an extra tx and I'm looking for the receiver.

hexfet, Yes, I went through the bind procedure (holding down the red button while powering on the tx) in all 3 cases. I have not used the Tx that came with my latest V04 Bugs 3. I first tried to bind the V04 with my oldest Bugs 3 Tx that I bought over a year ago. It appeared to bind, but would not start when I pressed the red button. I then tried to bind with the Tx from the second Bugs I bought about 9 months ago. That worked. I then tried again with the one year old Tx, and after having been "activated?" by the 9 mth old Tx it worked. Confusing, but it means that there must be only minor changes from the older models up to the V04 version.

My oldest Bugs 3 Tx has a moveable black button described as "[3] Reversed for new functions" on Page 7 of the manual. Both the later Txs have dummy white switches that can not be moved.

That is not the case currently. the other time i took it out and fly i notice the drone is flying at the low rate, shoukd i recapture everything in high speed mode instead?

hextfet, I have now bound and started the motors of both the new and the 9 month old Bugs 3 with the newest Tx (labelled B3). I can't test the one year old Bugs 3 until I transplant the rmains into the new shell. I've retired the original Tx with it's mysterious moveable black button. As you can see from the photo, I found the arming process confusing when I first started flying quads.

It would be unusual for binding with one tx to affect the ability to bind with another, but maybe. No more captures needed right now thanks.

Today the tx from kaseym arrived. It does bind with my FC. The radio id is the same as when binding with deviation, confirming the radio id is determined by the receiver. In the packets from the receiver there appears to be one byte for an RSSI value. Another two bytes appear to be for the low voltage alarm which is strange because it doesn't seem to be a voltage measurement - the value is ff87 for battery good and 0100 for battery low.

Still have to create the test jig and work has gotten busy but expect to make progress over the next couple weeks.

The attached file has the bugs3 rxid to radio id mapping. I haven't looked at the data much yet, but there are repeated values and some apparent regularity. The known values from previous captures are correct. (Also a couple rows missing judging by line count, haven't tried to find which ones yet) Anyone know what math to use to find the mapping function? I usually just fiddle with the numbers and hope for inspiration. Post here if you spot the pattern

hexfet wrote: The attached file has the bugs3 rxid to radio id mapping. I haven't looked at the data much yet, but there are repeated values and some apparent regularity...

Complete novice here (so probably saying something obvious) but the repeated radio IDs seem to repeat every 255

Attached file adds the missing two lines and cleans up a couple lines with format issues.

Repeats every 255 except the interval between the first appearance and the second is 511 (at least for the first two radio id's). I'm sure that says something about the underlying algorithm but not sure what

Hello,

I own one of these birds, hence I am very excited about this development. I tried DF75601, tx and rx have seen each other, but I could not arm it. So I am not sure how much the reverse engineering of this map will help my case.

But I was playing a bit with the map. Frequency analysis (whatever it means) of the values shows that it is almost periodic with period 255, those 255 values should be picked with some care. This already results 3/4 of the map. (Yes there is a lot of irregularities.) Pieces of this 255 long sequence can be shifted by 1 forward or backward according to a pattern, that matches almost all of the remaining 1/4. There is a hiccup for about 30 places, those irregular values can be further stored. So, the data for the map can be encoded in less than 2kB. I did not analyze it further, am I am not sure how useful is this or how much worth. Is the goal to store it in a very small place to fit into the firmware, or we need a definition of the function without excessive lookup tables? The function might actually be very simple, but simple or very complicated to decipher. Anyway, I do not see it right now. For an experiment (you will not like this) in java see https://bitbucket.org/mmakai/bugs3 .

Thanks for looking! The behavior you describe is due to binding working but deviation doesn't know the correct radio id to use, so finding an algorithm for this mapping will definitely help you. I can add a bit more information from tests I've been making.

There are 256 unique radio ids. The 256 unique radio ids are not all used equally. A majority (216) appear 256 times, while 20 other values occur 255 times and 20 more 257 times. Neither the difference or the quotient of adjacent numbers is a constant. I tried running the numbers through reveng in various ways but it never recognized a polynomial which I think means the sequence doesn't come from an LFSR (though I haven't tried to use reveng in this way before). Don't really feel any closer to finding the algorithm.

But there is a way to get people flying Test build (7867ad5) is updated. This build uses the deviation fixed id to allow manual configuration of the radio id. The attached file has the rxid->radio id correspondence in two formats. The .txt file is hex and the .csv file is decimal.

Here's the bind procedure:
1) In the bugs3 model delete all the digits of the fixed id. The display should say fixed id None.
2) Click Bind on the model screen.
3) Apply power to the bugs3. The bugs3 should react but deviation bind dialog will remain.
4) Turn the transmitter off (this saves the model with rxid stored in the fixed id).
5) Turn the transmitter on, go to the model screen, and read the fixed id.
6) In the bugs3_rxid_radioid.csv file, find the fixed id number on the left. The number after the comma is the radio id. Enter it as the fixed id in the model. If it is negative it must be changed by editing the model file.
7) With the correct radio id value set as the fixed id the bugs3 and transmitter should connect when powered up.


Won't have much time the next few weeks so this can suffice for now. Hopefully someone will crack the code.

Thanks for the explanation, as well I understand if you do not have more time to this project in the coming days.

I found a small good sign. In my finding of interlacing two periodic sequences to result the 65536 long sequence, there were 30 errors. The 8 changes in your v3 reading compared to v2 fix 8 of those 30, leaving 22 only cases. So v3 is probably more precise. But I did not find yet anything though to crack the key 255 long sequence.

I think finding the full sequence is key. With that we can figure out how to make the shifts work. But really can't afford 1K to store the whole sequence.

Were you able to get flying with the procedure above?

Hi hexfet, tried the bind procedure. Got to step 5 OK, reading a fixed id of 45334.
Did a lookup on your .csv file, and matched that to 1446417739
Tried to enter this number into the Fixed ID field on the Jumper.
The Jumper only allowed the first 6 digits to be entered.

Have I misunderstood the process?

Screenshots attached.

That's the right process. Please try editing the model ini file and entering the number directly there. I had checked that a longer number is displayed correctly. But since the fixed ID for my receiver is negative I had only ever entered it completely by editing the file.

It Works!

The switch I've assigned starts the motors, and the throttle appears to bring up the power smoothly.
A second switch turns the LEDs on and off. It's night here now, but in the morning I'll try a test flight and report back.
If all goes well I'll make a video to get the word out.

Thanks, hexfet!