New LCD proposal

[sp9bsl]

Hello everyone, my name is Slawek, this is my first post in this topic. Encouraged by Andreas, i would like to present some work with raspberry pi LCD connected to UI board. This LCD module has resolution 480x320, size of 3.5" and SPI interface. You can see it working in my video published few weeks ago: video I made simple adapter board with few connectors and 5V voltage regulator, simply inserted in socket for 2.8" LCD. The only modification of UI board is connected 8V for 5V voltage regulator on unused LCD pin. I decided to add a voltage regulator because of thermal hazard of U3 (LM2941), this LCD (its backlight) needs about 80mA more current. This is all regarding hardware. Ofcourse i can always step back to old 2.8 LCD by simply replacing it without soldering. This LCD is also few milimeters bigger in both directions and won't fit in tight case prepared for current LCD.

Now about firmware. As you can see on video there is simultaneous spectrum and waterfall display. This is the main advantage over normal solution with 2.8" LCD. I managed overall outfit of lcd by watching video recorded by HAM from Russia: video As you may think, there is a lot of differences with driver code. This LCD uses ILI9486 controller and it has little similarity to ILI932x, so almost all basic functions regarding communications required changes. Also because of twice as width compared to old LCD i also changed buffers size and depth of FFT. Simultaneous spectrum and waterfall display requires more memory for buffers that are swapped between waterfall or spectrum in current firmware.

Display of spectrum and waterfal at one time required rewrite DMA based LCD functions to speed it up. Instead of drawing every bin of FFT pixel by pixel i changed it to two pre drawn buffers. The first buffer contains background with grid, second is full filled with color of spectrum display also with grid. Drawing function simply changes buffers instead of pushing every pixel to buffer and flushing it when is full. This step gives speed up for about twice. I also added highlight for filter bandwidth working in the same way.

There is one drawback, i did not test freedv communication. Display improvements i made required more RAM for double buffers for FFT results needed by scope and waterfall. Now i have 102292 bss and 3736 data. There is some room for heap/stack but i cannot guarantee that freedv will now work, . I didn't mention that i still use STM32F405 with 192kb of RAM. Although i didn't find any RAM usage statistics for freedv.

I know that it will require a lot of work to integrate new lcd with current project, although i think that this change will bring big enhancement in overall look on this fantastic project. There is a lot to speak and think about it, i'm open for any suggestion where to start. At the beginning there should be a little cleanup with current definitions of placement items on LCD and touch. Plenty of them are coded inline (touch panel mainly). If we decide to integrate this lcd to current project, i think there should be conditional code compilation for new lcd version because of different item positions and size.

73, Slawek SP9BSL

[s53dz]

I wonder if in the case of introducing another/bigger LCD it would not be beneficial to add also a dedicated MCU for operating LCD. Just guessing. Probably in this case an STM32F429VG with 1MB flash and 256kB RAM could do its mcHF SDR job just fine.

73 Bojan

[df8oe]

Hi Slawek,

your suggestion and improvement is welcome. Your idea to implement it as "conditionally building" is very good, too. Freedv is eating much memory - there is not much free RAM at the time if you use STMs with 192KB of RAM. Maybe there can be done some enhancements - but I am not sure how much RAM this can free. Additinally, UHSDR works with STMs which do have 256KB of RAM (already in mcHF) - and on OVI40 there is F7 with 512KB of RAM. So the step

• adding code so that it is built conditionally frees up to do possible dynamic handlings later.

Regarding supply current: The 3.2" LCD which I use on adaptor PCB does consumpt ~60mA more than 2.8" - and is working using old regulators. Of course concept of 8V regulator is not a lucky one (and will be completely different in OVI40) - but it will still work if you do have good cooling.

Regarding of ui placement: 320x240 LCD of course will have another layout as 480x320. So there must be two different uis. We must talk about functions which can be used by both ui types so that code duplication is minimized. We must talk about the way we will start this. You have done your tests using nearly new firmware versions so you can make proposals what must / should be changed first.

vy 73 Andreas

[yo2ldk]

I personally, prefer the variant with both spectrum and waterfall, freedv is completely useless for me, and certainly for many others. Also, based on OVI40, I dream for a good 5" LCD (as it is on STM32F7 development boards) , at least on OVI40-II :)

73 de alex - yo2ldk

[df8oe]

OVI40 ui is very flexible and can (and will) support bigger LCDs. But for portable use it still can handle 3.2" LCD and this is the one which will be the "default one". Bigger LCDs are simply coupled to SPI and can be added later.

