Supporting OMP Hobby M2 Native Protocol

[richardclli]

Just want to see if anybody interested in working out the native protocol for OMP Hobby M2 helicopter. I do not have much information yet. And not sure if anybody working on this protocol.

[pascallanger]

I don't have access to a TX/RX so nothing will happen on my end.

[richardclli]

Well, anyway, I just want to see if anybody interested. Since, it seems the native protocol have telemetry of voltage feedback as well.

[pascallanger]

I don't think anyone will jump here since they are using the forum instead. If you have the original remote why don't you go ahead and open it up so we can see what RF chip is used and may be start to do some dumps?

[richardclli]

I will try to work out some details on this protocol once I have got the radio.

[richardclli]

Just got the radio hardware, the wireless chip is XN297LCU, seems this chip is not present in the 4in1 or 5in1 module.......

[pascallanger]

It is supported by the 4in1. Start doing dumps.

[richardclli]

Here is my first dump. The dump starts before switch on the radio, and ends after the radio finished initialized.

OMP-SwitchOn.xlsx

[richardclli]

This the the dump during binding:

1. Make the Heli in binding mode
2. Start capture
3. Switch on radio
4. End capture when bind success.

OMP-Bind.xlsx

[richardclli]

The radio has telemetry as well, only voltage feedback.

[richardclli]

Capture for some stick movement.

OMP-Sticks.xlsx

[pascallanger]

The excel files you are sharing are not exploitable.... You need to share the logic files.

[pascallanger]

I can't do anything with these files something is wrong... I need the logic analyzer files to see what you've done...

[richardclli]

These files are decoded SPI data. I used the setup as per XN297L datasheet, CS low activate, SCK rise edge, data MSB first. I also added coloring to separate the communication steps by long idle timing.

I can attach a raw dump here, but not sure if you can read it. I use DSView and it can save raw timing files that can store the waveform captured. Or you may suggest a format that is good to you. Will work this out when I have some spare time later.

[pascallanger]

Sorry but these excel files are shitty. Please share the original dsview files.

[richardclli]

Alright, here you are, see if it helps. I do this:

1. Set receiver in bind mode.
2. Start capture
3. Switch on transmitter
4. Wait until bind done
5. Move Ele/Ail Stick
6. Stop capture

Please rename the file and remove the ".zip".

DSLogic-la-200811-034819.dsl.zip

[richardclli]

Seems some commands are not recognized properly. I have updated the nrf24l01 decoder for xn297 chip. You may put this in the decoder folder to replace the old one.

nrf24l01.zip

[pascallanger]

Using the dsview file I can now fully decode the SPI:

• Bitrate: 250Kbps
• Scramble: enabled
• Enhanced: enabled
• Auto ack: enabled
• Bind address: "FLPBD" not sure what it means...
• Normal address: 0x4E, 0x72, 0x8E, 0x70, 0x62 which is part of the bind packet
• Hopping frequencies are in the bind packet
• ...

I hope the auto ack used during bind and some normal packets is not needed for the protocol to work since we can't emulate it...

[pascallanger]

Bind:

• RF channel 0x23=35
• Address: 46 4C 50 42 44 = "FLPBD" BD=BIND?
• Period: 4410µs
• TX
  • 18 times: P(16) = 42 4E 44 4E 72 8E 70 62 0F 14 19 1E 23 28 2D 32
  • 42 4E 44 : "BND"
  • 4E 72 8E 70 62 : normal packet address
  • 0F 14 19 1E 23 28 2D 32 : 8 RF channels used for normal packets
• RX
  • 12 times: P(16) = 46 4C 50 53 4B 0 0 0 0 0 0 0 0 0 0 1
  • nearly the bind address: 46 4C 50 53 4B = "FLPSK" SK=??
  • 4 times: P(16) = 42 4E 44 4E 72 8E 70 62 F 14 19 1E 23 28 2D 32
    • sends back what the TX is sending
  • The RX packets are using the auto ack feature which can't be emulated. We can't receive them.

[pascallanger]

For the normal packets, I would need separate dsview file for:

