DM-1701 screen clipping

[VK3KYY]

Now that the source code if available I could finally do it, the radio feels so much better to use.

Since the DM-1701 does not have GPS, and the GPS status does not needs to be displayed in the status bar, I could make all fields a little more spacious.

The DM-1701 has a very big display compared to the other radios, so the Channel display had plenty room even if I added 12 pixels at the top. I just had to rearrange some elements. I did not touched the menu and other pages, I think that can be skipped, but the channel screen was very important, now I think it's so much better.

1701_dmr_after3.png

What did you change to fix this in the source code ?

i.e Did you change the position of everythng or make a change to the XY offset in the data transfer to the display?

[ct1esj]

Now that the source code if available I could finally do it, the radio feels so much better to use.

Since the DM-1701 does not have GPS, and the GPS status does not needs to be displayed in the status bar, I could make all fields a little more spacious.

The DM-1701 has a very big display compared to the other radios, so the Channel display had plenty room even if I added 12 pixels at the top. I just had to rearrange some elements. I did not touched the menu and other pages, I think that can be skipped, but the channel screen was very important, now I think it's so much better.

1701_dmr_after3.png

Well done boy. All DM-1701s have a lot of space on the display, and it is properly structured. I would like, and I assume many more owners, to see this structure in the next update. Glad someone got the display fix. THANKS

[VK3KYY]

Now that the source code if available I could finally do it, the radio feels so much better to use.

Since the DM-1701 does not have GPS, and the GPS status does not needs to be displayed in the status bar, I could make all fields a little more spacious.

The DM-1701 has a very big display compared to the other radios, so the Channel display had plenty room even if I added 12 pixels at the top. I just had to rearrange some elements. I did not touched the menu and other pages, I think that can be skipped, but the channel screen was very important, now I think it's so much better.

1701_dmr_after3.png

Well done boy. All DM-1701s have a lot of space on the display, and it is properly structured. I would like, and I assume many more owners, to see this structure in the next update. Glad someone got the display fix. THANKS

We will fix this problem if the solution is practical

i.e In the code the location of most texts is defined and can be changed for different types of radios, but sometimes the position of a specific piece of text is offset from another piece of text, so sometimes simply changing the 'defined' positions causes one screen to be fixed but other screens to be broken.

[HA5DS]

What did you change to fix this in the source code ?

i.e Did you change the position of everythng or make a change to the XY offset in the data transfer to the display?

Well, for now I only changed the code, so it would work for me, but since the DM-1701 has its own firmware, I see no reason why it cannot be done.

I modified the define constants to move the text locations, and these are defined like this:

Code: Select all

#elif defined(PLATFORM_MD380) || defined(PLATFORM_MDUV380) || defined(PLATFORM_DM1701) || defined(PLATFORM_MD2017)
#define DISPLAY_H_EXTRA_PIXELS                32
#define DISPLAY_H_OFFSET                     (DISPLAY_H_EXTRA_PIXELS / 2)
#define DISPLAY_V_EXTRA_PIXELS                64
#define DISPLAY_V_OFFSET                     (DISPLAY_V_EXTRA_PIXELS / 2)
#define MENU_ENTRY_HEIGHT                     16
#define SQUELCH_BAR_H                          9
...

So the same values are used for 4 platforms, this can be separated, so the DM-1701 could have it's own values.

Most of these defines were in the uiGlobals.h file, there were 2 values for the VFO sweep graph in uiVFOMode.c.
There are also a couple of the in uiUtilities.c file.

I also needed to modify the code a little bit, because even though the position of the texts in the header was defined by these constants, the inverted rectangle of the mode text (FM/FMN/DMR/etc.) was fixed starting from position 1,1.
Also the uiUtilityRedrawHeaderOnly function needs to redraw 3 rows now, not 2.

[VK3KYY]

What did you change to fix this in the source code ?

i.e Did you change the position of everythng or make a change to the XY offset in the data transfer to the display?

Well, for now I only changed the code, so it would work for me, but since the DM-1701 has its own firmware, I see no reason why it cannot be done.

I modified the define constants to move the text locations, and these are defined like this:

Code: Select all

#elif defined(PLATFORM_MD380) || defined(PLATFORM_MDUV380) || defined(PLATFORM_DM1701) || defined(PLATFORM_MD2017)
#define DISPLAY_H_EXTRA_PIXELS                32
#define DISPLAY_H_OFFSET                     (DISPLAY_H_EXTRA_PIXELS / 2)
#define DISPLAY_V_EXTRA_PIXELS                64
#define DISPLAY_V_OFFSET                     (DISPLAY_V_EXTRA_PIXELS / 2)
#define MENU_ENTRY_HEIGHT                     16
#define SQUELCH_BAR_H                          9
...

So the same values are used for 4 platforms, this can be separated, so the DM-1701 could have it's own values.

Most of these defines were in the uiGlobals.h file, there were 2 values for the VFO sweep graph in uiVFOMode.c.
There are also a couple of the in uiUtilities.c file.

I also needed to modify the code a little bit, because even though the position of the texts in the header was defined by these constants, the inverted rectangle of the mode text (FM/FMN/DMR/etc.) was fixed starting from position 1,1.
Also the uiUtilityRedrawHeaderOnly function needs to redraw 3 rows now, not 2.

OK

For this to be usable a new section would need to be defined for PLATFORM_DM1701 and also the other places would need to have #if defined(PLATFORM_2017) around them

BTW.
The reason there is a function called RenderRows is because the radios with black+white screens have the screen divided into sections of 8 rows becuase of the way the 1 bit data is organised. And because the UI code is almost completely unified across black+white and colour screen radios, then the renderrows function is retained even though its not applicable to the colour screen radios.
Probably it should be replaced with a function like RenderLines which calculates the Row from the Line for black+white radios, but no one has time to retrospecively clean the code, especially as changing code can accidently introduce bugs

Anyway.
When you finish, can you zip the files from the application directory, and I can do a file compare and determine whether there is a way to implement this without affecting the layout of the UV380 and the other radios which share the same codebase, or the other radios which use the shared UI code i.e probably all the radios including GD77 and MD9600 and now MD2017

[HA5DS]

OK

For this to be usable a new section would need to be defined for PLATFORM_DM1701 and also the other places would need to have #if defined(PLATFORM_2017) around them

When you finished, can you zip the files from the application directory, and I can do a file compare and determine whether there is a way to implement this without affecting the layout of the UV380 and the other radios which share the same codebase

Sure, I will do that.

Another thing I did, which I think it's worth considering for all models, is that I specified another background color for the background of the RSSI bar, rather than the background color of the header. That way it's a little bit more distinguished from the header itself, I like this look better.
Of course if somebody doesn't, it's always possible to set to the same value as the header even if it's a separate theme option.

Right now I did this with a quick and dirty solution, I used the GPS spot option in the Theme Editor, since the DM-1701 does not have GPS, and this way I didn't need to add a new theme option everywhere.

But I think it's worth considering doing that.

[VK3KYY]

...
Another thing I did, which I think it's worth considering for all models, is that I specified another background color for the background of the RSSI bar, rather than the background color of the header. That way it's a little bit more distinguished from the header itself, I like this look better.

I do not know if this will be practical. There is very limited space available for these additional data blocks e.g the theme data

Daniel wrote the theme data system, and I don't know whether he used all available space

Also, the way the extra data (e.g theme data) is stored, is complex, and not designed to handle changes to sizes of data structure

[F1RMB]

Just moving down the header offset is not enough, you will get visual problem, as the header has 16 pixel height, past this it won't really work (like RSSI rendering).
Changing the screen scheme is not an easy task, because you should not break all other supported platform, and also don't harrass the MCU/BUS too much.

[HA5DS]

Just moving down the header offset is not enough, you will get visual problem, as the header has 16 pixel height, past this it won't really work (like RSSI rendering).
Changing the screen scheme is not an easy task, because you should not break all other supported platform, and also don't harrass the MCU/BUS too much.

Yes, of course I needed to move down the RSSI bar as well, and also the TG display, etc.
I also needed to check to whole code, how many rows we are updating on the display and why, and does it needs to be changed, or not.

This is a before and after screencap of the DMR display:

1701_dmr_before.png (3.33 KiB) Viewed 495 times

1701_dmr_after3.png (3.2 KiB) Viewed 495 times

[F1RMB]

I'm talking about rendering, not drawing.