Trying to capture 2x16 LCD signal...

I have been trying to capture the digital signals driving the 2x16 LCD on my fully functional QMX transceiver. ?

?

I am using an application called Scopy and the ADALM2000 learning module hardware from Analog Devices. ?I don't understand the captured data.? I am hoping someone on this forum is familiar with this protocol and can provide some insight.

?

My two main questions I have are:

1) Should the Enable line go high when the microprocessor of the radio is writing to the screen?? From what I have captured so far these does not seem to be the case.? However the reference material I read on line about typical 2x16 LCD screens indicates the Enable signal means write to the screen.

?

2) Should the Register Select (RS) line go high when the microprocessor is writing an ASCII character and low when it is writing a screen command?? My data collection shows that there seems to be far more RS pulses than Enable pulses, which I don't understand.

?

Am am attaching a screen shot of the data collected when I power up the QMX receiver with the factory reset splash screen.? I have the Enable pin tied to input bit 0, the RS pin tied to input bit 1 and LCD data bit 0 through 7 tied to input pins 2-9 respectively.

?

Any info on this would be greatly appreciated.

?

Thanks in advance

?

Mike (KC2EHR)

Scopy-Logic Analyzer-2025-04-15-20-14-26.pdf

#143255

?

16x2 LCD are quite similar, here is one of the specs

#143273

Hi Mike?

I'm not sure I know the answer to your question from memory but the HD44780 datasheet will tell you all you need to know, these things are 40+ years old now and remain the same.?

But my question is why why why! Aren't you making life very hard for yourself... I will soon add CAT commands to return the LCD contents, if you are trying to replicate the display elsewhere this could be a lot easier way to do it, than trying to reverse engineer the HD44780 and create a virtual shadow HD44780...

73 Hans G0UPL

Show quoted text

On Wed, Apr 16, 2025, 03:37 Michael LaBlanc via <mlablan1=[email protected]> wrote:

I have been trying to capture the digital signals driving the 2x16 LCD on my fully functional QMX transceiver. ?

?

I am using an application called Scopy and the ADALM2000 learning module hardware from Analog Devices.? I don't understand the captured data.? I am hoping someone on this forum is familiar with this protocol and can provide some insight.

?

My two main questions I have are:

1) Should the Enable line go high when the microprocessor of the radio is writing to the screen?? From what I have captured so far these does not seem to be the case.? However the reference material I read on line about typical 2x16 LCD screens indicates the Enable signal means write to the screen.

?

2) Should the Register Select (RS) line go high when the microprocessor is writing an ASCII character and low when it is writing a screen command?? My data collection shows that there seems to be far more RS pulses than Enable pulses, which I don't understand.

?

Am am attaching a screen shot of the data collected when I power up the QMX receiver with the factory reset splash screen.? I have the Enable pin tied to input bit 0, the RS pin tied to input bit 1 and LCD data bit 0 through 7 tied to input pins 2-9 respectively.

?

Any info on this would be greatly appreciated.

?

Thanks in advance

?

Mike (KC2EHR)

#143303

Hi Hans,

?

Thank you for responding to this email.??

?

Yes, I am attempting to create a virtual 1602 display to allow for a totally "headless" operation of my QMX transceiver.?

?

I do have some level of technical curiosity to see if I can accomplish this, but I am also a pragmatic person that will take any solid solution to fill the need.? However, I feel like only a very small percentage of QMX/QMX+ users will want to take advantage of this potential new feature.? Therefore, given all the other more popular features that might be considered I am very hesitant to have this idea thrown into the mix.

?

Having said that, most of what is needed seems to already be in place between the serial console interface and the existing CAT commands.? What I think is essentially missing are the ability to run the real time SWR antenna tuning utility (a GREAT feature on the QMX), the real time SWR feedback during full power transmit, real time feedback of power output and some way to tell if the radio is in the shutdown state from detecting a high SWR.

?