• each stick Aileron, Elevator, Throttle, Rudder with what has been done example: AIL_MID_LEFT_RIGHT
• each feature button like flight modes, rates...

[pascallanger]

Normal:

• RF hopping table: 0F 14 19 1E 23 28 2D 32, note this is (i+3)*5
• Period : 4995µs
• Address: 4E 72 8E 70 62
• P(16)= 00 08 40 00 00 00 00 00 A8 A1 FC 20 08 00 00 04
  • 00 : index of current hopping 0..7, |0x40 every 7 requesting telemetry from the RX
  • 08 : unknown switch to 28 after the first 10 packets
  • 40 00 00 00 00 00 : unknown and not moving in the single dump...
  • A8 A1 FC 20 : contains the ele/ail stick info but unknown since I don't know what has moved when...
  • 08 00 00 04 : unknown and not moving in the single dump... Can't do anything more without the additional requested dumps...

[richardclli]

Will try to do dumps of each channel when I am available.

For the normal packets, I would need separate dsview file for:

* each stick Aileron, Elevator, Throttle, Rudder with what has been done example: AIL_MID_LEFT_RIGHT

* each feature button like flight modes, rates...

[richardclli]

I have done your requested dumps, the first dump is the default.dsl with the following settings and I change one switch/stick to worked out another dump:

IDLE=0 MODE=Alt D/R=70% HOLD=Release Thr=down Rud=center Ali=center Ele=center

And I have worked out the telemetry feedback of 3 different battery voltages as well, please see if this is good to you for analysis.

OMP-M2.zip

[pascallanger]

Hummm... From the file names I understand that you have moved elev up took a dump, then elev dow another dump,... Is that it? This is not really what I've asked. But let's see what I can figure out from this.

[pascallanger]

As I was thinking these dumps are not usefull at all. I spent 1 hour looking at them for nothing...

[richardclli]

I think I may figured out something meaningful:

• P(16) = 05084000000000002862FC2E08000004
  • P[7-11] = 002862FC2E
  • P[7] is THR, THR 0% => 0, THR 100% => FF
  • P[11] is RUD, RUD center => 2E, RUD left =>94, RUD right => 0
  • P[8-10] I guess these may control 3 servos independently, that is why it is not straight forward for AIL and ELE movement, but need more study to verify.

Can we start code something for testing? So we can test out how the fields affect the heli movement. I have attached the file that I used for analysis for your reference.

default.xlsx

[richardclli]

Just figured out some more about RUD, maybe P[12] is related to RUD as well, need more test to verify.

[pascallanger]

I've already seen all that. The channels are most likely on 11 or 12 bits that's why you can't see it clearly. There is nothing to code right now. When I will have good dumps to work on then I'll look at it again. I mean why don't you just provide what has been requested since the beginning? We are just loosing time because the dumps are not done correctly. This protocol is damn simple and should have been reversed in less than 20 minutes. But 3 days later we are still talking about dumps.

[richardclli]

You are so amazing, I am finally be able to decode the 4 channels: thr, ail, ele, and rud because of your insight given. P[7-12] are encoded by 11-bit for each channel from P[7] to P[12] as LSB to MSB, trying to work out some more about the switches. From various experiments, pitch is not send to receiver, only 4 channels with some switches.

[richardclli]

P[2]P[1] => 16 bits B[16..0] B[5] = 0 Release, 1 Hold B[11,10] = mode: 0, 1 alt mode; 2 3d mode B[13,6] = idle: 0, 1, 2 (0 no -ve pitch, 1, 2, +ve and -ve pitch)

It looks a bit strange, no sure why the 2 bits idle separates so far.

[richardclli]

Here are some dumps for you to verify:

1. ele down/ail left -> ail mid -> ail right -> ail mid -> ail left -> ele mid -> ele up -> ele mid -> ele down
2. rud left/thr down -> rud mid -> rud right -> rud mid -> rud left -> thr mid -> thr up -> thr mid -> thr down

1-ail-ele.dsl.zip 2-rud-thr.dsl.zip

[richardclli]

