ERSKY9X Coding

[ozphoenix]

Mike,
Just curious - is it possible for you to use the same aspect ratio as OpenTX (192x114 png) or FrOS (155x100 jpg) for plane images? That way, icons already produced (for example, on SkyRaccoon) can be used in ErSky9x on the X12S.
Regards,
ozphoenix

[MikeB]

Well, apart from it won't fit in the space I currently have available (128x64), and I'll need to handle .png (or .jpg) files then yes!

Mike

[ozphoenix]

Ok, understood - thanks - figured that would be your answer but just wanted to ask, before I start suggesting UI ideas, so that I don't take up your time asking for things which are neither practical nor reasonable, given your need to support other radios which do not have the graphics capabilities of the X10S/X12S and others, such as Jumper, etc. Trying to get the most bang-for-the buck for the user from your time and effort without imposing unnecessary load on you or the user, also.

Will be back to you later, now that I know that for sure.

regards,
ozphoenix

Well, apart from it won't fit in the space I currently have available (128x64), and I'll need to handle .png (or .jpg) files then yes!

Mike

[MikeB]

I will look into being able to use .png files. I think openTx is using some third party software to handle them. What I don't like with that approach is I don't know what that software is doing. I had a quick look, and I think it is allocating memory "on the fly" to operate. I prefer to know what memory is being used for.
I've downloaded the PNG file format specification.

Mike

[ozphoenix]

Ok, thanks.
I agree - bundling in other people's stuff can lead to unexpected consequences and none of us wants that - let's keep it simple.
Thanks for looking into it, but I'm not asking you to spend a lot of time on it - we can do well enough with what we have, if changing it brings too high a cost, either short-term or otherwise.
Regards,
Ozphoenix

[ozphoenix]

Mike,
I'm slowly working on a longer post about other suggested/possible enhancements while also being distracted with a 3D printing work area (now set up) but in the interest of getting things started, I'd prefer to make an initial comment about having a static model image on the screen, as this area of change leaves me in a quandary, especially given that we now have this wonderful graphics-enabled display available and should probably put it to some useful purpose. Unfortunately, venturing into this type of territory often opens up a maelstrom of conflicting aesthetic and technical opinions -- I hope that is not the case here.

The model name already shows on our screen in big, bold, letters, but sometimes I am so busy fiddling with the plane that I don't always remember to read the model name -- and, I sometimes don't hear the audio of the model name callout I've set up, either -- yes, dumb, but it is what it is. Now, the model picture is a third thing I can miss or ignore, but I think it is a very useful 'add'.

That said, when I'm flying, I seldom look at the radio screen, preferring to receive audio messages, but when I do look at the screen, it's for a very quick moment (remember ... always watch your plane) and, when I do look, I want to be able to quickly see relevant information large and clear. Having a static image show up on the screen when I select a model and when I am setting up and connecting the battery and doing pre-take-off checks would serve me well, but not when I'm up in the air. Further, I am not sure how many users are going to bother collecting an image for every model, so any space permanently reserved for this purpose might serve a few (I'd probably be one of those) but be wasted use of screen space (and leading to less available 'real' information display) for many others.

So, my initial thoughts in this area are:
1. don't take up any space on the main screen with a model picture or any further added details but, instead, expand the font size of all existing ErSky9x menus and screens to evenly take up the whole of the new screen working space
2. instead of a picture on the main screen, have a user-enabled 'flash' screen (per model) that puts a picture (.png format?) on the whole screen, with the model name in big bold letters across the top, displayed for a user-selectable time, immediately after a new model is selected or after the radio is turned (after the existing selectable flash screen).
3. alternatively, I understand that newer radios such as the X10S and X12S can have their screen background changed - maybe put the model image as a transparency (might need a 'settable' percentage of transparency?) which could be displayed 'behind' the normal screens?

Fancy, colourful and pretty graphics screens might win over some users, but an already powerful programming device should not be turned into a digital picture frame. Not being one to want change just for the sake of change but, instead, for the sake of improvement, I think we need to put function before form most often but especially in this case.

So, my main quandary is that I think that the image display of the model is a worthwhile and helpful thing, but I don't want to degrade the benefits we've already garnered through your efforts at streamlining the ErSky9x we know and love already.

