DSM Forward Programming

[BeanieBots]

When Spektrum brought out 'Forward Programming' it was a convienient way of setting up a Rx from your Tx. Unfortunatley, with their latest Rx (the AR637T), it is now the ONLY way to configure the Rx. This means it is not possible to fully utilise all the features of such a Rx using a 4-in-1 and OPEN Tx. Would it be possible that the protocol used for 'Forward Programming' could be implemented?

[pascallanger]

Connect all 8 wires and not only the one you are pointing out. I don't know where you found your information about the spi but spektrum have a lot of different RF modules so having nearly all of the wires connected 8 out of 10 (+gnd and VCC) gives us the possibility to find our signals.

[johnnym007]

Ok - thanks Pascal.

[johnnym007]

@pascallanger Sorry I just deleted that post......I was hoping you had not looked at it yet. I have been playing around further and found that my ground was not properly connected. Sorry for wasting your time. This explains why things looked so strange on the traces. Looks like with that sorted I am getting SPI comms on Pins 3,4,5 & 8 - trace attached. I still need to work-out which of Pins 4 & 5 are MISO & MOSI, but I finally feel like I am making progress. Traces.zip

[pascallanger]

As far as I can see MOSI and MISO order are ok on the dumps. On MOSI you can see the channels being sent starting from the 3rd byte. On MISO the telemetry dat should start on the 4th byte.

[johnnym007]

Thanks Pascal - really appreciated. Sorry again for wasting your time with the erroneous traces.

Sent from my iPhone

On 20 Jun 2021, at 10:45, pascallanger @.***> wrote:

 As far as I can see MOSI and MISO order are ok on the dumps. On MOSI you can see the channels being sent starting from the 3rd byte. On MISO the telemetry dat should start on the 4th byte.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[johnnym007]

@gbine @kkriegel

Right I'm up and running with the logic analyser now and have written an Excel VBA function to help format it in a half sensible way, ignoring anything that is not related to the forward programming communications.

Link below (if it works) is to the raw logic analyser data and some sorted data where I have started to break-up the code to start to understand things. Also included is a video of the screen recorded at the same time as the capture, so the time stamp on the logic output should roughly correlate with the videos.

https://drive.google.com/drive/folders/1jBNWKU9Ybh2kexh-DWsj0j4Hdnogc2lp?usp=sharing

After some time looking at this I have realised (and tested to confirm) that the RX leads most of the communcations, with the TX effectively acknowledging receipt or providing the requested info. Once I start to understand this a bit further I plan to put together a command set document as a reference to understanding the command/response structure.

Anyway have a look and if you would like anything testing to prove a theory let me know and I will grab a capture and video and upload it (this might take a day or two).

[johnnym007]

Here is the latest LUA script version with some debugs enabled to help finding new field types: DSM FwdPrg.zip

I have also modified the Multi DSM RX code to act as a RX with built-in forward programming: DSM_Rx_cyrf6936.zip It's working but I can't guarantee in which state I left the source code so you might have to play around. But basically with this (and without opening the original TX) as an example you can dump all the TX known texts (use the option field and assign it to the text id so you can change it live) and explore how the menus are working since you can send whatever you want to the TX to be displayed there.

For the first time setup, I have the info to go past the first page somewhere in an excel file where I've disassembled the different exchanges but I've never coded it... I should be able to find it if someone is interrested.

Pascal

Hi Pascal - I am making some real progress and now have the first part of the "First Time Setup" working. This sends the Channel order and reversing status from the TX. There is still more to do as the RX also requests endpoints, mixing etc which I still need to decipher. One thing I believe is that there are more than one text lists held by the TX as I am definitely seeing an overlap of text strings. I would like to run the DSM_RX code that you have linked above, but I cannot get it to bind to the TX with telemetry (it always binds without). I am using multi version 1.3.2.86, but just do not seem to be able to get it working. Heres the Debug from the bind:

