Orange Module running MULTI protocol

[Bosshawg]

Apologies neglected to say I had cut the track and added the wire

[MikeB]

There is a possibility that the pad on the 5-way module connector the wire goes to may be tracked to ground (see later posts in the thread). Please check if this is the case.

Mike.

[TheGlutton]

Mike,

I flashed the 1.1.5.

-TheGlutton

[MikeB]

I'll see about building from the latest sources in case something changed since 1.1.5. The code currently uses the number of channels (4 to 12) specified by the option value and anything outside this range uses 6 channels so using option = 2 should be the same as option = 6ch.

When binding, you should see the parameters being used by the bind appear at the bottom of the screen that shows "BINDING". What, if anything, do you see there?

Mike.

[MikeB]

The v1.1.5 firmware has a longer filename than the AR9X can display should i rename it?

No, just press the RIGHT button a few time and filenames that are too long scroll left so you may read the entire name!

Mike.

[biasedlogic]

I'll see about building from the latest sources in case something changed since 1.1.5. The code currently uses the number of channels (4 to 12) specified by the option value and anything outside this range uses 6 channels so using option = 2 should be the same as option = 6ch.

When binding, you should see the parameters being used by the bind appear at the bottom of the screen that shows "BINDING". What, if anything, do you see there?

Mike.

Hi Mike,
I'm having issues with the multi protocol solution.

Equipment on hand:
9xr pro
"Orange RX internal module w/ Telemetry" (the one using 9xr internal antenna)
"Orange RX DSM2/DSMX/Walkera switchable module" (the one with a dipswitch, newest version)
R615X Orange receiver (couple of months old)
Redcon RM601 Micro Receiver

Oscilloscope, multimeter, fine soldering iron, AVRISP MK2, and a guy to operate it all

SW:
Original dumps from both modules, Multiprotocol_V1.1.6_OrangeTX_INV and the "1.1.5" from the first post.