73 de Andreas, DF8OE

[sp9bsl]

Dedicated microcontroller for LCD is good idea but this is completelly new design and total change in the code. Better way for this project is to change microcontroller to F7 and make benefit of its SIMD instructions. Unfortunatelly i cannot find info/schematics of OVI40 trx - can you point me where should i look to find it? My hardware is build on mcHF boards so simple changing F4 to F7 microcontroller is not possible (pin mismatch). So now i can only work with small improvement using adapter pcb converting 2.8" to 3.5" lcd on the ui board. New socket for LCD is highly welcome but this is Chris part of work due to licensing (i think). Besides 3.5" lcd is the best price to functionality ratio. Ofcourse we can use dedicated gfx controller from 429 of F7 with SDRAM and it should help a lot with core load, but again it will require board redesign. There is also possibility to use assembly language (i use it often in M3/F4 designs). Now about freedv: i never hear nor have QSO with freedv so for me it is also useless, but some people may think different and i have respect for that. Andreas, i think that most code will be the same for both types resolution of LCD, the most differences will be at positioning of items and buffer lengths (for example FFT length). Now i should send schematic and pcb for cloning my simple board, where can i do it?

[db4ple]

Hi, let us go step by step: What we have to do is the following:

1. We want to implement a higher resolution spectrum (i.e. larger FFT using more RAM).
2. We want to support a new graphics controller, in addition to the existing ones. In an ideal scenario the "highlevel" interface (the functions called from other files to do the actual user interface are identical) so that the only thing which differs is the implementation of the hardware access (the driver implementation).
3. We want to support an alternative resolution in addition to the existing one. As you pointed out, this requires rearrangement of ui elements or even resizing. Taking advantage of larger space would permit placement of more elements on the screen (scope + waterfall).

First item is relatively simple unless we are running out of RAM. Leaving out FreeDV for the low RAM scenarion would save 64k and that should be plenty for twice as large fft (which increase RAM use by about 12k according to your numbers and also my calculation looking at the data structures). Enlarging the waterfall from 256 to 480 would also increase the RAM usage unless we can follow a more clever approach if the graphics controller does screen buffer shifting. Then we can save a lot of RAM and performance (this is in fact currently the most time consuming ui operation when completely redraw the waterfall for every scrolling step).

Second item: well you did that, we should look at the code to see how feasible a uniform interface is, but I think this is also not too difficult.

Last item is the most complex one since the graphics layout is currently deeply embedded in the code and we need to consolidate that in a better way to have multiple layouts for different resolutions without too much effort.

First step: published your code so that our discussion can be based on facts rather than assumptions.

73 Danilo

[sp9bsl]

Hi Danilo, i will publish code at evening. 73 Slawek

[df8oe]

I will open a new branch and call it lcd-experiental

vy 73 Andreas

[df8oe]

Finished - new branch is available. We can comment out freedv for lcd implementation of course. What happens later: we will see. There are more options than one and minimum two different builds (one for OVI40 and one for mcHF). Here you can find schematics of ui-OVI40 board: https://www.amateurfunk-sulingen.de/data/uploads/ovi40-sdr/uhsdr_ovi40_ui_v17_sheet.pdf

I will create webpages regarding OVI40 at the weekend.

73 Andreas

[db4ple]

Hi, it is currently not possible to comment out FreeDV totally (this was broken) but I will fix that. Meanwhile it is sufficient to disable FreeDV in menu and to comment out the FreeDV setup call in the ushdr_main.c.

[sp9bsl]

I will send changed files to Danilo and Andreas to show you what i did. Github style of coding is new to me and i must learn some, so this will be faster for now. I will start to add code to new branch in next few days after some reading and learning. Thanx for schematics of OVI40 board, now i see big enhancements by using two codecs and F7 still maintaining compatibility with RF board which also needs rework :) 73 Slawek

[df8oe]

@Danilo: Yes - I remember... We will add theese changes to both branches as long as they are equal to have a "good start".

@Slawek: For the first time this is ok of course. But getting familar with git (and GitHub) is appreciated because it can save many, many hours of (merging) work and making community working comfortable...

73 Andreas

[df8oe]

Do you work on Windows or Linux? Of course will help you getting familar with GitHub.

[sp9bsl]

Andreas, you're right i will go this way. I work with Windows and Eclipse. 73 Slawek

[df8oe]

Slawek, I am working with Linux mostly on command line.... So Danilo is the one who knows Windows specific things. But I have read on Yahoo forum that there is a GUI which supports all OS, supports most technics of git and is free - I think you should have a look at it: gitkraken