16:01:10.528 -> Protocol selected: 70, sub proto 0, rxnum 0, option 0 16:01:10.528 -> Proto=DSM_RX, nbr_sub=0, Sub=, Opt=0, FS=0, CHMap=1, rfSw=3 16:01:17.341 -> RX:0, CH:5 16:01:17.341 -> RX:0, CH:5 16:01:17.341 -> RX:0, CH:5 16:01:17.341 -> RX:1, CH:5 16:01:17.374 -> RX:0, CH:5 16:01:17.374 -> RX:0, CH:5 16:01:17.374 -> RX:0, CH:5 16:01:17.442 -> RX:10, CH:7 16:01:17.442 -> RX:16, CH:7 16:01:17.442 -> ID= 7B E8 8B 49, num_ch=8, type=B2

I guess I am missing something somewhere. could you provide some assistance? Thanks, John

[pascallanger]

I am making some real progress and now have the first part of the "First Time Setup" working. This sends the Channel order and reversing status from the TX. There is still more to do as the RX also requests endpoints, mixing etc which I still need to decipher.

This is where I ended up too, sorry to have not shared the file...

One thing I believe is that there are more than one text lists held by the TX as I am definitely seeing an overlap of text strings.

Yeah I've seen it too. It is even more obvious when you start playing with the RX side to display all the text, you end up with different stuff and graphics...

Let me check the DSM_RX with forward telemetry code, like I said this was a working file so I don't know in which state I left it but I know it is working so it must be something small.

[pascallanger]

Ok, I see what's going on. I've used the option field to change the data timing. Don't ask me why it is like this... I've just scanned through and with an option value of 80 telemetry looks to work reliabily including forward telem. So you should be able to replace line 233 by: uint16_t DSM_Send_Telem=5000-10*80; // -970 Anyway you should also change in Multi_Protos.ino the line 237 to enable the option field: {PROTO_DSM_RX, STR_DSM_RX, STR_CPPM, NBR_CPPM, OPTION_OPTION, 0, 1, SW_CYRF, DSM_RX_init, DSM_RX_callback }, Then using the variable option in the DSM RX code line 507..532, you can do live adjustments like displaying the text you want.

[pascallanger]

Note: you don't need to rebind. It should just work right away if you do the modification above. On the Spektrum I have, you do see 5 RX bars and the fwd programming menu entry appears.

[johnnym007]

Thanks Pascal - Got it working. Just need to workout the syntax for getting the variable into the telemetry command now.

On 1 Jul 2021, at 18:14, pascallanger @.***> wrote:

 Note: you don't need to rebind. It should just work right away if you do the modification above. On the Spektrum I have, you do see the 5 RX bars and the fwd programming menu appears.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[pascallanger]

@johnnym007 Here is an example: line 521 to 527, replace the switch entry by this:

    case 0x13: // 1st menu entry
        //CYRF_WriteDataPacket((uint8_t*)"\x09\x03\x00\x10\x00\x1C\xF9\x00\x10\x10\x00\x00\x00\x00\x03\x00"); // Gyro settings 
        //CYRF_WriteDataPacket((uint8_t*)"\x09\x03\x00\x10\x00\x6C\x50\x00\x00\x10\x36\x00\xFF\x00\x36\x00"); // Throttle
        memcpy(packet_in, (uint8_t*)"\x09\x03\x00\x0A\x00\x6C\x50\x00\x00\x10\x00\x00\xFF\x02\x00\x00",16); // Text list type 6C, enables to dump text list from 0x0000 to 0x02FF
        packet_in[6] = 0x00 + option;                                                                           // change the title of the text list
        CYRF_WriteDataPacket(packet_in);
        break;

That code will create on the spektrum radio screen a menu with on the 1st line a text list type 6C. The text list 6C has multiple arguments but here I've set the title to the option value and the list text range from 0x0000 to 0x02FF. If you use that code and set option to 0 the spektrum radio will display " : " which is normal.

Here is now the interresting part:

1. if you change option to 1, exit the fwd pgm menu and reenter, the list text will change to "AR636 : " meaning that the title text number 1 is AR636 -> Text[0x0001]="AR636" (start of the RX type text). You can change the option value as you like and you will get the corresponding text.
2. if you go down to the text list, click on it and only scroll once you will get "AR636 : Off": meaning that the list text number 1 is Off -> Text[0x0001]="Off". You can scroll as you want, by counting the number of scrolls you get the list entry number and associated text.

As you can see and what you raised earlier, there are different text tables... If you change the 6C to 1C,0C... you can dump all the text and see what is common. This is where I've stopped working on it...

Pascal

[johnnym007]

Thanks again Pascal - there is absolutely no way I would have worked that out!

As you can see and what you raised earlier, there are different text tables... If you change the 6C to 1C,0C... you can dump all the text and see what is common. This is where I've stopped working on it...

I was starting to draw the conclusion that the text list were associated with the LineType (1C, 4C, 6C etc). I am also speculating that this links to images where appropriate e.g. for the Orientation setup showing the Model and RX orientation. Finally, I am also wondering whether these lists also specify a unit to follow the value (% etc).

Additionally I also think that there are some menus that are handled by the TX e.g. the "Gain Channel" menu where there is not enough information exchanged to build the entire screen that is displayed.

I think that the next sensible step is to place all the text details into a seperate file to allow it to be modified independent of the script. This could also provide the link to any images that need to be displayed.

John

[pascallanger]

Images for orientation are in fact a list text entry.

Thanks again Pascal - there is absolutely no way I would have worked that out!

As you can see and what you raised earlier, there are different text tables... If you change the 6C to 1C,0C... you can dump all the text and see what is common. This is where I've stopped working on it...

I was starting to draw the conclusion that the text list were associated with the LineType (1C, 4C, 6C etc).

Most of the text is common, so I don't think this is the case. The LineType is more of a flag kind.

I am also speculating that this links to images where appropriate e.g. for the Orientation setup showing the Model and RX orientation.

The images for orientation are in fact a list "text" entry, you will see it when scrolling through them.

Finally, I am also wondering whether these lists also specify a unit to follow the value (% etc).

As you see in my code to add a % you need a line type C0, which for me smells really like flags as said above.

Additionally I also think that there are some menus that are handled by the TX e.g. the "Gain Channel" menu where there is not enough information exchanged to build the entire screen that is displayed.

Might be

I think that the next sensible step is to place all the text details into a seperate file to allow it to be modified independent of the script. This could also provide the link to any images that need to be displayed.

Yep that's why I've put the comment in the code. I've done it in the MultiChannelsUpdater.lua script so the code is already available on how to open the file look through it to find a match and get the value.

Pascal

[pascallanger]

And again with the RX code supporting forward programming as it is, we can now generate all the possible line types and figure out how they work. For example, if my intuition is correct we should be able to find relatively quickly what each bit is doing.

[johnnym007]

Thanks Pascal - All up and running. Just need to spend the time going through the text lines now.

I've updated my version of the LUA script to read the text values from a file. I can share this if you are interested as it should drop straight into the original lua script (replacing the Get_Text() function)

[johnnym007]

As you see in my code to add a % you need a line type C0, which for me smells really like flags as said above.

I've been playing around with the code and think I have finally worked-out the % sign. It is not linked to the line type, it is linked to the maximum and minimum values. The following combinations result in a % sign:

Min Max 0 100 -100 100 0 150 -150 150

There may be other combinations, but Max value definitely sets the precedent e.g Min:-100 / Max: 0 will not result in a % sign.

So far I have seen 6 line types: 1C = Text Line 4C = Text List (Only seen this in one menu and it toggles between two values) 6C = Text List / No live updating C0 =Numeric Value / Live updating 60 = Numeric Value / No live updating 0C = TX controlled value. The TX overrides the parameters passed by the RX

[oryfoxer]

I have an AR637T I would like to program AS3X for. Is there a working script now? I am just getting a blank screen when using the latest stable version.

[oryfoxer]

What is needed to get Forward Programming going? I am backed into a corner with my TX16S wanting AS3X with no way to configure it.

Is there something I can do? Would donating an Airware Transmitter help get this started again?

I am not a programmer, but I will assist in anyway I possibly can.

The issue is, I'm being forced into buying a Spektrum Radio in order to program AS3X and frankly, I can't stand the gimbals/setup of Spektrum stuff. I would much rather buy a radio for the MPM project to get forward programming working than buy a Spektrum for myself and actually have to fly with it.

Let me know how I can assist.

[johnnym007]

I spent several weeks looking at forward programming and setting-up the AS3X is not going to be straightforward to program - although I think it is possible.

