Пытаюсь собрать на АТМЕGA8 устройство принимающее информацию о вызывающем абоненте в формате caller id. С приемом проблем нет, а вот с расшифровкой непонятно. По найденной информации в инете первый принятый байт должен быть равен 4, а у меня почемуто 128. На одном номере информация принимается стабильно, а на другом не совпадают стоп биты (АТС SI2000).
Помогите с описанием протокола.

Вообще-то, если мне не изменяет склероз, первый байт 0x55 затем собственно пакет 0x80, общий размер, и так далее и инверсная контрольная сумма пакета по модулю 255. Делал передачу для "третих" стран, что там в России - не в курсе....

Стандарт международный.
Сначало приходит сигнал захвата канала - 30 неприрывных байтов 55h (01010101). Служит для проверки работоспособности данной функции у определителя.
Потом сигнал курьера - 1200 Hz, 130 (+/-25) мс. Служит для создания условий приёму информации.
А потом приходит 128, вместо 4.

Ага :-) и не один :-( Вот списочек:


Bellcore:
GR-30-CORE, Issue 1, December 1994
TR-NWT-000031, Issue 4, December 1992
TR-NWT-000575, Issue 1, October 1992
TR-NWT-001188, Issue 1, December 1991
TR-NWT-001401, Issue 1, September 1993
SR-TSV-002476, Issue 1, December 1992
SR-3004, Issue 2, January 1995
ETSI:
ETS 300 659-1, December 1996
ETS 300 659-2, September 1996
Draft EN 300 659-3, October 2000 (v1.3.1)
Australia:
DC.001, Issue 4, July 1997
DC.002, Issue 2, July 1997
DC.017, Issue 1, June 1997
DC.018, Issue 1, July 1997
TS 030, 1997
Other related documents that might be useful include:
British Telecom:
Suppliers Information Note: SIN242 Issue 2, November 1996
Suppliers Information Note: SIN227 Issue 2, April 1996
Cable Communications Association (CCA)
TW/P&E/312, Issue 4, April 1997


Я бегло просмотрев нашел 17 (семнадцать) вариантов.
Что там в России - аллах ее ведает. Посмотрел свои записи - делался по GR-30-CORE

Посмотрел:
0x80 это сообщение Call Setup в MDMF формате далее может следовать до 9 параметров
01h Time
02h Calling Line Identification
03h Reserved (for Dialable Directory Number (DN))
04h Reason for Absence of DN
05h Reserved (for Reason for Redirection)
06h Call Qualifier
07h Name
08h Reason for Absence of Name
0Bh Message Waiting Notification

Я передавал только 1,2,7


0x04 сообщение в SDMF формате Calling Number Delivery, а вообще типов сообщений шесть....

Все вышеупомянутое относится к североамериканскому (Bell) варианту.
А в Европе даже частоты другие 1300/2100, но похоже в Росиию поставляется "что попало" :-(

Спасибо за советы.
Ошибку нашел. Проблема была при синхронизации на первый бит.

Ну тогда у меня вопрос, для ориентации нынешних в российских реалиях - получается, что по крайней мере на "российских" Si2000 и еще "какой-то" используются передача CLIP не по европейским а по североамериканским стандартам ( через 0,5-1,5 после первого звонка 300bit mark/space, потом 180bit mark, потом пакет. Частоты 1200/2200, 1200baud и прочее) и из всего обилия передается только минималистичный пакет "0x04 - Calling Number Delivery".
Это так?

Иногда ещё дата и время (01h).

Дата и время (точнее 01h это скорее только время) может быть только субпакетом в 80h пакете.
Если 04h, то это голый номер. Мне так это представляется.
Так как это в Росии?

В пакете я вижу: месяц, день, часы, минуты и сам номер в кодировке ASCII
Пакет всегда начинается с 80H.
АТС поступает из Словении.

Начало - понятно. А дальше? Что размер и все одним куском???
Или:
0x80, full_size, 0x01, time_size, время_в_ASCII, 0x02, caller_size, номер_абонента
Частоты "американские"?



А втроая АТС, которая не Si2000, как себя ведет?

Частоты 1200\2200 Гц.
Станция одна, номера разные.
Для меня было достаточно то, что номер абонента находится всегда в одном месте, далее просто не стал разбиратся.
С недели запишу принятый пакет и пришлю (в числовом виде).
Если интересен пакет в виде wav, прилагаю.

Привожу пакет в числовом виде

53
52
5
3
57 - 9 номер абонента 20399
57 - 9
51 - 3
48 - 0
50 - 2
56 - 8 префикс станции 78
55 - 7
7
2
48 - 0 минуты (0)
48 - 0
56 - 8 часы (8)
48 - 0
49 - 1 число (21)
50 - 2
56 - 8 август (08)
48 - 0
8
1
29
128 - начало пакета

Конец пакета вероятно обрезан т.к. приемный буфер в программе ограничен.

Посоветуйте кто чем детктирует Caller ID пока нашел только микросхему фирмы CML FX604 если память не изменяет. Но уж очень мне не понравилась политика этой фирмы - пихат в чипы кучу всякого. В результате высокие цены. Может удается контроллером детектировать?

Китайцы пользуют CMX602, HT9032. Последнюю чаще.
Еще от Elan семейство МК с Caller ID на борту: http://www.emc.com.tw/eng/ptl_cidtp_ds.asp?gid=A000008
(требуется регистрация).

Стоит задача: программно расшифровать пакет CLIP FSK.
Пожалуйста, помогите в какую сторону копать? Пытался работать с цифровыми фильтрами -
не получилось: длительность одного бита 1-2 периода частоты.
Ясно, что надо что-то другое.

Александр_в, спасибо за звуковой файл. Только у меня данные несколько отличаются от приведенных Вами:
$80,$1d,$01,$08,$30,$38,$30,$34,$31,$37,$33,$32,$02,$07,$37,$38,$32,$30,$33,$39,$39,$03,$05,$34,$35,$30,$38,$33,$08,$01,$4f,$de

Дополнительный код совпал с контрольной суммой($80+$1d+$01+$08+$30+$38+$30+$34+$31+$37+$33+$32+$02+$07+$37+$38+$32+$30+$33+$39+$39+$03+$05+$34+$35+$30+$38+$33+$08+$01
+$4f)+1=$de