How to control a Multi 4in1 module with a PC?

[Ralung]

Hello,

I am trying to modify the _config.h file to let my 4 in 1 board start auto binding while I plug it in my laptop or after I upload the code with Arduino IDE.

But I couldn't find a correct place and I am not sure how many file I need to modify to implement the function.

Term	My situation
Multiprotocol code version	v1.3.1.92 (compiling and updating firmware using Arduino IDE)
4 in 1 board	JP 4 in 1 v1.3(c)
Mode	Serial mode
LED status	Slow blink(on=0.5s,off=0.5s) while 4 in 1 board is plugged in USB port of laptop
Drone	E016H
Protocol	E016HV2
Transmitter	RadioMaster TX16s

I have added statement, "AUTOBIND_FLAG_on", in the line 1800 in Multiprotocol.ino file and comment the statement, "#define WAIT_FOR_BIND", in the line 66 in _config.h file, but these didn't work.

The 4 in 1 board was tested to work well before I modified the files. I can use it to fly my drone and it will also start auto binding once I use the "bind on channel" function.

Can anyone give me some suggest about how to modify the _config.h file?

If there are anything unclear, please let me know.

[pascallanger]

You are saying that you are using serial mode to control module. Then just set the bind flag in the serial frame sent to the module.

[Ralung]

Do you mean to send the command from the serial monitor in Arduino IDE?

I couldn't send the commands in Serail/ FTDI Debugging mode, but I got some data from the serial frame.

The following statement showed up when I press bind button or pull down the rebound lever which is the shortcut I set in channel 16 for binding.

P: A0 80 4A 94 4C 4C 4C 4C 00 80 00 F6FC

I don't understand the meaning of each number or letter, but I have tried to send this statement on the top of serial monitor and it didn't work.

What is the correct method to send the serial commands to the 4 in 1 board?

I also found one place that I am confused. I have set the "RF Freq. fine tune" as +20, but it seems to be changed back to +2?

BTW, why does the serial monitor keep blank when I plug the 4 in 1 board directly in the laptop?

[kilrah]

The 2nd byte of the control frame you send to the multi contains the bind bit, if that's 1 the module will go in bind mode.

DIY-Multiprotocol-TX-Module/Multiprotocol/Multiprotocol.h

Line 770 in b516bb8

Stream[1] = sub_protocol|BindBit|RangeCheckBit|AutoBindBit;

If you still haven't figured that out you send that whole 27-36 byte control frame to the module continuously.

[kilrah]

Because I can't send anything in my serial monitor.

If you use realterm you can send frames in hex format.

But you'll need to write your own software to control the module as it's designed to anyway, a serial moitor is of no use.

I first uncomment "MULTI protocol serial definition", which is from line 757 to line 1077 in Multiprotocol.h file.
Then I got errors like:

Why would you do that? It's not code, it's the documentation of the protocol that's there for you to read to know what you need to send to the module.

[Ralung]

Thank you, Mr. Kilrah.

I will search how to use Realterm first, but what is the meaning of "frames"? Is that a kind of commands?
I know how to send commands to Arduino serial port with Python and I will try it after I read the documentation.

Do I need to give another power support when I plug the 4 in 1 board in my laptop with USB port?
Because when I use the USB port of the computer to power the 4 in 1 module, the way the red LED flashes is different from when I use the five pin in the back of my TX16s to power the module.

This is my 4 in 1 module.

[kilrah]

1. You can't control the module through the usb port, you need to give a serial stream to the top pin of the module connector like a radio would using a separate usb-serial adapter (unless there's a debug option available that I don't know of).

2. A data frame is a stream of bytes that correspond to the protocol definition. E.g.
   0x55 0x01 0x00 0x00 0x00 0x04 0x20 0x87 0x07 0x08 0x40 0x00 0x02 0x10 0x80 0x00 0x04 0x20 0x00 0x01 0x08 0x40 0x00 0x02 0x10 0x80 0x08
   sent as raw binary is a valid MP frame, and that's sent periodically, e.g. 100 times per second with the content you need.

