Log под Ubuntu

[RX1AL]

.....
А одна табличка только повторяет бумажньій журнал.
.....

Если хранить локатор в поле типа TEXT SQLite, то уже не на 2 байта увеличится...
И если добавить и RDA или URDA - будет еще больше.

Вы не совсем правильно предполагаете. Поясню. Во время QSO, как звучит просьба,
не особо важно. Важна статистика для пост-процессинга лога. И по одному лишь
полю узнать, что где подтверждено - невозможно, если не делать сложную операцию
Bitwise со сдвигом. Только зачем, когда можно завести всего 4 булевских поля?

По поводу "изменять все равно придется, в каком формате данньіе в БД не сохраняй".
Нет не придется, так как есть стандарт для обмена с CAT, вот в его типе и будем хранить
частоту в базе. И по стандарту там не тип int, равно, как и в файле ADIF 2.2.6 поле для
частоты: <FREQ:8>3.581332

"А одна табличка только повторяет бумажньій журнал". Речь в топике идет не о повторении
бумажного журнала, а о том, чтобы сделать полноценный лог. Неужели не видно разницы?
Для повторения бумажного лога любой студент напишет на коленке "базюлку" на коленке
за полчаса работы. Но оно нам надо?

По поводу хранения RSTS и RSTR - можно и в двух, только для последнего номера в буквах
надо опять поле типа TEXT использовать. И зачем городить огород? Одно поле int или tinyint,
плюс text, да потом еще из разделять и мержить между собой через конкатенацию... Смысл?
Не видно профита. С одним полем через функцию Trim() куда проще.

Насчет вашего "ваше утверждение о якобьі большом обьеме служебньіх данньіх БД". Хочу
спросить, а где в вашем примерe базы на MySQL все служебные данные? Пардон, но их не видно.
Вы сначала набейте все справочники в базу и сделайте между ними связи в базе, согласно
логике, затем померьте объем. Тогда можно чего-то сравнивать. Пока же незачет!

А хранить все справочники в памяти - можно, только как их апдейтить, не понятно. И при сбое
питания надо будет дико кричать "... мать!" - так что ли?

И вообще - о чем спор-то идет? Какую базу взять и как написать лог? Если так все
просто, так давайте, напишите... и все скажут огромное спасибо. Но ведь не так это
просто... не так ли?

[UR3LCM]

Что-то ветка совсем "усохла" :-(

Если хранить локатор в поле типа TEXT SQLite, то уже не на 2 байта увеличится... И если добавить и RDA или URDA - будет еще больше.

Длина QTH Locator всегда 6 символов, и єтим можна ограничиться.
RDA, URDA - региональная/национальная специфика, которую можно расширять до бесконечности. Обозначения IOTA, крепостей, замков, заповедников, маяков, озер, горньіх массивов, городских площадей, деревенских пасбищ итд. imho єто нужно хранить как info/notes etc

... как звучит просьба, не особо важно. Важна статистика для пост-процессинга лога. И по одному лишь полю узнать, что где подтверждено - невозможно, если не делать сложную операцию Bitwise со сдвигом. Только зачем, когда можно завести всего 4 булевских поля?

О пост-процессинге с Вами согласен. Но храня все в одном поле никакие сдвиги делать не нужно, все сама СУБД делает, но не сдвигом, а imho маской. Я уже писал, что набор булевьіх переменньіх дает предложенньій тип данньіх SET('buro', .. ,'eQSL'), которьій представляет собой упакованньій набор поименованньіх булевьіх величин в каждом бите.

По поводу "изменять все равно придется, в каком формате данньіе в БД не сохраняй". Нет не придется, так как есть стандарт для обмена с CAT, вот в его типе и будем хранить частоту в базе. И по стандарту там не тип int, равно, как и в файле ADIF 2.2.6 поле для частоты: <FREQ:8>3.581332

Посмотрим какие форматьі использует DX-cluster, ADIF, HAMlib (поддержка CAT)
1) DX-кластер:
http :// www .drhnet.com/cluster.htm
DX - Command allowing the announcement of DX spot information.
Syntax: DX frequency callsign comment
The frequency can be entered in the format 14.1951 or 14195.10
Т.е. частота в МГц или КГц с точностью 100 или 10 Гц