For switches: HOLD 0, Mode 0, Idle 0 -> HOLD 1 -> HOLD 0 -> HOLD 1 -> Mode 1 -> Mode 2 -> Mode 1 -> Mode 0 -> Idle 1 -> Idle 2 -> Idle 1 -> Idle 0

switches.dsl.zip

[richardclli]

And for Voltage telemetry: Voltage = 12.6 -> start dump -> gradulate reduce voltage step by step to 10V

tele.dsl.zip

[richardclli]

For telemetry, the received packet R(16), R[3R[2] seems contains the battery voltage information.

[pascallanger]

OMP protocol available in Multi v1.3.1.56.

• Channels and details: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#omp---77
• Try first with a RF tune value of 1
• I haven't tested anything so please test and report but make sure to remove the heli blades...
• For now it's using your current ID, if it works comment out #define FORCE_OMP_ORIGINAL_ID and try again.
• I haven't forced the bind since I don't know if the heli remembers the radio ID or not... To test this power on the radio first, skip the bind and then power on the heli, if you have control it means that the ID/freqs are stored and therefore the current code is ok.

[richardclli]

Thank you!! I will test it out and report to you if this is good or not.

[richardclli]

I tried the followings and not able to bind:

1. Check out code and build bin
2. Flash the Multi 5-in-1
3. Switch on radio
4. Power up OMP M2

It seems not to bind, then I tried to tune the Freq, but still cannot get the bind. Anything missing?

[pascallanger]

I'll have a look but can you answer my previous question about the bind?

[pascallanger]

Try v1.3.1.57, I've fixed something

[richardclli]

• bind successfully with #define FORCE_OMP_ORIGINAL_ID
• remarked #define FORCE_OMP_ORIGINAL_ID can bind successfully with a bind procedure So binding is good now.

After binding, even the stick is moving, the servos will jiggle. Trying to fine tune the freq did not help. However, the stick movements and switches seems functional.

[richardclli]

I figure out the problem in your code. Attached is a fixed version. It looks usable, will try to test more and have a flight this weekend.

After fixing the code the freq tuning need to be non zero to stop the the servos from jiggering.

OMP_nrf24l01.ino.txt

[richardclli]

And I figured out the Ail and Rud are reversed, I revised the code again as follows:

OMP_nrf24l01.ino.txt

[richardclli]

No telemetry yet? It has battery voltage feedback, I think we can add it in using HUB telemetry with only voltage feedback.

[pascallanger]

Try v1.3.1.58. Telemetry won't work with the current emulation layer. In fact, I'm not even sure it's possible... I would need access to the heli to see what can be done.

[richardclli]

The modified code is good to go, it works.

For telemetry, I read the code of the emulation layer, so only the sending is implemented, but not receiving. But by theory, is it possible to implement the receiving as well? I can refine the code if I have some prototype to start with.

[pascallanger]

The problem here is that they have used a special mode to send the data back. Instead of using the traditionnal TX+RX approach, they are using an ack reply. It means that you not only need to figure out how to receive the data and decode it (XN297 is scrambling the data) but you also must be able to turn from TX to RX instantly since the answer over air is really back to back (at least if it's acting like the NRF which the XN297 is based on).

[pascallanger]

FYI I've already written in the past the code to receive a NRF ack reply (which I haven't kept sadly) but it never worked due to the switching time from TX to RX of the NRF in normal mode (ack packet is really sent right at the end of the original packet). Maybe the CC2500 will do better since it is using a bitrate of 250K but that's a lot of work with low chance of success (not saying it's not doable). Is it worth it? And without having the hardware to play with makes it even more a challenge...

[richardclli]

Tonight I used my Jumper T16 to connect to my OMP M2 and found that is is stable even using freq tuning 0. I think Jumper T18 has hardware problem that cause a lot of interference that may cause problems. If using NRF24L01 instead of CC2250, is telemetry possible?

[richardclli]

Test flight yesterday, I used a Jumper T16 to do the test, it is stable with freq tuning at 0, use NRF2401 directly. I flew for around 10 batteries and everything is good. ^.^

[pascallanger]

Ok let's call this protocol done for now. If I ever put my hands on this heli I'll look at the telemetry.