See the documentation,
0x55 = "sub_protocol values are 0..31 Stream contains channels"
0x01 = sub_protocol = Flysky, no bind, no range check and no autobind

etc...

[Ralung]

Thank you for telling me so many information!

For the usb-serial adapter, do I need the 3.3v USB-TTL or the 3.3V USBasp Progranner?

Or just a usb adapter which contains Rx pin, Tx pin, 3.3V pin and GND pin?

I also noticed one thing that is you said "give a serial stream to the top pin of module", but the guy who sold me the 4 in 1 board told me that the top pin is for PPM mode.
There is the picture he gave me.

It make me confused that what kind of adapter should I use?
If it is convenient, could you please share me a link?

[kilrah]

The top pin is PPM if the module is in PPM mode, and serial if the module is in serial mode.

[pascallanger]

The module doesn't do anything if it is not receiving a serial stream.
If you switch the module to PPM using the dial and configure the banks in config.h to use the correct protocol then it might send a bind but it will stop shortly if no ppm signal is available.

Anyway what are you trying to achieve?
I have the impression that you want to control the module from your PC?

[Ralung]

The module doesn't do anything if it is not receiving a serial stream.

Does this mean I have to send the command in correct format?
But I tried to send "P: A0 80 4A 94 4C 4C 4C 4C 00 80 00 F6FC" but the module didn't start to bind.

There is no rotary switch and no binding button on my 4 in 1 module, so I tried with serial mode first.
(It is difficult to buy a 4 in 1 board with rotary switch and binding button in where I live.)

Yes, Mr. Pascal.
I would like to control three E016H from my PC and the first step is to control one E016H from my PC.
That is another reason that I prefer to choose serial mode which can send the commands but not the PPM mode which needs a binding button.

If I misunderstand anything, please let me know.
Thank you!

[pascallanger]

By the way, PPM does not need a "binding button"... This is an auto bind protocol meaning that as soon as the protocol is selected (by using the trigger dial position which is just a short between 2 pins) it will send a bind. But anyway...

[Ralung]

Thank you!

[pascallanger]

@goebish you've done something similar for one of your friend. Is there a possibility to share your work? If I remember in your modified version you are sending the commands by USB and have put a work around in place for the bootloader.

[goebish]

The workaround to "skip" the bootloader when starting the module from usb is to run stm32flash, i.e:
stm32flash -g 0x8002000 COM3
(thanks @benlye ;))

[gvalbusa]

@goebish is the code still available? I could not find the file tx_example.py @Ralung mentioned in the next post in your repository.

Thanks for all the code shared

[goebish]

it's on this branch:
https://github.com/goebish/DIY-Multiprotocol-TX-Module/tree/JP4-in-1_USB_Serial_input

[gvalbusa]

Thanks!

[kilrah]

If I understand well it's a school project and figuring it out/writing the associated code or at least finding it themselves is kind of the point of the assignment...

[goebish]

Sorry, I replied to Pascal without reading the thread before ... that's just a crude sample with pretty much everything hardcoded for a specific usage (control 4x RC boats with a single TX module), some work is required for "real world" usage.

[Ralung]

Yes, Mr. Kilrah, this is my personal school project.
I am sorry that I asked some trivial questions.
Thank you very much again for your guidance!

[Ralung]

Hello, Mr. @goebish

I have read your tx_example.py and tried to add some codes for my situation.

These are the codes I added

E016VH2 = 80
protocol = E016HV2
AutoBindBit = 0x40
RangeCheckBit = 0x20
header = bytearray([0x55, protocol | BIND_FLAG | RangeCheckBit | AutoBindBit, 0x00, 0x00])
serial_handle.write(bytearray([0x55, 0x01, 0x00, 0x01, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]))

and there are the outputs I got

starting JP4in1 firmware
stm32flash.exe -g 0x8002000 COM5
Multi-Module is running
opening COM5 @ 50000 8E2
module waiting for commands
sending bind packets for 10 seconds
starting channels transmition
sweeping rudders, press CTRL+C to stop ...
Traceback (most recent call last):
File "C:\Users\User\Desktop\tx_example\tx_example_test1.py", line 204, in
time.sleep(0.02)
KeyboardInterrupt

