开云体育

HNY to all.? Hope that 2025 brings good health and happy digital QSOs to all.? Lord willing and the creek don't rise, I plan on continuing support of all of the fl applications during this year.

73, David
W1HKJ

Well done Tim.

73 and happy new year.

Dave G0WBX.

--
Created on and sent from a Unix like PC running and using open source software:

开云体育

Hi Richard

I think I remember that datatype error back in (my) 4.6 days. This would however be a recent change in the current master branch? Mine is at Hamlib 4.7~git 2024-12-29T16:43:39Z SHA=028d75 64-bit

Is it likely to be reverted in this branch?

Cheers Bob VK2YQA

The Country (CTY) Files were updated on 31 December 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:

31 December 2024 (CTY-3441)
VER20241231, Version entity is Trinidad & Tobago, 9Y

Added/changed Entities/Prefixes/Callsigns:

* IZ1KHY/IA0 is in ITU zone 70, not ITU zone 74
* IZ1KHY/IA0 is in CQ zone 29, not CQ zone 13
* IA0/IZ1KHY is Antarctica, CE9 in CQ zone 29, ITU zone 70
* N3ZZ is in ITU zone 7, not ITU zone 6
* N3ZZ is in CQ zone 4, not CQ zone 3
* AA6X is United States, K in CQ zone 4, ITU zone 7
* KI4LLA, KM4FOC and N4XTT are all United States, K in CQ zone 4, ITU zone 8
* K7ZVZ and N8YAK are both Alaska, KL
* LU1UU/D is Argentina, LU
* RK25NY, RN25NY, RT25NY, RW25NY and UA4FMQ/P are all European Russia, UA
* RQ9F/4 is European Russia, UA in ITU zone 30
* RX25NY is European Russia, UA in CQ zone 17, ITU zone 20
* RN1B/2 is Kaliningrad, UA2
* RC25BA, RC5B/8 and RO25NY are all Asiatic Russia, UA9
* RV7B/9 is Asiatic Russia, UA9 in ITU zone 20
* R0KA/9 is Asiatic Russia, UA9 in CQ zone 18
* RU25NY is Asiatic Russia, UA9 in CQ zone 18, ITU zone 31
* VK9/W5EIT is Cocos (Keeling) Islands, VK9C

Removed Entities/Prefixes/Callsigns:

* GB1RBL in Scotland, GM
* GB4SDC in Wales, GW
* IQ0SS/P in Sardinia, IS
* NJ5M in United States, K
* AK0S, KD7ZAP and ND1A in Hawaii, KH6
* KK6IQC in Alaska, KL
* KX4GB in Puerto Rico, KP4
* LU9XBA/L in Argentina, LU
* R0CM/4 and R225P in European Russia, UA
* R0FBA/9, R4HY/8, RA9WU/P and RK4PA/9 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>,

开云体育

Thanks for all your responses to this question. You've opened a door with the various tips.


73, Robin KK7MSN

开云体育

Hi Tim.

But, does the "Serialization" information set by Icom, appear in the strings returned to the system when they are enumerated on connection?

dmesg -WH should show it on finding the device, if it does.? eg:-? For a FTDI based device ...

dave@DellXPS:~$ dmesg -WH
[Dec31 10:45] usb 3-2.2: new full-speed USB device number 78 using xhci_hcd
[  +0.118563] usb 3-2.2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[  +0.000021] usb 3-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000007] usb 3-2.2: Product: FT232R USB UART
[  +0.000005] usb 3-2.2: Manufacturer: FTDI
[  +0.000005] usb 3-2.2: SerialNumber: AK06ML2R
[  +0.007436] ftdi_sio 3-2.2:1.0: FTDI USB Serial Device converter detected
[  +0.000066] usb 3-2.2: Detected FT232R
[  +0.002631] usb 3-2.2: FTDI USB Serial Device converter now attached to ttyUSB5

(My emphasis.)


What does that show for your Icom when it is connected?


The above will NOT show any udev created devices, but:-

dave@DellXPS:~$ ls /dev/tty*
/dev/tty    /dev/tty16  /dev/tty24  /dev/tty32  /dev/tty40  /dev/tty49  /dev/tty57  /dev/tty8      /dev/ttyS3
/dev/tty0   /dev/tty17  /dev/tty25  /dev/tty33  /dev/tty41  /dev/tty5   /dev/tty58  /dev/tty9      /dev/ttyTMV71
/dev/tty1   /dev/tty18  /dev/tty26  /dev/tty34  /dev/tty42  /dev/tty50  /dev/tty59  /dev/ttyACM0   /dev/ttyUSB0
/dev/tty10  /dev/tty19  /dev/tty27  /dev/tty35  /dev/tty43  /dev/tty51  /dev/tty6   /dev/ttyACM1   /dev/ttyUSB1
/dev/tty11  /dev/tty2   /dev/tty28  /dev/tty36  /dev/tty44  /dev/tty52  /dev/tty60  /dev/ttyACM2   /dev/ttyUSB2
/dev/tty12  /dev/tty20  /dev/tty29  /dev/tty37  /dev/tty45  /dev/tty53  /dev/tty61  /dev/ttyICR9K  /dev/ttyUSB3
/dev/tty13  /dev/tty21  /dev/tty3   /dev/tty38  /dev/tty46  /dev/tty54  /dev/tty62  /dev/ttyS0     /dev/ttyUSB4
/dev/tty14  /dev/tty22  /dev/tty30  /dev/tty39  /dev/tty47  /dev/tty55  /dev/tty63  /dev/ttyS1     /dev/ttyUSB5
/dev/tty15  /dev/tty23  /dev/tty31  /dev/tty4   /dev/tty48  /dev/tty56  /dev/tty7   /dev/ttyS2