As part of the setup process the RX reads a number of settings from the TX e.g. servo reversing, mixes, endpoints etc. OpenTX is very flexible in the way things are achieved, for example I am aware of at least 3 ways of reversing a servo (there may be more). Ensuring this information is captured correctly is critical to ensuring that the AS3X responds in the correct manner.

In the end I decided that the time required to get this working outweighed the cost of buying a Spektrum TX. If anyone wants to pick this up then I am happy to share what I learned.

[jbolene]

unfortunately that is what I decided also so I have a TX16 and a NX8

On Wed, Aug 18, 2021 at 1:19 AM johnnym007 @.***> wrote:

I spent several weeks looking at forward programming and setting-up the AS3X is not going to be straightforward to program - although I think it is possible.

As part of the setup process the RX reads a number of settings from the TX e.g. servo reversing, mixes, endpoints etc. OpenTX is very flexible in the way things are achieved, for example I am aware of at least 3 ways of reversing a servo (there may be more). Ensuring this information is captured correctly is critical to ensuring that the AS3X responds in the correct manner.

In the end I decided that the time required to get this working outweighed the cost of buying a Spektrum TX. If anyone wants to pick this up then I am happy to share what I learned.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/issues/408#issuecomment-900850822, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADA6MIQQTUCO2PXD4KPAFU3T5NGHXANCNFSM4PQFXV5Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

-- John Bolene

[pfeerick]

Same here... I got a Spektrum AR637T partly to try out Forward Programming with MPM, and also as a receiver with altitude telemetry for a plane that will be used for gliding...

I was able to see all the failsafe settings, and the gyro first time setup seemed to do nothing other than show a blank page... so I used a friends DX7 to set it up, and now seem to be able to access most of the "Gyro" section.

Maybe the first post could be edited so there is an overview of what is known to work and not work, and what else is needed?

[ReinhardZ1]

It's a pity, that it's not going on here. I've bought a Blade 230S smart and tried to do the forward programming of tailrotor PID value with my Radiomaster TX16S but that did not work (RM is running OTX 2.3.14 and MPM version is 1.3.3.0 AETR). When I start the DSM Fwd Prg LUA script, I get the Main screen with (un)known identifiers (D3 Swahplate, DD tailrotor, DA SAFE, DE setup, 86 System Setup), but I can not navigate to the sub menus. I made some photos of a friends DX8 of Blade Fwd Prg. Maybe it's possible to access/modify at least the Tailrotor value

[Dweinbach]

So is this a dead issue? Without forward programming support, we must all keep a modern Spektrum TX alongside our OpenTX device.

Although I can write code, I shouldn't be allowed to for the good of humanity. I don't have my TX16S yet (trying to decide whether to cancel the order because of this). IF I decide to go ahead with it, can I move the state of this forward without needing logic analyzers and writing code (other than LUA code)? Can I install some buld and then hack away at the unenumerated strings by putting my DX8e and the TX16S side by side and seeing what is missing? or is that only a small corner of the problem?

Total noob to OpenTX, but lots of experience troubleshooting firmware, hardware, and software.

Thanks,

Dave

[oryfoxer]

I ended up switching from a TX16S to a Spektrum IX20 for AS3X programming. As much as I loved the TX16S - the state of forward programming left me with no other choice.

Sold the TX16S and went deep into Spektrum.

No regrets.

[ReinhardZ1]

Can I install some buld and then hack away at the unenumerated strings by putting my DX8e and the TX16S side by side and seeing what is missing? or is that only a small corner of the problem?

For sure that is only a very small corner of the problem. I'm new with LUA programming, but I think there are several problems in the LUA script that is published with the latest OTX version (2.3.14).

Some issues I do not yet understand if it's a bug or my missing LUA experience: variables/pseudo constants MENU, LIST_MENU_NOCHANGING, LIST_MENU2, PERCENTAGE_VALUE, Line Are read in the code but never written (Line table is cleared once, but not written afterwards). Maybe that's the problem, why the menu navigation does not work with the Blade230S smart receiver.

Reinhard

[pascallanger]

It's surely a menu type that I haven't seen yet. If you are willing to spend some time I can look into at least getting your settings working.

[ReinhardZ1]

Hi Pascal, That would be great! I will support you where I can.

Reinhard

[paul-goelz]