73 Andreas

[db4ple]

Hi Slawek, before we integrate your changes in whatever way, just try to simply create a new project in GitHub with your content, it does not have to be connected or forked from the UHSDR project.

Then we can start integrating these changes into the lcd-experimental branch step by step. We will help you to get used to Git in general and how we use it in combination with GitHub.

73 Danilo

[sp9bsl]

I think i did it. Here you can find code as is now in my radio shown in first post here. Now i see that some of the comments are in my native language (polish) sorry for that.

The list of files i made changes: basesw\mcHF\Src\spi.c drivers\audio\audio_driver.c drivers\audio\audio_driver.h drivers\audio\freedv_mchf.c drivers\ui\ui_driver.c drivers\ui\ui_driver.h drivers\ui\lcd\ui_lcd_hy28.c drivers\ui\lcd\ui_lcd_hy28.h drivers\ui\lcd\spectrum.c drivers\ui\lcd\spectrum.h drivers\ui\menu\ui_menu.h drivers\ui\menu\ui_menu_internal.c hardware\mchf_board.c hardware\mchf_board.h hardware\mchf_board_config.h

73 Slawek

[db4ple]

Great. Will have a closer look at it today. I will see how we can fast forward your changes to a certain degree.

I would propose to start with integrating the low level graphics driver trying to get the unchanged layout to work on the larger screen (will look strange I guess), this looks like a good candidate. I might even have a ILI9486 based display 3.5" RPI display like yours, not sure though, need to check.

73 Danilo

[sp9bsl]

Yes, this is the right way. I did it like you said. First change the display and low level routines on current layout. There is also need for SPI edge/phase change compared to old LCD, i spent two days on it with white screen before notice what is wrong. Look at my code regarding spi settings also. My LCD is Waveshare clone. Danilo, will you try this or this is my task?

73 Slawek

[s53dz]

Hi Slawek,

I welcome your proposal very much since I think that 2.8" LCD is quite small for my fingers, hi.

I am observing some inter-modulation distortion resulting from the rate of 2.8" HY28B LCD refresh cycle. With only UI board connected it is presenting in the range of 14.014 to 14.017 MHz, for example. Although with a magnitude of only -120 dBm but still.

I suppose a 3.5" LCD project is only out of a baby phase now. But I wonder if you have measured or observed the inter-modulation or distortion of this kind from your 3.5" LCD? I suppose with better resolution also the refresh rate would be higher there.

EDIT: I know this is a HW question, however I am curious what to expect.

TNX 73 Bojan

[sp9bsl]

