Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend charset for Anytone #316

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

majkrzak
Copy link
Contributor

@majkrzak majkrzak commented Feb 23, 2023

Intro

While experimenting with APRS and AT878UVII+ I've accidentally find out that it supports much more than just ASCII characters. Further play with their CPS and scrolling through the font file, made me believe that it is the GBK encoding.

Details

GBK encodes ASCII characters on one byte, and non ASCI ones on two bytes. This could explain why some 16 characters fields are 32 bytes padded.

QT supports GBK through QTextCodec. I've made my implementation on top of it and it seem to work as expected.

TL:DR

This PR should give us possibility to use fancy characters like: "∮" or "№ " (see). It will also let something like naming "hotspot" as "ホットスポット" 😊
IMG_20230223_170734.jpg

TODO:

  • Implement GBK encoding/decoding
  • Implement GBK RadioLimit
  • Use GBK in channel name as POC
  • Use GBK where it is supposed to be used
  • Rewrite encoding/decoding (cleanup explicit for loop)
  • Fix yaml saving issue (qdmr fails to save the utf characters)
  • Prepare graphic with Anytone font

@hmatuschek
Copy link
Owner

hmatuschek commented Feb 23, 2023

The YAML issue may require some work as the yaml-cpp library only supports utf8 in std::string. I neglected that so far. However, the majority of strings are serialized automatically from the Qt properties by calling QString::toStdString() which itself first calls toUtf8(). So if the GBK string can be converted to Utf8, it should be no problem to be stored and read from the YAML file.

@majkrzak
Copy link
Contributor Author

Yes it is exactly how it works. String is converted to Unicode when generating reading the binary data to be uploaded.

For some reason I had problem that when adding non asci chars to the channel name it wasn't saved to yaml. Neither radio or the fancy encode was involved. I'll investigate this after the weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants