View Issue Details

IDProjectCategoryView StatusLast Update
0002945Ham Radio DeluxeBugpublic2019-11-07 05:46
Reportervk2byiAssigned ToK7ZCZ 
Status closedResolutionfixed 
PlatformOSWindows 10 Pro - 64-bitOS Version1803
Product Version 
Target VersionFixed in Version6.5.0.196 
Summary0002945: N1MM Logger 80m contacts forwarded to Logbook captured as 93m
DescriptionN1MM Logger specifies 80m band contacts with a Band value of 3{decimal symbol}5 where {decimal symbol} is a period when the regional settings are English:

<?xml version="1.0" encoding="utf-8"?>
    <band>3.5</band> <== comma

However, when the regional settings are Danish, the {decimal symbol} is a comma.

Eivind (OZ1QX) reported on Facebook that his 80m contacts where being captured in Logbook as 93m. I managed to reproduce the problems in my test environment by changing the regional settings in Windows to Danish.

Logbook needs to handle the variations in the decimal symbol between locales when mapping the N1MM Band value to the Logbook value.
Steps To Reproduce1. Configure QSO Forwarding in Logbook to receive UDP packets from N1MM Logger on port 12060;
2. Configure N1MM Logger to broadcast Contacts on port 12060;
3. Change the Region settings in Windows to Danish (Denmark). This results in the decimal symbol being set to a comma;
4. Restart N1MM Logger so that it detects the change in regional settings;
5. Log an 80m contact in N1MM Logger and note that the Band value captured incorrectly in Logbook as 93m;
6. Change the Region settings in Windows back to English (US) (English (Australian) in my case). This results in the decimal symbol being set to a period;
7. Restart N1MM Logger so that it detects the change in regional settings;
8. Log an 80m contact in N1MM Logger and note that the Band value captured in Logbook is correctly logged as 80m.
Additional InformationI have attached a PDF document that records the steps to reproduce with more detail.
TagsNo tags attached.
Testing Beta Successful



2018-11-17 22:26


93m.pdf (172,654 bytes)


2018-11-17 22:35

viewer   ~0006431

Updated version of attachment with more detail.

93m-2.pdf (195,692 bytes)


2018-11-23 10:45

administrator   ~0006445

To me, it seems like a bug in N1MM to use the user's locale setting for values that aren't actually shown to the user. The communications on this UCP port are pretty clearly meant for consuymption by another application, not directly by a human being. The N1MM documentation (at ) makes no mention of the use of localized numbers, so the appearance of localized values is probably a surprise to any consumer of the data stream.

Notably, the date format is still the ISO-like yyyy-MM-dd format, and the frequency doesn't have thousands separators, even when the Danish locale is selected.

I've made the fix to parse the value in the <band> field with attention to the user's locale settings, so this issue is fixed as it lies.

However, we can't be sure that every application will do so because the N1MM documentation isn't forthcoming about the intention of the design. I've resisted the temptation to try to write code that screws around with trying to parse the field flexibly, since that seems likely to lead to more trouble and could accept junk data.

By the way! Thanks for always writing such clear and detailed reports. It's really refreshing, and it makes it a snap to understand, investigate, and diagnose the issue you're describing.


2018-11-23 10:47

administrator   ~0006446

fix in the 6.5 branch with this checkin


2018-11-23 10:55

administrator   ~0006447

I've opened a bug over at the N1MM website. I didn't get an issue or ticket number. Maybe they'll offer a fix to consistently use a period; or maybe they'll document their intention to use the localized format. With that information in hand, we can react appropriately.


2018-11-23 16:24

viewer   ~0006451

Thanks Mike for your kind words - maybe something has rubbed off on me after working in IT for 40 years before retiring! :-)

It is good that you have reported the issue on the N1MM website and hopefully they will clearly document their intention. It strikes me as unusual that N1MM uses frequencies values for the <Band> element instead of actual band values in the XML UDP packet payload though.

Good work. 73 Chris.

Issue History

Date Modified Username Field Change
2018-11-17 22:26 vk2byi New Issue
2018-11-17 22:26 vk2byi File Added: 93m.pdf
2018-11-17 22:35 vk2byi File Added: 93m-2.pdf
2018-11-17 22:35 vk2byi Note Added: 0006431
2018-11-23 10:45 K7ZCZ Note Added: 0006445
2018-11-23 10:47 K7ZCZ Assigned To => K7ZCZ
2018-11-23 10:47 K7ZCZ Status new => resolved
2018-11-23 10:47 K7ZCZ Resolution open => fixed
2018-11-23 10:47 K7ZCZ Testing => Not Started
2018-11-23 10:47 K7ZCZ Note Added: 0006446
2018-11-23 10:55 K7ZCZ Note Added: 0006447
2018-11-23 16:24 vk2byi Note Added: 0006451
2018-12-05 11:24 WA9PIE Project 1 - Backlog => 3 - Current Dev List
2018-12-09 15:44 K7ZCZ Fixed in Version =>
2018-12-20 22:34 WA9PIE Status resolved => closed
2018-12-20 22:34 WA9PIE Description Updated View Revisions
2018-12-20 22:34 WA9PIE Steps to Reproduce Updated View Revisions
2018-12-20 22:34 WA9PIE Testing Not Started => Beta Successful
2019-01-16 22:04 WA9PIE Fixed in Version =>
2019-01-16 22:04 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2019-11-07 05:46 WA9PIE Fixed in Version =>