The outputs said "Multi-Module is running" when I run the program right after I just plug in my 4 in 1 module.
But the Red LED didn't flash and it was always not bright.
I also tried to modify the header as "header = bytearray([0x55, protocol | BIND_FLAG | RangeCheckBit | AutoBindBit])", but it didn't work either.

Could you please share some experiences about how to deal with this issue?
Thank you

[Ralung]

I send the commands directly via USB, and I flashed the firmware by Arduino IDE and used Serial/FTDI Debugging mode.

Maybe STM32FLASH command isn't set properly for my laptop.
Because I can't open stm32flash.exe with double click.

If the BIND_FLAG and AUTOBIND are not need, should I modify the commands like this?

header = bytearray([0x55, protocol, 0x00, 0x00])
serial_handle.write(bytearray([0x55, 0x00, 0x00, 0x00, 0x00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]))

Sorry, I have read the MULTI protocol serial definition in Multiprotocol.h file, but I am still confused about how to construct a correct command...

[goebish]

stm32flash runs fine on your machine.
Try disabling Debugging since the uart connected to usb is used for commands now, it can't be used for debugging (at least not without some work)

[goebish]

and yes, header = bytearray([0x55, protocol, 0x00, 0x00]) should be fine for the E016Hv2, no need for | BIND_FLAG or anything else

edit: I'm wrong, read below

[goebish]

I think I understand why it doesn't work.
The git branch with the USB uart "patch" is dated from last September, E016HV2 didn't exist back then.
Look at the required changes in Multiprotocol.ino and Pins.h to use uart1 instead of uart2 then patch latest Pascal's branch with that
master...goebish:JP4-in-1_USB_Serial_input

... or just use git to merge my branch into the latest version, it should be able to merge automatically (without conflicts), I let you read git documentation if you want to take that route ;)

[goebish]

Also, I see this protocol has number 80, so a different header is required as well (sorry)
header = bytearray([0x54, protocol + 32, 0x00, 0x00])
because the protocol number is above 31

[Ralung]

Hello, Mr. @goebish

Thank you for helping me, and I am sorry for replying you til today.
I was in a meeting yesterday and I just have time today to test the codes.

I have modified the multiprotocol.ino file and pins.h file.
But I got these errors

C:\Users\User\AppData\Local\Temp\arduino_build_128608/..\arduino_cache_493587\core\core_3a37eeec5f7896aa26ade432961a153a.a(usart_f1.c.o): In function __irq_usart1': C:\Users\User\Documents\ArduinoData\packages\multi4in1\hardware\STM32F1\1.2.2\system/libmaple/usart_private.h:46: multiple definition of __irq_usart1'
sketch\Multiprotocol.ino.cpp.o:D:\multi_protocol\test\DIY-Multiprotocol-TX-Module-master-test1\Multiprotocol/Multiprotocol.ino:2492: first defined here
collect2.exe: error: ld returned 1 exit status
exit status 1

I am trying to fix these errors now, and the good news is that the Red LED flashed after using the statements as you said.

header = bytearray([0x54, protocol + 32, 0x00, 0x00])
serial_handle.write(bytearray([0x54, 0x01, 0x00, 0x00, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]))

But the mode of Red LED is the "Slow blink" mode not the "Fast blink" mode which the mode showed up when I pressed the bind button on my transmitter.

Slow blink(on=0.5s,off=0.5s): serial has been selected but no valid signal is being seen on the RX pin.
Fast blink(on=0.1s,off=0.1s): bind in progress

I am testing with different commands and will update if I find anything new.
Thank you!

[goebish]

regarding the compilation error, I'm not sure that's the right way to do but as the commit message says I had to comment out the __irq_usart1 function in C:\Users\goebish\AppData\Local\Arduino15\packages\multi4in1\hardware\STM32F1\1.1.8\cores\maple\libmaple\usart_f1.c (near the end of the file, Interrupt handlers)

[goebish]

The command would be:

protocol = 80  # E016Hv2
header = bytearray([0x54, protocol + 32, 0x00, 0x00])
# send header + channels values
serial_handle.write(header + bytearray([0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]))

