Hello from new member!
Hello from new member!
Hi all!
My name is Olle from Bromma in Sweden, I recently picked up a Retevis RT84 and liked the OpenGD77 experience so much I ordered an RT3S in the Christmas sales to compare it to. Having 2 radios also will help in playing around with firmware features, such as TA.
I knocked together a CSV converter utility to make it easier to import repeaters from the SSA database (https://www.ssa.se/vushf/repeatrar-fyrar/) and will be sharing soon for my fellow Nordic hams to enjoy. I'm QRV on Brandmeister TG 240 if you want to give me a call!
Looking forward to the promised source code drop, as I would like to help fix the currently broken Unicode text in OpenGD77 CPS and the Callsign database.
73 de SA0ASM
My name is Olle from Bromma in Sweden, I recently picked up a Retevis RT84 and liked the OpenGD77 experience so much I ordered an RT3S in the Christmas sales to compare it to. Having 2 radios also will help in playing around with firmware features, such as TA.
I knocked together a CSV converter utility to make it easier to import repeaters from the SSA database (https://www.ssa.se/vushf/repeatrar-fyrar/) and will be sharing soon for my fellow Nordic hams to enjoy. I'm QRV on Brandmeister TG 240 if you want to give me a call!
Looking forward to the promised source code drop, as I would like to help fix the currently broken Unicode text in OpenGD77 CPS and the Callsign database.
73 de SA0ASM
Re: Hello from new member!
Welcome.
Re: Hello from new member!
We can only release the firmware source code. We planned to release the firmware source code a few days ago but we had problems with making archives of the build scripts.
We now plan to release the firmware source code before the end of the year. Assuming there are no more problems.
Unfortunately, we can't release the CPS source code, because we did not own the IP.
Hence to avoid litigation we are unable to release the source code publically.
What issue do you have with Unicode text and does it relate to the CPS or the firmware or both.
The database is stored in a compress format, and only supports a subset of ASCII (A-Z,a-z,0-9 and some punctuation)
Also, the display fonts are not unicode, as the max char index is 255, and special mappings are used to convert the native characters into the font characters.
So basically, its impractical to support anything other than the minimal subset of ASCII for the database.
If you mean conversion of things like accented characters to non-accented versions, then this may be possible in the CPS.
e.g.
https://stackoverflow.com/questions/249 ... ing-in-net
Do you have specific examples of unhandled accented characters in the DMRID database from RadioId.net
Re: Hello from new member!
Hi!
I specifically mean the display of non-ascii characters in the CPS user interface is broken. Importing UTF-8 channel/zone names from csv "works" in that they get converted to the correct codepage in the codeplug (and so show up correctly in the radio display), but the CPS user interface shows garbled characters and it is not possible to enter non-ascii characters in the ui dialogs (they get incorrectly converted). Also, entries in the callsign db that use UTF-8 characters do NOT get properly converted before writing to the radio, leading to the UTF-8 characters being displayed as two separate characters in the radio display.
By IP ownership, I guess you mean that the code is based on decompiled code from the "official" .NET CPS? Would you perhaps be interested in collaborating on a new CPS unencumbered by concerns about reverse-engineered code? I may be interested in doing a "re-write" of the basic CPS software in C#, if that would help remove the restrictions on releasing the code.
73 de SA0ASM
I specifically mean the display of non-ascii characters in the CPS user interface is broken. Importing UTF-8 channel/zone names from csv "works" in that they get converted to the correct codepage in the codeplug (and so show up correctly in the radio display), but the CPS user interface shows garbled characters and it is not possible to enter non-ascii characters in the ui dialogs (they get incorrectly converted). Also, entries in the callsign db that use UTF-8 characters do NOT get properly converted before writing to the radio, leading to the UTF-8 characters being displayed as two separate characters in the radio display.
By IP ownership, I guess you mean that the code is based on decompiled code from the "official" .NET CPS? Would you perhaps be interested in collaborating on a new CPS unencumbered by concerns about reverse-engineered code? I may be interested in doing a "re-write" of the basic CPS software in C#, if that would help remove the restrictions on releasing the code.
73 de SA0ASM
Re: Hello from new member!
Also, an example of an entry in the radioid.net database with UTF-8 that doesn't display properly would be SA0PRJ (2400871) with a city name of "Saltsjöbaden" which is displayed in the radio as "SatsjA.baden".
73 de SA0ASM
73 de SA0ASM
Re: Hello from new member!
The codeplug format is not unicode its 8 bits per character.SA0ASM wrote: ↑Wed Dec 27, 2023 8:27 amHi!
I specifically mean the display of non-ascii characters in the CPS user interface is broken. Importing UTF-8 channel/zone names from csv "works" in that they get converted to the correct codepage in the codeplug (and so show up correctly in the radio display), but the CPS user interface shows garbled characters and it is not possible to enter non-ascii characters in the ui dialogs (they get incorrectly converted). Also, entries in the callsign db that use UTF-8 characters do NOT get properly converted before writing to the radio, leading to the UTF-8 characters being displayed as two separate characters in the radio display.
By IP ownership, I guess you mean that the code is based on decompiled code from the "official" .NET CPS? Would you perhaps be interested in collaborating on a new CPS unencumbered by concerns about reverse-engineered code? I may be interested in doing a "re-write" of the basic CPS software in C#, if that would help remove the restrictions on releasing the code.
73 de SA0ASM
As I said in my last post, the firmware's font system uses a special mapping to support some non-alpha numeric characters.
Daniel F1RMB designed the mapping system used for the language strings, so I don't know how practical it would be to integrate the character mapping as part of the DB import or on-the-fly mapping when strings are rewitten / read from text boxes, to and from the internal strings or potentially only when the internal representation is converted to and from the codeplug binary format.
Re: Writing the CPS again from scratch
This would take a huge amount of time, which I personally don't have.
There is nothing to stop you writing your own CPS from scratch if you have time.
Re: Hello from new member!
Hi,
RadioId.net's user.csv isn't UTF-8 (it's us-ascii encoding), but we're using some custom remapping.
Maybe we could incorporate our conversion code to the CPS code to correctly remap the special characters when uploading the database.
Cheers.
RadioId.net's user.csv isn't UTF-8 (it's us-ascii encoding), but we're using some custom remapping.
Maybe we could incorporate our conversion code to the CPS code to correctly remap the special characters when uploading the database.
Cheers.
Re: Hello from new member!
@VK3KYY you misunderstand me, I'm talking about two separate issues here. The first is the internal representation of channel/zone names in the CPS UI, before the data gets written to the codeplug. I suspect there's some conversion from unicode to a chinese 8-bit codepage and back happening, screwing up what is displayed in the UI dialogs. It's impossible to input non-ascii text in the CPS and have it correctly display on the radio, though csv import of utf-8 names gets correctly translated when written to the codeplug, it just looks screwy in the UI. I could probably spend an hour or so investigating exactly where this happens. If I do, I'll start a thread about the bug in another part of the forum!
@F1RMB Yes, that's the second issue I'm talking about! So the radioid database export you guys are using is already converted to ascii (more likely latin1 or something) and is not in utf-8 format? I'll need to look at the source files then, and get back to you!
As to rewriting the CPS, I would probably need some indication that you would be happy to include the OpenGD77 specific feature additions in an open source re-write before committing my time. I'd rather not spend the effort to have the results be "just another" third party CPS clone. Anyway, we should probably take these discussions to the appropriate forum sections.
73 de SA0ASM
@F1RMB Yes, that's the second issue I'm talking about! So the radioid database export you guys are using is already converted to ascii (more likely latin1 or something) and is not in utf-8 format? I'll need to look at the source files then, and get back to you!
As to rewriting the CPS, I would probably need some indication that you would be happy to include the OpenGD77 specific feature additions in an open source re-write before committing my time. I'd rather not spend the effort to have the results be "just another" third party CPS clone. Anyway, we should probably take these discussions to the appropriate forum sections.
73 de SA0ASM
Re: Hello from new member!
It's not even a latin1 encoding, it's a mess:SA0ASM wrote: ↑Wed Dec 27, 2023 4:26 pm@VK3KYY you misunderstand me, I'm talking about two separate issues here. The first is the internal representation of channel/zone names in the CPS UI, before the data gets written to the codeplug. I suspect there's some conversion from unicode to a chinese 8-bit codepage and back happening, screwing up what is displayed in the UI dialogs. It's impossible to input non-ascii text in the CPS and have it correctly display on the radio, though csv import of utf-8 names gets correctly translated when written to the codeplug, it just looks screwy in the UI. I could probably spend an hour or so investigating exactly where this happens. If I do, I'll start a thread about the bug in another part of the forum!
@F1RMB Yes, that's the second issue I'm talking about! So the radioid database export you guys are using is already converted to ascii (more likely latin1 or something) and is not in utf-8 format? I'll need to look at the source files then, and get back to you!
As to rewriting the CPS, I would probably need some indication that you would be happy to include the OpenGD77 specific feature additions in an open source re-write before committing my time. I'd rather not spend the effort to have the results be "just another" third party CPS clone. Anyway, we should probably take these discussions to the appropriate forum sections.
73 de SA0ASM
daniel@daniel-Latitude-7480:~ $ file --mime-encoding --mime-type ~/tmp/user.csv
/home/daniel/tmp/user.csv: text/csv; charset=us-ascii
Re: Hello from new member!
I'm unsure if we are looking at the same data, so I downloaded the user.csv file from the same URL taht the OpenGD77 CPS uses and inspected it. The whole file is utf-8 encoded, I checked it with the iconv utility. When you say "it's a mess", what exactly do you mean? That rows can have different character encodings? Or something else? Could you give an example of a "messed up" entry in that file?
73 de SA0ASM
73 de SA0ASM