Page 13 of 14

Re: Ersky9x Bug Reporting

Posted: Mon Jul 06, 2020 9:51 pm
by MikeB
I've just committed some changes. It is all working on my AR9X board with multi V1.3.1.32. I get all the names correctly up to protocol 72.
I've updated the built in multi names so they match the multi.txt file, so no bytes were needed in the buffer.

Mike

Re: Ersky9x Bug Reporting

Posted: Mon Jul 06, 2020 11:01 pm
by jhsa
quadrifoglio wrote: Mon Jul 06, 2020 4:57 pm Hello,
im not sure if this is normal in erskyTx but on OpenTx this is not happen.

When i turn off Tx and turn it on back, ten throttle is pushed for about half second, it is very scary with mounted props.

My radio is 9XR Pro with erskyTx 222

EDIT: when i disable (uncheck) Fix Offset in Mixer then this not happens
What RF module and what receiver?.. It is possible the receiver failsafe setting is doing that. I also never seen the radio do that.

João

Re: Ersky9x Bug Reporting

Posted: Tue Jul 07, 2020 12:16 am
by JanRy
Hi Mike,
Thanks for looking into this. I don't know if the issue is with my Tx or my compilation, but my problem persists. I've recorded the behavior when changing the sub-protocol. In this case the main protocol is 65 (FrSkyR9) but it reverts to Flysky. It knows the protocol number, since it briefly shows the right sub-protocol:
https://www.youtube.com/watch?v=P_tuz34grPA

Edit: I've deleted multi.txt from SD card. It has no impact on what is displayed. Also strangely first Hitec sub-protocol is 'Optima', I was expecting 'OPT_FW'.

Re: Ersky9x Bug Reporting

Posted: Tue Jul 07, 2020 12:22 pm
by quadrifoglio
jhsa wrote: Mon Jul 06, 2020 11:01 pm
quadrifoglio wrote: Mon Jul 06, 2020 4:57 pm Hello,
im not sure if this is normal in erskyTx but on OpenTx this is not happen.

When i turn off Tx and turn it on back, ten throttle is pushed for about half second, it is very scary with mounted props.

My radio is 9XR Pro with erskyTx 222

EDIT: when i disable (uncheck) Fix Offset in Mixer then this not happens
What RF module and what receiver?.. It is possible the receiver failsafe setting is doing that. I also never seen the radio do that.

João
Frsky DJT+X8R, all channels is centered after powering Tx, but as i write in edit, disabling offset helps.
I think this is not problem in failsafe, because this happens when i power on tx, not during powering off.

Re: Ersky9x Bug Reporting

Posted: Tue Jul 07, 2020 12:41 pm
by MikeB
Do you have a safety switch set on the throttle channel?
What do you have set in the mixer for the throttle channel?

Mike

Re: Ersky9x Bug Reporting

Posted: Tue Jul 07, 2020 5:42 pm
by quadrifoglio
I do not have any safety switches on tx
Settings of throttle channel is default without any changes.

And this behavior is on all channels, not only throttle.
Tx simply center all channels for some time (half second, maybe less) after powering up.

Btw i try set failsafe on rx with zero throtle and does not help...
As i said, problem is on tx side, because with opentx this does not happen, with same rx.

But as i write beore there helps unchecking "Fix Offset", so i think problem is solved for me...

Re: Ersky9x Bug Reporting

Posted: Tue Jul 07, 2020 8:03 pm
by MikeB
I'm not sure why changing "Fix Offset" should change the operation.
I've tried to reproduce the problem. I have a servo on the throttle channel and I can see a very short glitch when powering the Tx on with the Rx already on, it lasts for a single frame time, around 23mS. I tried changing the "Fix Offset" and it had no effect.
Checking with a logic analyser, I can see the first CPPM frame has two extra pulses at the start, so the channels are shifted, CH1 and CH2 are at 1500uS, CH3 has the CH1 value, CH4 the CH2 value and so on. On my setup, the throttle is on channel 3.
I've now changed the initialisation code so that these two extra pulses are 5mS long. This makes them into "sync" pulses, so the first frame is now sent correctly. On testing, the servo now does NOT glitch.
This change will be in the next test version I post, and subsequent releases.
Hopefully, I'll post a test version in the next day or two.

Mike

Re: Ersky9x Bug Reporting

Posted: Tue Jul 07, 2020 8:36 pm
by MikeB
JanRy wrote: Tue Jul 07, 2020 12:16 am Hi Mike,
Thanks for looking into this. I don't know if the issue is with my Tx or my compilation, but my problem persists. I've recorded the behavior when changing the sub-protocol. In this case the main protocol is 65 (FrSkyR9) but it reverts to Flysky. It knows the protocol number, since it briefly shows the right sub-protocol:
https://www.youtube.com/watch?v=P_tuz34grPA

Edit: I've deleted multi.txt from SD card. It has no impact on what is displayed. Also strangely first Hitec sub-protocol is 'Optima', I was expecting 'OPT_FW'.
The radio is, I think, operating correctly, but the module is sending back the "wrong" protocol name, as though it is not getting the top two bits of the protocol number. These are sent in a later byte of the protocol stream.