Considered alternative suggestions and debate welcomed.

Regards,
ozphoenix

I will look into being able to use .png files. I think openTx is using some third party software to handle them. What I don't like with that approach is I don't know what that software is doing. I had a quick look, and I think it is allocating memory "on the fly" to operate. I prefer to know what memory is being used for.
I've downloaded the PNG file format specification.

Mike

[jhsa]

I do agree with you.. Model picture, should probably only show in one screen.
But I think model name should show always.. In my opinion, we always need a little confirmation of what model we have loaded.. Extra safety for people that forget things fast, just like myself

João

Sent from my BLN-L21 using Tapatalk

[ozphoenix]

No doubt at all - model name appearance and location remains as is.

I do agree with you.. Model picture, should probably only show in one screen.
But I think model name should show always.. In my opinion, we always need a little confirmation of what model we have loaded.. Extra safety for people that forget things fast, just like myself

João

Sent from my BLN-L21 using Tapatalk

[MikeB]

As a first step, I've just configured the X12 firmware to have a new main screen in the cycle. This is like the "Timer 2" screen, but the bottom half of the display just has the model image on it (still 128x64).

By keeping the font the size it currently is, I've increased the number of text lines visible in those menus that use more than 8 lines (currently 12). I think this is better than increasing the font size and reducing the number of lines again.
If I remove the current (fixed position) image, we could have 3 or 4 more lines visible.

The custom telemetry displays clearly need improvement. One item could be the model image.

Mike

[ozphoenix]

Good start

Since you're talking about telemetry -- one concept I have been mulling, given that most X10S/X12S users would be using a Tx module protocol which would support it (as opposed to, say, DJT) is a (slightly-averaged) graph of RSSI. I know we can log this to a telemetry log and then review on a computer at a later time, but a more-real-time display mechanism would, I believe, be helpful in some situations. Certainly not something that I would look at in real time (…..watch that plane), but some people might want to see it (or, a moving averaged line) on a screen as they fly (looking for distance vs reception problems, whatever). Since RSSI is free (no sensors needed) and could be collected easily, then an on-screen graph should be relatively easy, also. Same goes for any other 'free' data sources that make sense.

Again, because of the enhanced graphics capability, for those (like me) who do install lots of sensors in many models, being able to graph several user-selectable telemetry sources, against a time axis, onto a screen while we're at the field can probably help in a number of situations - I could list some examples, but I think they're obvious.

So, not so much about changing or enhancing existing screens, but more about utilising the enhanced display and processing features of the latest radios.

regards,
ozphoenix

As a first step, I've just configured the X12 firmware to have a new main screen in the cycle. This is like the "Timer 2" screen, but the bottom half of the display just has the model image on it (still 128x64).

By keeping the font the size it currently is, I've increased the number of text lines visible in those menus that use more than 8 lines (currently 12). I think this is better than increasing the font size and reducing the number of lines again.
If I remove the current (fixed position) image, we could have 3 or 4 more lines visible.

The custom telemetry displays clearly need improvement. One item could be the model image.

Mike

[MikeB]

I now allow the image to be larger, up to 192 by 114, although still a .bmp. Currently, if it is 128 by 64 it still appears where it was. If it is larger, then you get the "No Image" text.

Clearly, to be able to display a graph against time, the "sensor" values would need to be stored over time to provide the history.
Needs some thought regarding how many values over what time.

Mike

[jhsa]

Mike, if you implement it perhaps it could be placed in a "statistics" menu?

João

[MikeB]

The graphing, and storage/filtering, could be done using a script already I would think!
I may need to add something for the X12 to allow colours to be used when drawing lines and text.

Mike

[ozphoenix]

Oh, bother -- now it looks like I will finally have to go back and re-learn scripting!
Haven't done any for years.
Oh, well -- nothing ventured, nothing gained - so be it!

The graphing, and storage/filtering, could be done using a script already I would think!
I may need to add something for the X12 to allow colours to be used when drawing lines and text.

Mike

[ozphoenix]