Does.? The two in Blue in this case.

As a check...

dave@DellXPS:~$ readlink /dev/ttyTMV71 /dev/ttyICR9K
ttyUSB5
ttyUSB4

Reveals who's what, etc...?? Should some old-school software need the default format.


Flrig these days shows everything the system presents, when you go to configure a rig.
(Assuming the thing is connected before starting Flrig.? Else, use the "Update" button to the left of the port field in Config/Setup/Tranceiver.

Older versions will also accept things like /dev/ttyICR9K in the appropriate field of the radio specific .prefs file Flrig uses.
But, if something changes the setting in the settings UI, that will be reset.

Using a bash script to copy a fixed version of the .prefs file to the .flrig folder, before launching Flrig, can nail it down, so that if anyone does fiddle, exiting and restarting (via the script) will restore normal service.? (Possibly of use under EMCOM conditions, with less skilled operators perhaps.)


73.
Dave G0WBX.

-- 
Created on and sent from a Unix like PC running and using open source software:

That looks much like what happens, when Fldigi is not initially set for the correct CW WPM speed for the incoming signal, but eventually figures it out for itself.

Check the two figures in boxes bottom left of the main window when in CW mode while it's printing garbage, and then gets sensible.? One you can set, the other it what it finds for itself.

73.

Dave G0WBX.

--
Created on and sent from a Unix like PC running and using open source software:

开云体育

Hi Tobias,

I'll fix the tooltip.? I tested for Mid-Latitude-Disturbed NVIS 0 dB s/n; with 0, 1, 2 msec shaping.? Did not see any decrease in decode performance.? 4 or more msec will effect decode under stressful HF conditions.? The shaping does reduce the bandwidth for those situations where that is critical and signal is expected to be strong.

David

开云体育

Hi Dave

Had a build failure here. I build/test every fldigi change plus hamlib just prior. I have not tried to run this down, so only regard as background info.

Hamlib comes from git pull;
./bootstrap
./configure --with-python-binding PYTHON_VERSION='3.11' (FreeDATA?)
nice make -j 4
sudo make install
Hamlib 4.7~git 2024-12-29T16:43:39Z SHA=028d75 64-bit

fldigi build is vanilla
./configure --enable-optimizations=native
nice make -j 4

rigcontrol/hamlib.cxx: In function ‘void hamlib_get_rigs()’:
rigcontrol/hamlib.cxx:612:26: error: invalid conversion from ‘int (*)(rig_caps*, void*)’ to ‘int (*)(const rig_caps*, void*)’ [-fpermissive]
? 612 |???????? rig_list_foreach(add_to_list, 0);
????? |????????????????????????? ^~~~~~~~~~~
????? |????????????????????????? |
????? |????????????????????????? int (*)(rig_caps*, void*)
In file included from ./include/rigclass.h:27,
???????????????? from ./include/main.h:36,
???????????????? from ./include/squelch_status.h:31,
???????????????? from ./include/status.h:29,
???????????????? from ./include/nanoIO.h:42,
???????????????? from ./include/confdialog.h:424,
???????????????? from rigcontrol/hamlib.cxx:34:
/usr/local/include/hamlib/rig.h:3794:18: note:?? initializing argument 1 of ‘int rig_list_foreach(int (*)(const rig_caps*, void*), void*)’
?3794 | rig_list_foreach HAMLIB_PARAMS((int (*cfunc)(const struct rig_caps *, rig_ptr_t),
????? |????????????????? ^~~~~~~~~~~~~
make[3]: *** [Makefile:5636: rigcontrol/fldigi-hamlib.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/home/data.lap/mountpoints/raid10/data2/home/shared/Active/src-Active/lapp600/fldigi-4.2.06.18/src'
make[2]: *** [Makefile:8878: all-recursive] Error 1
make[2]: Leaving directory '/home/data.lap/mountpoints/raid10/data2/home/shared/Active/src-Active/lapp600/fldigi-4.2.06.18/src'
make[1]: *** [Makefile:2044: all] Error 2
make[1]: Leaving directory '/home/data.lap/mountpoints/raid10/data2/home/shared/Active/src-Active/lapp600/fldigi-4.2.06.18/src'
make: *** [Makefile:471: all-recursive] Error 1

Cheers Bob VK2YQA

开云体育

Added configurable tone shaping.? This is specifc to THOR.

???????????????????????????? 0 msec risetime???????????????????????????????????????????????????????????????????????????? 4 msec risetime

4 msec leading/trailing edge is similar to a CW signal.

David

Happy New Year, Folks... :)

I tried to install FLDIGI for Android on two devices that run GrapheneOS, which is an AOSP(Android Open Source Project) Rom.? If you're not familiar, GrapheneOS has higher security built into it and as such runs Google Play in a sandbox so it doesn't have copious access to everything on the phone or tablet (basically runs as a user level app and not 'root').

I attempted to install FLDIGI on a Google Tablet running GrOS and it errored out with 'App not installed as app isn't compatiable with your phone'.? I tried installing it on my Google Pixel 8 phone running GrOS as a test and it errored with the same message.? Now I'm able to install apps from the Google Play store with no issues and even sideload from F-Droid and other repositories so I haven't seen this error with any other apps I've used so far (This is the first time seeing an error of any kind).

Is FLDIGI actually looking for a Google OEM ROM image (via a specific OS identifying string) because it seems to have a problem with an AOSP version?

The APK I attempted to install was version 1.5.0 from the Sourceforge repository.

Any ideas?

Thanks!

Steve Baetz (N2YNQ)

No sudo needed, just open a terminal window, and enter...

dmesg -WH? (On Debian/Ubuntu/Mint based systems at least.)

Nothing will happen, until you connect, or disconnect something, then it'll show you what it is, or was etc.

Chances are the ICOM's use something generic for the USB/Serial part of things, that does not have any unique identifier (other than the I/O "path" to it) that you could use to create a udev rule, so you could have "reliable" /dev/ttyIC9100main and /dev/ttyIC9100sub virtual serial devices each and every time.

So long as, the device hardware path to it, is fixed.

I've just given up with such Prolific, SiLab and other generic chipset based things, as on many modern PC's (some laptops especially) even the "hardware numerical path" to external devices varies each time the system is powered up, or in one case when warm rebooted!? Probably due to the use of nested internal USB Hubs, inside the PC, and the way they are enumerated too.

At least FTDI based devices (the "Genuine" ones at least) all have a unique serial number that you can use for UDEV rules.

Resulting in (for example) a nice 100% reliable each and every time /dev/ttyICR9000 device to tell the software about.

Regardless of what host computer USB orifice I plug it's lead into, be that direct on the back of the PC, or via any combination of hubs.

The rule (in /lib/udev/rulesd/99shack.rules) for that device is:-

#IC-R900
SUBSYSTEM=="tty", ATTRS{serial}=="A10NDGR5", SYMLINK+="ttyICR9K"

That serial number "A10NDGR5" is unique to that particular USB<>C-IV lead, in fact, that particular embedded USB/Serial bridge chip used in the lead assembly!

I also have, among others...

#FT-736r
SUBSYSTEM=="tty", ATTRS{serial}=="A50285BI", SYMLINK+="ttyFT736"
(Based on the embedded serial number of a FTDI based USB to TTL serial adapter board, commonly used for working with Arduino's that don't have their own USB port.)

#TM-V71
SUBSYSTEM=="tty", ATTRS{serial}=="AK06ML2R", SYMLINK+="ttyTMV71"
(Based on the embedded serial number of a commercial FTDI based cable)

All result in the same /dev/tty device each and every time, so no confusion, even after a RFI event, they come back just the same after the system re-enumerates things.

(The system default assigned /dev/ttyUSB0 or 1 etc, are still present.? If you have application software that can't, or wont accept custom port names, you can often launch such programs from a script, in which you can "readlink /dev/ttyFT736" for example, and put the resulting normal "ttyUSB4" assignment for example, into a system variable from where you can hopefully specify that on the command line that launches the program, or feed it in some other way.? I've even grep'd and replaced a config file "port value" before invoking the program in the past.)

FTDI might be more expensive than others, but you get what you pay for, and an easier life too!
In the UK, "Technofix.uk" sell such cables for sensible costs, and they always work.? (Even on windows, the update service will find the correct driver, if not already installed.)

Google "writing linux udev rules" for some background, but be aware the learning curve is steep at first, but stick with it, they really do work very well.? SO LONG AS there is something "unique" about each such USB device.

Sadly, most equipment makers take the cheap generic route.?? Even though many of those such devices can also be connected to an external EEROM, where such unique info can be stored, and will override the chip's own default when a host system enumerates it on connection / re-connection.

Many common audio codec chips (Cmedia for example) can also do that, but again most device makers don't want the expense of extra parts and the process of creating and assigning such unique ID codes.

It could be possible to "dead bug" such an additional chip, if the codec/bridge chip's needed pins are not connected to anything else. And one has the eyes of a hawk plus microsurgery soldering tools!

One day, all this might be easy, but I'm not holding my breath!

Seasons Greetings...

Dave G0WBX.

--
Created on and sent from a Unix like PC running and using open source software: