ERSKY9x Questions

[jhsa]

Well, Well, Well, something new. Mike, could you please watch this video when you have time??

https://www.youtube.com/watch?v=PYlbdGcMxsM

Also please have a look at the log. As we can't log TmOK, I used it as source to a scaler and logged it. SC1
Please see the value of TmOK changing from 1 to 2 and back to 1.
Weird problem

Thanks

João

[MikeB]

If you have the main battery connected to the ESC, and you have a voltage divider from the main battery going to the OXS, then you may find you are powering the OXS via this voltage divider. Remember that the processor inputs usually have protection diodes from signal to the power rail. With the processor not powered, but a voltage on any input, this voltage will cause the protection diode to conduct and provide power to the processor.
Holding the balance lead may well AC couple some noise voltage into the processor. Inside a house, you will be picking up mains AC voltage (touch your finger to a 'scope probe!). This noise, probably coupled to the individual cell voltage dividers, will also provide a power source to the processor via the protection diodes. Taken together, you probably supply enough voltage/current for the processor to start running, then stop, then start again, causing the effect you see.

Looking at the log file, look at the "valid" column. The value here is 100 times the "User data timeout" plus the "Receiver data timeout".
The receiver timeout is set to 35 (for 350 mS) every time a link packet is received (RSSI/A1/A2), and the user timeout is set to 90 (for 900mS) every time a user packet is received.
A value of 0 gives TmOK as 0.
A value of 35 or less (but not 0) gives TmOK as 1.
A value of 100 or more gives TmOK as 2.
Clearly, you are receiving link packets (last 2 digits showing 3x most of the time, and sometimes you receive a user packet, first 2 digits show 8x, then half a second later 3x (counted down by 50, 1 count every 10mS, so 50 in 0.5 seconds), then nothing half a second later still.

So this may be the cause of your other alarm(s) at power on.

Mike.

[jhsa]

But Mike, this happens at the field as well.
and i don't remember seeing any of these problems before.. I didn't change anything on the oXs.

Also, the oXs is connected to the receiver by only one wire. The ground to it is connected when I connect the balance plug. How can the oXs be powered from the dividers, if there isn't even any ground connected??
I can see that there is some kind of interference, but a bit weird.. any suggestions to avoid this? If I power the oXs before, this doesn't happen.

About the other alarms at power ON, where is the problem then? Ersky9x? Or am I misunderstanding something?
Ahh, last time I remember having also a false cell voltage alarm when flying.. As far as I know this was caused by the oXs sending data to fast.. But I did increase the time and the problem stopped.. Now it started again? Strange..

I think i will flash the radio with an older version of ersky9x and test..

Thanks

João

[jhsa]

Ok, flashed ProvR221a7 and I can reproduce the problem.. How didn't I see it before?
The question is, what can be done to avoid this then??
The first cell doesn't have a divider. Thed oXs is working at 5V and the first cell is under that value. So, maybe I could put a serial resistance on this pin to limit some current? Without a resistor to ground the analog value would be the same, right?

Thanks

João

[MikeB]

Yes, you could add a resistor (less than 10K), and the analog value should still read correctly. If you connect a lipo cell directly, then it will power the processor via the protection diode(s).

Mike.

[MikeB]

I've posted test version "c9" of ersky9x.
I found a bug (added when I "improved" the protocol setting), where the custom failsafe setting for the XJT was not carried over to the new settings, so the failsafe would be set to all channels at 0% (not good for the throttle).

You will need to configure the custom settings.

The Horus firmware is included in this, and I've improved the file handling on the SD card for saving models and settings. I've also added model moving and copying on the Horus.

Mike.

[jhsa]

Thanks Mike, I think on my latest oXs's I already put that resistor.. I remember having similar problem before, but just didn't connect both situations.. So a resistor should stop the battery cell powering the atmega.. Will try that in the next days..

Thanks

João

Sent from my thor using Tapatalk

[jhsa]

Yes, you could add a resistor (less than 10K), and the analog value should still read correctly. If you connect a lipo cell directly, then it will power the processor via the protection diode(s).

Mike.

Mike, I have been thinking here. I think this doesn't make sense as far as the problem I'm seeing is concerned?

I power the ESC and receiver by connecting the battery's main plug to the ESC (oXs still disconnected)
Then I connect the battery balance plug to the oXs. The oXs is powered by the battery cell number 2.
So, no cell (no power) and no ground is connected to the oXs until i connect the balance plug. So, cell one not having a resistor should have nothing to do with the problem?? That pin (first cell) is connected at the same time as cell 2 which also powers the oXs..

The problem is:
When I finished one flight, disconnect the battery, have the Serial lost alarm (Which is normal). Do not turn radio off.
But when I connect the new battery (same procedure), I get the serial lost alarm as soon as i connect the balance plug after powering the ESC.

Sometimes I also have the alarm the first time I connect the balance plug, not only when replacing batteries..

João

[jhsa]

Hmmm, I have just tried another oXs i have here, and I am not able to make it fail.. let me have a better look at this. Perhaps I haven't updated the plane's oXs with the latest changes (1500mS delay on starting sending data), even if i think I did update it..

João

[MikeB]

I assume you "Serial Lost" alarm occurs when you notice TmOK change from 2 to 1 or 0.
TmOK changes from 1 to 2 when a "User Data" hub packet is received. This could happen due to simply powering up the oXs, causing the serial data signal to the Rx to change. If no more data is sent for a while, then the user data timeout could easily expire (0.9 seconds), and TmOK will drop back to 1.
Is there now a delay in the oXs at startup where it doesn't send any data for at least a second?
Edit: 1500mS delay could easily cause this!

Mike.

Edit2: Try adding a 0.7 sec delay in the voice alert.

[jhsa]

Thanks Mike, today I was seeing the low voltage problem when turning on the oXs ON by plugging the balance plug. Please check the video if you have time

https://www.youtube.com/watch?v=cv8rAt3stNw

I have just updated the oXs with a version that I knew had the 1500ms data delay, and it seems to be working.. no alarms so far.
The voice alarm on TmOK had a 2 second delay and still had the alarm. the reason for the oXs 1500mS delay is that before it was sending the data even before it did read the voltages of course, the result was a 0 volt reading sent.

I now decreased the delay on the voice alarm to 0.5s, and still no alarms.. it seems to work now.. will charge some batts and try to go to the field and test there..

Thanks

João

[jhsa]

Went to the field and all worked as expected. Obviously I thought I've updated the oXs but I never did
Too many projects at the same time

Sorry about that.

Will continue to test though. I still think that a 4K7 resistor in series with the analog pin when not using a divider is a good idea,and can prevent damage to the battery and/or loss of control if for example the atmega pin short to ground..

João

[mrozilla]

(...) Maybe one day I can find time to program a "view log file" option into eepskye.

Mike.

How about Mike, you already have a plan for the log viewer?

[MikeB]

No plan at present I'm afraid. I have just too many other things to do.

Mike.

[RCHH]

C9 flashed to Horus no problem.

Confirmed model move working. However, model backup gives a 'NOT DONE' message.

Also notice on shutdown a 'EEPROM BUSY' message. Am assuming something is 'saving' during that time?

[mrozilla]

No plan at present I'm afraid. I have just too many other things to do.

Mike.

Can you even make a .csv file template to just replace the data from your log file so that the graphs are ready and presented everything?

[jhsa]

I have just built a little low power, DIY Sbus Frsky compatible receiver to be installed inside my new Ar9x radio that I am building at the moment. The receiver worked outside of the radio, so I have proceeded to install it in the radio. It is placed beside the trainer Jack and under the backplate on the back of the radio. Yes it is small
Updated the firmware and bootloader on the board.
On setting up the trainer I have realized that the trainer calibration numbers moved but when I flicked the configured trainer switch, the channels just centered and would not move.
After about an hour messing with it, and as a last resort before I reported a bug I have decided to flash my other Ar9x radio's eeprom to this one.. All suddenly worked.
So I guess the problem was the old eeprom version that still came with the board a year or so ago?

My suggestion is when you install one of these boards, just update the firmware and bootloader as you normally do, and then open Eepskye, create a new blank eeprom, and flash it to the radio. This might save you a couple hours of trying to find out why stuff doesn't work as it should

João

Sent from my thor using Tapatalk

[andrewju]

Anyone using an RF module from a DX5e with ersky9x?
There's someone on a Russian forum asking for help, as he cannot get it to work with an ARUni (as neither internal, nor external module).

[jhsa]

Mike, I think the protocol menu might need some improvement.
It is not the first time that I change the settings for one of the modules thinking I have changed the setting for the other.
Today it happened again. You have just fixed the problem with multi, that wouldn't work on the internal protocol if the external wasn't set to multi frsky as well..
After this was fixed on d5, I was turning the external module off again, and due to the settings being so close to each other, I haven't noticed and somehow I've changed the multi protocol to flysky. When at the field, of course nothing worked on the model
It is difficult to see where the internal module settings end and the ones for the external module begin..

So, my suggestion is to separate both on their own menu inside the protocol menu, just like you did for the trainer (in protocol).
Each module protocol has now quite a few options, specially if multi is selected, and if they are all together it is really confusing..
Thanks
João

[MikeB]

Noted in my "ToDo" list.

Mike.

[jhsa]

Thanks, that will make it really easier to view/understand the menu and avoid confusion and mistakes like mine..

João

Sent from my thor using Tapatalk

[tsenecal]

one other "fix" to the multiprotocol menu... i see that there are quite a few protocols that are 22ms refresh rates, but on my version of ersky9x (latest downloaded from the test page), the list of available refresh rates stop at 11ms... not sure if it ever listed more choices, i have an older rev on an aruni board, and it also stops at 11ms. i would like to know if there is a reason for this? is there something stopping me from having a 22ms setting?

[MikeB]

For the multiprotocol, the refresh rate goes from 11mS down to 7mS. This is the rate at which the mixer outputs are sent to the module. It has nothing to do with the rate over the RF link, which depends on the protocol in use.

Mike.

[jhsa]

Mike, here is an idea that I think is useful. It would avoid having to program the same thing on all models that need a certain piece of programming when we wanted to add it to more than one model. I know that this for sure would not be as simple as I might think to implement but I explain what I mean..

Following an idea form another thread, I have just been playing with eepskye trying to program a trainer setup that reverts the control back to the teacher if one or more sticks are moved from the centre..
I have succeeded, and I would like to have this on more than one model. That means, I would have to program it on every single model I would need this, but it uses a few logical switches. I could make a model with this programming, but then, I couldn't add it to an existing model.
So the idea is to have another type of file that could be stored in a folder on the SD Card. A "Template" file, with another file extension, say ".eetp". These would be Templates that we could create in eepskye, or even the radio, that could be added to other models.
I guess that this opens a few cans of problems but do you think it might be viable? These could also be "add" templates, or "Replace" templates.
A problem that I see is for example, if the template uses the same Logical switches as the model we want to add it.. Would it be possible that when adding it, other (empty) switches would be used, not replacing the existing model's logical switches?

We could also just write the templates using other logical switches that aren't in use by any of our models, of course.. Maybe a warning would be displayed if we tried to add a template that had conflicts with the model we are trying to add it to??

Is this too crazy of an idea?? at the moment we can't even edit the existing templates..

Thanks
João

[ReSt]

For me, I implemented something obviously similar into my templates as an adding template that I can add to every existing model.
See http://www.openrcforums.com/forum/viewt ... ner#p76176

It does work for me with my standard setups
Student is activated with aileron switch
When the template is applied, logic switches L1 to L5 are set up to check the neutral position of every axis of the sticks
Additionally, in the radio trainer menu the required switches are set for the four channels and the mode is set to 'replace'.
(In the moment) I don't change anything in the trainer setup of the protocol menu.
You only have to calibrate the student stick ranges

As long as the teachers stick axis is at neutral (throttle = minimum) the student has control. As soon as the teacher moves any stick away from the 'neutral' position, he has control for that channel while the student still controls the remaining channels.

Reinhard

[MikeB]

This may, in time, be something that a script could do, if it is able to configure logical switches and/or mixes. That way, I only need to provide the basic facility for configuration, then a script is written to provide the template. Maybe the script could ask which logical switches to configure as well.

I'm close to being able to try my new script feature on a radio.

Mike.

[jhsa]

Well, not everybody can compile the firmware, which would be needed to add your own templates I can't do it

As far as the trainer template is concerned, I am using a different approach..
I want to detect only the Ail and Ele sticks.. The master has always control of the throttle at this point.. My Son is just starting

L1 |v|>val Ele 4
L2 |v|>val Ail 4

L3 OR L1 L2 (This combines the detection from both sticks)
L4 1-shot AIL 0.2 (this prevents giving control to the student when AIL switch is just turned ON after I pressed the trainer switch. This is due to the way the Latch switch works. It will force it OFF..)
L5 OR L3 L4 (stick detection and L4 to be used to turn the latch switch OFF)
L6 Latch TRN L5 AND AIL (So, I give control to the student by hitting the TRN switch, but only if the AIL switch is ON)
L7 OR L6 TRN (Use this switch to control the trainer)

So, what this does is, if the AIL switch is OFF, the Trainer is operated normally by the TRN switch, that means,the teacher hold it to give control, and release it to regain control. No stick detection.

When the AIL switch is ON, when you hit the TRN switch once, you arm the Latch switch giving control to the student. If you move a stick, the LATCH will turn OFF and you get the control back, until you momentarily hold the TRN switch again to give the control back to the student..

I like to know at all times who has control of the model. I don't really like the shared control approach. For that I would just use the "ADD" function instead of the "REPLACE" one in the trainer profile..
I prefer to have full control of the model to stabilize it if the student messes up. No doubt that getting the control back by just moving the stick should allow for a very fast recovery when learning to land for example.. Of course it needs testing..

João

[jhsa]

This may, in time, be something that a script could do, if it is able to configure logical switches and/or mixes. That way, I only need to provide the basic facility for configuration, then a script is written to provide the template. Maybe the script could ask which logical switches to configure as well.

I'm close to being able to try my new script feature on a radio.

Mike.

I knew you were going to say that

So, what you mean? The script would just run once (from the SD Card??) to program what is needed on the radio?
Another idea, what about if for example eepskye would be able to generate at least some of the scripts?
I mean, this would make it easy for people (like me) that can't do any kind of programming

We could tell eepskye what we need to do, and eepskye would save a nice script for us. Sorry if this sounds stupid..

João

[MikeB]

Hopefully, the sort of programming needed wouldn't be at all difficult. I would need to add a (built in) function to allow configuring a logical switch, maybe something like:
setSwitch( L3, "v<val", "batt", 73, L2 )
which would set switch L3 to check if the (telemetry) value of the radio battery was less than 7.3 volts with an AND switch of L2.

Mike.

[jhsa]

Mike, that, at first glance looks easy enough
But, any chance of eepskye writing/exporting the scripts while we just program them normally in eepskye?
That would be wonderful. I understand that if it works, it would be a tremendous amount of work for you. It is understandable if you wouldn't even want to consider this option people can learn to write simple scripts, specially when it looks like you are making them even easier to understand than the current LUA stuff..

Thank you

João

Sent from my thor using Tapatalk