openrcforums

Mike,

Updated the bootloader to v3.1, all seems ok now and LED works ok.

Thanks

Mike, I think I found a problem. I had an earlier version of ErskyTX installed on my 9XT radio when I made this video today. But After installing r222_D7 (Latest??) the problem persists. Please check the video below.
I have just found out that the problem happens if the trainer radio is ON when I try to select a trainer profile, and the radio reboots. If the trainer radio is OFF, I can select the profile and the 9XT radio does not reboot. As you probably remember, my radios have a DIY receiver inside outputting SBUS for wireless trainer.
I just wanted to adapt my Son to a new plane today, but couldn't change the trainer profile from OFF to something else without the radio rebooting. Ended up just passing my radio to him just like we used to do it quite a few years ago
Here is the video.

https://www.youtube.com/watch?v=65Fcq9N0Oe8

Thanks for looking into it.

João

I'll have a look tomorrow. Note that R222 is released at www.er9x.com, test versions are now for R223.

Mike

Thanks Mike.. I suppose that there is still no 223 test versions? At least I haven't seen any.
Is D7 the same as the released 223? I missed your post announcing the 222 release, sorry about that

João

Where is the internal Rx SBUS signal connected?

Mike

To the trainer input. Here is the project page.

https://openrcforums.com/forum/viewtopic.php?f=7&t=9400

Thank You

João

I've just posted a test version that may fix that bug.

Mike

Thanks Mike, will test asap and let you know..

João

Mike, flashed the test version. No more rebooting, but....
I set the trainer as I always did, but it didn't work until I un-selected the SBUS invert box.
Before this box had to be selected for the SBUS trainer to work. So, it looks like you have changed something there?

Not a big problem. Just want to make sure there isn't another bug..

Thanks
João

Hi Mike, not sure you saw my report just above?

Thanks

João

I was using two channels in a timer to capture the SBUS signal, one for rising edge and one for falling edge. When I added support for more transmitters, I had to just use a single channel for both edges, but missed changing the timer configuration for some transmitters. The need to toggel the invert SBUS option has occurred as a result of this change.

Mike

Thanks Mike.. Now I know it is not a problem and that we have to use it not inverted.

João

Mike, there is some kind of problem with the latest ErskyTX, at least with the 9XTradio. Some models need the SBUS signal of the trainer RX to be inverted, and some not inverted. So, something ,might still not be quite rightk, at least on the 9XT?
Also today I saw some odd behavior. I have learnt that my radio doesn't warn me of flight battery voltage whatsoever. I normally check the voltage regularly, but today I had the voltage drop under both lower cell voltage and FasV. No alarms at all. The values are read when I press a switch, therefore I haven't noticed this before. I suspect this problem was already present in the last version as last time I was surprised to have had lower battery voltage than I normally do. I like to take care of my batteries.. I have some 6 or 7 year old batteries still flying
Today, I rebooted the radio to check, but the problem was still there. After I rebooted the radio ( model secured of course), when powered ON, the radio started singing all sorts of nonsense like voltage at one thousand four hundred and something volts So, I guess that something is not quite right

Thanks in advance for looking into this. Please let me know if you need some specific testing.

João

If you are using FrSky hub telemetry, then rebooting the radio, with the Rx still operating, is likely to end up overflowing the telemetry buffer in the Rx and or Tx module resulting in corrupt telemetry data until the radio catches up and the buffers get flushed.

Is the FasV value and the low cell voltage value displaying correctly all the time when operating normally?

I can't see any reason for some models needing to invert the SBUS signal on the jack and others not. This may need specific testing.
Are you using the same trainer profile on all the models?
If you have two models that need opposite invert values, does the trainer input still work if you power cycle the radio on each model?

Mike

MikeB wrote: ↑Tue Jun 02, 2020 8:51 pm If you are using FrSky hub telemetry, then rebooting the radio, with the Rx still operating, is likely to end up overflowing the telemetry buffer in the Rx and or Tx module resulting in corrupt telemetry data until the radio catches up and the buffers get flushed.

Ok, that is one out of the equation. But what if the buffers were flushed at power ON before any events were spoken?

Is the FasV value and the low cell voltage value displaying correctly all the time when operating normally?

I think so Mike. I did read telemetry several times before this happened. In fact that is the reason I found this out, as I never let the batteries discharge so much. Today was an amazing weather to fly and i have just forgotten about the batteries. Luckily I always check with the switch. It is a habit I have since Er9x started supporting telemetry a few moons ago
I also flew a glider with vario, and the radio was always beeping. I guess that means the telemetry was alwqys being read and displayed.. Just no alarms..
I will have a better look tomorrow and hook a variable PS up, and see what I find.