I've attached the radio firmware I'm using, perhaps you could try this as it is working correctly for me.
For the HItec sub-protocol, the builtin name is "OPT_FW", but the module returns "Optima".

Mike

Re: Ersky9x Bug Reporting

Posted: Tue Jul 07, 2020 8:51 pm
by JanRy
thanks again Mike,
I've just flashed the firmware you've compiled. The problem persists, so I guess it is not a MBTX compilation issue.
I am compiling Multi (STM32 version) myself, so perhaps there is an issue there in _MyConfig.h settings. I'll investigate that further.
So, does it mean that for MBTX I don't need the multi.txt file on SD card?

Re: Ersky9x Bug Reporting

Posted: Tue Jul 07, 2020 9:20 pm
by MikeB
I've attached the most recent compile I did for the MPM (STM version). This works fine for me. It does use "INVERT_TELEMETRY".
What I do with the "Multi.txt" file is compare the entries with the ones I have built in. I then store and use any that differ, or are extra. This allows the names to be updated without a firmware update. Clearly, since the module returns the names, anything new does get displayed, but after a second delay.

Mike

Re: Ersky9x Bug Reporting

Posted: Tue Jul 07, 2020 10:33 pm
by JanRy
Thank you Mike,
I've reinstated multi.txt, flashed MBTX and multi from your files. The behavior is still the same though.
I wonder if anyone else has the same issue. I think João uses AR9x?

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 12:59 am
by jhsa
Yes, I have an AR9x radio currently in working order.. But it has a Frsky DHT module inside, not a MUltiProtocol module.
My other AR9x radio that has a Multi module, broke the little battery connector. Need to fix that :)

João

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 10:48 am
by MikeB
I'm going to guess either the ARUNI or the module has a crystal that is a bit off frequency, causing a mismatch in the baudrates between them. On your video I do see a missing character in the sub-protocol name, "td" instead of "Std".
You could try changing the baudrate on the ARUNI board and see if that cures the problem.
In frsky.cpp, line 3150 is:
baudrate = 100000 ;
and line 3260 is:
initComPort( 100000, (g_model.telemetry2RxInvert << 1) | g_model.telemetryRxInvert, SERIAL_EVEN_PARITY ) ;
I'm not sure which is used, so try changing both. Try changing by 1% at a time, both up and down, so 101000 and 99000, 102000, 98000 and see if it then works.

Mike

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 2:20 pm
by quadrifoglio
MikeB wrote: Tue Jul 07, 2020 8:03 pm I'm not sure why changing "Fix Offset" should change the operation.
I've tried to reproduce the problem. I have a servo on the throttle channel and I can see a very short glitch when powering the Tx on with the Rx already on, it lasts for a single frame time, around 23mS. I tried changing the "Fix Offset" and it had no effect.
Checking with a logic analyser, I can see the first CPPM frame has two extra pulses at the start, so the channels are shifted, CH1 and CH2 are at 1500uS, CH3 has the CH1 value, CH4 the CH2 value and so on. On my setup, the throttle is on channel 3.
I've now changed the initialisation code so that these two extra pulses are 5mS long. This makes them into "sync" pulses, so the first frame is now sent correctly. On testing, the servo now does NOT glitch.
This change will be in the next test version I post, and subsequent releases.
Hopefully, I'll post a test version in the next day or two.

Mike

I just want make a short video of this, so i cancel failsafe and rebind tx/rx and now all works fine, even if checked "fix offset" ...
:roll:

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 3:32 pm
by bob195558
Maybe then, by rebind and/or recreating the eeprom Model, it fixed a programing glitch ?

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 8:03 pm
by JanRy
Hi Mike,
the communication between ARUni and MPM was OK between 93000 to 103000 baud. Outside these values the Hitec Optima sub-protocol would not update from OPT_FW or it got garbled. I've settled mid range at 98000 baud. But, persistently, anything above protocol 65 wraps around.

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 9:36 pm
by MikeB
Please confirm this is with the module firmware I posted (V1.3.1.32), and that you do see "1.3.1.32" on the protocol menu (to confirm the module did flash correctly).
Have you tried creating a new (blank) model then configuring the protocol?
Please backup your EEPROM, then post it here (in a .zip file) and I'll try it on an AR9X.

Mike

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 10:23 pm
by MikeB
You are probably using what is the "internal" module connection, in which case:
In "sky/pulses_driver.cpp", starting at line 1195, add in the variable "length" and use it to obtain and then set "byteCount":