Ok, I've looked at the couple of scripts which are on the Er9x released versions site - can anyone point me to where the full script language set is documented and to where any other 'learning'/support material resides?
thanks in advance,
ozphoenix

Oh, bother -- now it looks like I will finally have to go back and re-learn scripting!
Haven't done any for years.
Oh, well -- nothing ventured, nothing gained - so be it!

The graphing, and storage/filtering, could be done using a script already I would think!
I may need to add something for the X12 to allow colours to be used when drawing lines and text.

Mike

[MikeB]

Here: viewtopic.php?f=7&t=10325.
I must put that up on www.er9x.com!

I'll have a look today doing one.

Mike

[ozphoenix]

Haha! I thought I did the right thing going (first) to test versions then (second) to released versions and I still couldn't see this stuff - now, I know why!

Thanks - will work through it now.

regards,
ozphoenix

Here: viewtopic.php?f=7&t=10325.
I must put that up on www.er9x.com!

I'll have a look today doing one.

Mike

[ozphoenix]

Errr, looked through it a bit - reminded me of a bygone era in my early programming life - not difficult, but one which i'm not sure I want to revisit just to see graphs.

Think I'll wait a while and see what you come up with, Mike, before I launch back in to this level of involvement

Haha! I thought I did the right thing going (first) to test versions then (second) to released versions and I still couldn't see this stuff - now, I know why!

Thanks - will work through it now.

regards,
ozphoenix

Here: viewtopic.php?f=7&t=10325.
I must put that up on www.er9x.com!

I'll have a look today doing one.

Mike

[MikeB]

Well I did base it on a "tiny BASIC" interpreter, although I've added more to it.
Hmm, Z80, 4K of RAM, tiny BASIC and a cassette recorder, did that!

Mike

[MikeB]

Here is an example script for drawing a "history" graph.
I've written it for a small display (128x64) so it runs on all radios.
This graphs the throttle stick position as that gives an easy item with which to test. I'm displaying the value as 0 to 100 for fully down to fully up.
The graph updates every 0.5 seconds, scrolling to the left as time passes. the last 40 values are shown on the graph.
Each value is the average for the 0.5 seconds. The sampling is every 10mS nominally, but if the script takes a long time to run, this may be longer (units of 10mS).
The firmware runs a script every 10mS, but limits the number of script statements executed each time to prevent scripts from "hogging" the processor. If the script needs to execute a lot of statements each time it runs, it runs over several "10mS time slots". The display is not updated until the script reaches a "stop" statement, so you don't get a partial display image.

The default method of drawing lines and plotting points is "XOR". If two lines meet, the pixel is drawn twice so ends up "white".
If you pass a non-zero value as a 5th parameter to drawline, this will (currently) change the drawing to "always black". I'm looking at passing an actual colour value for the X12.

(Remove the ".txt" from the filename, I had to add that in order to post the file)

Mike

graph.bas.txt

21-Mar-2019 13:07
Example script for drawing a graph

(1.75 KiB) Downloaded 192 times

[jhsa]

Thanks Mike, need to have a look at that as well

João

Sent from my BLN-L21 using Tapatalk

[MikeB]

I've just posted an update for the X12. I noticed the screen was flickering when running a script, this fixes it.
It also has an update (untested!) where drawline may have a 6th parameter.
The 5th parameter (type) is actually:
0 - XOR
1- BLACK
2 - WHITE
3- Foreground colour
4 - Colour specified by colour parameter (16-bit RGB)
The 6th parameter is the required colour (when the 5th is 4), coded as RRRRRGGGGGGBBBBB, for the Red, Green and Blue levels.
So full Red is 0xF800, Green is 0x7E, and Blue is 0x001F.
drawpoint should also accept 1 or 2 extra parameters for type and colour.

Mike

[ozphoenix]

Thanks for this extra work, Mike. I'll spend some time playing with it later today. This morning, weather forecast is prime for nice flying - missed out last Sunday due to weather, so will go this morning and try to have a double dose this week, as forecast for this Sunday is even better than today. Might take the X12S for its first flying outing in my hands (and with ErSky9x in it) on Sunday

