David,
? ? I rolled my G90 back from 1.8 to 1.79b3 out of sheer frustration.? 1.79b3 does a mediocre job communicating the amount of SWR to display on FLRIG, but did work.? V1.8 pegged SWR at my Xubuntu install regardless of the actual SWR. Xiegu may say they emulate the Icom CI-V, but the IC-7100's I used to have worked perfectly with FLRIG.?
? ?Between lack of firmware support and little or no factory service I have replaced my G90 with a Yaesu FT-450D and relegated the G90 to POTA service.?
|
I recently reinstalled Xubuntu onto a laptop of mine as the previous Ubuntu installation was getting clunky and bloated. I just tried to hook up my G90 to flrig to do remote control and in prep for digital modes. Before this I updated the head unit to firmware version 1.80 (previously head and body were both at 1.79b3). I'm using the DE-19 card as the interface. Now when trying to connect to it flrig never initializes the radio, it just never sees it. Here's a list of things I've tried:
*Changed settings, including stop bit settings, echo, RTS/DTS voltage. Baud has always been set to 19200.
*Added dialout group to my user as the tty device is assigned to that group. And yes, rebooted after to ensure it was in my profile.
*Removed brltty to avoid it subsuming the UART device when plugged in.
*Tried the old Icom 7000/7100 setting, no joy.
All the software I'm running is from PPA, no hand compiling.
I'm fearing that I may have to roll the firmware back on the head to 1.79b3 but this seems like a drastic step. Anyone have any thoughts?
|
Running FSQ Now on 30 Meters
Greetings,
Active on 10.144+1500hz with FSQ. Spotting heard stations to pskreporter.
73 de Ted, AB8FJ
EM79
|
Re: flrig 2.0.05.32 development version posted
You're welcome. If you still see issues be sure to bring them up. Dave does his best to weed them out.
toggle quoted message
Show quoted text
On Apr 5, 2024, at 08:19, Philip Rose, GM3ZZA via < gm3zza@...> wrote:
Hi Cliff,
I am running .32. And yes I did have the poll bandwidth button
unchecked. I've checked it now. I still saw some anomalies, but it
seems a lot more robust.
Thanks 73 Phil GM3ZZA
On 04/04/2024 17:52, Cliff, AE5ZA
wrote:
Phil,
You post says 2.0.5.32 in the subject. You are
running that version, correct? Older versions had issues with
reading BW.
Phil,
Check that you have polling for BW on in
flrig. It works fine here. In CW mode can change
filters and BW manually on the 7300 and flrig
follows.?
Same test in USB-D and all is good as
well.
On Apr 4, 2024, at 10:54, Philip
Rose, GM3ZZA via
< gm3zza@...>
wrote:
It's
the filter width display in flrig that doesn't
agree with the IC-7300. Then I think somehow
what flrig thinks is the width gets written
back to the IC-7300.?
I
did much testing this afternoon and never did
flrig change the width if I changed it on the
IC-7300 by changing the filter number.
|
Re: flrig 2.0.05.32 development version posted
Hi Cliff,
I am running .32. And yes I did have the poll bandwidth button
unchecked. I've checked it now. I still saw some anomalies, but it
seems a lot more robust.
Thanks
73 Phil GM3ZZA
On 04/04/2024 17:52, Cliff, AE5ZA
wrote:
toggle quoted message
Show quoted text
Phil,
You post says 2.0.5.32 in the subject. You are
running that version, correct? Older versions had issues with
reading BW.
Phil,
Check that you have polling for BW on in
flrig. It works fine here. In CW mode can change
filters and BW manually on the 7300 and flrig
follows.?
Same test in USB-D and all is good as
well.
On Apr 4, 2024, at 10:54, Philip
Rose, GM3ZZA via
< gm3zza@...>
wrote:
It's
the filter width display in flrig that doesn't
agree with the IC-7300. Then I think somehow
what flrig thinks is the width gets written
back to the IC-7300.?
I
did much testing this afternoon and never did
flrig change the width if I changed it on the
IC-7300 by changing the filter number.
|
flrig 2.0.05.34 development version
posted at
Most recent changes; full list in readme.txt:
Author: dave-w1hkj <w1hkj@...>
XML label access
* change all C style label string arrays to C++ vectors
make both the array and current label value accessible
via XML cmds
* XML cmd additions
. get_agc
. incr_agc
. both return post command agc value
Author: dave-w1hkj <w1hkj@...>
xml-tcp-serial
* fix for grungy tcp-serial drivers.
Author: Black Michael <mdblack98@...>
Win32 com port search
* improved search for active serial ports.
Author: Black Michael <mdblack98@...>
Win32 zusec overflow
* 32-bit Windows version is overflowing zusec()
Causing timeouts when timeout is set to 50ms.
NOTE: XML label access effects all 110 support transceivers. Please report any problems to this forum.
73, David, W1HKJ
|
Re: ANNOUNCEMENT: HamPi 4.0a1 32-bit (March 2024) "Raspberry Pi 5 Edition" Released
#rpi5
This release also supports the Pi4, Pi3, 400, Zero W2, etc.
What about the Pi4, Dave? I think it and the Inovato Quadra (or a cheap laptop, in some cases) are still better suited than the Pi5 for most ham radio work and I have no desired to "upgrade" to the Raspi power hog (Pi5).
Thanks for your work to support ham radio and 73,
Cal -- AD8Q
--
-- Dave,?? ? ? ? ? ? ? ? ? ? ? ?Technical Specialist,??--
--?? Lifetime Member:?////?--
--??--
|
Re: flrig 2.0.05.32 development version posted
Phil,
You post says 2.0.5.32 in the subject. You are running that version, correct? Older versions had issues with reading BW.
toggle quoted message
Show quoted text
Phil,
Check that you have polling for BW on in flrig. It works fine here. In CW mode can change filters and BW manually on the 7300 and flrig follows.?
Same test in USB-D and all is good as well.
On Apr 4, 2024, at 10:54, Philip Rose, GM3ZZA via < gm3zza@...> wrote:
It's the filter width display in flrig that doesn't agree with the IC-7300. Then I think somehow what flrig thinks is the width gets written back to the IC-7300.?
I did much testing this afternoon and never did flrig change the width if I changed it on the IC-7300 by changing the filter number.
|
Re: ANNOUNCEMENT: HamPi 4.0a1 32-bit (March 2024) "Raspberry Pi 5 Edition" Released
#rpi5
What about the Pi4, Dave? I think it and the Inovato Quadra (or a cheap laptop, in some cases) are still better suited than the Pi5 for most ham radio work and I have no desired to "upgrade" to the Raspi power hog (Pi5).
Thanks for your work to support ham radio and 73,
Cal -- AD8Q
|
Re: flrig 2.0.05.32 development version posted
Phil,
Check that you have polling for BW on in flrig. It works fine here. In CW mode can change filters and BW manually on the 7300 and flrig follows.?
Same test in USB-D and all is good as well.
toggle quoted message
Show quoted text
On Apr 4, 2024, at 10:54, Philip Rose, GM3ZZA via < gm3zza@...> wrote:
It's the filter width display in flrig that doesn't agree with the IC-7300. Then I think somehow what flrig thinks is the width gets written back to the IC-7300.?
I did much testing this afternoon and never did flrig change the width if I changed it on the IC-7300 by changing the filter number.
|
Re: flrig 2.0.05.32 development version posted
It's the filter width display in flrig that doesn't agree with the IC-7300. Then I think somehow what flrig thinks is the width gets written back to the IC-7300.?
I did much testing this afternoon and never did flrig change the width if I changed it on the IC-7300 by changing the filter number.
Phil.
toggle quoted message
Show quoted text
Phil,
I see no issue here on my 7300 with the latest Alpha of flrig.
The filters remember their last setting per mode so set your filter width to what you want and then if you don't change it, it should come back the next time you use that filter in that mode. It does here anyway.
On Apr 4, 2024, at 09:37, Philip Rose, GM3ZZA via < gm3zza@...> wrote:
What is the current state of filter handling for the IC-7300?
I was testing a different feature for CW on IC-7300 and I noticed that the filter width on the rig for filter3 had been changed from its default.
After some investigation I see that flrig does not change the filter width when I switch the filter on the IC-7300. If I switch mode on the IC-7300 then the current filter number and bandwidth is displayed correctly in flrig. It does not seem to restricted
to CW, I see the same happening with other modes.
It works fine with my IC-705.
73 Phil
|
Re: flrig 2.0.05.32 development version posted
In case you don't know it, FM is different from the other modes in that it has fixed BW-Filter combinations. Filter #1 - 15000, #2 - 10000, #3 - 7000. If you try to change the FM filter BW it will only show the three widths and will change the filter number to which ever filter will give you that BW.
toggle quoted message
Show quoted text
Phil,
I see no issue here on my 7300 with the latest Alpha of flrig.
The filters remember their last setting per mode so set your filter width to what you want and then if you don't change it, it should come back the next time you use that filter in that mode. It does here anyway.
On Apr 4, 2024, at 09:37, Philip Rose, GM3ZZA via < gm3zza@...> wrote:
What is the current state of filter handling for the IC-7300?
I was testing a different feature for CW on IC-7300 and I noticed that the filter width on the rig for filter3 had been changed from its default.
After some investigation I see that flrig does not change the filter width when I switch the filter on the IC-7300. If I switch mode on the IC-7300 then the current filter number and bandwidth is displayed correctly in flrig. It does not seem to restricted to CW, I see the same happening with other modes.
It works fine with my IC-705.
73 Phil
|
Re: flrig 2.0.05.32 development version posted
Phil,
I see no issue here on my 7300 with the latest Alpha of flrig.
The filters remember their last setting per mode so set your filter width to what you want and then if you don't change it, it should come back the next time you use that filter in that mode. It does here anyway.
toggle quoted message
Show quoted text
On Apr 4, 2024, at 09:37, Philip Rose, GM3ZZA via < gm3zza@...> wrote:
What is the current state of filter handling for the IC-7300?
I was testing a different feature for CW on IC-7300 and I noticed that the filter width on the rig for filter3 had been changed from its default.
After some investigation I see that flrig does not change the filter width when I switch the filter on the IC-7300. If I switch mode on the IC-7300 then the current filter number and bandwidth is displayed correctly in flrig. It does not seem to restricted to CW, I see the same happening with other modes.
It works fine with my IC-705.
73 Phil
|
Re: flrig 2.0.05.32 development version posted
What is the current state of filter handling for the IC-7300?
I was testing a different feature for CW on IC-7300 and I noticed that the filter width on the rig for filter3 had been changed from its default.
After some investigation I see that flrig does not change the filter width when I switch the filter on the IC-7300. If I switch mode on the IC-7300 then the current filter number and bandwidth is displayed correctly in flrig. It does not seem to restricted to CW, I see the same happening with other modes.
It works fine with my IC-705.
73 Phil
|
ANNOUNCEMENT: HamPi 4.0a1 32-bit (March 2024) "Raspberry Pi 5 Edition" Released
#rpi5
Hi friends, fellow hams, and HamPi / HamPC / HamIQ??users...
I am pleased to announce that after a long wait,??(32-bit), the comprehensive award-winning ham radio software distribution for the Raspberry Pi, is now available for public download! There have been over 100,000 downloads of HamPi to date across the world.
On March 1, 2022, SourceForge awarded HamPi the Community Choice and SourceForge Favorite awards. Additionally, in late August, 2022, SourceForge awarded HamPi the prestigious Community Leader award.
Direct Download Link:?
NOTE: This is the 32-bit version. The 64-bit version will be released in good time.
All things HamPi / HamPC related:?
If you run into issues, please post to the forum on? /g/Ham-Pi/?first. If you see a bug (defect), please report it on the GitHub issues page at:? Did you know that HamPi has a wiki? Find it at? UPGRADING: In order to transition smoothly from HamPi 3.X to HamPi 4.0a1 and preserve your configuration settings, please follow the instructions in the file found in the download area, "UPGRADING_FROM_PRIOR_VERSION.TXT" (This is still a work in progress.) CHANGELOG: Version 4.0a1 (March 2024) Release
===================================
- Updated copyright year to 2024
- Update for Raspberry Pi 5 Bookworm
- Broken packages (not installed this version)
? due to Bookworm package breakages:
? - All Soapy SDR drivers (Airspy, bladeRF, HackRF,
? ? Pluto, RTLSDR, SDRPlay3, etc.)
? - LeanSDR, Lysdr, GQRX, CubicSDR, SDR++
? - TrustedQSL
? - FreeDV
? - Dump1090
? - OpenDV
? - DroidStar
? - RpiTX
? - Trlog, Hlog
? - NOAA_APT
? - Callrec
- Packages missing from web (removed):
? - Twclock, TwHamQTH
It is my hope that future versions of Bookworm and updates to these packages will allow me to re-add them to the HamPi distribution. If you need one of these packages, please stay with a previous release of HamPi.
Good luck and 73! -- -- Dave,?? ? ? ? ? ? ? ? ? ? ? ?Technical Specialist,??----?? Lifetime Member:?////?----??--
|
CTY-3413 Country Files - 03 April 2024
The Country (CTY) Files were updated on 03 April 2024:
For installation instructions, start at:
Hover your mouse over the word Contest in the menu, then select the
software you are using.
To install the file, follow the link to your software at the top of the page.
If you are interested in a bigger CTY.DAT for everyday logging, you can get
it here:
Note that the release notes (and Version Entity) for this larger file are
different than what is shown below. There is a separate link to them.
As a reminder, there is an RSS feed of the latest country file announcements:
Here are the release notes:
3 April 2024 (CTY-3413)
VER20240403, Version entity is Chile, CE
Added/changed Entities/Prefixes/Callsigns:
* VP8CP is Antarctica, CE9 in ITU zone 73
* GB2WAA is Wales, GW
* IY0GM is Sardinia, IS
* KG6RIJ is Hawaii, KH6
* KI7JRD and KK7GZO are both Alaska, KL
* LU1AW/X is Argentina, LU in ITU zone 16
* R9HAF/6 is European Russia, UA
* R9CS/P is Asiatic Russia, UA9
* VI60IOTA is in ITU zone 59, not ITU zone 55
* VI60IOTA is in CQ zone 30, not CQ zone 29
Removed Entities/Prefixes/Callsigns:
* GB0GGR in Scotland, GM
* IT9AAK/8 in Italy, I
* AA5UN, ND9M and WD9GKG in United States, K
* KA1MRC in Hawaii, KH6
* K4J in Puerto Rico, KP4
* LT2V/D, LU1CBA/D, LU1CBQ/D, LU1DNQ/D, LU1HYW/H, LU1WL/W, LU1XJJ/XA,
LU1XMO/XA, LU1YY/D, LU1YY/V, LU2VV/D, LU2WA/XA, LU2WJV/XA, LU3DR/D, LU3DSR/D,
LU3DXG/D, LU4DQ/E, LU6DDC/D, LU6DJ/D, LU6DM/D, LU6DTJ/D, LU7EYX/D, LU8DBB/D,
LU8DCH/D, LU8EMD/D, LU8XW/X, LU8XW/XP, LU9DEW/D, LW1DYC/D, LW2DJG/D, LW2EDM/D,
LW3DEN/D, LW3EMT/D, LW6EGE/D, LW9DFA/D and LW9EVV/D in Argentina, LU
* R1IE/8, R9XD/9 and RL1I/8 in Asiatic Russia, UA9
Though I am subscribed to this reflector so that I can make these
announcements, I do not see most messages posted to it. If you have
any comments or corrections to the country file, please contact me
directly.
73 - Jim AD1C
--
Jim Reisert AD1C, <jjreisert at alum.mit.edu>,
|
Minor bug - Re: [nbems] flamp 2.2.11.13 development version posted at
Dave/Robert
During testing, but the problem might be existing in older
versions.
I have the unusual flamp config of all three checked;
Autosync fldigi to flamp
Autosync flamp to fldigi
Change fldigi mode just prior to TX
The base idea being I can change the mode on either fldigi or
flamp
flamp 2.2.11.13
fldigi 4.2.04.09
flrig 2.0.05.32
Linux Debian Bookworm XFCE
"Sometimes" when changing modem on flamp it doesn't stick,
reverting back to the prior modem in use. It seems to be more when
changing the base mode (eg PSK250RC7 to PSK250C6, OFDM or MT63)
rather than within the same. (eg PSK250RC7 to PSK250RC5) It takes
a few tries to replicate the fault, for me perhaps 1 in 4 times,
The fault does not occur if changing modem in fldigi.
I assume this is a command/thread race condition. ie
flamp>fldigi modem change, then fldigi>flamp before the
modem change has actually completed.
Cheers Bob VK2YQA
On 1/4/24 23:14, Dave wrote:
toggle quoted message
Show quoted text
Author: kk5vd <kk5vd@...>
??? Document/GUI/Header Modem/Default Modems
???? * Update User Manual for recent changes.
???? * Estimated Relay transmit time not updating on TX panel
modem change.
???? * Header Modem using interval timer RX state delay,
corrected.
???? * Olivia Modem Names to Uppercase.
???? * Remove redundant TX_SEGMENTED check.
???? * Add code for relay repeat counters, interval timer.
Author: dave-w1hkj <w1hkj@...>
??? font browser
????? * update font browser class to use std::list vice
??????? computed array size to enumerate system fonts
Author: kk5vd <kk5vd@...>
??? Tabs/Relay Options/GUI/Fluid
???? * Save selected Tab panel state on exit
???? * Restore selected panel on restart.
???? * Corrected Widget Event Settings (FLUID).
???? * Add Header/Data Repeat Counters for Relay file
transmissions.
???? * Add transmit time widget for relay files.
???? * Move relay auto save checkboxes to config panel.
???? * Corrected default Olivia modem tag names.
???? * Add code to correctly restore RX panel data on file
selection changes.
Report test results to this forum
73, David, W1HKJ
|
Thanks Dave,
Let me know what else need testing for the UTF-8 substitutions.
Phil.
toggle quoted message
Show quoted text
I'll do the UTF-8 substitutions and post a new test tarball for you.
That developers first name is Reme.
Dave
On 4/1/24 08:59, Philip Rose, GM3ZZA via groups.io wrote:
I have managed to install fltk 1.3.9 on top of 1.4 just for this experiment. I'll need to reinstall 1.4 as soon as possible as my app relies on the 1.4 API. I do have the two compilations in the build directories, but to compile using them involves switching
the execute path (for fltk-config), the library path (for the fltk libraries) and the include path (the API has changed).
As I expected it behaves as intended. I attach screenshots of the "about" dialog in the two cases, which show the problem in rendering the text.
You can see that the only problems are with the i-acute (should it be an e-acute in Ren¨¦ not Ren¨ª?), n-tilde and c-cedilla, which I presume are between 128 and 255. The other characters (Greek, Russian and the Polish e-hook) are presumably already coded
as UTF-8.
In the version of coordinates.cxx you sent I noticed you removed the degree, minute and second (¡ã, ', '') altogether rather than replace the ¡ã with the UTF-8 equivalent 0xC2 0xB0 (octal escape \302\260).
Phil.
?
On 31/03/2024 22:31, Dave, W1HKJ wrote:
Can you build fltk-1.3.9 and test an fldigi build against that lib version?
Dave
On 3/31/24 16:17, Philip Rose, GM3ZZA via groups.io wrote:
Managed to get some time to myself after the birthday party and Easter dinner.
I tried this Dave, but it didn't seem to solve this particular case. I downloaded the latest fldigi alpha (4.2.04.09) first, ran .configure and make, then tested. Then copied the two files into src/misc and src/synop-src. Then ran "make clean", "make -j4"
and "sudo make install", so I hope that picked up the changes.
?
It happens when I mouse over a callsign in the RX window. The tooltip that pops up with the info on the DX entity contains the degree sign (or rather doesn't) for the bearing information.
As it's a tooltip I can't move the mouse to copy what it says.
Phil.
On 30/03/2024 22:53, Dave, W1HKJ wrote:
At your convenience Phil.? Happy Birthday to your grandaughter and Happy Easter to you and your family.
Dave
On 3/30/24 17:43, Philip Rose, GM3ZZA via groups.io wrote:
Dave,
They were run-time warnings. I'll not be able to do it tomorrow, as it's my granddaughter's 5th?birthday as well as being Easter Sunday,?
Phil.
Phil,
Try substituting the attached for the original files.? Let me know if there are still compile warnings.
Dave
On 3/30/24 14:36, Philip Rose, GM3ZZA via groups.io wrote:
Hi Dave,
It's an old Dell Intel laptop repurposed with Debian bookworm. I use the default window manager. I built the latest FLTK git using default configuration so Wayland and pango are enabled.
From what I understand from the FLTK forum having had similar problems in my app, pango expects UTF8 characters. It's what draws characters on screen which are not specified in the supplied font.
I will understand if you don't want to support this yet.
73 Phil GM3ZZA
On 30 March 2024, at 17:28, "Dave, W1HKJ"
<w1hkj@...> wrote:
Phil,
I have a brand new Pi5 running PiOS Bookworm with one of several desktop managers (preference is Mate Desktop).? I am not seeing the errors you report.? What processor for the target build.? Is the OS install a base Debian or a derivative?
David
On 3/30/24 11:31, Philip Rose, GM3ZZA via wrote:
I had a quick look. There are quite a lot of degree signs coded in string literals and these will be the extended ASCII 0xB0 rather than the UTF-8 U+00B0 ("\302\260"). One of the files was "coordinates.cxx" (IIRC) in the << operator. The others were large menu_items
as part of a special character list.
Phil.
I compiled fldigi from 4.2.04.05 using the then latest fltk 1.4 on debian bookworm and I keep getting the following warning:
(process:21094): Pango-WARNING **: 22:50:00.323: Invalid UTF-8 string passed to pango_layout_set_text()
>From my own experience this is when an extended ASCII character is used rather than its UTF-8 equivalent. I noticed today as I hovered over a callsign the tooltip window came up and displayed latitude and longitude with the degree symbol replaced by the black
diamond used for an unprintable character. At the same time the pango warning came up.
If you want I can look at the fldigi code tomorrow.
73 Phil.
|
I'll do the UTF-8
substitutions and post a new test tarball for you.
That developers first name is Reme.
Dave
On 4/1/24 08:59, Philip Rose, GM3ZZA
via groups.io wrote:
toggle quoted message
Show quoted text
I have managed to install fltk 1.3.9 on top of 1.4 just for
this experiment. I'll need to reinstall 1.4 as soon as possible
as my app relies on the 1.4 API. I do have the two compilations
in the build directories, but to compile using them involves
switching the execute path (for fltk-config), the library path
(for the fltk libraries) and the include path (the API has
changed).
As I expected it behaves as intended. I attach screenshots of
the "about" dialog in the two cases, which show the problem in
rendering the text.
You can see that the only problems are with the i-acute (should
it be an e-acute in Ren¨¦ not Ren¨ª?), n-tilde and c-cedilla,
which I presume are between 128 and 255. The other characters
(Greek, Russian and the Polish e-hook) are presumably already
coded as UTF-8.
In the version of coordinates.cxx you sent I noticed you
removed the degree, minute and second (¡ã, ', '') altogether
rather than replace the ¡ã with the UTF-8 equivalent 0xC2 0xB0
(octal escape \302\260).
Phil.
?
On 31/03/2024 22:31, Dave, W1HKJ
wrote:
Can you build fltk-1.3.9
and test an fldigi build against that lib version?
Dave
On 3/31/24 16:17, Philip Rose,
GM3ZZA via groups.io wrote:
Managed to get some time to myself after the birthday party
and Easter dinner.
I tried this Dave, but it didn't seem to solve this
particular case. I downloaded the latest fldigi alpha
(4.2.04.09) first, ran .configure and make, then tested.
Then copied the two files into src/misc and src/synop-src.
Then ran "make clean", "make -j4" and "sudo make install",
so I hope that picked up the changes.
?
It happens when I mouse over a callsign in the RX window.
The tooltip that pops up with the info on the DX entity
contains the degree sign (or rather doesn't) for the bearing
information.
As it's a tooltip I can't move the mouse to copy what it
says.
Phil.
On 30/03/2024 22:53, Dave, W1HKJ
wrote:
At your convenience
Phil.? Happy Birthday to your grandaughter and Happy
Easter to you and your family.
Dave
On 3/30/24 17:43, Philip Rose,
GM3ZZA via groups.io wrote:
Dave,
They were run-time warnings. I'll not be able to
do it tomorrow, as it's my granddaughter's 5th?birthday
as well as being Easter Sunday,?
Phil.
Phil,
Try substituting the attached for the original
files.? Let me know if there are still compile
warnings.
Dave
On 3/30/24 14:36, Philip
Rose, GM3ZZA via groups.io wrote:
Hi Dave,
It's an old Dell Intel laptop
repurposed with Debian bookworm. I use the default
window manager. I built the latest FLTK git using
default configuration so Wayland and pango are
enabled.
From what I understand from the FLTK
forum having had similar problems in my app, pango
expects UTF8 characters. It's what draws
characters on screen which are not specified in
the supplied font.
I will understand if you don't want to
support this yet.
73 Phil GM3ZZA
On 30 March 2024, at 17:28, "Dave, W1HKJ"
<w1hkj@...> wrote:
Phil,
I have a brand new Pi5 running PiOS Bookworm with
one of several desktop managers (preference is
Mate Desktop).? I am not seeing the errors you
report.? What processor for the target build.? Is
the OS install a base Debian or a derivative?
David
On 3/30/24 11:31,
Philip Rose, GM3ZZA via wrote:
I had a quick
look. There are quite a lot of degree signs coded
in string literals and these will be the extended
ASCII 0xB0 rather than the UTF-8 U+00B0
("\302\260"). One of the files was
"coordinates.cxx" (IIRC) in the << operator.
The others were large menu_items as part of a
special character list.
Phil.
I compiled fldigi
from 4.2.04.05 using the then latest fltk
1.4 on debian bookworm and I keep getting
the following warning:
(process:21094): Pango-WARNING **:
22:50:00.323: Invalid UTF-8 string passed to
pango_layout_set_text()
>From my own experience this is when an
extended ASCII character is used rather than
its UTF-8 equivalent. I noticed today as I
hovered over a callsign the tooltip window
came up and displayed latitude and longitude
with the degree symbol replaced by the black
diamond used for an unprintable character.
At the same time the pango warning came up.
If you want I can look at the fldigi code
tomorrow.
73 Phil.
|
I have managed to install fltk 1.3.9 on top of 1.4 just for this
experiment. I'll need to reinstall 1.4 as soon as possible as my
app relies on the 1.4 API. I do have the two compilations in the
build directories, but to compile using them involves switching
the execute path (for fltk-config), the library path (for the fltk
libraries) and the include path (the API has changed).
As I expected it behaves as intended. I attach screenshots of the
"about" dialog in the two cases, which show the problem in
rendering the text.
You can see that the only problems are with the i-acute (should
it be an e-acute in Ren¨¦ not Ren¨ª?), n-tilde and c-cedilla, which
I presume are between 128 and 255. The other characters (Greek,
Russian and the Polish e-hook) are presumably already coded as
UTF-8.
In the version of coordinates.cxx you sent I noticed you removed
the degree, minute and second (¡ã, ', '') altogether rather than
replace the ¡ã with the UTF-8 equivalent 0xC2 0xB0 (octal escape
\302\260).
Phil.
?
On 31/03/2024 22:31, Dave, W1HKJ wrote:
toggle quoted message
Show quoted text
Can you build fltk-1.3.9 and
test an fldigi build against that lib version?
Dave
On 3/31/24 16:17, Philip Rose, GM3ZZA
via groups.io wrote:
Managed to get some time to myself after the birthday party
and Easter dinner.
I tried this Dave, but it didn't seem to solve this
particular case. I downloaded the latest fldigi alpha
(4.2.04.09) first, ran .configure and make, then tested. Then
copied the two files into src/misc and src/synop-src. Then ran
"make clean", "make -j4" and "sudo make install", so I hope
that picked up the changes.
?
It happens when I mouse over a callsign in the RX window. The
tooltip that pops up with the info on the DX entity contains
the degree sign (or rather doesn't) for the bearing
information.
As it's a tooltip I can't move the mouse to copy what it
says.
Phil.
On 30/03/2024 22:53, Dave, W1HKJ
wrote:
At your convenience
Phil.? Happy Birthday to your grandaughter and Happy
Easter to you and your family.
Dave
On 3/30/24 17:43, Philip Rose,
GM3ZZA via groups.io wrote:
Dave,
They
were run-time warnings. I'll not be able to do it
tomorrow, as it's my granddaughter's 5th?birthday
as well as being Easter Sunday,?
Phil.
Phil,
Try substituting the attached for the original files.?
Let me know if there are still compile warnings.
Dave
On 3/30/24 14:36, Philip
Rose, GM3ZZA via groups.io wrote:
Hi Dave,
It's an old Dell Intel laptop repurposed
with Debian bookworm. I use the default window
manager. I built the latest FLTK git using default
configuration so Wayland and pango are enabled.
From what I understand from the FLTK
forum having had similar problems in my app, pango
expects UTF8 characters. It's what draws characters
on screen which are not specified in the supplied
font.
I will understand if you don't want to
support this yet.
73 Phil GM3ZZA
On 30 March 2024, at 17:28, "Dave, W1HKJ" <w1hkj@...>
wrote:
Phil,
I have a brand new Pi5 running PiOS Bookworm with
one of several desktop managers (preference is Mate
Desktop).? I am not seeing the errors you report.?
What processor for the target build.? Is the OS
install a base Debian or a derivative?
David
On 3/30/24 11:31, Philip
Rose, GM3ZZA via wrote:
I had a quick look.
There are quite a lot of degree signs coded in
string literals and these will be the extended ASCII
0xB0 rather than the UTF-8 U+00B0 ("\302\260"). One
of the files was "coordinates.cxx" (IIRC) in the
<< operator. The others were large menu_items
as part of a special character list.
Phil.
I compiled fldigi from
4.2.04.05 using the then latest fltk 1.4 on
debian bookworm and I keep getting the
following warning:
(process:21094): Pango-WARNING **:
22:50:00.323: Invalid UTF-8 string passed to
pango_layout_set_text()
>From my own experience this is when an
extended ASCII character is used rather than
its UTF-8 equivalent. I noticed today as I
hovered over a callsign the tooltip window
came up and displayed latitude and longitude
with the degree symbol replaced by the black
diamond used for an unprintable character. At
the same time the pango warning came up.
If you want I can look at the fldigi code
tomorrow.
73 Phil.
|
David Eddleman, K5RNL
Philip Rose, GM3ZZA
Dave, W1HKJ
Dave Slotter, W3DJS