Hi Bojan, this LCD is only a little bigger, but pixel size is smaller because of resolution (twice more pixels than in 2.8"). Items are a bit smaller than presented on 2.8". I just use a stylus from old HTC phone to point them by touch panel, also when i buy this lcd i get plastic stylus in the package. Regarding interferences: i see something in freq range you asked, it looks like some kind of alias on -115dBm, but i don't see any other signal near except peak at 14.000 with amplitude of -100dBm. I didn't care about that coz i have background from my antenna(W3DZZ) at level of S7.

73 Slawek

[sp9bsl]

Should i start integrating low level routines or wait? I don't want to go in anyone's scope of authority.

73 Slawek

[df8oe]

Hi Slawek,

we do not have any authority - we only have to coordinate all works so that it gets best performance and no loss because of two persons are working at the same time on similar parts of the code...

So let us discuss how we will do it.: I have created new branch lcd-experimental You should clone and use this branch for implementation. @Danilo: do you have begun with work / how will we divide it? I will not distrub integration.

But I have got 3.5" LCD and will fit it to my OVI40-UI (SPI lines are already on the bus - just define one more for CS_LCD and everything can start up ;)

73 Andreas

[db4ple]

Hello all, if this is okay with all of you, I would like to propose how to make progress. This would require me to prepare a few things in the code and explain you, Slawek, how we organize this. I can unfortunately start this no earlier than tonight (i.e. not now). Appreciate you waiting. Basic idea is to use the feature branch lcd-experimental as Andreas suggested.

73 Danilo

[sp9bsl]

OK, no problem i will wait.

73 Slawek

[db4ple]

First step

I created in my (db4ple) GitHub Repo a new branch (lcd-ili9486) which "starts" at release 2.2.0 and has your changes (most of them) as next commit. This gives us a nice overview of what you did change in your effort:

https://github.com/db4ple/mchf-github/commit/daba61987dd11b7188d7a162f2295c06cfbbc03b

The setup

Now fastforward to the current activities:

You setup your git/github environment so that you can publish your changes to the DF8OE repo. Please use these instructions: https://github.com/db4ple/mchf-github/blob/active-devel/CONTRIBUTING.md I made small changes to the text there after looking at them (will be soon merged into the "official" repository). In general the CONTRIBUTING.md from DF8OE should be looked at...

Instead of using 'git checkout active-devel' you should use 'git checkout lcd-experimental'. In git rebase, do not replace active-devel with lcd-experimental When you do the pull request, use lcd-experimental as target branch.

You can try that workflow with a small commit to see how this works before starting the real work.

The real stuff

Looking at the changes, I would propose to use 3 flags

For step 1:

USE_GFX_ILI9486 to identify the places, where you make changes do to the new driver which are independent from the resolution (these are the changes we do in first step, only these please).

For step 2/3: USE_DISP_480_320 to identify places where the screen resolution related changes are addressed.

USE_FFT_LARGE to identify places where the FFT size needs to be changed. Maybe we just use the FFT SIZE but I don't know yet, we'll see.

Please keep in mind: This is a proposal from my side, if you have different ideas, just tell.

The goal

We integrate your change so that we can (by means of conditional compilation) build the "normal" mcHF firmware and the other one with ili9486 480x320 display (if the defines are set accordingly).

[sp9bsl]

Thanks Danilo, it is OK i think. Thanks for commiting this to v2.2.0, now all can clearly see what has been done. One question: by saying "3 flags" you mean #ifdef in those places right? I tried your instructions link, but it is not working.

73 Slawek

[db4ple]

I fixed the link. a) you can define the new flags in uhsdrboard.h (you will see, there other USE... already there). b) and yes, then we use #ifdef USE_....

[DG9BFC]

hmmm.. if we swap to the mcu with abit more ram we maybe could use the bigger display AND let freedv inside the code??? ... is the adaptor pcb for that bigger display available??? i would like to have that bigger screen resolution (and spectrum and waterfall on screen)

[db4ple]

Hi Slawek, just to be clear: Go ahead and add the driver to the original code in the lcd-experimental branch once your github setup is working. If you have trouble with git/github let us know. 73 Danilo

[db4ple]

@DG9BFC: I don't think there is a general problem to run all of this together once the RAM requirements are met. So for larger RAM devices FreeDV should work as before even with the new display. Of course, a larger FFT is also consuming more computational power and more data needs to be sent to the screen so the max update screen rate may not be as high as before.

[sp9bsl]

Hi Danilo, sorry for delay, i have some weekend activities, and also urgent task for my employer. I will start today at evening. 73 Slawek

[DG9BFC]

at slawek ... do you have any more of the adaptor boards (maybe with display so plug and pray?!?)

best would be if the fw would detect the needed settings at boot and so you can start with small or big display (shut off mchf ... plug in bigger display and restart) ... but i am guessing that would not work (or would boost up firmware size tooo much) .... i really like that new view (as seen in the video) and the better screen resolution is superb (especially if you ad more digimodes later that better resolution is fine i guess)

i would like to have such a display and try out the "new lcd experimental fw"

really looks great

maybe for original mchf fw some of your clever display driving tricks could be used to speed up the display (and also change layout to have wf and scope)?!?

greetz sigi

[db4ple]

@sp9bsl: No worries, take your time. Just wanted to make sure, you are not stuck. @DG9BFC: While the dynamic selection of the screen layout seems to be nice, this is a much larger piece of work due to the existing architecture. And if this is done wrong, it will become a software maintenance nightmare. So I suggest to static to the static compilation. The list of reasons for not doing it include (don't get me wrong, all of this is doable):

• Dynamic Sizing / Memory allocation for FFT without using extra memory on low memory machines. Low memory machines may not be able to run the large display although they detect it, if they want to use FreeDV...
• The layout (x and y coordinates of UI elements) are current "compiled in", making the dynamically switchable needs some attention to the details too.
  • Effort spent on the to previous items makes sense if users would really switch displays often. Which they don't typically I would assume.

[sp9bsl]

DG9BFC: sorry i haven't any pcb nor lcds now. I did it in home - it's prototype. Danilo explained everything about lcd autodetection, i must admit that this LCD has one way SPI communication, there is no possibility to detect it, only touch panel chip has back communication.

73 Slawek

[K2AAE]

I was looking at another issue related to this issue:

1. Move the Touch Screen Code to separate file, currently there is no means for Capacitance I²C touch screens.

2. Dynamic build system with users checking boxes to get the firmware for their hardware, did that for ESP8266.

3. The BIG Picture plan on LCD support moving forward. While the F7 can support external memory the H7 goes further with more graphics hardware support both of which isn't supported by F4xx.

4. Virtual screen, data sent to external display.

As it stands I found some 3.5" displays with either Resistive $2 or Capacitance Touch Screens $5, ILI9488. 320X480 no daughterboard, also some 3.5 320X240 SSD2119 with Touch screens, no daughterboard and 320X240 3.2, ILI9341, Resistive $2 or Capacitance Touch Screens $5, no daughterboard. To make a daughterboard with the pins to mate the UI for these is $3. They all have one thing in common: no display API, everyone of these controllers has to be beat into place with time and after looking at the existing code I figured we'd need to talk and you already are.

At any rate I'm still waiting on the first 2.8" display I ordered a month ago from hotmcu.com, it took 8 days to ship and he must of put it on a very slow boat. The bare boards I ordered from Chris arrived but the stuffed boards are still traveling so I basically have no hardware to test with yet, I had to take a break from rebuilding the parts list.

I did start on a shield for the Nucleo H746 that will mate with the RF board, have all the switches and controls along with Si5351 and WM8994, something to do while I wait on the slow boats. Kevin K2AAE

[db4ple]

Hi Kevin

1. Yes, once it gets to messy we should move it out. I think main motivation here was that both display and touch may share the SPI if both are connected using the SPI bus and thus have kind of a tight link. Due to maximum performance based on optimization and inlining the code was kept in a single file. By using gcc's LTO (which we do since quite a while) this may no longer be true and we can separate code easily without impacting performance.

2. Make an independent issue for that and suggest how we could do this, I am very much in favor of that idea.

3. and 4. I am not exactly sure what you mean.

Honestly, I don't think we should try to support every controller out there. However, moving to a different resolution is a somewhat logical and necessary step. Yet we have to keep in mind the intention is to keep the current mcHF HW in the loop and not to abandon them to quickly.
All of that puts some constraints on us. The current software architecture has not been made with hardware flexibility in mind, so it will be some kind of longer process of evolution to get there. Having 2. in place (or some equivalent of this) gives us some freedom to work on the evolution I would say, since it will permit us to provide more configurations without need to build all of them ahead of time and we can also track which configurations are being used and which not.

[df8oe]

I have already thought about a webinterface and the possibility to build special configurations on my server. I would buffer each build and if same is selected again it would caught from cache. So we can possibly provide more flexibility (of course I cannot archivate huge amounts of different builds on my server due to storage limitations). As Danilo already wrote: our intention is not to spread into every direction which is possible in theory (and reality) - we want to provide a support of a selected hardware. If some else wants to support special hardware configurations he can create his own branch (or, if interest is big enough, we will think about supporting it inside UHSDR main repository). But it is not planned and will not be done to support "special" hardware configurations which will not present in "nature" in a minimum amount.

vy 73 Andreas

[sp9bsl]

Andreas: this lcd (3.5" from raspberry i use) has 2 shift registers which convert SPI to parallel interface. The back spi node is only for touch panel IC.

73 Slawek

[df8oe]

Yes - I do have the same one. It has four 16pin COIC16 on back. Maybe the LCD is available in parallel wiring, too. But all this is subject of the future. Interesting is that the form factor of the LCD by itself has exactly the same form factor of the 3.2" we use at OVI40 if you include the PCB where it is mounted... So it is mechanically "drop in compatible" you only have to rewire it...

[db4ple]

Hi, my 3.5 RPi also uses a shift register. This is very interesting since the ILI controller can do SPI just fine. BTW, I just broke mine in an attempt to figure out which controller chip is on, I killed the flexcable beyond repair. I ordered a new one.

For using it with the mcHF and a newly developed adapter: I think this display could be right since it has the flexcable connected using a proper connector. Here an adapterboard could be more easily be developed for.

http://www.ebay.de/itm/Waveshare-3-5-inch-320x480-Touchscreen-TFT-LCD-Display-for-Raspberry-Pi-WS40003-/281842700934?hash=item419f225286:g:I7wAAOSwviBZxOwg

73 Danilo

[DG9BFC]

hello danilo ... would it be possible to add those raspi headers direct to the i40 ui board?

just in the layout with solder spots (so rewiring would be with some soldering work to be done)

or best with connecting the header in the layout in parallel with existing one?!? (a massive rework on the layout to be done ... so not that good)

my dream would be that you can plug in different lcd screen (take what is available in evilbay) and fire up the right fw (taken from andreas server ...) ... and have a working ui

i do not know if we could add some different screen headers in the layout (and rewiring has to be done from the user but i think it is not possible to have all different lcd screens (with its different header locations) on the ui board ... so ... to be flexible (also for later development) we have to have a display header ... and one (or a few) adaptor board(s) .... guessing that is the best way to have:

different screen sizes and resolutions available

and if that screen where i40 sdr is built and planned with is not available anymore in a few years (we have a good example with the 2.8 inch display) ... just plug in a different one

[df8oe]

Hi Sigi,

design of ui PCB is finished and will not be touched now. You can add new LCD (the original Raspi one) by adding 8 wires. It has exact same form factor as 3.2" LCD. Maybe late there will be a "special LCD" which carries the original display but does have a self designed PCB which adapts parallel mode using exactly the same connection as 3.2" has. But all this is future stuff. First we want to get a working device using the parts where PCB is designed for - rest is done in "next steps" ;)

[DG9BFC]

just thought about future (and what to do when a display becomes unavailable?) ... I DID NOT WANT TO CHANGE LAYOUT NOW FOR SURE ... if that was understood that way ... sorry if adding the new display takes only a few wirings to be done ... ok on that ... thats fine (and not more work as touch screen mod on mchf)

[df8oe]

The choosen 34pin header for LCD is as flexible as it can be. It contains all voltages and signals for parallel and SPI driven LCDs.

[sp9bsl]

Danilo, i have problem with push. What exactly command should i use? When i do git push origin lcd-experimental i get Everything up-to-date, when i try git push main lcd-experimental i get permission denied.

73 Slawek

[K2AAE]

Nice reading on this problem: https://goo.gl/k5iwdf I think it would be a good idea to set some expectations for going forward:

1. Current MCU can support? 320X240/480X320 with GRAM on the LCD
2. Which controllers to support: ILI932x + ??? ILI948x?? Build time selection?
3. Develop a shield for this type of display: https://goo.gl/khwoLj - SPI for LCD+SD Card+Flash Font memory+Touch+I²C for Touch on one flex cable with ZIP style connector, or this: https://goo.gl/EiVUbU at 5AMP per pin it could handle the display, I'm waiting on Molex, they left "number of insertions" out of the specs. Of course use a 74LVC139D to free up some pins. Add connectors that can be soldered for the OVI40 and mcHF but I haven't seen the OVI40 layout so I don't know if this is possible. With this those that had mcHF could upgrade to Flash Fonts and larger display "cheaply", could also make a 2.8" version. For this application (mcHF footprint) and the small displays SPI is very usable from what I can tell.

Since the current design can only 'fit' a 3.5" display (I used the front panel in CAD to find out what would fit, 4.3" height wise with moving all the controls to the left) and there is 320X240 3.5" display as well as 320X480 3.5" displays that looks to be the limit for the mcHF style. To move to the next generation of MCU with built in LCD support is another project since there isn't the room on the mcHF for a bigger display and the MCU is a bottleneck.

NPX has a M4 part that can handle 1024X768 $20 and new layout. About the time you get done you discover the LCD vendors are offering HD, 2K and 4K MIPI-DSI glass.

I feel the small and simple is the path to take on this, I don't want a Flex ten zillion like radio.. Using IceStorm opens some interesting projects.

[db4ple]

@Slawek: All of this is normal:

• 'main' is Andreas GitHub repository, you can read from it but not write to it.
• 'origin' is your GitHub repository, you can read from and write to it.
• Since you already pushed your local repository's to your GitHub repository (aka 'origin') already, a second push will tell you this.

What you have to do is:

• go to your GitHub repository ( https://github.com/sp9bsl/UHSDR )
• press New Pull Request
• Select the lcd-experiemental branch in the df8oe repository (this is the left side of the picture below) instead of the default "active-devel". Then you create the pull request.

This should be it...,

[db4ple]

@Airheadbit : I think we are aligned here. While there is some additional interest in getting a 5 inch 800x480 display connected, this is not an update option for current users with a "normal" mcHF UI like experience as this cleary requires a new UI layout or a separated display.

[sp9bsl]

Some mechanical drawings (3D view) how the 3.5" LCD fits in my case.

73 Slawek my mcHF inside.pdf my mcHF outside.pdf