2) Файльі в формате ADIF
http :// www .hosenose.com/adif/adif.html
Amateur Data Interchange Format 1.0 (ADIF) Specifications
2. Field Type Definitions: FREQ N in Megahertz
Частота в МГц, точность не определяется

3) Функции установки/чтения частотьі hamlib
http :// hamlib.sourceforge.net/manuals/1.2.7/html/_2tests_2testrig_8c-example.html
int rig_set_freq ( RIG * rig, vfo_t vfo, freq_t freq )
set the frequency of the target VFO
Parameters:
rig The rig handle
vfo The target VFO
freq The frequency to set to
Returns: RIG_OK if the operation has been sucessful, otherwise a negative value if an error occured (in which case, cause is set appropriately).
http :// hamlib.sourceforge.net/manuals/1.2.7/html/group__rig.html#g8c607ed599b82703db7d4029c780af27
typedef double freq_t
Frequency type, Frequency type unit in Hz, able to hold SHF frequencies.

http : // hamlib.sourceforge.net/manuals/1.2.7/html/_2tests_2testrig_8c-example.html
00110 /* 40m LSB */
00112 retcode = rig_set_freq(my_rig, RIG_VFO_CURR, 7250100); /* 40m */
00113 retcode = rig_set_mode(my_rig, RIG_VFO_CURR, RIG_MODE_LSB, RIG_PASSBAND_NORMAL);
00114 sleep(3);
...
00196 if (retcode == RIG_OK ) {
00197 printf("rig_get_freq: freq = %"PRIfreq"\n", freq);
00198 } else {
00199 printf("rig_get_freq: error = %s \n", rigerror(retcode));
00200 }
http :// hamlib.sourceforge.net/manuals/1.2.7/html/group__rig.html#g24b31a9b26962cf377e368c1c7dd9a2f
#define PRIfreq "f"

Частота указьівается в Гц. Внутреннее представление - double т.е. IEEE 754: Sign bit: 1 bit; Exponent width: 11 bits; Significand precision: 52 bits (53 implicit)

Так, что вопрос о формате для для частотьі остается открьітьім:
Поступило три предложения: Ваше - DECIMAL; мое - INTEGER UNSIGNED (4 bytes); третье (забьіл от кого) - DECIMAL (8 bytes).
DECIMAL
Для MySQL формат DECIMAL хранит значение в текстовом представлении включительно с десятичной точкой и завершающим нулем.
Плюс - произвольная точность без потери из-за конечной разрядности.
Минус -формат является наименее єкономньім. Например: 29.123456 = 10 байт. Или точность, по отношению к hamlib, надо ухудшать.
INTEGER UNSIGNED
Плюс - достаточная для ham-radio точность при компактном представлении (4 байта).
Минус - диапазон сверху ограничен 4,2 ГГц
DOUBLE
Плюс - широчайший диапазон при приемлемой точности представления.
Минус - занимает 8 байт, что в два раза больше от INTEGER

imho Если ориентироваться на hamlib, то тогда DOUBLE,
если ограничить диапазон - INTEGER UNSIGNED

Речь в топике идет не о повторении бумажного журнала, а о том, чтобы сделать полноценный лог. ... любой студент напишет на коленке "базюлку" на коленке за полчаса работы. Но оно нам надо?

Если речь идет не о проверке своих сил, а о создании серьезного АРМ радиолюбителя, тп мне кажется для Linux правильньім является не создавать свою поделку, а присоединится к существующим открьітьм проєктам. См. http : // radio.linux.org.au/?sectpat=logging&ordpat=title

По поводу хранения RSTS и RSTR - можно и в двух, только ... надо опять поле типа TEXT использовать. И зачем .. потом еще разделять и мержить ... Смысл? ... через функцию Trim() куда проще.

Только как бьіть с не contest qso? Или для них отдельную таблицу заводить, и считать - профитом?

... Хочу спросить, а где в вашем примерe базы на MySQL все служебные данные? Пардон, но их не видно. Вы сначала набейте все справочники в базу и сделайте между ними связи в базе, согласно логике, затем померьте объем. Тогда можно чего-то сравнивать. Пока же незачет!

В MySQL основная схема хранения данньіх - MyISAM. В данной схеме файльі с расширением .MYD содержат данньіе пользовтеля; -//- .MYI - информация индексирования; -//- .frm схему таблиц. В случае аварии, СУБД перестраивает индексьі, используя информацию из файлов .frm
Следовательно, - файльі с расширением .MYI и .frm содержат служебную информацию
Буду стараться войти в сессию без "хвостов" ;-)
В применяемьіх реляционньіх БД связи устанавливаются в предикатах SQL запроса (т.е. таблицьі БД сами связи не хранят, а создают только предпосьілки для них). Для установления связей необходимо наличие в таблице т.н. ключей (первичньіх и внешних). Первичньіе ключи должньі бьіть уникальньіми. Однако в случаях, когда невозможно гарантировать уникальность значений поля, существует возможность создать ключ, состоящий из нескольких полей таблицьі. Таким образом, во многих случаях установление связей приведет только к незначительному увеличению обьема БД.
При возможности попробую проверить-продемонстрировать сие на практике.

.. при сбое питания надо будет дико кричать "... мать!" - так что ли?

Питание єто ахиллесова пята любой компьютерной технологии. При сбое и диски "неслабо падают".

И вообще - о чем спор-то идет? Какую базу взять и как написать лог? Если так все просто, так давайте, напишите... и все скажут огромное спасибо. Но ведь не так это просто... не так ли?

У нас в UR сейчас єто назьівают не спор, а ДИСКУРС. Для себя я извлекаю из него много полезного. Например, по ходу освежил в памяти применение правьіх внешних обьединений, глянул внутреннее представление данньіх в hamlib и т.п.
О целесообразности участия в открьітьіх проектах см. вьше.

[RX1AL]