I really hate myself for asking this question, but when you say "I will soon add CAT commands to return the LCD contents", do you have any rough idea of when this might be fit into a very tight schedule?

?

As always, thank you for your outstanding engagement with your user base.

?

Kind regards,

Mike (KC2EHR)

?

#143306

Hi Mike

Nothing wrong with trying to reverse engineer the LCD for the challenge or some practical purpose. I think it would end up quite a difficult way to do things because of the custom character writing etc., if you wanted to replicate everything.

It's almost trivially easy for me to add a CAT command called say "LC;" which returns a 32 character string containing the whole LCD contents. Any custom characters need to be replaced by a space. Custom parts of the display need to be derived in other ways, it seems silly to have some kind of special extra definitions in the LC return string to define the bit maps of custom characters. The three characters at the top right are used for Power + SWR on transmit, and S-meter + AGC (optionally) on receive. It's equally easy to have four CAT commands that return power, SWR, S-meter and AGC values. An S-meter command exists alewady if I recall. Another CAT command could return the transmit status (1, 2 dots or the solid underline). Battery voltage too. What VFO is active is already available, the RTC can be read, and decoded CW, all available with existing CAT commands. With all this one then has all the necessary information to completely replicate what's on the display. And with a few other commands to virtually press buttons and rotary encoders you have one other way of controlling QMX.

I don't mind adding these in the next firmware version because it's the work of minutes not even hours. And nobody should mind that. And it moves things in a direction I think is the correct one.?

In my opinion the desired end state is that there's conceptually a headless SDR inside QMX. Various views into QMX can then control QMX, even at the same time:

Conventionally the LCD buttons and rotary encoders on the real device, which is all 95% of people will care about.
Terminal session via PuTTY etc on the current USB Virtual COM serial port, future second USB Virtual COM serial port, USART ports (the PTT output jack, and the QMX+ "AUX" jack can both optionally be configured this way in future).
CAT commands arriving on any of the above mentioned serial ports.
BASIC scripts running in their VM.

Of course some actions on the real SDR require mutually exclusive access. You already see this, for example if you run certain things in a terminal session it locks the main LCD/Controls and vice versa.?

I'd like to see complete remote capability developed too. Run your QMX over the internet. I think control is fairly straightforward using one of these WiFi Serial ESP32 boards; but I didn't manage to figure out yet how to stream audio to and from QMX to a remote internet browser.

For everyone else reading this and worrying about things getting complex and wishing they'd remain simple; don't worry. Just use QMX with it's LCD and buttons and don't worry about anything else you don't want to use. It remains totally invisible to you. But provides a lot of fun for certain people who want to explore different ways to use QMX.?

73 Hans G0UPL

Show quoted text

On Wed, Apr 16, 2025, 23:02 Michael LaBlanc via <mlablan1=[email protected]> wrote:

Hi Hans,

?

Thank you for responding to this email.??

?

Yes, I am attempting to create a virtual 1602 display to allow for a totally "headless" operation of my QMX transceiver.?

?

I do have some level of technical curiosity to see if I can accomplish this, but I am also a pragmatic person that will take any solid solution to fill the need.? However, I feel like only a very small percentage of QMX/QMX+ users will want to take advantage of this potential new feature.? Therefore, given all the other more popular features that might be considered I am very hesitant to have this idea thrown into the mix.

?

Having said that, most of what is needed seems to already be in place between the serial console interface and the existing CAT commands.? What I think is essentially missing are the ability to run the real time SWR antenna tuning utility (a GREAT feature on the QMX), the real time SWR feedback during full power transmit, real time feedback of power output and some way to tell if the radio is in the shutdown state from detecting a high SWR.

?

I really hate myself for asking this question, but when you say "I will soon add CAT commands to return the LCD contents", do you have any rough idea of when this might be fit into a very tight schedule?

?

As always, thank you for your outstanding engagement with your user base.

?