Guys, I have a very small forward programming issue that I can probably solve myself if you can point me in the right direction. I'm using the forward programming LUA in a Jumper T16, and with a Spektrum AR637T receiver. Everything in forward programming seems to work as expected EXCEPT when I go to display / change the receiver output frame rate for each channel, the frame rate is displayed incorrectly. The values displayed are 46 and 47 when they should be 11mS and 22mS (not sure which is which). I am not really a coder (I stopped at BASIC) but I had a look through the script and was unable to determine how the frame rates are supposed to display. At least I didn't find any obvious text strings.

If you can point me to how / where the frame rates are displayed, I can hack around and see if I can get them to display correctly.

Thanks, Paul

[ReinhardZ1]

Meanwhile I've played a little bit with the LUA script and as an exercise I've modified the DSM script to get the command response from the Blade230S smart receiver.

local toolName = "TNS|DSM Cmd Test|TNE"

---- #########################################################################
---- #                                                                       #
---- # License GPLv2: http://www.gnu.org/licenses/gpl-2.0.html               #
---- #                                                                       #
---- # This program is free software; you can redistribute it and/or modify  #
---- # it under the terms of the GNU General Public License version 2 as     #
---- # published by the Free Software Foundation.                            #
---- #                                                                       #
---- # This program is distributed in the hope that it will be useful        #
---- # but WITHOUT ANY WARRANTY; without even the implied warranty of        #
---- # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         #
---- # GNU General Public License for more details.                          #
---- #                                                                       #
---- #########################################################################

--###############################################################################
-- Multi buffer for DSM description
-- Multi_Buffer[0..2]=="DSM" -> Lua script is running
-- Multi_Buffer[3]==0x70+len -> TX to RX data ready to be sent
-- Multi_Buffer[4..9]=6 bytes of TX to RX data
-- Multi_Buffer[10..25]=16 bytes of RX to TX data
--
-- To start operation:
--   Write 0x00 at address 3
--   Write 0x00 at address 10
--   Write "DSM" at address 0..2
--###############################################################################

local commandSent = false
local answerReceived = false
local rxTimeoutInit = 50
local rxTimeout = rxTimeoutInit
local rxAnswer = ""
local cmdString = ""

---------------------------------------------------------------
local function DSM_Release()
  multiBuffer( 0, 0 )
end

--------------------- Init ------------------------------------
local function DSM_Init()

  --Set protocol to talk to
  multiBuffer( 0, string.byte('D') )
  --test if value has been written
  if multiBuffer( 0 ) ~=  string.byte('D') then
    error("Not enough memory!")
    return 2
  end

  --Init TX buffer
  multiBuffer( 3, 0x00 )
  --Init RX buffer
  multiBuffer( 10, 0x00 )
  --Init telemetry
  multiBuffer( 0, string.byte('D') )
  multiBuffer( 1, string.byte('S') )
  multiBuffer( 2, string.byte('M') )

end

---------------------------------------------------------------
local function Clear_LCD()

  lcd.clear()
  lcd.drawFilledRectangle(0, 0, LCD_W, 30, TITLE_BGCOLOR)
  lcd.drawText(1, 5, "DSM Command Test", MENU_TITLE_COLOR)
  lcd.drawText(10,32,"Press Enter to send command ...")

end