I can't see any reason for some models needing to invert the SBUS signal on the jack and others not. This may need specific testing.
Are you using the same trainer profile on all the models?

Yes I am, but I can confirm tomorrow.

If you have two models that need opposite invert values, does the trainer input still work if you power cycle the radio on each model?

If I understand well what you mean, I do think so, but I can test tomorrow and will let you know..

Thank you

João

jhsa wrote: ↑Wed Jun 03, 2020 12:26 am

MikeB wrote: ↑Tue Jun 02, 2020 8:51 pm If you are using FrSky hub telemetry, then rebooting the radio, with the Rx still operating, is likely to end up overflowing the telemetry buffer in the Rx and or Tx module resulting in corrupt telemetry data until the radio catches up and the buffers get flushed.

Ok, that is one out of the equation. But what if the buffers were flushed at power ON before any events were spoken?
. . . .
Thank you

João

The buffers are in the Rx and the Tx module, I can't do anything about them.

Mike

Understood, thank you

João

Hi Mike,
I've updated my transmitter (ArUni based Ersky9x - which I must compile myself to enable encoder page navigation) with the latest Multi-protocol and copied the multi.txt to the SD card. The file has now 72 entries. The protocols names are not displayed correctly anymore. Some have names, others just numbers and the last protocol number is 64. Is there a limit for the number of entries in Ersky9x? I've compiled the latest github firmware.

I've just committed the sources as I have them for the latest test versions. This includes the changes to allow more than 64 protocols for the Multi-protocol module and also get the names from the module. In the case the module isn't providing the names, there is a built in list that is also updated from Multi.txt.

Mike

Thanks Mike, I'll re-flash it tomorrow.

Hi Mike,
something is not right. I am getting the following error:

obj_ersky9x/menus.o: In function `menuRangeBind(unsigned char)':
R:\_Tx__Rx-DIY_modules\_My_Transmitters\ARuni-DIY transmitter\mbtx-master\radio\ersky9x\src/menus.cpp:10517: undefined reference to `DebugDsmBind'
obj_ersky9x/menus.o: In function `menuDebug(unsigned char)':
R:\_Tx__Rx-DIY_modules\_My_Transmitters\ARuni-DIY transmitter\mbtx-master\radio\ersky9x\src/menus.cpp:18184: undefined reference to `DebugDsmBind'

Just delete any line with DebugDsmBind in it, I'll commit an update later today, I've got some other debug in I need to sort first.

Mike

Hi Mike, that worked.
I've noticed an issue, though. The radio displays correctly the protocols 1-64, then starting with 65 I get briefly the correct name (i.e 'FrSkyR9') but then it changes to 'FlySky'. The same goes for the rest of the list. The displayed protocol is 'Selected'-64.
The protocols 69-72 initially display blanks and then it switches to the 'Selected'-64 protocol name.

The module only sends the protocol name once per second, which is why the displayed name changes, the built in name is displayed immediately, then this changes to the name received from the module. I see there is a bug where the protocol number is not displayed if there is no built in name.
On my radios I get the correct names displayed for protocols above 64, maybe there is a bug if you compile with "ARUNI" defined,, I'll have a look.

Mike

I am compiling only with the REVB=1 option.

OK, I'm testing with an AR9X board with the same compile option, just need to charge the Tx battery!
Make sure you have the latest "Multi.txt" file.

Mike

Blank names are caused by the buffer I used to hold the text from Multi.txt overflowing. It is currently set to a size of 600 bytes. I only store the differences in Multi.txt compared to the built in text. A quick solution for you is to increase that buffer to, say, 800. I'm just updating the built in names so only a few bytes are needed.

Mike
Edit: What revision of firmware are you using on the multi-module?

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

Interesting, I've not seen this, although I normally switch the Rx off first, then the Tx, then switch the Tx on first then the Rx.
Do you have a safety switch set on the throttle channel? I always use a sticky safety switch on the throttle channel.
What Tx module and receiver are you using?

Mike

Thanks Mike,
I've tried #define MULTI_TEXT_SIZE 800 (If that's the buffer in question), but it made no difference. The multi revision is V1.3.1.36.
I am in no rush for the fix, since I am not using any protocol over 65 at the moment.