Ersky9x Bug Reporting

[budavaril]

When you switch on the radio if you hold the trimms outwards ?

[jhsa]

That is maintenance mode, yes..

[budavaril]

I mean the maintenance mode available in "two way.."
One method is from the menu (I think is in the "General"?) when the radio started already. (Because his radio "looping" this way definitely not available now)

But this is the second option.. (When we hold the trimms, just opposite than firmware update)
I just thought may this option still could working even the radio "looping" instead of done the boot and initialize the whole menu..
He actually didn't mention which method he tried.. Or did he??
For me once worked this, when in the firmware was some bug and the start screen was freezing.
(Yes... That time not in the bootloader was the bug , so maybe now just my stupid idea)
If is not late night I sure flash one of my pro to try...
Another thing he wrote he was able to flash r211 fw on the radio (and that not "looping"), just the maintenance missing..
I have just an r212 and in that firmware from the menu not exist the maintenance mode yet, but with the trimms it works.

[ReSt]

But this is the second option.. (When we hold the trimms, just opposite than firmware update)

No, that didn't work either.

It was absolutely stuck in the "flash firmware" loop.

Reinhard

[ReSt]

I installed this code

You could try flashing "ersky9xs_rom.bin" (the "small" version for the SKY board).

AND IT WORKED !!!

Thanks Mike,

Reinhard

[jhsa]

Nice, well done

João

[ReSt]

I downloaded the github code from 2019-11-27 and there are some problems.

ErskyTx:

Compile error with AR9x/9XRpro
====================
Compile parameters: make REVB=1 STAMP=1 DEBUG=1 REV=222 USER=ReSt

menus.cpp: In function 'void menuProcIndex(uint8_t)':
menus.cpp:24513:28: error: 'BtStatus' was not declared in this scope

Model Setup - General
===================
on Page2 the continuation arrow disappears when the last line (Custom Check) is selected.

Page3
shows BG Script as the last line, but "Disable Thr Check" is not shown

And for ER9x:
pulses.cpp does not compile.
All three procedures at the end of the file (sendByteSerial, buildSbusFrame, putSerialFlush) and the definitions above them (starting with // sbus code) must be commented out.

The statement "uint16_t SerialStream(400)" probably breaks the free ram limit and leads to permanent reboots.

Reinhard

[MikeB]

I've just fixed those and updated Github.
I was looking into adding the SBUS code only to the 2561 version of er9x that has more RAM, but forgot to make it conditional for the other processors, now just commented out.

I need to do a full build and test on all radios now.

Mike

[ReSt]

Thank you, Mike

Reinhard

[jhsa]

Thank you

João

[ReSt]

Ersky9x without telemetry using Flysky protocol
By Chance I found the reason why one of my models was permanently telling me "No Telemetry"
When the Telemetry Usr Protocol is set to HUBRAW the radio permanently, with maximum repetitionrate, tells you that there is no telemetry
This Bug is there since the user protocol HUBRAW was introduced.

Reinhard

[MikeB]

I can't reproduce this. I used the MULTI protocol selecting the first protocol of Flysky, and set the Telemetry Usr Protocol to HUBRAW. I don't get the "No Telemetry" voice message, except once when I turn the radio off, or when I change the Usr Protocol to something else.
Possible there is another setting you have as well that causes your continuous voice output.

Mike

[ReSt]

Mike, thanks for looking into that problem.
You made me uncertain about my problem, so I wanted to verify it again.... and got ... no problem ??????
even with fw versions that I knew they had shown the same symptom.

My 'dirty' temporary circumvention (as I do not use any telemetry) of that permanent call was
on the github download from 31.03.2020 in module frsky.cpp after line 2497 ... == TELEMETRY_HUBRAW )
I commented the line "frskyStreaming = ......
With this modification, there were no more No Telemetry calls


But then I retried it with my other radio (also 9XRpro) and it was immediately calling "No telemetry"
That radio has a different mpm module!!!
The "failing" module I bought lately from AliExpress and it is signed as "JMT 4IN1"
The "good" module was from Banggood (without a housing).

So it looks like that this problem depends on the mpm module.

Reinhard

[jhsa]

You could try updating the module..

João

[MikeB]

Checking this in general, HUBRAW overrides the normal telemetry processing, which includes processing the status data from a multi-protocol module.
This status data includes the module firmware version, and if you have MULTI_TELEMETRY set it also includes the protocol names.
erskyTx now supports MULTI_TELEMETRY, as well as MULTI_STATUS. MULTI_TELEMETRY is now recommended as it automatically picks the correct telemetry protocol.
You should only set HUBRAW if you really have the raw hub telemetry, which won't be the case with a multi-protocol module.