(not sure about the 0x54 and +32 for E016Hv2, @pascallanger can you confirm ? Multiprotocol.h is not clear and I'm too lazy to look at the OpenTX source code)

[goebish]

since I'm not sure for the 0x54 and +32 in the header you can use a dirty trick:
in the PROTOCOLS enum in Multiprotocol.h, swap PROTO_E016HV2 with another one that has a number below 32, e.g.

// swap Q303 & E016HV2 protocol number
PROTO_Q303 = 80
...
PROTO_E016HV2 = 31

Then the required header will be [0x55, 31, 0x00, 0x00]
That's not the proper way to do! But at least I'm pretty confident that it should work ;)

[pascallanger]

There is no +32 since the protocol is sent as a bitmask of 0x1F. To access protocols above 63, you need to send an extra byte at the end of the frame which contains the 2 top bits and concatenated with the header 2 bits extend the protocols to 256.
I know it's not simple but that's how the project has evolved over time. Who could have guessed at the begining when only a few (single digit) number of protocols were available would get so large.
But as you said the easiest is to remap the protocol to less than 32.

[Ralung]

Thank you Mr. @goebish and Mr. @pascallanger

After I comment out the __irq_usart1 function in usart_f1.c file at

C:\Users\User\Documents\ArduinoData\packages\multi4in1\hardware\STM32F1\1.2.2\cores\maple\libmaple

There are no error when compiling.

Then, I modified the protocol number of E016HV2 in multiprotocol.h file as 31

PROTO_E016HV2 = 31

, and I modified the header as below

header = bytearray([0x55, 31, 0x00, 0x00])

After that, the 4 in 1 board can turn to the binding process successfully (the Red LED is in "Fast blink" mode), and LEDs of my E016H will stop blinking. I thought that means the binding process completed.
But the Red LED of 4 in 1 board would not stop blinking after the LEDs of my E016H are stop blinking. The binding process will be continued and the Red LED of 4 in 1 board can't keep turn on stably. Which resulted in, during the process of "send_bind_packets" function, the E016H will switch from "bind" mode and "unbind" mode two or three times.

According to above problem, I modified the header as

header = bytearray([0x55, protocol, 0x00, 0x01])
or header = bytearray([0x55, protocol, 0x00, option_protocol]) (opetion_protocol = 40)

Because E016HV2 protocol needs Freq. fine tuning.

After set a suitable value of Freq. fine tuning, the Red LED of 4 in 1 module will keep turn on stably as well as LEDs of my E016H.
But when the "send_bind_packets" is end, the RED LED will turn to "slow blink" mode again.
I think it might be because I couldn’t make the propeller turn successfully. I have tried to modify the numbers of channel as well as send different values to different channels, but the problems are still not solved.

I am trying to solve that and will update if I find any solution. Thank you!

[pascallanger]

The problem right now is that I'm not even sure your hardware works. You say that you are not even running the multi code on the arduino uno, therefore I'm not sure what to do. At least the multi code running on the arduino uno would tell you if the PC communication works, what it is doing like bind or normal. Right now since you are not even using the code from this github how do you want to get support remotely on your setup?
Again, there are many models of the CX-10 with different PCB but also the CX10D, CX10WD...
If you really want to know if your version of CX-10 is compatible turn your nrf24l01 into a RX and listen to the XN297 packets from the original TX over the air. That would tell you if your nrf24l01 is working as it should, that would also tell you in the end if the protocol is known or not.

[dataphile-jeff]

The problem right now is that I'm not even sure your hardware works. You say that you are not even running the multi code on the arduino uno, therefore I'm not sure what to do. At least the multi code running on the arduino uno would tell you if the PC communication works, what it is doing like bind or normal. Right now since you are not even using the code from this github how do you want to get support remotely on your setup?
Again, there are many models of the CX-10 with different PCB but also the CX10D, CX10WD...
If you really want to know if your version of CX-10 is compatible turn your nrf24l01 into a RX and listen to the XN297 packets from the original TX over the air. That would tell you if your nrf24l01 is working as it should, that would also tell you in the end if the protocol is known or not.