Что-то ветка совсем "усохла" :-(
.....
Длина QTH Locator всегда 6 символов, и єтим можна ограничиться.
Обозначения IOTA, крепостей, замков, заповедников, маяков, озер, горньіх массивов, городских площадей, деревенских пасбищ итд. imho єто нужно хранить как info/notes etc
.....

Да нет, ветка не усохла...
Поехали по вашим баранам что ли... Начнемс студента мучить:
1. Предложенный тип данных SET()
Возникает резонный вопрос: данный тип SET базы данных MySQL на какой тип данных будем маппить
в языке программирования? Без конвертера не обойтись.
2. Файльі в формате ADIF 1.0
Коллега, откуда вы вытащили сию древность доисторического периода? Давно уже стандарт 2.2.6,
где есть точность. Гугль вам поможет найти ошибку.
3. Речь не о проверке своих сил. Речь о написании нормального лога, а не поделке выходного дня.
Чтобы такой лог сваять, надо ТТЗ к нему определить, а потом садиться и писать.
4. Только как бьіть с не contest qso - Зачем заводить отдельную таблицу? Одной мало что ли?
Нужно будет завести таблицу для логов (их может быть несколько) и связать релейшн с данной таблицей.
Насчет лишнего объема не надо бояться. Не так много и будет, если использовать, например, тип аналогичный
nvarchar в сиквеле, где длина поля варьируется сама.
5. По поводу использования базы MySQL в серьезных проектах. Не мое мнение, а мнение многих, кто работает
с большими проектами: это не база. По определению. Для серьезного нужна серьезная база, а главное быстрая.
MySQL не обладает этими качествами.

И последнее. Вы только не говорите никому, что хранить все обозначения
для IOTA, RDA, WFF и т.д. надо в одном поле comma-separated или еще как,
иначе засмеют... Искать там как собираeтесь? Парсер будете писать заумный
с регулярными выражениями? А индексировать такое поле как? Неее, я в ауте!
Перл достойный копилки Ильи (бубуль-гума).

- офф -
Прошу пардона, теперь так учат реляционным базам в Украине?
Цитата:
"В применяемых реляционных БД связи устанавливаются в предикатах SQL запроса
(т.е. таблицы БД сами связи не хранят, а создают только предпосылки для них).
Для установления связей необходимо наличие в таблице т.н. ключей (первичных и внешних)."
Очень интересно... То-то у нас в универе Граца все удивляются, почему студенты с Украины
не имеют понятия о мета-данных и языке DDL (Data Definition Language). Жирным выделено
специально. А inner join тогда как же, если по каким-то причинам используются плоские
() таблицы?

PS для сиквела например, все хранится здесь в специальной таблице sys.objects:
USE Master;
GO
SELECT OBJECT_NAME(OBJECT_ID) AS NameofConstraint,
SCHEMA_NAME(schema_id) AS SchemaName,
OBJECT_NAME(parent_object_id) AS TableName,
type_desc AS ConstraintType
FROM sys.objects
WHERE type_desc LIKE '%CONSTRAINT'
GO
И для каждой базы есть своя схема.
- офф -

[UR3LCM]

1. Предложенный тип данных SET()
Возникает резонный вопрос: данный тип SET базы данных MySQL на какой тип данных будем маппить в языке программирования? Без конвертера не обойтись.

Тип SET() в реализации MYSQL занимает от 1 до восьми байт в зависимости от количества значений. Количество значений известно заранее.
Для K&R С єто будет unsigned char, unsigned int, unsigned long int.
Для С99, например - uint8 .. uint64. Вьі єтого не знали?
Для MySQL в gcc имеется отработанньій API, там есть типьі данньі: MYSQL_ROW, структура MYSQL_FIELD с типом поля FIELD_TYPE_SET.
Но зачем SET() мапить? Делаем так:
SELECT DISTINCT callsign FROM qso WHERE FIND_IN_SET('direct', qslvia) > 0; и видим всех желающих qsl direct

2. Файльі в формате ADIF 1.0
Коллега, откуда вы вытащили сию древность доисторического периода? Давно уже стандарт 2.2.6,
где есть точность. Гугль вам поможет найти ошибку.

Спасибо! Нашел 2.2.6: http :// www .adif.org/adif226.htm
Просмотрел. Ничего нового не нашел. Т.е. определение точности FREQ осталось прежним. Может бьіл невнимательньім?

3. Речь не о проверке своих сил. Речь о написании нормального лога, а не поделке выходного дня.
Чтобы такой лог сваять, надо ТТЗ к нему определить, а потом садиться и писать.

См. мой пост с вьсказьіванием о пользе от присоединения к сущестующим открьітьім проектам. Напр: http :// radio.linux.org.au/

5. По поводу использования базы MySQL в серьезных проектах. Не мое мнение, а мнение многих, кто работает с большими проектами: это не база. По определению. Для серьезного нужна серьезная база, а главное быстрая. MySQL не обладает этими качествами.

Проверить БД HAMlog на MySQL предложили мне Вьі (см. ваши прежние постьі).
Ранее я вьісказьівался в пользу PosgreSQL.
Хотя ... у меня в серьезньіх проєктах (совершенно не web) много лет трудится MySQL. Тьфу-тьфу без сбоев, и производительность устраивает.
А каков ваш вьібор? (ORACLE не предлагать, ввиду ориентации на open source)

И последнее. Вы только не говорите никому, что хранить все обозначения для IOTA, RDA, WFF и т.д. надо в одном поле comma-separated или еще как, иначе засмеют... Искать там как собираeтесь? Парсер будете писать заумный с регулярными выражениями? А индексировать такое поле как? Неее, я в ауте!
Перл достойный копилки Ильи (бубуль-гума).

Для меня "перл" єто конечно - Perl (This is perl, v5.8.8 Copyright 1987-2006, Larry Wall)
И в regex ничего заумного не вижу.
И CSV легко, даже без regex на Perl: @subfields = split(/\,/, infofield);
А можно и так:
SELECT DISTINCT callsign FROM qso WHERE FIND_IN_SET('IOTA123', info) > 0;
Да что я все вещаю, да вещаю? Вьі и так єто все знаете.
А можете, если не трудно, у себя произнести заклинание:
uname -a; free; cat /proc/cpuinfo; df -h; [ -r /etc/issue ] && cat /etc/issue; which mysqld perl gcc
и, как говорят, результат в студию представить?

Прошу пардона, теперь так учат реляционным базам в Украине?... Очень интересно... То-то у нас в универе Граца все удивляются, почему студенты с Украины не имеют понятия о мета-данных и языке DDL (Data Definition Language). ...
PS для сиквела например, все хранится здесь в специальной таблице sys.objects:
USE Master;
GO
SELECT OBJECT_NAME(OBJECT_ID) AS NameofConstraint,

imho нам следует определиться, - с какой СУБД мьі работаем, и относительно єтой реализации идей дедушки Кодда рассуждать о metadata, DDL, DML итд. А то - сик-велл да сик-велл (у нас тоже многие так произносят, желая продемонстрировать некую "западную образованность").
SRI: ORACLE не предлагать.

[RX1AL]

Тип SET() в реализации MYSQL занимает

Коллега, дабы не утомлять вас, себя и остальных... скажу:
1. Взгляните на точность в ADIF 2.2.6 еще раз: <BAND:3>80m<FREQ:8>3.581332
Если вы докажете, что 3.581332 - это unsigned int, то получите специальный приз.
2. Если вы не знаете, зачем нужно маппить полученные значения из SQL query, то
я вдвойне вам сочувствую. Так как помимо query есть и визуальные контроли, которые
отображают данные. И если пользователь захочет видеть всех LoTW, eQSL, Direct, Manager
одновременно, то будем лепить динамический запрос с where clause? А параметры откуда
будем брать? Из визуальных контролей, не так ли? И что с параметрами надо делать?
Наверное, втупую (чисто в лоб!) создать 4-ре DropDownBox, в каждый из которых поместить
значения из SET. Далее, в зависимости от выбранного занчения создавать запрос. Не слишком
ли накладно?
3. О пользе проектов с открытым текстом по линку, который вы привели. Там нет ничего
интересного. Все настолько старое, или в таком зачаточном состоянии, что если делать, так с нуля
дешевле будет по затратам.
4. Насчет серьезных проектов с MySQL. Уже все сказано на просторах интернета, о его серьезности
для энтерпрайз проектов. Повторяться не хочу.
5. Кстати, Oracle можно спокойно использовать и для опен соурс проектов - есть Personal Oracle.
Но раз вы так настаиваете...
6. Заклинание на Perl я производить не буду, по причине его отсутствия - лет 5 уже на нем не пишу,
в виду убогости для многих вещей. Есть Python, Mono (C#), F#, XAML - устраивает? Давайте потягаемся.
7. Без разницы с какой базой мы работаем... У той же MySQL 5 есть INFORMATION_SCHEMA... Или вы
мне опять докажете, что это не так?

И мой выбор, если б я начал писать: Firebird, VistaDB. Последняя имеет провайдера
для .NET под Mono (C#). А наработок уже полно под логи.

PS По поводу "западной образованности". Вы что-то имеете против такой образованности?
Я например, ничуть не против, а даже за. По крайней мере опыт здесь приобретается
иной и многому учишься. Насчет сиквела, да пока он является вместе с Oracle топ базами
данных.

[R3DMO]

Проходя мимо позвольте вставить свои 5 копеек....
Последние посты как я погляжу - дискуссия глухого и слепого!! Не поймите отвратно... Дело в том,( с моей точки зрения ) RX1AL кодит под ВЕндой, - осюда и .NET технологии и Vista, и 2008..... А вот UR3LCM кодит под Linux. Соответственно и MySql , PostageSql .... На сколько мне мой склероз не изменяет многие приложения не хотят работать под Linux из за применения .NET Вы попробуйте под Wine поставить NetFramework и всё сразу поймёте! Ну а Изначально Всёж тема какая??? Кажись Лог для Linux!!! Ну и как результат, - Большинство приложений под Линём используют Мускуль или Постадж.... Ну так и сделать на выбор!!!

[RZ4AG]

1. Взгляните на точность в ADIF 2.2.6 еще раз: <BAND:3>80m<FREQ:8>3.581332
Если вы докажете, что 3.581332 - это unsigned int, то получите специальный приз.

а кто вас заставляет хранить внутри программы частоту как значение с плавающей запятой? Намного удобнее хранить как целое, а при взаимодействии с адиф приводить к нужному виду.

[UA3GDW]

Снова говорильня как в http://forum.qrz.ru/thread22524.html
Там-то хоть дальше разговоров дело пошло?

[RZ4AG]

Там-то хоть дальше разговоров дело пошло?

чуток скриншотов нарисовали и тихо умерло...

[UA3GDW]

чуток скриншотов нарисовали и тихо умерло...

Так и думал. На словах тут один программист круче другого, а на деле...
P.S Не в обиду сказано.

[RZ4AG]

Так и думал. На словах тут один программист круче другого, а на деле...
P.S Не в обиду сказано.

А на деле надо понимать что это уйма времени и не только положительных эмоций. Кто-то это уже понял, а кто-то нет.
Технологии можно обсуждать вечно, а до ТЗ тут и не дойдет.

А то что структуру данных надо прорабатывать до того как начать - однозначно. Но к сожалению зачастую о чем сначала даже и не предполагаешь всплывает уже по ходу. Задача в том что бы минимизировать эти всплывающие аспекты.

Особенно интересен вопрос дипломной статистики

А коллективная разработка хороша только тогда когда есть тот кто скажет "хорош трепаться, делаем ВОТ ТАК!"

P.S. А крутым программистом я себя никогда не считал

[RX1AL]

Проходя мимо позвольте вставить свои 5 копеек....
Дело в том,( с моей точки зрения ) ....

Коллега, хочу поправить: ваша точка зрения ошибочна. В линуксе уже давно есть
Mono, который поддерживает .NET и база Firebird, VistaDB. В данное время проекты
по работе и не только пишутся для Ubuntu 10, Arch Linux. Кстати, с точки зрения
.NET - платформа без разницы, хоть Макинтош. И зачем ставить .NET под Wine, если
она уже встроена?
И конечно же, если приложение не работает, то виноват .NET (то есть Mono),
но не чьи-то шаловливые ручки.

RZ4AG:
По поводу хранения частоты в int. Можно пример перевода int в тип float без потери
точности?

Так и думал. На словах тут один программист круче другого, а на деле...

А на деле пишется сейчас другой лог Игорем UR5FCM на дотнет, который параллельно
портируется под линукс. И что? Все заглохло, так что ли?

PS И смайлики я б убрал... а то обидно как-то. Нехорошо. Люди, между прочим,
для вас же делают.

[RZ4AG]

По поводу хранения частоты в int. Можно пример перевода int в тип float без потери
точности?

Вот именно для уменьшения числа преобразований внутри программы целое. Потому что все трансиверы принимают частоту в герцах.

Добавлено через 4 минуты

А на деле пишется сейчас другой лог Игорем UR5FCM на дотнет, который параллельно
портируется под линукс. И что? Все заглохло, так что ли?

Была попытка что-то сделать для ТЕСТОВ вполне конкретными людьми. И Игорь там был далеко не главным идеологом. И пишет он очередной повседневный логгер с возможностью работы в тесте, а это несколько другое.

[UA3GDW]

P.S. А крутым программистом я себя никогда не считал

Да я и не про вас, в общем-то.

А на деле пишется сейчас другой лог Игорем UR5FCM на дотнет, который параллельно
портируется под линукс. И что? Все заглохло, так что ли?

И не про Игоря. А про ветку форума, ссылку которой я указал.

Люди, между прочим,
для вас же делают.

Лично для меня не надо, я для себя привык всё сам делать.

[RX1AL]

Да я и не про вас, в общем-то.


И не про Игоря. А про ветку форума, ссылку которой я указал.


Лично для меня не надо, я для себя привык всё сам делать.

Про ветку, которая заглохла - понял, да не совсем... Артур, по сведениям,
продолжает активно писать и есть хорошие результаты.

По поводу "для вас" - не имелись в виду только вы, а речь шлa о всех пользователях.
Насчет "пишу сам для себя" - да ради бога! Только не надо тогда критиковать других.
Люди ведь пишут в свое свободное время, многие и бесплатно. Или это в расчет не
берется?

RZ4AG:
По поводу хранения все же частоты в int, не будет удобно, IMHO. Интерфейс САТ воспринимает
частоту, как последовательность байт (в формате BCD с обратной последовательностью).
Причем в команде FA для установки частоты (FВ для считывания) может быть от 5 до 8 байт, в
зависимости от модели трансивера. Так, что по-любому нужен конвертер из int в BCD, и обратно.
Примерно так: x = (y -(y div 16)*16) + 10*((y div 16)-(y div 256)*16) + 100*((y div 256)-(y div 4096)*16);
где х - int, а y - BCD, как int. Ну и более ясно, что на Java, что на C#, разницы нет:
static byte[] IntToBCD(int input)
{
if (input > 9999 || input < 0)
throw new ArgumentOutOfRangeException("input");

int thousands = input / 1000;
int hundreds = (input -= thousands * 1000) / 100;
int tens = (input -= hundreds * 100) / 10;
int ones = (input -= tens * 10);

byte[] bcd = new byte[] {
(byte)(thousands << 4 | hundreds),
(byte)(tens << 4 | ones)
};

return bcd;
}

В обратную сторону аналогично. Но хранить в int, конвертируя каждый раз, IMHO,
потеря времени и быстродействия.