Kind regards,

Mike (KC2EHR)

?

?

?

#143308

Is there a list of CAT commands? used by QMX+??

Sorry if they had been posted on the reflector before I joined. I cannot search the website of the reflector because the browser on my phone returns an error message every time.

73!

de Bekir TA2RX

17 Nis 2025 Per 00:04 tarihinde Hans Summers via <hans.summers=[email protected]> ?unu yazd?:

Show quoted text

Hi Mike

Nothing wrong with trying to reverse engineer the LCD for the challenge or some practical purpose. I think it would end up quite a difficult way to do things because of the custom character writing etc., if you wanted to replicate everything.

It's almost trivially easy for me to add a CAT command called say "LC;" which returns a 32 character string containing the whole LCD contents. Any custom characters need to be replaced by a space. Custom parts of the display need to be derived in other ways, it seems silly to have some kind of special extra definitions in the LC return string to define the bit maps of custom characters. The three characters at the top right are used for Power + SWR on transmit, and S-meter + AGC (optionally) on receive. It's equally easy to have four CAT commands that return power, SWR, S-meter and AGC values. An S-meter command exists alewady if I recall. Another CAT command could return the transmit status (1, 2 dots or the solid underline). Battery voltage too. What VFO is active is already available, the RTC can be read, and decoded CW, all available with existing CAT commands. With all this one then has all the necessary information to completely replicate what's on the display. And with a few other commands to virtually press buttons and rotary encoders you have one other way of controlling QMX.

I don't mind adding these in the next firmware version because it's the work of minutes not even hours. And nobody should mind that. And it moves things in a direction I think is the correct one.?

In my opinion the desired end state is that there's conceptually a headless SDR inside QMX. Various views into QMX can then control QMX, even at the same time:
Conventionally the LCD buttons and rotary encoders on the real device, which is all 95% of people will care about.
Terminal session via PuTTY etc on the current USB Virtual COM serial port, future second USB Virtual COM serial port, USART ports (the PTT output jack, and the QMX+ "AUX" jack can both optionally be configured this way in future).
CAT commands arriving on any of the above mentioned serial ports.
BASIC scripts running in their VM.
Of course some actions on the real SDR require mutually exclusive access. You already see this, for example if you run certain things in a terminal session it locks the main LCD/Controls and vice versa.?

I'd like to see complete remote capability developed too. Run your QMX over the internet. I think control is fairly straightforward using one of these WiFi Serial ESP32 boards; but I didn't manage to figure out yet how to stream audio to and from QMX to a remote internet browser.

For everyone else reading this and worrying about things getting complex and wishing they'd remain simple; don't worry. Just use QMX with it's LCD and buttons and don't worry about anything else you don't want to use. It remains totally invisible to you. But provides a lot of fun for certain people who want to explore different ways to use QMX.?

73 Hans G0UPL

On Wed, Apr 16, 2025, 23:02 Michael LaBlanc via <mlablan1=[email protected]> wrote:
Hi Hans,

?

Thank you for responding to this email.??

?

Yes, I am attempting to create a virtual 1602 display to allow for a totally "headless" operation of my QMX transceiver.?

?

I do have some level of technical curiosity to see if I can accomplish this, but I am also a pragmatic person that will take any solid solution to fill the need.? However, I feel like only a very small percentage of QMX/QMX+ users will want to take advantage of this potential new feature.? Therefore, given all the other more popular features that might be considered I am very hesitant to have this idea thrown into the mix.

?

Having said that, most of what is needed seems to already be in place between the serial console interface and the existing CAT commands.? What I think is essentially missing are the ability to run the real time SWR antenna tuning utility (a GREAT feature on the QMX), the real time SWR feedback during full power transmit, real time feedback of power output and some way to tell if the radio is in the shutdown state from detecting a high SWR.

?

I really hate myself for asking this question, but when you say "I will soon add CAT commands to return the LCD contents", do you have any rough idea of when this might be fit into a very tight schedule?