In retrospect, I probably should have commented on the goebish code I am using (I defaulted to this one because of the previous comments).

FYI, I randomly tried an install of the multi code on the Uno, but I hit a validation error because the Uno is not listed as a supported board (but it probably would not work anyway, because I’m not using a 4-in-1 module?).

I believe the hardware to work, because if I skip the blue PCB binding, the code sends responses from the module back as strings. However, I’ll do as you say and set it to listen. In general, it’s been a lack of feedback that has made this hard to troubleshoot on my own (again, also combined with my lack of technical knowledge on the subject).

[pascallanger]

FYI, I randomly tried an install of the multi code on the Uno, but I hit a validation error because the Uno is not listed as a supported board (but it probably would not work anyway, because I’m not using a 4-in-1 module?).

The multi documentation on this github is all about using an Arduino Nano which is why but the code can run without a single modification on an Uno since both cards are in fact using an Atmega328. Just skip the validation... In the configuration you have to indicate which RF components are installed, in your case only the nrf and which protocols to compile CX10.

I believe the hardware to work, because if I skip the blue PCB binding, the code sends responses from the module back as strings.

No nothing here is showing me that the nrf talks with the atmega. It just means that the Arduino is connected to the PC and the program to send information on serial is working. It doesn't mean that you have connected the NRF correctly to the Uno... It will run exactly the same if you don't connect the nrf...
Have you tried just simple things like writting the nrf address register and read it back to see if you can communicate with it?

In general, it’s been a lack of feedback that has made this hard to troubleshoot on my own.

We are talking here of things over the air so there is nothing to check per say. As I said there are just too many unknowns in your current situation. Get rid of some of the unknowns and we will be able to progress.
Check:

1. Check that you can write the nrf address register and read it back to see if it matches -> that will tell if the Uno is able to communicate with the NRF.
2. Configure the NRF to listen for bind packets to see if they match the CX10 format. You have everything in the current code to do that since the NRF does listen for an answer of the quad, just block it in listen mode and check if it ever receives something with the original TX on. -> That will really tell us if the nrf is operational and also if the CX10 packets are what we expect.

This is far away from the purpose of this github. If you want something all baked in this is the wrong place... You have to check things by yourself and get back with evidences of your tests. For now I haven't seen anything apart that you have successfuly plugged the Arduino Uno to your PC using USB, uploaded a firmware and the serial monitor is correctly set.

[dataphile-jeff]

I really appreciate your help, especially (as you said) this task is removed from the main purpose of the code. I'm a bit busy with work, but as soon as I get a chance I am going to try each of the things you mention.

[dataphile-jeff]

@pascallanger It was a busy week, but I accomplished half of what you suggested. Specifically, I was able to write and read a different RF channel to the address register. Also, I ran the GetStarted example for RF24 (including prettyPrintDetails) and it seems that everything is working. As you suspected, I had it wired wrong. I don't know how the original project ever worked, because several websites indicate that MOSI, MISO, and SCK must be wired to specific pins on the Arduino, and the original project had them wired elsewhere.

I also was able to upload the full multiprotocol code to the Arduino, once I commented out the validation for the board, and selected a Custom TX endpoint.

I've been trying to check your second suggestion but I'm hitting a knowledge gap. I've tried to advance my knowledge of the subject, but I can't figure out how to 'block it in listen mode.' In theory, I guess I could use the RF GetStarted example to listen to the correct RF channel (which I think is 2)?

Because the Multiprotocol can accept serial inputs from a TX, it seems tantalizing close to just cut out the part for CX10s, and then send the right commands by PC serial port. I tried to see if I could rework the CX10_nrf24l01.ino file, which is what the original project must have done. However, the file is so intricately intertwined with the other files (Multiprotocol, Multiprotocol.h, etc.) that I'm struggling to make it work alone.

Again, I apologize for bringing up something that is tangential to your project. It may be that my knowledge gap on the subject is too great to make my desired project work. If there is any advice you can give I appreciate it, but again, I want to stress that I understand if this is beyond the scope of help. In the worse case, I can hope to directly replicate Ralung's approach whenever a 4N1 module eventually arrives.