Observations:
1. Switchable module set to "auto" binds to RM601 in DSMX-22 mode (two blinks of LED every second).
By dipswitch it can be forced to bind in DSMX-11 (three blinks of LED every second), DSM2-22 (no blinks) or DSM2-11 (didn't check the LED) - each mode works smooth and flawless (as far as I can tell by observing a servo on my table). Set to DSM2-2048 it binds, but the receiver behaves erratically - random servo movements, no true control whatsoever.

2. Internal module with original firmware binds to the RM601 without a hitch if protocol is set to [DSM2] / [9XR-DSM]. The module starts sending data on pin 5 of the module bay about every second or so, it seems to be at a baudrate close to 115200, idle bus state is HIGH, start bit is LOW. The 9XR Pro does not seem to receive this data at all (Telemetry screen is blank on the DSMX page). I've recorded a frame of the data sent, but didn't analyse it yet.
Module can be put into binding mode upon power up only, menu option 'bind' does beep and vibrate and does nada, nothing.

3. Internal module with the 1.1.6 firmware (as far as I can tell the behaviour is identical to 1.1.5):
DSM2-22ms binds and works right away
DSMX-11ms binds and works, but after RX restart (with the other module restart of RX is not necessary, it goes to work right after binding)
DSMX-22ms binds and works right away

DSM2-11ms is erratic, just as the 2048 mode of the switchable module.

Internal module with the 1.1.6 firmware does not send any data on the pin 5 of the module bay, the idle line state is ZERO. The 9XR Pro also does not seem to receive any data at all (Telemetry screen is blank on the DSMX page).

The internal module has R1 and R13 populated with 100Ω resistors, tried bridging each of them with a short, did not change a thing. There's no short between Pin5 and GND (checked, also, else no data would be sent with original FW).

Any hints where to go from here?

THANKS!
Marek

[MikeB]

I'll try to find some time to try some of this. I only have internal modules myself that I use for development. I only have 1 model I have ever flown using DSM.

The 'PRO has a FrSky SPort connection on pin 5, which expects inverted serial by default. If the module (original firmware) is idling high, then this is not inverted, so you need to set "Invert COM1" for the radio to recognise it.

Mike.

[biasedlogic]

I'll try to find some time to try some of this. I only have internal modules myself that I use for development. I only have 1 model I have ever flown using DSM.

The 'PRO has a FrSky SPort connection on pin 5, which expects inverted serial by default. If the module (original firmware) is idling high, then this is not inverted, so you need to set "Invert COM1" for the radio to recognise it.

Mike.

Okay, so I got to listen on the pin 5 with OFW on the internal module. The internal module is what I'm all about, the external one is just a backup for checking things as it works in a contained way and blinks operating mode out.

The module after power up, before init sends repeatedly:
AA FF 67 E6 C3 98 0D 0B 0E 00 45 07 00 00 00 00 00 00
at a rate of about 45 messages per second.

After it gets initialized it sends:
AA FF 67 E6 C3 01 0D 0B 0E 00 45 07 00 00 00 00 00 00
repeatedly at a rate of about 0.8 message per second (one about every 1.13s).

If binding is initiated upon power up, it will send during/after the binding init a couple of times:
AA 80 DD 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00
but I haven't checked deeper into when exactly will it be sent and what happens if binding was (un)succesful.
After a couple of lines like the above it gets back to sending
AA FF 67 E6 C3 01 0D 0B 0E 00 45 07 00 00 00 00 00 00
at the usual rate of one every 1.13s or so.

Irrelevant of the setting "invert COM1" 9xr (on 221a6) does not seem to pick any data up on the "DSMX" telemetry screen. The baudrate is set to 115200 manually, autobaud did not change anything, telemetry protocol to "DSMx".

More important: Internal module with the multiprotocol firmware appears physically not to send ANY data back. If set on binding to "AUTO"it will bind in some mode, but the setting will stay on AUTO until you manually figure out what the protocol it bound with was. The line to the Tx seems to be dead as the Python's parrot...

regards,
Marek

[MikeB]

From the main screen, go UP LONG, then RIGHT about 7 times to the "DEBUG" display. At the bottom of the screen is "TelRxCount". This is a running total of the bytes received from the telemetry. Is this changing?
If yes, press MENU LONG to enable "Raw Logging" (note this setting is NOT preserved through a power cycle). Now set up a switch to enable logging and turn logging on for ten seconds, then turn it off.
Restart the radio in bootloader mode, connect to the PC, then find the logfile on the SD card (under LOGS), zip it up and post it (or PM it to me) for me to see what is being received.

Mike.

[biasedlogic]

From the main screen, go UP LONG, then RIGHT about 7 times to the "DEBUG" display. At the bottom of the screen is "TelRxCount". This is a running total of the bytes received from the telemetry. Is this changing?

On the Multi FW no, it isn't.
Consistent with what one can see on an oscilloscope.
To check the original firmware i have to disassemble the module again, tbh. I don't care about the original firmware that much as it doesn't seem to be developed anymore.

I guess I have to ask first - is the module with a multi protocol firmware supposed to report any status at all on its own? Or does it respond only if paired with a telemetry receiver? I was hoping to get tssi/rssi at least.

Regards,
Marek

[biasedlogic]

From the main screen, go UP LONG, then RIGHT about 7 times to the "DEBUG" display. At the bottom of the screen is "TelRxCount". This is a running total of the bytes received from the telemetry. Is this changing?

With the original FW it is changing, yet the captured logfile is empty
(only the header row gets populated).
Checked twice that I've got "raw logging" ticked.

Any ideas?
Marek

[MikeB]

Ok, let me build the 'latest' MULTI firmware and get that on to a module and test it, then we'll go from there.
The latest includes sending a firmware revision number every 0.5 seconds.

Mike.

[biasedlogic]

Great! Once you have a binary to test I'll flash it too and report
M

[MikeB]

I just built this from the sources I'm using. They aren't quite the latest on Github, but I'm working on FrSky telemetry problems. I believe there is no difference with the DSM code however.
Since you have 221a6, you should see the Multi version number beside the BIND text in the protocol menu. This checks the serial data from the module is working.
I just tested with a R615X+telemetry module and it is all working. The bind was done using AUTO, and the BINDING screen showed the bind response and set the parameters as required.

Telemetry is also working.

Mike.

MultiOrange.zip

04-Feb-2017 21:55
1.1.6.10 with status/version report

(12.39 KiB) Downloaded 209 times

[biasedlogic]

I just built this from the sources I'm using. They aren't quite the latest on Github, but I'm working on FrSky telemetry problems. I believe there is no difference with the DSM code however.
Since you have 221a6, you should see the Multi version number beside the BIND text in the protocol menu. This checks the serial data from the module is working.
I just tested with a R615X+telemetry module and it is all working. The bind was done using AUTO, and the BINDING screen showed the bind response and set the parameters as required.

Telemetry is also working.

Mike.
MultiOrange.zip

Hi Mike,
Now there's data trickling in when I check the "DEBUG" screen, and there's (1.1.6. listed next to BIND (COM1 non inverted - no tick in the box). So it seems that the communication works. The binding in AUTO works too. I get the bind status reported back and the AUTO switches over to reported parameters (DSMX-22/7ch in my example wit the REDCON 602 or DSMX-22/6CH with the R615X). The range to get this binding feedback is very, very short - 10cm at best, 30cm (1ft) is too much, the radio will bind but not get the binding data back. Is this normal? If so, I'll have to test the previous FW I had on it, maybe I was just too far to get any data...?

I have no full-fledged DSMX telemetry module at hand to test telemetry data. FrSky RXes send basic telemetry on their own, but it seems DSMX don't, do they?

thank you,
regards,
Marek

[MikeB]

I'm usually a couple of feet away (60cm) when binding and this works fine, the binding feedback works.

DSMx receivers, in general, do not send any telemetry.

Mike.

[slimvulcanrider]

I am having problems binding my transmitter to a HobbyZone Champ S+.

I am using a Turnigy 9xr Pro (Mode 2) with ersky9x-r220 firmware and a OrangeRX 2.4Ghz Telemetry Module For Turnigy 9XR Pro (DSMX/DSM2/Walkera Compatible) with stock firmware. My problem, I can get the receiver to bind to my module, but rudder and elevator are on the right stick (throttle moves the rudder left and right, and rudder input moves the elevator up and down). Left stick Elevator control moves the ailerons. I have no throttle input from any of the sticks or sliders. I can get the motor to spin up to full power by leaving the plane battery plugged in and turning off the transmitter.

Going through the 9XR Pro set up menus I can't seam to change the channels. I have tried to flash the module with MULTI-Protocol firmware from the maintenance screen by selecting Update Xmega, then selecting Multiprotocol_V1.1.5_OrangeTx.bin and i get Flashing Complete: Failed.

I know I am doing something wrong, but I have no clue where to start to try and figure out what.

[MikeB]

It is quite well known the stock Orange firmware does not work with some BNF models, the throttle does not respond in these cases.
Have you followed the method of connecting to the board of the Orange module described in the PDF file(s) in the first post of this thread?

Mike.

[slimvulcanrider]

no i have not Mike, because I don't have the equipment to do so... I thought I ordered it along with my Module, but what I ordered was wrong. I ordered the OrangeRX USB Firmware Update Kit for JR/Futaba Style Transmitter Module but was told this is wrong... second problem is I don't have a windows or MAC computer and know almost nothing about the linux system I am running. I am currently trying to repair my windows 10 opperating system to see if this will help make matters more simple.

[MikeB]

The equipment you need can be as simple as 3 wires soldered to the pads (GND, CLK and DATA).
You can use the update kit you now have to supply power to the module. I have a couple of those kits and I do use one for this purpose.
Then as long as you can get the firmware file onto the SD card (in the Firmware directory) you may flash the module from the radio.

Mike.

[slimvulcanrider]

Mike, I am still confused... if I solder the wires to GND, CLK, and DATA, where do the other ends of said wires go, back to the radio? the update kit I now have is used to power the module only?

and lastly I do have the firmware (Multiprotocol_V1.1.5_OrangeTx.bin) on the sd card in the firmware folder.

[jhsa]

Please, go to the first post of this thread and download the file called " PDIflashing2.pdf". Then read it.. You will understand what you have to do..

João

[slimvulcanrider]

I have read it several times and am still just as confused as I was when choosing a computer radio

[MikeB]

What isn't clear?

Mike.

[slimvulcanrider]

i think i am getting this figured out Mike... from what I understand I solder 3 wires onto pads GRND, CLK, and DATA, these 3 wires go back to the module bay of the radio (corresponding pins) Then I need to pull power from the mod bay to the mod as well... I found a picture explaining the pinout of the mod bay, but they use differnt names than CLK and DATA... so that is where I am stuck at.

[jhsa]

yes those pins normally do something else when the radio is working normally, therefore those drawings/Pictures show different names for the pins. What it matters is what that PDF document say as far as flashing the module is concerned. I would really pay attention to how you power the module. Be careful not to connect battery voltage (available in the module bay) to any place that can only take 3.3V. That would destroy the module..

João

[MikeB]

It is easiest to power the module using the 5-way module connector socket that normally plugs onto the pins in the module bay. That way, you make use of the modules own 3.3V regulator.
This is where the update kit comes in useful, it has the 5-pin plug that goes into the module socket, and a two-pin header to which you connect a power source. I use a 4-cell Rx battery.

Mike.

[slimvulcanrider]

I am about to through this POS into the trash... Tx and all... I think I just fried my board... I just did every thing Mike said to do... soldered three wires to the Module on the GRND, CLK, and DATA, connected those wires to the TX mod-bay, then I turned the TX on holding both trim buttons APART, powered up the module by plugging in the Update kit powered by a spare 2s battery. went to Update EMEGA, selected MultiOrange.bin with long menu hold, then another long menu hold to confirm. screen went strait to Flash finished FAILD. after sevearl frustrating attempts I took off the wires and put the module back together, and now I am not getting the LED to light up.

[MikeB]

I've improved the status report when you get a "FAILED" result. Please go here: viewtopic.php?f=7&t=4676#p65894, download "ersky9xProvR221a6.zip", extract ersky9xr_rom.bin and flash this to your radio.
Ask if you are not sure how to do this.
Now please have another go at flashing the Orange module. If you still get "Failed" post the numbers and letters you see at the bottom of the display.

Mike.

[slimvulcanrider]

My radio wont turn on... when I turn the power switch to on, the Blue ready light comes on very dim, I have 11.2 Volts at the battery... tried unplugging and re-plugging in the battery and nothing changes. Charging my battery now, will report back when I have a full battery pack.