Mike

[ReSt]

I had the mpm already updated with the recent precompiled version "multi-stm-ersky-reta-inv-v1.3.0.76" (but redid it, to be sure)
No idea how that fw is compiled regarding MULTI_TELEMETRY or MULTI_STATUS.

Nevertheless, without a telemetry signal available, shouldn't it tell me the missing telemetry only from time to time, say, every ten seconds or so?

Reinhard

[MikeB]

If the filename includes "ersky", then you have MULTI_STATUS, if the filename contains "openTx", then you have "MULTI_TELEMETRY".
The MPM sends a status packet regularly, I'm not sure how often, but it is quite frequent (less than one second between packets).
I'm looking at detecting the module protocol is "MULTI" when you have "HUBRAW" set and handling the data from the module "properly".

Mike

[ReSt]

No Telemetry is also permanently called with the open TX version.
But when I compile the mpm code with "//define TELEMETRY" then there are nomore calls of 'No Telemetry'

Reinhard

[jhsa]

But then you also do not have telemetry, right?

João

[ReSt]

That's correct, but that's not a problem as I only use flysky AFHDS receivers that don't have telemetry.

Reinhard

[MikeB]

The problem is that the multi-protocol module is always sending "telemetry" data (except when you compile it off). This data includes the module status as well as any actual telemetry data.
Setting the USr Protocol to HUBRAW tells the firmware that you are only expecting raw hub data, not the MPM status. If using a MPM, then setting HUBRAW is actually meaningless as the telemetry protocol is never raw hub data.

However, if you change the code that handles the HUBRAW setting to this:

Code: Select all

	else if ( g_model.telemetryProtocol == TELEMETRY_HUBRAW )
	{
		if ( g_model.Module[1].protocol == PROTO_MULTI )
		{
			switch (dataState) 
			{
				case PRIVATE_COUNT :
				case PRIVATE_VALUE :
#ifndef SMALL
				case PRIVATE_XCOUNT :
				case PRIVATE_TYPE :
#endif
					if ( handlePrivateData( dataState, data ) )
					{
    	 					break ;
					}
					// else fall through
				default :
					dataState = frskyDataStart ;
			        	if (data == PRIVATE)
					{
						dataState = PRIVATE_COUNT ;
					}
				break ;
			}
		}
		else
		{		
  			frskyStreaming = FRSKY_TIMEOUT10ms; // reset counter only if valid frsky packets are being detected
	    		frskyUsrStreaming = FRSKY_USR_TIMEOUT10ms ; // reset counter only if valid frsky packets are being detected
			frsky_proc_user_byte( data ) ;		
		}

I think it should all work correctly.

MIke

[ReSt]

Thanks, Mike

this fix did the job.

No more 'No Telemetry' calls with the fully telemetry enabled module.

Reinhard

[35mhz]

Hardware Taranais X7

V222

Testing indicates that the LED on the on off switch does not operate in V222, its ok in v221

[MikeB]

Working OK on my X7. Have you reverted to V221 to double check it still works with that and then gone back to V222 to see it doesn't?

Mike

[35mhz]

Mike, as soon as I load v221 the LED comes on, tried on 2 X7s and both the same, just nothing on v222

version shows as erx0d-r222 6/3/20 11:34:30 mod QX7

[MikeB]

Is the LED green when it works?
My X7 is an early one where the SPort connector in the base is not fitted. It is possible the LED connections (there are 3 for the three possible colours) have been changed.

Mike

[35mhz]

Hi Mike,

Yes its green in V221, the X7's are about a year old, both FCC china import versions

[MikeB]

What version of the bootloader do you have and is the green LED on in bootloader mode?

Mike

[35mhz]

Mike,

the Bootloader shows as OTX Bootloader - 2.2.2.

The Green LED does not show in bootloader mode on either 221 or 222

The Green LED shows immediately i reolad 221 from 222.

Both X7's exhibit the same result

[MikeB]

The bootloader code always briefly to check for the trim switches. The erskyTx bootloader turns the green LED on, so if I have a mistake in V222 (I think I can see the problem) the green LED is on anyway.
You could try putting the erskyTx bootloader on the radios.
1. Best to backup the entire flash memory just in case you need to replace the existing bootloader.
2. Copy the V222 erskyTx file to the SD card, put it in the "FIRMWARE" directory (not firmwares).
3. Start in "maintenance mode (power on with the horizontal trims held APART).
4. Select UPDATE BOOTLOADER, then select the file you put on the SD card.
5. Confirm the operation.
6. Return to the main maintenance mode menu, then power cycle the radio.

Mike