?

As always, thank you for your outstanding engagement with your user base.

?

Kind regards,

Mike (KC2EHR)

?

?

?

#143311

Hans,

I like the idea of your LC CAT command.  However  instead of replacing custom characters with spaces, I think that it would be more convenient if you could replace them with UTF-8 encoded characters that approximate their appearance.  This would make it really simple to replicate the appearance of the screen without having to invoke additional CAT commands.  

For example, see Unicode 2580 to 259F, which become UTF-8 \xE2\x96\x80 to \xE2\x96\x9F for block elements that could be used to build up the bar graphs.  I've also seen some creative use of Unicode Braille characters 2800 to 28FF to do text based graphics.

Of course I also like the idea of commands to get Power, SWR, etc.

Peter LaRue
AI7YN

#143314

Back to the original question if you are still interested,? in my opinion 1mhz sample rate is not fast enough to capture the E strobes.?

#143330

Hello Bekir

?

Is there a list of CAT commands? used by QMX+??

Sorry if they had been posted on the reflector before I joined. I cannot search the website of the reflector because the browser on my phone returns an error message every time.

The CAT commands are documented in the operating manual, see pages 102 - 106.

73 Hans G0UPL

#143331

Thank you Hans. I must have forgotton that.

73!

de Bekir TA2RX

17 Nis 2025 Per 10:21 tarihinde Hans Summers via <hans.summers=[email protected]> ?unu yazd?:

Show quoted text

Hello Bekir
?
Is there a list of CAT commands? used by QMX+??

Sorry if they had been posted on the reflector before I joined. I cannot search the website of the reflector because the browser on my phone returns an error message every time.

The CAT commands are documented in the operating manual, see pages 102 - 106.

73 Hans G0UPL

#143375

Hi Hans - This is truly exciting news that the LC CAT command can be targeted for the next firmware release. ?I absolutely plan to make good use of this new feature when it becomes available. ?My only follow on question is if one more CAT command could be considered to reduce power output to 1/2 or 1/4 to recreate the SWR tuning utility built into the QMX firmware now? ?Thanks again for your special efforts to accommodate some edge use cases.?

?

Hello Wei - Thank you for your suggestion on digging into the 16x2 LCD data sheet. ?I have downloaded that document and I ? ? ?am studying it for answers to my questions.

?

Hey Ron - Thanks for your insight on having the sample rate set too low to capture the Enable strobes. ?I increased the sample rate on the SCOPY app I am using and I was able to capture what looks like a good data stream. ?I am now working on writing a program to interpret this data. ?Although I look forward to taking full advantage of the upgraded features in the coming firmware update, I am intrigued by the technical challenge and will continue to pursue my original goal a bit longer to see how far I can get. ?I may come back to this thread and ask some follow on questions. ?Thanks again for sharing your insight. ?

#143572

Hi Mike

?

Hi Hans - This is truly exciting news that the LC CAT command can be targeted for the next firmware release.? I absolutely plan to make good use of this new feature when it becomes available.? My only follow on question is if one more CAT command could be considered to reduce power output to 1/2 or 1/4 to recreate the SWR tuning utility built into the QMX firmware now?? Thanks again for your special efforts to accommodate some edge use cases.?

It's already on my list, to provide?a way to reduce QMX output power. And in the end it the aim is that EVERYTHING that you can set on the QMX itself, or in the terminal, should be accessible also via CAT commands. The reduction in power is easy to do but, I wanted to spend some time testing if everything is OK since effectively the voltage drop goes across the Q507 power amplitude modulator transistor, which dissipates all the power. I wanted to do careful testing to make sure it doesn't mind. I believe it should be OK, after all in two-tone testing and SSB etc., this is already what happens; but I didn't quite reach the "convinced" threshold.

73 Hans G0UPL

开云体育

Trying to capture 2x16 LCD signal...