---------------------------------------------------------------
local function DSM_Send(...)
  local arg = {...}

  multiBuffer(10,0x00);  -- clear receive flag
  rxTimeout = rxTimeoutInit

  for i = 1 , #arg do
    multiBuffer( 3+i, arg[i])
  end
  multiBuffer( 3, 0x70+#arg)

end

---------------------------------------------------------------
local function SendCommand()
  if not commandSent then

    -- edit command and cmdString here:

    ---[[
    cmdString = "Cmd: RxVersion"
    DSM_Send(0x11,0x06,0x00,0x14,0x00,0x00)
    --]]

    --[[
    cmdString = "Cmd: First Menu Title"
    DSM_Send(0x12,0x06,0x00,0x14,0x00,0x00)
    --]]

    commandSent = true
  end

end

---------------------------------------------------------------
local function ReceiveAnswer()

    if multiBuffer(10) == 0x09 and multiBuffer(11) ~= 0x00 then 

      answerReceived = true

      local i
      rxAnswer = "Answer:"
      for i=10, 25 do
        rxAnswer = rxAnswer.." "..string.format("%02X", multiBuffer(i))
      end

    elseif rxTimeout > 0 then
      rxTimeout = rxTimeout - 1
    end

  if rxTimeout == 0 then
    rxAnswer = "RX does not respond ..."
  end

end

---------------------------------------------------------------
local function ShowAnswer()
  lcd.drawText(10,52,"Timeout: "..rxTimeout)

  lcd.drawText(10,92,cmdString)
  lcd.drawText(10,112,rxAnswer)
end

---------------------- Main  ----------------------------------
local function DSM_Run(event)

  if event == EVT_VIRTUAL_EXIT then
    DSM_Release()
    return 2
  else

    Clear_LCD()
    if event == EVT_VIRTUAL_ENTER then
      SendCommand()
    elseif commandSent and not answerReceived then
      ReceiveAnswer()
    end
    ShowAnswer()

    return 0
  end
end

---------------------------------------------------------------
return { init=DSM_Init, run=DSM_Run }

That works for the RxVersion command, but not for the Menu command. If I activate (uncomment) the Menu command I get only 00 as a response. If I look for multiBuffer(11) ~= 0, I get a timeout ?

@pascallanger : Do you have any idea? Have you already checked your script?

[pascallanger]

Do you have any idea? That doesn't work further since you must keep the connection open with the receiver by sending a command every few ms, otherwise it disconnects and you need to restart all over again... And you need to send the requests in a given order otherwise it will disconnect too.

[pascallanger]

Have you already checked your script?

And my script work but taking just a piece of it doesn't...

[ReinhardZ1]

It's surely a menu type that I haven't seen yet. If you are willing to spend some time I can look into at least getting your settings working.

I was referring your statement above, as your script doesn't work with the Blade230S smart receiver. I'm willing to spend the time. What can I do?

[pascallanger]

Test this: DSM FwdPrg.zip Do a screen capture of the result and share.

[ReinhardZ1]

unexpected symbol ...

[pascallanger]

Typo... Try this one: DSM FwdPrg.zip

[ReinhardZ1]

When I start the script for the first time I get the Main Menu screen. Navigation to Menu lines is not possible. Enter on 'BACK' shows again the Main Menu. When I end the script with exit (RTN) and start it again I get the message 'no compatible receiver ...'. After disconnecting the receiver and connecting again Main Menu works again.

[pascallanger]

This one: DSM FwdPrg.zip

[ReinhardZ1]

[pascallanger]

Strange this is a standard menu entry. You are sure you can't scroll to select any of them?

[ReinhardZ1]

yes, I'm sure. Before the Main menu is shown, there is a short message 'no compatible DSM rx...' Is that a problem? With my test.lua I've checked already that EVT_VIRTUAL_NEXT, .._PREV, ..._ENTER is detected, when I use/press the roller.

[pascallanger]

Can you test this: DSM FwdPrg.zip

[ReinhardZ1]

That looks already much better! The first Menu line is now highlighted and I can navigate to each line in the main menu. If I enter the Tail-rotor menu, I first get the menu lines (maybe not all lines captured in the 2nd picture) and then immediately an error is generated (3rd picture).

[pascallanger]

I have no idea where the error is coming from and the message does not give any clue... Can you try this one: DSM FwdPrg.zip

[ReinhardZ1]

Main Menu is shown correct, navigation works. Tail-rotor menu is shown, Deg Char ° is not correct . Immediately after the tail-rotor menu is complete, the error occurs again.

[pascallanger]

Why is there no value displayed? This RX/FC looks to use a different format or at least does not provide the information the same way I've seen so far...

[ReinhardZ1]

Yes, the error must be somewhere in the value reading part. Maybe line 214 were Line[MenuCurLine].ValId is read? I don't find a line, were ValId is written, it initialized as nil

[pascallanger]

Line 294

[ReinhardZ1]

Ah, OK. Is there any kind of diagnosis possible? I have a second transmitter with external MPM.

[pascallanger]

By putting the external module in debug mode we would have a chance to see where the communication breaks. I need time to look into it since I don't have the hardware at hand which is making tests a bit complicated...