I've just posted an update for the X12. I noticed the screen was flickering when running a script, this fixes it.
It also has an update (untested!) where drawline may have a 6th parameter.
The 5th parameter (type) is actually:
0 - XOR
1- BLACK
2 - WHITE
3- Foreground colour
4 - Colour specified by colour parameter (16-bit RGB)
The 6th parameter is the required colour (when the 5th is 4), coded as RRRRRGGGGGGBBBBB, for the Red, Green and Blue levels.
So full Red is 0xF800, Green is 0x7E, and Blue is 0x001F.
drawpoint should also accept 1 or 2 extra parameters for type and colour.

Mike

[ozphoenix]

I downloaded the latest X12d test version and tried your script - yes, that's close to what I was meaning - thanks! I say 'close' because I see that this will scroll off the screen by the time I walk back to the pits to view it, but that's probably a next step, I guess.
For my next step, I made some simple mods to your script to read RSSI and display it as 1-110 (arbitrarily chose an upper limit), just to check the workings of the script and also my old brain - works as expected ('well' for the script, 'slowly' for my brain) when bound to a receiver on my bench - I then walked around my house stressing the RSSI signal and got the expected variations. Just for fun, here it is attached.

next steps are for refinement, I guess.

regards,
ozphoenix

I've just posted an update for the X12. I noticed the screen was flickering when running a script, this fixes it.
It also has an update (untested!) where drawline may have a 6th parameter.
The 5th parameter (type) is actually:
0 - XOR
1- BLACK
2 - WHITE
3- Foreground colour
4 - Colour specified by colour parameter (16-bit RGB)
The 6th parameter is the required colour (when the 5th is 4), coded as RRRRRGGGGGGBBBBB, for the Red, Green and Blue levels.
So full Red is 0xF800, Green is 0x7E, and Blue is 0x001F.
drawpoint should also accept 1 or 2 extra parameters for type and colour.

Mike

[MikeB]

I see you have a line:
history[index] = value/2.2

These scripts don't support floating point. You need to do value*10/22.
BTW, some testing of scripts may be done on the computer. On the post where the script.pdf is, there is also a file "Interpreter.exe". This runs scripts on the computer. Just download it and copy it to the directory where you have eepe/eepskye installed.

It uses the same source code file as the ersky9x firmware, it just cannot access things like "getvalue()", so these just return 0.

Mike

[ozphoenix]

Ah, didn't know about the floating point - thanks. Part of the reason I attached it was to receive any such pointers

And, I had wondered if I could run these on a PC first but hesitated to ask - thanks for that detail, it'll help.

Have shutdown my laptop for tonight but I'll continue to fiddle tomorrow and try a few other things, including the pc way - thanks.

BTW - the flying forecast was right and good - slight breeze, mixed cloud cover - but, 30C+, so gave it away after about 3.5 hours - too hot out in the sun

Now, I just need to figure how to open a telemetry log file and display some chosen values as a 'playback' directly at the field - shouldn't be too hard! You've got me thinking now - that's dangerous!

Regards,
Ozphoenix

I see you have a line:
history[index] = value/2.2

These scripts don't support floating point. You need to do value*10/22.
BTW, some testing of scripts may be done on the computer. On the post where the script.pdf is, there is also a file "Interpreter.exe". This runs scripts on the computer. Just download it and copy it to the directory where you have eepe/eepskye installed.

It uses the same source code file as the ersky9x firmware, it just cannot access things like "getvalue()", so these just return 0.

Mike

[MikeB]

Could be interesting!

Mike

[jhsa]

Definitely, specially if it could also be applied to other radios

Mike, by placing the interpreter.exe file in the eepskye directory, why not accessing it from eepskye itself?
Or does it work like that already?

João


Sent from my BLN-L21 using Tapatalk

[MikeB]

I need to find time to integrate it in to eepskye. For the moment, it is quicker for me to have it separate.

I've update the script.pdf file with the most recent changes, and I've also updated the Interpreter.exe file to have a "slider" that provides a value for "getvalue", currently between -100 and +100. I plan to add options to set the limits for the slider.
I tested graph.bas with this and it worked OK.

I'll give some thought to a function that reads data from a .csv file, may take a while to get something done though.

Mike

[jhsa]

Thanks Mike. Will this "graph.bas" script work on other radios??

João