Code: Select all

		if ( g_model.Module[0].protocol == PROTO_MULTI )
		{
			uint32_t length ;
			length = setMultiSerialArray( Multi2Data, 0 ) ;
				 
			dataPtr = Multi2Data ;
			uint32_t x ;
			x = g_model.Module[0].ppmFrameLength ;
			if ( x > 4 )
			{
				x = 0 ;
			}
			x *= 2000 ;
			x += 7000 * 2 ;
			rest = x ;
			byteCount = length ;
			bitTime = 10 * 2 ;
My module is on the "external" connection, which already has this change.

Mike

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 10:36 pm
by JanRy
Brilliant Mike,
I am indeed using multi as an internal module and the suggested fix has done the trick.
Than you very much again!

Edit: I got too exited. It appears by replacing byteCount = 26 ; with byteCount = length; the connection with multi is lost. The Multi activity led flashes with 50% duty cycle.

Edit 2:
It does work! I've forgotten to add the line: length = setMultiSerialArray( Multi2Data, 0 ) ;
Thanks Mike, it appears all is good now.

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 10:52 pm
by JanRy
The multi reports rev V1.3.1.32 (next to Bind button). I've attached my EEprom.

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 11:12 pm
by MikeB
These two arrays need to be longer (originally 28 bytes):
uint8_t SerialExternalData[38] ;
uint8_t Multi2Data[38] ;
The array:
uint16_t Pulses2[266]
may also need to be longer, I'm not sure by how much though, but making it 350 should be long enough.

Do you see the correct protocol names now though, even if the module flashes the LED?

Mike

Re: Ersky9x Bug Reporting

Posted: Wed Jul 08, 2020 11:27 pm
by JanRy
OK, I've updated the array sizes too now.
I'm not sure if you saw "edit 2" in my previous post.

One more question. I am confused with the use of MULTI_TELEMETRY and MULTI_STATUS in multiprotocol. Which one should be defined for MBTX?

Re: Ersky9x Bug Reporting

Posted: Thu Jul 09, 2020 9:17 am
by MikeB
Good all is working, I had not seen your edit 2!

I recently added support for MULTI_TELEMETRY, so that is the one to use now as it provides the protocol names from the module. It is possible that MULTI_STATUS will be removed from the module.

Mike

Re: Ersky9x Bug Reporting

Posted: Thu Jul 09, 2020 9:47 am
by JanRy
Got it, thank you.

Re: Ersky9x Bug Reporting

Posted: Mon Sep 21, 2020 6:01 pm
by ReSt
I have a 9XR Pro (FW Vers.: ersky9x-A3r223 from 17.07.2020) with external multi protocol module, running in serial mode.

The fw version (1.3.1.65) of the MPM is only read out, when I select the AFHDS2A protocol.
Once displayed, it is shown with any selected protocol.
Is this normal ?


When I select the Scanner protocol and activate "Display Scan" only an empty screen with the string "Spectrum" in the top left corner is displayed even though a second radio beneath is powered on and transmitting.

Do I have to do some special settings ?

Reinhard

Re: Ersky9x Bug Reporting

Posted: Mon Sep 21, 2020 6:51 pm
by MikeB
Are you using "MULTI_STATUS" or "MULTI_TELEMETRY" in the MPM? Scanner data is only received with MULTI_TELEMETRY.

Mike

Re: Ersky9x Bug Reporting

Posted: Tue Sep 22, 2020 8:39 am
by ReSt
I can't answer this in the moment as I used the precompiled version.

And compiling it myself does not work with the plain code because it's size is to big for the module.
I have not yet found out how to disable the USB support that is expected now for the code to fit the module.

I outcommented a bunch of protocols and activated multy_telemetry, so that code could be uploaded to the module. But this did not get the scanner running.

by the way,
The fw version (1.3.1.65) of the MPM is only read out, when I select the AFHDS2A protocol.
Once displayed, it is shown with any selected protocol.
Is this normal ?
Reinhard

Re: Ersky9x Bug Reporting

Posted: Tue Sep 22, 2020 9:06 am
by MikeB
Use a pre-compiled version that says it is for openTx, these are using MULTI_TELEMETRY instead of MULTI_STATUS, the only difference between the openTx version and the erskyTx versions.

I just checked on a @PRO with erskyTx-A3r223, and a MPM that has 1.3.1.3 on it (first module I had to hand) and the scanner display worked correctly.

Mike

Re: Ersky9x Bug Reporting

Posted: Tue Sep 22, 2020 5:41 pm
by ReSt
I downloaded the A3r223 fw version once more, compiled the mpm code 1.3.1.65 with multy_telemetry (outcommented some protocols) and now, the scanner is working !!!
And the mpm version is displayed with any protocol selection, not only wit AFHDS2A.

Thanks, Mike.

It's now working.

Reinhard

Re: Ersky9x Bug Reporting

Posted: Wed Mar 23, 2022 2:35 pm
by yds
Mike, I may have found a bug with x9e_rom.bin R223 -- here's how stumbled on to this:

in Voice Alerts I create a trigger on SD-down in slot 19 to play a FileType: Name

Code: Select all

VA19 ---- SDv  ON  N
the wav file assigned to the above Voice Alert does NOT play when SD-down is selected, however this wav file assigned to SD-down DOES play every time the Exit nav button at the bottom of the radio is pressed. SD-mid and SD-up both play wav files as expected, only SD-down seems to get mis-wired to the Exit button.